I’m back!

Well, it’s been a while since I’ve last updated this blog and I just wanted to make a short little post here to update y’all on a few things. It seems it’s not just me – the blog thing is kinda dying lately from what I can see from blogs I used to visit often and that are now rarely updated.

Anyways, I’m back after a long hiatus. I somehow missed it and am going to post again every now and then mainly with tips, tricks, and solutions to problems I encounter in my work life, especially on web development, as usual.

Not sure where I should start. Perhaps with a super brief update about myself?

Last time I blogged was in April 2014, so yeah, it’s been a while. I can’t say/remember much of what happened during the rest of that year, so I’ll say something quick about this past year.

In a nutshell, 2015 has been a overall good year, albeit I can’t say there have been any particularly important events. I still live in Finland – well, it doesn’t look I’m going anywhere else anymore – and I still work for OnApp, managing a small team of developers based in London. So as usual I work remotely, and visit the London office every now and then.

I’m still happy with my job, although sometimes I feel like it would be nice to do something different. But it’s nice to be able to kinda manage my own time since I work from home, although I usually try to be available during UK office hours. I wish I had more free time to work on some side project though.

Work aside, unfortunately I had to give up boxing mainly for health related reasons. I really miss it, as it’s the only kind of sport I would never get bored with. Anything else I tried just didn’t work for me. So the result is that I am not fit at all.. and that’s not a good thing, especially because I spend most of the time sitting in front of a computer. Anyways…

Here in Finland days are quickly getting shorter and darker, and the weather in general is depressing. Would be nice to spend some time in a sunnier place at the moment.

A little site news for the devs and bloggers who might be reading this: I have just switched from static pages hosted on Github Pages to Ghost. So I started with a self hosted WordPress, switched to Jekyll, then back to WordPress, then I decided to stop blogging and just to keep the existing posts available to Googlers I generated a static version of the blog which I published on Github pages. So it looks like I spent more time switching blogging software than actually writing posts. LOL.

Eventually, I switched to Ghost, but this time I am using a hosted service and I am kinda committed to it (I already paid for the first year). I didn’t want to bother with having to keep the blog software up to date on my servers, so it’s easier this way.

I really like Ghost! It’s pretty fast and its very simple, clean design makes blogging fun again. It’s not cluttered and bloated like WordPress, and it’s so nice to just write posts in Markdown (I know you can do this in WordPress too) with a live preview on the side. It makes blogging much easier and quicker. I can just focus on what I want to write more easily.

I guess that’s all for now. Stay tuned for updates and thank you for stopping by 🙂


Downtime and DDoS against PowerDNS.net

This site is back to normal now, after problems caused by a DDoS were resolved earlier today.

The attack was not against the site/server directly, but against the DNS service I’ve used until this morning, PowerDNS.net, resulting in my domains not being accessible for around 12 hours between 09:12:06PM GMT yesterday and 09:07:06AM GMT today (according to Pingdom).

Luckily this is just a personal blog and not a business, otherwise it could have cost me money. Nevertheless I am glad that everything is back to normal now. It’s a shame that the site was offline for that long, but at the same time my wife and I may have not received emails for a while, so I am more worried about the email services when the domains are not accessible.

While searching on Twitter for clues as to what was going on, I learnt that PowerDNS and PowerDNS.net are actually two distinct companies even with the same logo!… how confusing. Several people (me included) were asking @powerdns for help which they couldn’t provide while @PowerDNSNet, the company under attack (PowerDNS.Net Hosting by Trilab) remained silent.

No notice, email, explanation, status update on Twitter or else, was given during the outage. Frustrating and unprofessional. Only a few hours ago a tweet appeared in the PowerDNS.net feed saying:

Some of our ip’s have been nulled by our provider as traffic for them affected infrastructure and created latency/packet loss.

The lack of communication during the outage was enough for me to switch to the Amazon Route 53 service. Besides, PowerDNS.net has failed multiple times lately; I know that you can’t blame a provider if they are suffering from an attack, but ultimately the customer is affected. I hope that Amazon’s scale would at least make it more difficult for an attack to bring the service down.

