Archive for April, 2007

It’s All About Having the Right Tools

Sunday, April 29th, 2007

I’ve been doing a lot of DIY lately, after we had some building work done. Painting walls, laying new flooring, putting on new skirting boards, putting up new blinds and curtain rails. I’m not very practical, so my Father-in-Law is usually drafted in to help. One thing has become abundantly clear.

It’s all about having the right tools.

About 6 years ago when we moved into this house we turned the old owner’s kids bedroom into a grown up guest room. In the process we put coving up. This involves cutting stuff at 45 degree angles to make corners. When we did the coving, we used a Coving Mitre:

Coving Mitre

This is an odd shaped bit of plastic which can be layed at various positions on the coving to guide a hand-saw into cutting the right angle. It’s fiddly, and a pain in the ass to be honest. And because you are hand-sawing it’s hard work, and you can’t just nibble a couple of millimetres off. It was a long hard job.

A year or so later, when we put up some Dado Rail in another room my Father-in-Law had bought a Mitre Saw:

Mitre Saw

This makes it a lot easier to keep the saw in the right position and cut the angles. It clamps the wood in place. It made the job much faster. But it’s still impossible to cut a couple of Millimetres off a slightly too long piece of dado.

Last week, we put up skirting boards. Now my Father-in-Law has bought a Power Mitre Saw:

Power Mitre Saw

With this bitch you can do anything. It’s trivial to cut any angle in anything. You can trim a millimetre off the end of a bit of skirting in a second. It makes the job faster and easier.

When we were laying the flooring. My Father-in-Law cracked out his jigsaw and a Square (thing for getting right angles dead straight). Tools I don’t have, I’d have struggled with a big handsaw, a hacksaw and a steel ruler. And it would have taken ages and been crap.

It’s all about having the right tools.

Since this experience, I’ve decided. There is no point in doing a DIY chore without the right tools. And it’s no use going for the cheap-o option (the Coving Mitre) I need to get something decent. The Manual Mitre Saw would have been the best option, balance of cost and utility.

I’ve bought a cordless drill with a set of drill bits and screwdriver bits. I’ve bought a spirit level. I’ve bought a hacksaw and numerous other tools I’ve been doing without. The DIY I’ve been doing since has been much much more productive. I had to assemble some flatpack furniture yesterday. Normally a chore that takes hours and leaves me with hands sore from the screwing in of a million screws.

Yesterday, I used my cordless power drill and a couple of screw driver packs and had everything together in no time at all. Today, I put the curtains and blinds back up. Screwing them in took seconds, and I used the big spirit level with the built in ruler to make sure they’re level and centred on the window. And it took much less time than the blind I put up in our bedroom a couple of years ago, which wasn’t straight.

I still have to get my Father-in-Law round to do something if I’ve not done it before, and to show me what the right tools for the job are. But, my DIY is light years ahead of where it was 6 years ago.

It’s all about the having the right tools and knowing when to use which tool.

This isn’t just true of DIY. Take photography. When it comes to taking pictures of small children, you need the right camera. I’ve got an old 4 megapixel Nikon Coolpix 4300 at the moment. I bought it before my kids were born, and used to take pictures of landscapes on holiday, or us by the pool on holiday. Great camera, lots of control over what it does.

But it’s useless for taking pictures of kids. They don’t stay still looking cute for more than 2 seconds at a time, and the shutterlag on the Coolpix is about 3-4 seconds with a 10 second minimum delay between taking shots. It’s a useless tool for taking pictures of little kids.

It’s not just true of photography and DIY, it’s true of software engineering. Sure, you could write a full blown replacement for Microsoft Office using a command line compiler and notepad. But it would take orders of magnitude more effort than doing so using a rich IDE, powerful debugging tools and suites of standard components.

I know that I’ve said that coding is not like building a house. But, there are things they do share in common, such as the impact of trying to do a quality job in a decent time with the wrong tools.

It’s important that as a programmer, you have the right tools and you use them for the right job. Make sure that you are using the best programming editor for your language, if you aren’t, get the best or as near it as your budget will go. Make sure you have a debugger, profiler, lint tool, test tool. Make sure you have all the tools, and make sure you know how to use them. If you do, you’ll soon be producing better software faster.

If you aren’t, it’s not the right tool, or you’re not using it at the right stage.

Popularity: 16% [?]

Portable Development - Apache

Saturday, April 28th, 2007

Of course, the first part of your AMP instance to get working is the Apache part. A is the first letter of the alphabet, and you need Apache working before you can introduce PHP. And you may as well have AP working before trying to get MySQL working, since MySQL is there for your PHP application to talk to.

