IE6's entrenched position came from the fact that (a) it was the latest version of Internet Explorer for a huge amount of time and (b) its status as the IE dead end for Win2k and below.

When IE7 came out, any company that still had any Win2k machines had to keep designing with IE6 in mind if they wanted their new apps to work on all their computers. (I'm making the assumption that if they were relying on IE previously, they couldn't just switch to Firefox or something).

Now, IE8 I think most people can accept is going to end up in IE6's current place. It's the IE dead end for XP, a hugely popular OS. But IE7? None of those companies that don't upgrade upgraded to IE7. Home users that upgrade will also have installed the IE8 upgrade. So you're left with what? Unpatched Vista installations. These are much rarer than unpatched XP installations simply because Vista had a shorter lifespan, and Windows Vista to 7 is sufficiently undramatic an upgrade for the types of people who would take years to go from XP to Vista.

So so far we have:

• IE6 will drag on as long as XP does.
• IE7 won't last particularly long. While it's popular now, earlier Vista computers will be replaced in the close future (2-3 years), causing it to lose market share to IE8.
• IE8 will have a long lifespan, although probably not as long as IE6.

IE9? IE9 has never been shipped by default with any version of Windows. That means anyone who installed it did decide to upgrade. These users will likely upgrade away, meaning in the future, IE9 will be even more of a non-issue than IE7.

IE10 will likely also go the way of IE7. While it will be installed by default on Windows 8, the amount of dramatic changes in W8 will scare off many of the companies that are slow to upgrade.

So in 5 years time, what versions of IE will realistically you need to support?

• IE6 (maybe - probably, hopefully, enterprise only at this stage)
• IE8
• IE10 (enterprise will never use it because Win8 is scary and different to them so for home users only)
• IElatest-1 So IE13 or something?
• IElatest IE14 or something.

Needing to support IE6 and IE10 will likely be mutually exclusive, so that's 4 versions for sites targeted at home users and 5 for sites aimed at both enterprise and home users. Still ugly, but far from 76. And all those versions will be dead in the timescale that the article is using. Insofar as IE6 will ever die, anyway.

IE6 for home users will be dead at that point. Most of those old early XP computers will be "broken" and replaced, even if "broken" is just slow and annoying. Using XP in five years will be like using Win98/Win2k. Yes, people do use them. No, they aren't a large enough group for most to worry about. I even have a small amount of hits from Netscape 6. I haven't a clue what my page looked like for them, and don't care.

In theory, if even IE is aiming for at least yearly releases from now on, no future IE will end up in the position that IE6 is in, and that IE8 will find itself in, as upgrading your browser frequently becomes a fact of life. The compatibility modes will be much less important too, as the shorter lived the browser, the less likely that the compatibility mode for it will ever be used.

However, for someone learning to program today, for the most part, large parts of any itch that could be scratched has already been done so by someone else. Usually, this is someone who has done a much better job of it than any newbie code. This means that if they follow the advice regarding NIH, they would be reduced to writing glue code for quite some time, tying together libraries written by other people while they program relatively boring code.

The problem with this is twofold:

1. The newbie doesn't really learn much about designing their own programs. Sure, they see how the (hopefully) well written libraries do it, but they don't get to see the thought process required, or any of the refactoring that removes earlier bad design decisions.
2. Glue code is boring. How many people are driven away from programming by this experience?

One of the first big programs I wrote personally was a PHP social network. I did many parts of it from scratch - a database abstraction library, a templating system, even a primitive MVC system¹, and so on. The code that resulted was horrible, and probably riddled with security problems, but I learned a lot from the process.

How would a newbie do that nowadays? They'd install cakePHP or Django or Rails, getting them a DBA layer, templating, MVC all written for them. And sure, the resulting program will probably be cleaner and less buggy, as all the hard parts are handled by the framework. But the job of the programmer gets relegated to writing some models and a few views that are pretty much the same everywhere.

But then a lot of the benefit from trying to write a program for themselves just isn't there. They don't get the benefit of finding out why some ideas don't work, as they just use the framework. Most of what they learn are the APIs of the framework, not any of the thought processes involved in creating the program. Not to mention, while people writing more complex programs than anything a newbie might be delighted to have that problem taken out of their hands, as they figure out how to make their database not fall over with 20k users.

