The day before yesterday (I missed yesterday’s post), I published an article on my remote publishing setup with Octopress. It’s been my most popular article this year in terms of page views. Nothing else I’ve published has even come close to it this year.

This begs the question, should I be writing more technical articles?

When I committed to writing a post a day I wanted to try and stay clear of technical posts on programming and technology, as a developer though it’s hard to find ideas for posts on topics and subjects that are not technology related.

Next week I plan on committing to writing one technical article per week. I still want to keep technology posts to a minimum, but the popularity of the Octopress post is hard to ignore.

Octopress is a really great blogging framework for those not afraid of the command line, but one limitation it has is that when you are away from your desk, publishing to your blog remotely can be difficult.

It was this sticking point that made me hesitant about moving back to Octopress, but after some digging I was able to find a solution that allowed me to remotely publish to my blog through Github.

My preferred setup was to use Heroku to host the blog. Before I would have written my blog post, generated the site and the published it to Heroku. I remember this being a chore when I first used Octopress but there is a better way of doing this. We can offload the site generation bit to be handled by Heroku by using a buildpack.

A buildpack allows Heroku to run a number of languages and frameworks in the one environment. As Heroku’s Cedar stack is a polyglot stack, it can host a number of different languages and frameworks. Heroku isn’t just for Ruby devs now, it’s for everyone.

Jason Garber has a forked buildpack with updates for Octopress that will handle the generating of your site for you.

Now to update our site we simply need to create our new post, save it and push the code to Heroku. The buildpack will spot the incoming push and generate your site for you.

That’s one less step for me to do but I still wanted to publish remotely to my blog. Ideally I would be able to create new posts on Github and then once committed we can then push the blog to Heroku.

The second piece to the puzzle is this little Sinatra application by Anthony Lai. This application takes a repository on Github and deploys it to Heroku. It does this by being triggered by post commit hook at Github. After I commit to my blog on Github, the post receive hook is triggered and it deploys my blog from Github to Heroku.

Now at the moment this means I have two applications on Heroku. One for my blog and one for the Github Heroku pusher application. However it does mean that I can publish to my blog remotely by simply writing my posts to my blog repository on Github and let it trigger the push to Heroku when I commit my post.

It’s a great setup that has worked for me well over the last few weeks and it has meant that I can even publish to my blog from my iPad or even my iPhone if need be.

Yes, it is a bit heavy on the resources side with two Heroku applications and the use of a public Github repository but it works, and that’s what matters to me most at the moment.

Tonight I took the final step in making the move away from Google. After much deliberation I made the move to migrate my Google Apps email account to FastMail. It was certainly less painful than I thought it would be and took the best part of an hour to get all three email accounts over to FastMail.

As for the other services from Google, I’ve found suitable replacements for many of their services over the last few weeks.

• Switched to Pages and Numbers from Google Docs - I don’t have that many documents to manage and I don’t need them when I am on the move, so setup will be sufficient.
• Switched to Feedbin from Google Reader - Feedbin is still young but it’s growing and it’s supported by the Reeder app for the iPhone. A no-brainer decision there.
• Switched to Gauges from Google Analytics - Github’s analytics service is ideal for my needs at the moment. It’s dashboard provides all the information that I need at a glance and of course it has a greap API that’s easy to use.

There are of course other Google services that I never really took too like Google+, Chat, Picasa, and their Drive service. I already use alternatives for these that I find to be much better so I never really got round to using these.

So why move from Google?

It was the all your eggs in basket argument. Google aren’t going to go away anytime soon, but simply having all my information in one place was nerving. I wanted more control over my data, so I elected to find alternatives that would do just that.

I’m happy with the choice that I made in Google free. It’s not for everyone, but having more control and investing more into products and apps that provide a better service certainly does give a better feeling than handing all my information over to one provider.

Quick to change and always adapting. Nicholas Bate knows how the smart organisation works.

Thanks to Execupundit for this reminder that it is 70 years since the Dambusters raid. The Spitfire was my favourite as a kid and still is.

