John Wilger

The Tools You Build Are More Important Than The Tools You Use

Unknown — Mon, 29 Dec 2025 00:00:00 +0000

There's a pattern I've noticed among developers working with AI coding assistants. Some are having transformative experiences—shipping features faster, tackling problems they'd previously avoided, genuinely enjoying their work more. Others are frustrated, producing buggy code, and increasingly skeptical that these tools offer anything beyond fancy autocomplete.

The difference isn't the model they're using. It's not their prompting technique. It's not even their underlying programming skill, though that certainly matters.

The developers succeeding with LLM-augmented development have stopped waiting for the perfect out-of-the-box experience and started building their own tools to solve their own problems.

The Myth of the Perfect Configuration</h1>
When Claude Code, Cursor, Windsurf, and similar tools started gaining traction, a cottage industry of "optimal configurations" emerged. GitHub repositories full of system prompts. Blog posts about the "ultimate" rules file. YouTube videos promising 10x productivity if you just copy these exact settings.
I tried many of them. Some helped marginally. Most did nothing. A few actively made things worse because they were optimized for someone else's workflow, someone else's codebase, someone else's pain points.
This shouldn't have surprised me. I've spent two decades watching the same pattern play out with every development tool and methodology. Cargo-culting someone else's Agile process doesn't make you agile. Copying another team's CI/CD pipeline doesn't give you their deployment confidence. Using the same text editor as a famous programmer doesn't make you write better code.
The tool is never the thing. The thing is understanding your own problems deeply enough to know what tool you need.

A Problem Worth Solving</h1>
I'd been using Claude Code heavily for several months, and one friction point kept recurring: GitHub issue management.
Not the basic stuff—creating issues, closing them, adding labels. The `gh</code> CLI handles that fine, and Claude can drive it without much trouble. The friction was in the relationships between issues.`
`I work with hierarchical issue structures. Epics contain stories. Stories contain tasks. Tasks might have sub-tasks. When you're trying to keep Claude oriented on what you're building and why, being able to say "this task is part of story #42, which is part of epic #15, which is about the payment system redesign" provides crucial context.`
`GitHub added sub-issues and blocking relationships over the past year, but they're only accessible through the web UI or the GraphQL API. Every time I needed Claude to help me restructure issue hierarchies or track dependencies, we'd end up in a frustrating dance: Claude would attempt some gh api graphql</code> call, get the syntax wrong, try again, get the escaping wrong, try again, finally succeed, and by then I'd lost my train of thought on the actual problem I was trying to solve.`
`Worse, if I wanted to grant Claude permission to manage issues autonomously, I'd have to approve Bash(gh api:*)</code> in my settings—which is far too broad. That pattern would let Claude make arbitrary API calls to GitHub, not just issue management operations.`
`I could have lived with this friction. Most people do. They work around limitations, accept the rough edges, wait for someone else to build a better solution.`
`Instead, I decided to build the tool I needed.`

The Development Process (With an AI Partner)</h1> Here's where things get interesting. I didn't just sit down and write a GitHub CLI extension from scratch. I used Claude Code to help me build the tool that would make Claude Code more effective. The process started with research. I asked Claude to investigate the GitHub GraphQL API, find the relevant mutations for sub-issues and blocking relationships, and figure out what operations were possible. This took some trial and error—we created test issues, experimented with API calls, discovered that sub-issues require a special GraphQL-Features: sub_issues</code> header, learned that blocking relationships use issueId</code> and blockingIssueId</code> parameters (not the more intuitive names I initially guessed). Every failed API call taught us something. Every error message refined our understanding. Claude kept notes, I asked questions, and gradually a clear picture emerged of what was possible and what syntax was required. Then came the key insight: we could wrap all these GraphQL operations in a gh</code> CLI extension. Instead of Claude needing to construct complex API calls every time, it could use simple commands like gh issue-ext sub add 10 42</code>. And critically, I could grant permission for Bash(gh issue-ext:*)</code> without opening the door to arbitrary API access. The extension itself took maybe 20 minutes to write—a bash script that handles argument parsing, constructs the appropriate GraphQL queries, and presents results in both human-readable and JSON formats. Claude did most of the implementation work while I reviewed, asked questions, and occasionally corrected course. But the extension was only half the solution. I also needed Claude to know how to use it effectively. So we built a Claude Code plugin: a skill document that teaches Claude about GitHub issue management, comprehensive reference documentation for every command, a setup command that installs the extension, and a session-start hook that reminds users if they haven't installed the extension yet. The whole thing—research, experimentation, extension development, plugin creation, documentation—took an hour. And now I have a tool that solves my specific problem in exactly the way I need it solved. Why This Matters</h1> Let me be clear about something: the plugin I built isn't revolutionary. It's a wrapper around existing APIs with some documentation. Anyone could have built it. But almost no one does. Most developers treat their AI coding tools as fixed artifacts. The tool does what it does; your job is to figure out how to work within its constraints. If something is frustrating, you either live with it or switch to a different tool and hope it's better. This mindset made sense when tools were expensive to modify. Writing an IDE plugin used to be a significant undertaking. Customizing your build system required deep expertise. The cost of building your own tools was high enough that it was usually better to adapt your workflow to existing solutions. But that equation has changed. When you have an AI assistant that can help you build tools, the cost of custom solutions drops dramatically. That time I spent building the GitHub issue extension? I couldn't have done it that quickly five years ago. The research alone would have taken longer than the entire project did with Claude's help. This creates a flywheel effect. You use AI to build tools. Better tools make your AI assistant more effective. A more effective AI assistant helps you build better tools faster. Each iteration compounds. The Meta-Skill</h1> The developers I see thriving with AI coding assistants have developed a specific meta-skill: they notice friction, investigate root causes, and build solutions—rather than accepting friction as the cost of using new technology. This requires a particular mindset: Treat configuration as code. Your rules files, system prompts, custom commands, and plugins are part of your development environment. They deserve the same attention you'd give any other code you maintain. Version control them. Iterate on them. Share them when they might help others, but don't expect others' configurations to solve your problems. Pay attention to repeated friction. Every time you find yourself working around a limitation, every time Claude makes the same mistake twice, every time you have to manually intervene in something that should be automatic—that's a signal. You've found a problem worth solving. Invest in understanding. Before building a solution, make sure you understand the problem deeply. My GitHub issue extension works because I spent time learning exactly how the GraphQL API behaves, what parameters it expects, what errors it returns. That understanding is embedded in the tool and the documentation. Build incrementally. You don't need to solve everything at once. I started with just sub-issue management because that was my most pressing pain point. Blocking relationships and linked branches came later. Each addition was motivated by a real problem I'd encountered. Document for your AI partner. Half of building effective tooling is teaching your AI assistant how to use it. The skill documentation I wrote for Claude isn't just for human readers—it's optimized for Claude to consume and apply. Clear examples, explicit command syntax, common patterns and workflows. The Uncomfortable Truth</h1> There's an uncomfortable truth in all of this: the people who benefit most from AI coding assistants are the people who needed them least. Experienced developers who already understand their problem domains deeply can direct AI assistants effectively. They know what questions to ask. They can evaluate generated solutions. They can identify when the AI is confidently wrong. And crucially, they have the skills to build custom tools when off-the-shelf solutions fall short. Less experienced developers often struggle because they're trying to use AI assistants as a shortcut past understanding. They want the tool to just work, to give them correct answers without requiring them to evaluate those answers critically. When friction appears, they lack the context to even recognize that a solution might exist. I don't have a neat resolution for this tension. AI coding tools genuinely do lower the barrier to building software. But they lower it most for people who've already climbed over that barrier. Perhaps the best thing experienced developers can do is model this tool-building behavior openly. When you solve a problem by building a custom extension or plugin, share not just the artifact but the process. Show how you identified the friction, how you investigated solutions, how you iterated toward something that worked. The tools we build are artifacts of our understanding. Sharing them helps. But sharing how we built them helps more. Getting Started</h1> If you've read this far and want to try building your own Claude Code tooling, here's what I'd suggest: Start with your actual problems. Don't go looking for things to optimize. Instead, pay attention over the next week. When do you feel friction? When does Claude struggle with something that should be straightforward? Write these down. Pick the smallest valuable problem. You don't need to build a comprehensive solution. Find something specific and bounded. Maybe it's a single command that automates a repetitive task. Maybe it's a snippet of documentation that helps Claude understand your project's conventions. Use Claude to build it. This is genuinely effective. Describe the problem you're trying to solve, work through potential solutions, iterate until you have something that works. You'll learn about Claude's capabilities and limitations in the process. Test it in real work. The best tools emerge from actual use. Build something minimal, use it for a few days, notice what's missing or awkward, improve it. Share what you learn. Not just the finished tool—the process, the problems, the failed approaches. Someone else has the same friction you do. They might not have realized yet that building a solution is possible. The GitHub issue management plugin I built is available at https://github.com/jwilger/claude-code-plugins</a>, and the gh extension is at https://github.com/jwilger/gh-issue-ext</a>. You're welcome to use them if they solve problems you have. But more than that, I hope this piece encourages you to notice your own friction and do something about it. The tools you build for yourself will always fit better than the tools you borrow from others.



