Category Archives: Tips

10 New year’s resolutions for IT pros

1st of January

Self Improvement is a hard thing to do at the best of times. Putting pressure on yourself to change at the start of a new year is probably not the best of ideas, but we do it anyway (much like choosing to run Windows 8).

So without too much additional preamble here is my list.

  1. Backups – We are all guilty of not taking adequate backups… or often in my case taking adequate backups but not automating them or keeping them organised. This doesn’t need to be a big complex system, it could just be a cron job tar’ing up the important data, encrypting it and uploading it to the cloud.
  2. Improve security – There are still a lot of us choosing to not embrace TLS for their services and with StartSSL and LetsEncrypt offering free certs and PositiveSSL (I get mine via Namecheap) being pretty cheap, there is no excuse. In addition to this why not use this time to start using keypairs for your SSH (Microsoft announced SSH support back in June)  for secure access to your systems.
  3. Stop procrastinating – We all have these little things we have put off; fixing that computer in the corner, cleaning the office, learning a new language or framework or perhaps asking that girl at the coffee shop out. The first step in getting stuff done is to just fscking start it… and then continue doing it. I just wish I could take my own advice…
  4. See the world and meet new people – I know many of us are most comfortable when it is just ourselves and our computers, but if we are to grow as people we need to experience new things and be exposed to new ideas. Perhaps goto a usergroup (I sometimes goto some of the London DevOpsy ones and PHP:East Midlands) or perhaps a conference or two.
  5. Be more polite – We all get stressed from time to time and in our quest for efficiency we can forget how we are coming across. It probably isn’t helped by the fact that many of us communicate better with a machine than face to face. Like any skill we can hone it and become more adept at it.
  6. Be more organised – We often complain that there are not enough hours i the day but conversely know people that seem to manage to accomplish so much. It generally comes down to two things: being more organised and prioritising what is most important.
  7. Spend time with people that matter (and less time with the people that don’t) – As you get older you come to understand some of the decisions you have made in life didn’t always align with your current values. I doubt that when I am old and grey and laying on my deathbed that I will say ‘I wish I had worked more’. More likely I will lay there wishing that I had spent more time with the people that were important to me. Why wait for this time when you can do something about it right now?
  8. Get more sleep – Lack of sleep can affect your health, your stress levels, your effectiveness at work and indirectly the people you live and work with. Do the world a favour and don’t shortchange yourself on your rest.
  9. Eat healthier – Your body works better if it has the right fuel. Over the past couple of years I have come to understand I can’t just keep abusing my body and I am trying to turn my health around a little… unfortunately, I haven’t found this trivial with spending 13 hours a day out of the house and commuting 250miles a day…
  10. Exercise more – Spending hours a day sitting on your arse isn’t ideal from a health perspective. I try to get up at least once an hour and stretch my legs and get out for a walk at lunch – I say try because sometimes this is easier said than done…
  11. (Bonus) Learn to be content with your life – We all have things we regret doing; choices we made; opportunities that we passed up; girl friends we haven’t got over etc. We might also be looking forward to certain events in the future…
    We need to stop living in the past and live in the now. The future hasn’t happened yet and the past is gone and can’t be changed. We need to live in the moment; embrace it and let the past go.

10 things any newbie web developer needs to know

PHP or other language

I’m not going to preach about the pros and cons of different languages, suffice to say that any sufficiently advanced website is indistinguishable from magic requires more than just just static files to make it work. PHP is my language of choice (and has been for over a decade) but there are plenty of other options out there (Python, Ruby or even (shudder) .net)

Which you choose depends more on what is most comfortable to you and what support network you have to call upon. It isn’t generally a good idea to learn Python in a Microsoft shop for example unless there are other pressing reasons to do so.

Whatever you end up learning, you need to be competent in its use, make use of the extensions available (no point reinventing the wheel when there are dozens already made for you) and know how to use the online documentation. Coding style helps, but as long as you are consistent really isn’t that pressing unless you are working with others.


Even if you don’t deal with much front-end code yourself, perhaps you use templates, you still need to understand at least the basics of XHTML and CSS to make it easier for the front-end developers to deal with your output. At the very least your code needs to output well formed, correctly nested code. We mean

<div><p><b><i>hello world</i></b></p></div>

rather than

<div><p><i><b>hello world</i></b></div>

(note the lack of ending <p> tag and improperly nested <i> and <b> tags) an XHTML validator will help, but only on the finished output. They don’t work on fragments of code like this.

MVCs, frameworks and libraries

As stated above, and especially if you are getting paid on a per project basis, you want to reduce the number of times you want to reinvent the wheel. This is known as Don’t Repeat Yourself or DRU. There is no point writing yet another PDF library for example when FPDF, Zend_PDF, Pdflib and many others already exist (or docbook/ps via converters etc) and do an adequate job for most tasks. MVC or Model-View-Controllers to give them their full name are a concept (or design pattern) that allows you to separate the data access parts from the actual logic and the templates used in your projects. This is useful in a team based environment because the designer can design, the coders can code and the coders and DBAs can control the models and how they interact with the databases – it just tends to separate the roles more cleanly and make modifications at a later date easier. If you want to add sharding to the database, you can simply modify the models while keeping the interface the same and suddenly your app can be cluster aware. It’s really a win-win situation.

