Just as a small note, I’m off in Kuortane in Finland at the moment. Middle of nowhere, frozen bog and tundra all around, closing in on the artic circle and nothing as far as you can see outside the sports center here but wind and snow and wolves.

And I have a 256Mbit broadband connection to the apartment in the sports centre, and so do all the other 53 rooms in the facility, and there’s a free wifi hotspot downstairs.

So tell me Eircom, if the finns can get 256Mbit out to the middle of nowhere and then another hundred miles over to Kuortane, past -7C weather when it’s mild and -30C when it’s not, past moose and wolves and ice and snow; what the bloody hell is so damn difficult about getting 24Mbit broadband to the middle of Dublin City?

Gah!

If there is a lecturer in TCD’s CS department that doesn’t know of the problems and issues Joel just raised in his Capstone Projects post, they’re a rare bird indeed. But what Joel hasn’t mentioned — and what those lecturers can tell you because they’ve been debating it for decades, writing papers on it, holding conferences and have published peer-reviewed journals on the topic, as opposed to Joel’s one blog post — are that there are very specific and very good reasons why CS and CEng undergraduate courses don’t get to cover all the industry tools Joel uses.

To give a brief and inexhaustive list:

• Undergraduate courses in CS and CEng are not there to teach industrial tools, but basic principles, ususally ab initio to students just out of secondary school (high school for the US equivalent courses). This has implications:
  • Everyone must work solo. You can learn to work in teams later (and certainly there are team projects all through the four years of the CS and CEng courses in TCD) but until you have a grasp of the fundamentals, team projects are worse than useless as they mask the student’s problems with the basics.
  • No student is expected to graduate and be able the next day to walk into an industrial role without supervision or training, and no student has ever been expected to do that in Engineering since the first undergraduate course started in TCD in 1841. That’s why we have mentoring, why we have CPD processes, why we have Chartered Engineer (or Professional Engineer) titles granted by postgraduate programmes, it’s why there’s an entire structure there that’s been built up over hundreds of years of experience. Experience that we have paid for with lives in many cases.
  • Everyone needs to work on the “interesting 10%” and leave the boilerplate code for later. If we had ten years for an undergrad degree, you can be very sure it’d be covered in detail, but we don’t. And four years only sounds like a long time because you’ve never taught such a course before, and are missing details like the coverage of the entire field of Computer Science being necessary in that four years.
• Undergraduate courses lose their technical currency in something like five years on average (obviously different sectors age at different rates – web programming has a very fast cycle, embedded systems a very slow one). If we started students off on the latest fad language in year one, they’d graduate with an obsolete skill in year four. So instead we’re better serving students by choosing languages which allow the lessons to be taught clearly, or which are at least well-established and unlikly to vanish into obsolesence before they can graduate. That’s why moving basic courses to Erlang or Haskell is probably a poor idea.
• There is no such thing as the agreed best practise in industrial work. Some favour Agile methods, some regard them as toxic. What works in one sector of the industry will leave your business uncompetitive in another. What is a minor issue in one application will actually kill people in other applications. And different industry sectors have different governing legislation. So if Industry, that much-vaunted crucible where only the best practices survive the trial of the invisible hand of the free market, cannot come up with a single code of practice, what exactly would Joel have the universities teach?
• There is a duty of care to the students. There are many evangelicalists out there who promote one form of Agile methodology over another, who promote unit testing, who promote pair programming, who promote Scrum, and so forth. These methodolgies are without doubt all very interesting – but they’re also unproven. If I’d started teaching students in 2005 with whatever the Agile Methodology De Jour was, by the time they graduated in 2009, that methodology had a fairly low probability of being unaltered, let alone the dominant industry methodology. That’s four years of a student’s life, committed to a methodology based solely on the hype its originators could muster together. That’s not just poor teaching and an invitation for justified lawsuits, it’s downright unethical and wrong.

Normally in an article (or blog post in this case) like Joel’s, the last few paragraphs are where traditionally the author is meant to show a solution to an elucidated problem. Joel has highlighted a perceived lack of experience with current industrial tools and practices amongst college students (a faulty perception, but nonetheless). He’s pointed out a root cause (poor time management) which is fair enough – it’s not the sole cause, it’s not even a primary one in most professional evaluations, but it’s a valid contributing factor. So now’s the time for the solution, yes?