Curtis McHale offers some advice for those that are just a little bit too quick to write off change.

… with Nicholas Bate.

Yesterday I talked about annual reviews and how organisations can often get a simple process wrong, but are annual reviews immediately flawed due to their annual occurrence?

A year is a long time. A lot can happen in a year. I left a job, started a new job, got made redundant from the new job and then started freelancing all within a year. I hope you’re not as unlucky me to get made redundant, but maybe you move about a lot inside an organisation? What if you’re never in the same job for more than a couple of years. Does that make the annual review a redundant process?

In the UK there has been a rise in the last few years of self-employed workers and recently portfolio careers have proved to be popular with workers who want more of a variety in their career. The job for life is gone, so why are organisations still subjecting their workers to annual reviews?

Perhaps a more agile approach is needed with more frequent feedback. A year between reviews is too long, but what about quarterly reviews of your work with your line manager? How about monthly? At what point would your line manager know that you are enjoying your job and making a positive contribution to the company?

As a freelancer I have to continually look at my skill set and improve on areas that are rusty and also consider new programming languages and frameworks every few months. I have a core skill set that I am strong with but I also have to consider other skills if I want to make myself attractive to future clients. I give myself a review every month so that I know what work I have completed, whether I have completed it on time and what is in the pipeline ahead for me. I can afford to do this though as it is just me.

I’m just glad I don’t need to sit through anymore annual reviews for the foreseeable future.

It was my oldest son’s parents night at his school tonight. We had a fair idea what his teacher was going to say about him and his progress. We weren’t disappointed.

The format is simple. You get 10 minutes with the teacher in which time they will go over the your child’s progress (that you have already read the week before) and then you get to ask any questions about your child and identify any area where they can try and make improvements. Fortunately our son is doing great so there was just a couple of minor areas for him to improve on.

If you think the format is familiar then you would be right. Parents night is just the kiddie version of the annual review that many permanent workers go through. However, how is it that organisations can get this wrong when the basic format seems so simple?

I’ve experienced the annual review first hand in a number of companies. Very few of them actually did an annual review on a regular basis and even fewer followed through from the previous annual review.

A neighbour of mine worked in a really well known international bank where annual reviews were not done by your line manager but by someone even higher up. In an organisation such as this where the number of employees runs into thousands, there was a good chance that the person doing your annual review doesn’t even know you to look at. In this case our friend did indeed get their annual review done by a director who had only met him twice. Not exactly a good example of an annual review.

Twice a year my son’s school give a parents night without fail. They provide a report for your child that you get a week before parents night so that you can raise any questions during parents night. They give feedback on your child’s progress and give suggestions on areas where your child can improve. They do it for all the kids in the school. That’s hundreds of kids.

It’s not hard to do.

Today I did my first Capistrano deployment. Yes, that’s right. My first. Any experienced Ruby developers might be wondering how I haven’t used Capristrano in the past. I simply chose not to use it.

When Rails was in its infancy, Capistrano emerged as the default way for Rails developers to automate their deployments, but one thing that put me off was the amount of work that would be involved in getting it up and running. Scripts, SSH, source code management, web servers and databases. It all sounded a bit much.

Then Heroku came along and I smiled. I could deploy my application with a single command. In the past I’ve always opted to use Heroku and during my brief stint in an agile team we used Engine Yard for hosting our applications. Again deployment was as easy as a click of a button.

I’ll admit it. I’m lazy. I hate having to muck about with configuration settings, command line arguments, options and other little details to get things working.

As a developer I’ve come across hundreds of tools, editors, applications, libraries and services that help me do my job. One thing that sticks for my preferred selection of tools that I continue to re-use are the ones that just work and require little work to get working. Platform services like Heroku and Engine Yard fit this criteria perfectly.

Yes I probably should have some knowledge on using Capistrano but the ease of a single click deployment is hard to beat.

At the end of the day I just want to ship code.