A DDoS towards a DNS service or registrar reminds how easy it is these days for sites to go down even without being attacked directly.

At least for what concerns DNS services, the lesson learned is that using two services together vs a single service may be a good idea. I will likely use something else together with AWS Route 53. As said email especially is very important and I don’t want this to be affected if a DNS service is experiencing downtime.

Why I switched from Jekyll back to WordPress

Back in 2011 I wrote a couple of posts -which became very popular- on why I had migrated from WordPress to Jekyll and on how to perform such migration in great detail. I had become a big fan of Jekyll, so it may surprise that this site is now running on WordPress again after more than two years. At the time, I justified the choice by saying, among other things, that while I thought WordPress was (is) a great CMS, I also thought it was overkill for my needs, due to features I thought I didn’t need. I even blamed WordPress because I wasn’t writing new content as often as I would like, which was unfair.

When I came across Jekyll I was sold on the idea that it was written in Ruby, rather than PHP (which, btw, I absolutely hate) and I could write my posts in Markdown with VIM, yay! Still today, its popularity is growing, also thanks to free hosting with Github Pages.

At first I had fun with the migration, it wasn’t trivial for some aspects but it wasn’t too complex either since I am a Ruby dev. I had to write scripts to import content from WordPress, reproduce the widgets I had with the WordPress version, figure out how to handle syntax highlighting for my code snippets, figure out how to get related posts working, write tasks to optimise static content, and more. However, I enjoyed the results, in particular the speed of the static site generated by Jekyll, achieved without having to fiddle with some caching plugins as I had to do with WordPress. Another thing I really like of Jekyll is that a site generated with it is inherently secure from an application point of view, due to its static nature: there is no dynamic code and no databases, meaning that there are no administration areas to hack into, no plugins or themes with vulnerabilities to exploit, and so on. Plus, a static site combined with a well-tuned web server like Nginx can help mitigate small DoS attacks -well, in some conditions at least.

Blogging with Jekyll seemed OK a first, but after a while I felt like switching from WordPress had been a mistake. For starters, like many others I had been comparing Jekyll to WordPress while in fact these are two very different things, with the former being a static site generator and the latter being a full content management system. I was clearly comparing apples with oranges.

Reasons why I switched back to WordPress

Publishing workflow and build times

The very first thing annoyed me when using Jekyll was the process with which you get new content ‘published’. I’d write my post in Markdown and then rebuild the site so to see the changes; problem is, if while you are writing a post you want to save the draft and quickly preview the post, you can’t. You need to rebuild the site again. This slow process started to be very annoying even though I don’t have many posts yet on this site – I can’t imagine how long it would take to rebuild a site with a lot more content!

Writing new content

The second downside with running a site generated by Jekyll is that I’d be forced to write new content from home or anyway from a computer with both a copy of the code and the ‘tools’ required to rebuild and publish the updated site. With WordPress, I can write new content from anywhere. It’s nice to be able to fire up a browser in a cafe, or wherever, and edit new content when you have some good ideas.

I have also changed my mind about the editor; at the time, for some reason I didn’t like much to write posts with WordPress’ built in editor; but with Jekyll, I eventually got tired of how I had to manually manage images, copy metadata from an existing post to a new post, then change that metadata, write the post, rebuild the site. It was a lot of work, really. With WordPress, the editing experience is so easy and I actually like the editor now while I am writing this post. And you can even use some apps to write content if you are not happy with the built in editor.


Another thing that with Jekyll you need to take care of entirely on your own is search engine optimisation, while WordPress and many themes available for it are well designed from a SEO point of view already out of the box -but still, there are also valid plugins that can help further improve the SEO performance of the site.


WordPress’ ecosystem of themes and plugins is amazing, you really can find anything you need (although themes and plugins are often source of security concerns…as well). The same isn’t true for Jekyll. In most cases you don’t need to write any code, thanks to plugins but also thanks to many themes that automate a lot of stuff with great flexibility.

Genesis and other frameworks

