chrisblunt.com

Business Startup Week 1: Plymouth Software

2010-07-26T00:00:00+01:00

Last week, after nearly 4 months travelling, I got back home and started up my new business. After a few years away from self-employment, I was pretty excited, but still felt the nerves that go hand-in-hand with setting up by yourself.

Things were made easier, though, as Claire has also spent the week setting up her first business, ExpressVA Services, so we're working through the process together. Unsurprisingly to those who know her, Claire is a lot better organised than me!

Does what it says...

To get started, I set off in search of a name. I spent ages working through all the crazy/funky/web/tech/company names I could think of, before deciding just to keep it simple. After a couple of clicks to register a domain, I knocked up a quick logo and website, and Plymouth Software was born.

Meeting the bank manager

Next up was a business bank account. Although not strictly necessary, but I found it made accounting and tax returns much simpler last time. Whatsmore, HSBC still offered their excellent Business Direct account, which is as good as free to businesses that don't handle much cash.

I had a great experience with HSBC during my freelance days, so didn't hesitate in walking into my local branch and stepping out an hour or so later with a shiny new account. I was beginning to wonder if things were going a little to smoothly!

The main reason I needed a business account was so I could setup PayPal Pro, the gateway I'll be using to take Amberleaf subscription payments. Again, I setup the account online - with a minor hiccup, which was easily corrected - and waited to get approved.

Switching on Amberleaf

In the meantime, I've been tidying up Amberleaf, fixing little bugs and niggles that had surfaced. All in all, though, it seems to have stood up pretty well during my absence. It continued to get a steady stream of subscribers to try out the beta, and the feedback has been very positive.

Yesterday, my PayPal Pro approval came through, so I've been working away to implement a live Spreedly account. Over the coming days, I'll be switching off the beta plan and making Amberleaf live! Existing users will just need to subscribe to the new plan when they log in. I'll be sending out an email giving detailed instructions. Everyone gets a 30 day free trial.

I'm really looking forward to finally launching Amberleaf, and developing its features. In the pipeline are big improvements to some of the UI, and mobile device integration.

If you're a web developer, domain reseller, hosting provider, or do anything remotely domain-related, why not check out Amberleaf to see how it can help your business. I'd love to hear your feedback and experiences with the software. You can tweet me, or you can send through Amberleaf itself.

Short notes on a Long Trip

2010-07-22T00:00:00+01:00

Arriving into London Heathrow Terminal 5 after nearly 4 months away, everything started to feel a bit strange. Our flight from New York had done nothing for my nerves, turbulent from start to finish. We both got no sleep on the overnight flight, so were set for a pretty long day. As we walked into the arrivals hall - somewhat light, as our bags were following us on the next flight - the past several months suddenly seemed a lifetime ago.

The Trip

After leaving Hong Kong, Claire and I had endured another sleepless flight down to Sydney, several hours wait, and then a final flight back up to Cairns where we would start our tour of the East Coast.

Australia

We both loved Cairns; warm sunshine, and the friendly, laid-back attitude hit us the moment we landed - as did the heat! After a couple of day tours to explore up to Cape Tribulation, and Kuranda (where we were pleasantly surprised to see Devonshire Cream Teas on offer!), we spent the next 5 weeks travelling down the coast on the Greyhound.

Every stop was memorable - from the quiet eeriness of Magnetic Island; the calm tranquility of Cool Bananas in Agnes Water; and the stunning city of Brisbane right through to Australia Zoo (we stopped at Caloundra); our 11 mile walk around Port Macquarie; and our visit to the Koala Hospital.

It's not until you see the distinctive sails of Sydney Opera House that it feels like you're truly in Australia, though. We spent a few days in the city, and took an awesome trip out to the Blue Mountains with Jimmy at the Happy Coach Company. This was a hilarious day, and I'd highly recommend their tours.

We stopped off at Canberra for a night, and then travelled through to Melbourne. We both loved Melbourne's very different, European style that set it apart from the other Australian cities we'd visited.

New Zealand

From Melbourne, we flew across to Christchurch, New Zealand. Hiring a car for just NZ$1 a day, we travelled the South Island for a couple of weeks, our jaws dropping at the incredible scenery. Thankfully there was barely a car on the road, as our little DollarMobile struggled its away across vast mountains, up to Milford Sound, across the Cardrona Range (with a cheeky stop at the Cardrona hotel for a fantastic cream tea!) and down to Wanaka and Hawea.

Travelling the West Coast, we stopped at the powder-blue Fox and Franz Josef glaciers, and also one of my favourite spots - Punakaiki. There's plenty of trails here, as well as the mysterious Pancake rocks and blow holes. It was the Te Nikau accommodation, though, that made the stay. A friendly and homely cottage atmosphere; a log fire burning away in the corner of the lounge area; free fresh-leaf tea; and freshly baked muffins and bread every day. Like so many others who had written in the guest book, I was sad to have only stayed one night.

We headed up to Nelson and Picton (Sequoia Lodge does great, fresh and free chocolate pudding every night!) before catching the stomach-churning ferry across to the North Island. Crossing the Cook Strait is renowned as one of the most picturesque sailings in the world, but the weather was against us and we had high swells and low visibility.

