mark’s blog

In the beginning was the Nerd, and the Nerd was with God, and the Nerd was God.

The Nerd did write a simple rails application and deployed it unto a shared host provider.

The people were made of aware of the Nerd’s work via an intriguing message on twitter and they were pleased.  The people told their friends about the Nerd’s work and there was generally a reasonable amount of interest all things considered.

Soon, the many clicks of the masses did  bring the site asunder.

The Nerd’s operations skills were exhausted so did appoint a system administrator who deployed the Nerd’s work to The Cloud.

The people and their friends were mightily impressed.  They did click a lot on The Site (being young and unafraid of repetitive strain injuries).

Many many clicks later, the Nerd appointed a few additional developers and the system administrator appointed a few operations personnel.

The Nerds developers were busy.  Lots of excellent functionality was being added.  Deployments were frequent.  There was much clicking and rejoicing among the people.

Soon, issues with the production environment were encountered.  The System Administrator asked the Nerd for consideration – “perhaps it’s time for a ops guide – The Site is getting rather complicated”.

“Suck it up” stated The Nerd simply, “This is a Start Up and I won’t be paying my developers to write documentation for you.”

There were outages and The Nerd was angry.

“You guy are incompetents”, The Nerd said to the System Administrator while garroting a work experience student.

The System Administrator became angry and introduced a change control process:  ITIL was its name.

The Nerd was allowed to deploy once  every lunar cycle but only if all of the documentation materials were in good order.  The exact audience or nature of this documentation was not made clear and thus, The Nerd would regularly be rejected by the change control process for non compliance.

The people weren’t exactly unhappy.  They’d just lost interest.  Someone else had a similar idea and new exciting features were appearing all the time.

It’s been around a decade since I first started getting paid specifically to write software.  It seems a reasonable time to look back and speculate about the things that i’ve realised over that time.

One person’s personal revelations almost never correspond to anyone else’s and so perhaps most of these things will seem completely obvious.  Equally, it is often difficult to distinguish something insightful that just happens to immediately make sense from something that is completely obvious and unremarkable.  Hopefully then there’ll be some nuggets of wisdom in amongst what is possibly going to be a series of small semi coherent rants.

There are a number of assumptions that I had started out with regarding software development that wasn’t aware i’d made and that have turned out to be completely wrong.  I’m going to try to mention those here together with some assumptions I see others make that just disappoint me or make me really annoyed.  None of these are necessarily original or my own invention.

1. You should find one language and master it

As with many of the points i want to make, this is fairly well covered in the pragmatic programmer book.  You should aim to learn at least one new programming language a year.  One language is definitely not going to work for you – web development means that you will at least need to know one language such as java, scala, c#, php, ruby, python or perl but also be familiar with some of sql, javascript.  That and all the ‘frameworks’ that exist on top of those languages you need to understand such as rails, struts, wicket, lift, spring, django, hibernate, seam, asp.net mvc, jquery, prototype etc.  You will be useless as a developer until you have passing familiarity with a lot of these things.

I find it very odd that the various communities that surround these technologies are often quite insular.  These various communities have a great deal in common and are all trying to solve similar problems.  It just doesn’t make sense that in particular that developers involved in more ‘enterprise’ platforms such as .net or j2ee have so little communication.  This also applies to the dynamic language communities (ruby/perl/python) vs the same ‘enterprise’ platform developers.

2. You should receive paid training to learn anything new

This is always just offensive and absurd but I encounter it all the time.  If you aren’t familiar with something – mobile application development, web development – go out and read some books, some blogs, attend some user group meetings.  It is no one’s problem but your own if you don’t know about the technologies you’re paid to use.

3. You should write ‘chameleonic’ code

This is straight out of pragmatic programmer – the notion of ‘broken windows’.  Despite understanding this, I had the false belief that when code is particularly incomprehensible the worst thing you can do is put some code that makes sense in the middle somewhere.  Instead I thought you should write code that is consistently awful until you have to opportunity to completely rewrite everything.