But here is where Joel merely says “have the students use my product to track their usage of an unproven methodology”. No indications as to how we would approach the problem of explaining the relevant industrial methods, or how we’d select the specific one we’d teach, or why we should select it, or where it’s best applied and where it’s best avoided, what it’s strengths and weaknesses are, and so forth — just pure old-fashioned, ladies-and-gentlemen-this-product-cures-all-that-ails-ya, snake oil salesmanship.

Our students may indeed have poor time management skills on long timescales (a failing which  comp.risks and The Daily WTF and IT Project Failures have been pointing out in industrial programmers for many years now, which to me indicates that industry does not necessarily have much to teach here). At least when Limoncelli wrote Time Management for Systems Administrators he was putting forward a set of skills that had proven to work for him in the field, and he was trying to pass on lessons learnt the hard way. I might not use the book as a college textbook (though I do use it myself personally), but I can at least respect his intent there. But Joels solution isn’t to teach better skills; it’s to sell his software tool to those students. Let’s throw ethics out the window for a moment and say we do just that. Now what? I can sell you the best chisel in all creation Joel, but I can’t make you into Michaelangelo by doing so – I can just take some of your money and give you a tool you don’t know how to use in return.

Frankly, when I teach the CS7004 students how to use VCS and ticket tracking, it won’t be using FogBugz or any other proprietary system, it’ll be using systems they can explore without having to pay fees for, like Mercurial and Trac. And if afterwards they need to go learn Git or Jira, they’ll know the fundamentals and it’ll take them less than a few hours to make the transition. That is what university courses are for, to teach the fundamentals so that the students can pick up specific skills far more rapidly and evaluate tools according to their proposed use. Not to act as a captive and uncynical market for proprietary software tools.

And even after that, in the final paragraph, he admits himself that it won’t work – that you still require a manager to come in and do time management even in industry. That Scrum won’t teach you time management. That the only difference between college students and industrial programmers is that the latter have time management enforced upon them by a manager – in which case, were that the truth (and it’s not a universal truth, and I’ve witnessed that first-hand), then there would be no problem with college students whatsoever.

Gah. Well, perhaps it’s time I should exercise some time management techniques that I should have used years ago — and simply stop reading Joel.

Like many people these days, I use facebook to track what’s going on with friends and family I don’t get to see as often as I would have done in years past. Long work days, large numbers of balls in the air and general “stuff” prevents actual face time far too often, but while it’s not the same as a night spent laughing over a beer, it’s better to note that a friend has a new job or that there’s a new baby en route or whatever over facebook than not at all.

And of course, facebook has games. Which is handy sometimes, for those moments when you have literally six or seven minutes to fill – too much time to sit still and be bored, too little to get anything real started. Personally, I play bejewelled on facebook for those moments. It’s been set up rather nicely there – blitz games of one minute, with scores being tracked so that friends compete in weekly rankings and little medals at various scores and scores being classed as being in the top X% globally and so on. The thing about this is that now you have a large community of people (over five million within six months of its launch according to Popcap, who wrote the game), all competing against one another – so now it’s important that it be fair or it feels like it’s not worth playing. Unfortunately tonight I noticed that someone’s been too clever.

The game’s written in actionscript. I obviously don’t know the source code, but I have a pretty good guess as to what mistake’s been made here. I’m guessing that to set up the initial game board, they used the noise() function to generate a bitmap with the six pieces represented by the values in one channel of the bitmap like so (adopted from the Adobe documentation):

var myBitmap:BitmapData = new BitmapData(8, 8,false, 0xff000000);
myBitmap.noise(<RANDOM NUMBER HERE>, 0, 5, BitmapDataChannel.BLUE,true);
var image:Bitmap = new Bitmap(myBitmap);

So now you just read the bitmap, and for each of the 8×8 pixels, if the value is 0 display a blue diamond, if it’s 1 display a red square, etc, etc. It’s a clean enough way to do it, but it has a flaw, highlighted in light blue there. If the <RANDOM NUMBER HERE> number isn’t actually random, the noise looks the same every single time. And if they’ve used another method that calls Math.random(), I’m guessing they’re not seeding it correctly there either because what I’m seeing in the game is a fairly classic case of a random() function being repeatedly called without reseeding and giving the same sequence each time. In my case, I played three games before noticing that they all opened up like so:

