I took the leap. I made the jump. As of almost a month ago I’m no longer an employee. I’m now an entrepreneur! That’s right, I’m now working full time on my startup Geomium. So how did it happen?

Even at University I was making small steps towards it, working on my own interesting tech projects and doing freelance development work. When I started work as a developer for Siemens I kept this up, making sure I continued to read up about new and interesting technologies, and to write about it all for this blog and others.

A great part of working for such a large company was that they had a fantastic graduate development program. I got to go on courses about communication, presentation, and negotiation. There were even team building exercises where we got to go rock climbing and tackle assault courses! The whole time I was thinking “How could I apply these skills to my own business?”, and I got to take a lot from the program. Working for a large company certainly had its downsides though, and after I’d completed much of the graduate course and finished the project I was working on I knew it was time to move on.

The Run Up

I had a brief spell with a smaller company, and although I preferred the smaller company atmosphere I didn’t feel I was learning much. I needed a challenge! That’s when I moved moved to London to join Mendeley, a tech startup, as their second employee and first web developer. Who knew that a couple of years later that Mendeley would have over 40 employees in London and New York, and have won numerous awards?

Getting in early on meant that I really got to make a difference, and was able to play a critical role in making Mendeley what it is today. I found working for a startup so refreshing. Good ideas get worked on right away, there are no forms to fill in, or committees or procedures to get in the way. It requires hard work though. I remember the mad rush to get the first public beta of Mendeley ready, with several of us holed up in the office with vast amounts of Redbull. We ended up getting the first tube of the day home at around 6am, when most people were just getting up for work. Long hours, but lots of fun.

Mendeley not only gave me the chance to work on a large-scale high-traffic website, with all of the technical challenges that entails, but as the company grew I took on the role not only of technical lead, but also web team lead, so I got to learn first hand about managing teams, setting deadlines and targets, interviewing and recruiting people. It was an invaluable experience.

Being based in London also meant I could take advantage of its great tech scene. There are loads of monthly tech events, and annual conferences. I tried to attend as many of these as I could not only to keep up with the latest tech, but also to meet new people and to open myself up to more opportunities. It wasn’t through one of these meetups that I would eventually meet my co-founder though.

The Jump

Around a year ago I was browsing a freelance job site and came across a post from Michael Ferguson. The post sounded really interesting, so I got in touch. We first met at Costa Coffee, and spent at least an hour discussing not only Michael’s ideas for the project, but also about our backgrounds and interests. I think we almost immediately realised we were a good match, with complementary skill sets. By the time we’d finished our coffees we were both excited about moving forward with the project that would eventually become Geomium. At the time I thought it’d just be another interesting side project to work on though, little did I know that 12 months later I’d be leaving Mendeley to pursue it fulltime!

As the project progressed Geomium demanded more and more of my time. Not only on development, but also meetings with potential partners and investors, and going to events to try and get the word out. It was becoming clear that Geomium would soon need my full time commitment. It was at this point that I had to take the leap, and it was a time of mixed emotions. It was hugely exciting, but at the same time I was sad be leaving a company I’d cared so much about and put so much effort into for the previous couple of years. It was also scary to be leaving the relative security of employment, especially as I have a wife and baby to support. Fortunately my wife is hugely supportive, and just as excited about the opportunity as me. I took courage in the words of Tom Preston-Werner:

When I’m old and dying, I plan to look back on my life and say “wow, that was an adventure,” not “wow, I sure felt safe.”

It certainly is going to be an adventure, but with hard work and dedication from Michael and I, and support from our family and friends, I’m sure we can make a success of it. So far things are going well. Geomium recently took third in the TechCrunch summer pitch battle, and we’ve had some good write ups. It’s still early days though, there’s a whole lot still to do. The really hard work starts now!

Being an avid reader of his online stuff, and having watched various talks of his I knew the book would be well written and informative, but I thought it’d probably just repeat much of what I’d already read, without providing much new information or insights. To a certain extent this was true, the book does reiterate what’s said in many of his online articles and talks, but the book is absolutely amazing for a different reason: The code examples.

The book is extremely succinct. There’s no padding, and very little dialog to join one section to the next. There is a common thread thoughout the book though, and that’s the code. Examples of good coding practices are repeated, and functions written in earlier chapters are often reused in later ones. So although the book appears to be presenting one feature at a time with a small code example you’re actually building up more and more complex javascript applications, and the book ends with a full JSON parser!

Crockford’s coding style seems to match his writing style: succinct and to the point. There’s some really great code in the book, that I think even non-JavaScript developers could appreciate. Here’s my favourite, from the chapter on regular expressions:

