Ramblings on tools and other thoughts

None of the below is gospel.These are, like, my opinions, man

Don’t take this page too seriously, there are jokes and other slightly cheeky bits on it

I employ the practices of KISS and DRY pretty much everywhere I can. Google them.

Or click the links. Who am I to tell you what to do?

This page should give you an idea of what my approach to development is


Jetbrains Phpstorm - my preferred IDE, my most important piece of software.

I have my own licence, you do not need to worry about that. Best software license money I spent.

It used to be eclipse php, and zend studio before that (aeons ago, before they started using eclipse as their base), but now it's firmly set.

I tried a couple of things in between (sublime, atom) and didn’t like them.

Source control

For over a decade I used SVN, with tortoise svn on windows as a gui.

I've gotten quite good at it, merging branches, managing releases, rolling back catastrophic bugs at 2am etc.

Setting up a server is no problem (apache and mod_svn), and it just works.

These days it's all about git, and github.

Fortunately, setting up a server is less of an issue than svn: if I have ssh or a network share, i'll manage.

If not, there is always github with private repos.

I think that an integral part of source control is change management.

This used to be bugzilla and a wiki, but I have been using trac for years and love it.

Today change management is much more involved, with automated tests, test coverage, reports etc.

I'm looking forward to playing with Gitlab (if i can get it to run on one of my RPI’s), jenkins, travis ci and jira.

I always let the stakeholders know their bug/change has been implemented in this release. Communication is important.

Many of them will test it for me (more on testers later) and let me know if it doesn't work.

They will get that warm fuzzy feeling inside that I did the thing for them, and I will let everyone that matters know that I’m not just a waste of an office chair ;)

They will remain silent if it everything works fine. But that's how IT works around the globe (if it works).


I still like bare metal servers.


....and i'm ready to go.

On windows dev boxes it used to be xampp.

Recently things changed, vm’s now rule.

Virtualbox and Vmware were first, then Vagrant was the first usable, if clumsy and heavy.

Now it's all about docker, which is fun, light, and easily lets me try out different configurations with multiple machines (failovers, mirroring, cherries on top).

I'm still looking at how to easily deploy to amazon/google/openstack, and figuring out what my preferred workflow will be.

There are plenty of good workflow examples online.


One of the best reasons to keep updating your software, including the software you write yourself.

Have a look at OWASP, cloudflare and mod_security.

Never ever tell me something bad is ok because nobody knows about it:

All you need is one nosy person running an automated tool to dig it up.

And then you're SONY'd.

I tend to use hashes for automated logins across web properties if there is no oauth token to work with. I will limit internal stuff by IP’s and logins. I will link it up with your organization's directory server (LDAP or whatever) for staff only resources.

However many customers you have - it’s their personal data you are holding, and if we fail, the consequences will cost us muuuuuch more than implementing security in the first place ever would.

Passwords policies exist for a reason. Allowing customers 3 letter passwords is negligence on my part, not theirs. Never hold the passwords anywhere. Hashes and salts are the way to go.

There are entire books and presentations on the topic, which definitely worth the paper they are printed on and more.


So many versions to choose from !

Latest stable is always best, if nothing else for the constant speed/memory improvements (php-fpm was a game changer!).

I started off with 4.3, now we're up to 7.3 with all the lovely oop, caching, autoloading etc. and there is no end in sight !

The stock install always requires a couple of extra extensions, be it xdebug on my dev machine, or something like soap, mbstring, sqlsrv or others that aren't default.

I keep the dev machines as close to the production servers as possible.

I keep the staging machines identical to the production ones.

VM’s are cheap. Bare linux is fine. VSphere is fine. Docker is fine.

Vagrant and Virtualbox and xampp are ancient and best avoided.

Frameworks and libraries

I'm a big believer in KISS.

If you already have a bespoke framework and application, good for you. I can probably make it work. I can definitely rewrite it using symfony ;)

If you want a single page site with no content editing and nothing dynamic on the backend, I will probably just generate a few static pages.

If you want something nimble, I will recommend silex, or a different microframework.

If you want something that staff will update, has a nice theme, categorises content, users can comment on, manages media, has loads of plugins for the stuff you need - I'll recommend wordpress.

It probably does what you need and more.

If you want something large, modular and bespoke, and have the staff to support it, Ill recommend symfony.

It works, is well supported, well documented, has many plugins/bundles/recipes.

Who remembers when all we had was pear and pecl for packages with stuff scattered across phpclasses for good measure ? :)

Today you want to use composer, but be sure you chose a live project.

