I was very fortunate to be able to speak at the inaugural Dutch Mobile Conference in 2012, and I am delighted to be asked to return to speak once more. This year I am going to be tackling the subject of Behaviour-Driven Development. BDD has been a subject that has found itself at home at many a PHP and Ruby conference in recent years. However it has been noticeably absent from the mobile gatherings. Very conscious of this, I have decided it is time to bring testing to the forefront of mobile development.

The talk I intend to deliver (Ed: yes it’s still being written) will begin by explaining why BDD is so fundamentally important to software engineers, testers and business owners. This will give me the chance to introduce the uninitiated to the Gherkin domain-specific language for expressing behaviour, usually run by the Cucumber testing running framework. Once everyone is comfortable with Gherkin, I will switch my attention to delivering a mythical iOS application that has been defined in Gherkin. We will watch the tests fail inside of Calabash-Cucumber and then implement the logic to make them pass until finally, we have created a fully functioning awesome iOS application.

The talk is designed to be accessible for people of all levels of knowledge of BDD, Cucumber and Calabash. It is being constructed to be very demonstration driven, with live code and test examples throughout. All code will be available for people to try themselves from Github after the presentation.

To help explain the problem, consider this simple example.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

module Authenticate
  module Context
    class Email

      def initialize(user_repository, secret_hashing_policy)
        @user_repository = user_repository
        @secret_hashing_policy = secret_hashing_policy
      end

      def execute(email, secret)
        authentic = false
        user = @user_repository.find_by_email(email)

        if user
          authentic = user.secret.eql?(@secret_hashing_policy.hash(secret))
        end

        return authentic
      end
    end
  end
end

Here we have a simple context that authenticates credentials based on the supplied email and secret. The context has two dependencies, as shown in Fig.1;

1. A user repository that provides access user data
2. A hashing policy that governs how secrets are hashed before storage

Both of these dependencies are passed into the context during construction. The context provides a single execute method that tests the users authenticity based on the user identifier and secret provided.

This use case as it stands is doing its job very well. Additionally it is adhering to the single responsibility principle, as it only concerns itself with establishing the authenticity of the credentials supplied. It isn’t concerned with loading user data or how to correctly hash a secret.

Later on, the business owner walks over and asks to have insight into the number of authentications occurring;

When a user authenticates, the business must record the authentication data into our statistics data warehouse. We want to know who was authenticating and the result of their attempt.

She wants to capture this data in another statistics repository owned by the Data Warehouse team. Given the data our business owner wants is related to authentications, it seems a simple requirement to fulfil.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

module Authenticate
  module Context
    class Email

      def initialize(user_repository, secret_hashing_policy, stats_repository)
        @user_repository = user_repository
        @secret_hashing_policy = secret_hashing_policy
        @stats_repository = stats_repository
      end

      def execute(email, secret)
        authentic = false
        user = @user_repository.find_by_email(email)

        if user
          authentic = user.secret.eql?(@secret_hashing_policy.hash(secret))
        end

        @stats_repository.register_entry(email, authentic)

        return authentic
      end
    end
  end
end

Fulfilling the requirement to provide authentication statistics to the business has grown the authentication context slightly. As it now authenticates and updates statistics, you could argue that it has begun to violate the single responsibility principle. I would certainly agree with your argument if you were to make it. But given the scope of this change, most developers could probably live with that slight violation at this point.

A few days later, the business owner returns to ask for another great idea.

When a user fails to authenticate, they should receive an email notification instructing them on how to access the service.

Now we could just go back and modify the use case to include a mailer and the context would grow further. We are definitely going to violate the single responsibility principle now, as we are authenticating credentials and performing other notification tasks. A another approach would be to create an additional use case for authenticating credentials and notifying various parties. This use case would be a composite of the Authenticate::Context::Email context and two others. It would certainly be cleaner than trying to overload the existing use case with all these extra responsibilities. However, either solution starts introducing dependencies that authentication should not have.

Fig.2 demonstrates that authenticating a set of credentials now requires a lot of knowledge about other unrelated parts of the system. The simple act of authentication has become confused by the other requirements that have been made.

At this point we should pause for a second and consider the problem again. What we really want to do is authenticate some credentials and then tell the system we are done authenticating. The system can then respond to the message from the authenticate context without having to provide knowledge of the intended behaviour.

We would like is the authentication context to execute and return a boolean value as it does now. Additionally, we want it to notify observers that is finished. The context would still require one additional dependency for notifying, but that would be it. The business owner could provide additional requirements in future for what should happen when authentication succeeds or fails, and the existing authentication context would not have to be altered.

Lets go back to our original implementation of Authenticate::Context::Email and add a basic concept of a notifier.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

module Authenticate
  module Context
    class Email

      AUTHENTICATION_NOTIFICATION = 'authenticate::context::email::complete'

      def initialize(user_repository, secret_hashing_policy, notifier)
        @user_repository = user_repository
        @secret_hashing_policy = secret_hashing_policy
        @notifier = notifier
      end

      def execute(email, secret)
        authentic = false
        user = @user_repository.find_by_email(email)

        if user
          authentic = user.secret.eql?(@secret_hashing_policy.hash(secret))
        end

        @notifier.publish(AUTHENTICATION_NOTIFICATION, {
          'authentic' => authentic,
          'email' => email
        })

        return credentials_are_authentic
      end
    end
  end
end

Now we have introduced one additional dependency to the original two we defined. The notifier must be passed in, along with the user repository and hashing policy. But the notifier is the only additional dependency we will need. Now we can go and change the implementation of our statistics reporter and account access notifier to listen to the authenticate::context::email::complete notification coming from the notifier and perform their actions accordingly.

This implementation also does something interesting to the dependencies. Notice that Authenticate::Context::Email depends on the Notifier, but no longer depends on Authenticate::Stats or Message::AccountAccess. Instead, Authenticate::Stats and Message::AccountAccess depend on Notifier. The result is that Authenticate::Context::Email no longer has any knowledge of Authenticate::Stats or Message::AccountAccess and vice versa. We have inverted the dependencies and introduced a solid boundary between our authentication use case and other parties that need to know about authentication notifications but are not part of that domain.

The Notifier part of this implementation is currently an abstract concept. After looking around the Ruby world for an existing solution, we ended up devising and building a new observer pattern framework called Arbiter.

Introducing Arbiter

Arbiter is a simple notification framework. It provides a lightweight notification protocol that can be used across any Ruby application. Simply put, Arbiter is our solution to the Notifier class in the earlier example. There are only two component parts to Arbiter, the Arbiter and the Eventer. The Arbiter observes notifications and executes business logic associated with those notices.

The Eventer is the interface to post notices for observation. The Eventer consists of a transport (Eventer.bus) provided by the Arbiter and the Eventer.post() class method.

The Arbiter provides the transport for notifications posted by the Eventer. The Arbiter intercepts notifications on the transport and passes them to observers that register to a particular event. Registration of observers is done using the Arbiter.add_listener() class method.

Any class can observe notifications from Arbiter, provided it conforms to the Arbiter protocol by implementing the following methods;

• notify(message_name, args), called by Arbiter whenever it receives a notification that the observer is interested in.
• subscribe_to(), used by Arbiter to establish the notifications that want to be observed. This method should return an array of notification names.

This is all that is required to begin observing notifications with Arbiter. Did I mention it was simple?

Example

Revisiting the earlier example of an authentication context, now we will implement the context and the observers using the Arbiter framework.

First of all we need to decide on a transport for Arbiter to use. Given we want to keep this solution simple for the time being, lets use the standard Arbiter transport which uses an in-process execution model. To configure this, we’ll setup the Eventer.bus in a configuration for the application.

1
2
3
4

require 'eventer'
require 'arbiter'

