Jenkins is a fairly nice self-hosted CI server, fit for most uses. It's not perfect though: UI is rather ugly reminiscent from the early 00s, it has enterprisey feeling due to its Java focus, and it can be resource hog at times. But nevertheless Jenkins is easy to setup, it is very flexible and has plugins for most needs.

In this tutorial I'll show an example on how we did setup Jenkins as CI server for our JavaScript app at Applifier. Our app consists of APIs written using Node.js and frontend using Backbone.js, but most of this is valid for any tech.

Let’s skip the basic Jenkins setup, there’s plenty of tutorials for that. Come back after you've installed Jenkins and configured basics such as security (e.g. role-based strategy is quite simple to setup).

This is a quick guide on what software I just installed when setting up a new Mac.

Building a more complex JavaScript app can easily get out of hand if no effort is put into architecturing the application. In this post I'm overviewing some of the most common higher level architectural patterns and concerns that you should consider when building modular single page apps using Backbone.js.

Transition from building traditional web apps doing full page reloads into dynamic single page app often requires rethinking the application architecture. You cannot just hack together some random jQuery code, because you're storing application state in client and managing it quickly becomes spaghetti. On the other end I've seen some bad examples of over-engineering your app, so think carefully what kind of architecture suits best for your app.

Single page apps should usually be architectured more like desktop apps, thus Smalltalk-80 like MVC fits quite naturally as a basis for modular, object-oriented application's architecture. MVC is only part of large application's architecture though - it only solves how to layer your modules into models, views and controllers.

Backbone.js provides an easy starting point for MV* like structure, but it offers just mainly low-level patterns. What about bindings between objects, inter-module communication, dependency loading, handling JST templates, view layouts, memory management and object disposal? The former are example issues that Backbone.js leaves open for the developer to implement. This has been a design choice with Backbone.js - it has small core but missing parts can be added as libraries when needed.

Now in the case of more complex application you could pick some of the more full stack frameworks, add some of the open source projects providing the missing parts on top of Backbone.js or build your own framework. There's always a tradeoff with large frameworks, e.g. ember.js provides much more out of the box but it's 20K LOC and opinionated.

I prefer a micro-framework approach where you have a small core framework and you can easily add additional libraries. Bindings, dependency loading, etc. higher level architectural issues are things that many developers disagree on how to implement those. Backbone.js leaves it open for developers mix and match components that suit their needs best, which is great.

There seems to be hundreds of language specific build tools for everyone's needs, and somehow I feel that wasted energy could be spent on building more useful things. Often a small Makefile) is all that you need. 'make' may seem like complicated tool at first but learning the basics is quick and highly recommended.

GNU make has been built for detecting which parts of a program need to be recompiled, and issuing commands to recompile them. The most common use cases for frontend asset building are:

• You need to concatenate and minify your assets for production use
• You want to compile SASS/LESS/Stylus files to CSS and .coffee files to .js when developing. To make things convenient this should be automatically done on file modification without the need to run any commands.
• You want to run other tasks on file save; such as linting or running tests
• Deploy files to production Using 'make' is convenient because you don't need to introduce another dependency for your project since every developer should have 'make' preinstalled (as long as they are using Unix based OS). Once you learn it, it's easily portable, and can be used any project regardless of the environment, avoiding the need to learn language specific build tools. If you build your Makefiles right, it should be just few lines of code, which makes it simple and easy to maintain.

One thing you will need, is a tool for periodically running 'make' . I recommend installing watch by TJ Holowaychuck, which excutes a given command on selected interval. This is very lightweight way of detecting file changes, and doesn't use any processing power when there's no changes to be compiled (unlike when using many language specific build tools).

git clone https://github.com/visionmedia/watch.git
cd watch
make install

Here is a sample Makefile from my Rewindy project:

When you start working on the code, run

    make watch

which runs the necessary commands to compile your asset files immediately after change. Combine this with tools like LiveReload, and you'll have a pretty smooth build process.

Sometimes you'd like to have shared methods across classes, but it's not possible or it doesn't seem natural to create a shared parent class. CoffeeScript and Underscore make it fairly painless to create reusable patterns for your classes using mixins.

