Ok, so we’ve briefly discussed the importance of figuring out what your software should do, so what will my software do? What I need to do is sit down and write out what the software will do, and review that from an experienced developer stand point and figure out where I’ve not been precise enough. Let’s start with this (based on what MultiBlog the desktop app can do):

MultiBlog will allow users to register an account. Within that account they will be able to configure multiple remote blog accounts. They will then be able to write blog entries and cross post this to multiple blogs within multiple blog accounts.

That’s great. But that’s very high level, clearly that needs some expansion. What details are needed to register an account? What makes up a remote blog account? How do they write entries? How do they cross post the entry? It will serve as a statement of intent, but it’s light years away from a specification. I’m going to take one aspect of this and expand it as a worked example, that will be the writing of entries.

MultiBlog will allow a logged in user to write blog entries within a browser-based WYSIWG editor with the option to edit the raw mark-up of the entry. The software will support drafting of entries.

An initial screen will list all current, unposted draft entries the user has been composing. The user will be able to select a draft to continue editing, or to create a new draft. Upon selecting one of these options, the user will be presented with an editor screen.

The editor screen will contain controls to capture:

• Post title
• Post body
• Post tags
• Current Mood
• Current Music
• Post date and time

The editor will autosave drafts every 5 minutes, and allow for manual saving of drafts.

In addition, in a future release, the editor screen will integrate to external web services to insert content, for example, product information for Amazon content or Flickr images. This will allow easy blogging about films, books and photos taken etc. However, this will not be implemented for MultiBlog Online 1.0.

This is better. There is much more detail. However, there are still blank areas, what exactly will the WYSIWG editor do? What are it’s features? This is something I won’t expand as I’m just going to go with one of the leading open source, browser based WYSIWYG editors for HTML, after evaluating them against the other requirements in this area. One of these is of particular interest for several reasons. The final paragraph of my requirements for the Blog Entry Editor is a future requirement to allow easy insertion of data from Amazon, Flickr or other web services. Whatever editor I pick up is going to have to be easy to extend/adapt so I can use widgets to pull that information across.

This is an isolated packet of requirements. How does this interact with the rest of MultiBlog? What else will the rest of the application do? Obviously, I need a full MultiBlog requirements specification. I don’t intend to post that as a Blog entry. I will produce a document, which I will publish, that covers and elaborates everything I intend the application to do.

That will then form the basis of my high-level software design and architecture.

Popularity: 33% [?]

Typically for me, I’ve got sidetracked for the last few articles with technical stuff. What platform? Where to develop? Get the development environment set up. All that kind of stuff. Of course, that just hand waves away the fundamentally most important aspect of writing software:

Clearly identifying what you are going to produce, what it is going to do and how it is going to do it.

That is where both bespoke and product development most typically comes unstuck. Not agreeing up-front what you’re going to write and what it’s going to do. Now, for bespoke work, where you’re creating a custom solution tailored to a customers exacting requirements, that’s a massive issue. There are many problems en-route. Such as simple mis-understandings and, even worse, the things the customer thinks go without saying.

These are the things that cause scope creep and late delivery. Much bespoke work involves fixed price and/or timescales, so this is a major issue.

Of course, in the product world it’s not such a serious issue as much of the time. Obviously, there are issues making sure that your software does something that customers want, and does it in a way that will make them want to pay for it. Also, there are issues with making that first release in a timely fashion to start getting a revenue stream. Or some users and feedback etc.

But for product software, the biggest failing at this requirements capture phase is short-termism. You might decide that the software is going to do so and so. All very well and good, and that might lead down a certain path. That path might turn out to be a cal-de-sac when you realise later on that it was obvious that so and so was right, but, implementing it in such a way means you can’t do a natural extension of so and so that could have been an obvious thing to want to do later right at the start.

So, before I get any more carried away with the platform and the development environment, I think it’s time to sit down and figure out what the basic features of Multiblog are, and where the road map will take it in the future.

Popularity: 33% [?]

We now have Apache and PHP on a USB Key. We need a database, so we’re going for MySQL. Unfortunately, this step is much like getting Apache working. We have to download the installer from the MySQL site and install it. Then we take a copy of the installed directory and copy it onto the USB key and uninstall from the host machine.

Once we have this copy, we need to create a batch file to launch it and test it. This removes the need for a custom my.ini with path fixes, because we can pass those items on the command line. My batch file contains:

\development\mysql\bin\mysqld-nt.exe --basedir=/development/mysql --datadir=/development/mysql/data --port=3306 --console --standalone

We should now have a working Apache, PHP and MySQL, and we just need to tie it all together. To do this, I’m going back to the firepages method. I have a start.php script that contains the following:

<?php
echo "starting MySQL ....\n";
pclose(
    popen(
        'start \development\mysql\bin\mysqld-nt.exe --basedir=/development/mysql --datadir=/development/mysql/data --port=3306 --console --standalone'
        ,'r' )
    );
