We were recently asked to create a series of devices for our fantastic client cliqz (app store). They were looking for a great way to show that they are multi platform, namely iOS, Web and Android. So we created a nice visual to better showcase their product on an iPhone, an HTC one and a gorgeous iMac. You can see a glimpse of the result on top :) The finished piece will be on their website soon.

Now, here comes the great part: Thanks to cliqz, you can download the full PSD featuring all three devices here!

This is for educational purposes, we want you to dig through the psd and check out the layer styles so you can learn how to do this yourself. You are also allowed to use all three for personal or commercial use. Credit is not necessary but well appreciated! Please don’t try to make a profit by selling this psd or an altered version of it, we want this to be free. We’d also appreciate you not rehosting this file elsewhere, but rather link to this article if you want to share it with your friends and colleagues!

Русский перевод

JavaScript application development is a hot topic and people are wondering which framework they should pick. In this post I’m going to compare two of them.

Marionette and Chaplin are frameworks on top of the popular Backbone.js library. Both seek to ease the development of single-page JavaScript applications. In such applications, the client performs tasks that were typically performed on the server, like rendering raw data into HTML.

Backbone is designed as a minimalist library instead of a full-featured framework. My experience has shown that Backbone can only provide the foundation of a JavaScript application architecture. Both Marionette and Chaplin arose because Backbone is providing too little structure for real-world apps. They respond to the same problems. So there are a lot of similarities between the two – perhaps more than differences.

First of all I have to disclose that I’m a co-author of Chaplin. But I’ve also worked with Marionette in production and I’m following Marionette’s development. There is another ambitious framework on top of Backbone, named Thorax. Since I haven’t worked with it in production I don’t feel entitled to include Thorax in this comparison.

Contents

1. Non-technical aspects
2. Common features that fill Backbone’s gaps
3. Key features of Marionette
4. Downsides of Marionette
5. Key features of Chaplin
6. Downsides of Chaplin
7. Conclusion

Non-technical aspects

I’m going to talk about the technical details soon, but let’s face it, decisions between software libraries are largely influenced by their perceived momentum, reputation, success stories and documentation.

Marionette and Chaplin are MIT-licensed open-source projects that are being actively developed on Github. The authors have developed several bigger Backbone apps and took their experience to write layers on top of Backbone so you don’t have repeat their mistakes again.

Well-known companies are using Marionette and Chaplin to develop their products. It’s hard to estimate, but the user base is probably about the same size. The Marionette ecosystem is broader, so a lot of people use parts of Marionette without using the whole library.

Chaplin was more popular in the beginning, but Marionette has recently gained popularity. Marionette is beginner-friendly and has a great documentation, which is probably the most important reason for people to choose it. I think the commitment of Derick Bailey, the creator of Marionette, is one of the reasons for Marionette’s success. He wrote numerous key articles about developing Backbone apps. He is giving talks and recording screencasts, too.

Common features that fill Backbone’s gaps

Event-based architectures without the mess

Backbone’s key feature is the separation of concerns between models and views. They are connected using events and event listening. Using Backbone.Events, you can build an event-driven architecture. This is a great way to decouple the parts of your application.

Both Marionette and Chaplin identify the major pain points of Backbone apps. In an event-based architecture, cleaning up listeners is crucial. Components in your application need to have a defined lifecycle: A particular component creates another and is responsible for its later disposal. Marionette and Chaplin both address this problem with different approaches. They not only advocate event-based communication using Publish/Subscribe and related patterns, but also provide good means to avoid its pitfalls.

Application architecture

Models and views are low-level patterns. On top of that, Backbone only provides Routers. This is a very thin layer and probably the most confusing and problematic part of Backbone. With Backbone.Router alone, it’s not possible to set up a proper top-level architecture that controls the lifecycle of your objects. Both Marionette and Chaplin re-introduce controllers and a managing layer on top of them.

Strong view conventions

Following Backbone’s philosophy of simplicity, Backbone views and view rendering are rather abstract patterns. A Backbone view holds and controls a specific DOM element, but Backbone leaves it up to you how to fill this element and how to add it to the live DOM – the render method of views is empty per default.

Marionette and Chaplin provide view classes with a sane default rendering mechanism (see Marionette.ItemView and Chaplin.View). You just need to choose a template language like Mustache/Hogan, Handlebars of HAML Coffee.

Both libraries have conventions on when to render views and how to add them to the DOM. You can transform the model data before it is passed to the template. This is useful for computed properties, for example.

Views are probably the most complex part of your application, so Marionette and Chaplin provide several helpers and shortcuts. They allow to nest views in a safe way and declare named regions. They allow to register model events in a declarative way, which is easier and more readable than calling this.listenTo(this.model, …); several times.

If you’re using plain Backbone you will definitely miss the view classes for rendering collections (see Marionette.CompositeView and Chaplin.CollectionView). Using item views and two templates – a container template and an item template –, complex interactive lists can be implemented with clean and well-structured code. These collection views listen for collection events and render only those models that have been added, removed or changed their position.

Key features of Marionette

Marionette is a treasure trove for useful patterns to structure your app. It’s quite modular, you don’t need to use all what Marionette provides. It’s easy to start with some features of Marionette and discover others later. Some of Marionette’s features come from separate Backbone plugins, namely Backbone.BabySitter and Backbone.Wreqr. They are part of the Marionette family.

