via FGGT

Dedicating yourself to a project weekly means you don’t have to switch contexts. I wake up in the morning, get myself ready and then I start on the tasks for a weekly project. I don’t have to decide what clients gets my priority today, I just work on the project for the week.

I love this idea. Basically it amounts to charging for iterations or sprints. Nice to see Curtis picked up on my task switching post as well.

I can afford to lose some time during the day as I am working with mostly one client at the moment on a number of their applications, so a little lost time is to be expected.

I’ve adopted this idea of Patrick’s for my own stuff. The card only contains things that I want to do personally for that day.

Client work goes in my Moleskine where I need a more permanent record of day to day progress.

Sure. Why not? Your blog is your digital footprint in the world and it is more easily found than physical business cards.

After reading Matt Gemmell’s post on designing blogs for readers, I decided to assess my own blog for a re-design.

Here’s the parts of my blog I’m not that happy with at the moment:

• I used another template for my site that was similar to the default Octopress theme. They’re fine themes to use but I’ve always wanted to design a theme that suits my requirements.

• The side bar is a busy place. Perhaps too busy. While I do want to have extra information like links to other accounts and other information, I feel this information would be better suited at the bottom of the blog. This way the reader isn’t distracted during the reading of my post.

• The fonts used in the current theme make it difficult to differentiate headings from paragraphs. Easy to fix, but I don’t want to put a band-aid on the current theme. I want to start from scratch.

With this information I’ve decided to put together a new layout for the site over the next few weeks. I’m putting a couple of products to the side for the moment. For the next few weeks I am really busy with client work, so I want a side project that doesn’t demand too much of my time. This will fit the bill nicely.

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.