"Hello World!" is a simple computer program, typically the simplest possible, that prints "Hello World!" to a display device. It is often used as a way of learning a computer language, and can also be used on embedded systems as a way of verifying that a platform works. In some cases, the text can be replaced by other output possibilities; a flashing LED light or a few beeps. On the hx4700, "Hello World!" on the screen meant that we had a working kernel, and that the essential code was in place, allowing us to program the machine, and have a means of reading the output. From here, things were looking good! I've also used it extensively when using new frameworks or programming languages. When "Hello World!" was printed on the screen, it was time to forget about research, and do some development.

I can't remember the amount of programming languages I've used, or at least tried to play about with. I started like most geeks, by fiddling about with BASIC. My first attempts were on an Apple IIe, then on the ZX80/ZX81 family. From there, I made a "strange" choice for some, I bought a copy of DevPac, an IDE for 680x0 assembly development. Assembly on the 68k was fun (especially when compared to x86 assembly), but I still went for AMOS. There is a game, there, somewhere on Internet, signed by me. If anyone finds a copy of Kitten Curse, let me know. If was a really basic game, made for the Amiga, and released into Public Domain. Somewhere around 1992. Anyway.

When I arrived on the x86 platform, I tried assembly language, but the x86 is a nightmare, or more precisely, I wasn't used to the x86 platform and the lack of an IDE that looked like DevPac. I had fun with BASIC shipped with MS-DOS. They day Windows 95 came out, I switched to Linux. I had played around with it before, but that was the day I went Linux full-time. In march 1999, GNOME was released, and I started with C, using the GTK toolkit. From there, C++ was a logical step, but I've played about with a few others. Python, Java and Objective C to name a few. Today I'm mainly using Java, but I'll switch to C and Python as soon as I can. I have an application to maintain in C, and that is my joy at work right now.

Today I decided to start a little collection of "Hello World!"s, in different languages, using different toolkits. A quick reminder of my roots, and a little bit of fun. If you have any, don't hesitate to send me an email, or to contact me!

A long, long time ago, an entire generation of kids grew up with a war. Nothing that you'd see on TV, nor read about in the papers. This was a bitter, merciless war that raged on behind the scenes, pitting people against each other, most of them without even knowing it. There was no winner, the good old Amiga vs Atari war just faded away into oblivion. For those who are interested, I was an Amiga person myself.

Things have changed since then, and nowadays, rare are the families that don't have at least one PC somewhere. Most families even have several. One per adult, one per child. In my family, 2 adults, no children, we have no less than 4. One desktop PC that Lolo uses daily, my trusty lappy that goes everywhere with me, an ultraportable that gets flung into a suitcase here and there, and an old laptop that is about to be retired, who lives behind the TV and acts as a gateway and remote application tester. Most people, when asked, will say they use Windows, because most people do. My job as a Linux user should be to say horrible things about Windows, poke it cruelly, point at it in public and laugh at it. I don't. I won't.

So, what do we have here? A Linux user who likes Windows? Nope, not me. Sorry, I've tried, and I just don't like it. I have my reasons, and it isn't even about the money that Windows costs. A few years ago I used to make my own PCs, nowadays I just buy one and add the required hardware. The OS comes preinstalled, and is included in the price of the machine, so that rules out financial issues. Philosophy? I might not Bill Gates as a CEO of a company, but hey, he didn't make this thing on his own, and he didn't make all of the decision on his own either. And talking about Bill Gates, name ONE person that spends an equal percentage of his fortune helping others. So no, nothing to do with philosophy. Application support? Come on, Windows is THE OS to run for application compatibility. No, I just don't like it. I like having full control over my machines, so I use Linux. I like developing, so I use Linux. I like playing games, but I still use Linux (the ones I play are supported, anyway). I've used Windows, and I don't any more. However, I don't hesitate to advise it to people.

I strongly believe that each and every OS has a potential use, a market and a niche. Windows is great for casual users, and Lolo is one of them. She happily plays World of Warcraft, copies her CDs to her mp3 player, does some light office stuff and surfs the web. She could do the same with Linux, but she likes Windows, so she gets Windows. I've used Solaris, and I can advise it. Ive used BeOS, and it's dead, so I don't advise it, but you get the feeling.