The fun of programming is solving new problems. That's why Rails and co. are so popular. After you've written your second or third wep app, then these problems quickly become old problems, and having Rails handle them for you is really convenient. But for a new programmer, they haven't solved these before. Their programs will not be as ambitious (as anything that ambitious will most likely be dismissed by them as too hard), so having Rails solve these problems will leave them without any problems to solve.

Of course, another benefit is that when they are finished, they can go look at the existing solution to see how it compares to their own solution. This can help them to compare the thoughts that led to their own solution to the (presumably) better result of the existing solution. If they managed to find some itch that hadn't been scratched by someone else already, they wouldn't be able to find a sample to compare to their own work.

In short, laying off the avoidance of "Not Invented Here" can help newbies learn quicker in many cases than being relegated to writing glue code.

Any sufficiently advanced technology is indistinguishable from magic.

Arthur. C. Clarke

As a programmer, and a computer nerd, I obviously know more about how they work than if you just grabbed a random person off the street. As such, it's always interesting to see how people with less knowledge about computers use them.¹ To a lot of people, they click some buttons on the screen, and then the computer does something that may as well be magic, and finally results appear on screen.

However, it's not just those unfamiliar with technology that find that at some level, the processes going on may as well be magic. Very few people understand the entirety of how things work from top to bottom. Moving on from the unfamiliar user and the buttons they click, for many poorer developers they type (or copy and paste) in some code they don't really understand and somehow it all works. Their magic layer is lower than that of the user who doesn't understand how the program actually works. After all, they understand that programming code needs to be written, but they still don't understand any of what goes on beyond that. Their magic layer is off in the function calls, in the syntax on the language, in the meaning of the code. They may understand small sections, but the entire program as a whole is still magic to them.

Moving on from the poorer developers, novice developers, who instead of incompetence only have the problem of knowledge they don't yet have. They understand for the most part how their code works. They know how to structure their functions, they know when to use objects (and when not to), they can create programs from scratch. But they may not quite understand what is going on in the library routines, or what happens when the compiler creates a program from their code.

As you go further up in the skill of the developers, the magic level recedes. They realise that the library routines are just like functions they create themselves for the most part. Some might make system calls, but other than that, there isn't much magic there. They understand that the compiler reads their code, and produces machine code which is run by the CPU. The magic is banished from their code to the inner workings of the compiler/interpreter and the operating system.

Finally, once the developer learns how those last few retreats of magic work, they can understand pretty much the whole picture, as far as software goes. However, this still isn't the final end of the story. Sure, the magic might be gone from the software side, but there is still the hardware. How do those system calls translate to data being written to disk? How does the CPU know that MOV eax, ebx moves data between registers? And at this point you're in the hardware layer.

So, where is your magic layer? Personally I'm at the "inner workings of the compiler/OS" stage, and to work on pushing it further back, I've found some useful online resources. As a self taught programmer, most of the resources I've had up until now glossed over these areas, and it's my main aim for this year to push the magic layer back into the hardware. For compilers, I've found Jack Crenshaw's Let's Build a Compiler useful to start with, and I'm currently reading through that, and for operating systems, a bunch of useful articles have actual coincidentally popped up on Reddit and HN recently on that topic, though I'm still open for suggestons on other resources.

If you found this article interesting, why not follow me on Twitter, leave a comment, or suscribe to my RSS feed.

Some further discussion of this post can be found at Hacker News and on Reddit.

The first part of the IRC protocol is the rough layout of messages. The first, optional part, is the source (username and hostmask, or server) preceded by a colon, as in :holmes.freenode.net . Because they only deal with one other part of the network, the server, clients will rarely, if ever send this part, while servers nearly always will.