If I drag a yellow piece up to create a three-in-a-row in the top left corner there, it disappears and three blue pieces fall down from the top to replace them, creating a five-in-a-row (a hypercube in the game’s parlance) like so:

If I use that hypercube to delete all the blue pieces on the board, a multiplier bonus falls in attached to a red piece in the upper left quadrant of the board like so:

(You’ll note the timer at the bottom of the game is running out fast here, this is because I’m taking screenshots at leisure). If I now move the white piece in the top left quadrant to create a vertical three-in-a-row, it disappears, the multiplier (X2) piece falls down and a red piece falls behind it, creating a three-in-a-row of red pieces which vanish leaving this:

And the game progresses on from there. But the point is that this is the same sequence, every time I’ve played. So far I’ve repeated the same board in something like fifteen games (mostly while grabbing screenshots and mucking about). So it’d be perfectly possible for me to spend hours exploring this board’s possible permutations to find the optimum set of moves, or in simpler words, to cheat.

And suddenly the game isn’t fun anymore. Did person X beat my high score because they spent time playing the same game over and over honing their procedure? Is my own high score really valid anymore as a result of this? And yes, there are indeed cheating methods already available to those who are willing to install software to their browser to crack the game, but this is somehow different from that, there’s less effort required to cheat using this bug and less malicious intent as well. So it’s a nice game ruined by someone missing one single step in the setup of the game board – namely, they forgot to seed the random function with an appropriate seed value which changes between sessions.

So when they gave me the CS7004 course to teach in college this year, I went a little mad for an hour there, and after I got back up off the floor and cleaned the froth off the keyboard, it turned out I’d ordered this, Logitech’s top-of-the-line presenter remote/laser pointer gizmo. It arrived last Tuesday, just in time to not be around for the largest presentation I’ve done for a few years, but I’ve been using it since for lectures in CS7004. And I have to say, it’s very nice indeed.

First off, the basics are perfect. Insert two AA batteries, pull the USB receiver from the unit and plug it into the laptop’s USB port and it just runs. Powerpoint under Windows you’d expect, but for me it worked without a hitch for OpenOffice Impress under Debian Squeeze. All the usual features are flawless, the weight is just about perfect. No hinky little quirks anywhere that I’ve found since I got it.

But it’s the little touches that make the R800 so nice to use. The soft leather case it comes with, the soft-touch coating on the unit itself, the general ergonomic fit of the unit are all lovely. I’ve used a few different presentation remotes before, and the R800 feels better in the hand than any of them.

The laser pointer, being green, is remarkably bright in appearance – dazzling at close range even by reflection, despite only being a class II laser as opposed to the usual class IIIa/IIIb red lasers in most pointers. It’s well collimated, with the beam still precise ten metres away.

The R800 has an internal countdown timer to aid in keeping talks short, which is set and controlled by the buttons on the right of the unit. A silent vibrating alert happens once at five minutes to go, twice at two minutes, and three times when the timer runs out, at which point it counts upwards to track overrun. It’s a shame you can’t count up as a seperate function, that would be handy when rehearsing talks ahead of time, but since it doesn’t display seconds anyway, I’m probably not missing much. The graphical indication of the time running out as a vertical bar chart is a nice touch as well.

It’s handy to have the on/off slide switch (on the left of the unit) to preserve battery life for those days when you drop the remote in a bag and something bumps up against it and holds down the laser button, eating battery life.

The forward/backward and laser buttons are sufficiently large that you don’t confuse them unless you’ve got an awkward grasp of the remote, which happens rarely because it naturally fits into the right spot in your hand. The slideshow start/blank screen buttons are also handy when stopping mid-talk to answer a question or use the whiteboard behind the projection screen.

All in all, it’s a good tool and a nifty gadget. But the madness is the price. It set me back €80 on ebay – and €20 more for customs charges. I know, that’s made back in a lecture hour or two, but it’s still way too much. Overall, I think I’d sanely recommend getting the R400 instead, which seems to be the same thing but with a red laser pointer and without the timer and alerts, for half the price. I’ll grant you the green laser is far more bright in appearance, and the timer’s really handy in some cases – but unless this doohickey has a four-year lifespan and you use it a lot (like I’m doing at the moment), I don’t think it’s worth it.