Legacy code is difficult.  Read the Michael Feathers book for some ideas but ultimately the time to rewrite the entire application from scratch probably will never come.  Making small improvements over time will certainly make the code seem less consistent but at least starts sending the message that it is worth improving.  Talk to each other before trying to introduce radically new approaches, patterns or whatever as everyone must understand the technical direction the code is taking.

4. Comments and documentation are really useful

Comments are a lazy way to indicate when you couldn’t think of a better way to express something in code.  I find TODOs especially irksome.  If you have gone to the trouble of working out how to improve something why don’t YOU fix it?  Sometimes these fixes might take a lot of time – if that is the case, write it down as a task that can be given attention and priority rather than just a self righteous comment buried in the code.

Documentation unless autogenerated or executable  is most often misleading and WET (waste of everyone’s time).  No one could really be surprised by this – unless by heroic vigilance, documentation very quickly falls out of date and becomes nothing but a source of confusion and misinformation.

5. Greenfield projects are more interesting than dealing with legacy code

It is so much harder to deal with an existing system that I’ve now realised that it is the main challenge of software development.  Very few of your projects will be from a blank slate so stop complaining about legacy code and just get better at working with it.

I feel mostly when I am working on a greenfields project that i’m primarily just producing legacy code.  You know your sticking to the ’simplest thing that can possibly work’ will not accommodate future changes and can hear future developers bitching about the crappy code you’re now writing.

6. Writing software is about telling computers what to do

Computers will do whatever you tell them unless what you tell them doesn’t make any sense.  Computers can make sense out of almost anything so that’s not much of a safeguard.

Software development is about communicating with other developers.  That means both the developers you’re working with at that time and also all the developers that will ever work on your system.  Make the software make sense to humans or those humans will hate you and try to destroy you.

7. Testing is something someone else does for you once you’ve written some code

Write. The. Tests. First.

Just do it.  It is hard.  Don’t let anyone tell you it isn’t.  It is hard because normally you wouldn’t be forced to work out what you actually want to do.  You would just storm in, all guns blazing and write some awesome code that does some stuff.  What that stuff is you’ll find out eventually.  Most of the time you’ll be disappointed and a little embarrassed as it will not do some of what it should and a lot of stuff you didn’t intend.

When you write tests, you’ll know when you’re finished and you’ll know that it works.  It is incredibly important to see that your test fails first.  You then write some code. Then you see your test pass. Rinse. Repeat.

You can then safely refactor.  Refactoring will ultimately reduce the number of people in the world who hate you.

Write the outermost acceptance tests first so you know the lower level functionality is actually necessary.  Do not start writing unit tests for some class that may be completely unnecessary.

There’s nothing new here but it is amazing how many people say they believe this and then don’t actually ever do it.

8. Testing is easy work for less competent people

Testers are strange and gifted people. Great testers will break your system in ways you never thought possible.  That doesn’t happen by mindlessly keyboard mashing until something bursts into flames – it involves consideration and exploration.

To show respect for these gifted people who will ultimately save you from a humiliating career suicide if your bugs get out into the real world, you should work with them to automate everything that can possibly be automated.  Making intelligent people follow reams of lists of  manual tests such as ‘type “giblet” in the search field’,  ’click on the “search” button’ is unprofessional, disrespectful and will only lead to workplace gun play.

9. Email is an excellent way to keep track of people’s commitment to decisions

I’ve worked on plenty of projects where rather than talking, people find it more reassuring to conduct all communication via email.  This gives them the false sense that there is a trail of evidence in case some project disaster takes place.  Because everyone is aware of this – that each communication goes down on their permanent record – no one really has much incentive to commit to anything or to be completely clear.

The solution is simple: talk.

10. Agile software development is good in some limited situations

I’ve been at ThoughtWorks since the start of 2007.  Before that I’d read a lot about agile software development but really hadn’t had the opportunity to put it into practice.  That’s a real shame as not one project I can think of would not have been far better off following an agile approach.