Marionette has some great unique features. In my opinion, the strongest points are application modules and the smart view management.

Application modules

Application modules are independent parts of your app that may consist of routers, controllers, models and views. Modules can be started and stopped, and you can define initializers as well as finalizers. Modules can also be lazy-loaded when a route matches, they don’t need to be active right from the beginning.

BBCloneMail is an example app that consists of two modules (mail and contacts). In this example, only one module is active at the same time. In general, app modules don’t have to be exclusionary. The modules have associated routers that need to be active since the beginning (contacts router, mail router).

Modules can be nested. Your main application, Marionette.Application, is also module. Technically there are some differences between Marionette.Application and Marionette.Module, but I hope in the future they will get more similar.

You probably don’t need several modules right from the beginning, but it’s a powerful feature that helps to break up an app into smaller, coherent units.

View management

Another strong part of Marionette is its sophisticated view management. Views can be nested easily and safely using the aforementioned BabySitter. In addition, Marionette introduces abstractions called Layouts and Regions. A Layout is a view that holds several named Regions. So what is a Region? It’s an object that manages an element in the DOM where it can insert a view. Example regions are header, navigation, main, sidebar and footer.

How and where should I render views and append them to the DOM? Regions are the answer. Instead of messing with DOM element references directly, you declare a Region once and later just say mainRegion.show(view), for example. This renders the view and attaches it to the DOM element that corresponds to the region. A Region holds only one view at a given time, so the old view is “closed” (i.e. removed from DOM and disposed safely).

With nested regions, building a complex UI gets easier and the code gets more readable and maintainable.

Downsides of Marionette

For brevity, I have just mentioned two unique points of Marionette. Most of its features are mature and well implemented. What I don’t like are thin abstraction layers and unclear best practices.

Routing and controllers

For example, Marionette provides little on top of Backbone.Router. In my opinion, this in important because Backbone.Router provides no convention on how to dispose the objects created (typically models and views) when another route gets active. It’s possible to implement a central cleanup using route events, but that’s a hack.

In Marionette there are application modules that can be stopped and Regions than can be closed. But as far as I can see, you’re not supposed to start and stop modules over and over and close regions explicitly.

Marionette.AppRouter is a step in the right direction. The idea is to separate the route configuration from the actual handler code. An AppArouter delegates all route matches to a separate Controller instance.

Controllers in Marionette don’t have a single fixed purpose, they just control something. They can listen to events using the Backbone.Events mixin, they have initialize and close methods. This is definitely useful, but it’s up to you whether you use them and how. Typically, this is the place where you create models and views.

Global vs. private objects

In Marionette, the modules and classes are saved in a global hierarchical namespace, for example BBCloneMail.MailApp.Controller. The actual instances don’t have to be global, but it’s tempting to do so. In the BBCloneMail example, some objects are passed and returned while others are global (e.g. BBCloneMail.MailApp.controller).

From reading the code it’s unclear which objects are global and which are actually accessed globally. When using Marionette, I suggest to implement an object-capability model that defines ways to connect objects without using the global scope.

Templating defaults

Per default, views read their templates from the DOM and compile them using the Underscore template engine (_.template). That’s easy to start with, but it’s not a good practice to embed the template code in your HTML. Eventually, templates should be separated files that can be precompiled and lazy-loaded. Of course, you can change Marionette’s default behavior easily: The Renderer singleton is in charge.

Key features of Chaplin

Compared to Marionette, Chaplin acts more like a framework. It’s more opinionated and has stronger conventions in several areas. It took ideas from server-side MVC frameworks like Ruby on Rails which follow the convention over configuration principle. The goal of Chaplin is to provide well-proven guidelines and a convenient developing environment.

CoffeeScript and OOP

Chaplin is written in CoffeeScript, a meta-language that compiles to JavaScript. However, Chaplin applications do not have to be written in CoffeeScript. In the end, Chaplin is just another JavaScript library.

Using CoffeeScript is part of Chaplin’s idea to make application development easier and more robust. CoffeeScript enforces guidelines from Douglas Crockford’s book “JavaScript – The Good Parts”. Like Marionette, Chaplin is advocating the ECMAScript 5 Strict Mode.

With CoffeeScript, class declarations and class-based inheritance are more compact compared to Backbone’s extend feature. While Marionette tries to get around super calls, Chaplin embraces method overriding and tries to make class-based inheritance work smoothly. For example, if you declare event handlers on a derived class and on its super class, both will be applied.

Modularization using CommonJS or AMD

Chaplin requires you to structure your JavaScript code in CommonJS or AMD modules. Every module needs to declare its dependencies and might export a value, for example a constructor function or a single object. In Chaplin, one file typically contains one class and defines one module.

By splitting up your code into reusable modules and declaring dependencies in a machine-readable way, code can be loaded and packaged automatically.

Using AMD isn’t easy, you need to get familiar with loaders like Require.js and optimizers like r.js. As an alternative, you can use the CommonJS module format and Brunch as a processor.

Marionette also supports AMD. You can structure Marionette apps using AMD modules if you like, but it’s not a requirement.

Fixed application structure

Chaplin provides a core application structure that is quite fixed. It handles the main flow in your app.

• The Application is the root class that starts the following parts
• The Router replaces Backbone.Router
• The Dispatcher starts and stops controllers when a route matches
• The Layout is the top-level view that observes clicks on links