That’s not to say remotes aren’t worth getting, by the way – as Presentation Zen has pointed out more than once, they’re not optional, they’re required in order to give a good presentation (and he’s right). And if you’re pitching to VCs for funding in the millions-of-euros range – where unobtrusively tracking time during your presentation is that important, your milage may vary a lot. Certainly I missed it a lot at the Big Ideas 09 event. You don’t want to be having to keep traffic light systems in your field of view if you can offload the work to a vibrating alert.

…plus, it’s nice to have nice toys every once in a while and I was celebrating, so I’m not sending it back

There’s a fair amount of buzz going round at the moment about Wi-Fi Direct, the latest thing from the WiFi Alliance people. It appears for all intents and purposes to be a version of the 802.11 Ad-hoc mode, designed to allow for connections between individual devices without the use of an AP or router, which led to bnet.com claiming it was a “sales bomb” that would somehow destroy Bluetooth, kill the majority of AP sales, kill all the companies who make connector cables and create a large security problem to solve as we all switch over to using WiFi Direct to hook up our various gadgets. And they’re not alone in suggesting this is a bluetooth killer.

Baloney. Utter rot. Nothing of the kind is going to happen, and it’s pretty obvious why. Taking one worry at a time:

1. Bluetooth isn’t going to be destroyed, it’s perfectly safe. We’ve tested 802.11 and Bluetooth usage here on mobile phones as part of the Suura project and the difference in battery life isn’t just significant, it’s game-changing. Just scanning every few minutes (and powering down in between) with a phone’s 802.11 connection will drain a full battery in two or three hours on some of the older phones while bluetooth will give three times that or more even in continous usage. Bluetooth has a pretty much guaranteed role in the low-power end of the market for the foreseeable future no matter how much success WiFi Direct enjoys. 802.11a/b/g/n transceivers just draw too much power for us to see them in mobile phones replacing bluetooth modules for the next few years at least, and then only when someone invents a circuit that works at very low power over short ranges and higher power in normal mode (which is not a trivial exercise). And don’t forget, bluetooth was decried from the get-go and survived all the knocks because it’s good at what it’s designed for.

2. AP sales won’t take a dive for a while yet for several reasons. For marketing reasons, it’ll be a while before we see enough takeup of WiFi Direct for customers to be able to do without APs even if they wanted to. Plus, there are a lot of legacy devices which will still need APs to function.

There’s also the point that there are less hassles with an AP for connecting devices. Lets say you have three computers in your home with WiFi and an AP and you get a WiFi-enabled printer. You set up one connection (Printer ↔ AP) and everyone can use the printer without having to create their own WiFi connection to it. With WiFi Direct, you have to set up three connections (Laptop1 ↔ Printer, Laptop2 ↔ Printer and Laptop3 ↔ Printer). A technology that adds work for the user for the same end goal is probably not going to succeed in the marketplace.

And add to that the point that your connectivity to the internet is going to be a main driver for AP purchases for quite a while yet in the domestic market – regardless of how WiFi Direct works out, we will not be going over to 3G for all our data needs (or 4G/LTE/whatever MNO network you choose), not for some time and possibly not ever. It’s just too expensive – 3G basestation prices, spectrum limits and other factors make serving a single Mbit of connectivity two orders of magnitude more expensive with 3G than with WiFi and a wired backbone. While WiMax may make inroads here, it’s still going to be more expensive, and won’t be able to compete with a traditional DSL line to the house for some time yet.

3. Connecter cables didn’t go away when bluetooth arrived and they won’t go away because of a just-announced, as-yet-unavailable standard. Even when it’s arrived and fully deployed, they won’t go away, and here’s why: everything needs a cable of one sort or another. If for no other reason than to supply power. And no wireless connection is ever going to exceed the potential bandwidth of a wired connection, or require less power than a wired connection to run. And it’s hard to see how you could build a WiFi connection with less circuitry than a USB cable connection. Cables are cheap, low-power, high-bandwidth, and very user-friendly and obvious in operation. They’re not going anywhere for quite a few decades yet. Even old standards like RS-232-C are still in production today, long after their ports vanished from the backs of modern machines. Saying a new standard will kill them off is like saying that bread is going to kill off water as a foodstuff…

And don’t forget the people who were saying that the introduction of 802.11g would kill off 802.11b in the crib. Legacy systems are a powerful market force.