For some reason, the term agile has a bad reputation.  It is easily ridiculed I suppose – people can make jokes about being bendy or dexterous.  From my point of view, agile projects are the only ones that admit that no one really has any idea of what they’re doing.  Not only is it unclear what the system needs to do but also it isn’t completely clear how the team should work together.  So you apply a few basic principles, follow some sensible practices and just cautiously evolve your team just as you evolve your software.

Stop pretending you know everything at the start.  You don’t know what will change, you don’t know what the people you have are best at or how they will most effectively work together.  People will always surprise you.  You will need to set yourself up to make the most of those surprises.

11. Agile software development isn’t rigorous enough

This is just crap.  If you’ve ever said this then just punch yourself in the face right now.

Generating charts based on made up metrics and speculation is not rigor – it is waste.  Generating charts that plot actual functionality against time is not crap – it is simply fact.  To take this further, deploy every successful piece of functionality straight into production.  The charts will become very easy to draw in this scenario.

12. You should always buy before you build

Products can be awesome.  I’d have to be in a pretty dire situation if i thought it was a good idea to write my own database server, http server or operating system.  I am a software developer but I don’t believe that I am the only competent software developer.  Almost all software products will have been written by people with similar or superior development skills.

The problem with buying a product isn’t that it is not well implemented.  It’s that it doesn’t do what you want.  If you are not prepared to change what you want to more closely coincide with what the product does then you are in for a world of pain.

Here’s a lame metaphor that I just can’t let go: say I want to get from Sydney to Perth,  could get a direct flight but that might be expensive,  instead I get a much cheaper flight that takes me to Darwin.  It turns out that the flight from Darwin to Perth costs three times as much as a direct flight from Sydney to Perth.  The solution is to enjoy staying in Adelaide.  OK – perhaps i’ll hold off the metaphors for the remaining rantlets.

13. A programming language is about syntax and tools

This one seems to come up a lot.  Nothing is safe in this industry.  Some bastard has a better idea for a programming language, all the cool kids start using it and suddenly you’re all alone managing 1,000,000 lines of java.  So how do you choose a winner? You can’t

Surely because eclipse and netbeans are great IDEs and java 7 might have closures we’re safe aren’t we?  Not really

The strongest indication is the sort of community that surrounds a language, the associated frameworks and open source contributions.  Java has a great history in this respect which suggests that it (or at the very least the JVM) will be around for a long time. .NET on the other hand is newer to this game.  Sites like codeplex and the presence of alt.net groups is a very healthy sign.  The best indication for me is user group attendance.  People who are keen enough about a language community to attend regular user group meetings and present at conferences are likely to be interested in investing in the community.

14. Women do analysis, testing and database administration. Men write code

This should be the biggest rant – it drives me crazy.  The alpha geek phenomena in software development is by far the most shameful aspect of the craft.

I have actually had people say to me that they sincerely believe that women do not write code as well as men. Why? How does this make any sense? Kill yourselves now.  You might think you are a great developer but your misogyny and arrogance are destroying an industry that desperately needs more proportionate representation of the population.

15. Open source software is written by dirty dope-smoking hippies

Maybe no one really does believe this.  I’ve worked on projects where we had to use some hideous and overwrought product just because supposedly a manager somewhere in the stratosphere thought it was a bad idea not to buy something.  Perhaps there was no such manager – just a middle level manager that assumed that such a manager existed further up the food chain.

Regardless, it makes no sense.  You have as much chance of apache httpd, tomcat, mysql, postgres falling to pieces as you do oracle, sap, jdedwards or peoplesoft.  Even if they did, you’d have the source code.

16. You can control change by meticulous planning

This is probably just the same agile rant.  You cannot control change – you can only manage it.  Prepare for it by identifying the things that you suspect might go wrong, guess their likelihood and have an idea of what your reaction might be if it does come to pass.  Controlling change is just burying your head in the sand and needlessly restricting people from getting things done.

17. You should try to use the same technology at every layer of your application

This relates to the very first point.  The best example is that if you write web applications you should learn javascript.  Not cutting and pasting chunks of javascript from tutorial sites, actually learning javascript.

Generating javascript using java, scala, ruby or whatever is just lame.  Eventually you will encounter something that can’t be generated by the tools and you’ll have to understand javascript anyway.  Javascript is beautiful.  Learn to love javascript