In Chaplin, there is a central place where to define all routes. A route points to a controller action. For example, the URL pattern /cars/:id points to cars#show, that is the show method of the CarsController.

A controller is the place where you create models. It’s also responsible for creating the view for the main content area. So a controller usually represents one screen of your app interface.

Object disposal and controlled sharing

The main idea of Chaplin are disposable controllers. The basic rule is: The current controller and all its children (models, collections, views) are disposed when another route matches. Even if the route points to another action of the same controller, the controller instance is disposed and a new one is created.

Throwing objects away when another route matches is a simple and effective rule for cleaning up references. Of course, some objects need to remain in memory in order to reuse them later. The Chaplin.Composer allows you to share models and views in a controlled way. You need to mark them as reusable explicitly. If the saved object is not reused in the next controller action, it is automatically disposed.

In a Chaplin app, every object should be disposable. All Chaplin classes have a dispose method that will render the object unusable and cut all ties.

Private instances and Publish/Subscribe

A well-known rule of JavaScript programming is to avoid global variables. Chaplin tries to enforce this best practice. Classes are CommonJS/AMD modules that are hidden in a closure scope. All instances should be private. Two instances should not have references to each other unless they are closely related, like a view and its model.

Objects may communicate in a decoupled way using the Publish/Subscribe pattern. For this purpose the Chaplin.Mediator exists. The mediator can also be used to share selected instances globally, like the user object. After creating the necessary properties, the mediator object is sealed so it doesn’t become the kitchen sink of your app.

View management

Chaplin is also strong at view management. It has app-wide named regions and subview managing. Chaplin takes a different approach on rendering views and attaching them to the DOM. Views may have an autoRender flag and a container option. With these enabled, views are rendered on creation and are automatically attached to the DOM. Instead of container, you can specify region in order to attach the view to a previously registered region.

Apart from the app-wide regions there are no abstraction classes like Marionette.Layout and Marionette.Region. In a Marionette app, you typically create several nested Layouts and Regions. In a Chaplin app, you have fewer key regions and directly nest views inside of them. Of course you can create reusable views that behave like a Marionette.Layout, for example a ThreePaneView.

Downsides of Chaplin

As one of the main authors of Chaplin, I may be biased. But I do see weaknesses and room for improvement. It’s obvious that Marionette found better solutions to specific problems.

As I pointed out, Chaplin defines each component’s lifecycle and therefore is strong in memory management. When developing Backbone applications, this was one of our major problems. Chaplin found a solution that works well, but it isn’t perfect and it’s surely debatable. This feature already evolved and needs to evolve even further.

For beginners, it’s not easy to grasp the whole Chaplin picture. Memory management, modularization and other Chaplin concepts are still new to many JavaScript developers. While Chaplin’s rigidity seems to be a burden in the beginning, an app will benefit from it in the long term.

Publish/Subscribe isn’t a unique feature of Chaplin but can be compared to Marionette’s application vent. In fact Marionette is more flexible because every application module comes with its own Event Aggregator.

Chaplin is using Publish/Subscribe to broadcast events, but also to trigger commands with callbacks. This is rather a misuse of the pattern. Backbone.Wreqr implements the Command and Request/Response patterns for this purpose. Chaplin should learn from Marionette in this regard.

Conclusion

Marionette is rather modular, you can pick the patterns you like. (In my opinion, you should pick most of them because they can improve your app.) Instead of having one central structure, you can create a composite architecture with independent application modules. This offers great flexibility and allows decoupling, but you need to figure out how to use these building blocks properly.

Chaplin is more like a framework, it’s centralized and rather strict. The Chaplin authors think these guidelines offer convenience and boost productivity. Your mileage may vary, of course.

Because of its goals, Chaplin has a broader scope and deals with several problems that other libraries do not address. For example, Chaplin has a feature-rich routing and dispatching system that replaces Backbone.Router but makes use of Backbone.History.

Compared with Marionette, Chaplin is rather monolithic. That doesn’t mean you can’t do things differently. You can configure, modify or exchange the core classes and break all rules.

Standing on the shoulders of giants

So which library should you pick? I don’t think it’s an exclusive choice. Obviously, you should build upon the library whose core concepts meet your demands. But you should examine both to understand and apply their patterns.

When using Backbone, you need to set up a scalable architecture yourself. Do not write applications in plain Backbone and make the same mistakes others did, but put yourself on the shoulders of giants. Have a deeper look at Marionette, Thorax, Aura, Chaplin and other architectures to learn from them.

To get started with Chaplin, I recommend to use one of the boilerplates:
The CoffeeScript boilerplate with Handlebars templates or the same in plain JavaScript. These incorporate several conventions we consider useful: Folder structure and file naming conventions, coding style, template engines. These are part of “the Chaplin experience”.

If you’re looking for a mature quick-start developing environment, you may give Brunch with Chaplin or Chaplin’s Ruby on Rails boilerplate a try.

For a more hands-on introduction to Marionette, see this article on Smashing Magazine: part one and part two. In the Marionette Wiki, there’s a whole list of articles, screencasts and presentations.

Credits

Thanks to Derick Bailey, Sebastian Deutsch, Paul Miller and Paul Wittmann for their feedback on this article and their contributions to both Marionette and Chaplin.