The next part of the protocol, seperated by a space is the command name, which is in all-caps. Most of these are pretty much the same as what the user types in after the /. For example, the /join command becomes JOIN. The most notable exception is the PRIVMSG command, which is used for sending a message to a user or channel (it's the same command for both).

After this come the arguments for the command, again, space seperated. Most of these are limited to one word values. The one exception is the final argument, which can have more than one word, and is started off by a colon.

There are a few types of channel, but nearly all the channels you will encounter are of the #channel variety, so we will not go into detail on other types.

Finally, the command is terminated by \r\n not \n according to the spec, though it seems most servers will accept either.

An example of a full message is as such:

:Macha!~macha@unaffiliated/macha PRIVMSG #botwar :Test response

The first part of any IRC connection is sending the NICK and USER messages. The first of these is simple, just NICK name. The next is the USER message.

An example of a USER message is:

USER username 0 * :Real name

The * part is a remnant of earlier days, and will not need to be changed. The 0 is a bitmask for the user's mode, but with just one switch. Change it to 8 to be invisible to those not in a channel with you.

The next part of the protocol we will discuss is the PING message, because some servers need one immediately after these two messages. The server will send you a message in the format PING :message to which it needs a response of PONG :message. This is the most common case of a server not sending a source. Most servers use the server name as the message part, but this isn't consistent.

For all of the rest of these messages,  there is a source on the other messages from the server side. This is a user and hostmask for a user's message, and a server name otherwise. If you are writing a client, do not send the :source part.

The next message to deal with is JOIN. The basic format of this message from most servers I've tested is

:source JOIN :#channel

although the spec says otherwise as regards the need for the colon. This is pretty self explanatory, and works the same as the /join used in an IRC client. The one unintuitive part of this command is that JOIN 0 leaves all channels.

Its counterpart is PART. Its format is

:source PART #channel :reason

The reason part is optional, and some servers (for example Freenode) seem to just cut it off, as it did not exist in earlier versions of the IRC protocol.

Both of these messages can also accept a list of channels separated by commas when sent from the client, for example PART #channel1,#channel2. Don't put spaces between the channels in this list.

The most important command in the IRC protocol is PRIVMSG. This command is used for sending messages both to channels and between users. Its format is

:source PRIVMSG <target> :Message

where the target is either a user's nick, or a channel name. So to send a message to a channel, use PRIVMSG #channel :Hello, World and to send a private message to a user, send PRIVMSG Nick :Hi!

The final message you will use in basic usage is QUIT. Its format is

:source QUIT :reason

where the reason is optional.

These commands are sufficient to write a basic IRC bot but are by no means the full list. There are also numeric commands, and you can find more detail on these here.

If you found this post interesting and want to hear more from me, you should follow me on Twitter.

My first experience with anything even close to programming was when I was around 12. I had gone through all my mum's ECDL stuff for MS Office years before, and there was one program in Office on my then computer that wasn't even mentioned - Frontpage. So I got bored one day, and decided to check what it was. I gathered quickly enough that is was for making websites, and I sort of got parts of it, but I had to get a book from the library to figure it out fully. Armed with this newfound knowledge, I managed to make a basic website, a horribly primary-coloured frame-filled website, but a website nonetheless.

Of course, my instinct was to show it to people, so I found out about Angelfire for hosting from an even older book, and uploaded it, then showed it to people online. Needless to say, people didn't like it very much. But a few people did give me some somewhat useful advice, to drop Frontpage. They mentioned something called Dreamweaver as being better, and also suggested learning HTML. Which I did, until eventually I was using Dreamweaver as a glorified text editor.

Meanwhile, looking for the next thing to do, I decided to learn actual programming, in the form of Java. In retrospect, not the best choice of language for starting out, but it was one of the few that my local library had books for. The other alternative if I was to stick to library books was Visual Basic 6.0, so it was definitely the better of the two options. I went through the whole book of Java All-In-One for dummies, went through it, did all the examples, got to the end, and wrote a little Java clock applet for my website. I was so happy with myself, that I decided to go even further, and my next plan of a project was to make a Simcity clone in Java. Unsurprisingly, that didn't work out too well, and the failure put 13 year old me off programming for a while.

By this stage, I had long cured any illusions of coding being anything like the Matrix

The next time I came into contact with programming was when I was running a forum with a few friends. It ran off phpBB, and when installing mods, I noticed that all I was doing was editing programming code, which was kind of familiar. I looked into it a bit more, found out about PHP, and then quickly learned that. It was significantly easier to learn, both because it was my second language to learn, and also because languages with weak dynamic types are easier to learn in my opinion.

Of course, the problem with learning PHP, especially if you use the phpBB 2 code base as your example is you pick up bad habits. Now there's nothing inherently wrong with the language nowadays, but this was the PHP 4 days, with it's half-assed attempts at OOP. On top of that, something that is still a problem today is the amount of bad material floating around. Now, this is a problem with any language, but given PHP's large userbase, and popularity with hobbyist coders, it's far more pronounced in PHP than others I have used. So code found on the internet is ripe with a lack of care towards seperating output and processing, full of SQL injection holes, and often even relying on register_globals. But this isn't anything new. But it does lead me to recommend to everyone trying to get a good book. I started with this one, and while it did help me learn PHP, it set me back a long distance in terms of proper coding practices. Eventually, I got this book to learn how to code properly in PHP.

Around that time I started reading programming blogs, and found out about source control, in the form of Subversion, a rather important topic that no programming book seems to mention. Seriously, apart from Code Complete, which mentions it in glancingly a few times, the only book on my shelf that explains source control at all is the Linux Bible, 2009 edition. And that's talking about CVS. Now for all Subversion's faults, any source control is better than no source control. Later I was introduced to git and DVCS in general by some friends, and it's now my preferred form of source control (git for all Linux projects, hg if I have to work with Windows users). It didn't exist at the time, but for anyone looking for a good DVCS tutorial now, I reccomend Joel Spolsky's hginit. Even if you plan on using git or another program afterwards, it's the best basic explanation of the concepts of DVCS I've seen.

This was the only book to mention version control. Going back to my own journey, after that time in PHP, and several ill-fated projects, countless attempts at building a forum, a incomplete social network, and a completed, if basic, social network that I failed to get anyone to join, I moved on to Javascript. I spent ages messing about in that, making small scripts to move things around, before getting more ambitious. Yet again, I returned to the idea of a simcity clone. Given that this was before canvas became well supported or known about, the core of the program used a 200x200 table for the game's grid. It was every bit as slow as that sounds.

After a while of this, I returned to trying to make GUI desktop apps. I know, I know, many considering this a step backwards from web apps, but at the time, I couldn't think of many examples of web apps that had progressed of the "Oh, that's mildly interesting" stage. I had used Swing before, in my failed Simcity game, but wasn't particularly impressed by it. I gave SWT a go, before giving up again. I guess my problem with GUI apps resolves from my desire to control every last detail, compared to the designer-tool-centric design of most of the GUI toolkits. Somewhat bored with GUI apps again, but also bored of the general dislike of my main language, PHP, I went on a quick tour of several languages, including C#, C++, Ruby, Python, Ruby again, before finally deciding on Python as my new favourite.

Around this time, I switched to Linux as my primary OS. I'd tinkered with Linux for a while before this, but had always been too used to Windows to actually make the switch until then. Since then, Windows has been mostly relegated to use for gaming and iTunes.

I spent a while coding in Python, before going on a short hiatus from programming for a while, being somewhat bored as all the languages I learned being roughly the same at this stage, and no new ideas for a project to keep me interested. Projects are another thing I recommend to anyone starting to teach yourself programming, as even the failed ones or ones you get bored of are a good learning experience, especially if you have others looking over the code.

After a while, I decided to learn a less mainstream programming language, and after a quick straw poll on Twitter, Haskell emerged the winner. Luckily for me, Haskell has a good beginner's tutorial, Learn You a Haskell. I've heard it described as like Why's Poignant Guide, but it's not really. It's much more to the point which works for me (I'm sorry to say I found Why's Guide a rather boring read, having too much unneeded meandering with stories. But I accept it's good for others). It is a rather basic tutorial, but there is also Real World Haskell for when you need to go further, even if it isn't as well done.