I extend this to testing.  Just because your writing a web application using C# does not mean that you shouldn’t consider using awesome tools like mechanize, selenium and cucumber to write your tests in ruby.  If nothing else, when you look at some code, you’ll immediately be able to tell what layer of the system you’re dealing with.

18. Anything remotely good can happen for anyone after fixing price, scope and date

Pretty basic stuff.  If you can completely ensure nothing at all will alter the likelyhood of your project succeeding then go right ahead.  What is the point of your project then if there is no risk at all?

19. You need to be loud to be influential

More whining about alpha geeks I suppose.  I’m a shy quiet kind of guy.  I don’t want to ever have to yell or shout to make my point.  If you yell or shout, you have not convinced me or anyone else to take your point of view.

If you have a good idea, people will naturally adopt it.  If they don’t then perhaps it wasn’t so awesome after all or perhaps you need to find a more effective way to communicate the idea.

20. You need to choose to be a project manager or an architect for when you grow up

I really really like software development.  There’s nothing like the satisfaction of creating something that actually works.

So I resent this notion that at some point, I need to grow up and completely lose my grasp of low level technology.  I’m not interested in managing people – people are scary. I simply want to continue to improve and most importantly to share my experience with other like minded people.

21. There’s something special about large organisations

The only thing special about large organisations is that they are large. The size of an organisation

22. Code can not be beautiful

Everyone should get to experience the joy of working on a piece of code for a while that really just doesn’t make sense. By moving things around, teasing things apart gradually the mist begins to settle. After a while of this, all of a sudden, from the chaos emerges this brilliant shining jewel of clarity. Shielding your eyes from the painful intensity, tears streaming down your face, you commit your changes to the source repository and struggle to get on with the rest of your life.

You image other developers unwittingly opening the file. They think that this is just another normal day. It’s going to be yet another bit of source code that they need to decipher. As the text editor opens, before they can get protective eyewear on their face, the ingeniousness of your source code streams out at them. Their face is mildly scorched but they know they have seen true beauty and their lives with never be the same again.

23. Anything remotely important can be gained by static typing

24. Learning ‘old’ languages is pointless

25. Learning theoretical computer science is pointless

26. You should design your system by starting with a relational database schema

We have too long been enslaved to the relational database. This is strange. Databases can be a good place to put things. Clever people have worked out how to make them fast at getting those things out again quite quickly. Then people suddenly started waving rule books around about how we must normalise our schemas to 3rd normal form. Then sometimes we should denormalise in order to achieve gains in efficency. The rules sometimes say very foolish things such as that we must only talk to the database using stored procedures – that anything else is less secure and inefficient.

Sometimes, you can store data in these things called files. Some data can even be stored in memory or big distributed hash maps. Sometimes people like to store data in directory servers. Some data is is just better to leave with Jeff because Jeff is a good guy.

So when you next assume you need a relational database. Think again.

27. CASE tools are eventually going to be really useful

Most modern IDEs are designed to make generating code easier. This is because writing code is really hard so the only practical alternative is to have software write software for you. You don’t know what you’re doing so you need tools that turn the pretty diagrams you understand into source code that you can’t.

The worst culprit is Visual Studio – within seconds of starting a new project, visual studio can have written thousands of lines of code for you – web service implementations, web service clients, entire data persistance layers flash past the screen into your source control system.

28. Design patterns are crucial and you should use them everywhere

Design patterns are very interesting to read about and discuss. It is great to stand at a whiteboard and talk about classes collaborating with other classes in a way that makes sense. Especially if this is a way that the business stakeholders standing around can almost get their heads around.

What is not interesting is a design pattern trivia wankfest. There are few conversations more pointless than those that take place after an agreement has been reached about a particular technical direction that involves deciding which design pattern words to use to describe it. Is it a bridge, a proxy, an adapter? Is it a flyweight perhaps?

Understanding the concepts of design patterns is valuable but please stop writing software by gluing design patterns together and pretend you’ve produced a system.