var parse_url = /^(?:([A-Za-z]+):)?(\/{0,3})([0-9.\-A-Za-z]+)(?::(\d+))?(?:\/([^?#]*))?(?:\?([^#]*))?(?:#(.*))?$/;
var url = 'http://www.ora.com:80/goodparts?q#fragment';
 
var result = parse_url.exec(url);
var names = ['url', 'scheme', 'slash', 'host', 'port', 'path', 'query', 'hash'];
var blanks = '       ';
var i;
for (i = 0; i < names.length; i += 1) {
    document.writeln(names[i] + ':' + blanks.substring(names[i].length), result[i]);
}

Which outputs:

url:    http://www.ora.com:80/goodparts?q#fragment
scheme: http
slash:  //
host:   www.ora.com
port:   80
path:   goodparts
query:  q
hash:   fragment

I also love the explanations Crockford gives as to why he avoids using certain parts of JavaScript, and limits himself to a “good” subset of the language. He doesn’t simply say “This is bad and you shouldn’t use it”, it’s usually accompanied by a story about a time when Crockford had used that feature and got caught out, which is much more compelling.

I think it’s fair to say that JavaScript: The Good Parts is one of my favourite programming books: It’s succinct, packed full of great code examples and best practices for writing maintainable and bug free code. It’s a fantastic JavaScript reference, but much of what the book talks about is relevant to programming in general. Highly recommended!

After forming a group most of Friday evening and Saturday morning was spent discussing ideas around the original pitch of twitter calendar integration. We discussed a whole range of ideas including an event broker service, calendar availability widgets, and a twitter/google calendar mashup. It took until lunch time on Saturday to finalise our idea. We’d settled on a a service that would automatically work out the date of an event mentioned in a tweet and keep track of these events. There were now only 36 hours left!

I got straight to work on the code, using Django. I knew we’d need to pull in tweets and then analyse the dates. Using the python-twitter library I wrote a management command to pull in all tweets containing some specific hashtags every minute.

The next stage was to work out a date from the tweets. A Stack Overflow question suggested two options, parsedatetime library, and some pyparsing example code. I tried the parsedatetime library first, and it gave some fairly good results right away. It wasn’t so good at more complicated dates though. I tried the pyparsing example, but unless given just the date string (eg. “Next week” instead of “See you next week”) failed to work out a date at all. I did briefly investigate using the NLTK to extract the date from a tweet, but worried about running out of time I gave up on investigating further and stuck with parsedatetime.

While I’d been busy programming Guillume had come up with a great name for our service: tweevents. He’d then set about registering the domain name, setting up a twitter acccount and facebook fan page. Once we had the name sorted I setup an online logo competition offering $25 to the winner, and an hour later we had our logo.

Gabriel worked hard overnight to produce some HTML/CSS for the site, so on Sunday morning I worked on integrating that into the Django project. We worked on adding features to the website, such as links to add events to your google calendar, hCalendar markup, and the ability to filter events by twitter username, and the rest of the day was spent putting a presentation together.

So tweevents is now up and running. Within 54 hours we’d gone from a rough idea into a working website. The presentation we gave gives some details about what’s next from the business side, but there’s also some things I’d like to get done on the development side. Most importantly improved date parsing. I plan to give the python-dateutil library a try, and failing that go back to look into NLTK in more detail. Guillume’s also working hard on improving the library we’re already using. Should none of the Python options work I’ve also come across some great date parsing libraries for other languges, such as Chronic for Ruby and Datejs for Javascript. A Rails or Node.js rewrite might be on the cards! There are also features that we could add, such as Facebook event creation, or filtering the list of events to just your twitter followers, or people you follow.

A huge thanks to Damien, James and Franck who organised and helped out at the event, and made it all so much fun. Of course, tweevents wouldn’t be much without the rest of the team. Thanks also to my girlfriend, who was left on her own with our 2 month old daughter for the entire weekend!

I posted the problem to the OAuth user group but didn’t get any response. I got in touch with Yahoo. After quite a bit of back and forth we finally figured out the problem, which I’m posting here to try and save others from months of frustration!

The Yahoo guys noticed that with Python2.5 the HTTP host header was being sent through as as “fireeagle.yahooapis.com:443″, whereas 2.6 sends “fireeagle.yahooapis.com”. The inclusion of the port results in an invalid OAuth signature, because the signature is generated assuming the port isn’t included. I dug into the Python2.5 httplib code and came across this:

 813    if self.port == HTTP_PORT:
 814        self.putheader('Host', host_enc)
 815    else:
 816        self.putheader('Host', "%s:%s" % (host_enc, self.port))

In Python 2.6 the comparison on line 813 is done with self.default_port instead of HTTP_PORT, which prevents the port from being added with HTTPS requests. I noticed that later on in the code that if you pass in your own host header it prevents one being created for you:

 875     def _send_request(self, method, url, body, headers):
 876         # honour explicitly requested Host: and Accept-Encoding headers
 877         header_names = dict.fromkeys([k.lower() for k in headers])
 878         skips = {}
 879         if 'host' in header_names:
 880             skips['skip_host'] = 1

So the fix turns out to be really simple – explicitly set the http header. That’s exactly what I’ve done in my fork of the fireeagle library (see the fix). I’ve also sent a push request, so hopefully this fix will make it back into the original library. Thanks to Arnab Nandi and Anand S from Yahoo for helping to debug things their end.

37signals are the creators of the popular Ruby on Rails web framework and the people behind successful web applications such as basecamp and campfire. Their previous book Getting Real, about effecitive web application development, really resonated with me.

When I heard that they were writing a new book, ReWork: Change the Way You Work Forever, about “building, running and growing (or not growing) a business” the 37 signals way, I was excited. Especially as it arrived at a time when I’m working on my own startup.

A week has passed since my copy arrived from Amazon, so I’ve had a change to read the book and write up some of my favourite points below.

Planning is guessing

“Working without a plan may seem scary. But blindly following a plan that has no relationship to reality is even scarier”

Don’t make long term plans, or at least don’t obsess over them if you do. I think the key point here is be flexible.

Start making something

“Ideas are cheap and plentiful…the real question is how well you execute.”

Coming up with cool ideas all day won’t get you anywhere. Starting something will. Even if it’s lame, you’ll learn something that’ll make the next attempt better.

Build half a product, not a half-assed product.

“Getting to great starts by chopping out what’s merely good.”

The classic 37 signals do less argument, about less being better, and bloat being bad.

Launch now

“Stop imagining what’s going to work. Find out for real.”

I’m also reminded of the Reid Hoffman principle here:

“If you aren’t embarrassed by what you launch with, you waited too long to launch.”

Good enough is fine

“When good enough get the job done, go for it. It’s way better than wasting resources or, even worse, doing nothing because you can’t afford the complex solution.”

I think the above rule is really a specific version of this one. Get something basic done first – worry about making it great later!

Pick a fight

“Having an enemy gives you a great story to tell customers…They take sides. Passions are ignited.”

This is certainly an approach that 37 Signals employ, and it seems to have worked well for them. OnStartups have a good article on the power of polarization which goes into more detail about this idea.

Don’t confuse enthusiam with priority

“The enthusiasm you have for a new idea is not an accurate indicator of its true worth. What seems like a sure-fire hit right now often gets downgraded to “nice to have” by morning.”

Don’t drop everything to start on your latest idea. You’ll constantly be chasing new ideas, and never finish any of your old ones which might be just as good, if not better.

Take a deep breath

“When people complain, let things simmer for a while. Let them know you’re listening…but explain that you’re going to let it go for a while and see what happens. You’ll probbaly find that people will adjust eventually.”

Every time Facebook change their privacy settings there is a huge uproar. When websites change their design you hear complaints. Changes aren’t always for the best, but there are some people complain no matter what. The advice given here is to wait a while for things to settle down before making any decisions based on the feedback.

Four-letter words

“Need, must, can’t, easy, just, only and fast. There words get in the way of healthy communication. They are red flags that introduce animosity, torpedo good discussions, and cause projects to be late.”

This is one of my favourite points in the book. I’ll certainly be making an effort to avoid these assumption-ridden words in the future!

Inspiration is perishable

“Inspiration is a magical thing, a productivity multiplier, a motivator. But it won’t wait for you. Inspiration is a now thing. If it grabs you, grab it right back and put it to work.”

So true. A great reason why you should start making something the second you feel inspired to do so.

They were my favourite points, but the book is filled with many more. If you’ve also read the book I’d love to know what you though and what your favourite parts were, either in the comments section or on twitter.

A feature I’ve often wanted, that is currently missing from PHPUnit, is a simple command line display of code coverage statistics when you’re running tests. If you’re trying to improve the code coverage of a specific test it isn’t practical to generate a full HTML report of the test every time you run it, and then check it in a browser. It would be much easier if the code coverage could be reported next to the success or failure message on the command line.

After a little bit of investigation into the different PHPUnit reports, and some git, awk, and sed hackery I came up with the following PHPUnit wrapper that does exactly what I was after. Once you’ve run a test, or collection of tests, it’ll display a list of files affected by the test and the code coverage for each file. The code for this script is below:

#!/bin/bash
METRIC_FILE="/tmp/test-metrics.xml"
# Call PHPUnit will all provided command line arguments, and also generate a metrics file
phpunit --log-metrics "$METRIC_FILE" $@
# If phpunit exits with an error then exit here with the same error code
if [ $? -ne 0 ]
then
   exit $?
fi
# Do some manipulation of the metrics file and output each file and the coverage for that file
echo "*** SIMPLE COVERAGE REPORT ***"
cat "$METRIC_FILE" | grep "<file" | awk '{print $2 $10}' | sed
"s|$PWD||g" | awk -F\" '{printf "%-50s %.2f%\n", $2, $4}'
# Cleanup
rm "$METRIC_FILE"

I’ve place the script in /usr/bin/phpuc on my machine, and then I can invoke it like so:

$ phpcs tests/ExampleTest.xml

PHPUnit 3.3.16 by Sebastian Bergmann.

.........

Time: 0 seconds

OK (9 tests, 9 assertions)

Writing metrics report XML file, this may take a moment.
*** SIMPLE COVERAGE REPORT ***
Example.php                     89.37%
IncludedFile.php                 12.9%

Hopefully this will be something that’ll be built-in to PHPUnit in the future!

The code is based on Matt Biddulph’s screenshot-tng script, but heavily modified to be more user friendly and provide more options. It uses embedded mozilla for rendering, and therefore requires the python-gtkmozembed package.

You can specify a resolution to take the screenshot at, and also a resolution for the thumbnail. When generating the thumbnail the aspect ratio will be preserved. You can also specify a delay, so that the screenshot is only taken so many seconds after loading the page. Here’s an example of running PyWebShot with 3 URLs, and the resulting images:

$ ./pywebshot.py -t 500x250 http://www.coderholic.com http://geomium.com/update/598/ http://jobs.plasis.co.uk
Loading http://www.coderholic.com... saved as www.coderholic.com.png
Loading http://geomium.com/update/598/... saved as geomium.com.update.598..png
Loading http://jobs.plasis.co.uk... saved as jobs.plasis.co.uk.png

It you have a huge list of URLs you’d like to generate screenshots for you can put them all into a file and generate images for them all with the following command:

$ cat urls.txt | xargs ./pywebshot.py

For more details and the source code see the PyWebShot project page on GitHub.

While all of these design principles and practices will certainly help you to write better software there are lots of them to learn, and lots to remember. When you actually sit down to write some code and you’re under pressure to get it finished as soon as possible some of the best practices can go by the way side.

Here are three acronyms that are simple to remember and will almost certainly help you to write better software. So whether you’re writing a small function, a class or a large module spare a few minutes to think about these acronyms and hopefully your software should end up being easier to use, test, maintain and understand as a result:

DRY

Don’t Repeat Yourself – The DRY principle is about not repeating any logic or knowledge throughout your software, it’s about removing duplication. At the very least this means that repeated code should be moved into a function or class – no copy and paste! Taken to an extreme it means even things like a database schema and database interaction code should be generated from a single source. In their book The Pragmatic ProgrammerAndy Hunt and Dave Thomas recommend the use of code generators to help remove all duplication from a project.

With no duplication software becomes much easier to maintain. If something needs to be changed you know you’ll only need to change it in once place. It should also be easier to understand and test as a result.

KISS

Keep It Simple and Stupid – The KISS principle is about avoiding needless complexity, and keeping things as simple as possible. This doesn’t apply just to code, it can also apply to features. As 37Signals say in their free book Getting Real, which contains lots of suggestions for maximizing simplicity:

“The key is to restate any hard problem that requires a lot of software into a simple problem that requires much less. You may not be solving exactly the same problem but that’s alright. Solving 80% of the original problem for 20% of the effort is a major win. The original problem is almost never so bad that it’s worth five times the effort to solve it.”

Almost by definition simpler software should be easier to use, test, maintain and understand – so don’t forget KISS!

YAGNI

You Ain’t Gonna Need It – YAGNI is about not writing code now for things that you think you might need in the future, because the chances are that you won’t, and even if you do the software you write now will likely be less than ideal for what you actually need in the future.

As a Software Engineer it’s easy to get carried away and think about generalized solutions to the problem you’re working on, or other ways in which your code can be used. This isn’t necessarily bad, and thinking about these issues can certainly aid maintainability and software reuse. The point of YAGNI though is that we shouldn’t actually write the code until we need it. Otherwise we have to maintain code that may never be used, and the time could better spent on other things.

Getting Starting with Clojure

Getting up and running with Clojure was made easy to to the wealth of documentation. There’s a great getting started guide, and a guide specifically for Clojure on Ubuntu. In terms of programming environment there’s a round up of Clojure IDEs. I stuck to Vim, but I didn’t take it as far as this guide, which describes turning Vim into a fairly comprehensive Clojure IDE.

Clojure has a REPL, which I always find makes learning a new language easier. When you want to find something out just type it in a see what the result is! The default REPL doesn’t support arrow navigation or pressing up to run previous commands though, so it can be a little frustrating. There are guides on enhacing the REPL with this functionality.

One of the first things I did was put together the following shell script which either runs the specified Clojure script, or gives you a REPL if no script was specified.

#!/bin/sh
CLOJURE_JAR="/opt/clojure-1.1.0/clojure.jar"
if [ -z "$1" ]; then 
        java -jar "${CLOJURE_JAR}" 
else
        java -jar "${CLOJURE_JAR}" "$@"
fi

Writing Code

I decided to write a port scanner in Clojure, which would introduce me to command line argument handling, the network API, and parallelization.

One of the great things about Clojure is that despite being such a new language there is so much example code available on the web. I was able to find a Clojure network scanner by Travis Whitton which detailed all of the network related code I’d need to my port scanner. Travis uses Clojure’s agents for parallelization, which is something else I borrowed from his script. I was amazed at how easy it was to parallelize the lookups. So much simpler than threading. If there is only one thing I take away from Clojure it’ll be its interesting approaches to parallelization.

So without further ado here is my Clojure port scanner:

(import '(java.io IOException)
        '(java.net Socket)
        '(java.net InetSocketAddress)
        '(java.net SocketTimeoutException)
        '(java.net UnknownHostException))
 
(if (== (count *command-line-args*) 1)
  (def hostname (first *command-line-args*))
  (
    (println "Usage: scanner <hostname>")
        (System/exit 1)
  ))
 
(defn port-open? [hostname port timeout]
  (let [sock-addr (InetSocketAddress. hostname port)]
    (try
     (with-open [sock (Socket.)]
       (. sock connect sock-addr timeout)
       port)
     (catch IOException e false)
     (catch SocketTimeoutException e false)
     (catch UnknownHostException e false))))
     	<li>
(defn host-port-open? [port]
  (port-open? hostname port 5000))
 
(def port-list (range 1 1024))
 
(def agents (for [port port-list] (agent port)))
 
(println (str "Scanning " hostname "..."))
 
(doseq [agent agents]
  (send-off agent host-port-open?))
 
(apply await agents)
 
(doseq [port (filter deref agents)]
       (println (str @port " is open")))
 
(shutdown-agents)

I’m sure it is far from an idiomatic solution, so any suggestions for improvement are welcome. Running the scanner with my bash script gives the following output:

$ ./clj.sh scanner
Usage: scanner <hostname>

$ ./clj.sh scanner github.com
Scanning github.com...
22 is open
80 is open
443 is open

What’s next?

I’ve barely scratched the surface of Clojure, but I’ve certainly become more aware of some of the concepts and idioms used by the language, which is what I was hoping for. I’ll be looking for more projects in the future where I can make use of it. For now though I need to move on to another language as part of my challenge. As I’m running behind I plan to go with one that I don’t think will be too unfamiliar, either Go or Fantom. I’ll keep you posted!

This all changed for a project that has been taking up all of my spare time lately, Geomium, a location-based communication tool. MySQL’s geospacial support is almost completely non-existant. PostgreSQL, on the other had, when combined with the PostGIS extension, has fantastic support. So PostgreSQL was what the project needed. I thought it’d be fairly easy to transition from MySQL to PostgresSQL but the command line clients of these two RDBMSes are very different. Here are some of the things I’ve learnt.

A few other things to note: PostgreSQL only supports single quotes in queries not double quotes, so

SELECT * FROM table WHERE column = "value"

would need to be rewritten as

SELECT * FROM table WHERE column = 'value'

PostgreSQL also defaults to being case-sensitive, whereas MySQL defaults to case-insensitive, so you might want to modify your queries to something like

SELECT * FROM table WHERE lower(column) = 'value'

although this can prevent an index on “column” from being used.

At first I thought PostgreSQL didn’t support some of the handy MySQL date functions (such as NOW() – INTERVAL 1 DAYS), but it turns out that it does support them, and more. It’s just fussier about the format. For details see the datetime documentation.