For this site I am using the Genesis framework, and I have also used Thesis in the past. These premium themes are amazing and allow for quick customisation and changes to layouts and more, without having to write any code. With Jekyll, making changes to the layout or things like that mean making changes to the code and rebuilding the site, then deploying again.

Other considerations

With Jekyll I had a super fast, completely static website; it’s hard to beat that. However there are valid caching plugins which, if well configured, can help speed up WordPress quite a bit, so at the end of the day it is not a so big deal as it may appear. Security is another aspect that can be a well known problem with WordPress; however with some good sense and useful plugins and services (both free and paid), it is at least possible to harden WordPress against common attacks. Having said that, I have to admit that I would sleep better at night with a static site generated by Jekyll than with a PHP based CMS like WordPress. But hey, you can’t have everything -I hope I won’t be regretting these words 🙂

At the end of the day, Jekyll is still a young project and I will surely keep an eye on it, but for now I am happy to be back on WordPress. Content is the most important thing, and whatever makes writing content easier gets my vote; at the moment, it is WordPress.

Migrating from WordPress to Jekyll – Part 1: Why I gave up on WordPress

This is a two parts post on why and how I migrated this blog to Jekyll. In this first part, I’ll mention the main reasons why I grew tired of WordPress and that led me to look for alternatives. I will publish over the next few days the second part with the “how” I migrated this blog from WordPress to Jekyll, with various useful tips I haven’t seen elsewhere.

When I started this blog back in December, I didn’t really think I would be making very big changes to the code etc so soon… but here we are. I have completed just a few days ago a full migration of this blog to a different publishing system, and this very post is the first one I am publishing with it.

If you happen to be a regular reader of this blog, you may have noticed that I have kind of slowed down the publishing of new posts over the past couple of months. Besides some unexpected events that lately have forced me to more offline life than I am used to, there was something else that had to do with the blog but that in a way distracted me from writing new content: WordPress.

I originally planned to write a couple posts per week or so, since there’s a lot of topics I’d love to write about, and I’ve got so many notes about so many things that I would like to develop into useful blog posts. However, if for one I have realised it often takes much more time than I’d have thought to write a complete post on a certain subject, on the other hand I have been spending too much time on customising and fixing many aspects of WordPress, much more than I would like.

WordPress is a great CMS, and surely deserves the great success it has earned over the years compared to other competitors in the blogging arena; it has all the features a blogger would need out of the box, it is well designed from a SEO perspective and it’s so easy to add features thanks to a simple API and the zillions of plugins available. There’s also an infinite number of both free and premium themes available, and many hosting services are optimised for this particular CMS.

So for many reasons, WordPress really is a great choice for most people when it comes to content management systems designed for blogging. However, I realised pretty soon that while WordPress is certainly great for non-developers as well as for PHP developers, it is kind of overkill for me; plus, on the other hand, since I haven’t done any serious PHP coding in many years, I found quite frustrating how long it would take at times for me to fix or customise some aspects of the CMS the way I wanted.


In particular, I wasn’t happy with how difficult it could be to seriously optimise WordPress for performance. And by performance, I don’t mean the simple server side caching of pages, as some may assume since it’s a common topic on WordPress: for that there have been for years several valid plugins that can help speed things up by caching content to static pages, which can then be served much more quickly than pages dynamically built by PHP (on a side note, I don’t get why WordPress doesn’t have yet a caching-to-static feature built in as MovableType does). By performance, in this case, I mean client side performance more than anything else.

Sure, there are also plugins that can combine and minify JavaScript or CSS files, gzip pages in advance so that a web server like Nginx would not need to do the HTTP compression on the fly, and in some cases even further reduce the number of HTTP requests by using for example CSS sprites; in theory, there are plugins for all this and a lot more.

In reality, I bet I would have spent less time with a Rails app designed from the ground up to perform well, than extending and customising WordPress. Most of those plugins only work well if you have a really simple blog, with none or few other plugins; as soon as your blog uses several other plugins to improve some features built in WordPress or add new features, with these plugins also using JavaScript libraries, CSS stylesheets and so on, making those plugin work properly from a “client side performance” point of view can become a much harder task. It’s not uncommon, for example, for plugins to use libraries such as jQuery; the thing is that very often several plugins installed on the same blog require different versions of the library at the same time, without even checking first what scripts have already been ‘queued’ either by WordPress itself, the theme in use, or other plugins.

