A simple app to monitor Google Chrome on OS X

I was on-site with Vigill one day before Christmas and I mentioned to Oisin an idea I had for an app.

I was sick of having endless tabs open in Chrome, hogging memory, each one some seeming important enough at the time that I read it but now just a contextless enigma.

If I at least knew how many tabs I had open, it would be a step in the right direction I thought. There’s got to be an app for that, right? Not that I could see. Opportunity knocks.

Enter AppleScript

I knew that AppleScript would likely give me the functionality I was after so that night in the hotel I installed the Ruby version of the easier to use though now abandoned AppScript and was eventually able to get some details out of a running instance of Chrome concerning it’s open tabs.

Over the Christmas holidays I spent an evening playing with the NSAppleScript class and figuring out how to add an item into the OS X status bar. Huzzah!

Give it a name

Naming things and cache invalidation, 2 notoriously hard things. Inspiration soon struck though and I stumbled upon a catchy name for the app which corresponded to an available dot com domain. I didn’t register it straight away but later in a moment of entusiasm I whipped out a card card and starting piecing together a single page site with Bootstrap to give the app somewhere to live online.

Oisin and myself have been using Bootstrap a lot these last few months as we’ve been building out the Vigill platform and it’s truely a godsend for those of use with the natural tendency to produce apps which look like they’ve been designed by a programmer. I recommended it highly.

The Future

To date the app doesn’t do much, it sits in you status bar, displaying the number of open tabs in Chrome. You can click on the number and choose to quit the app. Fits a need but it’s nothing fancy.

Suggestions have included to show how long the oldest tab has been open, how much memory is being used and even an idea to apply some gamification and have an online leaderboard of tab fetishists.

As with all my personal projects I never know if I’ll ever come back to them after the initial buzz of motivation has passed. In the early days of this blog, nearly 6 years ago now, I was hacking on desktop apps and I can feel myself being drawn back to the world of compilers and executables so chances are good I’ll revisit this app in order to sharpen my skills with Objective-C and Cocoa. Suggestions on a postcard please.

Get It

The app is available to download from chromitor.com and the code is available on GitHub, hopefully you’ll find it useful.

My also-ran Markdown Editor for OS X

Quite often I feel the need to learn something new for the sake of learning something new. Covey aficionados would know this as sharpening the saw.

I usually struggle deciding upon something however as there are so many areas to choose from in the software world and it isn’t everyday I feel drawn enough to something to put time and effort into it on top of holding down a day job.

Five years ago it was Rails, two years ago it was testing that I wanted to improve my skills with and I’m now waiting on whatever will be the next major piece of technology or practice I feel I need to push myself towards.

Before the web

When I started out teaching myself to write code I didn’t have access to the Internet and the web as we know it didn’t exist. My output was to evolve from simple CLI programs to games to desktop apps.

These past years a lot of my work life has involved developing web software with scripting languages. Compilers, graphics routines and assembly language have all started to become lost in the mists of time.

Returning to desktop software development seemed like both an interesting challenge and a break from dealing with the web. As I’ve little interest in cross-platform toolkits this meant Objective-C and Cocoa, technologies which I pick up every once in a while but haven’t produced much with. But what exactly to develop?

Eating my own dog food

In May I was working on-site with a client in Dublin and had to produce some documentation for the analytics platform I was building at the time. As usual I chose Markdown and put up with the workflow of editing the content in Vi and running it through the supplied Perl script to see what the HTML, which was eventually to handed over to the client, looked like.

It struck me that here was repeated effort I could automate with software and there didn’t appear to be a widespread, simple Markdown editor for OS X. An opportunity at last to start work on a first offering from my software company I thought.

The possible beginnings of a product-based business

Over the course of a few months I added a bit of code here and an interface tweak there, mostly while staying in hotel rooms in Dublin. Any time I wanted to edit some Markdown I used the app and it suited my purposes fine.

I toyed with the idea of publishing what I had on the Mac App Store. I shared the binary with a couple of people to see what they made of it and was extremely pleased when one asked if it was ok to pass the app on. I could see a possible path opening before me allowing me to start stepping away from a consultancy business model to one centred on selling products.

Beaten to it

Life moved on though, I started a new contract which gave me a lot of new technology to play with and development of this side project was put on hold.

About a month ago I spotted Mou. Not only was it more complete than my effort but it was better designed than I could hope for considering the limitations on my time and Cocoa experience. “Fair play” I thought, I wasn’t quick or decisive enough and as a result, if I’m to build this planned business it will have to be on the back of a different product.

Today I spotted Marked and a quick search turns up a number of other apps and text-editor plugins. Such is life.

Open source

As of today it’s been over 3 months since the last commit to the repo and many superior alternatives exist so I thought I may as well give it away.

The app suits my needs though it would be even better if it could saving/load files from the local filesystem. I may well tinker with it for my own learning purposes but who knows what side-project my interests will wander to next.

The code is available on Github and compiles with Xcode 4.1. Enjoy.

A tale of three pull requests

After years of earning a living through using free software I’ve finally contributed back to the open-source world.


For the two and a half years I’ve been pushing some personal projects to Github and some of my code I’ve been told has even been helpful for others. While this is certainly open-source none of my efforts have affected existing codebases.

Numerous times I’ve scoured the bug trackers of projects I’ve had some sort of interest in, on the lookout for an issue I could investigate, even getting as far as reading through upteen lines of foreign code but ultimately unable to add anything.

A first attempt

The project I’ve been working on for my current client, like many other projects, makes use of a handful of libraries.

I discovered one library I’m using to access an API had failed to implement a feature I required. My choices were to abandon the library and the code I’d already written using it, open a feature request in the hopes it would be worked on or man up and do the needful myself. Can you guess what I decided upon?

After forking the repo and creating a feature branch I wrote a test for the needed behaviour, wrote some code to implement that behaviour, committed the changes when the test suite passed, pushed to GitHub and finally opened a pull request. Unfortunately the original author decided he didn’t want that feature in the library at that time.

Such is life, the code fit my own purposes, I was able to get with the task at hand and at the end of the month invoiced my client. Things have been worse.

Once more with feeling

A similar situation occured again a bit further down the line: another library I’ve been using required a small modification to fit in with the constraints placed upon this project. I went through the same procedure as above and this time there has been no response.

Ah well, things could still go either way and at the end of the day I still have the functionality I need.

Third time lucky

Last week i was debugging an issue involving authenticating against a SAML Identify Provider. I was eventually to deduce that the library in question on this occasion didn’t support the algorithm used to compute the digital signature of the authentication response.

I drank a lot of espresso, scratched my head a lot and then found a library supporting this algorithm. The downside was there was no documentation or tests.

There was nothing to do but read the code. I was able to get something working after a while and thought it would be a shame not to share my understanding so I wrote a quick test and put in place the mechanics to run the test which in itself yielding some more know how.

Forks, branches, pushes, pull requests, merges, deploys, happy client, problem solved, home time.


All I basically contributed was a unit test. I didn’t invent anything new or expend any great time or effort but I did give something of myself and didn’t expect anything in return. This has always been the spirit of open-source software and it’s why I use it all day, every day.

No matter how insignificant you feel your contribution may be, it’s the small changes that keep the wheels of the open-source machine turning.

The pull request was merged into master, maybe you’ll find it useful.