Eventer.bus = Arbiter

The configuration file sets up Eventer to use the basic Arbiter as the transport, referred to as the bus. With this we can write the observers.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

require 'stats/repository'

module Stats
  class Observer

    def initialize(stats_repository)
      @stats_repository = stats_repository
    end

    def subscribe_to()
      return [:authenticate]
    end

    def notify(message_name, args)
      @stats_repository.register_entry(args['email'], args['authentic'])
    end

  end
end

This observer provides the same functionality for recording authentications as implemented earlier. The actual recording of statistics is now completed within the observers notify() method.

We can use the same pattern for the observer that is responsible for the account access email message when authentication fails.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

module Message
  module Authentication
    class Observer

      def initialize(message_manager)
        @message_manager = message_manager
      end

      def subscribe_to()
        return [:authenticate]
      end

      def notify(message_name, args)
        @message_manager.send_reaccess_account(args['email']) if (args['authentic'] == false)
    end

  end
end

Now we have our two observers configured and ready to receive messages, lets update the original Authenticate::Context::Email context to use Arbiter.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

module Authenticate
  module Context
    class Email

      def initialize(user_repository, secret_hashing_policy, eventer)
        @user_repository = user_repository
        @secret_hashing_policy = secret_hashing_policy
        @eventer = eventer
      end

      def execute(email, secret)
        authentic = false
        user = @user_repository.find_by_email(email)

        if user
          authentic = user.secret.eql?(@secret_hashing_policy.hash(secret))
        end

        @eventer.post(:authenticate, {
          'authentic' => authentic,
          'email' => email
        })

        return credentials_are_authentic
      end
    end
  end
end

Our context is now using the Arbiter Eventer to post the :authenticate notification to the transport. We are almost ready to go, but there is a problem. Right now we are publishing our notifications correctly and have two observers ready to observe. But they are not going to observe anything yet as they have not been registered to the Arbiter. To do this we will need to tell the Arbiter that Stats::Observer and Message::Authentication::Observer want to listen to notifications. Where you do this in your application will depend on its structure. But for the sake of simplicity lets set up these observers in the eventer.rb configuration file we defined earlier.

1
2
3
4
5
6
7
8
9

require 'eventer'
require 'arbiter'
require 'lib/stats/observer'
require 'lib/message/authentication/observer'
require 'factory'

Eventer.bus = Arbiter

Arbiter.set_listeners([Stats::Observer.new(Factory.stats_repo), Message::Authentication::Observer.new(Factory.message_manager)])

We have successfully implemented the Arbiter framework to replace our Notifier abstraction used earlier. As a result the authentication use case is now maintaining its single responsibility of authenticating credentials and the two observers we wrote handle the recording of statistics and any other messages as a result of the authentication process.

Notifications beyond the process boundary

The example above uses Arbiter to send notifications in-process to observers. However there are times where there are concurrent processes operating with observers interested in a particular topic.

For example, a main application handles user requests, while a second process is devoted to statistical analysis and a third is devoted to messaging users. The primary process will be publishing notifications and the other two processes want to listen to those notifications. In these cases the Arbiter example shown above will not work.

Having also encountered this problem, we have created two additional Arbiter implementations to allow for concurrent process observations.

1. ResqueArbiter uses the Resque framework as the Eventer.bus
2. ZeromqArbiter uses the ZeroMQ (ØMQ) messaging protocol as the Eventer.bus. This Arbiter transport provides the most flexibility, but can be the most complex to use.

It is possible to use any transport for notifications, as long as you can provide the Arbiter implementation to handle the registering of observers and delivery of messages. However be aware that thread safety and other concurrent concerns still apply when using Arbiter across processes.

Obtaining and using Arbiter

We welcome and encourage everyone to use and improve this lightweight notification framework. Please fork and pull to your delight.

Arbiter is now released as an open source library available on GitHub and pre-packaged as a Ruby Gem. Arbiter is licensed under the ISC License.

Arbiter is maintained by the awesome Sittercity development team and was written by Robert Grider (@mrerrormessage) and Jeremy Bush (@zombor), based on a concept by Robert Grider and myself.

For the uninitiated, ZeroMQ provides a simple way to pass messages between processes, whether they are local or remote. It can use TCP, UDP, inproc, multicast and several other protocols as the transport mechanism. In the past I have heard ZeroMQ (or ØMQ from now on) referred to as a “sockets framework”. Although this doesn’t capture the entirety of what ØMQ is, it does provide a nice metaphor for my particular use case.

The project that required ØMQ in this instance was a proof of concept for another project I am currently engaged in. The application in question requires two iOS devices to communicate with each other in realtime across a network. ØMQ provides the communication layer, coupled with Apple’s Bonjour zero config network discovery protocol. As ØMQ is a C based library, integrating it with an iOS project should require relatively little effort. Obtain the libzmq source, compile and add to the Xcode project. But as it turned out, producing a static library for iOS development took some additional effort.

Because Apple provide an iOS simulator for development rather than a more useful iOS emulator, any static library must be compiled for the simulator and then again for iOS devices. When an iOS application runs in the simulator, it is using the x86 (or i386) instruction set; iOS applications are not 64-bit, yet. However all iOS devices use an ARM based CPU of some description, requiring different instructions from their x86 cousins. Apple currently support two ARM architectures, named armv7 for iPhone 4/4S plus the iPad 2 and 3. And armv7s for iPhone 5 and the new iPad 4 (retina display)^{[1] [2]}. Due to this, my project requires ØMQ support for the i386, armv7 and armv7s architecture. It is possible to compile the ØMQ static library three times, add them all to the project and only link to the correct version at compile time. But this can be fiddly, especially when dealing with two almost identical architectures such as armv7 and armv7s.

Fortunately Apple have encountered this multiple architecture problem in their recent past, when moving from the PowerPC to the current x86/x86_64 architecture. Apple wanted to ensure the transitional period was as smooth as possible for their users. So they created the concept of the universal binary, which they imaginatively named a “Universal Application”. To the end user, they could execute the same application on their existing PowerPC powered iMac G5 or a shiny new Intel powered MacBook Pro without issue. However, this apparently magical execution of the same code on two different CPU architectures was nothing more than a cheap parlour trick. In reality a universal binary is a single resource that encapsulates the compiled code for two or more CPU architectures. Although the PowerPC to Intel transition was completed many years ago, the tools to produce these universal binaries remain. Only today iOS developers are combining x86 with ARM instructions.

It is worthwhile to note that universal libraries are also referred to as “fat” libraries, because they are larger than their single architecture counterparts. The overall iOS application size is a factor in how they can be downloaded to the device. Applications weighing in at over 20 megabytes will require a wifi connection to be downloaded, and all applications must be less than two gigabytes. Although the two gigabyte ceiling is unlikely to be a problem due to a fat library, the 20 megabyte limit could cause a concern. If size is a factor for your application then it is probably worthwhile to only include the correct library for the target architecture. I’ll touch on this briefly a bit later.

The ØMQ page describing how to build libzmq for iOS details the cross-compiling process. This is fine for creating an armv7 static library from an Intel powered Mac. But as discussed earlier, this library would not be usable by the iOS simulator. I require a universal static library for libzmq that can execute on all of the required architectures.

The process of creating a universal static library for libzmq is conceptually straight forward, but as it turns out it is quite cumbersome. In theory, all that is required is to compile the libzmq library for i386, armv7 and armv7s and then glue them together into the universal binary. Compiling the binary for ARM requires cross-compiling using a version of GCC with instructions for that CPU. All Mac systems with Xcode installed contain the ARM version of the compiler. The only challenge is figuring out the correct compile flags to set to ensure the right binary is produced.