A short and painfully cold stopover in Wellington started our trip around the North Island, where we would head to Napier, Taupo, Rotorua and Hamilton, resuming our Australian-trait of walking miles around the towns, and discovering more strange natural phenomena - the Wai-O-Tapu geothermal parks are like something from a science fiction movie.

Fiji & The USA

After 5 weeks in New Zealand, and exploring Auckland and a few stops in the Northland, we flew out to Fiji's Coral Coast. Our stay here was perfect. During our week here, Claire would finally try eating fish - and liked it! - thanks to the awesome chef at the Hideaway Resort. Amongst lots of relaxing, I decided to give SCUBA diving a go with Diveaway Fiji, and instantly regretted leaving it until the last day. If you go there, make sure you leave enough time to book a second dive - it's incredible!

After a full week of serene relaxation in Fiji, we flew up to Waikiki, Hawaii with a stopover in Christmas Island. Crossing the dateline was very strange - we experienced two Tuesday 23rd Junes. Claire summed up the craziness when she pointed out we'd landed in Christmas Island (for a stopover) tomorrow. It was easy to see where inspiration for Lost might have come from (I've still not seen the finale, though!).

Hawaii was great, and although Claire spent the first day suffering from extremely bad insect bites, they were soon sorted out and we enjoyed a few days exploring the city and visiting Pearl Harbour.

As our trip's end grew closer, we stopped for a few nights in San Francisco, which was like walking around a movie set! It all looked strangely familiar, and we loved the Bay area spending every day walking and exploring new parts. We were also lucky enough to be there for July 4th, and watched the fireworks display from Ghirardelli Square.

We caught a short flight to Las Vegas, where we finally picked up our marriage certificate from Christmas; and then travelled on to New York to arrive in the middle of a heatwave. Unfortunately, the air conditioning in our room had packed up, but the guys at Chelsea Star were quick to fix it though, and New York was as incredible as expected. On our final night, Claire fulfilled her dream of going to the top of the Empire State Building, from where the sunset views across the city were truly stunning.

What's Next

So it was with a bump we came back to reality, and two weeks on I'm not sure being home has sunk in yet. We're both starting up businesses, Claire racing ahead with ExpressVA Services, and me frantically remembering Rails code to develop Amberleaf. I'm also setting up Plymouth Software to carry Amberleaf and Android app ideas I've been thinking about.

To squeeze our experience this short post is impossible. We learned so much and met great people who we'd love to stay in touch with. We've seen and experienced things that we couldn't even have imagined.

Claire and I both kept daily journals, which we'll be typing up and publishing as EBooks shortly. We've also jotted down the places we stayed, the sights we've seen and places we would recommend - but you'll have to check out the ebook to find the best rated tea!

Short notes on Hong Kong

2010-04-21T00:00:00+01:00

After 3 weeks of travel, I'm finally finding time to write something for this blog! Although such a short amount of time, a lot has happened since we left Heathrow on our 12 hour flight to Hong Kong.

When Claire and I landed, the rain was pouring! We managed to get a bus into the city, but with no idea where to get off, we relied on photos from Google! Thankfully, it paid off, and we were soon at the Oriental Lander, a compact hotel in the north of Kowloon.

We strolled down Nathan Road, something we would do a lot over the next few days as we bounced between Kowloon and Hong Kong aboard the Star Ferry. Excellent value at just HK$2.40 (about 24p) each!

The city is an amazing clash of eastern and western cultures - whilst Starbucks and Burger King straddle one side of the road, traditional Chinese medicine stalls and dried fish cover the opposite streets. Language wasn't too much of an issue either, which was a relief, as almost everything was written in English...

We sampled some tradional Chinese food, and whilst still unsure of some of the things we were eating, it all tasted very nice!

We headed up to the Peak for views across the harbour, but although the rain had long gone, cloud still hung heavy in the air, so we could barely make out any buildings. Undeterred, we walked around some of the tracks across the Peak, and got some good photos!

At night, the view across to Hong Kong harbour from Kowloon is incredible, and we made sure to get plenty of pics. The buildings here are on a scale you have to see to believe-we were both very impressed!

On our last full day in Hong Kong, we travelled to Lantau island to see the famed 'Big Buddah'. He is indeed big, and the surrounding countryside is breathtaking. After climbing the steps and exploring the neighbouring monastery, we hopped on a bus to the fishing village of Tai O.

Here, we walked through the bustling fish markets and through the village houses to a lookout across the ocean where we could see Chinese White dolphins breaking the waves. Again, the landscape was like something out of a book, with lush green mountains surrounding us, and the Big Buddah emerging every so often through the mists that passed over their peaks.

Our final day in Hong Kong was spent exploring more of the city and Hong Kong island. As recommended by our travel guide, we seeked out the Luk Yu tea house (along Stanley Street) for a well deserved brew.

Whilst Claire was initially concerned we might be spending a fortune on Dim Sum, her fears were alleieved by the lovely green tea, and - more importantly - endless refills of the teapot on offer.

Hong Kong is a truly amazing place, and we both enjoyed our short stay there. We sampled plenty of tea and famed Hong Kong cakes, and were very surprised by the seemingly slow pace of the main streets.