So many dead insects on the web... :(

If the last bug was closed a year ago, and there is still a pile of them, I consider it dead.

You might take bits from it, or resurrect the whole thing, but you shouldn’t wait for an update to fix the issue you are having or implement a feature you want. It will never come. This applies to all open source projects.

Code Comments

I try to write just enough of them to help you figure out what something does at a glance, but never more than the commented code itself.

If I am describing something very complicated, I will go into the detail, but break it up into sections (it should have already been broken up with functions, classes, interfaces etc.).

Variable and function names should tell you what they are and do.

The only good single character variables are i and n for loops, and x,y,z for coordinates.

Domain specific knowledge applies when naming stuff.

I use phpdoc. You should too. It's a standard now. It takes next to no time to do.

It also lets me generate pretty pages of documentation to show to my fellow developers.

I’ll print it out and put it somewhere safe. A dusty folder in the closet.

I’ll initially get a clean one, and the next new hire will check if its dusty yet ;)


TDD, BDD, DDD, whitebox, blackbox and all the others.

I love it, it makes checking for regressions sooooooo much easier and faster.

Ideally on every commit into your semi-stable branch.

In reality though it's often an added cost, and is often done last, and only on key bits of the architecture.

Unless you are a software house. Then you need it. A lot of it.

Preferably with test coverage. And maybe mutation tests. And maybe do them across multiple versions of PHP. And you want code sniffers. And frontend tests, like selenium. Or one of the cloud providers that do that across many browsers. You want those in nice reports, especially when something goes wrong. Preferably saying what went wrong, when was the last time it was OK, and who to blame. And you probably need testers to look at accessibility, with tools like JAWS. (This is often a legal requirement). And if you are a software house, you need proper documentation as well. Both end user and developer documentation. Developers can write developer documentation. Someone else needs to write end user docs. And you need time to refactor the code for your customers in-house developers/designers AFTER you get it working in-house. A proof of concept, or a beta version is not the same as an end product.

Software houses have a greater responsibility and a lot more to do to make the product worth whatever it is the customer is paying.

The list could go on: plugin architecture, templates, languages, integrations, update systems, security audits, and on and on...

But you probably need testers anyway. Us humans are not very good at double checking their own work. It’s easy to miss something I think is obvious and have been working on for weeks.

You need a third party.

Sometimes all you need is a cleaner, or food prep person (or your mother, but she probably has better things to do) to click through whatever it is that you are building.

Fresh pair of eyes. If they can use it, and it does what they expect, I won.

My expectations are not the same as the expectations of the end user.

New toys !

I'm always open to new things, cool stuff keeps popping up every day !

Libraries, frameworks, architectures, tools and more !

Words of caution:

If you want to make money off, use established tools where possible.

Some old things just work

Design patterns for instance. Factory, Singleton, Listeners and others.

Think of them as problems that you keep bumping into.

These have been pretty much solved. Sometimes you might want to add your own twist, but they are a solid base to expand from.

Familiarity is a resource to be used:

  • It takes time to learn new stuff

  • It takes more time to learn to use it well

  • It takes even more time to learn about its limitations
    (usually the hard way, when you run into an invisible brick wall head first)


Honestly, I do not specialize in frontend work though I can still do it. It used to be simpler, even with the incompatibility between various browsers. (looks like google won the browser wars anyway, with edge moving to chromium)

These days there are numerous frameworks for frontend development with javascript:

React, Angular, AngularJS, Polymer, Vue and many others. Too many to list.

For my work I manage with jQuery.

Other frontend tools are more basic and have been around for years: html(5), css.

Css has been expanded since with sass and less, and there are multiple css frameworks (the one I work with is mostly bootstrap or some basic css grid).

The end result of using all of these should be pretty, responsive, at times dynamic - but not confusing.

I have a preference for simple and minimalistic designs - I find these do not distract from the actual content and make interactions easier for the users.

I consider a frontend design perfect if it:

  • Is simple and functional

  • Passes w3c validators

  • Is easy to work with on desktop and mobile browsers

  • Does not take too long to load

  • Is accessible (ie tested with something like jaws)

Also I’m not a designer. When forced to draw something, it usually ends up comparable to artwork gleefully created by 5 year olds.


KISS. If it already exists - use it.

If its open source and maintained, all the better.

I like to look at the code.

I like to fix things that aren't working and someone else is angry about it.

Or I'm angry about it.

Or just annoyed.

With closed source this is often tricky.


  • something closed source fits the bill perfectly

  • there are no open source alternatives

  • you trust the vendor

  • the cost is lower than developing it yourself