My daughter Maisie makes up some interesting games so I thought I should document a few of them. These games involve some fairly interminable repetition but I’m sure it won’t be long at all before I look back and really miss playing them.

Each game will be varied at some point by Maisie saying “I’m daddy and you’re Maisie”.  She means that in order to swap our roles in the game we must swap our actual identities – it’s quite confusing and seems perhaps a little excessive the first time it happens.

The Ladies

This game involves a couple of barbie dolls.  They mainly take turns cooking some food, getting distracted by something while the other one eats the prepared food (see ‘the cooking game’).  They also sometimes either act as shopkeepers (a butcher’s shop that sells variety of things including shoes) or as customers.

The Cooking Game

This game is played outside.  One of us pretends to prepare some food which then has to be left to cool down.  While the food cools down, the other player eats all of that food.  The first player then returns and is disappointed so has to cook more food.

The ‘What’s that?’ game

This is a cool game.  First you throw the doona on the floor. Then get all pillows and cushions in the house and put them on the bed.  You then lie down.  Maisie will then bring things and put them on the bed.  Your only responsibility is to ask “What’s that?” as each new thing arrives.  The main challenge with the game is that you may fall asleep.  Sometimes Maisie gets distracted, forgets that you’re on the bed and stops bringing new things.

The Doll’s house

The game is played with pretty much anything at all and a dolls house.  Maisie says “what’s she gonna do” and you need to pick something interesting for the character to do.  Most often, she’ll just say “no” (ie. not interesting enough).  Other times, she’ll say “no” and her character will start doing it (ie. too interesting).  Occasionally your character will get to act out the suggestion.

The Tricky Game

This game involves running from one end of the house to a bedroom, diving under the covers of the bed but leaving your legs sticking out.  The other player then enters the room, pretends to look around for a while before eventually admitting that they know where you’re hiding.  When I’m hiding Maisie will find me first and then hide with me (having yelled out for Terese to come and find us).

The Babushkis

Unsurprisingly, this game involves some russian dolls.  The game revolves around them finding their bottom halves or just ‘bottoms’.  They try each of the unsuitable bottom halves saying things like “no, that’s much too big”, “no, that’s much too small”, “no, that’s got wee in it” or “that’s got poo in it”.  Not sure if this is obvious but the advent of this game coincides with the start of toilet training.

The Jungle Game

This game again involes the russian dolls.  This time they go exploring caves and encounted various sorts of ’scary things’.  The scary things as usual include ghosts, monsters, leopards, kittens, heaters, giraffes and hippopotamuses.

I feel compelled to write a list of the new albums that I really got into last year.

The Dodos – Visitor

I’ve just been thrashing this album for some reason and can’t wait to see them next Tuesday night at the Northcote Social Club.

Man Man -Rabbit Habits

I saw these guys a few weeks ago at the East Brunswick Hotel.  Unfortunately, due to some poor organisation on my part I missed the first 30 minutes of their show but what I saw was awesome.  They have an amazing amount of energy.

Fleet Foxes – Fleet Foxes

I missed out on tickets to see these guys perform but played this album incessantly since coming across it.

Titus Andronicus -The Airing Of Grievances

Yeah this band’s a bit adolescent and angsty perhaps but I love it and played the hell out of it.

Islands -Arm’s Way

These guys are just brilliant.  Perhaps this album is a bit more catchy than ‘Return to the sea’ and not so coherent but a band’s gotta cater for these youngsters with their ipods buying a few songs while old timers like myself are compelled to hear entire albums.

Hot Chip -Made In the Dark

Really catchy stuff – should’ve gone to see them.

Ladytron – Velocifero

This is the way 80s music should have sounded in the 80s.  Really brilliant album and another band i’m going to regret not seeing this year.

The Notwist – The Devil, You + Me

Yeah so this was no ‘Neon Golden’.  I just think Markus Acher has a great voice and I like their subtle indie-electronica.

Portishead – Third

I never really liked Portishead in the 90s – I thought they were vastly overrated and their music was irritating.  This album however is excellent and completely unlike the old stuff.