The Hidden Pitfalls of AI Software Development
Unknown — Tue, 11 Mar 2025 00:00:00 +0000
Before we start, I want to make it clear that I'm not going to "blame the controller" for losing this game. I've always believed that a software engineer using AI assistants to write code is still responsible for reviewing and understanding every line of that code, and this situation is no different. Even though the issue I faced was unexpected, it's still completely my responsibility. I'm just relieved that I'm the only one affected and that it didn't happen in a situation involving a client.</em></p>
I've been trying out different AI-assisted software development workflows recently so I can guide clients and colleagues on which tools and methods to use or avoid. One setup I find quite promising is Goose</a>, an on-machine AI agent that interacts with the system through extensions using an MCP server. When used with a .goosehints</code> file, which gives instructions for a ping-pong pairing, TDD approach to development, I've been quite impressed with its capabilities and how it can be adjusted to fit specific workflow preferences.</p>
As part of my experimentation, I used Goose to help create a small TypeScript CLI utility. This tool takes a CSV file, where each record is a latitude/longitude coordinate pair, as input and outputs a new CSV file that includes the associated business name, website, and telephone number from the Google Places API. This task, having never used the Places API before and not being a regular TypeScript author, would likely have taken me 2-3 hours to complete. With AI assistance, it was done in about an hour. It was a complete, working solution that easily processed a test file with about 10,000 rows. It had full test coverage, and the code quality was decent, if not perfect. Success, right?</p>
The problem is that bugs and low-quality code aren't the only issues that can cause trouble.</p>
In my first attempt at creating this utility, I only extracted the business names from the Places API for each record. A quick check of the Places API pricing showed that I could make 10,000 requests for free, and additional requests up to 100,000 would cost $5 per 1,000 requests. Running an input file with 20,000 rows would cost about $50. I thought this expense was reasonable for the experiment, but I also wanted to avoid unnecessary spending. So, I decided to use a 10,000-row input file to stay closer to the free tier and maybe only spend $5-10 on the extra requests needed during testing.</p>
Once I got the basic version working by refining the solution with Goose, I then asked Goose if I could also include the website URL and phone number for the business in the output. Goose was happy to help and did a great job updating the existing solution, including the tests, without unnecessarily rewriting major parts of the code.</p>
At this point, anyone familiar with the Google Places API is probably shaking their head and laughing at my mistake.</p>
The pricing I was looking at was for their "Place Details Essentials" level of requests. By simply asking for these two extra fields, URL and phone number, the request automatically moved to their "Place Details Enterprise" tier, which is much more expensive. At this tier, you only get 1,000 requests per month for free, and you pay $20 per 1,000 requests</strong> for anything beyond that! You can imagine my shock and horror when I received emails from Google later that day saying they had received payments from me totaling just under $2,000.00!</p>
This probably wouldn't have happened if I had been writing this code without AI assistance. I would have needed to review the API documentation for the Places API to find out how to get those two additional fields of data. At that point, I likely would have noticed that this would move me into a different pricing tier. However, since using AI assistance meant I didn't need to look up this information myself, I didn't notice the change. I happily ran my tests and then the entire test file, and I was quite pleased with the output. It was a job well done, and it probably took about an hour less than it would have if I had written the code myself.</p>
This post is not a criticism of Goose specifically; the issue I faced could happen with any LLM-based coding assistant. In fact, I would argue that the better the tool (and the more you trust it), the more likely you are to encounter a similar issue. The problem wasn't with the code itself. I reviewed the code before running it and made sure I understood what each line was doing. What I didn't do was thoroughly consider other factors that a professional software engineer should evaluate, such as the financial cost of running the solution. Thankfully, this was just a personal project and not a client system, so I'm the only one dealing with the consequences. Now imagine if a less-experienced developer made a similar mistake in a production system that processed many more records over a month. The consequences of that decision could be much worse.</p>
While AI-assisted coding tools like Goose can significantly enhance productivity and streamline the development process, they also introduce new challenges and responsibilities for developers. It's crucial for software engineers to remain vigilant and thoroughly review not just the code, but also the broader implications of their work, such as financial costs and potential impacts on production systems. This experience underscores the importance of maintaining a balance between leveraging AI capabilities and exercising professional diligence to avoid costly oversights. As AI tools continue to evolve, developers must adapt and refine their practices to ensure they harness these technologies effectively and responsibly.</p>