4. What, a security problem? With WiFi? What’s new there? We’ve seen password sniffing on open WiFi nets, then WEP was cracked and then WPA and frankly, if you think there’s no possible way to crack a WiFi connection security-wise, you’re deluding yourself. The trick is to make the encryption strong enough so that the cost of decrypting it exceeds the reward – economically-based security in other words. WiFi Direct introduces no new issues here, Bluetooth and Ad-hoc WiFi and even normal WiFi all have this same problem and have longstanding tried and tested solutions to it.

Bomb? Hardly.

Competitor to Bluetooth? Not universally. In some limited areas, yes, but until and unless extremely low-power WiFi chipsets turn up, it’s never going to happen for battery-powered devices.

Interesting development? Well, sure But not something to go around playing Chicken Little over. Bnet.com FAIL I think.

So it’s not nonlinear math, but this made for a fun five minutes over Sunday morning coffee. There’s a number of ways of solving it, I went for the geometric one myself but the same answer comes out in the end for all of them, hopefully And it’s nice to think you could still pass the Leaving Cert if you had to sit it again tomorrow, so hooray for Reddit.

Enjoy over coffee today! (My scribbled answer after the break…)

3.05572809 (or for those who like a more neat answer, 4(3-√5) )

A question came up on the boards.ie programming forum a week or so ago about whether to write apps for the iPhone or the Android platform. With Suura, we’ve been looking at what platforms to write clients for (and which to write for first), and it occurs to me that the data on what’s actually going on and what the hype is pushing are monumentally disparate. Believe the hype and the competition is all between Android and WebOS.

Thing is, all that noise is ignoring a few details. First off, both are tiny. In the telecoms market, even the iPhone is a niche player. Take mobile internet usage – yes, it’s growing, and at a rate noone expected, but look at how much of the overall total is made up of phone browsing compared to laptop browsing in these statistics released by Boingo in June this year:

Yes, it’s rising and I’d be surprised if it tailed off tomorrow, but it’s still only a small part of a niche market – don’t forget that the telecoms market is seeing 50% global market penetration at the moment and is looking to improve on that. That’s one mobile phone (of any type) for every two humans on the planet. Unless you’re talking clothes or food, odds are you’ve never even seen a commodity that sells that well, let alone a high-tech one. So the mobile internet is still quite a small part of the overall picture here.

But even setting that dose of perspective aside, and looking only at the niche of the niche, what’s the breakdown of devices? Again looking at Boingo’s statistics reveals an interesting story. Everyone says the iPhone was a gamechanger, but you really have to look at the figures to see how true that is:

And it’s not just Boingo reporting this, the Q3 data from JiWire tells a similar story:

So the iPhone/iPod Touch has gone from nothing to well over 90% of the US market in the space of two years. That’s phenonomal growth, and nothing’s even close to touching it right now. On the global side of things, it’s not quite so dramatic but that’s more down to inertia and the size of the market than anything else – even in the last six months there’s been significant change according to AdMob’s latest statistics:

Now granted, all of this also means that something that’s currently nothing could be eating Apple’s lunch in two years time, but I don’t think that’s very likely for two reasons. Firstly, the iPhone really was something new – it didn’t try to be a phone first but to be a communications device first. The “Phone” in “iPhone” is really a misnomer, it’s nowhere near being as primary a function as the name suggests. But “iCom” was already taken:

Secondly, to compete with the iPhone, you’re going to have to have an integrated approach – hardware and software design. That’s not a trivial problem, it’s one of the more hinky embedded system problems around at the moment. Apple are very good at this sort of thing and it takes a fair bit of know-how to be a threat to them. Being a slightly better iPhone is just not going to be enough to compete, especially given the marketshare the iPhone currently enjoys. So for the moment (and the immediately foreseeable future), the platform for anyone looking to sell mobile apps is the iPhone, regardless of the hype surrounding Android, WebOS or Moblin.

Personally, however, I think the “Next Big Thing” isn’t really being talked about much right now. It’s going to be an iCom rather than an iPhone, the looks are going to be important, but more than that it’s going to need some major backing. I think myself that the best looking contender out there right now is the Nokia N900.