Being a huge financial and business centre, we'd expected streets rammed like London's Oxford street, but instead everyone along Nathan Road seemed to stroll along at a pleasant and relaxed pace.

We left Hong Kong for the next leg of our journey to Australia, happy to have finally seen that world-famous skyline and sampled some very new foods.

During our travels, we are keeping journals that we'll eventually write up on our return. It would also be great to get some photos up, but finding free (or even cheap!) Internet in Australia, and somewhere that can read SDHC cards, is proving nearly impossible.

Hopefully we'll be able to find somewhere as we travel down the East Coast. In the meantime, you can follow us on Facebook and Twitter.

Lanyon: An Email and Web Interface to Jekyll

2010-04-01T00:00:00+01:00

I really like the idea of sites like posterous which use email as an interface for publishing content. However, I just moved this site to use static content built by Jekyll, and didn't want to maintain multiple blogs.

So I created Lanyon, a quick Rails 3 app I built in an attempt to bridge the simplicity of Jekyll with the accessibility of email/web publishing systems like Wordpress. Lanyon polls an email account for posts and, when detected, automatically publishes them. It can also automatically commit and deploy your blog using Jekyll, so posts appear without the need for manual intervention.

Lanyon also provides a rudimentary web interface to your blog, so you can create, edit and delete posts.

Lanyon gives you the advantage of being able to publish from anywhere, but still maintain the simplicity of static content created by Jekyll.

I wrote Lanyon to allow me to post to this site as I'm travelling (we leave for Hong Kong tomorrow!). If all goes to plan, I should be able to post entries without the awkwardness of vim and SSH on a mobile phone.

So here's the first test...

Amberleaf: Pricing Announced

2010-03-17T00:00:00+00:00

Today I released a small update to Amberleaf that includes details of the pricing and subscription plan. To keep things simple, Amberleaf only has one price plan, at just £4.95 per month. That gets you everything the software has to offer - there are no artificial limits in place.

I'm happy to say, though, that for the duration of the public beta test, all accounts are still completely free! Sign up now and try out Amberleaf's new billing features! By taking part in the beta, you'll also have the opportunity to help shape Amberleaf's development to meet your needs.

Amberleaf manages domains and hosting accounts for you and your customers. Sign up now for an account, or find out more.

Amberleaf Update: Bill Tracking for Domains and Hosting

2010-03-11T00:00:00+00:00

It's been a long time coming, but today finally saw the launch of Amberleaf's bill tracking for domains and hosting accounts. How to implement billing had been troubling me for a while, but I finally decided to keep it simple.

So, I spun a branch in git and started coding. I gave myself a time limit of 3 days to get something built and released. This proved a useful tool in keeping me focussed. Despite the inevitable "if only it just did this..." going through my mind, pledging my deadline in public helped me to stick to it!

I designed the billing system to simply track income and bills that were due to be paid. No complex invoice generation or sending invoices to clients - that's better left to specialist tools like Freshbooks or Invoice Machine. The plan is to eventually let Amberleaf interact with these services to generate invoices.

If you've got an Amberleaf account, just sign in to see the new billing functionality. If you've not yet signed up, Amberleaf is completely free during the beta, so why not register an account to check out the new features? There'll also be a limited free account once Amberleaf goes live!

I'd love to hear your feedback if you're using Amberleaf to manage your domains and hosting accounts - you can send feedback directly from Amberleaf using the Send Feedback tab, or tweet @cblunt.

Run Rails 3 Apps on Passenger

2010-03-05T00:00:00+00:00

Update: Make sure you update Rubygems using sudo gem update --system.

Whilst I've been learning more about Rails 3, I've been using the built in rails server to run my code. Today I tried to run my Rails 3 app through Passenger on Apache, and immediately hit an error page:

uninitialized constant Rack::Runtime

It turns out that Passenger notices Rails' new config.ru file, causing it to run as a Rack application. This requires a slight change in the app's VirtualHost entry. The RailsEnv setting now becomes RackEnv:

# /etc/apache2/apache2.conf
# RailsEnv development
RackEnv development

But that wasn't all. My development machine was still running Passenger 2.2.7, which wouldn't support Rails 3. To ensure a clean slate, I removed the old versions of Passenger and installed the latest build (2.2.11 at the time of writing). Once installed, I ran the standard Passenger installation script and updated apache2.conf:

$ sudo gem update --system
$ sudo gem uninstall passenger
  # Remove all versions of Passenger
$ sudo gem install passenger
$ sudo passenger-install-apache2-module

# /etc/apache2/apache2.conf
# Passenger mod_rails 
# NOTE: Your paths may be different. Use the config generated by Passenger's install script)
LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-2.2.11/ext/apache2/mod_passenger.so
PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-2.2.11
PassengerRuby /usr/bin/ruby1.8

RailsEnv development
RackEnv development

After a quick restart of Apache, Passenger kicked in and my new Rails 3 app was up and running!

References

Building apps with Rails 3, RSpec, FactoryGirl and Mocha.

2010-03-03T00:00:00+00:00

Clone the source code from github.

It's no secret that Rails 3 has been released in beta for a little while now. Like most Rails developers, I was keen to try out some of the new functionality, not least the redesigned Active Record API.