Custom migration is quite a powerful tool and you can perform all kinds of transformations, e.g., change relationships or merge entities. In this guide, only changes of the attribute’s type are discussed, but this might be a good starting point for other kinds of migrations, too.

(This guide refers to Xcode Version 4.5.2 (4G2008a) and iOS >=5.)

TABLE OF CONTENTS

1. Versioned Core Data Model
2. Lightweight Migrations
3. Example Scenario
4. Custom Mapping Models
5. Custom Migration Policy
6. Conclusion

1. VERSIONED CORE DATA MODEL

You can skip this section if you are already familiar with versioned Core Data models.

If you simply change your model it will be incompatible with the Core Data store used to create it and Core Data wont be able to open it. Therefore you need to add a model version:

1. Select your Core Data model file in Project Navigator
2. Choose Add Model Version.. from Editor menu item
3. The Based on model field should indicate your previous model version

If you do this for the first time, this turns the original document into a file package that groups both versions of the model, each represented by an individual .xcdatamodel file:
One for the original Core Data model and one for your updated model.
Choose the latter in Project Navigator and change your model as required. Now tell Core Data to use your new model:

1. Select the container Core Data model in Project Navigator
2. In File Inspector (View -> Utilities -> File Inspector) choose the latest version in the Versioned Core Data Model dropdown. Check that the green checkmark switched from the old to the new version in the File Inspector.

2. LIGHTWEIGHT MIGRATIONS

Core Data needs to know how to map the entities and properties from a source model to the destination model. For the following cases, Core Data can infer the changes automatically, which is referred to as lightweight migration:

• Addition of new attributes
• Removal of attributes
• Changing a non-optional attribute to an optional
• Changing an optional attribute into a non-optional, and defining a default value
• Renaming an entity or property (if the renaming identifier is set appropriately)
• Please refer to Core Data Model Versioning and Data Migration Programming Guide for the complete list.

In order to activate lightweight migrations, you have to pass the following options

NSDictionary *options = @{
    NSMigratePersistentStoresAutomaticallyOption : @YES,
    NSInferMappingModelAutomaticallyOption : @YES
};

when invoking:

addPersistentStoreWithType:configuration:URL:options:error:

If Core Data cannot infer the mapping model automatically, it will not be able to open the persistent store. Resetting the simulator or reinstalling your app will do the trick. But if your app was already released on the App Store you want to guarantee your customers a smooth update process. That is where custom mapping models come into play.

3. EXAMPLE SCENARIO

Let us assume we have a view controller that shows comments. Therefore, we have got an entity named Comment consisting of three attributes: author, text and createdAt, all of type String.

Furthermore, the server delivering the data sends the creation date in a custom format that requires further processing.
We released our app to the App Store, just to realize afterwards that it would have been more efficient to store the transformed timestamp in our entity instead of doing the transformation whenever we access this attribute. Thus, let us add a new model version, update the type of the timestamp attribute from String to Date and set this model version to be the current version.

Since Core Data will not be able to infer the mapping model on its own, let us create a custom mapping model.

4. CUSTOM MAPPING MODELS

To create a custom Core Data mapping model:

1. Open the new file dialog File -> New -> File
2. Choose the Mapping Model template (Core Data -> Mapping Model)
3. Choose the source and target version of your versioned Core Data model

IMPORTANT NOTE:
If your Core Data model evolved over several versions since your last App Store release, you have to choose the version used in your App Store release as the source in the mapping model! Otherwise the mapping model will not be applied when updating from that release.

5. CUSTOM MIGRATION POLICY

The custom mapping model contains an entity mapping called CommentToComment, which contains attribute mappings prepopulated to perform a simple copy and paste of all attribute values. Since we want to perform a custom transformation on the createdAt attribute, change its attribute mapping to:

FUNCTION($entityPolicy, "dateFromTimestamp:" , $source.createdAt)

This tells the migration manager to call dateFromTimestamp:
on the entity migration policy object and to pass the createdAt value of the source entity. Last, we need to ensure Core Data finds our custom transformation method:

1. Create CommentTransformationPolicy class as a subclass of NSEntityMigrationPolicy
2. Define and implement the transformation method dateFromTimestamp:

+ (NSDateFormatter *)dateFormatter{
   static NSDateFormatter *sharedDateFormatter = nil;
   if (!sharedDateFormatter){
      sharedDateFormatter = [[NSDateFormatter alloc] init];
      [sharedDateFormatter setDateFormat:@"yyyy-MM-dd'T'HHmmssZZ"];
   }
   return sharedDateFormatter;
}

- (NSDate *)dateFromTimestamp:(NSString* )timestamp{
   return [[[self class] dateFormatter] dateFromString:s];
}

1. Register this class as custom entity migration policy in the mapping model:
   • Select the mapping model file in the project navigator
   • Select the CommentToComment entry in Entity Mappings
   • Fill out CommentTransformationPolicy in Custom Policy field of the mapping model inspector (View -> Utilites -> Show Data Model Inspector)

6. CONCLUSION

We now have a working custom migration that smoothly updates the app’s database. This way, you save time writing your own methods to detect whether a migration is actually necessary. If you have got any questions or suggestions feel free to leave a comment or tweet me @c_gretzki.

Special thanks to Martin Winter for pointing me to the mystical FUNCTION($entityPolicy, “dateFromTimestamp:” , $source.createdAt) syntax ;)!

Hardware