The problem I found with Apache was finding a reliable, trustworthy build of Apache for Windows in a non-installer format. I gave up in the end and grabbed the latest stable release of the 2.0.x line for Windows from the Apache downloads site here. You then have to run the installer and install it on a spare windows machine.

Once you have installed it, grab the contents of your install folder (Typically c:\program files\Apache Group\Apache\ or similar) and stick it into a folder on your USB Key. I went for \development\apache containing the contents of my Apache folder.

Once you’ve done this, you need to make some changes to your httpd.conf file. This can be found in the apache\config folder. Edit it in any text editor.

The main complication of using a USB key is that when you stick it in one PC, it will likely have a different drive letter assigned to it when you stick it in another PC. So, we need to make sure all paths are relative.

Now, firepages specifies using \\pdrive\\apache, I found this didn’t work. I used /development/apache/ and this worked fine. In fact, in all places I used Unix style path separators over Windows style path separators. And it all just worked.

In my httpd.conf I specified a number of virtual directories for each application I was working on, I’ll come to them when we first set up a test environment for evaluating software libraries. However, I followed Firepages example and set up a /development/applications/www directory for the server root. In there I maintain an index.html that lists all the things I have to access and works as a start page for me.

The other vital step, is to change the Listen directive to make Apache run on an obscure port. Because the machine you’re using might already have Apache or IIS running on port 80. I usually go for 8080.

Listen 8080

So, once we have Apache copied to our USB key, replaced all the absolute paths with relative Unix style paths to the USB key folders, changed the port Apache will run on and dropped a test index.html into the /development/applications/www folder, we can uninstall Apache from the host machine and leave it clean again.

Now we need to start Apache. I created a temporary start.bat that contained some basic stuff to do this:

/development/apache/bin/apache.exe

Once we run that up, we should have an Apache instance on port 8080. Just point a web browser at it. Congratulations, it’s a little baby portable Apache!

Popularity: 13% [?]

Portable Development In Anger

Saturday, April 21st, 2007

It doesn’t matter what you are doing, whether that is managing a web site that you run using an application such as Wordpress or writing your own application from scratch. You need a development environment. To run this site, I have my main webhosting with an installation of Wordpress. My Wordpress installation has a custom theme and I’ve installed a selection of plugins to get the functionality I require.

I did not prepare this work on my live webserver.

Since I set this site live, with Wordpress 2.0.5, two security releases (2.0.6 and 2.0.7) were released. Then Wordpress 2.1 was released, followed by three security updates. My site has now run six versions of code, it’s fully up to 2.1.3 (2.1.1 was compromised on the Wordpress site before I downloaded it and they advanced to 2.1.2 to avoid confusion).

But, when I did the upgrade work, I didn’t do it on the live site.

Once you have a site live with some software, you need to perform the upgrade on a copy of that site and refine the process so that when you do come to take your site down for the upgrade process it is a simple exercise that results in your site being live once more as soon as possible. Not leaving your blog down for days.

When you’re working on software, you want full control of the environment so you can debug and experiment to identify what the problems you are having are. You have to have a development environment.

Now, most web hosting is LAMP. Linux, Apache, MySQL and PHP. For things like Wordpress, Geeklog and the majority of web development, LAMP is the most available and most used platform. How do you go about having a LAMP environment to develop on? I would strongly suggest that you don’t want to use any hosting provider as your development environment. You may want a staging host, a subdomain that you perform the upgrade on before copying to your live environment. But the trial and error troubleshooting and testing phase should be on your Development Environment.

Now, if you’re not the kind of person who has a Linux box to hand that they can use for this, fear not, Apache runs anywhere, as does PHP and MySQL. You could install them on your Windows Vista/XP/2000/98/95 box (or even your Mac) and have an environment there. There are even bundled installers that give you the AMP portion all running in a few mouse-clicks.

But, I don’t use one machine. I have two laptops at home, and I could be on either, depending on what else I need to do and whether or not my wife wants to play games. I have a machine at work that I don’t want to have a copy of my development environment permanently set up on, and I don’t want the headache of keeping three environments in synch.

So, I had a bit of a Google to try and find a solution for a portable development environment. I’ve seen portableapps.com’s [1] available end user software and started looking for options for AMP development that can be extended to include Python, Ruby and other languages. I found a good article at firepages that was my starting point.

Since I first created my portable environment, portableapps.com released a portable XAMPP which would have saved me the effort. If you just need an AMP instance, I would investigate that. However; I want to understand my environment, know how it hangs together, feel confident playing with it and be installing Ruby and so forth. It’s also far more interesting to me, to build my own. Sad, but true.

I’m going to write a few articles on getting your AMP instance set up on your USB key, as I’ll need that environment to talk about evaluating software libraries and starting development. So this is going to briefly interrupt the flow of the Multiblog articles.