Some heavy duty googling turned up little information on how to get an app started and configured with all the associated goodies we've come to expect: rspec, mocha and factory_girl.

This is probably because most of these plugins are in a state of development to bring full compatability with Rails 3. So until that happens, I thought I'd document how I've got a skeleton app up and running on Ubuntu using the current development branches.

You can find the latest versions of the code behind on my github. I'll continue to revise this template as I figure out more about Rails 3, and the plugins.

Installing Rails 3

There's plenty of posts detailing how to get Rails 3 on your machine. Favouring gems, I followed the official advice:

$ gem install tzinfo builder memcache-client rack rack-test rack-mount 
$ gem install erubis mail text-format thor bundler i18n
$ gem install rails --pre
$ rails -v
Rails 3.0.0.beta

With everything set, we can spin a new app using:

$ rails myapp
# Lots of output
$ cd myapp

Bundling Gems

Rails 3 uses the Bundler gem to configure its environment. Bundler brings a lot of benefits, including dependency resolution and ensures that an app's gem requirements are met.

Your app's required gems are declared in a Gemfile in your project root. A default Gemfile is provided to load Rails 3 and SQLite. For our project, we'll update it to require some additional gems:

# Gemfile
source 'http://gemcutter.org'

gem "rails", "3.0.0.beta"
gem "sqlite3-ruby", :require => "sqlite3"

# Require the haml gem for rendering HAML templates and SASS stylesheets
gem "haml"

# FactoryGirl and Shoulda Rails 3 development branches from github
group :thoughtbot do
  # I've included shoulda here in case you use TestUnit. Shoulda macros for RSpec 2 don't 
  # work yet though.
  gem "shoulda", :git => "git://github.com/sinefunc/shoulda.git",
                 :branch => "rails3"

  gem 'factory_girl', :git => 'git://github.com/thoughtbot/factory_girl.git',
                      :branch => 'rails3',
                      :require => "factory_girl"
end

group :test do
  # Install development release of rspec (includes rspec-rails)
  gem "rspec-rails", ">= 2.0.0.a9"
  gem "webrat"
  gem "mocha"
end

Now you can install the bundled gems with:

$ bundle install

Configuring RSpec and FactoryGirl

One of the first tools I felt lost without in Rails 3 was RSpec. Although I tried going back TestUnit, I missed the clarity of RSpec. With RSpec 2 installed by Bundler, the app can be prepared for specs with:

$ rails generate rspec:install

This creates the appropriate spec folder and configuration files. I configured RSpec to use FactoryGirl and Mocha. Notice that in the Gemfile above, Shoulda and FactoryGirl are declared in a group :thoughtbot. Bundler loads the default gems before Rails has initialised environment constants such as Rails.root. By declaring these gems within a group, they can be defered until Rails has setup the environment (Reference).

For RSpec to use FactoryGirl, we ask Bundler to load the :thoughtbot gems in spec_helper.rb:

# specs/spec_helper.rb
ENV["RAILS_ENV"] ||= 'test'
require File.dirname(__FILE__) + "/../config/environment" unless defined?(RAILS_ROOT)
require 'rspec/rails'

# Load in RSpec and Shoulda
# Shoulda macros don't seem to work with RSpec 2. When they do, this is where to require them.
# require 'shoulda'
# require 'shoulda/rspec'

require 'factory_girl'

# Autoloading of Factories seems to be broken, so manually require the <tt>factories.rb</tt> file
require File.dirname(__FILE__) + "/../spec/factories.rb"

# Requires supporting files with custom matchers and macros, etc,
# in ./support/ and its subdirectories.
Dir["#{File.dirname(__FILE__)}/support/**/*.rb"].each {|f| require f}

For now I've left shoulda out of the configuration as the Shoulda macros don't yet work with RSpec 2. I also manually required spec/factories.rb as FactoryGirl's autoloader also seemed not to be working yet. Before running a spec, you'll need to declare your factories in spec/factories.rb:

$ touch spec/factories.rb

Finally, switch RSpec to use mocha for mocking objects:

# spec/spec_helper.rb
# == Mock Framework
config.mock_with :mocha

Writing specs

With everything setup, it's time to write the first spec. As a simple example, I'll create a User model and its associated spec. With RSpec installed, the standard rails model generator will automatically create an associated spec file:

$ rails generate model user email_address:string password_hash:string password_salt:string
$ rake db:migrate
==  CreateUsers: migrating ====================================================
-- create_table(:users)
   -> 0.0041s
==  CreateUsers: migrated (0.0043s) ===========================================

The spec for the User model can now be written using the familiar RSpec dialect:

# spec/models/user_spec.rb
require 'spec_helper'

describe User do
  it "should be valid" do
    @user = Factory.create(:user)
    @user.should be_valid
  end
end

I've also used Factory.create to build a user, so as before, you'll need to declare your user factory in spec/factories.rb:

# spec/factories.rb
Factory.define :user do |u|
  u.email_address 'joe.user@example.com'
  u.password 'secret'
end

Finally, to run your specs, you use rake:

$ rake spec