There is but one exception to the list, and that is MacOS. A sweet, sexy system that is inherently safe and secure. It is, in my opinion, one of the best systems, and I loved using it, but I avoid it as often as I can. Why? The OS itself is great. The machines are sexy, all be it a little expensive, but the cost of rock solid systems with perfect compatibility with the system comes at a price. MacOS might only support, say, 10 graphics cards, but those cards work, and they work very, very well. Nope, the reason is extremely simple, I don't use MacOS because sometimes I just can't stand the fan club. Some Mac users (I said some), are religious to the point of being extremists. I can still remember an "argument" about the Mac office suite being the best in the world, and while it is good, they are still playing on Microsoft's lawn. The people I talked to needed to win that argument because if they didn't, a huge apple would fall out of the sky and kill them. I know a lot of people who use Mac, and it's sad that just a remote few can really ruin it for the others. Some people worship their hardware, I'm not the religious type. Yes, I have an iPhone. Yes, I had a Powerbook, and I loved it. Yes, I was an apple Dev, and I loved it, but some things I just cannot stand. I've had job interviews for Mac development, and I've said exactly that reason, and even the employers agree with me, to an extent.

SSD, short for Solid State Disks (or Solid State Drives). They are considered to be the future of computing, answering the questions that have been around for years. In all aspects, SSDs appear to be better, but are they? I've been playing about with some for a while, and I've been surprised.

Idea : SSDs use less power

This is one of the major beliefs, but it isn't necessarily true. Some tests have been around on the 'net for some time, and while it may no longer be true, at the beginning of the SSD hype era, some of them actually used more power than a mechanical drive. The ones I've been playing about with use less energy than mechanical drives, and especially they don't have spin-up times where a motor is using an awful amount of power, at least as far as netbooks are concerned.

Idea : SSDs are faster

Yes and no. A mechanical drive takes a "long" time to retrieve data; first the heads must be positioned onto the correct sector, then the head must "wait" for the platter to spin round to the correct place for the data to be read. These operations are calculated in milliseconds, and in the lower part of the scale. Hard drives have evolved at an incredible rate over the last few years, and someone even compared hard drive operation to flying a passenger jet a few meters above the ground. Whilst mechanical drive performance has increased ten fold over the last few years, they just can't compare to SSDs that read data almost instantaneously. I need the data at this place, and the drive just gets it in a single operation.No head moving, no platter spin, nothing. It's just a RAM access. SSDs are blisteringly fast... for reads. Now, what most people don't say, is that life isn't just about reading, there i, of course, the write part. The drives that I've been using are terribly slow, and are much slower than their mechanical counterparts. I'm having a hard tome with our drives, since I need to change the system accordingly.

Idea : SSDs burn out because they can only read/write data a limited amount of times

True, and false. SSDs do suffer from write failures, but are designed so that writes will be placed evenly over the entire memory space. Secondly, enormous progress has been made in the memory chip field, and more and more writes can be made. A lot of tests have been made, and using constant writes where a 64Gb drive is entirely written over every day, it would take over 7 years to burn out the drive, which is about the life expectancy of a mechanical drive anyway.

Idea : SSDs are far more robust.

 Absolutely true. With no moving parts, an SSD can survive enormous wear and tear. The drives I am playing with are simply 4 chips soldered onto a board. We chose SSD drives for our machines especially for this; users can subject the netbooks to huge stresses and not be concerned about their data. An SSD can survive far more than the system it is in; the screen and mainboard will die well before the SSD, which can survive stress beyond the 350G barrier.

In my honest opinion, SSDs are not the answer to all of mankind's problems, they are a choice of technology.  They have their strong points, they have their weak points, and an engineer's job is to decide which type of drive is most fit for a particular job. I needed a system that could survive wear and tear, and SSDs were a perfect fit.

A few days ago, I had the pleasure of doing a bit of pair programming with OT, the lead developer of a small software company. It was a pleasure, but it cost me a few aspirins... 

He's seen me code, and he knows of (part) of my background. I haven't told him everything, but there again, I can't. Anyway, he knows enough. He showed me the benefits of Extreme Programming, and why I should use it. I'm interested in any technique that I can get hold of, and even if I am fond of prints, printfs and the lot, I'm not the sort to ignore any advice. So here we go, peer programming, with Olivier starting a new Python project.

The first thing you notice, once he creates the general structure with all the files and folders, he created a test.py file. The name is self explicit, but I was still wondering why. Ok, so here we go! We need to create an RPC client that talks to a server. The real life applications are countless, this is simply a generic program to start off another project, or just to show off the advantages of Python, whatever.  First thing we need to do is to create a proxy server that our python script can talk to, and that will answer us. The proxy is then responsible for sending out RPCs and getting back to us when it is done. Its a simple slave. So! First thing we do, open up tests.py, and create a test. Ahem... Ummm... We haven't done the proxy yet? The answer was "Exactly". I smiled, shut up, and watched him code. He wrote a test for a proxy that didn't even exist. "I want to talk to my proxy, and this is what I want it to answer". A few lines of simple code later, off we went, for a make test. It failed, miserably. What did you expect? So, now that the test has failed, let's make it pass.