Look, everyone thinks Android’s hot because Google is big. But Google isn’t big. Not compared to Nokia. Nokia has a bad day – Finland’s GDP takes a hit. That is what “big” means. And with Nokia dropping the horrible developer experience that S60 development is, and taking on some hefty open source projects like Maemo and Qt to build the N900, and having an app store (Ovi) already running (even if it’s a pain in the fundament to use right now), they have a real shot at eating Apple’s lunch. The only missing piece from the N900, the thing that would have made it a major threat, would have been the inclusion of GAN hardware in the phone (if the operators could offload from 3G to Wifi on the fly with GAN, they’d want the N900 out there with a vengeance). Still though, if you had to seek out the next big thing – I’d be looking at the Maemo platform very hard indeed.

A new toy arrived today – the VisTablet, which is just a rebadged Aiptek 600U (model number WCK-C121). They sell as Aiptek or Waltop or Medion or any one of a few other names for about €65 on ebay.ie at the moment, so I thought what the heck, I do a fair bit of stuff in Gimp so maybe it’s worth a look. A few clicks and a week or so later and it arrives. Cue tearing open the box and unwrapping!

Plugging it into the laptop (Thinkpad R61 running Debian Squeeze amd64) got an instant result in that it found the device and allowed cursor movement… but no actual buttons or pressure sensor stuff, so it couldn’t work as a tablet. So off to google we go and after trying some frustrating messing about with udev rules (to create /dev/apitektablet - which isn’t necessary it turns out) and hal fdi files (to set up X.org options, which are needed) and I’d advanced in a posterior direction.

By now we were through the phase where plugging in the device crashed X and had reached the phase where plugging the device out crashed X. At this point, I found that the problem lay in the wacom drivers. See, just because it’s aiptek hardware doesn’t mean the aiptek drivers actually work – in this case, the wacom driver works much better.

But, just to be annoying, the new version of the wacom driver doesn’t work because it picks up that it’s not a wacom device and commits seppku to avoid being of any use. Note to the coder who thought that was a good idea – go choke on a hairball please.

Solution? Go to linuxwacom and download the latest driver, then untar the tarball, go into linuxwacom-0.8.4-2/src/xdrv and edit wcmUSB.c. You’re looking for this line (it’s line 530 in version 0.8.4.2):

/* vendor is wacom */
 if (sID[1] == 0x056A)
 {

And you want to change it to this:

/* vendor is wacom or waltop */
 if (sID[1] == 0x056A || sID[1] == 0x172f)
 {

Now apt-get install xorg-dev and whatever other packages you need like build-essential and call configure and make and then sudo make install.

You now have a working wacom driver and if you copy the wacom.fdi file into /etc/hal/fdi/policy/ (it’s /usr/share/hal/fdi/policy/20thirdparty/10-linuxwacom.fdi on Debian) and add in the following bit:

<match key="info.product" contains="WALTOP">
   <merge key="input.x11_driver" type="string">wacom</merge>
   <merge key="input.x11_options.Type" type="string">stylus</merge>
   <append key="info.callouts.add" type="strlist">hal-setup-wacom</append>
   <append key="wacom.types" type="strlist">eraser</append>
   <append key="wacom.types" type="strlist">cursor</append>
   <append key="wacom.types" type="strlist">pad</append>
</match>

into the <device> section of the xml file (you probably don’t need the eraser and cursor lines, but what the heck, they don’t harm anything and I was too tired of restarting X at this point to check). You should now be almost done – restart hal, restart x.org, and log back in and then plug in the tablet (check dmesg and /var/log/X.0.log so you’re sure it worked) and then fire up Gimp, go to Edit->Preferences->Input Devices->Configure Extended Input Devices and make sure the tablet is listed there and that it’s not set to disabled, then go to Edit->Preferences->Input Controllers and make sure that Linux Input is in the list of active controllers and is set to look at the tablet, and it should work.

Mind you… if this is what it takes to make cheap hardware work on linux, Linux Hater has a very good point.

So for CS7004’s labs, I wanted to have one large-ish, deep-ish, multi-step, interesting project. And I’ve thought of one and I’ll write it up as we go through it (no fair readers here learning before the students!).

But here’s a sneak peek at the hardware they’ll be using

(Assuming, of course, that I can get the sodding thing to do what it needs to do!)

Well that didn’t go too badly. General course overview and a probably over-long “what is an embedded system” lecture. No-one overtly fell asleep at any rate. And everyone enjoyed the videos of the explosions.

So what the heck, enjoy – Ariane 5 Flight 501. An example of what can happen with unsafe datatype casting

Next talks are on the hardware used in embedded systems, starting with the microprocessors and microcontrollers.