I use Zend Framework under PHP to provide a MVC and other libraries. I’ve tried Code-Igniter and Kohana and while they work, they either feel dated (in the case of Code Igniter) or just are poorly documented (in the case of Kohana). Zend Framework, while not trivial to get up and running for the novice, worked well for the way I work.


OOP is one of those things, you either love it or hate it. I personally tolerate it with a mild distain – but that is just me. (I predate the whole OOP revolution.) Put simply, OOP allows a set of related variables and functions to be pulled together into a single package called a class. You then can either extend the class in your own projects overriding or extending the various functions (called methods) or use it as is. The biggest advantage, especially when you are importing a lot of libraries is that unless you are careful, two libraries may have a function or variable with the same name. (This is solved with namespaces in the latest PHP versions) At best the interpreter or compiler throws an error, at worst one library may end up calling a function or trampling over the data from another unintentionally.


At its simplest level a regex is a way of matching patterns within strings. When used to their full ability, a regex can sometimes replace 10-20 lines of non regex code with a single line. They are often used in Mod_rewrite rules, input validation and searching for certain things within quanities of text. Learn them, use them and master them – they will save you a lot of time.

Source Control

Even when working on your own projects, you sometimes wish you could turn back time and undo something stupid you did a month ago in some code. Your backups have been recycled and a lot of changes have been made since – it sounds like a lost cause. This is where version control comes in. Everytime you are happy with a set of modifications you check them in. The difference between the old version and the current version are worked out and saved. At a later date you can go back and see who made the change, when it was done and exactly what was changed. If you want to checkout a copy of the code as it was at this time, you can do that. This is almost essential in a team-based environment as it allows auditing of code in a more detailed way than simply looking at backups from a particular point in time. What if one of the coders inserted a backdoor into your code? Wouldn’t you want to be able to identify every other change that was made and check them for similar nefariousness?


As a developer you will often find questions and problems that you don’t have the answers for. You can try to puzzle through it yourself, but there is a whole world of people out there, many of whom have already solved similar issues and put their answers online. Being able to search effectively puts these answers at your fingertips.


Not everyone in this world has perfect vision, perfect hearing or the ability to use a mouse. Many sites are designed in such a way that every user is assumed to have adequate abilities. If your site assumes that all readers can use your fixed-sized font, will have Javascript enabled and have will be read rather than listened to using a screen reader then it probably wont be accessible. There are many tools and concepts that don’t take much effort to make your site easier for users with impaired abilities, some are listed below.

Monitoring and SEO

A site is a success if it reaches its goals. It is hard to know if you are hitting them if you have no way of measuring the values the goals specify. Are you being seen by 100 people a day? Are you selling at least 3 widgets from your site a week? Does your advertising campaign result in increased sales and traffic? You need to measure anything that you need if you are going to try to set goals on these things – simple idea, but it’s suprising how few people ‘get it’.

SEO is related to monitoring your traffic in a similar way to energy efficiency is related to watching how much power you use. Unless you know where you are starting from and where you are now, you can’t know how much you have improved by and if you are paying for adwords or similar advertising, then how much each extra visitor or sale is costing you.

JQuery and other JS toolkits

It is all well and good being able to produce dynamic pages and process forms from the server-side, but sometimes you really need something extra on the clientside as well. Enter JavaScript.

JavaScript or JS has been around since the mid 90s and is standard on all major browsers. The big problem comes when certain features exposed to Javascript (Ajax, Storage, Location, DOMs/BOMs etc) vary from browser to browser.

The easy solution to this is to take a library that hides these differences and make it easy to write code once that will run on most other browsers. Jquery is one option, but not the only one.

In addition to this there are many libraries, shims and other utilities that make doing more complex things easier. JQuery for example has the UI library which makes certain tasks such as tabs and date pickers trivial to add to your page.

This isn’t an exhaustive list and I’m sure there are many things could be added to the list. If you feel I have missed something, please add it below in the comments section.


Lessons I learned from building startups

Sysdom isn’t my first startup, it isn’t even my second, but comes some way down the list at 3 or 4 (or 8 or 9 depending on whether you want to count startups that I didn’t have equity in). In that time I have made mistakes (oh so many mistakes), but I have learned from them and tend to make completely new mistakes the next time around. 😉

I will try to distil some of that hard learned knowledge into a something that others can learn from so they don’t have to make the same mistakes I have.

Happiness is everything

If you aren’t happy going to work then you really shouldn’t be doing this. You will work harder for something you enjoy and unhappiness will spread to colleagues and customers. In the end it will make or break the business.

Everything has a cost

While you might not value your time during the initial stages of building your new enterprise, your time does have a cost. Any time that you spend reinventing the wheel or building solutions to a problem that can be solved cheaply by using an outside service or product is time that you are not concentrating on your core product.