Our CI environment runs on dedicated hardware. We took one of our unused Mac Minis, installed a fresh copy of OS X Mountain Lion (version 10.8.2 as of this writing) and created an OS X user named “jenkins”. This user is the only user on the system and the system is not used for other purposes than running a Jenkins server.

As an alternative, the CI environment could be installed in a virtual machine or even in the developer’s OS X account on her own computer. But this is not our setup and you are on your own if you want to configure this setup instead.

Setting Up Jenkins

At 9elements, we use the excellent OS X package manager Homebrew. SSH into your CI computer and install Jenkis via Homebrew:

$ brew install jenkins

We want Jenkins to always run, even after an unexpected system restart. Create a new file ~/Library/LaunchAgents/org.jenkins-ci.plist with the following content:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" 
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>KeepAlive</key>
    <true/>
    <key>Label</key>
    <string>org.jenkins-ci</string>
    <key>ProgramArguments</key>
    <array>
      <string>/usr/bin/java</string>
      <string>-server</string>
      <string>-d64</string>
      <string>-XX:+UseG1GC</string>
      <string>-Xms512m</string>
      <string>-Xmx512m</string>
      <string>-XX:MaxGCPauseMillis=500</string>
      <string>-jar</string>
      <string>/usr/local/opt/jenkins/libexec/jenkins.war</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
  </dict>
</plist>

This causes Jenkins to always launch after the OS X user “jenkins” logged into the system. The parameters for /usr/bin/java are explained in the article java – the Java application launcher. After restarting the system the user “jenkins” is not automatically logged in. Go to System Preferences → Users & Groups → Login Options → Automatic login and select the user “jenkins” from the drop-down list.

Disclaimer: We are fully aware that this allows people with physical access to the CI computer to access it without entering a password. We configured OS X to show a screensaver after 1 minute of inactivity and require the user’s password to unlock the screensaver. However, an unauthorized person with physical access could restart the computer and use this time window to access the computer. Decide on your own if you actually want to do this.

It is not possible to run application tests when Jenkins is configured via /Library/LaunchDaemons. Jenkins needs to have access to the window manager to be able to launch and interact with the iOS Simulator through the tool ios-sim (more on that later). This is the error that occurs if Jenkins is configured as a system daemon [phonegap/ios-sim/issues/5]:

[DEBUG] Session could not be started: Error 
Domain=DTiPhoneSimulatorErrorDomain Code=2 
UserInfo=0x100270b90 "Simulator session timed out."

We have not been able to successfully configure a “headless” Jenkins (via the parameter -Djava.awt.headless=true) that can run the Kiwi specs.

Running Kiwi Specs from the Command Line

Kiwi is a nice framework for implementing unit tests in iOS projects. It allows the developer to write unit tests in the popular RSpec flavor.

Xcode knows two different types of unit test targets: application test targets and logic test targets. Application tests run inside the iOS application (simulator or device) and allow the tests to access all parts of the running application. Logic tests run outside of the application and can only test specific classes. The Xcode user interface supports both test target types. However, application tests are not supported when run from the command line. Unfortunately, Kiwi specs need an application test target to work properly. This means that running Kiwi specs within a CI environment (that needs them to be run from the command line) is not officially supported by Xcode. Two answers on Stack Overflow [SO1, SO2] provide help. It is possible to recreate the behavior when pressing CMD+U in the user interface of Xcode (where application tests are officially supported) on the command line.

1. Copy the Gist mbinna/RunUnitTests.sh and paste it into the “Run Unit Tests” build phase of the application test target.
2. Create a new scheme named “CommandLineUnitTests” for the Kiwi test target.
3. Select the checkbox “Shared” and add this scheme to the VCS repository, so that it is available on the other computers that work with this repository.
4. Add the application test target to the section Build by pressing the + button
   

The additional scheme is necessary to run tests from the command line. xcodebuild does not provide a “test” action that would provide the same behavior of pressing CMD+U in Xcode. The additional scheme builds the project and runs the unit tests (as can be seen in the column “Run” in the screenshot above).

The customized script to run unit tests (configured in step 1 above) uses the tool ios-sim to install and launch applications in the iOS Simulator from the command line. Install ios-sim via Homebrew:

$ brew install ios-sim

You can now run your Kiwi specs from the command line by invoking the follwing command:

$ xcodebuild -sdk iphonesimulator \
             -workspace SampleProject.xcworkspace \
             -scheme CommandLineUnitTests \
             -configuration Debug \
             RUN_APPLICATION_TESTS_WITH_IOS_SIM=YES \ 
             ONLY_ACTIVE_ARCH=NO \
             clean build 2>&1

This command performs a clean build of your project and runs the Kiwi specs in the iOS Simulator afterwards. The environment variable RUN_APPLICATION_TESTS_WITH_IOS_SIM=YES is necessary to run the unit tests with the custom approach specified by the script RunUnitTests.sh. ONLY_ACTIVE_ARCH=NO ensures that xcodebuild builds all supported architectures, not only the currently active architecture. Only compiling the active architecture is often used in the configuration Debug to reduce compile times during development.

Configuring rbenv, Bundler, CocoaPods