She & Him – Volume One

Zooey Deschanel is one of the few successful actors that has made the very difficult leap into recorded music.  For reasons I don’t understand, people are very unforgiving when actors think they can also make music (regardless of whether music was something they were interested in prior to acting).  It is totally unforgivable for an actor to create tedious or awful music (um … Scarlett Johanssen).  Fortunately Zooey has a really great voice and M. Ward is a genius so this album is flawless.

Sigur Rós – Með suð í eyrum við spilum endalaust

I really wish I saw this band.  Life is just so much more exciting with this music as a soundtrack.

TV on the radio – Dear Science

Each of their albums becomes just a little bit more mainstream I suppose but they’ve always been brilliant and too cool for school.

Emiliana Torrini – Me and Armini

I don’t love every song on this album but Gun is my favorite song for the year.  She has a really interesting voice that can sing a wide range of completely different musical styles.

The Kills – Midnight Boom

This is my least favorite album from The Kills but still listened to it a lot.  The songs were much more radio friendly and less dark than the other albums.  It was somewhat of a guilty pleasure.

Vampire Weekend – Vampire Weekend

It’s really interesting this indie-african phenomenon.  It brought back some painful memories of Paul Simon’s Graceland album on occasion but I really loved it.

Flight of the Conchords – Flight of the Conchords

Yeah maybe this album is somewhat overwrought but these guys are fucking hilarious.  It’s rare to laugh everytime you listen to the lyrics of a comedy song but Bret and Jermaine’s laconic style never seems to lose its appeal.

I checked out this blog on my phone browser yesterday. It still looks awesome but is completely impossible to use. The unusability of this blog is probably the feature I find the most endearing.

Blogging often seems such an act of vanity (especially when you have nothing interesting to say).

Here’s a picture of Maisie for no good reason (enter ’startx’ to see how beautiful she really is).

I really like the portrayal of nerds in rands in repose’s nerd handbook but just can’t go along with it. I like it because it’s flattering to nerds but can’t help feeling that there’s a much more serious pathological aspect to being a nerd that is completely glossed over.

I consider myself a fairly earnest and serious nerd and so state all of the following on behalf of myself and not necessarily anyone else. So here’s a list of additional characteristics that any prospective nerd partner should be made aware of:

a) a nerd is completely useless around the house. I like the idea of a clean house but find no intellectual stimulation in the actual execution of cleaning activities and so do them desultorily and badly.

b) a nerd is physically extremely unhealthy. My nerd pathology primarily consists of requiring a constant stream of novel intellectual stimuli. If a choice has to be made between reading a book and exercising – guess what happens.

c) a nerd is not interested in being considered attractive. Basic personal hygiene is something most nerds can muster but that’s pretty much where it ends. Having the slightest interest in fashion is probably an important aspect of being a member of society. It is not possible to wear clothes that say nothing about you.

d) a nerd is lazy. I just can’t be bothered explaining this. Instead, i’ll spend hours writing something that generates the explanation.

e) a nerd is forgetful. I added his one about a week after publishing because I forgot. I have an anniversary on remembrance day and have forgotten 3 years in a row. Most nerds try to compensate for this with technology.

f) a nerd is … well there are plenty of others (refer to d).

I have to agree though that all nerds are incredibly fucking funny – just ask me about my lemon tart joke (I refuse to accept that it is unfunny).

More to remind myself than anything else, this post provides the details for getting started using private git repositories on site5 (and pretty much any other shared hosting service that has ssh available and is willing to install git).

To start, you’ll need to politely ask the technical support people at site5 to install the latest stable redhat git rpm. They did this for me but mentioned that this is with no technical support (ie. if you mess up your repository somehow, you’re on your own) and that you must not leave any server side process running (such as git serve). You’ll also need ssh access to your site5 account – you enable this on backstage.site5.com.

I’m doing this on a brand new ubuntu hardy heron installation as I write this but everything I mention should work equally well on other linux distributions, mac os x and cygwin under windows.

Set up ssh dsa key pair

