Packetfury.net

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.

Divide by zero. It is a killer. It has crashed computers, it has wrecked research, it has crashed countless models, be it automotive, aeronautic or even space. It is an impossibility, and the impossible can be a killer. It can also keep you up until 4am talking about the joys of mathematics.

Reminder. Computers. Computers are only as intelligent as the programmer (and even then...). They are stupid machines that can only deal with certain numbers, and do certain things. What makes them flexible is the programs embedded into their memory. They count in binary, and even if some programs allow you to use fractions, imaginary numbers or entire sequences, it all boils down to binary at one point or another.It also boils down to basic mathematics; plus, minus, multiply, divide. Divide. What is a division?

Laws of computers, especially the law of divide by zero. Don't. Division by x is the same as multiplying by x's inverse number. An inverse number is the number where number x inverse = 1. Multiply anything by zero and you get zero. Therefore, zero does not have an inverse, and therefore you cannot multiply by the inverse of zero, therefore you cannot divide by zero.

An inverse of zero "exists", but not in any series of real numbers, and binary can only deal with real numbers.  Some toolkits detect a divide by zero, and quit quietly. Some languages scream. Some languages crash, root the machine and make it very, very angry. Worst case scenario, unplug the power and replugging.