The management of dependencies to third-party projects became much easier with CocoaPods. CocoaPods is a package manager for iOS projects that installs third-party projects. The content of the Podfile specifies which dependencies (and which version of each dependency) CocoaPods installs. We recently published an article about best practices for dealing with a CocoaPods-enabled Xcode project. CocoaPods is a Ruby gem and thus runs with the Ruby version that is installed in the system. Besides iOS, 9elements is also doing a lot of Ruby and Ruby on Rails development. Different Ruby projects may require different versions of Ruby. We want our CocoaPods to run in a controlled Ruby environment. To meet this requirement, we use rbenv (together with ruby-build) to install and switch between different versions and flavors of Ruby.

$ rbenv local 1.9.3-p327

This sets the official Ruby 1.9.3-p327 as the local Ruby installation for our project. Be sure to check the generated file .ruby-version into your repository.

We also use Bundler to install the gems for the currently selected Ruby version. This eliminates potential problems when two or more developers use different versions of Ruby (or even different types of Ruby interpreters). The steps to setup our Ruby environment for CocoaPods are as follows:

$ bundle init

This creates an initial Gemfile that you can customize. Add the following to your newly created Gemfile:

source "https://rubygems.org"

gem "cocoapods", "0.16.0"

Now you can install the gem with Bundler:

$ bundle install

Be sure to check the two files Gemfile and Gemfile.lock into your repository. Now we can install the gems:

$ bundle exec pod install

Now we are ready to configure our Jenkins server.

Configuring a New Job in Jenkins

Create a new job with the “Build a free-style software project” template. Fill out the required information to checkout the repository and configure the build trigger. Add a new build step of type “Execute shell”. Paste the following commands into this build step:

#!/usr/bin/env bash
source ~/.bash_profile

bundle install
bundle exec pod repo update
bundle exec pod install

DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer
xcodebuild -sdk iphonesimulator \
           -workspace SampleProject.xcworkspace \
           -scheme CommandLineUnitTests \
           -configuration Debug \
           RUN_APPLICATION_TESTS_WITH_IOS_SIM=YES \
           ONLY_ACTIVE_ARCH=NO \
           clean build 2>&1

By default, Jenkins uses the shell /bin/sh in “Execute shell” build steps. However, we want to use our shell profile configured in ~/.bash_profile, because it contains the rbenv initialization that is necessary to actually use rbenv. The script sets the shell to be bash and uses the profile configured in ~/.bash_profile. It installs the required gems by executing bundle install followed by bundle exec pod repo update and bundle exec pod install to install the required pods. It sets the DEVELOPER_DIR to use the current stable version of Xcode. This is only needed if you installed serveral version of Xcode (stable, beta, GM, …) and want to ensure that the correct one is used in the build step.  The last step invokes xcodebuild by providing the workspace, the scheme, and the environment variables necessary to properly run the Kiwi specs from the command line.

Displaying Kiwi Spec Output in Jenkins’ Web Interface

Jenkins has built-in support for JUnit test reports. The gem OCUnit2JUnit parses the output of xcodebuild and generates JUnit-style output for Jenkins.

Add the gem OCUnit2JUnit to the Gemfile:

gem "ocunit2junit", "1.2"

and install it via

$ bundle install

Now edit the “Execute shell” build step in the build job to pipe the output of xcodebuild to ocunit2junit:

xcodebuild -sdk iphonesimulator \
           -workspace SampleProject.xcworkspace \
           -scheme CommandLineUnitTests \
           -configuration Debug \
           RUN_APPLICATION_TESTS_WITH_IOS_SIM=YES \
           ONLY_ACTIVE_ARCH=NO \
           clean build 2>&1 | bundle exec ocunit2junit