user@host:~$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_dsa): (hit enter)
Enter passphrase (empty for no passphrase): (enter a passphrase and hit enter)
Enter same passphrase again: (enter the same passphrase and hit enter)
Your identification has been saved in /home/user/.ssh/id_dsa.
Your public key has been saved in /home/user/.ssh/id_dsa.pub.
The key fingerprint is:
15:94:f2:f2:36:a7:37:1b:9c:23:80:30:96:30:ee:00 user@host
user@host:~$ scp ~/.ssh/id_dsa.pub remoteuser@remotehost:
remoteuser@remotehost's password: (enter password and hit enter)
id_dsa.pub 100% 605 0.6KB/s 00:00
user@host:~$ ssh remoteuser@remotehost:
remoteuser@remotehost's password: (enter password and hit enter)
Last login: Sat Aug 9 23:34:20 2008 from 122.122.122.122
[remoteuser@remotehost ~]$ cat id_dsa.pub >> .ssh/authorized_keys
You should now be able to ssh to your site5 account without being prompted for a password (you may be prompted for the passphrase for your key if ssh-agent is not setup – i’ll come back to this).

Create a git repository on site5

[remoteuser@remotehost ~]$ mkdir -p git/repo.git
[remoteuser@remotehost ~]$ cd git/repo.git
[remoteuser@remotehost ~]$ git --bare init
[remoteuser@remotehost ~]$ exit
user@host:~$ mkdir git
user@host:~$ cd git
user@host:~$ git clone ssh://remoteuser@remotehost/~/git/repo.git

Push some changes

user@host:~$ echo 'Here we go' > README
user@host:~$ git add .
user@host:~$ git commit
user@host:~$ git push

Pull changes

(someone else pushes some stuff into your repository)
user@host:~$ git pull

Start ssh-agent

user@host:~$ eval `ssh-agent`
user@host:~$ ssh-add

I thought I should mention something about this awesome wordpress theme that seems to now work only on firefox. Why you can’t ‘telnet’ to other people’s blogs on other themes i’ll never understand.

It was originally written by Rod McFarland and hosted on google code but has recently been taken over by fogus and moved to github. There’s a very low volume email list on google groups. The general direction of the new improved cli is not yet clear.

Apart from the fact that it doesn’t work on many browsers (not sure if it’s just my installation but firefox 3 seems to be the only browser that allows the keyboard events to be correctly captured) and when it does work it makes leaving comments somewhat confusing, I think it is a marvelous invention. It predates goosh by a several years. I’m hoping that this is going to be a common feature of web 2.0+ as i’m fairly sick of needing to use the mouse to interact with web content.

Perhaps it just serves my unique purpose in acting as necessary discouragement from reading any further into the inanity that is my blog.

This is the first in a series of howto articles explaining how to do things that you should never under any circumstances want to do.

So the gmail web interface is a pretty straightforward usable interface for reading email.  It neatly threads conversations together and has fairly simple vim like key shortcuts for navigating email.

Notes on the other hand is the least convenient mail client ever devised: it has a completely incomprehensible menu system and is very difficult to use to do anything using only the keyboard.  On a mac, the default fonts are so small that no human being can read email at all (there’s a surprisingly elaborate fix for this that i might describe some other time).

So you might find yourself asking: how can i bring the unusability and inconvenience of lotus notes to reading my gmail mail?

The answer is to use IMAP:

In gmail, click ‘Settings’ > ‘Forwarding and POP/IMAP’ and ensure the ‘IMAP is enabled’ radio button is selected.  Now in notes, go to ‘Address Book’ > ‘Advanced’ > ‘Accounts’ > ‘New’ > ‘Account’.  The account name can be whatever you want (notes will create a database with this name). The account server should be ‘imap.gmail.com’.  The login name will be your full gmail email address.  The password will obviously be your gmail password.  Make sure the protocol is ‘IMAP online’ and that the port (in the advanced tab) is 993.

Voila, all the functionality you scarcely understand and despise to read your gmail.

Oh and by the way: you can cut and paste email between notes and gmail with the limitation that encrypted notes email will not be readable in gmail (and won’t be readable if you move it back).