All being well, RSpec should now load up and run your specs. In this example, the spec fails trying to set User#password. To fix this, we'll add a virtual attribute, password, to the User model that sets a salted, hashed password:

# app/models/user.rb
require 'digest/sha2'

class User < ActiveRecord::Base
  def password=(pass)
    @password =  pass
    return if @password.blank? 

    self.password_salt = Digest::SHA2.hexdigest(Time.now.to_s + rand(32000).to_s)
    self.password_hash = Digest::SHA2.hexdigest(@password + self.password_salt)
  end

protected
  def password
    @password
  end
end

With that, another call to rake should report your passing spec:

$ rake spec
.
Finished in 0.062692 seconds
1 example, 0 failures

With this, you can now start to build your Rails 3 app, complete with specs and factories. I'll continue to update the code on github as I figure out more, and as more plugins become compatible with Rails 3.

References

Changed Permalinks and More Blog Tweaks

2010-02-16T00:00:00+00:00

I'm really liking Jekyll as a blog engine, and have been tweaking a few things on the site. One big change is permalinks. To follow Jekyll's preferred convention, I've switched my post's permalinks from /blog/YYYY/MM/DD to just /YYYY/MM/DD. Thanks to Apache's mod_rewrite, old links will still work, but I find mod_rewrite rules a bit of a dark art. So, for convenience and future reference, here are the rules I've used:

# .htaccess
RewriteBase /
# Don't redirect if URL is a real file
RewriteCond %{REQUEST_URI} !-f
# Redirect requests for /blog/some/page.html to /some/page.html
RewriteCond %{REQUEST_URI}% ^/blog(.*)
RewriteRule blog/(.*) http://chrisblunt.com/$1 [R=301,NC,L]

# Redirect requests for /feed to Feedburner
RewriteCond %{REQUEST_URI}% ^/feed/?(.*)
RewriteRule ^(.*) http://feeds.feedburner.com/chrisblunt [R=301,NC,L]

For now, the changed permalink structure means that Disqus comments are not available. I've contacted Disqus about this though, and hope to move those comments to the new format soon.

In the meantime, everything else seems to be running smoothly on Jekyll. I've tweaked my site's design back to a fairly minimal theme - influenced by other Jekyll sites that I've seen.

I've kept deployments simple too; rather than using git hooks, I use a Rakefile and rsync combination based on this post. The Rakefile lets me use a fork of Jekyll to compile and upload the site with a simple call to rake deploy:

# /Rakefile
def jekyll(opts = "", path = "../jekyll/bin/")
  sh "rm -rf _site"
  sh path + "jekyll " + opts
end
  
def rsync(options = {})
  options = {
    :domain => 'servername', 
    :deploy_to => 'filesystem path',
    :port => ssh_port,
    :user => 'ssh_username'
  }.update(options)

  sh "rsync -rtz -e 'ssh -p #{options[:port]}' _site/ #{options[:user]}@#{options[:domain]}:#{options[:deploy_to]}/"
end

desc "Perform a jekyll rebuild of the site"
task :build do
  jekyll 
  Rake::Task["sitemap:build"].invoke
end

desc "Serve on Localhost with port 4000"
task :local do
  jekyll("--server --auto --limit-posts 5")
end

desc "Rebuild and Deploy to Live"
task :deploy => :build do
  rsync
  Rake::Task["sitemap:ping"].invoke
end

desc "Deploy the currently cached build to Live"
task :cached do
  rsync
  Rake::Task["sitemap:ping"].invoke
end

namespace :sitemap do
  desc "Rebuild the sitemap.xml using gen_sitemap.rb"
  task :build do
    generate_sitemap_bin = File.dirname(__FILE__) + "/_tools/gen_sitemap.rb"
    cmd = "cd _site && ruby #{generate_sitemap_bin} '.' > sitemap.xml"
    `#{cmd}`
  end

  desc 'Notify Google of the new sitemap'
  task :ping do
    require 'net/http'
    require 'uri'
    Net::HTTP.get(
        'www.google.com',
        '/webmasters/tools/ping?sitemap=' +
        URI.escape('http://chrisblunt.com/sitemap.xml')
    )
  end
end

Overall everything feels a lot lighter and easier to manage, and vim now sits at the heart of my blog workflow. This is great as I find it hard work to use any other text editor since learning vim. Static HTML means the site is served quickly as well, and I feel safe in the knowledge that my data is stored in a git repository rather than a single database.

One caveat is that the site can't include external dynamic content; at least not without some Javascript. I figure, though, that there are plenty of ways to follow my Twitter ramblings or photostreams and so on without adding distraction to the site.

So hopefully the transition is complete. Once the Disqus comments are linked, I'll be able to get back to writing some content to fill the blog! There's plenty to write about, with the recent release of Rails 3 beta, and my upcoming travels. I'll also document more about Amberleaf's development, post more Rails tips as I learn, and discuss a new mobile app for Android I'm starting.

Are you using Jekyll or something similar to power your site? How have you found the transition if you've switched from bigger engines like Wordpress or Mephisto?

Switching to Jekyll

2010-02-07T00:00:00+00:00

For several years now, I've used Wordpress to power this site. As I've learned to use new tools for coding (vim, git and so on), Wordpress has started to seem a little too heavy, especially for just writing posts. A <textarea> editor just can't cut it when you've been using vim for a couple of years.