The Language Model Is Just Another User
Unknown — Thu, 21 Mar 2024 00:00:00 +0000
The first time I worked on an application that heavily relied on OpenAI's chat completion API, my years of experience managing APIs within an extensive service infrastructure shaped my approach. It seemed straightforward: it was just another JSON API where you send a request to a known endpoint and get back data in a specific format. However, as the development progressed, we encountered problems due to the unpredictable nature of the generative AI responses. Features that worked one day would suddenly cause errors the next, leading us into a repetitive cycle of tweaking the application code and the prompts we were using. This situation was unsustainable; I couldn't in good conscience tell my client that their application was "complete" when it could break down at any moment. Is building anything more sophisticated than a fancy chatbot using this technology even possible?</p>
![](https://cdn.hashnode.com/res/hashnode/image/upload/v1710518866017/e8877cff-7fb0-4e49-ae69-1f47a2847c94.webp align="center")</p>
The system architecture we were using led me to a realization that has completely changed how I now integrate generative AI features into an application. I've always appreciated event-sourcing and CQRS (Command Query Responsibility Separation) architectures. We were developing this application in Elixir using the Commanded library. In this architecture, whenever a user performs an action that changes the system's state (like submitting an order form), this action is captured as a "command" that shows the intent to change the state. This command is checked and carried out, leading to either an error message or a state-change event. These events are the truth for the entire application's state, and no changes to the system's data happen without a matching event. The system records events in response to the language model's changes, just like those made by human users. Although it's possible to write an event directly to the event stream, the Commanded library makes it much easier to create a simple command that the system can execute, which results in the recording of an event.</p>
It took me longer than I'd like to admit to see how everything fit together. The human user and the language model change the system's state using the same basic process: the command. Once I realized this, I wondered if we were approaching this from the wrong perspective. What are we using generative AI for? In most situations, a language model is creating results that a skilled user could also achieve on their own; we use these models as an aid to help us bridge a gap in either knowledge or efficiency. They aren't a part</em> of the application as much as they are an assistant in working with</em> it.</p>
As I mentioned in an earlier piece about how generative AI is changing UX paradigms</a>, we successfully let the language model control many aspects of an application humans would have previously performed. When creating APEX</a>, a generative-AI-integrated application we made at Artium to help produce product plans that are well-grounded in the needs of the business, we could have taken a different approach to the interaction. We could have had the user click on nodes, click an edit button, fill out a form with the information they wanted in each section, and click "save," and to incorporate generative AI, we could have put a little AI-sparkle button next to the text fields and used the model to fill in just that one piece.</p>
Instead, the primary means of interacting with APEX is via a back-and-forth conversation with "the Artisan." The Artisan isn't just a chatbot that gives you the text to put into a form field; it can also update that text for you in the right spot.</p>
![](https://cdn.hashnode.com/res/hashnode/image/upload/v1710490780687/caa42080-902b-4113-aa17-a01b8be68c7e.png align="center")</p>
Imagine you're on a call with someone and you’re collaborating on a Google Doc. You read through the text they've just written and suggest changes. Right before your eyes, you see the text change as your writing partner edits the document on another computer. Once upon a time, that felt magical; today, it's mundane.</p>
Using APEX to build a product plan is similar to this style of collaborative editing. The difference is that your writing partner is a language model that understands how to use the application. Sometimes, it offers its own opinions, but it also does what you say verbatim when you are explicit. Sometimes, it produces results you will love; sometimes, you need to iterate on its suggestions.</p>
Witnessing this approach come together, I realized that this is precisely where generative AI can shine when integrated into our applications. I also learned how we can make language models a much more reliable part of our systems.</p>
Rather than treating the language model as an internal component of your system, a better approach is to consider it as just another user sitting at their computer and sending inputs to the system. By treating the output from the language model precisely</em> as if it had been typed into a form by a human user, the solutions to non-deterministic inputs suddenly become clear. It's just form validation.</p>
![](https://cdn.hashnode.com/res/hashnode/image/upload/v1710490806221/24df3557-4a7a-46ca-8616-59286bca8716.webp align="center")</p>
Build your application as though multiple humans can concurrently and collaboratively edit the same entities. Then, teach your model to control your application. For example, your two human users might have a text chat about the documents they are working on. Treat text responses from the language model the same way; your application code processes the response by executing the same SendMessage command that a human user invokes if they click the send button on a message they typed. If the language model determines it needs to change the title of a document, it must send a message back that your client code can translate into an application command such as UpdateTitle. This command, again, is the same UpdateTitle command that the system will execute if a user clicks an "edit" link next to the title, changes the text, and then hits "save."</p>
How you handle an invalid attempt to change the system data is an essential aspect of this approach. Language models work best with plain, human language. While their ability to run completions of computer code is currently helpful and still improving, typical language models are better at working with good old-fashioned prose. Because of this, you should respond to the incorrect function call in the same way you'd react to the human user: show it the natural language descriptions of the errors.</p>
For example, we have a rule that a document title must be unique in the system. We enforce this invariant at the command execution layer. When a title is not unique, instead of recording a TitleUpdated event, the system responds with an error message: "Another document already uses the title Foo Bar Baz." If the language model sees this error in your response, it will have enough information to correct itself and attempt to execute the UpdateTitle command again with a different title. If, instead, the model receives a machine-friendly error message like "dup_title," there is less of a chance that it will interpret that to mean an error occurred or that it will sufficiently address the mistake.</p>
Treating generative AI as just another user of your application means that you'll also be well-situated to add human/human or human/human/AI collaboration, should that be desired. It becomes more apparent how to handle errors when you receive invalid data or when the model tries to interact with your application in ways that aren't available to it, such as hallucinating functionality that doesn't exist or isn't permitted. Additionally, much knowledge and experience exists in designing UX for collaborative-editing applications. Rather than reinventing the wheel, we can rely on this existing body of knowledge to guide how we approach UX for generative-AI-enhanced applications.</p>
By changing your perspective on the role that generative AI plays in your application, you can both delight your users and create an application that is more fault-tolerant and easier to maintain.</p>


Generative AI is a UX Revolution
Unknown — Tue, 12 Mar 2024 00:00:00 +0000
When I first engaged with computers, the landscape was predominantly shaped by command-line interfaces, a stark contrast to the GUI-based systems like Windows or MacOS that later emerged and democratized computing. This transformation was monumental, making technology accessible to a broader audience. Yet, it also introduced a dichotomy: while GUIs simplified interactions for the majority, they often fell short for expert users who valued the precision and efficiency of command-line interfaces. This divide underscored a technological gap where neither GUIs nor command-line interfaces could entirely meet the diverse needs of users. Attempts to redesign expert interfaces into graphical formats frequently resulted in a confusing mishmash of buttons and menus, complicating the user experience for novices without offering significant advantages to experts over the command line. Consequently, we find ourselves in a world where applications are often neither intuitive nor efficient, highlighting a significant challenge in the quest for inclusive and effective user interfaces.</p>
In my role as a software engineer, I prefer using command-line and keyboard-driven tools. I avoid using the mouse while programming, not because I think "real programmers don't use mice," but because reaching for the mouse is significantly slower for tasks like navigating files, editing text, and running programs. Therefore, you'll often find me in a full-screen terminal window, using tmux (a tool for managing multiple terminal sessions in one window) and vim (a highly customizable text editor). Over time, I've developed a set of configuration tweaks and shell scripts that help me work efficiently. I use a minimalist UI that keeps the code I'm working on in focus, without the distraction of unnecessary UI elements that require mouse clicks.</p>
![This is my entire main screen when programming.](https://cdn.hashnode.com/res/hashnode/image/upload/v1709939093205/b1a60861-5844-4855-8ec2-84377132c4e2.png align="center")</p>
However, for those unfamiliar with these tools, becoming immediately productive in this environment can be quite challenging. I've been working this way for over 20 years, and I’m still finding new ways to boost my efficiency with vim. Given that I use this application almost daily for long hours as a crucial tool of my trade, the time invested in learning to use it as efficiently as possible is highly worthwhile. That said, I wouldn't suggest that all user interfaces should require this level of expertise to be effective. When I come across a system I'm not familiar with, I really value a simple, intuitive interface that helps me do the right thing.</p>
On the other side of the spectrum, there are people who aren't as familiar with computer technology and can get frustrated by systems, even when those systems are meant to be used with a mouse or trackpad. My wife is one such person. She's not computer illiterate, but she often gets frustrated with websites and applications when she knows what she wants to do but can't find the right buttons to press to make it happen.</p>
![](https://cdn.hashnode.com/res/hashnode/image/upload/v1709941595065/2804c54e-2218-4d1d-928c-f38cdce625f0.webp align="center")</p>
Recently, at Artium</a>, I've been involved in building a new product called APEX</a>, where we are exploring a new approach to how users interact with applications. APEX is a tool to help you take an idea for a software product and bring that idea to life by walking you through the process of defining the problem space, refining the product vision and value proposition, and then focusing on the key users of the application and how they will use it. The goal is to arrive at an actionable plan for building the initial version of your product and provide you with the information you need to create a proposal and business plan that will help you launch your product. The primary interaction with APEX involves exchanging messages with a generative AI assistant. However, this is not just an AI chatbot that is generating text in a chat window for you to copy and paste into your plan. Our assistant is actively updating the representation of your product on-screen as your conversation progresses.</p>
![](https://cdn.hashnode.com/res/hashnode/image/upload/v1710267850978/5b83104c-e624-4469-99be-6325a60c1830.png align="center")</p>
This style of interaction represents a pivotal shift from the traditional dichotomy of GUI and command-line interfaces. By adopting a conversational, AI-driven approach, we can create a unified interface that intuitively adapts to the user's expertise level—simplifying the learning curve for novices while providing the depth and efficiency that experts crave. This adaptability showcases how generative AI can transcend the limitations of previous technologies, offering a seamless, inclusive user experience that traditional interfaces have struggled to provide.</p>
While getting ready to launch our open beta for APEX, I asked my wife to try using the application to plan out a product. She was able to get through the entire process, and amazingly, I didn't hear her get frustrated with it even once. She is a registered nurse by trade, and as I mentioned before, she is often frustrated with computer programs; this is not someone who has experience with product design or comes to the table with a high level of knowledge about computer systems. When I asked her about the experience, she told me that she much preferred this way of interacting with a computer because it was just like having a conversation with another person. Rather than having to feel overwhelmed by options or frustrated that she couldn't figure out how to change something, she was able to simply converse with the assistant and watch the updates happen in the display of the product. And there are no "wrong answers" when talking to the assistant. If you misunderstand a question or simply choose to focus on a different aspect of the product, the assistant is able to adjust, guide, and redirect to help you complete your task.</p>
What is amazing to me is that this style of interaction is equally appealing to me as an expert user of the system. While the conversation and guidance of the assistant can be essential for a novice user who doesn't necessarily understand how to approach product planning, as someone who does understand both the process and the types of information that APEX manages, I am able to very quickly create a product plan without ever touching my computer's mouse by simply being explicit with the assistant with my directions. I can directly say "set the product title to MyAwesomeProduct", and it does it. If I say "use Elixir, Phoenix, and LiveView with a Postgres data store", it updates the Technology section without me having to wait for the assistant to ask me about that. If I already have text-based documentation about a product idea (typed notes from a client planning session, for example), I can simply paste those notes into the assistant window and tell it to create a product plan based on those notes.</p>
Despite the promise of generative AI in enhancing UX, several challenges loom. One significant concern is the potential for AI to misunderstand user intent, leading to frustrating experiences or, in worst-case scenarios, harmful outcomes. Ensuring that AI systems can accurately interpret and act on a wide range of human inputs is crucial for their success. Additionally, ethical considerations are at the heart of deploying generative AI in any user-facing application. Issues such as bias in AI responses, transparency in how AI decisions are made, and the autonomy of users in guiding the AI's actions are critical. As we integrate AI more deeply into our lives, ensuring these systems enhance rather than undermine human autonomy, respect user privacy, and promote fairness and inclusivity will be essential. By addressing these ethical challenges head-on, we can harness the benefits of generative AI while minimizing potential harms. Addressing these challenges requires new approaches to software testing to account for the non-deterministic nature of generative AI responses. At Artium, we have also been pioneering the use of Continuous Alignment Testing</a> to ensure that products using generative AI are able to function with a high degree of confidence and safety.</p>
The impact of generative AI on UX design, as shown by our work on APEX, is clear. By enabling a more natural, conversational interaction with technology, we're doing more than just making applications more accessible and efficient; we're changing how humans interact with computers. This move towards intuitive, adaptive interfaces suggests a future where technology truly serves everyone, no matter their background or level of expertise. As we keep improving and broadening the abilities of generative AI, the potential for innovation in UX seems endless. The evolution from command lines to conversational interfaces is just the start of a UX revolution that will keep growing and surprising us.</p>
I did not and could not have produced APEX on my own in the time that we were able to bring this together. APEX would not have been possible without the team that created it:</em></p>


Cauri Jaye</em></p>
</li>

Ross Hale</em></p>
</li>

Serena Epstein</em></p>
</li>

Michael McCormick</em></p>
</li>

Ryan Durling</em></p>
</li>

Nick Mahoney</em></p>
</li>

George Wambold</em></p>
</li>

Nafisa Rawji</em></p>
</li>

Mark Whaley</em></p>
</li>

James Lenhart</em></p>
</li>

Chay Landaverde</em></p>
</li>

Gene Gurvich</em></p>
</li>

Randy Lutcavich</em></p>
</li>

John Wilger</em></p>
</li>

and the rest of the Artium team who supported our work</em></p>
</li>
</ul>


Using the 27" LG UltraFine 5k Display with Linux
Unknown — Thu, 07 Dec 2023 00:00:00 +0000

UPDATE 2019-07-25:</strong></p>
Based on some comments made on the original post below, I swapped out the Asus ThunderboltEX 2 AIC
for a Gigabyte GC-Titan Ridge Thunderbolt AIC that supports two DisplayPort inputs. I'm happy to
report that I can now use the monitor in full 5k resolution and</em> that X11, GDM, and Gnome were
able to autodetect all of the correct settings (after removing the /etc/X11/xorg.conf</code>,
$HOME/.config/monitors.xml</code>, and /var/lib/gdm3/.config/monitors.xml</code> files in order to get the
autodetection to kick in.)</p>
</section>

UPDATE 2019-07-26:</strong></p>
Interestingly, the computer stopped recognizing the USB devices (speaker and microphone) in the
monitor with the new, GC-Titan Ridge TB3 AIC installed. With the previous AIC, I did not
specifically turn on any of the Discrete Thunderbolt Support options in the BIOS and everything
was working fine. It would seem, however, that this AIC requires some BIOS settings to get
everything working.</p>
I found these directions for setting up TB3 in the Asus Prime Z390-A
BIOS</a>.
In this case, the author was attempting to configure the BIOS for a Hackintosh build, but I
cargo-culted the setup anyway with the exception of setting the Windows 10 Thunderbolt Support
(when I attempted to set that to the specified value, the BIOS utility just froze up completely.)</p>
After changing those BIOS settings, the USB audio in the monitor was detected just fine on
startup.</p>
</section>
Lachlan and I built a new desktop PC this past weekend (something I haven't done
in probably 15 years). Over the past couple of years, I've grown more and more
annoyed with some of the choices Apple has been making with MacOS that have made
it more annoying to use the system for the kind of software development I do,
and I've had an itch to return to my first love: Linux. I've also wanted to
share that experience of building up a computer with Lachlan for a while, since
he's the one of my kids who is really into all things technology. To be honest,
while I brought the knowledge and experience of how to safely handle the
equipment and debug any issues, Lachlan was the one who brought the knowledge of
what technology is available today and was able to give great advice in terms of
picking out the processor, motherboard, and video card.</p>
We had one particular challenge, though, in building this system. Last year, I
bought one of the new 27" LG UltraFine 5k displays to use with my Macbook. It's
truly a beautiful display in terms of picture quality, and...well...it was
pretty darned expensive, too. What I stupidly didn't realize at the time is that
it only</em> has a Thunderbolt input and would pretty much only work "out of the
box" with the newest Macbooks. D'oh!</p>
A little research showed hints of being able to get the LG 5k monitor to work
with a PC if you have a motherboard that provides a Thunderbolt header and</em> you
install a special Thunderbolt AIC (add-in card) that has a mini-DisplayPort
input. The idea is that you use a patch cable to feed the DisplayPort output
from your video card into the Thunderbolt AIC's mini-DisplayPort input, and then
the AIC will send the video signal through its Thunderbolt output. Unfortunately
there was not a huge amount of information out there about this particular
setup, particularly with regard to Linux support.</p>
We decided to go ahead and try to get it working. While we spec'ed out the
system with that as a central constraint, the AIC itself only cost around $35.00
(USD), and the rest of the system would still be great aside from that. If it
didn't work out, the worst case was that I'd sell the LG 5k monitor and buy a
new monitor with regular DisplayPort inputs—a hassle, but not a disaster.</p>
I'm happy to report that we did</em> get the monitor working great with Linux after
a lot of trial and error (see below for the details about configuring Linux to
work with this setup) and all of the other hardware worked well out of the box
(except for the lack of any Linux drivers for all of the Asus Aura RGB stuff,
which is only an aesthetic complaint—although an annoying one, because there is
no way to turn off the slowly flashing red glow on the video card).</p>
Here is the part-list for the build:</p>

CPU: Intel Core i9-9900k 5.0 GHz</li>
CPU Cooler: Noctua NH-D15 82.5 CFM CPU Cooler</li>
Motherboard: Asus Prime Z390-A ATX LGA1151</li>
Memory: Corsair Vengeance LPX 16 GB (2 x 8 GB) DDR4-3000</li>
Storage: Samsung 970 Evo 250 GB M.2-2280 Solid State Drive</li>
Video Card: Asus GeForce GTX 1070 8 GB STRIX Video Card</li>
Case: Corsair 760T Black ATX Full Tower Case</li>
Power Supply: EVGA SuperNOVA G2 650 W 80+ Gold Cerified Fully-Modular ATX</li>
Wireless Adapter: Gigbyte GC-WB867D-I PCI-Express x1 802.11a/b/g/n/ac WiFi
Adapter</li>
Thunderbolt AIC: Asus ThunderboltEX 3</li>
Operating System: Ubuntu Linux 18.10</li>
</ul>
After building the system with this configuration, running the Nvidia's DP
output into the Thunderbolt AIC, and connecting the LG 5k monitor via its
Thunderbolt cable, a fresh install of Ubuntu loaded up fine, and we were able to
log into the Gnome 3 desktop just fine. Unfortunately (or perhaps fortunately in
this case?), Nvidia does not provide their own open-source drivers for Linux,
and Ubuntu does not install the closed-source drivers by default. Instead, you
get the open-source nouveau driver. That driver works fine for most things, but
if we wanted to settle for "most things", we'd just have used the on-board GPU
of the motherboard. In order to take advantage of the Nvidia's capabilities, we
needed to install the proprietary Nvidia drivers. Ubuntu's apt repository
contains the nvidia-driver-390</code> package, and they even make it easy to switch
to it by running ubuntu-drivers autoinstall</code>, however the distribution lags
behind the official release of the drivers, which are up to version 415 as of
this writing. In order to have access to the latest drivers, just add the PPA
and update apt:</p>
sudo add-apt-repository ppa:graphics-drivers/ppa
sudo apt-get update
</code></pre>
Then you can install the proprietary driver with:</p>
sudo apt install nvidia-driver-415 # or whatever the latest version is
</code></pre>
This will add the appropriate kernel module and some necessary configuration.</p>
Then you'll reboot your computer, and...</p>
The desktop manager won't load. You'll probably be staring at a blank screen,
perhaps with a blinking cursor.</p>
Luckily, I do have another display here at the house that has an HDMI input, so
we were able to hook that display up for some debugging. We hooked up the other
display and rebooted. This time, GDM loaded up on the HDMI display just fine. I
then reattached the LG display as a second monitor. Nothing showed up on it,
but</em>, it showed up as a monitor in Gnome's display settings. Heh. That's
weird...</p>
On a whim, I changed the resolution of the LG display from "auto" to 4096x2304,
and...all of the sudden it worked!</em></p>
I don't know for sure, but my guess is that something about being passed through
the Thunderbolt AIC is causing the automatic detection of the resolution to
fail.</p>
Great, we're done now, right?</p>
Not exactly. I'll spare you the details of the rest of the debugging we went
through (lot's</em> of trial and error, searching Google, and piecing together what
I could find from people who had sort-of-kind-of similar symptoms here and
there, but never all in the same combination, and definitely never with this set
of hardware.) Suffice it to say that the solution lies in being very</em> specific
about configuring the display with all three of Xorg, GDM, and Gnome. Here are
the contents of the configuration files that needed to be changed in order to
get this working on the new system (you may need to tweak them a bit if you have
a different combination of hardware, but hopefully this saves you from the hours
of trial and error!):</p>
In /etc/X11/xorg.conf</code>:</p>
# nvidia-settings: X configuration file generated by nvidia-settings
# nvidia-settings:  version 415.27


Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0" 0 0
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
    Option         "Xinerama" "0"
EndSection

Section "Files"
EndSection

Section "Module"
    Load           "dbe"
    Load           "extmod"
    Load           "type1"
    Load           "freetype"
    Load           "glx"
EndSection

Section "InputDevice"

    # generated from default
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/psaux"
    Option         "Emulate3Buttons" "no"
    Option         "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"

    # generated from default
    Identifier     "Keyboard0"
    Driver         "kbd"
EndSection

Section "Monitor"

    # HorizSync source: edid, VertRefresh source: edid
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "LG Electronics LG UltraFine"
    HorizSync       31.5 - 177.7
    VertRefresh     60.0 - 60.0
    Option         "DPMS"
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GTX 1070"
EndSection

Section "Screen"

# Removed Option "metamodes" "DP-0: nvidia-auto-select +0+0"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "Stereo" "0"
    Option         "nvidiaXineramaInfoOrder" "DFP-3"
    Option         "ConnectedMonitor" "DP-0"
    Option         "metamodes" "DP-0: 4096x2304 +0+0"
    Option         "SLI" "Off"
    Option         "MultiGPU" "Off"
    Option         "BaseMosaic" "off"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection
</code></pre>
In both</em> $HOME/.config/monitors.xml</code> and</em>
/var/lib/gdm3/.config/monitors.xml</code> (my guess is that you'll need to change the
value for <serial></code> here to the serial number for your actual monitor):</p>
<monitors version="2">
  <configuration>
    <logicalmonitor>
      <x>0</x>
      <y>0</y>
      <scale>1</scale>
      <primary>yes</primary>
      <monitor>
        <monitorspec>
          <connector>DP-0</connector>
          <vendor>GSM</vendor>
          <product>LG UltraFine</product>
          <serial>707NTFA2N827</serial>
        </monitorspec>
        <mode>
          <width>4096</width>
          <height>2304</height>
          <rate>59.999275207519531</rate>
        </mode>
      </monitor>
    </logicalmonitor>
  </configuration>
</monitors>
</code></pre>
With those files in place, neither X nor Gnome were relying on autoconfiguration
of the display's settings, and the LG 5k display seems to be working just fine
(although not actually at "5k", but it still looks great.)</p>


Complex Unique Constraints with PostgreSQL Triggers in Ecto
Unknown — Sun, 16 Feb 2020 00:00:00 +0000
Ecto</a> makes it easy to work with typical uniqueness constraints in your database; you just
define your table like this:</p>
defmodule MyApp.Repo.Migrations.CreateFoos do
  use Ecto.Migration

  def change do
    create table(:foos) do
      add :name, :text, null: false
    end

    create unique_index(:foos, :name)
  end
end
</code></pre>
and a module with a changeset validation for the uniqueness constraint</a>,
perhaps like:</p>
defmodule MyApp.Foo do
  use Ecto.Schema

  import Ecto.Changeset

  schema "foos" do
    field :name, :string
  end

  def changeset(%__MODULE__{} = foo, %{} = changes) do
      foo
      |> cast(changes, [:name])
      |> unique_constraint(:name)
  end
end
</code></pre>
Then, when you run:</p>
result = MyApp.Foo.changeset(%MyApp.Foo{}, %{name: "bar"})
         |> MyApp.Repo.insert()
</code></pre>
The Ecto library will attempt to insert your record, and if there is already a record where the
name column is set to "bar", Ecto will see the uniqueness constraint violation error produced by
the database and turn it into a validation error on your changeset, so that it would look
something like:</p>
{:error, %Ecto.Changeset{errors: [name: {"has already been taken", _}]}} = result
</code></pre>
Something More Complex</h3>
I recently needed to enforce a database constraint similar in spirit to a unique index (if a
record were in violation, I wanted the same behavior on the Elixir end of things—the changeset
should report that the value for the field "has already been taken") however the criteria for what
should be considered "unique" was more complex than what a simple unique index in PostgreSQL would
be able to deal with.</p>
Let's pretend we have a project that is managing meeting room reservations. The process for
reserving a meeting room is as follows:</p>

The customer chooses a room and selects the time range for the reservation.</li>
Assuming the room is available at that time, the system places a hold on the room for 24 hours</li>
Within that 24-hour period, the customer pays for the room and completes some contractual
information that must be signed by both the customer and the facility manager.</li>
Once the payment is complete and the contracts are signed, the reservation is confirmed.</li>
</ol>
Here, then, are the business rules for creating a reservation:</p>


A room reservation cannot be made for a given room and time-period if there exists another room
reservation for that same room with an overlapping time-period and the existing reservation is
in a "confirmed" status.</p>
</li>

A room reservation cannot be made for a given room and time-period if there exists another room
reservation for that same room with an overlapping time-period, the existing reservation is in a
"hold" status, and the existing reservation was created within the last 24 hours.</p>
</li>
</ul>
We decide to store the room reservations in a table defined as:</p>
defmodule Meetings.Repo.Migrations.CreateRoomReservations do
  use Ecto.Migration

  def change do
    create table(:room_reservations) do
      add :customer_id, :binary_id, null: false
      add :room_id, :binary_id, null: false
      add :reservation_starts_at, :timestamp, null: false
      add :reservation_ends_at, :timestamp, null: false
      add :status, :text, null: false, default: "hold"
      timestamps()
    end
  end
end
</code></pre>
and ideally, we'd like to be able to model the RoomReservation</code> in Elixir as:</p>
defmodule Meetings.RoomReservation do
  use Ecto.Schema

  import Ecto.Changeset

  schema "room_reservations" do
    field :customer_id, :binary_id
    field :room_id, :binary_id
    field :reservation_starts_at, :utc_datetime
    field :reservation_ends_at, :utc_datetime
    field :status, :string
    timestamps()
  end

  def create(%{} = res_data) do
    %__MODULE__{}
    |> cast(res_data, [:customer_id, :room_id, :reservation_starts_at, :reservation_ends_at])
    |> validate_required([:customer_id, :room_id, :reservation_starts_at, :reservation_ends_at])
    |> put_change(:status, "hold")
    |> unique_constraint(:room_id, message: "has already been reserved")
    |> Meeting.Repo.insert()
  end
end
</code></pre>
with the interesting bit being the |> unique_constraint(:room_id)</code> line. When a customer tries to
reserve a room that is already reserved for the given time period, we want the
Meeting.RoomReservation.create/1</code> function to return with a validation error:</p>
%{:error, %Ecto.Changeset{errors: [room_id: {"has already been reserved", _}]}} =
  Meetings.RoomReservation.create(%{
    customer_id: "0af5716a-c3d2-4d4c-87f5-9fed9b2515d4",
    room_id: "2c0d6242-3585-40cb-be92-a1818c0f4a73",
    reservation_starts_at: DateTime.from_naive!(~N[2020-01-01 8:00:00], "Etc/UTC"),
    reservation_ends_at: DateTime.from_naive!(~N[2020-01-01 17:00:00], "Etc/UTC")
  })
</code></pre>
Clearly, according to the business rules for the system, we can't just put a unique index on the
room_id</code> column. To the best of my knowledge, an exclusion constraint also won't work here,
because of the need to not</em> check against any rows that have a status of "hold" and an
inserted_at</code> timestamp that is more than 24 hours ago relative to the current time. It is</em>
however possible to use a trigger function to enforce the constraint in the database:</p>
defmodule Meetings.Repo.Migrations.CreateRoomReservations do
  use Ecto.Migration

  def change do
    create table(:room_reservations) do
      add :customer_id, :binary_id, null: false
      add :room_id, :binary_id, null: false
      add :reservation_starts_at, :timestamp, null: false
      add :reservation_ends_at, :timestamp, null: false
      add :status, :text, null: false, default: "hold"
      timestamps()
    end

    execute(
      # up
      ~S"""
      CREATE FUNCTION room_reservations_check_room_availability() RETURNS TRIGGER AS
      $$
      BEGIN
      IF EXISTS(
        SELECT 1
        FROM room_reservations rr
        WHERE rr.room_id = NEW.room_id
          AND tsrange(rr.reservation_starts_at, rr.reservation_ends_at, '[]') &&
              tsrange(NEW.reservation_starts_at, NEW.reservation_ends_at, '[]')
          AND (
            rr.status = 'confirmed'
              OR rr.inserted_at > CURRENT_TIMESTAMP - interval '24 hours'
          )
      )
      THEN
        RAISE "room already reserved";
      END IF;
      RETURN NEW;
      END;
      $$ language plpgsql;
      """,

      # down
      "DROP FUNCTION room_reservations_check_room_availability;"
    )

    execute(
      # up
      ~S"""
      CREATE TRIGGER room_reservations_room_availability_check
      BEFORE INSERT ON room_reservations
      FOR EACH ROW
      EXECUTE PROCEDURE room_reservations_check_room_availability();
      """,

      # down
      "DROP TRIGGER room_reservations_room_availability_check ON room_reservations;"
    )
  end
end
</code></pre>
The problem is that instead of that nice validation error on the changeset that we want</em> to get,
we instead end up with an unhandled Postgrex.Error</code> exception. We could, of course, simply rescue
that exception in our Meetings.RoomReservation.create/1</code> function and add the error to the
changeset ourselves, but that starts to look a little ugly:</p>
defmodule Meetings.RoomReservation do
  # ...

  def create(%{} = res_data) do
    changeset =
      %__MODULE__{}
      |> cast(res_data, [:customer_id, :room_id, :reservation_starts_at, :reservation_ends_at])
      |> validate_required([:customer_id, :room_id, :reservation_starts_at, :reservation_ends_at])
      |> put_change(:status, "hold")
    Meeting.Repo.insert(changeset)
  rescue
    error in Postgrex.Error ->
      case error do
        %{postgres: %{message: "room already reserved"}} ->
          changeset
          |> add_error(:room_id, "has already been reserved")
      end
  end
end
</code></pre>
TL;DR - It's All About the Raise</h3>
Knowing that Ecto.Changeset.unique_constraint/3</code> works by intercepting an error raised by the
database, I set out to see if I could implement the complex unique constraint logic in the
database and still be able to use the Ecto.Changeset.unique_constraint/3</code> validation without
needing to modify any Elixir code. Looking at the relevant code in ecto_sql</a>, we
can see that the trick to getting the room_reservations_check_room_availability</code> functionality to
work with that function is to change the PostgreSQL exception to use the correct error code as
well as a constraint name that is linked with the changeset validation. We can redifine the
PostgreSQL function as:</p>
CREATE FUNCTION room_reservations_check_room_availability() RETURNS TRIGGER AS
$$
BEGIN
IF EXISTS(
  SELECT 1
  FROM room_reservations rr
  WHERE rr.room_id = NEW.room_id
    AND tsrange(rr.reservation_starts_at, rr.reservation_ends_at, '[]') &&
        tsrange(NEW.reservation_starts_at, NEW.reservation_ends_at, '[]')
    AND (
      rr.status = 'confirmed'
        OR rr.inserted_at > CURRENT_TIMESTAMP - interval '24 hours'
    )
)
THEN
  RAISE unique_violation
    USING CONSTRAINT = 'room_reservations_room_reserved';
END IF;
RETURN NEW;
END;
$$ language plpgsql;
</code></pre>
and then add the :name</code> option to our unique_constraint</code> in the changeset validation:</p>
defmodule Meetings.RoomReservation do
  #...

  def create(%{} = res_data) do
    %__MODULE__{}
    |> cast(res_data, [:customer_id, :room_id, :reservation_starts_at, :reservation_ends_at])
    |> validate_required([:customer_id, :room_id, :reservation_starts_at, :reservation_ends_at])
    |> put_change(:status, "hold")
    |> unique_constraint(:room_id,
                         message: "has already been reserved",
                         name: "room_reservations_room_reserved")
    |> Meeting.Repo.insert()
  end
end
</code></pre>


Kookaburra 0.24.0 Released - Exorcised ActiveSupport
Unknown — Tue, 15 May 2012 00:00:00 +0000
I just released version 0.24.0 of Kookaburra</a> to
Rubygems.org</a>. While there were no changes to Kookaburra's</em> API
with this release, it is a minor release rather than a patch release,
because I removed ActiveSupport</a> from Kookaburra's dependencies.
Previously, Kookaburra depended on ActiveSupport >= 3.0, and this
prevented it from working smoothly with Rails 2.x applications (at least
in the same Bundler bundle.) Since Kookaburra only used a small fraction
of ActiveSupport, it seemed easiest just to break the dependency, so
that your application can use whatever version of ActiveSupport it
needs.</p>
Because of the fact that ActiveSupport makes a number of modifications
to core Ruby classes, if your application does not otherwise explicitly
require ActiveSupport, some of these core classes may now behave
differently. Specifically, Hash</code> and String</code> core extensions were
being used, as well as ActiveSupport::CoreExt::Module::Delegation</code>.</p>
Also, where Kookaburra::JsonApiDriver</code> used ActiveSupport::JSON</code> for
encoding and decoding of JSON data, it now uses ::JSON</code> as provided by
either</em> the json</a> or the json_pure</a> gems. The tests
on Kookaburra itself pass just by swapping out ActiveSupport JSON
library for the new one, but these tests do not comprehensively test
JSON usage, and there may be differences that impact your application.</p>
Kookaburra declares its dependency on the json_pure</code> gem (a pure-ruby
version) in order to ensure that it works cross-platform. However, both
json</code> and json_pure</code> are written in such a way that, when you require 'json'</code>, it will detect if both libraries are installed and prefer the
natively compiled json</code> gem's version of the library.</p>


tmux and the OSX Clipboard
Unknown — Thu, 12 Apr 2012 00:00:00 +0000
I started using tmux</a> recently after a) I was informed that GNU screen is
basically an outdated POS, and b) an excellent book</a> on the subject
was published. I'm glad to have made the switch, as tmux is a wonderful
improvement over screen. However, on OSX, I found that the pbcopy</code> and
pbpaste</code> commands (among other things) would no longer work from within a tmux
session.</p>
After a bit of searching, I found this post</a> that explains how to make
things right again.</p>
TL;DR:</p>
brew install reattach-to-user-namespace
</code></pre>
# Reattach to user namespace so that clipboard integration with OSX works again
set-option -g default-command "reattach-to-user-namespace -l zsh"
</code></pre>
Obviously, replace zsh</code> above with whatever you use for your shell.</p>


Kookaburra Rewrite for 0.15.1
Unknown — Sat, 10 Mar 2012 00:00:00 +0000
After getting some good feedback on Kookaburra</a> Kookaburra</a> since the original
release announcement as well as using it in a few more projects, [Sam] SLG</a> and
I decided to treat all of the versions prior to 0.15.0 as a spike and rewrite
the framework from the ground up. Although we certainly learned a lot about the
approach with the pre-0.15 versions, the problems with continuing to grow
Kookaburra from that seed became apparent as we tried to use it in more
applications.</p>
Because the original code was extracted from another project, the Kookaburra
framework itself was not well tested. It had been indirectly tested due to its
position within that other project's tests, but as a seperate library it lacked
tests that would help bot document the project and ensure newcomers can work on
it with a good safety net. Additionally, there were a number of design decisions
made in the earlier versions of Kookaburra that were...questionable. Not only
would these decisions probably have been made differently if the development of
the framework itself had been driven with unit tests, these decisions in many
cases made it difficult to go back and add tests after the fact.</p>
Starting with 0.15.1, which I just [released] Gem</a> a few moments ago,
Kookaburra has been rewritten using a proper TDD approach. In some ways, 0.15.1
is possibly less functional than its 0.14.x cousins, but it is almost certainly
easier to understand and contribute to the project from this point on. Please
have a look at the new codebase, try it out in your projects, and send me a pull
request with updates to the library. Also, if you have any problems getting it
running, please don't hesitate to [let me know] GHIssues</a>.</p>


Using Jeweler for Private Gems
Unknown — Wed, 25 Jan 2012 00:00:00 +0000
I really like using [Jeweler] 1</a> to create and manage gems, but its default
behavior is to publish your gem to [rubygems.org] 2</a> whenever you run rake release</code>. This is great for generally useful libraries that you want to
open-source, but not as great when you want to use gems as shared libraries for
internal use only (whether because the code contains business secrets or just
because it's not something that would be useful to the community at large.)</p>
After a bit of poking around, I figured out how to use Jeweler to manage
your versioning, gemspec and git tagging without pushing the result to
rubygems.org when running the release task. It turns out to be both obvious and
trivial. Just add the following line to the end of your gem project's
Rakefile</code>:</p>
Rake::Task[:release].prerequisites.delete('gemcutter:release')
</code></pre>


Acceptance and Integration Testing with Kookaburra
Unknown — Sat, 21 Jan 2012 00:00:00 +0000
UPDATE (2012-01-22):</strong> I realized this morning that the credit I gave to Sam
Livingston-Gray</a> below may not have
adequately shown how instrumental he was in getting this project off the ground;
especially since much of his work was done in the private repository from which
this was extracted. So, thanks, Sam. This might not have gone anywhere if you
hadn't worked to put the idea in practice in our application and helped everyone
on our team learn how to use the approach. I made a few minor changes below to
reflect this a bit better.</em></p>
We've been using Cucumber</a> for acceptance testing at
Renewable Funding</a> since back when it was still part of
the RSpec</a> project (indeed, since before we were even
Renewable Funding). While we've always liked the ability to have plain-language
feature documentation that we could automatically test against, after years of
adding to and maintaining a fairly large set of Cucumber scenarios, the cost of
that maintenance was starting to really slow us down. The test suite began to
grow fragile, and it seemed like every time one of our UX designers changed
anything about the application's interface, the development team would spend a
bunch of time just babysitting Cucumber tests to get them passing again.</p>
Last year, as I was reading Jez Humble's excellent Continuous
Delivery</a> book,
I was inspired when I came across the section titled "The Application Driver
Layer" (p. 198). This section describes an approach to acceptance testing where
the specification and the test implementation are isolated from the details of
the application's user interface by inserting a layer between the two that uses
good old OOP to abstract the user interface components. Martin Fowler describes
it as the [Window Driver] 1</a> pattern on his website.</p>
I started a proof-of-concept implementation of this pattern last summer, then my
coworker, Sam Livingston-Gray</a> and I
started pulling it into a new project at work. After Sam and the rest of the
Renewable Funding team helped improve on my original attempt while putting it to
use for the last six or so months, we extracted a library to make it easier for
other Ruby developers to implement this pattern in their testing. I'm happy to
introduce Kookaburra</a> to the world.</p>


Capybara, Selenium and Firefox 3.5
Unknown — Sat, 30 Apr 2011 00:00:00 +0000
I banged my head against this one while setting up our CI build for a new
project at work and just now figured it out. I added an example integration
spec that just visits the default Rails homepage, clicks the "About your
application's environment" link, and verifies the Rails version. This link
uses an AJAX action to load the environment details, so I marked it as a
JavaScript test, which would cause it to use Capybara's Selenium driver.</p>
The test passed fine on my machine (with Firefox 4 installed), but it failed
consistently on CI, which has Firefox 3.5. It kept failing with the exception
Capybara::TimeoutError: failed to resynchronize, AJAX request timed out</code>. I
didn't dig enough into the guts of Selenium/Firefox to find out exactly what
is going on (and a Google search for that error message turned up nothing that
really explained it) but I did at least find a workable fix. Just add the
following line to spec/support/capybara.rb</code>:</p>
Capybara::Selenium::Driver::DEFAULT_OPTIONS[:resynchronize] = false
</code></pre>


Apprenticeship Program at Renewable Funding - Thoughts?
Unknown — Fri, 04 Mar 2011 00:00:00 +0000
The Renewable Funding</a> technology team is moving into
some new office space in a few months, and now that we'll have our own space,
I'd like to start up a variation on an apprenticeship program at work.  I'm
still in the early stages of designing this, and I want to gather some input
from the community before deciding how we might run the program.</p>


Production Release Workflow with Git
Unknown — Sat, 08 Jan 2011 00:00:00 +0000
After growing the ProjectDX</a> team from three to
eight software developers, our release process was a complete pain, and it
typically took two to three hours to get a good build on the production branch
(and even then some insidious issues would sneak through). By making a few
changes to our development and acceptance process, we were able to turn it
into a five-minute, low-stress job.</p>


What it Really Means to be "Agile
Unknown — Wed, 15 Dec 2010 00:00:00 +0000
Yesterday, Elizabeth Hendrickson posted her Agile Acid
Test</a> in which she asks
three questions to determine whether or not a team is truly "agile". There is
also the Agile Manifesto</a> which describes the
values that an agile team should adhere to. While there is nothing that I
disagree with in either Elizabeth's post or the Agile Manifesto, there
are two simpler questions you can ask that get to the heart of whether or
not your team is agile: Can you react immediately and without panic when
external constraints on your project are changed</em>, and does your team regularly
and frequently review its processes to ensure the answer to the previous
question is always "yes"?</em></p>


Retrospective Facilitation
Unknown — Tue, 13 Jan 2009 00:00:00 +0000
Sprint 1 (11/03)</th> Sprint 2 (11/24)</th> Alpha (12/15)</th> Beta (12/29)</th></tr></thead>

11/03</td> 11/24</td> 12/15</td> 12/29</td></tr>
</tbody></table>
I facilitated my second release retrospective with the ProjectDX team yesterday. The first one, back in October, went reasonably well considering I was asked to facilitate at the start of the retrospective and had no time to prepare. However, yesterday's retrospective went even better since I knew in advance that I would be facilitating.</p>
The activities we used during the retrospective primarily came from Diana Larsen and Esther Derby's book, Agile Retrospectives. We began with the "ESVP" (Explorer, Shopper, Vacationer, Prisoner) activity to gauge the group's interest level concerning the work we were doing in the retrospective. Almost everyone in the group identified as an Explorer through an anonymous vote. With this group, I generally trust the outcome, although I did wonder if anyone might have provided the answer they thought they were "supposed" to give.</p>
Next, I asked the team to construct a timeline of events from the past release. Before the retrospective began, I drew the timeline on our whiteboard and divided it into sections for each iteration (our cycle consists of two 3-week sprints followed by a 2-week internal Alpha testing period and a 2-week customer Beta testing period). The result looked something like:</p>
During the retrospective, I asked everyone to take some time to think about any events during that time period that were meaningful to them in any way, write the event on a sticky note, and then place the note on the timeline in approximately the right spot. We spent about 45 minutes generating events, during which time we were free to look back at calendars and email, as well as the commit logs from our SCM. I set a 45-minute time box and mentioned that it was fine for people to take a break if they felt they couldn't remember any more events, asking everyone to simply be back on time for the next step.</p>
Instead of specifying that people work in pairs, I chose to let the team self-organize. It was interesting to see how, at first, everyone seemed to work on their own, but as the more obvious events were posted to the board, people started working in groups to come up with more data. At the end of the allotted time, we had a whiteboard full of events.</p>
The area below the timeline was intended for a graph of energy/emotion levels, which I'll discuss in a moment, but JD Huntington had a great idea to also add a rough bar graph of our commit volume, as reported by GitHub's activity graphs, to that area.</p>
After everyone had a last opportunity to look at the board and add any last-minute stickies, I asked everyone to take a turn at the board and use markers to place a blue dot next to any event which they felt positive about and a red dot next to any event that they felt negative about. Then, I asked them to think about their positive and negative energy/emotion levels throughout the release and draw a line graph in the bottom section to signify their ups and downs throughout the release cycle. At this point, we looked at each iteration in the cycle and I asked the team to make observations about the data. Using bullet lists at the bottom of the white board, we captured the observations as further data points for analysis.</p>
After a break for lunch, we used the "Patterns & Shifts" activity to generate insights about the data on the time line. We gathered around the white board where I asked each person to mark on the time line any point at which they felt there was a shift or transition of some sort and to draw lines between any events, graph points and observations that they felt were somehow related.</p>
After no one was able to see any more connections, I asked the team to look for any patterns among the connections and the shifts. The first thing we noticed was that we felt like the real shift between iterations was constantly happening about 3 days after the actual time box ended. Rather than get into a long discussion about it when it was noticed, I asked the team to simply keep it in mind as a possible concern during the next phase of the retrospective.</p>
The next observation was that we had a number of connections with long lines spanning two or more iterations. I asked everyone to focus on these connections and look for those where we may have noticed an issue early on but it wasn't addressed until much later. In some cases it turned out that while that was the issue, the length of the line just signified that either the work took that long or there was a conscious decision not to address the issue right away.</p>
Reflecting on the other cases led to an interesting discovery, however. Chris noticed that where the lines crossed the bounds of the iterations it was likely signifying a parallel cycle which we were attempting to force into our release cycle: specifically, we have both an explicit product release cycle and an inexplicit customer deployment cycle occurring at the same time.</p>
After we were finished recognizing patterns in the data, it was time to discuss these patterns (and anything else on our minds) and come up with a few action items for the next release cycle. Here I ran the team through the "Circle of Questions" activity. In this activity, the group sits in a circle, and each person takes turns asking a question to the person on their immediate left. The question can be about anything they like (barring anything offensive or attacking), but it's helpful to focus on the insights gained during the previous stage of the retrospective. The person to the left answers the question to the best of their ability, and then they ask the person to their left any other question (or the same question if they feel they'd like a better answer). This continues until the alloted time is up or you have gone around the entire circle twice, whichever comes last. Make sure you go around the complete circle: if some people in the group get more turns to ask or answer a question than others, it can send the wrong message.</p>
The thing that I really like about the Circle of Questions activity is that when you have a mixed group of people—some of whom tend to dominate the conversation while others tend to stay quiet—it gives everyone a chance to ask their questions and have their opinions heard without feeling like the most boisterous people have the only valuable input. We certainly have a mix like that in our case, and this activity worked wonderfully.</p>
In the end, we came away with a number of things to change for the next release cycle. It's interesting to note that none of our action items were directly related to the insights generated from the time line. I think the insights are still valuable (and are contained in the notes which we post to our internal wiki), so we may still come back to them in the near future; we were running over on time and had to wrap up even though the discussion could have continued longer.</p>
Before we held this retrospective, I think some of the team members felt that we would not gain much from doing a full-day retrospective this time around. We had made good progress on our action items from the previous retrospective, and the general feeling was that things were going basically well. What could we possibly need to change?</p>
People, please don't hold retrospectives only when your team feels like there's a problem that needs to be dealt with. If you hold retrospectives on a regular basis, whether you feel like you "need" to or not, you will uncover issues before the become problems. In our case, we managed to uncover a number of issues during our retrospective that could easily have grown into much larger problems if we didn't bother to think about them until the effect was obvious.</p>
If you do have obvious issues, then you might choose a different set of activities than what we did for this retrospective. The time line activity is great for discovering potential improvements even when everything seems to be going well, so I suggest giving it a try the next time your team is tempted to skip a retrospective because no one thinks there's any huge problems.</p>