Learning on the job

There's nothing like actually doing something to make you realise that #yerdoingitwrong.

I've recently been kicking about a small Ruby console app that will merge the contents of two directory structures. I've been doing this for two reasons: -

1. I want to sync the music folder on my network with the one on my MacBook.*
2. I want a sandbox app that I can use to learn RSpec, Cucumber and various other technologies.**

So, why am I telling you all this? Well, I learned an important lesson today and I thought I would share it because it bears repeating.

ALWAYS DESIGN EACH OF YOUR APPS FROM SCRATCH! Don't start a project by nicking the design from a previous one. There will be differences, many of them subtle, that will mean that sooner or later (likely later) you will realise that the two apps are actually different and that a redesign is in order.

The sandbox app I'm building just now seemed to be similar enough to the Codebreaker app in The RSpec book for me to nick at least the bin file from it as a starting point. Wrong! Obviously there is very little an app designed to let you guess a secret code has in common with an app to synchronise two directory trees. Even the part that I thought they had in common, the means of running and accepting commands from the user, is clearly different as soon as you chuck the first couple of use cases at it. I had assumed the model to be used for user interaction would be for them to call the program passing in the source directory and the destination directory. They could thereafter type commands at the given prompt to view the differences between the directories, sync them or exit the program. But this is not intuitive. Nor does it fit the Unix paradigm where I would be running the program most often (and where any others downloading it would most likely be running it as well). So I'm going to have to do a redesign so that the program is run from the shell prompt, passing in a switch to dictate the use (i.e. -d to see the diff, -s to sync), as well as the directories.

However, before I do that, I'm going to map out the use cases on the whiteboard to make sure I'm happy with them first!

* Yes, I know that there are already multiple apps out there that can do this for me (and the vast majority will be better than mine no doubt), but I want a sandbox app and this fits the bill nicely.

** Yes, I am aware that a shell script will probably be faster, however it's Ruby that I want to play about in and not shell script. Besides, I may well want to run this on my Windows machine as well (although it's dual boot so all file ops could be done in the Linux kernel instead).

Getting over commitment issues

Since I left Uni back in the summer I've been promising that I was going to start releasing the code I was working on. By committing it to GitHub I could start sharing with others and learning from them. Well, I have a confession to make ... I have commitment issues. I've been worrying so much about making a good impression with my first commits that I've not made them yet.

I'm an idiot. No code that I release right now is going to set the world on fire (even if I polish it for the next six months). The whole point of releasing my code into the wild is that others can take a look at it and make comments, improve it and show me the stuff that they are working on. Only then will I start learning properly.

In fact, I was recently speaking to a coder (whose coding skills I greatly respect) about a previous project that he had created, and one which is pretty much the community norm in its field now. One of the first things he said when I mentioned I was going through the rdocs for the project was, "Don't look at the code!" Even he was worried about code that he'd written a couple of years ago. The way I see it now though, is that you will almost always look at code that you wrote 6 months, a year or even longer ago and find things to improve. If you don't, then you're not learning and you're not improving.

Then, this morning I read this blog post by John Nunemaker and I recognised the situation I was in. So, I'm going to do the same with my GitHub account as I have with my blog. I'm going to start anew. I have a project that I've started working on as a follow up to the first section of The RSpec Book. It's nothing impressive and it definitely won't be a trending topic on Twitter anytime soon, but it's a start. Tonight I will commit it to GitHub. It will be the baseline that I will measure all future coding endeavors against. Yes, it sucks and yes, I could do better ... and I will.

But not before taking that first step of actually committing it.

Coming soon!

I've changed my blog over from the one I developed in Rails all those years ago to a Blogger-hosted one instead.

Why?

Well the first reason is that I was spending more time actually developing and maintaining the blog code (adding extensions, parapets and ramparts essentially) than I was actually writing anything down. Secondly, what I was writing down wasn't worth reading (a mixture of my Uni Honours project log and the occasional rant).

As such, I've decided to start again from scratch. There are two articles currently in the pipeline, one of which should be finished this week and the other the following.

You never know, this one might actually be read be other people from time to time!