And now, my current project is to write an IRC bot in Haskell to learn Haskell better. I'm still learning and improving, and it's going to be a handy headstart for college that I have all this done already, so the story goes on. If you want to hear more about me, you can always read more of this blog, or follow me on Twitter.

What you need on if statements after the first language is just a small paragraph like:

Python if statements are done like so: if condition: doStuff() elif other_condition: doOtherStuff() else: doOtherOtherStuff()

Seven lines, not a whole chapter. Oh look, the language docs do that. Never mind then. Those chapters are now totally redundant. Spending €40+ for the last 5 chapters really doesn't make sense.

The other problem is one of quality. Several books promise to teach you everything about something, yet obviously fall far short of it. An extreme case can be seen in the two books I bought around 2-3 years ago, when I was first learning PHP.

Which title do you think is more accurate?

Even apart from the amount of extra information in the Apress book, the quality of that information is far better. The smaller book doesn't even mention how to create a class. And it would have you believe that the only way to interact with a database is through the old mysql library, using functions like mysql_fetch_assoc(). Oh, and to really rub it in, it does actually mention MySQLi, but basically as a slightly faster version of the MySQL functions that needs to you put an i in your function calls, and nothing else. The example code in it always mixes code and markup, and then you wonder why PHP has such a bad reputation, when there are so many books like this floating around.