I decided on a simple structure for me USB key, I have a development folder in the root. This contains an Apache folder, a PHP folder, a MySQL folder and an Applications folder. Also in the root I have a Tools folder, containing installers for tools I use all the time, and a Downloads folder where I place the tar balls of things like Wordpress when I download them.

I then set out to start installing.

Popularity: 14% [?]

Choosing a Language is Choosing a Platform

Tuesday, April 17th, 2007

I’ve already posted an article about choosing a platform for your development. I missed a very important point, when choosing a language to develop in you also buy into the platform available to you, in this context, this means the third party libraries and supporting frameworks available to you. And as Jeff Atwood points out:

When you choose a language, like it or not, you’ve chosen a platform. And as Steve so patiently and calmly explained to all the Lisp enthusiasts, the platform around the language, more than the language itself, sets the tone for your development experience. The availability of common, popular libraries and the maturity of the development environment end up trumping any particular significance the language holds.

This was something I was planning to move on to talk about in more detail later. When you pick a language, you do need to look around at the choices of libraries available to you. PHP is lucky. It’s mature. There are a lot of libraries out there.

But, you must be very careful when confronted by such choice. Take a look at the options available for templating. Pear (a major source of libraries) have several implementations. There’s Smarty, and numerous other “just templating” libraries. The new Zend Framework also has a templating implementation.

There is a lot to choose from. Making the choice to go Pear::Flexy because that fits in with your use of Pear::DB, or to make use of the entire Zend Framework might be completely the wrong thing to do. You might want to create your own lightweight abstraction. Or go for something like SimpleT.

Picking a language with a small platform footprint can actually be better than picking a language with a large platform footprint.

But I’ll be talking about the costs associated with blindly using a library from the “PHP platform” for every project. When all you have is a hammer, everything looks like a nail. If you only have one type of hammer, that’s not worse than having a whole basket of different hammers.

Popularity: 28% [?]

Software Design Approach

Saturday, April 14th, 2007

So I’ve decided on a platform for development. PHP/Apache/MySQL. Next we need to think a little bit about how we’re going to build this thing.

Right now, downstairs, I have a builder working on a new extension to my living room and a carpenter fitting a new kitchen. I don’t want to trivialise the problems and issues they face, but, the building industry is thousands of years old. Materials and techniques do change. But not that much. Lighter stronger materials. But, a brick is a brick. And it takes a certain amount of time to build a wall out of them. And the calculations required to ensure it meets requirements are well known and understood.

There is always the uncertainty of weather, and suprises like (random attempt to appear to know something about building…) dryrot to deal with. But generally, there aren’t that many suprises and new challenges in building. You do have some aspects of interpretting the customer’s desires, but, blueprints, 3d modelling of what’s being planned in the kitchen sort all that stuff out with a pretty exact level of detail.

Software specification, design and development on the other hand is another thing entirely.

Software is not a science, it’s not even really engineering. Software has been likened to a collaborative sport. I quite like this article I read recently where one parallel drawn is that software development is like rock climbing. This rang very true for me, as I’m a software developer and ex-rock climber.

Techniques and methods are changing all the time, we still haven’t managed to reach the point where we have such a set of tools, techniques and materials that we can get a bunch of people to go through an apprenticship in purely practical things and follow a basic recipie to turn out a repeatable delivery on time of a finished product, like we can with building (troublesome builders who run over, turn up late etc asside).

Software development (commercial, enterprise grade) takes highly skilled and educated people to deliver the mess we currently deliver. We’re far behind the building industry, which is delivered by (sorry, but it is) the less bright, less able, less educated people in society. Becuase they can! Becuase those of us with degrees in software engineering are crap at it and are too busy being crap at writing software. But crap in that certain special way.

Anyway, opinionated rant asside, things are getting better. We’re starting to establish some common, re-useable techniques to get software delivered better. There are a whole bunch of generic approaches to development, each one with a myriad of different interpretations.

I’m going to talk about Object Oriented software development, because, in my opinion that is the best approach.

The basic concepts of Object Oriented software design and development are covered well in a number of places. My general preference as the font of all knowledge is usually Wikipedia, and as it’s a software topic, they give Object Orientation a pretty good coverage.

Basically though, in object oriented software, everything is should be an “object”. And by that we mean the literal term for an object, in the sense of the fact a car is an object. That object should wrap up all the attributes of that object, such as it’s colour, and all the things you can do to it, such as start the engine.

In procedural programming, you would have a whole bunch of unrelated variables, such as $carColour and routines such as function startCarEngine() that lived somewhere in that spagetti of code you call a system. Object Orientation keeps things clean and tidy. You have your Car class, and you have a variable $myCar that represents a specific car. You can find out what colour that car is ($myCar->Colour) and you can start it ($myCar->StartEngine()) without worrying about the mess of variables.