So from my experience with WordPress for my own blog, I found that optimising it for client side performance and faster rendering of the pages, often means spending too much time with fixing and tweaking both plugins and themes, rather than simply using, configuring or customising them (in theory, a plugin is supposed to be something kind of …ready to use for the most part, without necessarily having to fix or tweak the code – right?). Despite for the most part I can say I had achieved great results with WordPress also on this front, I really grew tired of how time consuming all this can be and just wished I had something else that would be easier to maintain and customise over time.


WordPress really was overkill for me. It had so many things that were pretty useless to me either because I didn’t need them at all, or because I was using plugins that anyway replaced or improved features built in WordPress. Plus, as with any software, as it grows it also gets bigger, and not always in a positive way. I bet this is one of the reasons why many people have switched to something like Tumblr over the past few years.

So a lot of stuff in WordPress was basically bloat to me (I am well aware that “bloat” may mean something quite different from person to person). A lot of little things that I would not use but that would make my site heavier and slower to run. And as said I needed several plugins to make WordPress work the way I wanted; plugins often add to the bloat, and the more plugins you use, the slower and heavier your site will be – without taking caching into consideration.

Also, I’ve often seen overlapping in some features shared by different plugins as well as themes (for example in the context of SEO).

Upgrading and backward compatibility

WordPress is updated fairly often. That’s great, although this is more often than not because of security issues. Usually anyway having a site built on top of an application that is constantly updated is a good thing, right? The problem is, while with WordPress most upgrades are just a click away, in some cases it can be a nightmare to upgrade a blog since each time you’ve got to be worried with backward compatibility: will the new version work with your themes and plugins?

It would not be a big issue if WordPress were somehow more “stable”, where by stable I mean updated not too often; unfortunately there are frequent updates that just fix security issues and don’t add anything new or fix anything else. Of course you have to upgrade also in these cases, otherwise it may be possible for others to exploit some bug and gain access to your code and data, or worse. The problem is that regardless of the reasons behind an update, each time it could mean problems with regards to backward compatibility.

Poor security

As just mentioned, too often WordPress is updated just to fix security related issues. It’s not a secret that security has never been among WordPress’ best features; every now and then you hear of blogs being hacked or defaced, since not all bloggers have the ability or anyway possibility to keep their WordPress installs up to date so frequently, with the result that at any time there’s tons of sites in the blogosphere that run older versions of WordPress and therefore could be compromised sooner or later through some vulnerability.

Until literally a few days ago, just before completing the migration of this site away from WordPress, I was using a number of tricks to protect it, for example, from unauthorised access to the administration area, since that part of WordPress is the most common target of attacks and is often affected by vulnerabilities; also, WordPress out of the box doesn’t even do a basic thing like limiting the number of failed login attempts before banning a client.

Plugins can also be a significant risk: it’s great that you can so easily extend the CMS, but let’s face it: plugins are too often just crappy pieces of code with lots of holes. This is especially true for many of those plugins making use of AJAX, often leaving a blog open to XSS or XSRF vulnerabilities. A few months ago I tested a plugin (I can’t remember which one) that turned out to have some cryptic PHP code that actually rendered a sort of backdoor in the blog’s pages, allowing the plugin’s author to pass commands through the query string that would then be executed server side with PHP. I figured it out after noticing some weird, obfuscated HTML and JavaScript code in my pages, and luckily I found it right away, so it didn’t make its way to my production server. And this is more common than one would think. One would also assume that plugins downloaded from the official repository would be secure; well that plugin came from there as well as many others which have been found over the time to hide malicious code.