So I started looking for alternative blogging engines. After trying out a few Rails-powered engines, I eventually stumbled across Jekyll.

Jekyll is described as a "blog-aware static site generator", and I set about giving it a try. After a few minutes, I knew that Jekyll was what I'd been looking for. It lets me edit my site in a text editor of my choosing, generates static HTML files (no more heavy server-side tech), and sits perfectly in a Rails-esque git push; rake deploy workflow.

So after a few days migrating from Wordpress, this site is now 100% Jekyll powered: there is no back-end PHP; no database connection to worry about; and everything is versioned and backed-up through git. I've used a fork of Jekyll that lets me write templates in Haml rather than stock HTML.

There have been a few bumps along the way, but thanks to the growing Jekyll community and wiki, there are plenty of helpful guides and tricks available to solve any problems I've had. Here's a quick overview of how I've switched to Jekyll.

Pure Text

Jekyll uses plain text for everything. Plain text is great - it's small and portable; can be edited using your editor of choice, and is easily versionable using tools like git.

Deploying

With a suitable Rakefile, managing my site is as simple as writing a post and running rake deploy. Rather that git post-commit hooks, I've used rsync (as described in this post) to push files into my server's blog directory.

Comments

Having no server-side scripting means that Jekyll sites have no way to submit and process comments. The Jekyll sites I've seen either don't use comments, or implement them through a hosted service such as Disqus or IntenseDebate.

I like the conversation that comments bring, so I went with Disqus to manage this site's comments. The process was fairly simple, and just involved adding a couple of <script> tags to my _layouts/post.haml file.

As an added bonus, using a hosted service lets you keep track of your conversations across the web, and listen for replies across a number of sites more easily.

Migrating Posts

Jekyll comes with a set of converters for getting your posts out of other blog engines. You can find them in the lib/jekyll/converters/ folder of the Jekyll repository.

I had 6 years worth of posts stored in Wordpress, and used the built-in converter to extract them. This was fine, but I found the default converter didn't migrate tags and categories.

After taking a quick look at the Wordpress database structure, I forked Jekyll and added a snippet of code to pull out each posts' tags and categories. The tags and categories are inserted into each post's YAML front matter.

You can find my fork of Jekyll on Github.

Code highlighting

Jekyll uses pygments to as its source highlighting engine. As a lot of my posts include code snippets, I've come to rely heavily on the wp-syntax plugin. Jekyll uses a different markup delimiter though, so I've not yet managed to migrate highlighted source code. I'm hoping to find some way to patch this, probably using regex. I'll update my fork of Jekyll with any changes.

An alternative approach that I'm thinking of is to use github gists. This would allow code to be embedded into each post, and would keep all my code in one place.

Google Sitemaps and Pings

My Wordpress site used a plugin to generate a sitemap.xml file every time a post was published. Again, the Jekyll community had already developed a script to replicate this functionality, and my sitemap.xml is now built and submitted to Google every time with every update.

RSS/Atom Feeds

My site's feed is handled through Feedburner. For the few users that were directly subscribed to my site's raw XML feed (http://chrisblunt.com/blog/feed), I've used Apache mod_rewrite to redirect requests to Feedburner. This should be transparent to those subscribers, but please let me know if you find otherwise.

So that's my site switched over to Jekyll, and I'm glad to say that everything seems to have gone smoothly. Thanks to the magic of mod_rewrite all previous links should still work.

The only problem so far is that code snippets haven't migrated properly, so you'll find that they aren't syntax highlighted. I'll work on switching those manually once I decide whether to go with gist or pygments.

There are likely to be a few more tweaks to the site's layout and theme. I'll also be posting more as I get to grips with Rails 3 and Android, and Claire and I start on our travels in March...

Amberleaf: Manage Your Domains & Hosting - Public Beta Now Open.

2010-01-04T00:00:00+00:00

After several months of evening development and jumping into Rails at the deep-end, I'm happy to jump into 2010 by opening public beta accounts for Amberleaf - and every account is free for the duration of the beta!

Amberleaf is built to remind you of upcoming renewals for domains and SSL certificate expiries, and hosting account renewals, and simply to remind you when to bill your customers. It is the evolution of HostManager, an OS X app I wrote back in my university days.

Who uses Amberleaf?

Anybody who has a domain! Whether you own or manage a single domain, or several hundred hosting accounts on behalf of your clients, Amberleaf is designed to make your life easier, by providing:

Automatic WHOIS lookup for domains, with more TLDs being added.
Email notification of upcoming expiries and renewals.
Private RSS feed of your upcoming notifications.
Simple client management, with the ability to import your existing clients' vCards.
Keep a history of notes for your domains and clients, such as when special discounts are due to end.

What do you think?

Amberleaf is completely free for the duration of the beta, and signup only takes a couple of minutes; I'd love to hear your feedback and comments.

Sign up for Amberleaf now or find out more.

If you've already signed up, you can email comments to chris at chrisblunt dot com; ping me on twitter (@cblunt), or send feedback directly from Amberleaf using the feedback tab at the bottom of every page.

If you'd like to see what's coming in future releases, and get involved in Amberleaf's development, check out the public tracker at trac.chrisblunt.com.

Just Married

2010-01-03T00:00:00+00:00

Over Christmas, Claire and I travelled to Las Vegas to finally tie the knot. After a few relatively easy months of planning, several hours delay in London and very little sleep; the wedding day was perfect.

We were married at the Treasure Island, and had a small reception meal across the road in the Venetian hotel, before taking a tour of the strip, and obligatory photos at 'the sign', in a stretch.

The trip was complete with a helicopter tour of the strip and neighbouring Grand Canyon valleys.

Needless to say it was one of the most exciting and unusual Christmas' I've ever experienced, and a great start to married life in 2010!

More photos on Flickr...

Introducing Molehill: Simple Issue Tracking

2009-12-15T00:00:00+00:00

In my previous post, I wrote how I've recently been getting to grips with Cucumber and Pickle. To do this, rather than trying to retro-fit Cucumber stories into another app, I decided to start with a fresh new Rails app: Molehill.

Molehill is an experiment, both in learning behaviour driven design (BDD), and also trying out some ideas for a simplified issue tracker.

Molehill is open-source, and can be downloaded from github. See the end of this post for more details.

Post. Fix. Close.

Molehill is designed to avoid the problem I've found with other issue trackers I've used - they do too much. They require so much overhead setting up and managing versions, milestones, time estimates, shipping forecasts, gantt charts, and so on - that it's as much work posting a case as actually fixing it.

Molehill takes a much simpler approach, purposefully avoiding all that which makes other issue trackers so heavy. Instead, Molehill is based on the idea that tracking bugs and features should be as simple as post, fix, close.

Posting and Promoting Cases

Taking cues from Twitter and the micro-blog format, cases are written as simple posts which are dropped into a timeline.

If a case is posted that you think is important, you can promote it. The more promotions a case has, the higher it appears in the timeline.

For developers, this means that your users' most desired bugfixes or features are always sitting at the top of the timeline. Instead of spending hours building roadmaps, and scheduling cases for release in 6 weeks (if you're lucky), just work on whatever case is next at the top of the list and release it.

