Pete Hodgson

In the previous posts in this series we’ve done some test-driven development of Backbone Models, Collections, and Views.

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 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.

In my previous post I discussed why you might want to deploy to Heroku as part of a CI build.

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.

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.

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.

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.

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.

I’m excited to announce PublicAutomation, a friendly wrapper around Apple’s private UIAutomation framework.

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.

I spent a fun evening recently setting up a deployment pipeline for this blog.

Frank is a tool that allows you to run automated acceptance tests against your native iOS application.

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.

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.

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.

Software designs don’t pop into existance fully formed.

On a recent project we were applying Continous Delivery practices and were releasing to production reasonably frequently - sometimes multiple times a week.

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

It seems that every javascript framework of a certain size is compelled to implement some kind of pseudo-classical type system.

Intro We’ve been building mobile web apps using JQuery Mobile with the main target being webkit-based mobile browsers - Android and iPhone, basically.

One of the interesting aspects of Javascript development is its asynchronous, event-driven nature.

The Background For a recent project retrospective we wanted to chart some metrics over the course of the entire project.

What's Symbiote?

I maintain Frank, a tool which lets you write automated acceptance tests for your iOS app using Cucumber.

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.

I just published a new Ruby gem called timestamped-scenarios.

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.

In my last post I talked about memory leaks in Objective C.

I would say that the steepest learning curve for someone new to iOS development is having to manage your own memory using reference counting.

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.

Recently I joined a team developing an iPad application.

In my experience good TDD designs tend to have evolved (and hopefully continue to evolve) in a sort of punctuated equilibrium.

Generating HTML tables in ruby has always seemed like more of a hassle than it should be.

Hipster geeks crack me up.

I just threw together a really straightforward stopwatch class, for use when profiling operations in ActionScript code.

I listened to a really good podcast yesterday on Kanban.

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.

When developing the presentation layer in a Flex application I like to follow an MVC/MVP pattern.

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.

I've been using git for a few months now.

I've always found it a slightly hard to read ruby which uses Enumerable#include?

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

Today I had the great pleasure of deleting a huge chunk of old code from my application.

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

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

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

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".

As I mentioned in a previous post I've recently been adding some features to mock4as, a mocking library for ActionScript.

As I start to get fluent in ruby I often find myself using a more functional programming style, particularly when dealing with collections.