I’m sure i’ve written about a Sublime Text package called SublimeTODO before.

It’s easy to install but getting to the list of todos isnt retibble easy. I created a keyboard shortcut of cmd+shift+g. Add this to your user key bindings, making sure it’s valid json.

    { "keys": ["super+shift+g"], "command": "todo" }

If you work on projects with a package system (NPM, Ruby gems, Composer etc), builds scripts or other stuff you didnt create, you don’t want to search them for todos. Add this to your user settings. Note that you can easilly create new comment prefixes. I have CRITICAL, MAYBE and a few other things.

    "case_sensitive": true,
        "BUG": "BUG[\\s]*?:+(?P.*)$",
        "CHANGED": "CHANGED[\\s]*?:+(?P\\S.*)$",
        "CRITICAL": "CRITICAL[\\s]*?:+(?P.*)$",
        "FIXME": "FIX ?ME[\\s]*?:+(?P\\S.*)$",
        "FUCKTHISSHIT": "FUCKTHISSHIT[\\s]*?:+(?P.*)$",
        "MAYBE": "MAYBE[\\s]*?:+(?P.*)$",
        "NOTE": "NOTE[\\s]*?:+(?P.*)$",
        "TODO": "TODO[\\s]*?:+(?P.*)$"

I like inline todos.

Update: 14:52pm, 29th Jan 2014
As Leny pointed out, this plugin doesent work in Sublime Text 3, so he made this plugin. I’ve not tested it.

Update: 20:33pm, 11th June 2014
I wrote a new article about a new plugin for Sublime Text 3.

Pretty Pre

If you work with PHP, chances are you work with arrays and boolean data. I’m sure we’ve all used print_r() to show the data on the page to aid debugging and themeing, but i’m also sure we’ve all accidentally left something in when the site went live.

This is a function I add into all my PHP projects that prints arrays and boolean values in a big yellow box that;s hard to miss. It’s limited to 300px in height, but that max can be turned off by making the second attribute false.

The advantage to abstracting this is that you can simply comment out the echoed data and prevent anything going onto the page. If your framework has the concept of environments, you could also build it in so production never echoes this data.

// $var is the data
// false turns off the max height
pre($posts_array, false);

It’s simple, and it works.