When using Chaplin, application views are normally extending CollectionViews and Views. It usually makes sense to make custom subclasses for both, which application views then can extend. Now, lets say I'd like to add Google Analytics tracking functionality for user actions. I'd like add this tracking functionality to both types of views, thus I cannot create a shared parent class for both.

One solution could be to make custom base classes for both types, but that would mean that I would need to copy-paste the same method to both base classes, which would make it ugly and difficult to maintain. In this case we need multiple inheritance, which can be implemented using mixins. Our mixin is defined as object literal which has shared attributes and functions required in our views.

Then in your base view you can use this mixin with:

You can also use Mediator's publish/subscribe pattern for doing this elegantly, but this could be one alternative way to do it. In my base_extensions.coffee, there's also view helpers e.g. for i18n and template handling.

Mixins are great way to structure your app into smaller and reusable components. Check also Chaplin's source on how they are using mixin to source in Subscriber which offers functionality to subscribe to global Publish/Subscribe events to any object.

I haven't seen too many good blog posts on how to build architecture for a modern, frontend-heavy HTML5 app, so I thought I'd try to explain our stack while choices are still fresh in memory. We are just getting started (just started private alpha) so things will still change and evolve.

Don't reinvent the wheel. I believe that especially in an early-stage startup the best code is the code you don't need to write yourself(SaaS) and best way to host your server is let someone do that for you (PaaS). When choosing components for Rewindy, we opted for choices that got us moving as fast as possible. Performance and scalability are good to keep on mind but there's time for optimizing later, if the app succeeds.

Plan was to use a third party service or existing component whenever possible instead of building our own, even though sometimes that means making few compromises. That allows us to maximize the development on our core business. Surely later it makes sense to start replacing suboptimal parts in the system with custom code or servers, if that is needed for cost or performance reasons. Still it's good to keep in mind that often you don't need library or framework for that feature, a few lines of code will do just fine. Choose the best tools for the job.

It's been way too long no blogging, but now I'm starting this blog again. I moved away from my custom blogging platform and I'm using Octopress, hosting pages in GitHub.

Setup and migration was a snap and only issue was converting old posts written in Textile formatting to markdown. This demo of Pandoc did help.

Using CSS3 isn’t quite as easy as it should be. Lots of advanced functionality requires using vendor prefixes which easily bloats your stylesheet with repetitive properties.

One solution to this is using Sass. Especially Sass mixins and color functions can radically reduce the amount of code you need to write. Combine that with CSS3Pie to add IE support and you have quite elegant solution for making cross-browser supported CSS.

Here are some zsh helpers for Google App Engine will save you lot of typing in the long run. I’ve extendend the oh-my-zsh project with my own plugin for Google App Engine, but you can easily just add these to your .zshrc.

Christian Tietze has done great job forking Notational Velocity to support previewing markup using Textile, Markdown or MultiMarkdown. You can also export text as html, in case your blog engine doesn’t support these markup formats. It’s now my favorite tool for editing blog posts. Good job!

True hacker makes his own keyboard!

Well, maybe not. But many international keyboard layouts suck for programming. For example with Finnish keyboard you have to type Alt + Shift + 8 to get }. Now that’s a pain to type gazillion times a day.

To increase my productivity, I decided to create my own keyboard layout using Ukelele OSX app. First I was considering using Dvorak or its programmer’s variant, but then I realized it would have its issues with VIM key mappings and having to relearn everything would require a lot of practicing. So instead I based mine on the Finnish layout.

I just received my new Kindle3 from Amazon. So far it seems like a great device for the price (150 EUR shipped to Finland, including all expenses). The screen is great, battery lasts long and size and weight are good for e-reader. The UI is still clumsy and feels very outdated, but with a little tweaking, it does the job. First things I did was:

Terminal is perfect tool for hackers but it can increase anyones productivity.

ZSH is my default shell in Mac now. Read [My Extravagant Zsh Prompt](http://stevelosh.com/blog/2010/02/my-extravagant-zsh-prompt/ or "zsh: The last shell you'll ever need!":http://friedcpu.wordpress.com/2007/07/24/zsh-the-last-shell-youll-ever-need/) why you should choose ZSH over OSX's default Bash.

The 1.3.6 update for App Engine introduced support for multitenancy using namespaces. You might want to read the introduction by Nick Johnson to read what it means. Here is a snippet for function decorator allowing you to run function in given namespace. Code is based on this.