But that’s just the start. What if you have different types of car. Old fashioned cars needed a crank handle to start them. But they still had wheels, tyres and so forth. In the procedural world, we’d have effectively duplicated code for old fashioned car starting and new modern car starting. The difference to the user is turning the key, or cranking the handle. But internally, much of the implementation may be the same (pump fuel, fire spark plugs etc).

That’s where object orientation gets useful. Objects can be built of other objects. This is called inheritance. Basically, you define a basic car class that defines all the features common to all cars. Then from that you inherit all that code, and extend it or replace it to provide an implementation of a type of car. Such as a Crank Handle Car or a Modern Car. From that you can inherit down and down until you have a class that defines a Ford Mondeo 1.8 Deisel, because it has details that are different to the Ford Mondeo 1.8i Petrol.

Indeed, your base car class, could have inherited common properties from the Vehical class. In some implementations of object orientation you can inherit multiple things. So it may have inherited “Internal Combustion”, “Wheeled Transport” and several other base classes.

You code once, and use or extend that code in many other places.

This is important, because it means you fix a root bug once and fix it everywhere.

OO is important for Multiblog, because Multiblog needs to post to many different web services. But, each web service will have certain things in common. At the very least, I’ll need the ability to make an HTTP POST operation to a URL. If I write my blog service implementations as classes, I can derive common functionality from a BlogService base class.

Furthermore, with Object Orientation there is a rich collection of Design Patterns. These are as close as software engineering gets to fixed, repeatable recipies for development. They give us ways to do things.

The typical object oriented patterns make it really simple to layout and engineer your software in such a way it will be easy to change, expand and manage your development. We’ll see that in action later on (I hope!)

Popularity: 13% [?]

Choosing a Platform

Saturday, April 7th, 2007

The first step for me in starting to design and plan for the development of the new Multiblog web product is to decide what platform. To be honest, this is a pretty trivial decision for me. But, lets discuss why I’ve made the choices.

Firstly, what do I mean by platform? Multiblog the first application runs on the “Windows” platform. That’s it’s target platform, but I’m not talking about that kind of platform. I’m talking about a web application, by default the client platform is any browser any operating system. Developers for an application had better have a good reason for narrowing that down, or they are losing customers.

When we talk about the platform for a web application we’re really talking about the server side. What kind of operating system? What Web Server on that operating system? What database server? What language to develop in?

Several things will impact on this decision. What the application needs to do, how it needs to do it, where it needs to do it, when it needs to do it and budget. There are languages with particular strenghs in the what and how market. For example, for a basic data in, data out application, Ruby on Rails would be hard to beat with it’s instant building of simple forms for managing data. For an application targetted at the enterprise market, Ruby’s an unlikely choice due to it’s lack of maturity and commercial support. Java, .NET, SQL Server and Oracle occupy that space.

There’s a lot of impacts. But, I’m going to go with Apache as the host web server, PHP as the development language and MySQL as the database. Why?

Simple. This is a startup niche product. Budget is critical. I can find PHP, Apache and MySQL hosting pretty much anywhere for hadly any money. This is a platform that can scale. I know how to set it up and manage it. If this does take off, I can easily migrate up and up with that base platform.

So the initial cost is zero. Everything is free, and I can develop on my laptop at home. Or any computer anywhere, since my Apache, MySQL and PHP environment can be mounted on a USB key and wacked into any Windows box and worked on with notepad. I’ll be able to find a good cheap host to start with and swiftly migrate and scale up as and when needed.

PHP is a mature web development language, and I’m very familiar with it. So, barriers to getting things done are pretty low. I also want to pick a language that is going to be of most interest as an example. There are lots of hobbiests working in PHP. Lots of professionals too. If this is to be an example of a professional approach to web development, the barrier of entry for the audience should be low. I’d still like to follow up wtih an attempt in Python and one in Ruby for reference and comparisson, but that will have to come much, much later.

Obvious and easy choice made…

However, which version of PHP should I target? PHP4 is ubiquitous. PHP5 provides some very nice features.

Well, for reasons I hope will become clear down the line, as I explain them, I want to write an Object Oriented system. So, given that PHP4’s OO options are limited and frustrating I’m jumping in on the much less supported (in terms of available, cheap, good hosts) PHP5.

Why Apache? Why not IIS? Frankly, PHP is mostly used in Apache. It works best there. it works in other places but not as easily and readily. I like IIS as a platform. I work with it in my day job. But for a PHP project, it’s not a good choice.

Popularity: 9% [?]