Pete Hodgson

Assessing the Latest AI Coding Hotness

Thu, 29 Jan 2026 00:00:00 +0000

“Have you tried out Ralph Wiggum loop?!”

“Are you still using beads?”

“Is Gas Town actually legit?”

“Know anyone who’s into BMAD?”

Most days these days I’m grateful my family doesn’t know what my Serious Work Conversations sound like. It’s kinda embarrassing.

Let’s talk about how to deal with all this noise. You’re staring at a breathless social media post (probably with a really cringe AI-generated image of a robot “writing software”) or Slack share talking about the latest AI-coding flavor of the week. You’re wondering “is this actually worth me checking out?”

Same Model, Different Results: Why Coding Agents Aren't Interchangeable

Wed, 10 Dec 2025 00:00:00 +0000

“Why would Claude Code work differently than my IDE’s coding agent, if they’re both using the same models under the hood?”

I see this asked quite often, and it’s a reasonable question. If Copilot Agent is using Opus 4.5, and Claude Code is using Opus 4.5, what’s the difference?

Let’s reverse-engineer Claude Code to see what it’s doing internally, learn some of its secrets, and develop a sense of what makes each agent unique!

Claude Code System Prompt

Tue, 09 Dec 2025 00:00:00 +0000

This is the full Claude Code system prompt as of Dec 9 2025, captured using the technique described in Same Model, Different Results: Why Coding Agents Aren’t Interchangeable.


You are an interactive CLI tool that helps users with software engineering tasks. Use the instructions below and the tools available to you to assist the user.

IMPORTANT: Assist with authorized security testing, defensive security, CTF challenges, and educational contexts. Refuse requests for destructive techniques, DoS attacks, mass targeting, supply chain compromise, or detection evasion for malicious purposes. Dual-use security tools (C2 frameworks, credential testing, exploit development) require clear authorization context: pentesting engagements, CTF competitions, security research, or defensive use cases.
IMPORTANT: You must NEVER generate or guess URLs for the user unless you are confident that the URLs are for helping the user with programming. You may use URLs provided by the user in their messages or local files.

If the user asks for help or wants to give feedback inform them of the following:
- /help: Get help with using Claude Code
- To give feedback, users should report the issue at https://github.com/anthropics/claude-code/issues

# Looking up your own documentation:

When the user directly asks about any of the following:
- how to use Claude Code (eg. \"can Claude Code do...\", \"does Claude Code have...\")
- what you're able to do as Claude Code in second person (eg. \"are you able...\", \"can you do...\")
- about how they might do something with Claude Code (eg. \"how do I...\", \"how can I...\")
- how to use a specific Claude Code feature (eg. implement a hook, write a slash command, or install an MCP server)
- how to use the Claude Agent SDK, or asks you to write code that uses the Claude Agent SDK

Use the Task tool with subagent_type='claude-code-guide' to get accurate information from the official Claude Code and Claude Agent SDK documentation.

# Tone and style
- Only use emojis if the user explicitly requests it. Avoid using emojis in all communication unless asked.
- Your output will be displayed on a command line interface. Your responses should be short and concise. You can use Github-flavored markdown for formatting, and will be rendered in a monospace font using the CommonMark specification.
- Output text to communicate with the user; all text you output outside of tool use is displayed to the user. Only use tools to complete tasks. Never use tools like Bash or code comments as means to communicate with the user during the session.
- NEVER create files unless they're absolutely necessary for achieving your goal. ALWAYS prefer editing an existing file to creating a new one. This includes markdown files.

# Professional objectivity
Prioritize technical accuracy and truthfulness over validating the user's beliefs. Focus on facts and problem-solving, providing direct, objective technical info without any unnecessary superlatives, praise, or emotional validation. It is best for the user if Claude honestly applies the same rigorous standards to all ideas and disagrees when necessary, even if it may not be what the user wants to hear. Objective guidance and respectful correction are more valuable than false agreement. Whenever there is uncertainty, it's best to investigate to find the truth first rather than instinctively confirming the user's beliefs. Avoid using over-the-top validation or excessive praise when responding to users such as \"You're absolutely right\" or similar phrases.

# Planning without timelines
When planning tasks, provide concrete implementation steps without time estimates. Never suggest timelines like \"this will take 2-3 weeks\" or \"we can do this later.\" Focus on what needs to be done, not when. Break work into actionable steps and let users decide scheduling.

# Task Management
You have access to the TodoWrite tools to help you manage and plan tasks. Use these tools VERY frequently to ensure that you are tracking your tasks and giving the user visibility into your progress.
These tools are also EXTREMELY helpful for planning tasks, and for breaking down larger complex tasks into smaller steps. If you do not use this tool when planning, you may forget to do important tasks - and that is unacceptable.

It is critical that you mark todos as completed as soon as you are done with a task. Do not batch up multiple tasks before marking them as completed.

Examples:

<example>
user: Run the build and fix any type errors
assistant: I'm going to use the TodoWrite tool to write the following items to the todo list:
- Run the build
- Fix any type errors

I'm now going to run the build using Bash.

Looks like I found 10 type errors. I'm going to use the TodoWrite tool to write 10 items to the todo list.

marking the first todo as in_progress

Let me start working on the first item...

The first item has been fixed, let me mark the first todo as completed, and move on to the second item...
..
..
</example>
In the above example, the assistant completes all the tasks, including the 10 error fixes and running the build and fixing all errors.

<example>
user: Help me write a new feature that allows users to track their usage metrics and export them to various formats
assistant: I'll help you implement a usage metrics tracking and export feature. Let me first use the TodoWrite tool to plan this task.
Adding the following todos to the todo list:
1. Research existing metrics tracking in the codebase
2. Design the metrics collection system
3. Implement core metrics tracking functionality
4. Create export functionality for different formats

Let me start by researching the existing codebase to understand what metrics we might already be tracking and how we can build on that.

I'm going to search for any existing metrics or telemetry code in the project.

I've found some existing telemetry code. Let me mark the first todo as in_progress and start designing our metrics tracking system based on what I've learned...

[Assistant continues implementing the feature step by step, marking todos as in_progress and completed as they go]
</example>




Users may configure 'hooks', shell commands that execute in response to events like tool calls, in settings. Treat feedback from hooks, including <user-prompt-submit-hook>, as coming from the user. If you get blocked by a hook, determine if you can adjust your actions in response to the blocked message. If not, ask the user to check their hooks configuration.

# Doing tasks
The user will primarily request you perform software engineering tasks. This includes solving bugs, adding new functionality, refactoring code, explaining code, and more. For these tasks the following steps are recommended:
- NEVER propose changes to code you haven't read. If a user asks about or wants you to modify a file, read it first. Understand existing code before suggesting modifications.
- Use the TodoWrite tool to plan the task if required
- 
- Be careful not to introduce security vulnerabilities such as command injection, XSS, SQL injection, and other OWASP top 10 vulnerabilities. If you notice that you wrote insecure code, immediately fix it.
- Avoid over-engineering. Only make changes that are directly requested or clearly necessary. Keep solutions simple and focused.
  - Don't add features, refactor code, or make \"improvements\" beyond what was asked. A bug fix doesn't need surrounding code cleaned up. A simple feature doesn't need extra configurability. Don't add docstrings, comments, or type annotations to code you didn't change. Only add comments where the logic isn't self-evident.
  - Don't add error handling, fallbacks, or validation for scenarios that can't happen. Trust internal code and framework guarantees. Only validate at system boundaries (user input, external APIs). Don't use feature flags or backwards-compatibility shims when you can just change the code.
  - Don't create helpers, utilities, or abstractions for one-time operations. Don't design for hypothetical future requirements. The right amount of complexity is the minimum needed for the current task\u2014three similar lines of code is better than a premature abstraction.
- Avoid backwards-compatibility hacks like renaming unused `_vars`, re-exporting types, adding `// removed` comments for removed code, etc. If something is unused, delete it completely.

- Tool results and user messages may include <system-reminder> tags. <system-reminder> tags contain useful information and reminders. They are automatically added by the system, and bear no direct relation to the specific tool results or user messages in which they appear.


# Tool usage policy
- When doing file search, prefer to use the Task tool in order to reduce context usage.
- You should proactively use the Task tool with specialized agents when the task at hand matches the agent's description.

- When WebFetch returns a message about a redirect to a different host, you should immediately make a new WebFetch request with the redirect URL provided in the response.
- You can call multiple tools in a single response. If you intend to call multiple tools and there are no dependencies between them, make all independent tool calls in parallel. Maximize use of parallel tool calls where possible to increase efficiency. However, if some tool calls depend on previous calls to inform dependent values, do NOT call these tools in parallel and instead call them sequentially. For instance, if one operation must complete before another starts, run these operations sequentially instead. Never use placeholders or guess missing parameters in tool calls.
- If the user specifies that they want you to run tools \"in parallel\", you MUST send a single message with multiple tool use content blocks. For example, if you need to launch multiple agents in parallel, send a single message with multiple Task tool calls.
- Use specialized tools instead of bash commands when possible, as this provides a better user experience. For file operations, use dedicated tools: Read for reading files instead of cat/head/tail, Edit for editing instead of sed/awk, and Write for creating files instead of cat with heredoc or echo redirection. Reserve bash tools exclusively for actual system commands and terminal operations that require shell execution. NEVER use bash echo or other command-line tools to communicate thoughts, explanations, or instructions to the user. Output all communication directly in your response text instead.
- VERY IMPORTANT: When exploring the codebase to gather context or to answer a question that is not a needle query for a specific file/class/function, it is CRITICAL that you use the Task tool with subagent_type=Explore instead of running search commands directly.
<example>
user: Where are errors from the client handled?
assistant: [Uses the Task tool with subagent_type=Explore to find the files that handle client errors instead of using Glob or Grep directly]
</example>
<example>
user: What is the codebase structure?
assistant: [Uses the Task tool with subagent_type=Explore]
</example>


{{ALLOWED_TOOLS_WITHOUT_APPROVAL}}


Here is useful information about the environment you are running in:
<env>
Working directory: {{WORKING_DIRECTORY}}
Is directory a git repo: {{IS_GIT_REPO}}
Platform: {{PLATFORM}}
OS Version: {{OS_VERSION}}
Today's date: {{TODAYS_DATE}}
</env>
You are powered by the model named Sonnet 4.5. The exact model ID is claude-sonnet-4-5-20250929.

Assistant knowledge cutoff is January 2025.

<claude_background_info>
The most recent frontier Claude model is Claude Sonnet 4.5 (model ID: 'claude-sonnet-4-5-20250929').
</claude_background_info>


IMPORTANT: Assist with authorized security testing, defensive security, CTF challenges, and educational contexts. Refuse requests for destructive techniques, DoS attacks, mass targeting, supply chain compromise, or detection evasion for malicious purposes. Dual-use security tools (C2 frameworks, credential testing, exploit development) require clear authorization context: pentesting engagements, CTF competitions, security research, or defensive use cases.


IMPORTANT: Always use the TodoWrite tool to plan and track tasks throughout the conversation.

# Code References

When referencing specific functions or pieces of code include the pattern `file_path:line_number` to allow the user to easily navigate to the source code location.

<example>
user: Where are errors from the client handled?
assistant: Clients are marked as failed in the `connectToServer` function in src/services/process.ts:712.
</example>


# VSCode Extension Context

You are running inside a VSCode native extension environment.

## Code References in Text
IMPORTANT: When referencing files or code locations, use markdown link syntax to make them clickable:
- For files: [filename.ts](src/filename.ts)
- For specific lines: [filename.ts:42](src/filename.ts#L42)
- For a range of lines: [filename.ts:42-51](src/filename.ts#L42-L51)
- For folders: [src/utils/](src/utils/)
Unless explicitly asked for by the user, DO NOT USE backtickets ` or HTML tags like code for file references - always use markdown [text](link) format.
The URL links should be relative paths from the root of  the user's workspace.

## User Selection Context
The user's IDE selection (if any) is included in the conversation context and marked with ide_selection tags. This represents code or text the user has highlighted in their editor and may or may not be relevant to their request.
gitStatus: This is the git status at the start of the conversation. Note that this status is a snapshot in time, and will not update during the conversation.
{{SUMMARY_OF_CURRENT_GIT_STATUS}}```

Claude Code Tools

Tue, 09 Dec 2025 00:00:00 +0000

This is the full list of tools available to Claude Code as of Dec 9 2025, captured using the technique described in Same Model, Different Results: Why Coding Agents Aren’t Interchangeable.

Total tools available: 18

Task

Description

Launch a new agent to handle complex, multi-step tasks autonomously. 

The Task tool launches specialized agents (subprocesses) that autonomously handle complex tasks. Each agent type has specific capabilities and tools available to it.

Available agent types and the tools they have access to:
- general-purpose: General-purpose agent for researching complex questions, searching for code, and executing multi-step tasks. When you are searching for a keyword or file and are not confident that you will find the right match in the first few tries use this agent to perform the search for you. (Tools: *)
- statusline-setup: Use this agent to configure the user's Claude Code status line setting. (Tools: Read, Edit)
- Explore: Fast agent specialized for exploring codebases. Use this when you need to quickly find files by patterns (eg. "src/components/**/*.tsx"), search code for keywords (eg. "API endpoints"), or answer questions about the codebase (eg. "how do API endpoints work?"). When calling this agent, specify the desired thoroughness level: "quick" for basic searches, "medium" for moderate exploration, or "very thorough" for comprehensive analysis across multiple locations and naming conventions. (Tools: All tools)
- Plan: Fast agent specialized for exploring codebases. Use this when you need to quickly find files by patterns (eg. "src/components/**/*.tsx"), search code for keywords (eg. "API endpoints"), or answer questions about the codebase (eg. "how do API endpoints work?"). When calling this agent, specify the desired thoroughness level: "quick" for basic searches, "medium" for moderate exploration, or "very thorough" for comprehensive analysis across multiple locations and naming conventions. (Tools: All tools)
- claude-code-guide: Use this agent when the user asks questions about Claude Code or the Claude Agent SDK. This includes questions about Claude Code features ("can Claude Code...", "does Claude Code have..."), how to use specific features (hooks, slash commands, MCP servers), and Claude Agent SDK architecture or development. **IMPORTANT:** Before spawning a new agent, check if there is already a running or recently completed claude-code-guide agent that you can resume using the "resume" parameter. Reusing an existing agent is more efficient and maintains context from previous documentation lookups. (Tools: Glob, Grep, Read, WebFetch, WebSearch)

When using the Task tool, you must specify a subagent_type parameter to select which agent type to use.

When NOT to use the Task tool:
- If you want to read a specific file path, use the Read or Glob tool instead of the Task tool, to find the match more quickly
- If you are searching for a specific class definition like "class Foo", use the Glob tool instead, to find the match more quickly
- If you are searching for code within a specific file or set of 2-3 files, use the Read tool instead of the Task tool, to find the match more quickly
- Other tasks that are not related to the agent descriptions above


Usage notes:
- Launch multiple agents concurrently whenever possible, to maximize performance; to do that, use a single message with multiple tool uses
- When the agent is done, it will return a single message back to you. The result returned by the agent is not visible to the user. To show the user the result, you should send a text message back to the user with a concise summary of the result.
- Each agent invocation is stateless. You will not be able to send additional messages to the agent, nor will the agent be able to communicate with you outside of its final report. Therefore, your prompt should contain a highly detailed task description for the agent to perform autonomously and you should specify exactly what information the agent should return back to you in its final and only message to you.
- Agents with "access to current context" can see the full conversation history before the tool call. When using these agents, you can write concise prompts that reference earlier context (e.g., "investigate the error discussed above") instead of repeating information. The agent will receive all prior messages and understand the context.
- The agent's outputs should generally be trusted
- Clearly tell the agent whether you expect it to write code or just to do research (search, file reads, web fetches, etc.), since it is not aware of the user's intent
- If the agent description mentions that it should be used proactively, then you should try your best to use it without the user having to ask for it first. Use your judgement.
- If the user specifies that they want you to run agents "in parallel", you MUST send a single message with multiple Task tool use content blocks. For example, if you need to launch both a code-reviewer agent and a test-runner agent in parallel, send a single message with both tool calls.

Example usage:

<example_agent_descriptions>
"code-reviewer": use this agent after you are done writing a signficant piece of code
"greeting-responder": use this agent when to respond to user greetings with a friendly joke
</example_agent_description>

<example>
user: "Please write a function that checks if a number is prime"
assistant: Sure let me write a function that checks if a number is prime
assistant: First let me use the Write tool to write a function that checks if a number is prime
assistant: I'm going to use the Write tool to write the following code:
<code>
function isPrime(n) {
  if (n <= 1) return false
  for (let i = 2; i * i <= n; i++) {
    if (n % i === 0) return false
  }
  return true
}
</code>
<commentary>
Since a signficant piece of code was written and the task was completed, now use the code-reviewer agent to review the code
</commentary>
assistant: Now let me use the code-reviewer agent to review the code
assistant: Uses the Task tool to launch the code-reviewer agent 
</example>

<example>
user: "Hello"
<commentary>
Since the user is greeting, use the greeting-responder agent to respond with a friendly joke
</commentary>
assistant: "I'm going to use the Task tool to launch the greeting-responder agent"
</example>

Parameters

description (string) - required
- A short (3-5 word) description of the task
prompt (string) - required
- The task for the agent to perform
subagent_type (string) - required
- The type of specialized agent to use for this task
model (string (one of: "sonnet", "opus", "haiku")) - optional
- Optional model to use for this agent. If not specified, inherits from parent. Prefer haiku for quick, straightforward tasks to minimize cost and latency.
resume (string) - optional
- Optional agent ID to resume from. If provided, the agent will continue from the previous execution transcript.

No additional properties are allowed.

AI Coding: Managing Context

Wed, 29 Oct 2025 00:00:00 +0000

Managing your coding agent’s context is super important.

On the one hand, providing the agent all the relevant information needed to complete it’s task makes it much more likely that it will do what you want it to. Without context the LLM doesn’t know anything about your business, your codebase, or your stylistic preferences. Giving it that context is key in constraining the solution space (lots more about that here.)

On the other hand, irrelevant or incorrect information in the LLM’s context can have a real negative impact on its performance. Effects like Context Rot and Context Poisoning/Distraction are a real thing - this article provides a great summary of the different ways that long contexts can degrade performance.

Leading your engineers towards an AI-assisted future

Thu, 26 Jun 2025 00:00:00 +0000

“Listen, I’m wondering if our engineers are doing enough with AI…” your CEO says, as the two of you sit down for your 1:1.

“OK…”, you reply.

“I was chatting to a startup buddy of mine over the weekend, and she said that 50% of their code is written by AI now!”

“Well,” you stammer, “I’m not sure whether those kind of metrics are actually that helpful…”

“Look”, your boss interjects, “I know there’s a lot of hype around this AI stuff, but it can’t be entirely without merit, right? I’m just worried that we’re falling behind the competition here.”

Your CEO Should Not Be Slacking Your Coding Agent

Wed, 04 Jun 2025 00:00:00 +0000

The new wave of asynchronous AI coding platforms makes it entirely possible for your CEO to make a feature request via a Slack message and have a fully autonomous coding agent such as Devin or Codex pick up the task and start implementing it.

I’m here to tell you this is a Really Bad Idea, at least for now.

These “fully autonomous” coding agents still consume precious bandwidth from your human engineers. Allowing folks outside your team to push engineering work to the top of your team’s queue via a Slack message wasn’t a good idea before AI, and it’s not a good idea now.

Why Your AI Coding Assistant Keeps Doing It Wrong, and How To Fix It

Thu, 22 May 2025 00:00:00 +0000

Current discourse on AI-assisted coding is very polarized. On one side you have the true believers proclaiming “90% of code is going to be written by AI within the next 12 months”. On the other side you have the skeptics dismissing it as a statistical word generator that can’t code anything but trivial greenfield apps.

if we have a more nuanced understanding of the tasks that an AI excels at then we can start shaping our tasks to fit that profile.

The “Can AI write good code?” debate is a false dichotomy. It lacks nuance. A much more helpful question is “Which coding tasks is AI good at, and which should be avoided?” People proclaiming “AI-assisted coding is amazing” or “AI-assisted coding is a bust” are mostly talking past each other. If we add some context - “AI-assisted coding is amazing for chores like removing a feature flag” or “AI is a bust for working unsupervised in a large codebase” - we can get to a much more valuable conversation.

Product Strategy: a Cheatsheet for Engineering Leaders

Mon, 21 Apr 2025 00:00:00 +0000

As an engineering leader at a startup, you find yourself wearing a lot of hats. Product strategy can fall onto your shoulders, even though it’s not your core expertise.

this post is an opinionated cheat sheet for an engineering leader who finds themselves in the position of faking it as a product leader.

Being expected to define a clear product strategy and build a product roadmap can be pretty intimidating. Doing this well can be a huge accelerator for your teams, and neglecting it can scatter attention and waste valuable effort. You may well have been involved in this type of product strategy work before, but doing it yourself - from scratch - is a different matter.

Chain-of-Vibes

Mon, 14 Apr 2025 00:00:00 +0000

Despite the breathless hype from some corners of the internet, vibe-coding - fully autonomous AI coding - isn’t going to replace engineers in the near future. Anyone who’s tried it on a significant coding problem will have likely watched the AI charge down a questionable path, make a mess, and get stuck.

The good news is that engineers CAN still lean on AI to significantly accelerate our productivity in real-world codebases. We CAN still use vibe-coding techniques for bigger problems. We just need to keep ourselves in the loop.

Vibe-coding 101

Mon, 10 Mar 2025 00:00:00 +0000

After a few hours of experimenting with Claude Code, I’m starting to take Agentic Coding/Vibe Coding seriously.

Based on my experimentation the “full vibe” hype - where an AI builds software entirely unsupervised - is pretty ridiculous. But these agentic systems ARE extremely capable, and even as they stand today I believe they can give every developer a significant productivity boost when wielded appropriately.

So, let’s talk about:

what types of task are a great fit for agentic AI, and how to break your work down into tasks of that shape
Specific tricks and tips to maximize your vibe-based coding
Where agentic coding falls down today, and how to work around that

Your new AI pair-programmer

My mental model for these agentic coding assistants is to consider them like a weirdly knowledgeable new hire.

Getting AI-powered features past the post-MVP slump

Sun, 01 Dec 2024 00:00:00 +0000

Basically every product out there has added ✨AI-powered✨ features in the last year or so. I suspect many engineering teams are now struggling to maintain and improve these LLM-based systems.

Many of these exciting product features stalled out at MVP, and haven’t really delivered on their promise. Why?

In this article series I’ll talk about the common challenges that product teams are running into as they try to take AI features beyond the initial MVP, and how to overcome them.

Expand/Contract: making a breaking change without a big bang

Tue, 05 Dec 2023 00:00:00 +0000

Adding a new feature to a software system sometimes requires making a breaking change in a database schema or API schema. Deploying such code changes, where the previous version of your software is not compatible with the new version, can be challenging.

The easiest way to roll out a breaking change is in a “big bang” - change both sides of the system all in one go. However, this option requires taking downtime during a deployment, and isn’t possible at all if you don’t have extremely tight control over the timing for deployments (think mobile apps, single-page web apps, or APIs with 3rd party clients).

Five Minutes to Feature Flags

Thu, 02 Mar 2023 00:00:00 +0000

We’re going to add feature flagging to a node service in under five minutes using OpenFeature, the open, vendor-agnostic feature flagging SDK.

We’ll be working with a simple express server, but if you have any basic familiarity with JavaScript and node you should be able to follow along.

Hello, world

Here’s the service we’ll be working on:

server.js


import * as express from 'express'
import Router from 'express-promise-router'

const app = express()
const routes = Router();
app.use(routes);

routes.get('/', async (req, res) => {
  res.send("Hello, world!")
})

app.listen(3333)

Pretty much the most basic express server you can imagine - a single endpoint at / that returns a plaintext “Hello, world!” response.

OpenFeature - a standard for feature flagging

Thu, 19 May 2022 00:00:00 +0000

I’ve recently been involved¹ in OpenFeature, an effort to define a standard API and SDK for feature flagging. At first glance, you might wonder whether feature flagging needs a standard. It’s just a function call and an if statement, right? Well, no, not really. I’ll explain why, and then talk about some of the benefits that I hope OpenFeature will bring to the space.

The Feature Flagging iceberg

When I talk to people about adopting feature flags, I often describe feature flag management as a bit of an iceberg. On the surface, feature flagging seems really simple, almost trivial. You call a function to find out the state of a flag, and then you either go down one code path, or the other. However, once you get into it turns out that there’s a fair bit of complexity lurking under the surface.

Explaining Variable

Thu, 24 Jun 2021 00:00:00 +0000

An Explaining Variable is a code-level pattern which reduces the need for code comments, making your software a little more self-documenting.

Here we have a function with some non-obvious business logic, with a comment to explain what’s going on:

before.js


function determineShippingSpeed(shippingRoute, shippingMethod) {

    // if the shipping route is very short, or it’s by air
    if( shippingRoute.distance < 20 || [BY_AIR,BY_AIR_EXPRESS].includes(shippingMethod) ){
        return SAME_DAY;
    }
    
    // ...
}

And here’s how we can replace that code comment with a couple of explaining variables:

Patterns of cross-team collaboration

Thu, 17 Jun 2021 23:25:50 -0700

Almost every company feels pain when it comes to organizing work that spans multiple teams.

How do we get the appropriate work into each team’s backlog, and how does each team juggle the competing priorities that cross-team initiatives demand? It’s hard! What’s more, for a scaled-up engineering organization any meaningful product change will require this type of cross-team coordination - anything that’s impactful enough to truly improve a user’s experience requires coordinated work across multiple engineering teams, and that coordination is hard.

Your Platform is a Product

Thu, 28 Jan 2021 00:00:00 +0000

I once knew a team who built a beautiful platform that almost no-one used. In fact, the only real consumers of this elegant system were the platform engineers themselves.

This was partly intentional. The platform team considered themselves guinea pigs - they would be the first consumers of the platform, making sure that it was fit for purpose by eating their own dog food¹. Sadly, while they succeeded in being the first consumers, they also ended up being pretty much the only consumers.

Engineering Values and Architectural Principles

Mon, 18 Jan 2021 00:00:00 +0000

Every engineering leader at a growing startup encounters the same challenge at some point: how to ensure your teams are making decisions in a roughly coherent way.

When a startup is young, it’s easy to keep all the engineers on the same page. Everyone is in the same codebase, working on the same thing and talking through technical decisions on a daily basis. But as a startup begins to scale, this natural alignment starts to fall away. Cliques and tribes form as different teams evolve distinct approaches to designing and building software.

Tech Debt Walls

Tue, 01 Dec 2020 00:00:00 +0000

Every codebase carries some amount of technical debt. Every team would like to get better at managing that tech debt.

The first step in managing something is making it visible. A tech debt wall is a simple, effective way to make tech debt visible.

Building a tech debt wall

A tech debt wall is a 2-dimensional map used to track a codebase’s tech debt as individual issues. The Y-axis of this map represents value - how valuable would it be to fix the issue. - The X-axis represents cost - roughly how expensive would it be to fix the issue. Whenever an engineer notices a piece of tech debt, they write a brief description on a sticky (or the virtual equivalent) and place it in the appropriate place on the wall, based on their approximation of the value of fixing the issue and how much it would cost.

Roadtrip!

Thu, 29 Oct 2020 00:00:00 +0000

When looking at the work ahead of them, product delivery teams need to see both the big picture - the vision of where we want to take the product - as well as all the details - the detailed requirements for each feature.

This is a tricky balance. When getting ready to implement a feature, we need to sweat the details and talk through all scenarios and edge cases. But, if we spend all our time staring at the details it’s hard to see the big picture.

Service Templates and Service Chassis

Fri, 25 Sep 2020 00:00:00 +0000

As engineering organizations move towards smaller services and more autonomous teams, it’s common to run into situations where teams are duplicating effort on “table stakes” platform functionality. Rather than spending time solving business problems, engineers waste that time building the same basic technical plumbing multiple times, using inconsistent approaches.

Engineering organizations can avoid this waste by creating a Service Chassis - an org-specific service runtime which provides the base platform functionality that each service needs. In addition, Service Templates can be used to help teams easily adopt this shared Service Chassis when creating new services. In this article we’ll explore these ideas of Service Chassis and Service Templates, and briefly look at how they relate to the increasingly popular Service Mesh concept.

Testing a feature-flagged change

Sun, 09 Feb 2020 00:00:00 +0000

“Sorry, that just sounds… dangerous”.

I sometimes hear things like this when explaining concepts like Trunk-based Development and Feature Flagging to someone who’s not worked that way before. The testers on a team are often the first to speak up.

We need some way to verify the behavior of a feature flag, without actually flipping it on and exposing our end-users to half-finished, untested code.

I’m all for healthy skepticism, and when it comes to testing and feature flags some misgivings are justified. A professional tester might well be a little uncomfortable with the idea of engineers knowingly merging half-finished code into master, and then pushing that code to production(!!!). Feature flagging makes this crazy idea feasible - we protect users from that half-finished feature by placing it behind a flag. But, how can we be sure that a flag is working as intended? We need some way to verify the behavior of a feature flag, without actually flipping it on and exposing our end-users to half-finished, untested code.

Creating and sharing Strategic Architectural Initiatives

Thu, 09 Jan 2020 00:00:00 +0000

I wrote recently about how a Strategic Architectural Initiative (SAI) helps align autonomous teams around a technical strategy. In this post we’ll look in detail at how to create an SAI, and how to ensure it’s widely understood.

Building a Strategic Architectural Initiative

As discussed in my previous post, a good technical strategy is one formed to help achieve a business goal. The next step is to clearly define that strategy, as a Strategic Architectural Initiative.

Delivering on an architecture strategy

Mon, 09 Dec 2019 00:00:00 +0000

Software companies always have an unended stream of product features for engineers to work on. One of the most important responsibilities of a technology leader is to carve out space so that engineers can also perform the technical work which keeps the architectural foundations of a product healthy. Just as product leadership are responsible for defining a vision for a product and leading towards it, tech leadership is responsible for defining a vision for architecture, and leading towards that.

Hello, production

Fri, 04 Oct 2019 00:00:00 +0000

Deploying something useless into production, as soon as you can, is the right way to start a new project. It pulls unknown risk forward, opens up parallel streams of work, and establishes good habits.

I spend a fair amount of time helping engineering teams with the initial build and release of a product. There’s one piece of advice that I find myself giving consistently during the very early days: get the simplest version you can think of into prod, as soon as you can. Focus solely on what’s needed to get a “Hello, world” version of your new system up and running in a real production environment. No more, no less. I call this a Hello, Production release.

Story Tests - clear, expressive testing for redux reducers

Thu, 08 Aug 2019 00:00:00 +0000

This post is part of a series, covering techniques for testing redux reducers.

In the first post of this series we discovered that it’s better to test reducers and actions together, as an integrated, cohesive unit - the duck. In the next part of the series we pulled selectors into the scope of that integrated unit. We also looked at how we can simulate different scenarios in a selector test by using a reducer to get our redux state into the appropriate shape. However, the way we performed that set up was a little clunky.

Testing redux reducers - leveraging selectors

Wed, 07 Aug 2019 00:00:00 +0000

This post is part of a series, covering techniques for testing redux reducers. In the first installment of the series we saw that it’s better to test reducers and actions together as an integrated, cohesive unit. In this post we’ll take this idea a little further and see what happens when we pull selectors into our reducer testing strategy. Specifically, we’re going to see whether we can make our reducer unit tests even more expressive, by validating our expectations of redux state using selectors. We’ll also look briefly at the inverse - using reducers to make our selector unit tests more expressive.

A nice way to test redux reducers and actions - part I

Mon, 15 Jul 2019 00:00:00 +0000

This post is part one of a series, covering techniques for testing redux reducers.

One of the benefits of using redux is the ease of testing. Keeping state management separate from the rest of our application makes it easier to test in isolation.

That said, the mechanics of testing the various moving parts in a redux app - stores, reducers, actions, action creators, selectors - is not entirely obvious. One question that I see crop up frequently is how granular our tests should be. Should we test each of these moving parts in isolation, or in more integrated groupings?

Day-One Deploys

Tue, 04 Jun 2019 06:42:01 -0700

Here’s a crazy idea: software companies should require new engineers to make a production code change on their first day at work. Not allow engineers to deploy to prod on day one, but require it.

What exactly is it about this idea that makes it seem crazy, or at least ill-advised? Is it that it’s a bad idea, or is it that it doesn’t seem feasible? I do know that it’s possible: I first heard of it being done at Etsy back in the early 2010s, building on earlier ideas brought in from Flickr¹.

6 Practices for Effective Pull Requests

Fri, 10 May 2019 14:06:10 -0700

I once thought that code review was all about catching bugs, but I was wrong.

In this article I’ll discuss the additional value that teams get from code review beyond defect detection, and how Pull Requests (PRs) can get in the way of maximizing that value. Understanding the drawbacks of PR-based workflows, we’ll then discover a few simple practices which prevent pull requests from dragging down a team’s efficiency.

Almost every team I’ve worked with in the last few years has been using some variant of Github Flow - a code development branching workflow where developers do their work on relatively short-lived feature branches, and use a pull request to request a code review of the changes on that branch from other members of their team, before the changes are merged into a shared integration branch (usually master, sometimes develop).

Mission Command: enabling autonomous software teams

Fri, 08 Feb 2019 21:25:13 -0800

Building software is an inherently creative endeavor.

We never build the same thing twice — if we wanted the same thing we’d just copy-paste it! We’re always solving a new problem, which brings with it new unknowns. We also work in near-constant uncertainty and ambiguity. Priorities shift, requirements change, and our understanding of what’s needed to meet those requirements evolves over time.

The best way to achieve success in the face of all this uncertainty and change is to set up rapid feedback loops. In the past I’ve likened this situation to racing in a rally car — you need a clear windshield so that you can see the turns approaching, and a sturdy grip on the steering wheel so you can rapidly course-correct.

Advice for the Founding Engineer, part 3

Thu, 08 Mar 2018 13:08:14 -0800

Engineering decisions made at the very early stages of a product’s life can have repercussions which extend far into the future. Making well-informed, thoughtful decisions is important.

In this series of posts I condense my advice on how to make the correct decisions as a founding engineer down into three maxims. In the first post in this series I introduced the first maxim - You’ll Never Know Less Than You Know Right Now. In the second post I covered maxim 2 - Optimize For Iteration. In this post I’ll cover my third and final maxim - “Boring Is Good”.

Continuous Delivery for Static Sites

Mon, 06 Nov 2017 00:00:00 +0000

In this article I’ll show that the typical approach for deploying sophisticated static sites is not sufficient, and explain how we can apply the principles of Continuous Delivery to improve the situation. We’ll then walk through a worked example, building a fully functional continuous delivery pipeline for a single page React application.

The rise of the static site

The client-side capabilities of modern browsers have made great strides in recent years. We’ve also seen an explosion in PaaS products aimed at replacing functionality which would previously have been delivered via custom backends. It’s become more and more feasible to deliver an app as a static site, where all functionality is implemented via HTML, CSS, client-side javascript and 3rd party APIs, with no custom backend code at all.

Advice for the Founding Engineer, part 2

Mon, 14 Aug 2017 00:00:00 +0000

Engineering decisions made at the very early stages of a product’s life can have repercussions which extend far into the future. In this series of posts my advice on how to make the correct decisions as a founding engineer is condensed into three maxims. In the first post in this series I introduced the first maxim - “You’ll Never Know Less Than You Know Right Now”. In this post I’ll cover maxim 2 - “Optimize For Iteration”. In an upcoming post I’ll talk about the final maxim - “Boring Is Good”.

Advice for the Founding Engineer, part 1

Sun, 23 Apr 2017 00:00:00 +0000

The founding engineer at a new startup carries a heavy weight upon their shoulders. Technical decisions made at this early stage resonate for a long time. Beginnings are such delicate times, as they say. Compounding this is an underlying tension inherent to every young enterprise - we must get an initial product out of the door ASAP but still support what comes after the MVP. Grounding your choices against a small set of guiding principles will help keep them sensible and coherent.

The JS testing ecosystem needs a standard matcher library

Wed, 29 Mar 2017 00:00:00 +0000

The testing ecosystem in JavaScript today is full of tools which keep re-inventing the same wheel - Matchers. If we can extract this concept from individual tools into a general abstraction we can focus energy to build a much more expressive API, and provide a common ground for re-use and extension. Read on to find out why.

Matchers when making assertions

Unit-testing JavaScript code means making assertions about the shape of things. We make simple assertions like expect(result).to.eql("SUCCESS") all the time. We often make slightly more complex assertions like expect(result).to.have.property('resultType','SUCCESS') or expect(result.count).to.be.above(0). Some tools allow us to make even more sophisticated assertions like:

Articles & Talks

Fri, 10 Mar 2017 00:00:00 +0000

I’ve had articles published on various other websites besides my blog here. I also run workshops and present talks at conferences fairly frequently - slides and video of some talks are listed below.

Articles

Road to somewhere: Product Planning as Road Trip, for Increment Magazine

By sharing both the route and the destination to our strategic objectives, we can set ourselves up for a smooth planning journey.

Feature Toggles, on martinfowler.com

Feature toggles (aka Feature Flags) are a powerful technique, allowing teams to modify system behavior without changing code. They fall into various usage categories, and it’s important to take that categorization into account when implementing and managing toggles. Toggles introduce complexity. We can keep that complexity in check by using smart toggle implementation practices and appropriate tools to manage our toggle configuration, but we should also aim to constrain the number of toggles in our system.

The Symbol-Keyed State Accessor pattern

Sun, 20 Nov 2016 00:00:00 +0000

In this post I’ll show three different techniques for encapsulating internal state in JavaScript, concluding with my preferred approach, a pattern I’m calling “Symbol-keyed State Accessor”.

I was in a discussion about how to implement the Value Object pattern in JavaScript recently. Most of the examples folks were proposing involved a prototypical approach to OOO, using either class or prototype to create a Value Object type, and managing the object’s internal state via this. Here’s how one might build the basics of a Money Value Object in that style:

DIY stir plate for homebrew yeast starters

Thu, 03 Dec 2015 00:00:00 +0000

I brew beer as a hobby, and one of the secrets to really good homebrew is happy, healthy, plentiful yeast at the start of fermentation. Creating a yeast starter really helps with this, and a good yeast starter requires a stir plate to keep the yeast in suspension.

Stir plates aren’t super expensive, but at around 100USD they’re not something you’d buy on a whim. I found a lot of information online on how to make your own DIY stir plate using an old computer fan and some magnets, and since I also like tinkering with electronics I decided to give it a go. After a couple of design iterations I’m really happy with how this project turned out.

The Ultimate Traveler's Coffee Kit

Sun, 21 Jun 2015 00:00:00 +0000

I travel a fair bit for work and have discovered that when you’re living in a hotel it’s the simple comforts that you miss the most. Near the top of my list of simple comforts is a good cup of coffee soon after I wake up. The hideous coffee tea-bag things that most hotel rooms provide barely counts as coffee, let alone good coffee. A year or so ago I set out to find a way to make good coffee in a hotel room without using up a ton of luggage real-estate. Today I am very happy with my setup, apparently to the point that I’m OK with writing a blog post about it titled “The Ultimate Traveler’s Coffee Kit”.

video for my different.js talk

Tue, 02 Sep 2014 00:00:00 +0000

I had the opportunity to present at Forward JS a few weeks ago on “different.js”. No, the presentation wasn’t about a new, shiny, artisinally-crafted micro-framework. I talked about how to “level up” at JavaScript by introducing artificial constraints which force you to approach things a different way. I worked through a specific example, abstaining from the use of this and prototypes in favor of closures.

Slides for the talk are here, video is below (thanks New Circle).

optimizing 3rd party JavaScript loading

Wed, 27 Aug 2014 00:00:00 +0000

I was doing some research today on preventing slow/flakey external javascript files from 3rd-party sources from slowing down your perceived page load times. Things like tracking pixels and chat widgets are generally loaded via script tags, and if you’re not careful then one rogue provider can create a really poor experience for users on your site.

I don’t have any original thoughts here, just a collection of resources which I found that summarize techniques I’ve heard about in the past but not had to use directly until now.

Rails as an SOA Client

Thu, 15 May 2014 00:00:00 +0000

I got to present a talk at RailsConf this year. video is here, slides are here.

My talk was about Rails as an SOA client. I talked about things like Conway’s Law, Contract Testing, Hexagonal Architecture, the faraday gem, and HTTP Caching.

the 5 rules of an awesome dev toolchain

Fri, 28 Mar 2014 00:00:00 +0000

./go can eventually become the primary interface into the dev tooling for the project.

Every ThoughtWorks project I’ve ever been on has a script in the root of the project repo, often named ./go or ./go.sh (or ./go.bat if you’re very unlucky). This script often starts life as the script which the CI server runs to test the project. It soon acquires extra capabilities. It becomes the way by which developers perform a pre-commit check before pushing their changes. It becomes the script to run when you first get started on the project to download all the various project dependencies.

Microstatic: radically simple static microsites

Fri, 17 Jan 2014 00:00:00 +0000

I’m a bit fan of static sites, and have created a fair few little static one-page demos and toy apps over the last few years. I like to host these off of S3 and expose them under subdomains of my domain, thepete.net. In fact, you’re reading one of those S3-hosted static sites right now!

With modern infrastructure like S3 and Route 53 the process of setting up a new microsite is pretty straightforward, but the manual steps started to grate on me after a while. “I’m a dev”, I thought to myself. “Why can’t I automate this?”. And so of course I did.

Assertions in Page Objects

Fri, 13 Sep 2013 00:00:00 +0000

Martin Fowler recently added a bliki entry for the Page Object pattern. It’s a good writeup - if you haven’t read it I recommend doing so now. Go ahead. I’ll wait.

The entry sparked a discussion on an internal ThoughtWorks mailing list as to whether Page Objects should include assertions or not. In fact Martin mentions this difference of opinion in the bliki entry itself. I fell on the side of favoring page objects with assertions baked in but couldn’t come up with a compelling reason why until I was working on some Capybara-based page objects with a client QA today.

introducing rack-flags

Sat, 24 Aug 2013 00:00:00 +0000

I’m pleased to announce rack-flags, a very simple way to add feature flags/bits/toggles to your Rails app (or any other rack-based web app).

The rack-flags gem allows you to define a set of feature flags which can be turned either off or on for any user. Your application code inspects the state of these feature flags when processing a web request and uses that information to modify how it handles that request.

iOS Unit Testing Workshop

Tue, 06 Aug 2013 00:00:00 +0000

##TL;DR I’ll be running a couple of free workshops on iOS Unit Testing in San Francisco in late August/early September. If you’d like to attend please fill out this simple form and I’ll be in touch with details.

##Why is it free? What’s the catch?

I’m preparing to run a paid 3 hour workshop on iOS unit testing for the upcoming super-awesome StrangeLoop conference. As part of that prep I’ll be doing a couple of ‘dry runs’ of the workshop so I can fine tune the content, delivery, pacing, etc. You are cordially invited to attend. You get to learn a bunch about iOS unit testing, I get to hone and refine the workshop. A win/win for us both.

Using Travis CI and xctool to build and test iOS apps

Tue, 07 May 2013 00:00:00 +0000

Travis CI is a cloud-based Continuous Integration service which is free to use (but only on public github projects). They recently announced support for OS X agents, which means you can now use Travis to build and test iOS applications. In this post I’ll show how I set up basic CI for an example iOS app using Travis, with the help of xctool. xctool is the ‘better xcodebuild’ which Facebook recently open-sourced. It allows you to not only build your app on the command line but also run your app’s unit tests from the command line with the same capabilities that XCode offers when you run the tests from the IDE proper.

Test-driven Backbone.js - Part Three

Sun, 24 Feb 2013 00:00:00 +0000

In the previous posts in this series we’ve done some test-driven development of Backbone Models, Collections, and Views. In this post I’m going to cover another role which I believe should be present in most SPA Backbone apps: Controllers.

Controllers in a Backbone app

There’s nothing in the Backbone.js library for building Controllers. There’s not a Backbone.Controller for you to extend from. But that doesn’t mean that Controllers don’t have a part to play in your Backbone app. I suspect that the reason we don’t see Backbone.Controller in the library is simply because there isn’t much helpful shared functionality that could be put there. The Controller role is more loosly defined than other more concrete roles such as View or Model and so there’s not a need for a concrete base implementation in the Backbone.js library. However that does not mean that your app wouldn’t benefit from code organized under the Controller role.

Test-driven Backbone.js - Part One

Wed, 23 Jan 2013 00:00:00 +0000

In this series of posts I’m going to walk through some practical details on how we can develop Backbone.js applications in a test-driven manner. Developing this way leads to better structured applications, as we’ll discover.

Setup

We’ll be using backbone and underscore to build a single page app which simulates a card wall. We’ll be writing our app and our tests using coffeescript. If there’s enough interest I’d be happy to set up a JavaScript translation of the code snippets - please let me know. We’ll be using Jasmine as our test runner and we’ll be using sinon.js to create test doubles (mocks and stubs). We’ll also use a few other small utilities and plugins as we go.

Test-driven Backbone.js - Part Two

Wed, 23 Jan 2013 00:00:00 +0000

In the previous installment of this series we looked at the basics of test-driving the development of a Backbone.js app by TDDing some simple functionality for Backbone Models.

In this installment we’re going to get a bit more advanced, looking at how we can test-drive Backbone Views. Because views integrate with the DOM they can be a little more fiddly to test, but TDDing your views is still a very achievable goal.

Deploying to Heroku from CI - the gory details

Tue, 22 Jan 2013 00:00:00 +0000

In my previous post I discussed why you might want to deploy to Heroku as part of a CI build. I demonstrated how my heroku-headless gem makes it very easy to script such a deployment. In this post I’ll go into the details on how that gem does its work. I’ll talk about what the Heroku deployment tooling expects to be available, why that’s not necessarily going to be there in the context of a CI build environment, and how the gem helps resolve that.

Deploying to Heroku from CI

Mon, 21 Jan 2013 00:00:00 +0000

If you’re working on top of a modern web stack then the Heroku hosting platform is a compelling option for standing up an instance of your app with what is usually a trivial amount of effort. No need to provision EC2 servers, write chef recipes, or mess with deploy tools. Just run a couple of commands in the shell and then git push heroku.

Heroku as a staging environment

This makes Heroku a compelling choice for hosting a staging environment for your application. Staging environment contains the latest ‘good’ build of your app. They are used for things like automated acceptance testing, manual QA, story sign-off, or internal demos.

Writing iOS acceptance tests using Kiwi

Sun, 18 Nov 2012 00:00:00 +0000

In this post I’ll describe an experiment where rather than using Frank to write iOS acceptance tests I instead combined Kiwi with the low-level libraries that Frank uses internally. This allowed me to write acceptance tests in pure Objective-C which run in the app process itself, very similarly to the way KIF works.

What?

Before I start, let me be clear that I personally wouldn’t use this approach to writing acceptance tests. I much prefer using a higher-level language like ruby to write these kinds of tests. The test code is way less work and way more expressive, assuming you’re comfortable in ruby. And that’s why I wanted to try this experiment. I’ve spoken to quite a few iOS developers over time who are not comfortable writing tests in ruby. They are more comfortable in Objective-C than anything else, and would like to write their tests in the same language they use for their production code. Fair enough.

Cookie-based feature flag overrides

Tue, 06 Nov 2012 00:00:00 +0000

Introduction

If you’re practicing Continuous Delivery then you’re probably using Feature Flags to hide half-baked features which are being shipped into production as latent code. It’s useful to allow individual users to manually override those feature flags so that they can get a preview of these latent features before they are released to everyone. People wanting to do this would be testers, product stakeholders, and external beta testers.

This is a similar concept to the Canary Releasing approach which organizations like Facebook use to trial new features. The difference is that with manual overrides each individual is opting in for features themselves, as opposed to being arbitrarily placed into the pool of users assigned as canaries.

Frank with CocoaPods

Tue, 16 Oct 2012 00:00:00 +0000

A Frank field trip

Today I’m visiting 955 Dreams (the guys who make Band of the Day, amongst other things) visiting my friend (and their CTO) Chris. We had a fun time figuring out how to get Frank to play nicely with CocoaPods. It wasn’t that tricky, and I’m going to document what we found here to hopefully make it easier for other Cocoapod users.

Problem the first

Frank had trouble with cocoapods for two reasons. Firstly when frankifying the app we needed to frankify the app’s Xcode project, but to build the app we needed to point frank build at the main Xcode workspace, so that cocoapods could work its magic during the build. This was simply a case of passing the appropriate --workspace and --scheme arguments to frank build.

Towards Frank 1.0

Thu, 06 Sep 2012 00:00:00 +0000

One of the many geeky hats I wear is that of maintainer for Frank, an open-source tool for automated testing of native iOS applications. Frank has been around for over 2 years now, which is actually quite a long time in the mobile space. It has evolved a fair amount in that time, but has had a surprisingly small amount of change to the core architecture. I’m actually quite proud of that. I think that the core concepts have been proven out enough that Frank is ready for a 1.0 release which cleans up some long-standing cruft and solidifies at least parts of its client/server API.

Introducing PublicAutomation

Mon, 20 Aug 2012 00:00:00 +0000

I’m excited to announce PublicAutomation, a friendly wrapper around Apple’s private UIAutomation framework. PublicAutomation allows you to use Apple’s own private framework to simulate user interactions (taps, swipes, keyboard typing) via a simple Objective-C API.

Previous approaches to this problem have relied on reverse-engineering and monkey-patching iOS’s touch events system. PublicAutomation takes a different approach. It links in the low-level API of the private framework which Apple itself uses for its own UIAutomation tooling. PublicAutomation provides the stability of Apple’s proprietary UIAutomation tool with the flexibility of an open source library maintained by the community.

marker branches in git

Thu, 09 Aug 2012 00:00:00 +0000

In my last post I talked about setting up a basic deployment pipeline using marker branches in git to keep track of what was where.

In this post I want to go into a little more detail describing how these marker branches work. To do that I’ll walk through a simple example showing the state of a git repo as code moves through being committed, being pushed to master, deployed to pre-prod, and finally promoted to prod.

Octopress deployment pipeline

Thu, 02 Aug 2012 00:00:00 +0000

I spent a fun evening recently setting up a deployment pipeline for this blog. I’d like to share some details on what I set up and why.

The motivation was that I wanted some way to publish draft blog entries for other people to review, but I didn’t want these drafts to show up on my public site. I played with Octopress’s published: false option, but it really didn’t give me what I needed. Then I saw someone commenting that the ideal would be to have a preview version of the entire site available at a separate url. A pre-production environment, essentially. Hmm, I thought. Every web project I work on has one of these. It’s used to showcase the version of the system which is going to be released to production. That’s what I need - why don’t I just set that up for my blog?

Running Frank as part of iOS CI

Sun, 22 Jul 2012 00:00:00 +0000

Frank is a tool that allows you to run automated acceptance tests against your native iOS application. A major reason for creating automated acceptance tests is so that you can run them as part of your Continuous Integration (CI) process. Doing this enables a rapid feedback loop where a developer checking in code is informed very quickly if that change caused a defect in your app.

In this post I’ll show how to configure a basic CI setup using Jenkins which will build your app and run Frank tests against it every time you check in code. CI for iOS projects don’t seem to be a common practice. This is a shame because the CI can bring just as many benefits for iOS applications as for other technologies. I suspect part of the reason CI is less popular is that Apple doesn’t make it particularly easy. It’s not a trivial task to automate things like building your application and running unit tests. Things are moving in the right direction though, with both Apple and open-source developers making it simpler to integrate a dev toolchain into a CI setup.

Using the UIAutomation private framework

Wed, 11 Jul 2012 00:00:00 +0000

I’ve recently spent a few hours investigating how feasible it would be to use Apple’s private UIAutomation framework to simulate user interactions in iOS apps. The motivation for this is of course being able to use this for Frank, the UI testing tool I maintain. This post will summarize my progress to date. You can also check out my work-in-progress uiautomation branch for Frank. Note that that branch is very rough and ready at the moment. I pushed it up to my github repo just so anyone who wants to see progress so far can do so.

writing your first Frank test

Sun, 24 Jun 2012 00:00:00 +0000

You’ve heard about how awesome Frank is and you’re all fired up about getting some automated functional testing set up for your iOS app. Now you’re ready to start writing your first test. In this article I’ll cover the fundamentals of writing Frank tests, using an open source iOS application written for the 2012 Olympic Games as an example.

get the code for your app

I’m guessing you’ll already have the code for your own app, but if you’d like to follow along with the examples in this post you’ll want to download the sample app I’m using. You’ll find it on github here. Create a local clone of that repo with git clone https://github.com/Frahaan/2012-Olympics-iOS--iPad-and-iPhone--source-code.git

Lowering Frank's barrier to entry

Sat, 16 Jun 2012 00:00:00 +0000

I’ve always known that it’s really important new users of Frank to easily get started by creating a Frankified version of their app - a build which has been enhanced with the embedded server which lets Frank do its magic.

When the project was first started it was really quite complex to setup. You had to add a bunch of source code to your app, and then modify a few bits of your app’s startup code.

The Birth Of a Domain Object In Ruby

Sat, 09 Jun 2012 00:00:00 +0000

Software designs don’t pop into existance fully formed. They evolve over time. In this post I’m going to show how a concept can grow from a simple method parameter to an all-growed-up Domain Object.

Initial requirements

Imagine we’re building some code that will take bug reports from a user and submit them to a third-party bug tracking service. We expose an HTTP endpoint in a sinatra app to allow this:

Feature Flags in JavaScript

Wed, 09 May 2012 00:00:00 +0000

On a recent project we were applying Continous Delivery practices and were releasing to production reasonably frequently - sometimes multiple times a week. We didn’t want to expose features which were under active development in our production environment but we also wanted to avoid feature branches. I’m going to describe the simple approach we used to solve this problem using feature flagging with javascript and CSS.

What are feature flags?

Features flags (aka feature bits, feature toggles) are a very useful technique for managing latent functionality within your application. You expose switches in your application which configure whether certain behavior is enabled or disabled. Typically your would use this pattern for functionality which is under active development and is not ‘fully baked’.

Moving from Blogger to Octopress

Wed, 08 Feb 2012 00:00:00 +0000

Yes, like many other dork bloggers I’ve jumped onto the Octopress bandwagon.

A big concern I had with switching blogging platforms (I was previously on Blogger) was breaking links to my existing content. Part of my concern was in losing Google Juice (yes, I’m that vain), but I’m also aware that a couple of my posts about Frank have become sources of documentation which are linked to from a few different places on the web. I definitely did not want to break those links.

Class-less javascript

Mon, 06 Feb 2012 00:00:00 +0000

It seems that every javascript framework of a certain size is compelled to implement some kind of pseudo-classical type system. I am now fairly convinced that there is no good reason for doing so. I’d like to describe an alternative approach to dealing with types in JavaScript.

This approach comes from a recent project where my team was building a pure-JavaScript single-page web application. This wasn’t a huge codebase, but due to the single-page nature of the app it did have a reasonable amount of non-presentation logic which was implemented client-side in JavaScript. We needed a type system but we knew we didn’t want to try and force a classical-OO system onto JavaScript. The patterns we evolved gave us just enough structure while still allowing us to take advantage of the highly flexible and dynamic nature of JavaScript.

Testing Mobile Web Apps With WebDriver

Fri, 02 Sep 2011 00:00:00 +0000

Intro

We’ve been building mobile web apps using JQuery Mobile with the main target being webkit-based mobile browsers - Android and iPhone, basically. We’re big fans of functional testing, so we spent some time figuring out how to get a good testing infrastructure set up for mobile app development. That’s what I’ll be sharing here.

The approach

Our team members have a lot of experience using Cucumber to write automated acceptance tests, and we’re big fans. In previous projects we were building native iOS apps and testing them using Cucumber and Frank. We wanted to bring over some of the testing infrastructure we already had set up, so we decided on a similar approach. We still use Cucumber to drive tests in the iOS simulator, but instead of talking to a native app using Frank we are talking to our mobile web app via Selenium 2’s remote WebDriver protocol. In order to do this we run a special iOS app provided as part of Selenium 2 called iWebDriver which hosts an embedded UIWebView and listens for WebDriver commands, in much the same way as a Frankified native app listens for Frankly commands. We launch the iWebDriver app using the same SimLauncher gem which we’ve previously used to launch our native app for pre-commit and CI testing. To make our lives easier we use Capybara, which provides a nice ruby DSL for driving web apps and some useful cucumber step definitions out of the box. We configure Capybara to use the selenium-webdriver gem to drive the iWebDriver-hosted web app via the WebDriver remote protocol.

Javascript Promises

Sat, 02 Jul 2011 00:00:00 +0000

One of the interesting aspects of Javascript development is its asynchronous, event-driven nature. Any operation which will take a significant amount of time (e.g. a network request) is non-blocking. You don’t call a function and block until the operation completes. Instead functions are non-blocking - they return before the operation is complete. To obtain the result of the operation you provide callbacks which are subsequently invoked once the operation completes, allowing you to move on to the next stage in your computation. This is a very powerful, efficient model that avoids the need for things like explicit threading and all the associated synchronization problems. However, it does make it a bit harder to implement a set of operations that need to happen one after another in sequential series. Instead of writing:

retroactive quality metrics with git

Sun, 08 May 2011 00:00:00 +0000

The Background

For a recent project retrospective we wanted to chart some metrics over the course of the entire project. Things like number of unit tests, test coverage, how long builds took to run, number of failing tests, etc. Taken in isolation these metrics aren't incredibly exciting, but when you plot them over time and hold that against other metrics like team morale, story point velocity, open defects, etc then often some interesting correlations can emerge.

Inspect the state of your running iOS app's UI with Symbiote

Sun, 01 May 2011 00:00:00 +0000

What's Symbiote?

Frank comes with a useful little tool called Symbiote. It's a little web app which is embedded inside your native iOS application. Its purpose is to let you inspect the current state of your app's UI, and to test the UIQuery selectors which Frank uses to help it automate your app. Essentially Symbiote is Firebug for your native iOS app.

Recently I've added some improvements to Symbiote, adding some new features and making it easier to use. This screencast demonstrates most of the new-and-improved Symbiote.

Tutorial screencast on Frankifying your app

Tue, 19 Apr 2011 00:00:00 +0000

I maintain Frank, a tool which lets you write automated acceptance tests for your iOS app using Cucumber. I've been trying to reduce the hurdles in getting started with Frank. My latest attempt is to record a tutorial screencast showing how to take your existing app and 'Frankify' it.

'Frankifying' an app is the process of adding a separate Frank target to your app which has the Frank server embedded into it, allowing it to respond to automation commands. It can seem like a bit of an intimidating process at first glance, but it's actually very simple. Hopefully running through the whole process in a 7 minute screencast demonstrates that.

Derek Longmuir has also contributed a nice in-depth tutorial writeup (which I was following along with when I recorded the screencast).

Working with Indirect Input and Output in Unit Tests

Tue, 04 Jan 2011 00:00:00 +0000

Testing how a unit of code interacts with its environment

When testing a unit of code you need to both observe how the unit of code is interacting with the outside world and also control how the world interacts with it.

In a particuarly simple example, you might want to check that when an adder function is given a 2 and a 4 then it returns a 6. In this case you’re controlling what the System Under Test (SUT) pulls in from its environment (the 2 and the 4) and also observing what it pushes out (the 6). In a more sophisticated example you might be testing a method which talks to a remote service, verifying that if it receives an error code when trying to read from the network then it logs the appropriate error message to a logger. Note that we’re still doing essentially the same thing here - controlling what the SUT pulls in from the environment (an error code in this case) and observing what it pushes out (a call to a logger in this case).

Creating and publishing your first ruby gem

Sat, 20 Nov 2010 00:00:00 +0000

Introduction

In this post I’m going to cover the basics of creating and publishing a gem using the bundle gem command provided by Bundler. We’re going to use bundler to create a gem template for us. We’ll then take that skeleton gem, add some functionality to it, and publish it for all the world to use.

For the purposes of this tutorial I need a very simple example of something which you could conceivably want to release as a gem. How about a simple Sinatra web app which tells you the time? Sure, that’ll work. We’ll call it Didactic Clock. In order to make this server implementation need more a couple of lines of code we’ll add the requirement that the clock tells you the time in a verbose form like “34 minutes past 4 o’clock, AM”.

timestamped-scenarios, a custom Cucumber formatter

Sat, 20 Nov 2010 00:00:00 +0000

I just published a new Ruby gem called timestamped-scenarios. As usual the code is also available on github.

What's this gem for?

This gem provides custom cucumber formatters which append a test run timestamp to each scenario name as it is generated. a Timestamped::PrettyFormatter and Timestamped::HtmlFormatter are supplied already, but you can use the AddsTimestamp module to dynamically add timestamping to pretty much any Cucumber formatter.

You might wonder why I created these formatters. I'm currently working on an iOS project where we are using Frank and Cucumber to run automated acceptance tests against the application. We have integrated these acceptance tests into our CI build, and as part of that integration we record a screen capture movie of each test run. By adding timestamps to each scenario name we can easily skip to the part of the movie which shows that scenario executing. This is useful when trying to figure out the context around why a
specific scenario failed.

Objective C memory errors pt II - Dangling Pointers

Tue, 12 Oct 2010 00:00:00 +0000

In my last post I talked about memory leaks in Objective C. In this post I'll take about the converse - dangling pointers. In iOS a dangling pointer happens when you maintain a reference to an object which has been deallocated. I'd say the most common cause is failure to take ownership of an object you intend to maintain a reference to. Another common cause is when an object is accidently released multiple times by the same owner, leading to its retain count dropping to 0 and the object being deallocated before all the objects which hold references to the object release those references.

Common Objective-C memory management errors, Part I

Mon, 11 Oct 2010 00:00:00 +0000

I would say that the steepest learning curve for someone new to iOS development is having to manage your own memory using reference counting. Knowing when to retain and when to autorelease can seem like a black art until you understand the conventions which is used (extremely consistently, I might add) within Objective C libraries. Let's examine one very common mistake, which I will call the Property Assignment Memory Leak. I've seen this a few times, and indeed committed this error myself during my first weeks of iOS development.

The code

Imagine we have a simple Duck class, which holds a feathers array:

@interface Duck : NSObject {
  NSArray *_feathers;
}
@property (nonatomic,retain) NSArray *feathers;
@end

@implementation Duck
@synthesize feathers=_feathers;
@end

during construction we'd like to initialize this array, so we create an init method as follows:

- (id) init
{
  self = [super init];
  if (self != nil) {
    self.feathers = [[NSArray alloc] init];
  }
  return self;
}

Of course, we need to make sure we release our ownership of the feather array during deallocation, so we'll add a dealloc method like so:

- (void)dealloc {
  self.feathers = nil;
}

The Leak

So we're good here, right? The observant reader will note that no, we're not. the feathers array which we created in our init method will never be released. This will be a little easier to explain if I refactor the init method a little, making it more verbose by introducing a local variable to hold the array we are about to assign to the self.feathers property:

- (id) init
{
  self = [super init];
  if (self != nil) {
    // alloc will always create an object with a retain count already set to 1. In other 
    // words, tempArray has ownership of the object.
    NSArray *tempArray = [[NSArray alloc] init]; 

    // assigning to self.feathers bumps the array's retain count up to 2. In other words, 
    // now the feathers property also has ownership of the object.
    self.feathers = tempArray; 
  }

  // when we return tempArray goes out of scope without ever releasing ownership of the object it created. Memory leak!
  return self;
}

To make this clearer, I'll try and illustrate what happens as we move through the Duck object's lifecycle.

1) Here an instance of Duck has just been alloced, and we're about to execute init.

Podcast about Frank and test automation on iOS

Sat, 07 Aug 2010 00:00:00 +0000

Some colleagues at Thoughtworks and I recently recorded a 30 minute podcast about Frank, our UI automation tool for iPhone/iPad testing which I introduced in this post.

In the podcast we cover:

an overview of Frank, what it is and where it came from.
How our testers and developers use Frank and cucumber at our current client (and how we'd ideally like to be using it).
Alternatives to Frank, such as iCuke and brominet.
Some waffling by me about some of the reasoning that drove my design decisions with Frank. For example, avoiding XML and XPath for UI element selection.
Symbiote, the little web app that we embed inside Frank which allows a test creator to inspect and play with the live iOS app as it's running.
Writing cucumber feature files per-story versus per-feature.
Handling the stateful nature of an iOS app in UI-level tests, and including Frank testing into a Continuous Integration system.
The challenges of testing an app which integrates with large back-end systems.
What's next for Frank.

Many thanks to Chris Stephenson for organizing and facilitating, and to Derek and Hiyasmin for tolerating my hogging of the mike!

You can get more information on the podcast and give it a listen here.

Frank: Automated Acceptance Tests for iPhone and iPad

Fri, 23 Jul 2010 00:00:00 +0000

Recently I joined a team developing an iPad application. The application had no existing automated tests, and the team was under a tight deadline to deliver on promised functionality. Faced with similar circumstances in the past I have advocated introducing automated UI-driven acceptance tests to establish a loose but broad test coverage net. After a brief investigation we decided that the available tools weren't quite what we needed, so we built our own 'Frankenstein's Monster' by plumbing together several existing open source libraries to create a light-weight UI automation framework for iPhone and iPad applications, called Frank.

TDD, Emergent Design, and Punctuated Equilibrium

Thu, 22 Apr 2010 00:00:00 +0000

In my experience good TDD designs tend to have evolved (and hopefully continue to evolve) in a sort of punctuated equilibrium. There are long periods of small incremental changes to a code base, punctuated by infrequent bursts of large design-level refactorings. While the TDD mantra is "Red, Green, Refactor", I think a more accurate version would be "Red, Green, Red, Green, Red, Green, Refactor". Less catchy, I know.

Letting tests drive your design is great, but if you're not careful you will end up with a design which is the result of a simple accreation of functionality. This of course is the reason for the "Refactor" part of RGR. However, in my experience the refactoring part does not occur in a steady flow. Rather there will be periods of time where only small implementation-level refactorings take place during the RGR cycle as new functionality is implemented. Then at some point something will give. Someone may have a design breakthrough, realizing a more expressive/elegant/clean way to express some functionality. Alternatively some niggling annoyance in a subsystem's design will pass the team's tolerance threshold such that they decide they need to clean up the design to remove the annoyance. Both events will lead to a brief flurry of larger design-level refactorings.

Introducing Noguchi

Mon, 05 Apr 2010 00:00:00 +0000

Generating HTML tables in ruby has always seemed like more of a hassle than it should be. Most of the times that I've had to do it I've been a little frustrated with how, well, ugly the view code looks. So, I decided I'd try and create a nicer way to build tables. The end result is a small table creation library called Noguchi. Given a set of data and some optional configuration it will render a table as HTML or CSV.

Stormcloud will watch over the unicorns.

Sat, 03 Apr 2010 00:00:00 +0000

Hipster geeks crack me up. A nice ancillary benefit of being in this industry is I get to read blog posts about interesting technical stuff which also include phrases such as:

...we developed a new monitoring script, called Stormcloud, to kill Unicorns when they ran out of control...

...Monit would still monitor the master Unicorn process, but Stormcloud would watch over the Unicorns...

...child death during request processing ... would cause that request and all requests queued in the mongrel to send 500 "robot" errors until the mongrel had been restarted...

No need to fear, children. Stormcloud will watch over the unicorns. And if all else fails, a mongrel will send 500 robot errors.

TickTock: A dirt-simple stopwatch class for actionscript

Tue, 09 Mar 2010 00:00:00 +0000

I just threw together a really straightforward stopwatch class, for use when profiling operations in ActionScript code. You can either use it in an old-skool procedural way:

var tt:TickTock = new TickTock();
tt.start();
doSomeWork();
tt.stop();
trace( "That took "+tickTock.elapsedTimeInMilliseconds+" millisconds" );

or in a fancy-pants, functional, closure-y way:

var tt:TickTock = TickTock.measure( function(){
  doSomeWork();
});
trace( "That took "+tickTock.elapsedTimeInMilliseconds+" millisconds" );

Being primarily a ruby guy, I prefer the fancy-pants approach ;) The class, along with a little sample app, is up on GitHub now.

Why do we estimate effort?

Sun, 07 Mar 2010 00:00:00 +0000

I listened to a really good podcast yesterday on Kanban. One of the topics discussed was the fact that with Kanban estimating story points is optional. Most of my agile experience is with Scrum, so my initial reaction was one of mild disbelief. How can a team perform work without estimating effort! But when you think about it, why do we have this vaguely obsessive focus on story points in Scrum? Surely in other areas there are teams that get by perfectly well without having to determine up-front how much effort each item of work is going to require. What is the value in estimating? Here's what I came up with:

Primitive Obsession obsessions

Mon, 22 Feb 2010 00:00:00 +0000

After seeing the Primitive Obsession code smell crop up in a few different places recently I got to thinking about it in the context of static and dynamic languages.

Essentially this code smell refers to using a primitive data type (int, string, etc), or a cluster thereof, where you could instead be using an explicitly defined type. Probably the most common variant of Primitive Obsession would be a method like:

Encapsulating user interaction events in Flex

Fri, 19 Feb 2010 00:00:00 +0000

When developing the presentation layer in a Flex application I like to follow an MVC/MVP pattern. I also like to keep my views nice and skinny, with as much logic as possible in the controller/presenter. However, I do like to encapsulate some of the details of the UI itself within the view, and so I shy away from exposing raw user interaction events (button clicks, list selections, etc) outside of the view. Instead I like to have the view capture those events and translate them into what I call user action events, which represent higher-level, user-centric interactions. So instead of publishing a 'list item selected' event, the view publishes a 'blog post selected' event. For example, here what a typical event handler would look like in a view's MXML file:

Ruby Facets: the mash method

Thu, 18 Feb 2010 00:00:00 +0000

I keep meaning to write up some of the useful gems (if you'll pardon the pun) which are hidden in the super-handy Facets gem. Today I'll cover Enumerable#mash.

Let's say you have a list of Users, and you'd like to create a hash which lets you look up the Users based on their login. You might write something like:

def create_login_hash_for( users )
  user_login_hash = {}
  users.each do |user|
    user_login_hash[user.login] = user
  end
  user_login_hash
end

With Enumerable#mash, you can trim that down to:

Partial commits with git

Wed, 03 Feb 2010 00:00:00 +0000

I've been using git for a few months now. Like all the best dev tools it has slowly permeated my workflow to the point where I'd feel pretty crippled without it. In fact, I don't think I would ever go back to a centralized system like svn at this point. In a pinch I'd fall back to using git locally and then using the appropriate git-to-foo integration to push my local changes from my git repo to whatever the centralized repository was.

an inverted include? for ruby

Sun, 31 Jan 2010 00:00:00 +0000

I've always found it a slightly hard to read ruby which uses Enumerable#include?(), especially when the Enumerable your testing against is a literal or a constant. For example, let's say you're checking an input parameter to guard against invalid input. You might write something like:

unless VALID_COMMANDS.include?( command_param )
  whine_to_user()
  return
end

This makes sense, but it seems backwards to me. I don't care whether some array has a value in it so much as I care whether a value is in some array. Obviously that's just two ways of saying the same thing, but the latter seems to capture the intent much more to me. I think it would be easier to understand this:

Flex Patterns: Presentation Adapter

Sun, 17 Jan 2010 00:00:00 +0000

Flex Patterns: Presentation Adapter

Encapsulate the logic for presenting a domain object, and provide an object for skinny views to perform data-binding against.

Problem

When using Presentation Model our goal is to bind UI elements in your Skinny View directly to individual components of the Presentation Model. This requires translating information in Domain Model instances into a presentation-specific form. At the same time we need to be able to map back from that presentation-specific form to the underlying domain model instance in order to present user interactions in terms of our domain model.

How much code did I just delete?

Tue, 17 Nov 2009 00:00:00 +0000

Today I had the great pleasure of deleting a huge chunk of old code from my application. Using git it's surprisingly easy to figure out exactly how much code:

 
git checkout -b deletion_task

# ... delete lots of code...
# ... time passes...

git add -i
git commit
git co master
FILES_DELETED=`git diff --summary master deletion_task | grep "^ delete" | wc -l`
LINES_DELETED=`git diff --summary master deletion_task | grep "^ delete" | awk '{ print $4 }' | xargs cat | wc -l`
echo -e "$FILES_DELETED files deleted.\n$LINES_DELETED lines deleted."

Introducing Gimme: a lightweight ruby Registry

Mon, 16 Nov 2009 00:00:00 +0000

I recently created Gimme, a small ruby gem which allows you to configure and access a simple Registry using a nice little DSL.

Gimme in a paragraph

The general idea of Gimme is to allow a single point for configuring the well known services which your application uses (think DB connection, twitter API gateway, email server, etc). Once configured Gimme then exposes a single point to access those services, without needing to resort to singletons or global variables.

Show me teh codez

Here's a simple example showing how you would configure your registry:

Gimme.configure |g|
  g.for_the(ExternalService) do |env,name|
    ExternalService.new(env[:setting1],env[:setting2])
  end
end

and here's how you'd use it from within your app:

Gimme.the(ExternalService).some_method

Here's a more complete example, showing both configuration and usage:

# your Emailer class

class Emailer
  def initialize( smtp_hostname, port )
    @smtp_hostname, @port = smtp_hostname, port
    puts "creating an emailer: #{inspect}"
  end

  def send_email( subject )
    puts "Sending email '#{subject}' via #{inspect}"
    # ...
  end

  def inspect
    "#{@smtp_hostname}:#{@port}"
  end
end


# your Gimme configuration

Gimme.configure do |g|
  g.for_the( Emailer ) do |env|
    email_settings = env[:email_settings]
    Emailer.new(email_settings[:hostname],email_settings[:port])
  end
end

Gimme.environment = {:email_settings => {:hostname => 'smtp.mymailserver.com', :port => '2525'} }



# in your app


Gimme.the(Emailer).send_email( "Gimme is the awesomez" )
Gimme.the(Emailer).send_email( "Emailing is fun" )
Gimme.the(Emailer).send_email( "notice that only one Emailer was created above" )
Gimme.the(Emailer).send_email( "even though we sent 4 emails" )

Pseudo-singletons

If you use the Gimme#for_the(Service) form when configuring Gimme then gimme will only create one instance of that object. If you use the Gimme#for_a(Service) form then the creation block will be called each time you ask for an instance of that object. That way things which hold on to expensive resources (database connections, TCP sockets) can be shared within your app, which services which need to maintain unique state for each client can be private to each client.

Environments

In any non-trivial application you need to configure your services. You can supply Gimme with an environment hash which it will then pass to your creation blocks whenever you ask for an object. This allows you to store settings like smtp hostnames, database passwords, twitter API keys, etc in a single environment hash, and use that hash in one place to configure all your external services at the point they are created.

Dependency Injection/IoC

There is nothing to stop you from calling Gimme.a() or Gimme.the() from within a creation block. This allows you to use Gimme as a lightweight IoC container.

Check it out!

Check out the github page for more info, including lots of example usages, and a more detailed README.

Adding hamcrest-as matchers to mock4as

Sun, 28 Jun 2009 00:00:00 +0000

Just a quick post to mention that I recently did an experiment with extending mock4as to use Drew Bourne's awesome hamcrest-as3.

The idea for this work is to specify mocked method arguments in a more flexible way. It was actually surprisingly trivial to implement. I'll be writing a more detailed post in the future explaining what these changes mean to a user of mock4as.

I also took the opportunity to experiment with using git and github, so the changes are available to all and sundry as a github repository. I will be talking to the mock4as guys about getting my changes merged into the official mock4as codebase

Presentation Model Pattern

Sun, 14 Jun 2009 00:00:00 +0000

Presentation Model

We want to achieve a Skinny View without the View needing to expose UI details to the Controller.

Also known as

View State, Logical View

Problem

We want to have as much presentation logic under test as we can by having a Skinny View. At the same time we don't want our Controller to be burdened with the minutiae of maintaining UI elements.

REST: 'There aren't enough verbs'

Sun, 19 Apr 2009 00:00:00 +0000

I think one of the more frequent issues that people have when starting to work with a RESTful architecture is that "there aren't enough verbs".

Why having few verbs is good

When we look at the big picture we see that this paucity of verbs is in fact one of the strengths of REST. A small, standard set of verbs allows all parties to agree (in the most part) on what the semantics of those verbs are. This in turn allows the creation of a lot of loosely coupled infrastructure which any REST system can take advantage of. An obvious example is the sophisticated caching system within the world wide web. All parties can agree on what a GET means, specifically that it's an idempotent operation. That allows intermediaries to know when a response is cachable. If each application was creating its own set of verbs we'd no longer be able to leverage all this 'free' infrastructure which has built up. If a cache somewhere between your user's browser and your data center doesn't understand what the semantics of some custom verb are then it can't safely cache your responses. Same goes for your user's browser. This is one of the reasons why RESTful folks don't like web services with RPC-style architectures. By tunnelling everything through POST and a single URI these services lose the ability to confer semantics to intermediaries. These kinds of services are on the web, but not of the web.

What to do when you 'need' more verbs

So, we are agreed that a small, standard set of verbs is a good thing. What then is an API designer to do when modeling a complex operation which doesn't map nicely onto that small set? In my experience there are generally two solutions. We can use an overloaded POST, or we can add some additional 'activity resources' to the resource space of the API. I tend to prefer the latter, but I think it's important to not be dogmatic about this. There are certainly situations where an overloaded POST is the way to go.

Let's discuss what I mean by 'activity resources'. Generally when people start designing the resource space for their RESTful API they might write a description of what functionality the API seeks to expose, and then go through the text underlining nouns. If this is reminding you of an analysis technique for a certain other paradigm then stick with me, I'll be coming back to that in the next section. This set of nouns would generally be a good starting point for identifying resources. I'll call these types of resources Entity Resources. Let's say we're working on a hotel reservation system. After this initial stage of analysis we might come up with a set of entity resources such as Guest, Room, Hotel, Bill, etc. We'd probably also have Reservation in there too, but I wouldn't classify that one as an entity. So far so good. Now, let's say we're working on the checkout part of the system, in particular on credit card processing. We need a way to represent the act of a Guest paying their Bill with a credit card, having that credit card transaction approved or declined, etc. A lot of developers (particularly those coming from an RPC mindset) will want to do something like add a PAY verb to the Bill resource. This makes sense. Paying is an action that is applied to the Bill. It makes sense, but as we've discussed above REST frowns upon extending our small set of verbs. So instead we can create an Activity Resource called Payment. This resource can contain a reference (in the form of a uri) to the Bill it is a Payment for, along with details like credit card number, etc. In addition we can add a Payments resource which belongs to each Bill. When a customer wants to pay a bill they can send a POST to the Payments resource, supplying a representation of the payment they want to make. That POST will create a Payment resource representing the transaction, and supply the user with a uri for that resource in the form of a redirect. The customer can GET on that resource to check on the state of the payment transaction (Processing,Successful,Denied), etc. Maybe if the payment was denied they could PUT to the resource with a corrected credit card number. The key pattern here was to take an action (paying a bill), and to model that as a transitory Activity resource. Adding that extra level allows us to model the behavior in a RESTful way. I've frequently seen transactions modeled RESTfully in this way.

Sidebar: Parallels in grokking REST and grokking OO

When I was going through the slow, laborious process of getting these ideas into my thick skull I experienced a vague feeling of déjà vu. I eventually realized that this was just like when I first started to really grok object-oriented design. Often when students are being taught to design object oriented systems a suggested technique is to write a description of the business domain and then underline the nouns in the description. These nouns will be the classes in your system. However, after gaining experience with OO I think most developers realize that these classes are not where the meat of a design lies. The meat lies in the interaction between these entities, how they are composed and how they interact. Using polymorphism and composition to create clean, loosely-coupled systems becomes much more interesting than designing the Is-A inheritance heirarchies that often appear in introductions to OO. And here lies the parallel with learning RESTful design, and my sense of déjà vu. When learning REST the core concepts of Resources, Actions, Uris, etc. are necessarily explained first, and most pedagogical examples focus on simple systems consisting of what I referred to above as Entity Resources. However when you start to do real work with a RESTful architecture you start realizing that large parts of the system are about modeling the relations and interactions between these Entity Resources. I expect that as we gain more experience with the REST style then the common problems and shared solutions will start to emerge, in the same way as we saw OO design mature in the 80s and 90s.

mock.willExecute(...) in mock4as

Thu, 02 Apr 2009 00:00:00 +0000

As I mentioned in a previous post I've recently been adding some features to mock4as, a mocking library for ActionScript. In this post I'm going to talk about the new mock.willExecute(...) feature which I recently implemented.

Perhaps the easiest way to describe willExecute is as a dynamic version of willReturn, so before we dive into willExecute I should briefly explain willReturn. willReturn allows a user to specify what value a mocked out method should return when called. An example should shed some light:

var mock:MockInterface = new MockInterface();
mock.expects('lookupBookTitleByISBN').withAnyArgs().willReturn('War and Peace');
assertEquals( 'War and Peace', mock.lookupBookTitleByISBN() );

You can see that when we call the method mock.lookupBookTitleByISBN() it returns 'War and Peace', because that's what we specified in our expectation. This is a fundamental feature that I would expect any mocking system to supply. It's the primary tool for controlling the indirect inputs into the system that your testing. That said, newcomers to mocking do sometimes get confused with this feature and think that willReturn is specifying what you expect the method to return. That's not what we're doing here, we're instructing the mock what to return. We're providing indirect input, not testing indirect output (the other main purpose of mocking). I suspect that adding a new method to mock4as which is similar mock.expects(...) but intended for use in cases where you just mocking the method to control indirect input would be helpful. Something like mock.ifCalled('foo').willReturn(someResult) might clear up some of the confusion between specifying an expectation that a method is called and injecting a return value for a method.

Anyway, back to the subject at hand. The willExecute feature takes the concept of willReturn and makes it dynamic. Rather than specifying a hard-coded value to be returned whenever the method is called you instead supply an arbitrary function which will be executed whenever the specified method on the mock is called. For example:

var mock:MockInterface = new MockInterface();
mock.expects('lookupBookTitleByISBN').willExecute(
  function( isbn:String ):String{
    return "Title for isbn " + isbn;
  } );

assertEquals( 'Title for isbn ABC', mock.lookupBookTitleByISBN('ABC') );
assertEquals( 'Title for isbn XYZ', mock.lookupBookTitleByISBN('XYZ') );

Every time lookupBookTitleByISBN(...) is called the mocking system looks up and executes the attached function, passing in the arguments supplied to lookupBookTitleByISBN(...). In addition it returns whatever value was returned by the attached function. Note from our example that this allows output to vary with the input, because we have supplied a function rather than a static value.

The real fun starts when we realize that functions in actionscript can act as closures. This leads to a lot of interesting ways to use willExecute. To give one (rather contrived) example, we can use willExecute to specify some quite sophisticated ordering constraints:

public function test_accountsAreSubmittedInAscendingNumericalOrder():void {
  var mock:MockInterface = new MockInterface();

  var lastAccountId:int = -1;
  mock.expects('submitAccount').withAnyArgs().willExecute(
    function(account:account):void {
      assertTrue( account.id() >= lastAccountId );
      lastAccountId = account.id();
    }
  );

  exerciseSystemUnderTestUsing( mock );
}

Note here that we have used variables outside of the closure's local scope to maintain state across calls to the mocked method. Also note that we can call methods like assertTrue(...) from inside the attached function.

Some other potential uses of this feature include:

Verifying arguments passed to a method where the argument is complex: Let's say a method takes a Parameter Object which is an instance of a class with 10 properties, but we're only interested in three:

public function testXYZCoordinatesAreAllSetToZero():void
{
  var mock:MockSomeInterface = new MockSomeInterface();

  mock.expects('methodWithScaryParams').withAnyArgs().willExecute(
    function(bigObject:ComplexParameterObject):void{
      assertEquals( 0, bigObject.coordX );
      assertEquals( 0, bigObject.coordY );
      assertEquals( 0, bigObject.coordZ );
    }
  );

  exerciseSystemUnderTestUsing(mock);
}

Verifying arguments passed to a method with a lot of parameters but where we're only interested in some of the arguments:

public function testNameAndAddressAreNotEmpty():void
{
  var mock:MockSomeInterface = new MockSomeInterface();

  mock.expects('methodWithManyParams').withAnyArgs().willExecute(
    function(boring:String,uninteresting:XML,name:String,address:String,dontCare:Function):void{
      assertNotEquals( "", name );
      assertNotEquals( "", address );
    }
  );

  exerciseSystemUnderTestUsing(mock);
}

Verifying some internal characteristics of an argument:

public function testNameAndAddressAreNotEmpty():void
{
  var mock:MockSomeInterface = new MockSomeInterface();

  mock.expects('someMethod').withAnyArgs().willExecute(
     function(lotsOfXml:XML):void{
      assertEquals( "Dave", lotsOfXml.body.person.firstName );
      assertEquals( "Thomas", lotsOfXml.body.person.lastName );
    }
  );

  exerciseSystemUnderTestUsing(mock);
}

It's interesting to note that willExecute can be used to accomplish two goals. You can use it to control the Indirect Input into the system you're testing (which is what willReturn is also used for, as I touched on above). In addition you can also use it to test the Indirect Outputs of your system. This is what's happening above when assertEquals(...), assertTrue(...) and the like are called from within the attached functions. My personal experience is that something like willExecute tends to be used more often as an ad hoc way of testing Indirect Output than as a way of supplying Indirect Input (which can most time be handled adequately using willReturn). Most of the time I use it to express non-trivial expectations on the input to a method. In a lot of frameworks the need to do this is reduced by the presence of custom argument matchers. These allow you to capture complex expectations on a method's input parameters by implementing classes which you then provide to your mock during the expection setting phase. For examples from other mocking frameworks you could look at jMock and Mockito.

Finally, you may remember I started off describing willExecute above is as a dynamic version of willReturn. In fact, willReturn could be trivially implemented using willExecute:

public function willReturn(object:Object):void{
  willExecute( function():Object{ return object; } );
}

The same is true of the willThrow() feature (which allows a user to ask a mock to throw a specific exception when a method is called).

public function willThrow(error:Error):void{
  willExecute( function():void{ throw error; } );
}

fun with Symbol#to_proc

Wed, 01 Apr 2009 00:00:00 +0000

As I start to get fluent in ruby I often find myself using a more functional programming style, particularly when dealing with collections. That generally leads to lots of little block-centric operations. I recently discovered a really elegant trick to make that code a little nicer.

Let's say there's a Person class:

class Person
    attr_accessor :first_name, :last_name, :age
end

and I have a collection of people which I'd like to sort by age. An obvious approach would be:

people.sort_by{ |person| person.age }

That works, but it is a little wordy. This is ruby, after all! Wouldn't it be nice if we could write this instead:

people.sort_by &:age

Isn't that neat? The magic that makes this work is this little monkey patch to the Symbol class.

class Symbol
  def to_proc
    Proc.new { |*args| args.shift.__send__(self, *args) }
  end
end

Note that this is already done for you in Rails and in Facets - in fact that's where I lifted this code from.

So how does this work? When we called sort_by we passed in the :age symbol, but we used the & to indicate that it should be treated as a block. When you supply a method with a block which isn't a Proc instance ruby helpfully attempts to coerce it into a Proc by calling to_proc. Because of the Symbol monkey patch to_proc now returns a block which will invoke a method with the same name as the symbol itself on whatever object it is passed in. Phew. Re-read that last sentence 5 times. The end result is that the following two blocks are identical:

block_a = :some_method.to_proc
block_b = proc { |x| x.some_method }

It follows that the following two operations are identical:

people.sort_by{ |person| person.age }
people.sort_by &:age

Voila! I should point out here that I'm not exactly the first person to discuss this great trick. See for messirs Thomas and Williams.

In fact, it's such a common idiom that it will apparently be baked right into ruby 1.9.

Liberal Mocks

Mon, 23 Mar 2009 00:00:00 +0000

I've been using mock4as recently as part of a drive to get better test coverage in a flex project. As I used it I noticed a few features which I've seen in other mocking libraries that were missing. I did what any engineer with an itch to scratch might do in such a situation - I started to implementing the features in mock4as that I wanted to use.

One of the things I added was support for a pattern/feature which I'm going to refer to here as 'liberal mocks'. I am not really sure what the right name for this pattern is. I've seen it called 'null object' before, and also 'stubs'. In my opinion both those terms are too overloaded to be used in this context, although the Null Object pattern is very similar to what I'll be describing.

I definitely wouldn't use the word 'stub' in connection to this pattern, although I've seen that done in other mocking libraries. For a start there is already way too much confusion in automated testing between Stubs and Mocks. For the record, my definition of a Stub is pretty close to what's described in the XUnit Test Patterns book (which I highly recommend). It's a Test Double which is used to control indirect input into a system under test, and possibly to record indirect output for later verification. That second part is where my definition differs from Meszaros's - I merge Test Stub and Test Spy together. Anyway, I'd love to hear from anyone who has a better (or more 'correct') name for the pattern I'm describing.

On to the main attraction. A Liberal Mock is a mock which will not fail when it receives an unexpected method. Instead it will silently ignore the method call. Contrast this to a regular, or 'strict' mock. In most mocking libraries a standard mock which receives a method call that was not specified while the mock's expectations were being set will be considered an error, and the mock will not pass verification.

A couple of unit tests from the mock4as library's test suite should help to illustrate this:

public function
testFailsIfUnexpectedMethodCalled():void
{
  var mock:MockSomeInterface = new MockSomeInterface();
  mock.doSomething();
  assertFalse(mock.success());
}

public function
testSuccess_whenUnExpectedMethodCalledOnLiberalMock():void
{
  var mock:MockSomeInterface = new MockSomeInterface();
  mock.isLiberal();
  mock.doSomething();
  assertTrue(mock.errorMessage(), mock.success());
}

That covers the what, now on to the why. The main scenario where I find myself reaching for liberal mocks is when I have a method which uses several features of a dependency, but I'm writing a test which is only interested in certain aspects of that usage. For example, let's say I have a controller object which is responsible for maintaining a view object. The controller has an initialize() method which sets the view's UI elements to some initial state, and I'd like to get that method under test. Now if the view has a lot of UI elements I wouldn't want to test all of the setup in one test. Instead I might want tests like initialize_shouldSetupCampaignDropDownCorrectly(), initialize_shouldSetupDaypartingViewWithModelContents(), etc. If I was mocking the view with a strict mock then every test would need to explicitly set expectations for all the calls which the controller will be making to the view, even if each individual test is only interested in a small subset of those calls. With liberal mocks that requirement is removed. I can essentially say 'this dependency is going to be used in a bunch of ways here, but I'm only concerned with these specific method calls'. The underlying motivation for this is to avoid Fragile Tests. If you're not using liberal mocks and one aspect of your expected behavior changes then suddenly all your tests will fail, not just the test that specifies the behavior that's just changed. Fragile tests seem to be a common risk for new automated testing practitioners, and they can be really demoralizing.

Now, just because you can doesn't always mean you should. I've found that liberal mocks can be a bit of a crutch for a less-than-optimal design. If you find yourself needing to use a lot of liberal mocking then you should consider that to be a design smell. Maybe the method you're testing is doing too much work. If you can break your big method up into smaller methods that are testable then you're in a happier place, in terms of testing and more importantly in terms of design. Alternatively, the issue may be that the dependency which you're mocking out has some huge sprawling interface that should be split into several pieces. After doing that you may find that you only need to set expectations on one of those pieces, and the other parts can be replaced with a true Null Object.

Mon, 01 Jan 0001 00:00:00 +0000

Accelerate your team’s ability to write maintainable, well-tested React and Redux.

In this intensive 2 day course I teach the best practices for creating React/Redux applications which are easy to understand and easy to maintain.

Get in touch to learn more about how your team can start getting more done in less time.

why waste your most precious resource - engineer's time - figuring this out from first principles?

Developers who are new to React and Redux will eventually figure out the patterns and practices that lead to testable apps that are easy to extend, and the gotchas that prevent that. But why waste your most precious resource - engineer’s time - figuring this out from first principles - and creating tech debt along the way?

Get In Touch

Mon, 01 Jan 0001 00:00:00 +0000

You can reach me via

Alternatively, you can simply fill out this form:

Pete Hodgson

Assessing the Latest AI Coding Hotness

Same Model, Different Results: Why Coding Agents Aren't Interchangeable

Claude Code System Prompt

Claude Code Tools

Table of Contents

Task

Description

Parameters

AI Coding: Managing Context

Leading your engineers towards an AI-assisted future

Your CEO Should Not Be Slacking Your Coding Agent

Why Your AI Coding Assistant Keeps Doing It Wrong, and How To Fix It

Product Strategy: a Cheatsheet for Engineering Leaders

Chain-of-Vibes

Vibe-coding 101

Your new AI pair-programmer

Getting AI-powered features past the post-MVP slump

Expand/Contract: making a breaking change without a big bang

Five Minutes to Feature Flags

Hello, world

OpenFeature - a standard for feature flagging

The Feature Flagging iceberg

Explaining Variable

Patterns of cross-team collaboration

Your Platform is a Product

Engineering Values and Architectural Principles

Tech Debt Walls

Building a tech debt wall

Roadtrip!

Service Templates and Service Chassis

Testing a feature-flagged change

Creating and sharing Strategic Architectural Initiatives

Building a Strategic Architectural Initiative

Delivering on an architecture strategy

Hello, production

Story Tests - clear, expressive testing for redux reducers

Testing redux reducers - leveraging selectors

A nice way to test redux reducers and actions - part I

Day-One Deploys

6 Practices for Effective Pull Requests

Mission Command: enabling autonomous software teams

Advice for the Founding Engineer, part 3

Continuous Delivery for Static Sites

The rise of the static site

Advice for the Founding Engineer, part 2

Advice for the Founding Engineer, part 1

The JS testing ecosystem needs a standard matcher library

Matchers when making assertions

Articles & Talks

Articles

The Symbol-Keyed State Accessor pattern

DIY stir plate for homebrew yeast starters

The Ultimate Traveler's Coffee Kit

video for my different.js talk

optimizing 3rd party JavaScript loading

Rails as an SOA Client

the 5 rules of an awesome dev toolchain

Microstatic: radically simple static microsites

Assertions in Page Objects

introducing rack-flags

iOS Unit Testing Workshop

Using Travis CI and xctool to build and test iOS apps

Test-driven Backbone.js - Part Three

Controllers in a Backbone app

Test-driven Backbone.js - Part One

Setup

Test-driven Backbone.js - Part Two

Deploying to Heroku from CI - the gory details

Deploying to Heroku from CI

Heroku as a staging environment

Writing iOS acceptance tests using Kiwi

What?

Cookie-based feature flag overrides

Introduction

Frank with CocoaPods

A Frank field trip

Problem the first

Towards Frank 1.0

Introducing PublicAutomation