The problem is, many people will look at these books, and see the Apress book looking much more formal, and presume that's it's full of unnecessary detail. I did at first (hey, I was just starting out), which is why I initially bought the second book, then had to go back and buy the other one when I finished the first one, and realised I could of learned the same amount of stuff from 2 hours and an internet connection.

Of course, eventually, every programmer moves on from these books to more general ones about coding in general, rather than specific technologies and languages. The problem is, many book stores don't bother selling anything more advanced. And the only computer shop where I live, PC World, has an even more pathetic collection. So you have to wait ages for something to turn up. Or have someone recommend a book, and then buy it online. You can't browse through books, flicking through a chapter of each to see which looks better, on eBay or Amazon unfortunately, which rather limits the options for just looking around for something good.

Moving on to better books, like this one.

The first proper programming book I got was Code Complete, second edition, which I bought roughly a year ago. I'd heard a few people recommend it before, but hadn't went to buy it. I was amazed when one day, among all the copies of Excel for Dummies and iPhone for Seniors, there was a copy of Code Complete in the book store. I presume someone had ordered it in, and the store had just got a few of them, because it's sadly not the kind of book they usually get. I suppose they rather books that don't require the customer to have some knowledge already. (Which is odd, because surely they'd be able to sell two books with an offer like "Buy this book to learn how to program, and this book to learn how to program better.")

Unfortunately, even when you know what book you want, the book stores don't do themselves any favours. Around this February, I had €30 in book vouchers for the local bookstore left from Christmas, and decided to buy Design Patterns with them. I had the PDF version, but I still read best from dead trees, so I had a look. Unsurprisingly, they didn't have it there, as most of their books are of the Language x for dummies/Buzzword y in 24 hours variety. Oh, and they have Code Complete again as well, but I already have that. So, as I had expected, they would need to order it in. I had checked beforehand, and the book was €30 delivered from Amazon. I expected it might be maybe €40 in the bookshop, cheaper once you factored in the vouchers I already had. It wasn't €40. It was €82. I don't know what planet they are on in the bookstore, but needless to say it's led to Amazon being €30 richer.

A welcome development is the trend towards free online books. Examples such as Dive Into Python, Programming Ruby, Dive into HTML5 and Real World Haskell do help with their respective languages. And the fact that they tend to be more concise than the usual books on the shelf (I know they come on dead trees too, but nowhere near me sells any of them) also makes them more useful, even despite my preference for reading from a physical book.

So, after purchasing the VPS, I set it up with the basics: DNS, Apache, MySQL, PHP (my blog runs on Wordpress which uses PHP, which is why it got in ahead of Python). Very simple, just use the package manager and Control Panel to set it up. There was a slight mishap where my DNS changes were propagated before I fixed them, leaving my blog not set up yet. But that was soon resolved.

After about a day, I noticed Apache was getting random segfaults serving static pages. Rather than spending ages to debug the problem, I decided to try out nginx, which I had heard good things about. It was quite simple to set up, with Linode providing a guide with most of the steps. All well and good. Until, about two days later, nginx started reporting a 502 bad gateway error. A problem with a new web server? Nope. The fault lies with php-cgi, and it was compwhizii's blog to the rescue again. His post about using nginx provided a link to this page explaining how to solve it. The short version? Set the  PHP_FCGI_MAX_REQUESTS environment variable, so the php-cgi process gets restarted every so often.

The VPS is, unsurprisingly much better than the shared hosting. SSH is much better for administration than the old Control Panels. The first project I'm doing to really make use of that, is something I have planned using Django. More on that later, if it comes to anything.

So first of all, to quote one of my tweets:

After using it a while, I apologise to vim users. It isn't weird and crap, it's just weird.

I haven't exactly been the most positive of vim. After all, as a Linux user, it's nigh impossible to use many of them without one of them using vim or a vim-like interface for something. And while nano manages to be relatively easy to understand, vim does not. Because vim is weird.

But after a while of using it, I realise it's weird for a reason. Want to get rid of a line? In other text editors it's:

• Left arrow to start of line
• Hold shift
• Hold right arrow to end of line
• Press delete

In vim it's:

• Type dd

Don't like that 13 line function anymore, and want to delete it?

In normal editors it's:

• Up and left arrows to start of function
• Hold shift
• Down and right arrows to end of function

Vim is:

• Type 13dd

Weird, obtuse, but once you learn it, it's far more efficient. A final example. Suppose you want to rename that variable from $car to $vehicle:

A normal text editor?

• Edit
• Search and Replace (somethings this is part of search anyway and under Ctrl-F, other times it's its own menu, under Ctrl-H)
• Type in $car.
• Type in $vehicle

Vim?

• Type :%s/$car/$vehicle/

At this stage, I'm still not getting the most out of vim. After all, I only know a few basic commands (and even then I'm missing a few. Any vim users care to tell me how to Select All?). Yet I'm already finding it easier and faster than I did in other editors. vim is also cross platform, unlike the Windows-only Notepad++ and Linux-only gedit, which means I can use the one editor across all OSes. For that matter, it's even available on my jailbroken iPod touch.

Another useful feature of it is it's huge styling and plugin community. Again, Sirupsen pointed me to BusyBee. I didn't quite like that, so I found Mustang, the theme it was based on. I haven't yet found plugins that I'd reccomend, but the choice is huge. One of the inbuilt ones, allows you to set different options per language. I'm doing a project in Ruby atm, and in any other editor I'd have to change my settings to and from my personal preference of tabs and Ruby style of double spaces. With vim, I can set it to do tabs with all other files, and just do the silly double space thing with Ruby.

This reminded me of when I was starting out (and again when I was starting out with Javascript, and again with PHP, and again with... you get the picture). Like him, I also struggled to think of something to make. My first trivial program was a Java clock applet when I was 13. I saw one on another site and decided to make one for my own. My first non-trivial program was a social network, written in PHP when I was 15. Two years to think of an decent idea that I could keep working on until completion.

I think the problem with beginners projects by self-learners is one of overreaching. I've certainly done it a lot. If they try to write a social network, they want to write Facebook. If they write a forum, they want to write vBulletin. If they write a game, they want to write Fallout 3. All of these were written over a significant amount of time by large groups of people.

My advice is this: Start small. Reduce whatever you plan to build to it's basics. A social network can be reduced to users who can add friends, edit profiles and leave comments on other's profiles. A forum can be reduced to users creating threads and posts. A game can be something like Pacman. Implement these basics. When you have them done, you will have enough motivation to get the rest of the stuff done (login, logout, etc.). While you can't assume designing a successful product is as simple, as the linked blog post shows, designing a beginners project to practice your coding is easier than designing a product to base a business around.

Despite not being quite that simple, many successful products are based on simplicity. Compare Twitter to Facebook, punbb to vbulletin, Google Chrome to Firefox. Simple and fully-featured are two equally valid design strategies (although I tend to favour simple products myself), but simple ones are much easier to get going.

Once you have your basic program written, you can then add features to it. You could add image uploads to your social network, bbcode to your forum or extra enemies to your game. Further again, you can add groups to your social network, tagging to your forum, and new level types to the game. Since you already have a working base to start from, it's much easier to look at it feature by feature, instead of waiting ages until you have anything that works.

Given that (a) it's written by a beginner (me two years ago) and (b) it's PHP, you wouldn't be surprised to hear that the code is bloody awful. Even for a basic CRD app (I hadn't programmed the U bit), it sucks.

Hardcoded numbers and categories everywhere, no sign of code organisation, redundant code, copy/paste as a design pattern and inconsistent naming. It's a wonder that information going into the database was even escaped. And let's not talk about character encodings.

Needless to say, now that I've picked up the code again, it's had a swift rewrite. It's still pretty crap, but at least it doesn't screw up completely if you type a euro sign.

Has anyone else ever seen some of their first code and gone: "I can't believe I wrote this crap"?