To save a lot of time I automated the process into a single bash script. I have placed this script on Github for anyone who requires it; available from https://github.com/samsoir/libzmq-ios-universal. It is licensed under the open source ISC license, so modifications and extensions are welcome. For those not willing to look at the source, the script performs the following operations.

1. Compiles a libzmq static library for the armv7, armv7s and i386 architectures^[3].
2. A tool called lipo is used to perform the gluing of the three libraries into a single universal static library.
3. The header files for the library are copied into the universal folder.
4. Finally the script tidies up after itself and then provides instructions on what to do next.

Once the script has finished executing successfully, there will be four versions of the libzmq library. One version for each architecture, and of course the universal version. The individual architecture versions of libzmq remain so that you can use them in place of the universal version if application size is an issue.

The current project on Github is work in progress. It mostly supports my specific requirements at this time. If you try it and it does not work as designed for you, please do tell me or create a pull request. I do intend to add features and more support over time.

Tutorial

To use the libzmq-ios-universal compilation script, you will require a Mac with OS X Snow Lion with Xcode 4.3.3 or later installed. Additionally, Automake is also required. I used Homebrew to obtain Automake in this tutorial, but you can also download and compile it yourself if you do not have, or want to have, Homebrew installed.

First of all, if you have not done so already, install Automake using Homebrew. Or build manually if preferred

In a terminal type;

1

brew install automake

To verify whether automake is successfully installed;

1

automake --version

This should produce output similar to what is shown below. If automake is not found try reinstalling.

1
2
3
4
5
6
7
8

automake (GNU automake) 1.12.3
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl-2.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Tom Tromey <tromey@redhat.com>
       and Alexandre Duret-Lutz <adl@gnu.org>.

With Automake installed and available, it is time to get the compilation script and the libzmq source code. Start by cloning the libzmq-ios-universal project from Github. Change directory to a suitable location

1

clone https://github.com/samsoir/libzmq-ios-universal.git

Once the clone operation is completed, cd libzmq-ios-universal so that the next step downloads into the project folder.

Now download and untar the latest stable build of libzmq from the ZeroMQ download page. At the time of writing this is version 3.2.2.

1

wget http://download.zeromq.org/zeromq-3.2.2.tar.gz && tar xfz zeromq-3.2.2.tar.gz

If everything is fine up until now, we are ready to begin compiling libzmq for iOS. To begin the process type;

1

./compile_libzmq_ios_universal

A successful compilation will result in the following output;

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Initializing build directory...
Initializing dependency directory...
Compiling libzmq for armv7...
Compiling libzmq for armv7s...
Compiling libzmq for i386...
Creating universal static library for armv7, armv7s and i386
Copying libzmq headers into universal library...
Tidying up...
Finished compiling libzmq as a static library for iOS.

Universal library can be found in build/universal;
  "lib" folder contains "libzmq.a" static library
  "include" folder contains headers

To use in your project follow linking instructions
available on the iOS zeromq page
http://www.zeromq.org/build:iphone

Note that in the unfortunate event that something goes wrong during the compilation, the root cause may not be immediately apparent. However the last command executed places all of its output into a file called build/build.log relative to the current path. The cause of the issue should be apparent within that file.

Assuming everything is fine, it is now possible to add the new universal static library to Xcode.

Change the directory to your Xcode project, for example;

1

cd ~/Projects/<project name>

I like to keep my external libraries in their own directory. So I create a directory called “lib” within the project to keep them in.

1
2

mkdir -p <project name>/lib && open <project name>
cp /<path>/<to>/<libzmq>/build/universal <project name>/lib/libzmq

This will result in a new directory named lib created within the MyZMQProject code base directory. Within that folder with be a libzmq folder containing the static library and headers. Xcode will nest the directories like this to keep separate targets apart within a project. Finally the command will open a Finder window at ./MyZMQProject allowing you to see the lib folder.

Ensure your Xcode project is open within Xcode and then drag the lib folder from Finder into the correct (and corresponding location) within Xcode. A dialog will appear asking how you want to add the folder to the project.

Once you select “Finish” the lib folder will be added to your project.

Before you can start using the library you need to update your projects settings to link the library to your project at compile time, and include the headers in the search path.