In a previous post on how to hide and protect WordPress’ administration by restricting access to known IP addresses, a reader reminded me that plugins should be allowed to execute the file admin-ajax.php within the wp-admin folder, for AJAX features. This means that with WordPress, still today, it is not even possible to completely isolate the administration area from clients, which would dramatically improve the security of a blog (provided that users are not required to login directly on the site, for example by outsourcing comments to Disqus or similar services).

All these issues concerning security, for a site that will then have to be cached to static pages to perform well, made me think: what is the point to have a dynamic CMS in the case of a blog? Wouldn’t it be easier to just have a static site instead? Especially if we take into consideration that the only case when a blog’s pages need rebuilding is when you publish or update posts (again, this is true if you are outsourcing comments).


I grew tired of WordPress’ editing UI, until I started to literally hate it. Yes, you can extend and customise it but at it’s core it’s buggy, doesn’t work well with some plugins and often screws up the HTML markup and requires you to manually fix it..

I was using a cool plugin for the syntax highlighting, named CodeColorer, which unfortunately didn’t work well with WordPress’ TinyMCE editor. It was a pain, in that I had to fix the HTML each time, for whatever reason, I needed to switch between the WYSIWYG interface and the HTML editor.

There are also some desktop clients I could have used, but I wasn’t attracted by any of them also because using these editors would have meant I had to give up on some other features added by plugins that would only work if I wrote posts with WordPress directly.

This made me wish I could just fire up TextMate, quickly edit my posts in markdown or textile, and then just push the changes with git to publish the new content…

Enter Jekyll…

I have been working almost exclusively with Ruby for a while now, therefore the next step naturally was for me to look for Ruby-based alternatives. I mentioned in a couple occasions that I had even started a sort of WordPress clone in Rails, so that I could more easily customise and maintain things over time than I would otherwise be able in PHP, for WordPress.

In the end I didn’t like too much the idea of a WordPress clone, so I looked for some existing Ruby solutions that would look simpler than that. I had already discarded the few Rails blogging engines out there since I didn’t like any of them for a reason or another, but fortunately I recently found a memo in my notes that reminded me about an open source Ruby project, Jekyll, that is actually quite popular in the Ruby community, so I finally checked it out.

Jekyll isn’t a full CMS like WordPress; it is actually not a CMS, but something a lot simpler, which I liked it right away, mainly for these reasons:

  • it is in Ruby, so that alone makes many things a lot easier for me
  • it is “a simple, blog aware, static site generator“, which is basically what I was trying to do with my Rails project (now obviously abandoned in favour of Jekyll, so that I could spend my free time on other side projects instead); I mentioned that, with WordPress, I used a plugin (namely WP-SuperCache) to cache the blog’s content to static pages; since I was already outsourcing comments to Disqus, the only time when my blog was actually changing was when I published or updated posts. Why not have a super fast static site in first place, then?
  • it uses liquid for the templating; I love liquid and have used it a lot in all my projects over the past few years, since it makes it really easy to manage even nested templates/layouts and I like both the designer friendly markup syntax and the possibility to easily extend it
  • I can just use git for the versioning of both code and raw posts!
  • posts are just markdown text files; the generated HTML is cleaner than that generated by WordPress, without funny escaping stuff. Having posts in plain text files rather than in a database, can also make it easier to export/convert posts to other formats if needed
  • I can use my favourite text editor, TextMate, which makes writing posts quicker (thanks to the markdown bundle) and with less distractions
  • improved security: with a fully static site (or almost, as I’ll explain in the next post), there’s nothing to worry in terms of security that concerns the application; as long as the server that hosts the site is properly configured and maintained from a security point of view, all the problems that you’d have with WordPress are simply gone. No dynamic app can beat a static site on security and performance
  • a static site is a lot lighter than WordPress. I always use Nginx as web server, since it’s super fast at serving static files; no need anymore for several PHP workers that suck memory and CPU; this means that servers and hosting can also be a lot cheaper for a high traffic site compared to the same site in WordPress
  • it’s very easy to customise since I can of course work directly on Jekyll’s source code; however, as we’ll see in the next post, there’s even an easier way to do this by using extensions which give you roughly the same power for the most part, but without requiring you to change Jekyll’s code directly
  • any hosting service supports Jekyll since it’s just static stuff; well I don’t need this since I run my own servers, but it is a good thing to know; I’ve seen many people even using Github Pages to serve their Jekyll-generated sites (since it is itself powered by Jekyll), besides for the source code hosting
  • deployment is as easy as copying files; you can for example generate the static site on your development machine and then use rsync to push changes to a production server; you could use git’s post-receive hooks, or, also, with rake or capistrano you can easily define custom publishing or deployment tasks, or for whatever other maintenance need – this is what I am doing now
  • Ruby developers can write plugins and extensions (we’ll see the difference in detail in the next post)
  • Jekyll does syntax highlighting out of the box with Pygments, so there is no need for plugins and alike for this
  • CSS and JavaScript files can also be processed with Liquid, so they can also include, for example, variables depending on the environment