Everything has a value

Any time you are building solutions to problems you are creating value. While it might be difficult to turn this value into money (ie. by productising it) it quite often can be used to build reputation or build attention for you and your business.


If you don’t have a vision or aim, then you are essentially just randomly hitting keys and hoping to come up with the complete works of Shakespeare – it is unlikely to happen. Start with a problem that vexes you regularly then solve that problem. It is quite probable that other people face the same problem regularly too.

Never take outside money

Taking other peoples money is never a good idea for a small startup. It gives them a massive lever in the direction of the business and often results in the business going in a way that you dislike. Result? You end up getting dissatisfied with the business and work suffers.

Don’t give away equity

Giving away shares in your business should be one of the last resorts. It can mean that employees will work harder, that investors may bring in expertise to assist in the growth of the business, but unless done right it will mean huge risk and little benefit.


If you aren’t breaking new ground then you are really just building a ‘me too’ product. This isn’t always a problem, but makes it hard to differentiate yourself in a market filled with clone products. Innovation is key: make it simpler, faster or do something no other product does.

Pivot and think laterally

Inside almost any solution is the key to solving an even bigger problem. Build a good solution and you often have other products that can be brought to market with minimal effort.

Be Lean

Even if you do have cash available, you don’t have to spend it. Do you really need that flashy usb coffee cup warmer? That £800 office chair when a £100 will do? The same goes for infrastructure. Why buy a £5k server when you can build using cloud servers (Rackspace Cloud and Amazon Web Services for example) at a fraction of the price and gain redundancy to boot. Yes, it will be hard, but these challenges will make you face up to the real problem – that of bringing in customers and cashflow.

Fail fast

If the problem isn’t really a problem or your solution doesn’t adequately solve it then don’t be afraid of quitting before you sink too many resources into it and move onto the next problem.

Don’t quit at the first hurdle

If you find a problem that you can’t solve initially, don’t quit. Other people will be facing the same issue and a solution will mean you have an advantage over them. This doesn’t mean you should sink resources into something that is unlikely to be able to recoup them – fail fast in this case.


You are unlikely to get it right first time. Build a product then improve it one problem at a time. Sometimes it will look nothing like how the original concept was envisioned – this is fine and normal.


Metrics and logs should be an integral part of everything you build. If you can’t measure it you can’t improve it. Web logs are a good start, but alone don’t tell you much besides who is visiting and how many times they have visited. You also need to know how many resources you are spending on servicing each visitor.

Low barrier to entry will mean many competitors

If the solution is easy, then many people will build one and compete with you. For example, there are many projects cloning 37signal’s Basecamp product or bringing basic telephony services to market based on the open source asterisk project. If the problem is harder, then you will have less competitors and will be be able to price your product higher.

Find your niche

Your niche should be somewhere where you can dominate, where few competitors exist and you can grow unhindered. For example, applications for pig farmers – there are a lot of them around the world…

Some competitors will always race you to the bottom

Racing your competitors to the bottom is generally a losing race for everyone involved. Without the cashflow to innovate and support your product, your service will suffer and your product will likely stagnate. Charge a fair price, explain what your customers are paying for and point out why a lower cost solution isn’t suitable. 37Signals have been releasing uptime and customer happiness metrics for just this reason.

Stop doing things that don’t get you towards your goals

If it doesn’t get you closer to your goals then it isn’t worth spending your time on. Stop doing it, or at the very least outsource it.

You aren’t perfect

It is unlikely you will have all the skills required on your own. Don’t be afraid of buying in talent to bolster your skill-set.

I hope that this has been interesting and please do leave any additional lessons in the comments below.

MongoDB Journalling

A quick one if you are wondering about MongoDB and Journalling (especially on Debian/Ubuntu from the MongoDB repo) .

By default mongodb will generate 3gig of journal files in /var/lib/mongodb/journal this is far from ideal if you are running on a Rackspace CloudServer or smaller VPS.

There are two easy solutions:

  • If you are running as part of a ReplicaSet then you can choose to go without journalling altogether with the

    option in mongodb.conf.

  • Alternatively you can request that MongoDB uses smaller preallocated files for journalling use the

    option in mongodb.conf.

To also reduce some usage in your datafiles there is the also the

noprealloc = true

option, however I don’t see this as particularly useful considering the preallocation starts pretty small and only grows as your data does.

Bash Tip #1

Often when operating on the commandline you may want to re-execute something with elevated privileges. There is a shorthand way to do this rather than either cutting and pasting or retyping the line.

mike@mike-P35C-DX3R:~$ updatedb
updatedb: can not open a temporary file for `/var/lib/mlocate/mlocate.db'
mike@mike-P35C-DX3R:~$ sudo !!
sudo updatedb

The first updatedb command needs to be ran as root, initially I forgot the sudo so it couldn’t update the database. Running it again with !! meant that I didn’t have to retype the whole command… Obviously this is more impressive with longer lines…