Within the main target of your project, filter the Build Settings to only show items including “Search Path”. Then update Header Search Paths section to include your newly created lib folder. Add ${SRCROOT}/<project name>/lib/** to the list and hit return. The double-star means search recursively through sub folders.

Xcode 4.5 automatically adds the correct path for libzmq to the Library Search Paths entry. However if this hasn’t been added for you, the same entry that was added for Header Search Paths will work here.

Finally ensure you add the standard C++ library to the Other Linker Flags section of the Build Settings. Add -lstdc++ to the list if it is not already present.

At this point you are ready to start using libzmq in your code. To use the ØMQ C library within your code, import the zmq.h header in any location where you require it. Libzmq will now run in the simulator or on a device without modification.

Footnotes

1. As the name implies, armv7 instructions can be executed on armv7s architectures, but the reverse is not true. The armv7s architecture provides additional instructions that provide faster execution of code over armv7, so it is worth supporting it when possible.

2. Anyone that is put off by this, it is worth mentioning that there is an Objective C higher level wrapper in existence.

3. I decided not to support armv6 at this point. It may be added in in future if demand shows it is worthwhile. Or there is a pull request.

This week I attended the WindyCityGo, Chicago’s mobile developers conference. WindyCityGo is in its second year and like musicians second album, it was potentially a tricky one. Chicago’s tech scene is currently enjoying massive growth, no doubt helped by the success of locally based popular internet brands Threadless, 37signals, Orbitz, Career Builder and not forgetting Groupon. Recently many local startup companies have also been making a big name for themselves as well such as Peapod, GrubHub, Braintree and my employer Sittercity. With this in mind I expected a massive turnout for the WindyCityGo conference, so I was rather surprised to discover that this conference was a very intimate affair.

The conference was hosted at the Groupon headquarters, providing a rather cosy environment for proceedings. The lecture room chosen was probably not the most suitable for a conference of this nature. However the free wifi did provide a great service and didn’t drop once in the two days, which was a refreshing change from most conferences. However, the room felt slightly awkward. Three large displays provided the slide presentations, one large plasma at the front flanked by two attached to pillars. Speaking of the pillars, they were bulky and spread throughout the room such that if you got caught behind one it hid the speaker completely. These details are only small negative points against the venue, but they did start to add up. Given that Groupon were also the platinum sponsor it did all feel a little bit too convenient. However, none of these details would stop the conference from commencing, and it did so with real gusto.

The first day started with a session from The Second City, Chicago Improv players, lead by Cody Dove. The Second City group are famous for launching the careers of John Belushi, Bill Murray, Mike Myers, Dan Aykroyd, Steve Carell and Stephen Colbert among many many others. Needless to say the players for the conference weren’t any of the above, but they were excellent nonetheless. The session started with an improvised sketch with all four players creating a short sketch whilst pausing for amusing input from the audience. This then lead into another four activities all requiring audience participation in one form or another. It was very energetic and more importantly fun. Once the players had finished, the audience was awake, alert and ready to learn. This was a novel and inspired way to kick things off and I tip my hat to the organisers. Not since Aral Balkan’s opening performance at Update Conference 2011 has such an introduction been so entertaining. Everyone was now ready for some technical talks.

First up was a talk on Painless Localization from Whitney Young of FadingRed, the creators of the Mac personal finance application Koku. Localization is often an overlooked aspect of mobile and desktop development, but vitally important in these competitive markets if you want to reach the broadest possible audience. Whitney provided some analysis of global language distribution to re-enforce his argument. It was fascinating to witness that the proportion of English as a first language speakers is relatively small on a global scale. However, a large proportion of the worlds population would use a computer within the english localization. The talk then went on to explain how you localize projects in Cocoa, which was nice to see as I’m currently in the process of doing this myself. Localization is not trivial on any platform and you can see why in some cases developers choose to ignore it completely. This puts localization right up there with accessibility in this respect.

To ease the pain and make life easier for FadingRed localizing their applications, they created a tool called Greenwich. Greenwhich is a Cocoa framework that provides a great solution to the localization problem, enabling the users of the application to provide the translations. Whitney explained that before Greenwich was created, their end users would email them translations for their applications. So it was clear there was a hunger for user-created translations. Crowd sourcing localization obviously has some risks, but Greenwich provides some additional tooling to sanity check the provided translations. The real power of Greenwich is the instant feedback mechanism, allowing translations to be examined in the app immediately, without having to recompile the binary. Greenwhich looks like a great project and one I’ll be watching closely. If you’re building Cocoa apps for desktop or mobile, I suggest you checkout Greenwich.

Following Whitney was David Kinney presenting iOS Application and Data Security. This talk provided some deep insight to some of the security issues that plague iOS, though in reality Android suffers the same vulnerabilities. The talk started with a general look at iOS security model;

• Device Security via pass code or pin code
• Data Security via encryption and keychain
• Network Security via SSL/TLS and VPN
• Application Security via code signing and sandboxing

First off David criticised people who protect their iOS devices using just the four digit pin code. The pin code protection provides ten-thousand possible variations, which is a lot for a person to go through. However software can defeat this in under two minutes. iOS does provide a string based pass code as an alternate method of securing the device and David recommended using that with a strong password. Personally I feel that if your device is stolen then you’re screwed anyway. Modern hardware can process around three billion passwords per second. At that rate a password that a human can also recite will be broken in a reasonable amount of time.

Given the device is not safe, the next subject of Data Security was apt. If the device is not safe, then data must be made secure. David went into to detail about the OS security features, pointing out the flaws with using Keychain. Keychain is only as secure as the device. So if sensitive data is being stored then it is best to encrypt it using a custom method using the CommonCrypto library. David went into more detail covering the preferred encryption algorithms to use such as AES and TripleDES, touching briefly on Password Based Key Derivation Function v2. Overall David’s talk was highly informative and gave a great overview of the security pitfalls of developing for devices in general.

Next up was Eric Meyer from 8th Light presenting a talk on how to test code properly in Cocoa. This is the subject matter that I was most interested in seeing today and Eric did not disappoint. I have had the pleasure of briefly working with Eric so I was sure this would be an informative session. The session took the form of a brief introduction to the two tools Eric would be using, ObjectiveCSlim and OCDSpec. ObjectiveCSlim is an Objective C implementation of the Fitness wiki based acceptance test framework. OCDSpec is an implementation of RSpec (or PHPSpec) in Objective C.

With the introduction to the tools complete, Eric switched into live demonstration mode. Using the board game Mastermind as the use case, Eric demonstrated how to build the ObjectiveCSlim and OCDSpec tests and then implement code against them. Of course this is classic test driven development. Unfortunately there is not a lot to say, other than ObjectiveCSlim looks like it is a great tool for acceptance test verification. OCDSpec is also an interesting tool, although it is very verbose (even awkward) when compared to the implementation in its dynamic language cousins. But this is small criticism. Anyone writing Objective C would be used to this level of verbosity. Eric’s presentation was competent and bar a few minor live demo issues, was delivered without issue. I must give Eric bonus points for doing a live demonstration.

After lunch Jason Van Lue kicked off things with his talk on the mobile design process. This session was aimed squarely at web designers for all devices. The talk provided a walk through some best and worst practices of modern web design, touching on the differences between adaptive and responsive web design. As an aside, it is nice to see responsive design being talked about at conferences right now. Just as progressive enhancement was important in the last decade, responsive design is important in this one. In reality progressive enhancement and graceful degradation sit comfortably with responsive design. They are all members of the same discipline, the web as one platform for all.

Jason’s talk was very well delivered and equally well received. I must be honest that I didn’t learn very much myself, but I’ve spent a lot of time researching this subject matter. I imagine everyone watching who wasn’t aware of these deign concepts benefitted from Jason’s talk.

After a break the subject matter returned to the technical. Chris Anderson presented a talk on the CouchDB backed datastore, CouchBase. CouchBase is basically a set of existing open source technologies woven together into a new product that resembles a document-store-come-memory-cache with a multitude of interfaces. Out of the box CouchBase has a RESTful HTTP and Memcache compatible interfaces for remote access, as well client libraries for C, Java, .NET, Ruby, Python and PHP. Chris provided a broad overview of how CouchBase builds upon CouchDB and Memcache to provide a highly scalable and resilient datastore.

At this point another related project called TouchDB was introduced. TouchDB is an iOS datastore that is sync compatible with CouchDB, and by extension CouchBase. TouchDB basically provides the same data abstraction as Apple’s CoreData, but using an open source implementation. This was all very intriguing, but I was beginning to wonder why I would use TouchDB over CoreData? The next subject covered categorically answered this question.

CouchBase Mobile Syncpoint is a new sync service (currently in beta) for CouchBase and TouchDB. CouchBase Mobile Syncpoint effectively provides an open source iCloud implementation. However unlike iCloud, multi-tenant synchronisation does not have to be limited to one user account. This potentially allows for some new, and until now impossible, synchronisation models.

There was a lot of information delivered by Chris over his 40 minutes, but little technical detail. At times it felt a little too light on technical details, but I guess this was a symptom of the number of subjects being introduced. The talk has certainly inspired me to look at CouchBase Mobile Syncpoint in more detail.

The last talk of the day came from Eduardo Scoz on the subject of QuickDialog. QuickDialog is an iOS framework designed to make dialogs simple. Eduardo started his presentation exclaiming that the UIKit framework was great, but when it came to dialogs it found itself wanting. I tend to agree with this opinion. As a result most people ,including this author, use a UITableView to build custom forms.

QuickDialog aims to simplify this process, providing a framework that uses JSON documents to describe the dialog required. Once the JSON has been defined, the QuickDialog framework builds the UITableView with all the necessary controls. Additionally QuickDialog binds data between the view inputs and the model, so an update in either one will result in the other being updated. It was a great talk by Eduardo delivered with some excellent live demonstrations. I will certainly look into this framework in more detail.

After a long day of excellent talks I was ready for home. I decided to forego the after party and head straight home to start playing with some of the tools mentioned. Overall day was full of very insightful talks aimed at the iOS platform. The next day would be split between Android and Windows Mobile. The few negative factors mentioned at the beginning of this post did dampen the experience slightly, but the quality of the talks so far was helping to compensate for those minor issues. Given a better venue, this conference would have been excellent.

Recently my team were using PhoneGap, the HTML5 middleware that enables web developers to write mobile apps once using technologies they know; HTML5, CSS and Javascript. The completed PhoneGap/HTML5 application is then compiled into binaries for each of the supported mobile platforms. The idea is simple, developers write code once and deploy many times. PhoneGap can certainly be used for creating simple applications, but stray from the core API and you quickly find yourself either writing a native extension; or more likely finding a plugin that does the task for you.

As part of a research project for my employer we were writing a mobile application using the PhoneGap platform. The application in question was a relatively simple concept, however it quickly became apparent we would have to go outside of the core API.

PhoneGap does not provide a standard way to create a date picker, instead delegating the vast majority of interface responsibilities to the application and/or framework chosen to author the application. In our case we were using JQuery Mobile for the application user interface. There are others available, Sencha Touch being another popular one from the creators of ExtJS.

Date input is a potentially complex operation on a mobile device. There are many components to a full date and making the user type it in is hardly the optimum interface. Of course there are many web forms that expect the user to do just that. But in the mobile context, there is a chance the operator will only be using one hand to interact with the device, so making them use a complex input control, such as a keyboard, would instantly have a negative effect on their experience.

Presenting the standard JQuery Mobile Datepicker or similar will equally frustrate the user. The JQuery Mobile Datepicker component is awful, but hardly the most efficient design. Also, PhoneGap gives the user the impression the app they are using is a native app, so they will most likely expect a native control in this situation. We could use an iOS DatePicker implementation in Javascript such as Cubiq’s Spinning Wheel Plugin to present a picker in the PhoneGap. But this ensures the picker will use an iOS interface even when used on an Android, Windows Mobile or one of the two remaining Blackberry devices. Another great way to ruin the user experience is to start presenting unfamiliar controls.

Luckily modern mobile operating systems have solved this problem by supplying a native Datepicker control. Using the native Datepicker control on each platform requires a native PhoneGap extension. Naturally the first thing to do is look for an existing solution to this problem within the PhoneGap ecosystem. A quick search revealed that Datepicker extensions do exist for PhoneGap on iOS and Android. After downloading the extension and plugging it into our PhoneGap application, the extension worked… but unfortunately it would only work the one time.

The application would display the UIDatePicker as expected, allowing the user to select a date and dismiss the action sheet. However when the date picker was summoned subsequently, it would not respond to the user input and the date selected was not returned to the application. It was time to look at the source code to see if there was anything obvious going wrong. The source quickly revealed some issues that required urgent attention.

Memory management

First off there are some basic Objective C memory management violations within the DatePicker extension. The DatePicker.h header file defines @property (nonatomic, retain) UIDatePicker *datePicker; accessor method. Using this accessor for assignment will increment the reference count of the UIDatePicker object passed to it by one. If we examine the following code, we can see how the accessor is used within the DatePicker implementation.

1

self.datePicker = [[UIDatePicker alloc] initWithFrame:pickerFrame];

The alloc method will allocate memory for the UIDatePicker object and increment the retain count by one. Assigning the resulting object to the datePicker instance variable via the accessor will increment the retain count a second time. Later in the implementation the datePicker property is released, decreasing the retain count. It is now 1 for those still counting. An object with a retain count greater that zero will be retained by the autorelease pool.

Memory management in Objective C is a vital concept to understand if you are going to write code any code. Even if you intend to use the new Automatic Reference Counting features provided by Clang, I believe it’s imperative to understand the fundamentals of memory management. I am not using ARC at the moment and do not intend to any time soon, the reasons behind this decision are probably worthy of another blog post at some other time. However there are three simple rules within the Objective C language for managing memory that, when followed, will see you good in the vast majority of situations;

When creating a new object using either the;

1. [alloc]
2. [new]
3. [copy] or derivatives, such as [mutableCopy]

methods, then you are responsible for releasing that object when you are finished with it.

The result of this oversight within the PhoneGap DatePicker extension is that the UIDatePicker object created in the code block shown above is never released, creating a memory leak. If there was only ever one instance of the UIDatePicker object then this would not be so much of an issue, although all memory leaks are bad. One leaking date picker is not going to consume vast amounts of memory. But this situation gets worse.

Further inspection

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

datePickerSheet = [[UIActionSheet alloc] initWithTitle:nil delegate:nil cancelButtonTitle:nil destructiveButtonTitle:nil otherButtonTitles:nil];

[datePickerSheet setActionSheetStyle:UIActionSheetStyleBlackTranslucent];

CGRect pickerFrame = CGRectMake(0, 40, 0, 0);

self.datePicker = [[UIDatePicker alloc] initWithFrame:pickerFrame];
bool allowOldDates = ([[options objectForKey:@"allowOldDates"] intValue] == 1)?YES:NO;
if (!allowOldDates) {
  self.datePicker.minimumDate = [NSDate date];
}
if ([mode isEqualToString:@"date"]) {
  self.datePicker.datePickerMode = UIDatePickerModeDate;

  NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
  [dateFormatter setTimeZone:[NSTimeZone defaultTimeZone]];
  [dateFormatter setDateFormat:@"MM/dd/yyyy"];
  NSDate *date = [dateFormatter dateFromString:dateString];
  [dateFormatter release];
  self.datePicker.date = date;
}
else if ([mode isEqualToString:@"time"])
  self.datePicker.datePickerMode = UIDatePickerModeTime;

[datePickerSheet addSubview:self.datePicker];

The code block above presents an abstract from the DatePicker show:withDict: method. This is the Objective C method the PhoneGap Javascript plugin is bound to. Each time a HTML control is selected that invokes the show:withDict: method, the code above is executed.

To provide some context, PhoneGap plugins in Objective C are lazily instantiated, thus loaded into memory only when they are first called. This is quite a nice feature. However PhoneGap relies on the extension code playing nicely and tiding up after itself when it is finished working, or if the operating system warns of low memory. PhoneGap calls the onMemoryWarning method within the extension if the operating system is running low on memory, allowing the plugin to release objects superfluous to requirements at that moment. No such luck here. It wouldn’t be so bad if this extension was not leaking memory.

Returning to the code shown above. The DatePicker show:withDict: method is being invoked by PhoneGap when the plugins Javascript counterpart is executed. Each time this method is executed a new UIDatePicker is created and assigned to the plugin and action sheet. Because the previous UIDatePicker is not released and also not removed from the Action Sheet view, the new instance is placed over the existing instance. The new instance should always be placed on top, but who knows what happens when there are several UIDatePicker controls layered up on top of each other. This begins to explain the strange behaviour experienced earlier where repeated use of the DatePicker extension resulted in it not responding or returning the correct date.

Delegates and Single Responsibility Principle

One other implementation detail was also causing concern. The UIActionSheet class has a delegate protocol. The Cocoa frameworks use the delegate pattern consistently across many user interface controls. Unfortunately the DatePicker extension does not use the provided delegates.

1
2
3
4
5
6
7
8

- (void) dismissActionSheet:(id)sender {
  [datePickerSheet dismissWithClickedButtonIndex:0 animated:YES];
  [datePickerSheet release];
  [datePicker release];
  NSString* jsCallback = [NSString stringWithFormat:@"window.plugins.datePicker._dateSelected(\"%i\");", (int)[self.datePicker.date timeIntervalSince1970]];
  [super writeJavascript:jsCallback];
  isVisible = NO;
}

The dismissActionSheet: method is invoked by a UISegmentedControl button defined earlier in the class. When the user selects the Close button, this method is invoked. But this method is performing a lot of actions, most are outside the scope of the method name. The current responsibilities of this method are;

1. Remove the UIActionSheet from the interface
2. Free the UIActionSheet from memory
3. Free the UIDatePicker from memory (although we saw earlier this won’t happen)
4. Return the date picked to the PhoneGap API
5. Update the state of the DatePicker extension

That is a lot of responsibility for a simple UI action. A method named dismissActionSheet: should do just that, dismiss the action sheet. Therefore to maintain the single responsibility principle this method should only perform the action it prescribes.

1
2
3

- (void)dismissActionSheet:(id)sender {
  [self.datePickerSheet dismissWithClickedButtonIndex:0 animated:YES];
}

The new implementation of dismissActionSheet: solely performs the action requested of it, namely removing the UIActionSheet from the interface. But in the process a lot of the other functionality previously performed has been lost. Returning to the list of responsibilities above, there are three tasks that are important to the functionality of this extension. (Memory management of UI elements should not be handled here)

1. Return the date picked to the PhoneGap API
2. Update the state of the DatePicker extension
3. Remove the UIActionSheet from the interface

Having already removed the UIActionSheet from the interface, only the first two tasks remain.

The first task is to return the date picked to the PhoneGap API. Because a value is being transmitted from the one platform (Objective C) to another (JS), there is potential for things to go wrong. It is probably best to send the value to the PhoneGap API before removing the UIActionSheet. The UIActionSheetDelegate class provides a method actionSheet:willDismissWithButtonIndex: that is invoked prior to the UIActionSheet being dismissed.

1
2
3
4
5

- (void)actionSheet:(UIActionSheet *)actionSheet willDismissWithButtonIndex:(NSInteger)buttonIndex
{
  NSString* jsCallback = [NSString stringWithFormat:@"window.plugins.datePicker._dateSelected(\"%i\");", (int)[self.datePicker.date timeIntervalSince1970]];
  [super writeJavascript:jsCallback];
}

The date selected by the user is now passed to the PhoneGap API as the UIActionSheet is being dismissed by the system. If there are any problems passing the value back to PhoneGap, an alert can be provided before the interface is dismissed. (Ideally, there would be a UIActionSheetDelegate method for cancelling the dismiss; actionSheet:shouldDismissWithButtonIndex: for example. Unfortunately no such luck here)

The final task is to update the state of the extension. As the extension will hang around after the user has dismissed it, the state will be important for managing memory and components so it is worth keeping. Again the UIActionSheetDelegate protocol provides the perfect method for updating the state, actionSheet:didDismissWithButtonIndex:.

1
2
3
4

- (void)actionSheet:(UIActionSheet *)actionSheet didDismissWithButtonIndex:(NSInteger)buttonIndex
{
  isVisible = NO;
}

All of the original functionality tied to the Close button has now been refactored into new methods that use the standard Objective C and Cocoa patterns. Additionally, the single responsibility principle has been maintained.

The refactored DatePicker extension and PhoneGap

There are many more improvements that can be made to this DatePicker extension for PhoneGap. It is easy to critique others code, but it is far more valuable to give back. As we had to fix the issues detailed here and a number of others, we pushed the changes back to GitHub and requested they were pulled into the project. To the credit of the PhoneGap plugins project, they merged the changes in promptly.

There are no doubt other improvements that can be made to the DatePicker extension, however those improvements will not be completed by myself or the team. After attempting to build our application in PhoneGap, we ultimately abandoned the project and reverted to native development on iOS and Android.

Unfortunately PhoneGap promises a lot, but does not always deliver on these promises. Additionally many of the official extensions are implemented to a similar standard as the DatePicker extension examined here. The questionable quality extends beyond iOS to Android as well, as different but equally crippling issues were found with the Android DatePicker extension. I am sure that PhoneGap has a place in the mobile development space, but beyond basic brochure applications I am not entirely sure what it is.

Update

After this was initially posted, people have pointed out that HTML5 does provide a datetime input type. This would obviously provide a better way to perform all of the above within the browser context. The support is still rather patchy, so keep an eye on PPK’s excellent work testing HTML5 support across all mobile devices. As with all things in the mobile web, support for <input type="datetime"></input> can only improve with time.

Just a quick note to say that I have been experiencing some DNS woes with this domain. As a result, many of you have probably been seeing a far from beautiful 404 Not Found served by my former hosting company. Initially I thought this was an issue with my Heroku web dynos. However after doing some further DNS analysis and investigation I discovered that I had what can only be described as DNS EpicFAIL!

When this site was on the previous host it was hosting its own DNS server using Bind. Because there was only one piece of bare metal there needed to be a backup DNS server hosted elsewhere. At the time I decided to use a free service offered by a company based out of California. I will not advertise them here, not through lack of service but to ensure their offerring is not abused by the masses. I setup the secondary DNS host to be a slave to the primary Bind DNS server hosted on my bare metal. This all worked beautifully for several years.

Fast forward to 2012 and the decision is made to move to another host. Heroku is a wonderful service, but they don’t do DNS within their core offering. There are addons that can provide DNS services, but I wanted to have more control than those services offered. In the end I opted to move to Zonomi as they offered the service required at a very resonably price.

After exporting the original Bind zone configration and importing it correctly into the new DNS server, I then updated the secondary slave DNS servers to pull from the new primary servers hosted by Zonomi. This is where the trouble started. I did not hang around to check if the secondary DNS host was able to pull the zone information from Zonomi using the AXFR protocol. As it turns out, Zonomi disallow this presently. I’m not sure why but will certainly investigate. As the new DNS zone information was not updated at my secondary DNS host, the original data remained pointing at my old servers.

Over the last few months I have noticed that this site has intermittently been unvailable some of the time, all of the time or not at all. Initially I thought this was due to Heroku spinning down the web dynos on the free account I started with. However after spinning up a second dyno and still experiencing the issue, it became obvious the issue lie elsewhere. I noticed that Pingdom would report this site as being down even when I could navigate to it without issue. Currently I do not serve Cache-Control headers (coming soon), so it was not a stale cache persisting in a proxy. It was time to dig a little into this issue.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

dig def.reyssi.net

; <<>> DiG 9.7.3-P3 <<>> def.reyssi.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51223
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;def.reyssi.net.          IN  A

;; ANSWER SECTION:
def.reyssi.net.       599169  IN  A   46.105.102.142

;; Query time: 4 msec
;; SERVER: 10.0.1.1#53(10.0.1.1)
;; WHEN: Mon Mar 26 22:36:25 2012
;; MSG SIZE  rcvd: 48

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

dig def.reyssi.net   

; <<>> DiG 9.7.3-P3 <<>> def.reyssi.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65009
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;def.reyssi.net.          IN  A

;; ANSWER SECTION:
def.reyssi.net.       1851    IN  A   75.101.163.44
def.reyssi.net.       1851    IN  A   174.129.212.2
def.reyssi.net.       1851    IN  A   75.101.145.87

;; AUTHORITY SECTION:
reyssi.net.       171051  IN  NS  ns1.zonomi.com.
reyssi.net.       171051  IN  NS  ns2.zonomi.com.
reyssi.net.       171051  IN  NS  ns3.zonomi.com.
reyssi.net.       171051  IN  NS  ns4.zonomi.com.

;; Query time: 102 msec
;; SERVER: 193.26.222.2#53(193.26.222.2)
;; WHEN: Mon Mar 26 22:39:12 2012
;; MSG SIZE  rcvd: 162

As is very clear, the two records are quite different. The DNS servers that my work uses have the correct zone information for this domain. However my ISP for home seems to be using the record hosted by the secondary DNS server. Because the old secondary server is failing to update correctly, the zone information is sparse at best. It appears that different DNS nameservers were choosing to use different zone records hosted either at Zonomi or the secondary host. To fix the issue I have retired the secondary DNS service as Zonomi offer four separate nameservers.

Hopefully all these DNS woes will be behind me now. It will take around 72 hours for all the DNS changes to propagate across the network, so stability is a little way off. But hopefully everyone should be able to read this by the weekend.

Kill All The Servers image courtesy of DIY LOL – inspired by Ian Barber’s Skype avatar

First of all grab the latest copy of the OCMock dmg from http://ocmock.org#download, version 2.0.1 at the time of writing. Next mount the disk image ocmock-2.0.1.dmg (version number may be different) so that the directory structure of the mounted disk image should resemble the image below

At this point the OCMock library is ready to be added to your project. The disk image provided supplies linked libraries for iOS and Mac OS X, as well as the source. Naturally the project source is also available on Github. Be warned, the Github source will require compiling before it can be used in your own tests. If you are not comfortable with that concept, it is best just to use the precompiled binaries.

Before importing the OCMock library into your Xcode 4 project, create a folder for this library name something similar to $(SRCROOT)/tests/libraries. $(SRCROOT) is xcode shorthand for the project root folder for anyone scratching their head. In Xcode create a group within the tests group called libraries to mirror the layout of the filesystem. Now drag the contents of the OCMock iOS folder on the mounted drive to the new libraries group within Xcode created previously.

Xcode might be clever and realize what has just happened at this point and added libOCMock.a to your tests targets Link Binary With Libraries build phase. If it has not, then you can drag libOCMock.a from your filetree into the Link Binary With Libraries build phase to add it. Before continuing we need to ensure that Xcode is including the library and headers when the tests are run. Within the test target, check the Build Settings entry for Header Search Paths and Library Search Paths includes $(SRCROOT)/tests/libraries.

Finally and most importantly Xcode needs to tell the compiler to force load the OCMock libraries at compile time, otherwise your tests will crash. Within the Build Settings in your test build target add the following line to the Other Linker Flags entry; -force_load $(SRCROOT)/tests/libraries/libOCMock.a.

OCMock is now ready for use and bar any other unforseen problems, testing should be uneventful. The last step of instructing the compilier to force load the library caused me to loose 30 minutes this afternoon, so hopefully this will help anyone else having similar issues.

I am delighted to announce that I’ll be speaking at the Dutch Mobile Conference in June 2012. I will be presenting Ten considerations for taking a web business to the mobile market on the Friday. The talk will provide attendees with ten useful considerations for taking an existing online business into treacherous world of mobile. Moving an established online business into the mobile domain sounds simple to say. In some cases, it can be simple to perform. But the reality for a lot of companies is that their present model does not necessarily work within a mobile context.

It is always a pleasure to visit Amsterdam, a city that Siân and I enjoy visiting as often as possible. I will be staying on in Europe for a week after the conference to visit friends and family back in London. June cannot come soon enough for me.

Setting up your development environment

First off you are going to require Ruby 1.9.2. At this point your natural temptation may be to download and compile the source code directly. This will work for the most part, but any seasoned Ruby developer will advice you against this path.

When doing any serious Ruby development you most likely will be working on numerous projects that use a variety of different frameworks, each with their own specific Ruby and Gem version requirements. Managing multiple versions of Ruby and Gems manually is a rather daunting task.

Thankfully this problem has been solved already by RVM and Rbenv. Both RVM and Rbenv provide an isolated Ruby environment, encapsulating Ruby and Gems to specific versions. This allows each Ruby project on your system to run a targeted version of Ruby and Gems per project without concerning yourself with conflicts. I am not going to advocate either of these tools over each other, but I will be using RVM in this article. There are instructions on using Rbenv on the Octopress setup guide.

To install RVM, in Terminal run;

1

$ bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)

Once RVM has finished installing, you should add it to your shell as a command. Run the following command to update your .bash_profile.

1

$ echo '[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm" # Load RVM function' >> ~/.bash_profile

Finally you should update your Terminal sessions .bash_profile to load the new profile settings.

1

$ source ~/.bash_profile

Now you’re ready to install Ruby 1.9.2.

1

$ rvm install 1.9.2 && rvm use 1.9.2

This command installs Ruby 1.9.2 as a Gem into your ~/.rvm/gems/ folder. Now within each Ruby application, you can create a .rvmrc file that defines the Gem sets required by the project. For example, Octopress instructs RVM to use Ruby 1.9.2 by including the following in its .rvmrc file.

1

rvm use 1.9.2

Obtaining Octopress

The best way of getting Octopress is directly from Github. This will require your system to have Git installed. By cloning the Octopress project, obtaining updates in the future will be as easy as git pull origin master. However you may prefer to fork the project on Github and then clone from your own repository. In this case, I am happy with the standard build of Octopress, so will clone it directly.

1

$ git clone http://github.com/imathis/octopress.git ~/Projects/octopress

This will place an instance of Octopress into my ~/Projects/octopress folder. You may wish to place it elsewhere, it does not matter where at this time.

Now change directory into the newly created local Git repository and check the Ruby version.

1
2
3

$ cd ~/Projects/octopress
$ ruby --version
ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-darwin11.2.0]

You should see the Ruby version you previously installed, the exact version number and details will differ depending on your platform and other environment variables. The Ruby environment is controlled by the RVM ~/Projects/octopress/.rvmrc file I mentioned earlier.

Next we install Bundler into this project.

1
2

$ gem install bundler
$ bundler install

Taken from its own website, Bundler provides the following functionality;

Bundler manages an application’s dependencies through its entire life across many machines systematically and repeatably.

When the bundler install command is invoked, it reads the required list of Gems from the projects Gemfile. If you were inspect the Gemfile for Octopress, you can see the project dependencies.

Finally, to install the default Octopress theme run the following command.

1

$ rake install

This will setup your local instance of Octopress with the standard theme. In my instance this command failed with the following message.

1
2
3
4
5

$ rake install
rake aborted!
You have already activated rake 0.9.2.2, but your Gemfile requires rake 0.9.2. Using bundle exec may solve this.

(See full trace by running task with --trace)

In some circumstances this will happen if you have a newer version of rake installed for whatever reason. Usually the Gemfile and Bundler will resolve these issues, but because both rake 0.9.2 and rake 0.9.2.2 are matched in the Gemfile this conflict is not resolved. However in this case, following prescribed advice provides the expected outcome.

1
2

$ bundle exec rake install
## Copying classic theme into ./source and ./sass

Octopress is now installed locally and is ready for you to begin blogging. You can use a plethora of hosting services with Octopress. As Octopress compiles a static version of your site, it would be perfectly possible just to publish the public/ folder to any standard HTTP server such as Apache or Nginx.

Because the contents of public/ folder is compiled by Octopress, by default the Git clone of the project will contain a .gitignore file with an entry to ignore the public folder. We need to remove this entry to ensure the public/ folders contents are included in our git repository and pushed upstream.

To remove the entry, edit the .gitignore file remove the offending line.

Deployment to Heroku

Deployment to Heroku requires an account on Heroku. If you do not have an existing Heroku account, sign up for one now.

I am discovering that as with most things in Ruby, there is usually a Ruby Gem tailored to working with whatever Ruby service you require. Heroku is no different.

To install the Heroku Gem.

1

$ gem install heroku

Now we have the Heroku Gem available, we can create our Heroku app. This does require an existing Heroku account, so if you still have not signed up with the Heroku service, now really is the time!

Note: To proceed you will need to have a SSH public key. Github have a great guide if you require help.

First we need to tell Heroku about our account. Using the heroku login command, we can authenticate ourselves with the Heroku service.

1
2
3
4
5
6

$ heroku login
Enter your Heroku credentials.
Email: <your email address>
Password: <your password>
Found existing public key: /Users/<your user>/.ssh/id_rsa.pub
Uploading ssh public key /Users/<your user>/.ssh/id_rsa.pub

If successful, the heroku login command will upload our SSH public key automatically to the Heroku service. The reason for this is that you publish to Heroku using Git, and just like any other standard Git remote repository, connection is made over SSH.

Next we create an application on Heroku that will host this blog.

1
2
3

$ heroku create
Creating smooth-beach-2208... done, stack is bamboo-mri-1.9.2
http://smooth-beach-2208.heroku.com/ | git@heroku.com:smooth-beach-2208.git

Well we have an app, but I don’t like the name. Heroku will generate a random name for applications if no name is supplied. After doing some research, I discovered you can provide a name, thus heroku create defreyssinet would result in an application located at defreyssinet.heroku.com. However it is not a disaster as we can rename any Heroku application after creating it.

To rename our app, within the ~/Projects/octopress folder type.

1
2
3

$ heroku rename defreyssinet
http://defreyssinet.heroku.com/ | git@heroku.com:defreyssinet.git
Git remote heroku updated

This has updated the hostname on Heroku and rather neatly tidied up our local Git repository remote entries. It is possible to do this manually by logging on to the Heroku site and renaming the app there, then updating the local git repository remote entries.

1
2

$ git rm heroku
$ git remote add heroku git@heroku.com:defreyssinet.git

At this point we have a Heroku app linked to our local Octopress Git repository. We can verify that our app has indeed been created by logging onto Heroku and selecting the My Apps menu item.

Now we have a local instance of Octopress and a host ready to accept our new blog. What is lacking is the content.

Creating a new post

As I mentioned earlier, Octopress is a static site generator rather than a fully fledged web application like Wordpress or Habari. This implies that there is a specific workflow in relation to publishing using Octopress. The typical publication flow for an article is as follows;

1. Create an article – rake new_post["title"]
2. Write some content
3. Review – rake generate
4. If more work required, return to step 2.
5. Publish – git push heroku <your app>

Before we get ahead of ourselves, it is time to setup the configuration of the blog using the _config.yaml file found in the root of the project. All of the configuration settings are described in detail on the Configuring Octopress page. Before creating any content it is probably worth familiarizing and editing this file to your specific needs.

Creating an article simply uses the rake new_post["title"] task. This creates a new file in the ~/Projects/octopress/source/_posts/ folder with a name composed of the date and the title. The extension will be .markdown as we will be writing in Markdown format.

Note: We will only be working in the source/ folder and we must not touch the public/ folder. The rake generate task compiles the contents of source/ and places it into public/.

So lets go ahead and create an article. (I’m prefixing with bundle exec here to avoid the version complaint seen earlier.)

1

bundle exec rake new_post["Get blogging with Octopress on Heroku"]

Rake helpfully creates a new Markdown file called 2012-01-14-get-blogging-with-octopress-on-heroku in the source/_posts folder. Opening up the new file will reveal the following.

1
2
3
4
5
6
7

---
layout: post
title: "Get blogging with Octopress on Heroku"
date: 2012-01-14 12:24:32
comments: true
categories:
---

The header of this file contains some yaml front matter. There are additional options available to control the publication state and author. Personally I think the time of publication is less important, but this is easily fixed by removing the time index from the date: entry (Edit: don’t do this as it will mess up article ordering!). I have also turned off comments comments: false for this post.

It is now possible to add some content to this page in Markdown format. We don’t need a title as the filename will become the title, so don’t start with a # my title block.

1
2
3
4
5
6
7
8
9
10
11

---
layout: post
title: "Get blogging with Octopress on Heroku"
date: 2012-01-14
comments: false
categories: [blogging, heroku]
---

Following on from [my opening post](http://def.reyssi.net/blog/2012/01/14/hello-2012/), one of the main hurdles preventing me from blogging was the setup of the blog platform and the management of the hosting. Thankfully, [Octopress](http://octopress.org) and [Heroku](http://heroku.com) have provided a simple, effective and free way for me to publish my thoughts to the web. In this post I will explain how I got started with Octopress on Heroku.

...

With some content in place, we can generate our first blog post using the rake generate task.

1
2
3
4
5
6

$ bundle exec rake generate
## Generating Site with Jekyll
unchanged sass/screen.scss
Configuration from /Users/sdefreyssinet/Projects/octopress/_config.yml
Building site: source -> public
Successfully generated site: source -> public

At this point Octopress has compiled the static version of our site. It is possible to load the public/index.html folder into any browser to view our new content.

If like me you are using Mac OS X, you can use the POW zero-configuration rack server from 37signals to host your site locally.

With POW installed, the following commands will create a local web server hosting our Octopress site.

1
2

$ cd ~/.pow
$ ln -s ~/Projects/octopress octopress

Now it is simply a case of navigating to http://octopress.dev to see the site we just compiled. This is a really quick and simple way of reviewing changes.

Users on other platforms that wish to test in a server environment locally just need to host their local public/ folder.

Previewing the site should present a page that looks similar to the screenshot below.

Looking good. At this point we can carry on editing and reviewing until we’re happy the post is ready. Remember that each time a change is made, an additional rake generate task needs to be invoked before any changes will be available in the public/ folder.

Publishing to Heroku

The first post is completed, reviewed and ready for publication. This is where Heroku makes our lives very easy. First we need to check all of our changes into the local Git repository.

1
2

$ git add .
$ git commit -am 'Initial commit with our first post, get blogging with octopress on heroku'

With the local repository up to date, we can push the repository to Heroku. Once the repository is pushed to Heroku it will be available immediately, so be sure you’re really ready to publish before pushing upstream.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

$ git push heroku master
Counting objects: 77, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (39/39), done.
Writing objects: 100% (49/49), 4.80 KiB, done.
Total 49 (delta 26), reused 0 (delta 0)

-----> Heroku receiving push
-----> Ruby/Sinatra app detected
-----> Gemfile detected, running Bundler version 1.0.7
       All dependencies are satisfied
-----> Compiled slug size is 784K
-----> Launching... done, v8
       http://def.reyssi.net deployed to Heroku

To git@heroku.com:defreyssinet.git
   efce197..2f3ed54  master -> master

Once the repository is pushed upstream, it will be available from the address configured in the Heroku app. In this case we named the app defreyssinet so the site will be available from http://defreyssinet.heroku.com.

In conclusion

In this blog post we have covered how to create a blog using the Octopress static site generator and host it on Heroku. In particular we have covered provisioning a local development environment with POW, obtaining Ruby using RVM and cloning the Octopress project from Github. We created a new Heroku application instance using the Heroku cli interface. Then we discovered how the publishing cycle works with Octopress, revolving around the rake generate task. Finally we pushed the Octopress blog to Heroku for production.

This article only scratches the surface of what Octopress offers, for more information I encourage everyone to read the official documentation.

Octopress will certainly not be to everyones tastes, but I hope this article has provided those with the slightest curiosity about Octopress some impetus to try it from themselves.

So why start writing again now? Well there are a number of reasons, too many to list here in full without leaving you bored. But three are worth mentioning;

1. For some time I have wanted to create a new blog, but none of the existing popular blogging platforms attracted me. Wordpress is, in this authors opinion, an awfully architected application that has unfortunately become popular the world over. I also considered writing my own system, but given I hardly had time to write article developing my own platform would be too big an ask- I did have a stab at it though! I had thoughts on developing a very rudimentary platform that would take my notes in Markdown format and publish them to either my server or another cloud-based server. Then I read a blog post by Matt Gemmell on Octopress and realized it had already been done well.

2. I have started a new job in Chicago. This in itself is nothing special. However my new role involves using a new programming language in the form of Ruby. For over ten years I have been developing for the web using PHP and related tools. So the move from LAMP to Nginx+Unicorn and; PHPUnit+Behat to Rspec+Cucumber will be a great opportunity for me to record my experience changing languages and toolsets. In all honesty I am delighted to be moving away from PHP, but that is a topic I’ll be writing about separately. On top of the challenges associated with mastering new language,I have also moved into a strange new country, which presents another aspect of my life to write about. Chronicling the trials and tribulations of moving country for work may be useful to others, if not a reminder to myself that international moving is not for the faint hearted!

3. Since my previous blogs disappeared, Twitter and Google+ have provided me with some online expression capabilities. But they do not provide me with enough characters to express myself in any kind of meaningful way, especially when writing about complicated subjects such as the OAuth Protocol; Continuous Deployment pipelines; or the Hierarchical Model-View-Controller architectural pattern. I really needed the freedom to construct articles as I have been used to writing for other publishers. Thus, restarting a blog seemed the only appropriate action.

I am turning off any ability to comment from the outset. The reasons for doing so has already been argued most eloquently by the aforementioned Matt Gemmell on his blog, so no need repeat that here. Needless to say, feel free to comment on anything I say on your own blog, Twitter, Facebook, Google+, or by email.

Lets see what 2012 has to offer.