Things that should also be taken into account regarding Jekyll

  • the blog’s content must be regenerated when adding or updating posts; while this is OK now since I don’t have many posts yet, I wonder how time consuming this task could become over the time
  • Jekyll can determine more accurately related posts for each post with an optional feature that however makes the whole process of generating the static site a lot slower; unfortunately, I am not too sure about the accuracy, either, compared to some plugins I have used for WordPress that -I think- did a better job on this front
  • as it is, Jekyll only understands dates for posts, but not times (although this is not difficult to fix); to be taken into account especially if you write multiple posts in a single day
  • while WordPress, with the right themes, is good enough from a SEO perspective, with Jekyll you have full control on the HTML markup of the pages and everything else; full control also means, though, that you need to be a bit more careful with how you write your layouts, otherwise your site’s SEO performance may be affected once you migrate from WordPress to Jekyll

All in all, I am very pleased with Jekyll so far. It did take a little longer than I’d have thought to migrate this blog as it is from WordPress, while also preserving the site’s SEO characteristics, but it didn’t take too long and I love the results.

I doubt I would ever want to look back! In the next post, I will describe all I had to do to migrate this blog from WordPress to Jekyll, with a few tips I haven’t seen elsewhere. So, if you too are planning to switch, as always stay tuned!

Live! (Eventually… with a few lessons learned)

