Harp.js and Heroku

Harp.js is an awesome static web server with built-in preprocessing. It supports Jade, Markdown, EJS, CoffeeScript, Sass, LESS and Stylus as HTML, CSS & JavaScript, with no required configuration!

Harp doesn’t require any configuration to get started. Simply ensure you have Node.js installed and then run the following commands:

sudo npm install -g harp
harp init myproject
harp server myproject

Harp supports some very cool features that most developers will be familiar with, for example Yield, Partials, Globals, etc. You can also easily add a simple blog and basic authentication.

Before you start coding, I would check out their great documentation, starting with "The Rules".

Once you've got your application running, you can deploy to Heroku in a couple of simple steps:

There are two files you’ll need to add to the root of your Harp application (not inside the public directory). The first is "package.json", which should look like this (note the "harp" dependency):

 "name": "My-Harp-App",
 "version": "1.0.0",
 "description": "A Harp App on Heroku",
 "dependencies": {
 "harp": "*"

Next, create a "Procfile", containing the following line:

web: harp server --port $PORT

Thats it! You can now push to Heroku and your application will be live!

Less with Grunt

Less is a CSS pre-processor which helps you develop, extend and maintain complex CSS.

I now use Less by default when starting a new project, as it promotes simplicity and reuse, two things that can often be lost when building complex, response web applications.

One of the great things about Less, is that it is easy to pick-up for anyone that has experience with CSS. This is because Less uses standard CSS syntax, making it backwards compatible and easy to extend.

What actually is a CSS pre-processor?

A CSS pre-processor enables a developer to write CSS in a programming construct instead of static rules. For example, Less supports variables, nesting, mixins, operators and functions. These mechanisms allow the developer to manage CSS as if it were application logic, making it more maintainable, themable and extendable.

A very simple example, would be the use of variables:

@green: #006600;
@light-green: @green + #111;

#header {
color: @light-green;

In this example, you can see the variables green and light-green were declared and then made available for reuse. Simple, but powerful when compared to CSS static rules.

Automating Less with Grunt?

One of the (minor) downsides to any CSS pre-processor is that they must be compiled into CSS. To get the most out of Less, I recommend setting-up some simple automation, which essentially removes the compilation pain.

To do this I use Grunt, which is a JavaScript Task Runner. Grunt enables you to automate repetitive tasks like compilation, magnification, unit testing, etc. The other great thing about Grunt, is that it has an incredible ecosystem of plugins, making it very easy to get started. My personal favourite plugins are:

When working with Less, I use Grunt to watch my Less files and automatically compile any changes. As a result, any changes are instantly available within my application, which helps to streamline the development process.

Once I hit a logical milestone, I use Grunt to minify the output into optimised production ready code.

Getting Started

Getting started couldn't be easier, simply head over to the Less and Grunt websites and follow their excellent installation and configuration guides.

Enterprise Force.com Architecture - Continuous Integration

Force.com is a great place to build enterprise applications!

In my precious articles, I've outlined the value proposition for the Force.com PaaS, as well as shared my thoughts regarding org strategy and development methodology.

Building on this content, I wanted to share a reference architecture, covering environments, code management and deployments.

This reference architecture is specific for enterprise organisations who are looking to leverage Force.com as an application platform as a service. This means you are looking to simultaneously build multiple applications, across multiple development teams, that will be hosted in a single Salesforce.com production org.

NOTE: Enterprise development can be complex. This post will only provide a summary of the reference architecture, although where possible I will post follow-up articles providing more detail on specific areas.

There are many ways to deploy code to Force.com, however for enterprise organisations I only ever recommend the Force.com Migration Tool (e.g. Ant) and Continuous Integration (CI).

Continuous integration is not unique to Force.com, it's a practice in software engineering, of continuously merging all developer working copies with a shared mainline. This methodology demands a high level of automation, which helps to reduce errors by frequently testing small pieces of effort and providing constant feedback to the developer. 

To help explain the reference architecture, let's start with a diagram:

At the top of the diagram I've highlighted two capabilities:

Git, which is a distributed source code management system with an emphasis on speed and data integrity. Git is used to manage all source code (including meta-data) for all of the projects that are being developed for Force.com. Every project team should have their own private repository, which enables them to manage their code via different branches. There are plenty of Git services available, however the most popular are GitHub and BitBucket.

Jenkins, which is the industry standard for continuous integration. Jenkins automates code deployments across different environments, as well as facilitates the testing process. You can host your own Jenkins instance, but I would recommend a cloud-based service such as CloudBees.

These two capabilities facilitate the entire development process, making the end-to-end application lifecycle management significantly simpler to manage and support.

Next we have the different environments. Every production Force.com org comes with a suite of development sandboxes (the exact number depends on your agreement with Salesforce.com). These sandboxes can be created ad-hoc and are a direct replica of production (however do not include any data). There are also different sizes of sandboxes (e.g. DEV, DEV Pro, etc.)

To ensure you leverage these environments efficiently, the reference architecture is split into two halves.

Developer Owned (Left Side)

On the left side of the diagram, we have the developer tracks, these are fully owned by the development teams, providing complete autonomy. Every development team (which could be working on multiple apps) will be provisioned three sandboxes:

DEV = Main development environment.
CI = Continues integration merge / build test environment.
TEST = Formal user testing environment.

A traditional development pattern would be:

  1. All development will occur in the DEV environment, leveraging an IDE (e.g. Eclipse or MavensMate) and Git.
  2. With every commit to Git, Jenkins will automatically build the code in the CI environment. This will confirm that the development has not broken the build or created any conflicts. In the event of a failure, the development team will immediately be notified (via e-mail or even social tools such as Chatter or Slack).
  3. Finally, any code positioned for a release to production will be moved into the TEST environment where formal testing (including UAT) can occur. This is also managed by Jenkins, but triggered by the development team by selecting a specific tag from Git.

In a perfect world, every developer would have their own DEV sandbox, however, at the time of writing, Salesforce.com only offer a restricted number of DEV Sandboxes to their customers. As a result, developers within a specific development team would share the environments (DEV, CI, TEST). This actually works fine, but obviously requires some level of coordination, which is where development methodologies such as SCRUM Agile are key!

Production Org Owned (Right Side)

On the right side of the diagram, we have another set of environments, specifically:

CI = Used to test / merge code from the different development tracks. 
PRE-PRD = An exact replica of PRD, including the full data set. A final testing environment for the development teams.
PRD = The production environment, where the live users will access the applications.

These environments are used to merge and test all code from the different development tracks, ready for a specific production release. The actual process remains consistent, leveraging Git and Jenkins to automate the deployment between environments.

Production releases can be as frequent as required, however it is common for enterprises to start with monthly releases and progress to weekly as they gain confidence. The good news is that the reference architecture is highly scalable and could easily manage multiple production releases per-day, should this become a requirement.

The two sides of the reference architecture are important as they provide a clear control point for the team that is accountable for the production Force.com org, ensuring that no unapproved code is deployed into production.


Hopefully this information provides a good overview as to how Force.com can be leveraged as an enterprise application platform as a service.

The key is to recognise that the reference architecture provides autonomy for the development teams, whilst providing a consistent control point that protects the production environment. Thanks to the high levels of automation, it also enables high levels of agility, without negatively impacting quality.

Jekyll on Heroku

Jekyll is a fantastic static site generator, allowing you to turn plain text into websites or blogs with just a few clicks!

Static site generators have been growing in popularity over the past year thanks to their speed, simplicity, portability and ease of management. Essentially they allow you to focus on your content and host the output almost anywhere, instead of you having to spend time configuring and maintaining a traditional content management solution (e.g. WordPress, Drupal, etc.).

Thanks to its Ruby roots and open-source nature, I've started to host a number of blogs using Jekyll and have found the experience to be a developers dream.

Arguably the easiest way to host Jekyll is via GitHub Pages, however I have a lot of apps already running on Heroku and therefore favour it as a service.

This post will explain how to deploy your Jekyll site to Heroku in five simple steps:


Before proceeding, I assume you have already installed Jekyll. If not, start by checking out the excellent Jekyll Installation Documentation.

Step 01:

Add a "Gemfile" in the Jekyll project containing:

source 'https://rubygems.org'
ruby '2.1.2'
gem 'jekyll'
gem 'kramdown'
gem 'rack-jekyll', :git => 'https://github.com/adaoraul/rack-jekyll.git'
gem 'rake'
gem 'puma'

Run "Bundle Install".

Step 02:

Create a "Procfile" which tells Heroku how to serve the web site with Puma:

web: bundle exec puma -t 8:32 -w 3 -p $PORT

Step 03:

Create a "Rakefile" which tells Heroku’s slug compiler to build the Jekyll site as part of the assets:precompile Rake task:

namespace :assets do
task :precompile do
puts `bundle exec jekyll build`

Step 04:

Add the following to the "_config.yml" file:

gems: ['kramdown']
exclude: ['config.ru', 'Gemfile', 'Gemfile.lock', 'vendor', 'Procfile', 'Rakefile']

Step 05:

Add a "config.ru" file containing:

require 'rack/jekyll'
require 'yaml'
run Rack::Jekyll.new

That's it! You can now push your code to Heroku like normal.

Git - Cheat Sheet

Git is the undisputed king of source code management! However, it can be a little daunting for new users, especially as most developers and online guides favour the command line. 

Thankfully,  there are a set of common commands that cover 80% of my standard workflow.



Initialising your repository, updating the index, record changes and pushing to the remote.

git init
git add .
git commit -m "Initial Commit"
git push origin feature


Remote Setup

Manage set of tracked repositories.

git remote
git remote add origin <https://github.com/teamname/reponame.git>
git remote -v
git remote rm origin



Clone a repository into a new directory.

git clone <https://github.com/teamname/reponame.git>



Fetch from and integrate with another repository or a local branch.

git pull <https://github.com/teamname/reponame.git>



Branching is a powerful way to manage your code, I highly recommend following a branching methodology such as Git Flow.

git branch
git branch <branch name>
git checkout <branch name>
git checkout -b <branch name>
git branch -m <branch name>



Join two or more development histories together.

git merge <branch>



Tag specific points in history.

git tag TAG_01
git push origin --tags



If you work on a Mac, you will probably also have pesky ".DS_Store" files cluttering up your repository. To remove them run the following command (don't forget to also add .DS_Store to your ".gitignore" file.

find . -name .DS_Store -print0 | xargs -0 git rm -f --ignore-unmatch


If you're unsure about any of these commands, I suggest you head over to the official Git documentation.