Buy it. This is a business, nothing is free. In-house developer salaries are non zero amounts. Even unpaid interns indirectly cost money (stuff needs to be checked by someone paid to do it).

Just check a few basic things:

  • How much making changes will cost. Get a quote.
    (avoid sticker shock for changing the style of a list or border around a box)

  • Are the changes you need possible ?
    Sometimes they are not.

  • What infrastructure does it require?
    I can't support C# applications running on IIS, I dont have the skillset.
    You need a different developer for that. And different infrastructure staff.
    And maybe MS server licenses.

  • When is the next version coming out ?
    Never ? Bad sign….
    Next month ? Maybe worth waiting.
    How much do upgrades cost ?

  • Please, for the love of all that is digital, ask someone in-house to check before buying.
    Sales people are there to make a sale.
    In-house developers are there to make sure things work in-house.

Maybe, just maybe... you can do it all in-house with a closed source product. There are good companies out there. There are plenty of crap ones, double check that you haven’t chosen one of those.

General musings on software development

I try to keep in mind real world limitations. These put additional constraints on decisions.

Ever heard of the joke about the manager who figured that 9 women can conceive and give birth to a child in just one month ? :)

Ramping up staff numbers is not a silver bullet. If it takes a team of 5 people 6 months, there is no practical way to get this down to 1 month.

If nothing else, more people means more effort to keep things coordinated and takes time away from the existing team to train up the new hires.

It takes time to go from a conversation in a meeting room to a project plan. It takes time to test stuff. It takes time to make unexpected changes (there are always changes).

I always try to give a realistic timeline for projects based on what I know and have worked with. I might underpromise and overdeliver, but this seems to make most people happy.

Maybe you can have it done in a month. There are a few reasons why this might be hard and cost a lot.

You can hire a larger, established team... Outsource.

Be ready to come with all the questions the team will have already answered.

The above is impossible, which is why negotiations and pricing take a long time.

You can spot an over-eager salesperson this way: they say 'yes' to everything without changing deliverables or consulting anyone.

Also, no changes at all to meet the deadline.

Also, check the stuff I mentioned in the open source section as well. Maintenance costs are a thing.

If you want to meet a firm deadline, you might have to make some compromises.

The best is the enemy of the good

Nothing I (or anyone else) ever write is perfect, because there are imperfect humans involved.

Developers, users, testers, requesters, third parties, management included - all make mistakes.

Late changes, feature creep, bad communication, no communication, natural disasters, deaths in the family, the inability to predict the future, and so many other things that can and will go wrong with all but the smallest projects.

I learned to simply accept that I will have to figure out how to work with what I have.

Get it out if it's good enough and iterate on it, keep improving.

Like the saying about planting a tree: the best time was 10 years ago, the next best time is today.

No such thing as a successful software product exists in version 1.0, forever unchanging since it was first scribbled on a napkin.

Even the 'true' binary had to be fixed and amended over time.

Negative feedback

Hearing 'no' from a developer like me does not exactly mean 'no'.

It means that as far as I can tell, the thing you asked for is not doable with the constraints I have.

  • Can you build this for tomorrow ?

    • No.

    • The boss has me working on the big thing, and will have my head if I drop it.

  • Can you fix this in the next 5 minutes ?

    • No.

    • The guy who knows how it works already left the building and will only arrive home in an hour. I can't even call him while he's underground.

  • Can you do this project in a month ?

    • No.

    • It will take a month to gather requirements and plan the work, and another 2 to get it done with the two people I have.

  • Can you get her to give birth in a month if you have 8 of her friends helping.

    • No.

    • That's not how it works. Have you heard the joke about the manager... ?

  • Can you have it done in X time ?

    • No, unless we drop all other projects.

    • I'll need to get an OK from my boss, and the owners of those projects, some of which have firm deadlines.

  • Can you build a sentient AI ?

    • Sure.

    • I need £20bn, a team of 2000 researchers and 30 years. Then maybe I'll have a delivery date.

Sometimes I have to give an answer in the negative, or a conditional positive where the conditions cannot be met.

Some might call this a negative attitude, if they never bother to listen to the reasons for the 'No': they are usually good reasons.

Sometimes the good reasons I have are wrong because I don't know about something you do.

Sometimes I need time to check if something is doable and can't commit to a 'Yes' on the spot.

Half of my job is poking holes in concepts and finding potential flaws before I get around to coding. This isn’t resistance to the idea, it’s a reality check that we both need to address to make the project happen.