Closing Cases

Once a case has been fixed or implemented, the original author can mark it as such; or - if it's not going to be implemented - it can be marked declined.

At the moment, only the original author can close a cace - I've intentionally avoided roles (such as Developers and Reporter) in Molehill, although I may have to make an exception so that developer's can mark any case as completed or declined.

An alternative approach might be to allow any other use to suggest a case is complete, or indicate that it won't be implemented. This might be better achieved through a reply system though, like Twitter's @reply tag.

Categories and Projects

Molehill doesn't have a concept of projects, but does allow #hashtags within a case. This means cases can easily be tagged and categorised to a project or feature, for example:

There should be a way for #molehill to categorise or tag #cases.

A quick search from the homepage, or click on the #hashtag, reveals any other cases tagged with the same words.

Cucumbers Everywhere

I built Molehill primarily to learn Cucumber, and doing so has got me hooked on writing feature-first code. The majority of Molehill was built without once launching Firefox or Chrome; everything was instead written as a feature, and run through Cucumber and Webrat until that feature passed.

Good Cucumber coverage allows far more confidence when deploying your code that everything works together. Too often I've seen a minor fix in one part of an app have a completely unforeseen effect on some screen assumed to be unrelated. With Cucumber, and a good test suite, these worries can be all but forgotten. Now that it's in public beta, I'm working to retrospectively cover Amberleaf in Cucumber stories

Getting Molehill

Molehill is open sourced under the MIT licence (the same as Rails). You can grab a copy of the code from github, and setup your own local Molehill server using the following steps:

$ git clone git://github.com/cblunt/molehill.git
$ cd molehill

$ cp config/database.yml.sample config/database.yml
# You'll need to configure your local database in config/database.yml

# Molehill has a number of gem dependencies, including Cucumber and Pickle
$ rake gems:install

$ rake db:migrate
$ rake db:migrate RAILS_ENV=cucumber

$ rake cucumber

You can also generate an RCov coverage report (saved in features_coverage) using:

$ rake cucumber:rcov

There is a live demo of Molehill running at http://molehill.chrisblunt.com. To begin with, I'll use Molehill to track its own development. However, if it proves to be a workable concept (and requires less management than a full redmine setup), I'll probably use it for Amberleaf's issue tracking as well.

Rails: Building Apps with Cucumber and Pickle

2009-12-11T00:00:00+00:00

I'd often read about Cucumber, but had always been put off by the task of learning another abstract domain language to distract me from actually writing code. But as I kept reading more and more about it, curiosity got the better of me and I had to give it a try.

After a couple of weeks of learning to use Cucumber, I'm completely hooked.

What is Cucumber?

Cucumber grew out of RSpec as a language for describing user stories in behaviour driven design (BDD). Cucumber avoids the abstract and often incorrect, functional and technical documenting of the software process, instead encouraging you to write short, specific stories about an should do.

In Cucumber, these stories are described through number of individual steps that describe a situation, set of actions, and conditions to be met. For example, a Cucumber story to test logging out of an application might look something like:

# features/logging_in_and_out.feature
Scenario: A logged in user wants to log out
  Given I am logged in
  And I click the "Log out" link
  Then I should not be logged in
  And I should be on the home page
  And I should see "You have been logged out"

Stories are designed to be written and read by people, not machines. When you run your story through Cucumber, it applies some funky logic and regular expression matching to run your application code against the story's steps. Each step creates or checks the situation being described.

For example, the steps for the logging out feature above might be:

# features/step_definitions/authentication_steps.rb
Given /^I am logged in$/ do
  controller.current_user = Factory(:user) # I've used FactoryGirl to create fixtures here
end

Then /^I should not be logged in$/ do
  controller.current_user.should be_nil
  session[:user_id].should be_nil
end

Thankfully, Cucumber comes with a collection of pre-defined steps that cover common situations, such as the Then I should see "{something}" and When I click "{some link}" steps in the previous example.

Cucumber with Pickle

Cucumber works well with a number of other gems, but one that you'll definitely want to use is pickle. Once installed, pickle gives you a collection of handy step definitions for creating a referring to new models in your stories.

In the example below, a new Post model is created and assigned the label "the post". The remaining steps can then refer to "the post" directly:

# features/publishing_posts.rb
Given a post "the post" exists with published: false
And "the post" belongs to me
When I am editing "the post"
And I click "Publish Post"
Then "the post" should be published
And I should see "Post Published"

Why You Should Be Using Cucumber

Confidence

The greatest benefit of Cucumber (and most test-driven methodologies) is that you gain an incredible amount of confidence in your code. Before any release, you can quickly and automatically check that your whole application is doing what you'd expect it to do. This makes releases a far less daunting experience.

It tests your entire application, from top to bottom

I'd always found testing the high-level functionality of a web app tricky with other test tools, including RSpec. Although they were great at checking very specific, model conditions, when it came to testing the working app as a whole, they never seemed to quite cut it.

Cucumber lets you write tests that drive through every layer of your application: views, controllers, models and other utility classes (such as email handling, see this great post on email_spec) can all be tested in a much more natural manner.

Stories are reusable

As you write more stories, you'll quickly build up a library of handy step definitions. You can use more advanced regular expressions to DRY those step definitions, and then re-use them in other parts of your project, or in other projects.

Your code is self documenting

One of the greatest benefits of Cucumber stories is that they act as effective documentation for your app. Cucumber can output its running descriptions in a number of formats, including HTML. Having this documentation automatically generated can give you even more assurance that your code is doing what you'd expect, and lets you answer those "what's supposed to happen if...?" questions with certainty.

Get Started

If you haven't tried Cucumber yet, I really recommend you take an hour to follow some of the tutorials. You definitely won't regret it. There's loads more tips and information available on the Cucumber website, as well as the official RSpec Book from The Pragmatic Bookshelf.

In the next post, I'll introduce Molehill, my first attempt at building an app the BDD way. In the meantime, if you'd like to check out the code and take a look at the Cucumber stories, you can find Molehill on github.

Rails: Multiple default scopes for ActiveRecord

2009-10-22T00:00:00+01:00

Default scopes were introduced in Rails 2.3 to allow a default set of options to be applied to any find methods. The common example is to always order a set of results by a given column, e.g:

class Post < ActiveRecord::Base
  # Any calls to Post.find will automatically have the default :order option merged into them
  # Post.find(:all)
  # => SELECT * FROM "posts" ORDER BY "created_at DESC";
  default_scope :order => "created_at DESC"
end

Unlike named_scopes (which I am finding more and more useful every day), I found that default scopes cannot be combined when I tried to use the acts_as_revisable and is_paranoid plugins together:

class Post < ActiveRecord::Base
  acts_as_revisable
  is_paranoid
end

It seems the default scope declared in is_paranoid overrides that of acts_as_revisable. Post.find(:all) will therefore return every revision of Post rather than just the current revision. You can check this out by reversing the plugin order:

class Post < ActiveRecord::Base
  is_paranoid
  acts_as_revisable
end

Now, Post.find(:all) will return only current revisions, but will include any destroyed posts as the acts_as_revisable default scope overrides is_paranoid!

A Solution

This post and code snippet shows a method for declaring multiple default scopes on a model. I've not yet tried out the code, though, as one of the commenter's was kind enough to forkis_paranoid and modify it to merge any existing default scopes. With this forked plugin, Post can be scoped correctly by both plugins.

The fork is available at http://github.com/grioja/is_paranoid/tree/master.

But... is_paranoid is depracated

I noticed that the original is_paranoid plugin has ceased development, so I'm not sure if I'll continue to use it, although It's a neat little plugin, and has several forks.

The underlying problem, though, of ActiveRecord allowing only one default_scope to be declared, is something that I'm bound to come up against in the future, so it's handy to know there is a workaround at least until Rails includes the functionality.

As an aside, Rich Cavanaugh, the developer of acts_as_revisable, has pointed out that the plugin includes some basic is_paranoid functionality already (see Rich's reply to my original ramblings):

class Post < ActiveRecord::Base
  acts_as_revisable :on_delete => :revise
end

Do you use default_scope? Do you find the single scope a limitation, or do you rely on named scopes? Feel free to discuss in the comments.