function pre($var, $maxheight = true) {
    $maxheightcss = ($maxheight) ? 'max-height: 300px;' : '';
    echo ' style="background: #fcffb1; text-align: left; outline: 4px solid rgb('. rand(0, 250) .','. rand(0, 250) .','. rand(0, 250) .'); width: 100%; overflow: auto; '. $maxheightcss .'">';
        if ($var) :
        else :
            if (is_bool($var)) :
            else :
                echo "\n\n\t--- No data received by pre() function ---\n\n";
    echo '



This is a list of anything & everything that annoy me, either a little or a lot. It’s in no particulate order and has no real reason to exist, other than possibly saving on Twitter rants which always go on for far too long. Anyway…

  • Responsive websites which don’t responsive on anything larger than a small tablet.
  • People who call their child a ‘mini person’ or ‘thing’.
  • Militant privacy activists with no power to do anything, i.e. armchair politicians.
  • People who drink IPA’s, coffee via obscure methods and skinny jeans but insist they’re not hipsters.

Kodery UI Technology Stack

I often get asked about the tools I use to build the user interface for the new Kodery. I thought I’d write it up and point people here in the future.

Note: This is not the stack for the API. The UI and API are 2 completely separate, at least in terms of technology.

Markup & Styles

I used no framework for the design or markup, except for Bourbon which only gives me shortcuts, no styling.

Aside from the main index.html file which is needed to kick everything off, all views are Handlebars templates. The home page is a view, the navigation is a view, the category & snippet list is a view. It means the markup is kept simple and I can easily re-render a section with fresh data, pragmatically.

Styling is done with SCSS and Bourbon. There’s a few global defaults for things like text and form elements. It makes heavy usage of variables and custom mixins to make the code cleaner and easier to adjust. Rather than have a few fixed media queries, most visual changes happen when something starts to break. If that happens at 569px wide, then so be it.

Vendor JS Files

Custom JS Files

  • plugins.js has loads of small, simple plugins in such as polyfills for string.contains(), string.replaceAll() and obj.lazybind() which can be used for delayed hover interactions and such.
  • handlebars_helpers.js has over 20 custom helpers for things like checking permissions against the logged in user, relative time (3 minutes ago, etc) and passing markdown, which is as simple as {{markdown description}}.
  • app/local.js has all the logic for setting & getting stuff from LocalStorage. I chose to write my own, as it usually always means it’s better for the product.
  • app/support.js has a few tests for browser compatibility. It’s fairly sparce at the moment, but is there to be added to.
  • app/utils.js is home to string/password generators and converters, like get_url_parameter() which lets me get URL paramaters, much like $_GET['thing'] in PHP.
  • app/snippet.js has all the logic for adding and removing fragments, and copying code to the users clipboard.
  • app/helpers.js could probably be combined with app/utils.js. Is has functions to render Handlebars views and getting JSON from the API.
  • app/search.js only has the logic to do real-time search of the data in LocalStorage. Simple.
  • app/do_page.js has the logic for each page or part of a page, which can mean getting new data from the API, rendering a view, or anything else specific to the action.
  • app/store.js is the middleware that sends data to the API, and runs a callback (if provided).
  • main.js is huge. Currently 1136 lines long. Is handles all the routing which then initiates other stuff, controlled in the files above.


This is a crucial part of the build process. I won’t go into great detail (that’ll take hours) but as a brief overview.

  • Combine JS files in a predefined order.
  • Compile SCSS
  • Insert the Handlebars views into the bottom of the index.html file.
  • Go through the index.html and .htaccess file (alpha is on a Linux box) and replace variables with version number for cache busting, like filename.0.1.2.ext.

There’s 2 build processes. One is for local development which keeps everything big and debugable, that builds into build which is what my local server uses as the document root. The other builds the production files, which are minified and have gziping enabled (via .htaccess). That goes into dist.

So there we have it.

Nothing ground-breaking. It may not be the best way of doing it, i’m sure there’s ways to automate more and reduce the code I write, but for now, and the 8 months i’ve been slowly working on it, I have a full understanding about how it all works. There’s nothing happening in the back that I can’t explain and improve upon.


I started smoking in mid 2011, going through a rather tough stage in my life. I got introduced to it on what was seemingly a good day, in a hellish half of the year. I had recently started driving, and with my own sanctuary, I started smoking several cigarettes a day, typically while driving to work, and when going for evening drives with a friend.

It was a rush. Initially, it felt more rebellious, an adrenaline rush, not nicotine induced. With time though, the addiction kicked in and I started buying packs of 20 instead of 10. This was my life for the next two and a half years.

Apart from mid 2012 when I had a girlfriend who also smoked when I was on 20 a day, my typical habit dictated around 10 cigarettes a day. Luckily for my health (relatively) and my wallet, that relationship didn’t last long. I quickly cut down to 10 again.

I never kept my smoking a secret. I wouldn’t hide it from anyone, but I wouldn’t force it on anyone either. I would wait for quiet moments in social situations and sneak out for a quiet 5 minutes, where i’d usually end up talking to others with the same idea.

I would call myself a considerate smoker. I would always try to leave a decent block of time between smoking and meeting people or going into someones home. I also made sure I stood far away from non-smokers. It’s my choice to smoke. I stood far away from those who don’t.

I always carried mints and deodorant. I was very aware of the smell, and for one person, the taste, but for me, the nicotine hit was more than worth these downsides.

A cigarette every hour or so kept me levelled in times of stress. It kept my head level, at least compared to when I had no cigarettes available and was craving a hit.

This was until Autumn 2013 when I got introduced to vaporisers. They meant I could get the hit I needed, the hit I craved, but cheaper, with no smell and in a more socially acceptable way.

It took a few months to transition between cigarettes and the vaporiser, but in time, I mostly use the vaporiser. I spent about £60 on the vaporiser, but the cost of liquid is so low compared to cigarettes that i’ve already saved so much money.

As it stands now, early January 2014, I have one or two cigarettes a day. I still enjoy the motion of standing outside with a cigarette, lighting up and stubbing it out, but it’s early days I think. I’m sure that with time, I will completely cut out cigarettes and eventually the vaporiser too.

With time, I will go ‘clean’. On my own terms though.