echo "starting apache....\n";
flush();
pclose(popen('start \development\apache\bin\apache.exe','r'));
flush();
sleep(5);
echo 'opening localhost';
exec( 'start http://localhost:8080/');
?>

And a start.bat file that launches PHP in an appropriate fashion to finish that off:

/development/php/php.exe -c /development/php/php.ini -f /development/start.php

There we go. All done. Of course, this could be acheived by downloading XAMPP (Lite), however, this way we know how our environment hangs together and can easily upgrade and extend it.

At a later date, I’ll be getting PEAR working, installing XDebug and getting a PHP4 instance in here. But for now, we have a sufficient development environment to get on with things.

Popularity: 26% [?]

This morning I was reading a post by Jeff Atwood about Mike Gunderloy switching away from Microsoft. Jeff says:

Still, his [Mike Grunderloy's] attitude frustrates me, because it falls so egregiously into the stereotypical, religious love/hate dichotomy that I’ve observed again and again in software developers. You either love Microsoft and use exclusively Microsoft products, or you hate Microsoft, and you vow never to use any of their products ever again. There’s nothing in between. No middle ground.

This is something I too see all the time. People take their choice of development platform incredibly seriously. Personally, I’ve not seen too much positive Microsoft love, in my life I’ve been more exposed people with a blind and all consuming love elsewhere. More specifically, I’ve been exposed to Java Zealot’s who will not, under any circumstances, accept that anything other than Java is the solution to their problem. I’ve been exposed to Java developers who are Microsoft haters, and Microsoft haters who are not Java developers also. But overridingly, the zeolotry I’ve seen has been for Java.

My professional work has had a predominately Microsoft bias. I’ve ended up for whatever reason falling into teams using Microsoft tools and products to build solutions. My non-professional work on the other hand has had the opposite bias. I’ve tended towards Open Source languages and tools such as PHP and other scripting languages. I’ve used Delphi heavily. And when I have been using Microsoft languages (mostly scripting), I’ve been using non-Microsoft products to write the code (namely Ultraedit).

I’ve even written Java.

I’ve found this to be a huge advantage to me in my career.

Each language I learn, each tool I use, comes with further knowledge and appreciation of the art of programming. Each new language that appears is designed to solve a perceived problem with a pre-existing language, and so comes with a new development ethos.

As language and platform are a religion for so many developers, the communities round these platforms become isolated and insular. There is little cross-pollination of ideas and techniques between these communities. In biological terms, this limits the evolution and growth of development. It’s gene pool is kept artificially shallow.

I’m driven by a deep interest in programming. I love to pick up new tools and new ideas. I find that every time I learn a new language, I find new approaches to common problems, that could work in a number of other languages that I am fluent in. And then I try and take these ideas and use them outside of their spawning ground.

Looking at some of the endorsements I’ve had provided on my LinkedIn profile from ex-colleagues, it’s not just my perception that this has been good for me. Other people have seen the benefits I’ve given previous companies from this breadth of knowledge. I can think outside the box in any language, because I know so many languages. For example, this quote was from one of the senior technical architects in the Java division of my company, a division that I only directly worked with once however, provided input to many times:

“Mike is a very skilled and highly professional developer. Perhaps the most impressive aspect of Mike’s work is the sheer number of languages and technologies Mike knows to a professional standard - no doubt a consequence of Mike’s eagerness to take on, and complete, new challenges which others may shy away from. Mike’s breadth of knowledge makes him a great asset to have around as he is very approachable and will find time to share his expertise with his colleagues.”

As Jeff says:

As a software developer, you’re doing yourself a disservice by pledging allegiance to anything other than yourself and your craft– whether it’s Microsoft or the principle of free software. Stop with the us vs. them mentality. Let go of the partisanship. We’re all in this thing together.

I’m a pragmatist. For now, I choose to live in the Microsoft universe. But that doesn’t mean I’m ignorant of how the other half lives. There’s always more than one way to do it, and just because I chose one particular way doesn’t make it the right way– or even a particularly good way. Choosing to be provincial and insular is a sure-fire path to ignorance. Learn how the other half lives. Get to know some developers who don’t live in the exact same world you do. Find out what tools they’re using, and why.

It is your duty to yourself, your company, your colleagues and most of all your career to keep your eyes on the alternatives. Don’t start to feel safe that you’ve made the best choice. Pick up other languages as they become of interest, use them in anger, understand why the Ruby way of doing something is different to the Java way, the .NET way and the Visual Basic way. Take that knowledge, absorb it, and re-use it in other languages, on other projects.

Unless you are happy to be a day coder, you need to do this. If you are serious about being a real programmer, and being all that you can be as a developer. You must have breadth. You must get away from the us-and-them, the religion, the I’ve chosen the right tool, yours sucks attitude.

You must understand programming as an art, not just the particular paintbrush that was shoved in your hand. If you don’t have the time or the passion to pick up and code in other languages, at least read blogs about them. Follow the design and issues that surround using that language. Keep yourself open to the new ideas.

It will make a huge difference

Popularity: 48% [?]

So now we have an Apache instance on a USB Key. Great. Can’t do much with it, other than brochureware, so our next step is to get PHP working.

Fortunately, the nice people at PHP provide Windows Binaries in a zip file. No messing with installers and then re-copying everything. Just go and grab the latest stable Windows Binary Zip of PHP from their downloads section. This can then just be extracted into /development/php.

I’ve gone for PHP5, later, I’ll show you a quick change to the portable environment I have that enables me to test Geeklog on PHP4 as well. (I use my portable environment for the stuff I do to Geeklog too, and that needs to support older PHP versions).

We have to edit a couple of files to get this to work on the key. Firstly, we need to configure the php.ini file to support our environment. Again, the first step here is to change paths to relative ones. Simple job of finding all the paths and editing them. Boring hey?

We then have to edit the httpd.conf file again to get it to load PHP:

LoadModule php5_module "/development/php/php5apache2.dll"  

addtype application/x-httpd-php .php .php4 .php5 .php3 .htm .inc .fire  

PHPIniDir "/development/php/php.ini"

Once that’s done, we can shut down and re-start. We also need a test php file to be sure whether or not the PHP instance is working, this is done by creating a new file called phpinfo.php, dropping it onto our web root and putting the following code into it:

<?php
phpinfo();
?>

We then visit that url in our browser: http://localhost:8080/phpinfo.php and should see a nice page telling us all about how our PHP instance is configured.

We don’t really want to leave things there, there are a number of further configuration options that it’s worth getting out of the way now, since we’re tuning for development not production and the sample distributed php.ini is a sensible startign point for a production server.

The main thing we need to turn back on is error reporting to screen and log. Both of runtime and startup errors. As we add and remove extensions and as we code, we need to know in real time that errors are happening:

display_errors = on
display_startup_errors = on
log_errors = on

The magic_quotes_gpc directive is an interesting one. It’s there to protect the not so great programmers from common attack vectors. I turn it off, always, and make sure that I work round the case where it’s on. This means I have to turn it on to test. But I keep it off for development. Geeklog (an open source project to which I contribute) works with it on or off. I write my applications to work with it in either state, but, I prefer to have it off, because it saves resource and I trust my code to protect my code better than the magic_quotes_gpc setting.

If you are not sure whether you want it on or off, find out what your production host has set, and use that.

With PHP5 you need to ensure that the mysql extension is loaded (remove the ; which has commented it out), and in preparation for our mobile MySQL on USB instance, we’re going to change the default MySQL port in the MySQL area of the ini file.

extension=php_mysql.dll

and

mysql.default_port = 3306

And that should be it, a fully working, development adjusted PHP5 in Apache instance set up and ready to go.

Popularity: 45% [?]

I’m fresh home from work, I’ve got a bit of time to myself as the kids have just gone to bed. I’ve got a number of choices as to what I do. I could watch TV. Watch a movie. Read a novel. Or something else. The top contenders on my list right now are to play a PC game (Ghost Recon: Advanced Warfighter) that I was hooked on before Christmas and haven’t had the time to play since then, or to write some software.

Today I found sux0r, it’s an RSS aggregator with a Baysean filter built in so it learns to categorise the posts I read. It’s pretty neat and with a bit of work I could have it trained to read all the BBC news feeds for me and only pass on the things I am interested in, so I don’t have to keep skipping the sports or international politics and can concentrate on UK news, tech, science and health.

It doesn’t quite work how I would like, so I’ve been glancing at the source and considering making some enhancements and submitting a patch back to the core project.

When I left for work this morning however, I faithfully promised that this evening would be dedicated to slacking off and doing something purely to relax. But all I want to do now is sit and hack away at an open source piece of software. To code. Which is my normal work.

I’m not alone, Eric Sink, the founder and a core developer at SourceGear posted this in his blog the other day:

Poker or Citizen Kane?:

A few weeks ago I saw an enticing little flash game on Reddit. It’s called Virus. After playing it just a couple of times, I wished that it had a solver. It took me 25 turns to win that round? How fast could a computer do it with 3 levels of look-ahead?

That night, the question was still nagging me. The kids are in bed. My wife turned in early. Should I pop in a DVD and watch X-Men 3 again? Or, I wonder how quickly I could clone that Flash game?

Eric choose to sit and re-invent a flash game to prove he could. And a few nights later, he ditched Citizen Kane in favour of writing a Poker hand comparison algorithm.

On the surface of it, this may seem like strange behaviour to non-programmers. We’re at home. We could be doing something for relaxation, instead we’re  working. But that’s the point. For a lot of real programmers, we do it because that’s what we love to do. Footballers play football because they love the sport. We code because we love to.

At the end of the day, working on your own problems for your own interest is a real buzz. It’s the problem solving. The challenge.

If you don’t get this, then you’re in the wrong job. People who aren’t enjoying it, aren’t relishing the challenge and wanting to stretch themselves can be programmers, but they won’t reach the same heights that someone who is driven to program can.

Popularity: 29% [?]