The idea of creating a test and then writing the code was interesting, but I still didn't see the advantage to it. I'll admit that in all the code I've written up until now, I've never made any test framework or test structure other than the typical. So off he goes to code his proxy, and once he's done, he fires up make test again, and it fails. He expected x, and the proxy answered y. Now things get interesting. His routine looked good, seemed to act well, but here we have a test that is supposed to work, and the result is strange. The test itself is elementary, and a test script looks like a first year developers course. x = MyRoutine(2), then check that x = True. So if MyRoutine is sent the number 2, it has to return True. Simple! But why didn't it work? We made a simple mistake, one that got past both of us. It didn't get by the test, though. Olivier wouldn't have been affected by this, and indeed he wasn't. He made a make test, just like he did every 5 minutes afterwards, and he was told of a problem. I, on the other hand, wouldn't have seen this immediately, and I probably would have spent some quality time with a debugger checking things over and over.

The idea of writing tests before even beginning some code suddenly appealed to me, and I can even remember a big 4-month project where unit testing would have saved me hours, and probably days, of debugging. Don't you just hate it when you want to go home, but you can't? The make fails, and you just can't leave the office until everything is done. I've returned home well after midnight from time to time because of that, and I've taken work home with me on an almost daily frequency because of that. And here we go, we make a test that will fail, even before we write anything. All those nightmares coming back at me... But, no. This is a simple test, and if ever on the third or forth attempt at getting the thing to work, it still doesn't pass the test? Delete the code, and restart. Once it's done, re-make test. Then write a test for the second bit of code that you will write. At the end of the day, you might have run dozens, maybe even hundreds of make tests, but you will never find yourself in a situation where you will be submerged in errors, because you know exactly what works, and what doesn't yet pass the test. I've learned that there are things that you know don't work, and that there are things you are convinced work. Now here comes a new element, things that I know work. And even better, if ever you change some lines that risk affecting the rest of the application, who cares? If it does create a conflict, the make test will show it immediately.

Since that day, I've been making tests for almost everything that I do. I've done some more peer programming with Olivier, and even if I do get shouted at from time to time because I still write print commands, I do so less and less because tests are just so simple. Test it to death. Test that it works when I do this, and even test that it doesn't work when I do that.

So, unit testing? Fun, constructive, quick. Quick might sound strange because you write more code, but even if you do write more code, you spend less time debugging. This was my first real approach to Extreme Programming, and I can't wait to try that again.

I stated my programming live with DevPac on the Amiga. 68k assembly language was fun, but as a first development experience, it isn't the easiest thing ever. Most of the programming languages that I have tried since have been significantly easier than assembly. After a few years, I settled for C/C++ development, with a touch of Java and some other common languages here and there. Today, I've been presented with something new - Objective C. I've known of Objective C for some time now, it is the programming language that is used for NextStep and other using the OpenStep standard. I've never really done anything OpenStep, but I've seen some source code, without really noticing. Today, things have changed. I've been told to learn Objective C, and the faster the better. PA isn't leaving me alone to figure it out with Google (even if I probably could); he has bought some online training videos, projects, some good litterature and is throwing every training element I could think of my way. More importantly, time. If ever I need anything, if I have questions or if I want to watch someone code something in Objective C, someone is always there to help.

The main objective to learning this language is for COCOA programming, mainly for iPhones. The "Hello, World!" application that comes with Xcode is a 2 minute job, literally. Fire it up, add a button, add some text, compile, hello world. I've rarely seen something that easy and quick, and I'm even considering leaving GTK alone for a while. My only regret is that I don't have a Mac, and I don't have MacOS at home, even on a VM. I'd love to be able to play around a bit more with this at home, but for the time being I can't, so the lunch break is spent mainly fiddling around with Xcode. The more I play with Macs, the more I love them.

Objective C is, theoretically, a thin layer on top of C, like a glass of freshly squeezed C with a hint of Smalltalk. Interfaces and implementations changequite a bit, and I really like the fact that you don't call a procedure, but you send messages to it. and as for the dynamic typing... Wow! Send an object a message that is not specified in its interface... Who cares? No one is there to listen, no exceptions, no warnings, no problem. At the same time, it does mean that the developer needs to be careful, and I know that I'll make a few mistakes here and there, but I'll get there. I'm thrilled by the possibilites of Objective C, and this is one language I'm going to love! I've already spend all weekend learning it, and I can't wait for the next chapter.