Add a new post-build action of type “Publish JUnit test result report”. Enter “test-reports/*.xml” (without quotes) into the field “Test report XMLs”. Start a new build and check if everything is working as expected.

Conclusion

We now have a working CI environment that checks out the repository, builds the projects, and runs the Kiwi specs. This process could be much easier if Apple provided official support for running application tests from the command line. Until this happens, we use the “inofficial” solution presented here.

Let us know in the comments if there is a better way to do certain things or if something is missing in this article. You can also find me on Twitter @mbinna.

CocoaPods is a relatively new way to manage Xcode library dependencies like the Facebook iOS SDK et al. If you are coming from the Ruby world you know this kind of workflow from bundler. CocoaPods can be easily installed as a gem via ‘gem install cocoapods’ but this is where the pain begins. What if one developer is using CocoaPods 0.14.0 and another developer is using CocoaPods 0.16.0? To ease that problem we are using CocoaPods together with bundler.

Always use the same version of CocoaPods

We have a Gemfile where we exactly specify the CocoPods version we want to use:

source 'http://rubygems.org'
gem 'cocoapods', '0.16.0'

So we never use a globally installed version of CocoaPods but a version that can be executed via bundler: bundle exec pod install

Always specify the version of a pod

When we started using CocoaPods we simple added our dependencies and let CocoaPods take care of the versions by locking them in the file Podfile.lock:

pod 'Facebook-iOS-SDK'
pod 'SBJson'
pod 'TestFlightSDK'
pod 'GoogleAnalytics-iOS-SDK'
...

But we soon found out that if you updated a specific version, things sometimes tend to break. In our case Google decided to break a header file in version 2.0beta3 of their Google Analytics SDK. Version 2.0beta4 fixes that problem, but if you just run “bundle exec pod update” it not just updates a specific dependency – it updates all the pods. One of those pods broke our build chain. If you archived our project in Xcode it started to generate a Generic Xcode Archive instead of an iOS App Archive. We did not suspect that CocoaPods is the problem in the first place and Googled that problem for hours. “Skip install” had the correct value and everything seemed to look fine. Then we started to work with an old Podfile again and everything was ok. So here comes the fix: we created a new Podfile and manually added all versions. After that, we just upgraded Google Analytics to the latest version.

pod 'Facebook-iOS-SDK', '3.1.1'
pod 'SBJson', '3.1.1'
pod 'TestFlightSDK', '1.2.beta2'
pod 'GoogleAnalytics-iOS-SDK', '2.0beta4'
...

And the problem was gone. So a best practice for us became to concretely add the version numbers for each pod so that we control the update mechanism.

Specify the version of your Ruby

That brings us to our last best practice. Since we are doing a lot of Ruby on Rails consulting we need to switch between different Ruby versions a lot and we use rbenv to control these environments. We wanted to apply the same control in our Xcode projects, so we specify the Ruby version in an .rbenv-version file:

1.9.3-p327

Always check in the Pods directory

Since there is no global repository for CocoaPods every maintainer of a library is responsible for keeping his versions online – which has actually gone wrong in the past. Some versions disappear or repositories are temporarily offline. So check in the Pods directory in your version control guarantees that you can reconstruct a specific version at any time. Also you don’t have to tell your designer friends how to install CocoaPods.

Through all that practices we can guarantee that a new developer is always getting the same environment for development without surprises. Hopefully CocoaPods will add the feature to update a specific pod in the near future. If you want to see the efforts of our latest app then download our social video player Watchlater.

There are a lot of awesome jQuery plugins and Javascript libraries out there, and with every new one it gets more difficult to keep track. Some might save you hours of work, others just add that teaspoon of UI love, that little big detail, that separates a good UI from a UI that feels great and makes using your app fun. Here are some of our picks – virtual chocolates, all sugar-free and low-calorie.

Feel free to add yours in the comments!

Galleries

• Nivo Slider lets you create image sliders with transitions. [Demo]
• jQuery.popeye is an alternative to lightboxes, especially if you don’t want to disrupt the user experience by having a modal window pop up. [Demo]
• Infinite Carousel displays your images in a continuous loop. [Demo]

UI Helpers

• grumble.js lets you create bubble style tooltips you can freely position and rotate.
• If you’re not into bubbles, try tipped. It has everything, from the simple classic one-line tooltip to more advanced ones.

• If you need custom drop downs with images and descriptions, try ddSlick. [Demo]
• Before you code that tag form field with autocomplete, check out TextExt – it might save you a lot of work.
• Have users explore all the awesome details of whatever with Magnifying Glass. It’s just an eyecandy, but isn’t it always about the little details?

• Avgrund displays nice modal boxes with depth of field.
• jQuery Stick ‘em can make elements stick to a fixed point as you scroll. Useful for explanations in the sidebar. [Demo]
• noty is a slick alternative for jQuery’s standard alert dialog. It provides a queue and several layouts.

Typography and Text

• If you’re looking for down-to-the-letter control and kerning of your type, kerning.js and Lettering.js might be for you.

• Love big responsive headlines? Try slabText.
• With Cutter.js you can truncate HTML code without losing the markup.
• No excuses for ugly unformatted documentation: Create instant Markdown documents with Strapdown.js.
• Speaking of Markdown, Showdown is a Javascript port of Markdown.
• Looking for a lightweight syntax highlighter? Look no further: Prism.js

Data

• list.js makes your HTML lists and tables searchable, sortable and filterable.
• If you rather sort by drag and drop, HTML5 Sortable is for you.
• Remember that sleepless night some weeks ago when you thought it might be a fun project to code Excel for the web? Have a look at Handsontable. It’s a data-grid editor.
• For displaying large data sets there’s Pivot.js.

• For even larger project, try Datatables .

Responsive Design

• Wanna serve high resolution images for users with Retina displays? Retina.js is here to help.
• foresight.js is an alternative to Retina.js that detects whether the user has a Retina display and a fast enough network connection for hi-res images.

Form Styling

• Replace endless select boxes with a more user-friendly alternative with Chosen.
• For even more select box awesomeness, have a look at Select2. It can use remote data sets, offers multiple select and tagging.
• Super Labels is a nice and user-friendly way to label form fields.
• prettyCheckable brings better looking checkboxes and radio buttons.

Forms

• Ideal Forms is a framework that helps you build and validate your forms.
• As a lightweight alternative, there’s validate.js.
• Need to validate credit card numbers? jQuery Credit Card Validator
• Tired of users misspelling their email address? Try mailcheck.
• If you want to offer users the possibility to search using complex queries, VisualSearch.js might be for you.
• Give your users feedback about their password strength with Complexify.

• Add pretty file uploads to your app with jQuery File Upload. It’s got progress bars, image preview and uploads are resumable.
• If you just want the resumable uploads, go straight to resumable.js – it does just that.

Time Savers

• Has this ever happened to you: You started filling out a lengthy form on some website, and halfway through the process your browser crashed and everything you entered was lost? Yeah, that sucks. Protect your users from mishaps like this with Sisyphus.js.
• For money and currency formatting there’s a little helper called accounting.js.
• If you not only want to display currencies, but also convert them, check out money.js.
• Formatting, parsing and validating dates is another tedious task. Let moment.js do it for you.
• Smart Time Ago intelligently updates the relative timestamps in your document.
• cookies.js is for managing … – guess what – cookies!
• For zipping and unzipping files, there’s zip.js.
• With string.js come handy methods like slugify, truncate() and isEmpty().
• Let’s be honest: Google Maps is awesome, but its Javascript API can really be a pain. gmaps.js soothes this pain.
• If you need a preloader for your HTML5 game, try PxLoader.
• Working with URIs a lot? URI.js can help you. It offers methods for working with query strings, detecting URIs within text and much more.
• For dealing with touch events in the browser, there’s Touchy.js.

This is a collection of things we’re using in our day to day projects. We find these things on Smashing Magazine who originally created a post with useful plugins, additional links came from Daily.js and Badass.js.

Many thanks to all the hard working developers who created all these plugins – you make a better web happen!

Building websites today is usually a totally bloated and inefficient process: First, there is a designer who creates layouts and designs in photoshop. After that, the designs are iterated together with clients or teams. Making changes to the overall design in Photoshop, e.g. changing fonts, colors and margins is a ridiculously time-consuming task – compared to making the same changes in css. After the designs are finalised (or even worse – not finalised) some poor coder is asked to build HTML & CSS markup. A tedious job, if you’ve done that, you probably know what I mean. And then, there comes the CMS, but I will just skip that topic for now.

If I remember correctly, we had the same process already 10 years ago. Some earlier versions of Photoshop for the designer, and a different text editor maybe. But there has always been this huge friction within this process, mostly due to the several tools and stakeholders involved in it. (And because Photoshop is NOT a web publishing tool).

Worst of all, it makes it very hard for non-coders to easily create something beautiful in the web.

When Sebastian and Stefan were guest lectures at the Hochschule für Gestaltung in Offenbach, they realized that there was no tool for design students to build their portfolios in a “what you see is what you get” fashion. There were some CMS solutions, like squarespace, but these work with templates. It was simply not possible to instantly create and design for the web. That’s what they wanted to change with Salon.io, and we were happy to help here.

Technically, there were all the ingredients to develop such a product:  Thanks to HTML5, we were able to create a drag’n'drop interface. We made it a single page app, using backbone.js, which was essential to make salon feel as smooth as a desktop app. In fact, salon is one of the very first backbone applications we’ve created and backbone itself was still in it infancy (v0.3).

After over a year of development, already thousands of designers, photographers and illustrators have created their portfolios with salon. It’s definitely worth to check out some of the great examples what they have built. The user-feedback is overwhelming.

Salon.io is malleable and allows designers to move closer to a flow of creativity. The ability to stream consciousness and employ improvisation in web design is now becoming a very possible thing with Salon.io
Naveen

The Salon team has chosen not to take any VC money, this is why we kicked off a crowdsourcing campaign for salon over a month ago. Now, everyone can get premium memberships for half of the price and support further iterations on the product. After all, there are still so many awesome things in the pipeline.
If you haven’t tried out Salon, you should definitely do that. Chances are that you will enjoy this whole new way of publishing anything online.

And please spread the word to support Salon.io.

Dalton Caldwell and his team had a crazy idea to create a new social network called App.net. They also had a crazy business plan – people should actually PAY for being part of that social network: $50 for a yearly membership. Blasphemy! But it worked. Through a kickstarter like campaign they successfully raised over $750.000.

Now unlike to other startups real money is involved – and that changes everything. App.net can give a shit on advertisers and or even more crude monetization strategies. They won’t have to sell your data to 3rd parties. They won’t have to screw their developer ecosystem. They just have to make their customers happy.

And it works! All basic functions looks pretty solid and it’s superfun to read the global timeline (remember the early days of Twitter when that was possible too). The API is ready and all over the mighty internetz people are talking about what to do next. Third party apps are popping up for the web or mobile platforms, there is a brief list on their GitHub page.

It’s really impressive to see what people are building just within a few days.

But with all the praise I have to admit that the things you can do on App.net are really basic and they have to proof their “raison d’être”. That are the features that I’m expecting in the near future:

App.net should be a interface that reflects my digital me. I want to put information inside, I want to pull information out. Let’s get rid of the data silos. For example when I’m changing my email I have to login to a plethora of web services and change my email for each one of them. Why can’t I change my email at a centralized point and all the services will know how to notify me? I want an easy to use single sign on mechanism with fine granular control over which data will be shared or modified.

I want to add arbitrary data to my digital profile. Some of the data should be semantically structured, but I want to be able to add arbitrary data (even if it just makes sense for me). I want to add semantic information to a post, like Twitter does with Twitter Cards. And for arbitrary data let me or other developers define aggregations like Facebook does with the Open Graph. Let me access the data in any format I want (json, rss, etc) and don’t forget that there has to be something like a realtime notification system in case my data changes.

Please let me also connect to people that are not App.net (for some people $50 is a lot of money). They may be on Twitter, Facebook or Google Plus. It’s sufficient that I can maintain my friend graph and that I know how to contact them. It might also solve your problem with reach.

I understand that some of these wishes are difficult technical challenges – especially at scale. But I believe that the open web has to go there and explore what’s doable since the status quo is a mess.

PS: And please create a repost mechanism fast – I need it ;-)

Now have fun:
http://forgif.me

That said, we open sourced the code, so grab it on github if you like to play around.