Marc Benton in his new blog has written a good write up on the spec of the £100/$200 laptop offered by the “One Laptop Per Child” charity - the XO laptop. Saw this on News Night last night and was impressed that they could get a laptop that cheap. Marc’s post describes the specs and explains how they kept costs down. Nice work Marc.
As many of you know I’m doing a part time degree course (Politics, Philosophy and History) as well as being a self employerd web developer. One of the best things about this course is that I can go to extra lectures which complement the course. A couple of weeks ago I had the pleasure of going to one of these extra lectures, “The Philosophy of Wine Tasting” by Barry Smith. I must say, it was fantastic. I’ve never really thought about wine tasting before but this lecture was so interesting and Barry was so passionate and eloquent about his subject, I ended up wanting to buy a vineyard.
Incidentally, Barry has just brought out a new book, which you can get from Amazon (I have, perfect Christmas present for my Dad!)
During the lecture Barry took us through the journey of a wine tasting, contrasting the difference between a novice (like me) and an expert. A novice finds a nice bottle of wine, likes it – it works for them – and that’s kind of it, thinks that all this “it smells of blueberry leaves” is a load of crap. Whereas the expert goes beyond their personal preference and analyses the multitude of components the wine has. The grape, the age, the weather, the process, even the earth, the people and history that all go into making the wine what it is. This started me thinking. Now, I’m a bit of a geek and pretty addicted to my job of coding. And I began thinking:
Now run with me on this one.
When you first start, you’re a novice. You’re looking around for what you like, and when it works, you’re pretty pleased with yourself (at least, I was/am). But there is no background to it.
When I first started programming, I was one of those copy/paste kids that wasn’t quite sure why it worked, but it did, and I was pretty pleased with myself. This is like most people. They have no idea how or why Google works, or Word, or email, it just does. At the same time, people aren’t quite sure why they like a nice bottle of Jacobs Creek, any concept of what’s gone behind it, the effort put in.
But then people start to get more interested, start asking how it works, or why it tastes like it does. Then they get hooked. At this stage most people really go for it. They buy countless books, they read hundreds of articles, but most of all, they start to try out lots of new things. First they start with the foundation, either the language: Ruby, Java, PHP, C#, or the grape: Chardonnay, Cabernet Sauvignon, Pinot Gris and Noir. Each of these have different philosophies, concepts - call it methodologies, behind them. Dabble in these, test them out, see what works for them, try them out for size, for example OOP or “under ripening the grape”.
By now, an appreciation is being formed. Irrelevant of whether you like it or not, you can distance yourself from the actual “flavour”, but instead focus on the inner working of the code, or the wine. You can come to appreciate a well made wine, or well structured code. But also you can come to appreciate the history gone into producing the product in front of you. The age of the vine, the good summer it had a decade ago, or the frost suffered last year, the problems faced by people using the language, the particular itches that had to be scratched, experiences gained from other projects. Once you’ve truly immersed yourself for a few years you can come to appreciate the nuances, the culture, for want of a better word, the soul of a language or of a wine.
At this point, go for it, taste everything, try everything, become an expert. Know the most obscure syntax or date and time functions, know that if you have a cheap bottle of bubbly you can make it taste like the most expensive champagne you’ve ever tasted by complementing it with a little slice of Parmesan cheese on the side. There is so much out there to find out, to sample and to learn.
I have to admit, I love it. I love wine and I love programming. But the most important thought that struck me during this lecture was this: both the best wine in the world and the best programming most likely originate from the garage or shed of someone who is truly passionate about what they are doing.
Browsing about the internet this weekend, and came across an Analog Binary Clock by Michael Battle on the rather brilliantly named domain: footloosemoose.com. Flicking through his other articles, it looks like a good blog to follow.
A great article has been posted on the Agile FAQs blog. It is a list of 11 myths of Agile Development, and why they are wrong. If you’re into agile development at all, I’d recommend a read.
If you’re a web developer like me, but don’t have access to all the different operating systems and browsers, check out browsershots.org, I’m testing it out now to see what my blog looks like, so hopefully by the end of this article, it’ll be done. Free too, which is nice.
Patrick (of Bingo Card Creator fame) has just posted a new article on his Blog, about exploiting new niches for SEO. I’m an avid reader of Patrick’s blog, and neat little posts like this are the reason why.
And finally, web2Project is nearing release. As a user of dotProject many moons ago, before the development temporarily stopped, I’m looking forward to the inaugural release of a brand spanking new project management system, built on top of the dotProject framework. As many of you know, I use Timersheet.php, but am thinking of taking on the development as the project seems to have died. Lets see if web2Project has all the features I need, yet be simple enough to use.
Some screenshots have been uploaded of my blog by browsershots.org….wow! what a great service. I recommend using this 100% (even though my blog does look rubbish!!)
Found this article whilst browsing Digg. Being self-employed it’s quite interesting to read other’s opinions. The discussion is good to read too.
I follow a guy called Noel Perlas on Twitter, and he’s just posted a tweet about how he’s giving away a Moleskin 2008 planner. You can read about it on his blog here:
http://noelperlas.com/2007/11/19/im-giving-away-a-moleskine-planner/
This is a brilliant idea! Like Noel, I and many others (girlfriend included, hint hint, help me out with this one Noel!!) love these things.
Why is this such a good idea?
Whilst this may be a clever marketing ploy, is isn’t out of the blue. Noel seems to have a strange attraction to notebooks. In fact he’s raved about them before, which, in my mind, makes this idea even better.
Well done Noel, keep it up!
I have been using an open source project called Timesheet.php for a number of months now and am finding it very useful for tracking the time I work on projects - and as a result helping me get more organised.
From the Freshmeat project page:
Timesheet.php is a Web-based application designed to keep track of the hours worked by multiple people on multiple projects. It allows users to log in and manage the times that they are clocked on or clocked off. It has many features, including user, client, project, and task management; a calendar view of work, grouped by project or all projects; monthly, weekly, or daily views of work; work periods spanning multiple days; automatic calculation of invoices; manual clock-on/clock-off maintenance; administrator views and reporting; timezone adjustment; a simple weekly timesheet entry mode; and LDAP support.
However, I’ve had a good look on the internet to see if this project is still being maintained, but it appears development has ground to a halt.
As said, I’m finding it a pretty useful app and would really like to see development continue. I’ve been trying to contact the admins of the project to see how to get involved, but as yet with no luck. Following some conversations with existing users of the project, I have decided to fork Timesheet.php and actively develop it. I have chosen to fork the project instead of taking it over as time won’t have to be wasted trying to chasing all the instances of this project on different sites (e.g. code.google, Ohloh etc).
So now a little help is needed. The first thing needed if this project is going to be forked is a new name. My suggestion of “Timesheet.php 2″ is a bit rubbish, so if anyone can come up with a better name, please post a comment on this blog, or reply to to the thread I’ve started at Sourceforge. Also, if you want to get involved with the fork, please drop me a line - message me through Sourceforge, comment on this post, or post a reply at Sourceforge.
Due to work commitments at my end, I can’t see anything major happening until early next year, but hopefully by then, the new project will have a name!
Subscribe to my RSS feed to keep up-to-date about further developments!
Can I just say a big thanks to Gergor K of Phex for helping me out and offering his thoughts and advice. Thanks Gregor
Wow! Whist an avid user of Joe’s Goals, I’m not subscribed to the blog, but when ticking off stuff I’d done today, I noticed that he’s reached 1.5 million checks! Wow, well Ian! (aka Joe’s Goals)
Going to be a work filled weekend, but before I whack on a bit of Goa-Psy Trance at Digitally Imported, and settle down to some coding, I thought I’d have a quick browse around the interweb.
First up for you is a great post By Joel Spolsky from Joel on Software, his latest post following on from his FogBugz world tour: How to demo software
A good read, some nice pictures of Cambridge and London and a great bit of advice: story telling.
The only interesting way to design a demo is to make it a story. You have a protagonist, and the protagonist has a problem, and they use the software, and they… almost solve the problem, but not quite, and then everybody is in suspense, while you tell them some boring stuff that doesn’t fit anywhere else, but they’re still listening raptly because they’re waiting to hear the resolution to the suspenseful story, and then (ah!) you solve the protagonists last problem, and all is well. There is a reason people have been sitting around telling stories around campfires for the last million years or so: people like stories.
The world seems to be going OpenSocial mad at the minute, so need to look into it further, found some sites which I still need to browse
Some Micros ISV blog posts to read when I get a chance.
I like these guys and avid fan of their blogs. If you are a one man band and develop software I strongly recommend reading their blogs.
Also, found a nice little post from Nick at the BreezeTree Software
As a self-employed web developer I’ve had numerous experiences over the years outsourcing work to other providers. This is the option I turn to when a relatively “simple” clearly defined project comes in that I’m either too busy to take on myself, or I don’t want to be distracted from a larger, more complex project. I have also hired a number of single outsource developers to work as a “team member” where we both work on the same project together and tackle things in a much more fluid way. Like most experiences, sometimes it’s worked, and other times it hasn’t, also some of the providers have been great, some have been simply awful. This post is about what I have learned from experience.
The number one most important tip I can offer is that you must have a good line of communication with the provider. If you are outsourcing a single project, make sure that it is as fully spec’d as possible, with clearly defined goals and timescales. Also, make sure the provider agrees to the spec and that they fully understand what is entailed. If you are working on a more fluid, lengthier project you must stay in touch with the provider as much as possible. Obviously if you are working in different time zones I’m not suggesting that you should switch to using their clock, but the provider needs to know when you will be on line, how they can contact you if there is a problem/question etc. Instant messaging, email, Skype and wikis are all valid means of communication, each with a specific job, and I strongly suggest that you use as many of these lines of communication as you feel comfortable with, or that the project entails.
This relates heavily to point 1, but it is absolutely imperative that you have a clearly stated outcome you are working towards, including expected timescales or date of completion. I have found if there aren’t clearly defined expected outcomes, regardless of whether it is a single project, or a “team member” type scenario, the provider doesn’t have anything to aim at. If there is no outcome to aim for none of the functionality will ever get properly written. And, if there is no timescale agreed, there is no urgency to get anything done!
As well as having good communication with clearly defined expected outcomes I have found it is imperative to have a clearly defined methodology. This may be as simple as “please email me at the end of the day with a progress report” or be as complex as instructing the provider to always use your online collaboration suite and submitting to the Version Control System for the nightly build. Which methodology you choose to use really depends on how mission critical your project is. Whatever methodology you do use, it is important to define this from day one, as it is very easy to get into a habit, but impossibly hard to break one.
This is linking in a little bit with point 3. It’s necessary to have good tools with which to implement your chosen methodology. It is also important (critical in fact) that your provider knows how to utilise the tools. One (very irritating) time I noticed that a provider I had just hired promised that he knew all about Subversion, but was downloading, file by file, the entire code base from the browser, and not with an SVN client like TortoiseSVN. Needless to say, he didn’t last long.
These tools should include, in my opinion, at a minimum a version control system and bug tracking software. I am a big fan of Trac but I don’t know if that is just me coming from an Open Source mentality. Also, as I think it is brilliant, I recommend Mantis as a bug tracker if you don’t want to get as complicated as Trac or BugZilla. Damn, that means I also must mention FogBugz, but enough – on to point 5.
This isn’t just about being polite, which of course is an absolute must, but is really about trusting your provider to be able to actually work on your project without you having to hold their hand and check up on them every 5 minutes. Yes you should always be there if they need help or have a question, after all they aren’t as up-to-speed on your project as you are in the beginning. However, trusting your provider and treating them with a little programming respect will not be as hard if you heed point 6.
One of my first mistakes when outsourcing work was to just hire the first provider that came along and said they could do the job. Every provider I have since found out says they can do the job, but it really depends how well you want the job done. The more providers I used, the more I realised that getting a provider is really like finding someone to employ. You want to get the right person for the job. Also, a big mistake I made was thinking that a bigger price equals a better provider; this is not always the case. So when you are looking for a provider, ask to look at some example work and some of the code that makes it work. Maybe even give them a little test. You want to make sure you get the right provider after all…
This might seem a stupid point, obviously it’s your money (it may be your client’s money eventually, but you will still have to pay for it first). As it is your money, if you feel unhappy, or are not confident the provider can do what they said they can do, or complete the project, don’t waste your money and your time. There are a hell of a lot of providers out there, you can find someone you are confident with and who can complete the project. When I first started using outsourcers I was often too nice, I helped them out and was very communicative, all good. However, with some of them I realised I was doing more explaining and helping out than the provider was coding. I had to keep on referring them to the coding standards I wanted them to adhere to, or the function spec I had written for them. After a while I twigged that this was costing me money. If the provider cannot do what you are asking, find someone who can. Nevertheless, saying that, if you find a provider that keeps getting it right, doing what you are asking and in the timeframes you’ve requested – hang on to them, they will help your business invaluably!
Yesterday I wrote about whether I should rewrite or refactor a website I have now taken over. As this website is the lively hood of my client, and because I have fallen into the trap or rewriting before, I have decided instead to refactor the code piece by piece as and when I encounter it.
I’ve had a further scoot around the web for some different opinions (or matching ones) and came across quite an interesting, if slightly old (2005 - positively ancient! 
) article by a guy called Marcus Whitney: Refactor vs Rewrite. Something that struck true with me was:
and immediately began ranting about how the code was crap and needed to be replaced. Well… that attitude is pretty much crap. Obviously the code did SOMETHING for the client prior to my arrival.
I absolutely agree, and this goes along with my conclusion of my earlier post: One of the main reasons I started the rewrite was my pride - I could do better than that, but I was really missing out on the bigger picture: that site is my client’s livelyhood.
Anyway, thanks for the post Marcus, spot on.