Well, I did it – eventually; if you can read this column, it can only mean one thing: this blog is finally live! I must confess it took ages, mainly because of work related projects that have kept me exceptionally busy over the past months, to the point that I almost gave up. However, I am glad to see this first post finally published. A personal blog is something I have been wanting to author for a so loooong time (read more here, and following a couple of poorly failed attempts in the past, it looks like this may be the right time!

I actually started some months ago to work on a cool Ruby on Rails-based clone of the popular WordPress, as I love the ideas behind WordPress itself, but not their implementation; I definitely plan on carrying on with this project as soon as I can (and open source it once I have a first usable version ready), but in the end I had to give up for now because of lack of time, and …had to resort to using a customised version of WordPress, at least for the time being. In order for this blog to go live, I also had to give up to a number of features and optimisations that I had in mind, otherwise… well, it would have never gone live. At some point, as one who -for better or for worse- often tends to fall victim of some stubborn “perfectionism” and its distracting head, I came to the realisation that aiming for perfection can -more likely than not- only lead to a project never being completed. This site would never have gone live if I were to implement all the stuff that I’d like it to have, and make it as pretty as I’d love it to be (I am not a designer, therefore I may struggle at times even to put two colours together). The site now isn’t yet as speedy as it will be, yet it is acceptably fast, and also has a few “social” and search related features that I have been playing with and I particularly like and that may hopefully help make the site more useful to readers than it would be otherwise.

Anything else can definitely wait. So, can I say I’ve learned a few lessons already, while working on this side project, and even before actually starting to write content? Definitely yes!

Lesson 1: Let go of perfectionism

Go for the ‘good enough’ instead -at least for something new waiting to launch!I now tend to agree with who suggested that “premature optimisation is the root of all evil” (of course, taken in a very, very wide sense in this context). It may not always be the case, but often it is true that “premature optimisation” can turn out to be a huge waste of time and can definitely lead to loss of focus.

Lesson 2: Have a realistic deadline

Then stick to it, and try to get things done within that time frame. This if for myself one of the biggest challenges when working on a project, especially if it is something that I particularly like working on and for which I have tons of ideas. But, as said, a project will never be completed unless you have a reasonable deadline and stick to it. If you are serious about your deadline, most other things will fall into place. When I started work on this blog in my free time, I thought I would launch it when I was done with all the customisations and additions I had in mind.

But, yet again, I had to realise that this model never works, because I could always find features or improvements I could implement, with the result that I would never stop changing the code or the design, or something else (especially so since I gave up my Rails project and started working on WordPress….arghhh!! I am pretty sure now it would have taken less time to achieve the same -if not better- results had I carried on with that project rather than getting mad with all the crap that is in WordPress and in many of the plugins one has to use with it).

Having a deadline, regardless of the nature of the project, always helps keep the focus more easily on the more important features and tasks needed for the satisfactory completion of a project, with the ultimate goal of getting the job done as soon as possible, and with as good results as possible. From experience, I definitely know that sometimes it may not be easy to plan and schedule whatever is required to complete a project, especially when time or any other resources cannot be easily identified or allocated in advance. However, even in these cases defining a deadline anyway can still help determine how long it should take at the most to complete the most important parts of a project, for the project itself to still make sense.

Lesson 3: Seek instant gratification to motivate yourself!

When I happen to keep adding more and more to an already long wish-list of features, I usually end up feeling overwhelmed by the too many things to do, and the loss of focus that this likely leads to has often translated into some loss of motivation, as well. In this context, when there isn’t at some point some sort of “proof” for yourself to actually see that at least relevant portions of a project have been completed (for example, a first version of a website or web application live in production, publicly accessible and ready to use), and everything just seems to be a work in progress forever, that feeling is not easy to overcome.

You can prevent this by adequately prioritising all the project’s tasks, so that you can know in advance what needs to be done first, in order for you to launch a first version of the project. Seeing some results of your work soon can help keep yourself motivated. I’ve learned from my work related projects that it also helps to define in advance some sort of high level road map, splitting a project’s tasks into several phases, and sorting them by priority. Once identified what tasks need to be performed first, and what features need to be implemented for the more relevant portions of the project to be completed, all the rest can temporarily and safely be ignored for better focus and increased productivity, which in turn also helps build motivation.

Lesson 4: Deploy early for reduced complexity!

The sooner the most important features can be rolled out, the better, also for another reason: from experience, I have also come to learn that deploying early, and then often, does indeed help reduce the complexity and potential issues with each deployment, as there are less changes to track, remember and replicate in the production environment. This is especially true with development work.

Lesson 5: Focus on what needs to be done, not what you like doing!

This is an issue I often -perhaps I should say “too often”- encounter in my work related projects too. Not always as developers we have the luxury to work on stuff or with technologies we love or enjoy more, and this at times can also affect focus, and get us distracted by things we’d like to implement, and make us forget what the main outcome of the project ultimately is. Whatever the project, keep reminding yourself what the expected outcome is.

Summarising the five points above into a single advice to anyone who, like me, would also like to start, specifically, a blog, I’d like to suggest: forget most stuff for now and start blogging today! Don’t waste your best thoughts and ideas that you’d better capture right now while you don’t have the perfect place where to host them -as happened to me so far.

Don’t care too much about the design, you can make it prettier later on. Focus on what blogging is about…that is… writing on something you like! Also spend some time with SEO and promote your articles in social networks (if people can’t find your blog in a way or another, it’s pretty useless, unless you write purely for your own pleasure), but postpone anything else that is not needed from day 1. Happy blogging!

Needless to say, I will try myself to always keep these lessons in mind in the future. Now that this site is live, I’ve just realised that blogging itself may be even more challenging than I had thought! I will now have to look for things to write about, and hope readers find these pages useful. And, more importantly, I will have to make time for all of this. But I am sure it will be fun.

In the meantime, I hope you enjoy reading my blog and find these pages useful!