Space: The closed frontier

This makes me happy:

ISS and Endeavour seen from Soyuz

Once in a life-time picture of the Space Shuttle Endeavour docked at the ISS. Taken by Italian astronaut Paolo Nespoli from the Soyuz TMA-20 following its undocking on May 23, 2011. For more, see NASA's incredible gallery or click for an embiggening of this image.


But this makes me very sad indeed:

Time flies

Credit: XKCD


If you’d asked me as a teenager, I’d have told you that we’d be on Mars by 2010. Why? Because we can. Because it’s there. Because we’re explorers. And because new eras of civilisation begin with new discoveries on new frontiers. There are those that say that we’ve got better things to spend the money on, but then again, those people clearly don’t have even the most basic grasp of how economics work and if we listened to them then we’d still be stuck in the middle ages. I don’t know about you, but I’m prepared to poke around expanding the horizons of our knowledge out of both curiosity and the hope that this expansion improves both the lives and collective understanding of everyone.

When I was growing up, I believed that I’d get a shot at going into space in my lifetime — that the cost of doing so would allow me to cover the Earth with my thumb and have the same sense of perspective that the Apollo astronauts did back in the late 60s and early 70s. Now, sadly, it looks less and less likely. Until someone figures out how to make a whole stack of cash out of putting people in space, such baby steps into the void around our little planet need to be funded by tax payers and one of those funding doors is about to slam shut.

Today is the last ever launch of the Space Shuttle. Atlantis is scheduled to lift off at 16:26 BST. They’re filling the tank with fuel as I write this post. Bad weather means that there is only a 30% chance of successful lift-off, but if you’re remotely interested in this stuff, tune in to NASA TV and watch the whole process: it’s the last time you will be able to do so. You can watch the astronauts get strapped in, listen to all the hard-working folks check and double-check and all being well, get to watch – live – the last ever launch of the Space Shuttle. Tune in. It’s history being written.

In the meanwhile, manned space travel is now the realms of the Russians1 and their fantastically reliable work-horse Soyuz. The European Space Agency are tootling around with some stuff that’ll probably be derived from their pressurised ATV, but frankly, they’re so bloody awful at PR that I doubt you’d notice even if they did launch someone. They’ve managed to make space travel about as interesting as watching grass grow.

Have a fine mission, STS-135.

1 And the Chinese now that they too are setting out on this exciting path.

Posted in Cool stuff | Tagged , , , , | 3 Comments

I used to be indecisive but now I am not sure

Space snake is doooooooomed

Space snake can concentrate all he wants but his spaceship is on fire and anti-matter blah blah containment blah plasma injectors something etc.
(PS: this is a clue!)

It is time for May’s iPhone game update and progress has been made! A whole nine hours of work went into creating a working map editor and it was great fun to create. I learnt a lot about Cocoa, Interface Builder and XCode 4. All in, definitely worth it. Can you feel it yet? You can, can’t you… there’s a but coming and it’s not the firm, rounded female version with two ‘t’s, it’s the apprehensive, confused single-‘t’ version that potentially leads to complete changes.

The problem is that as much as I love my idea, it invokes too much asset creation. That kind of stuff doesn’t come free. Unlike the outrageously over hopeful teenage designers who advertise with “leet MMORPG WOW beater, just need 10 programmers and 10 artists.. will split revenue no contracts just trust honest I am an expert, not living with mummy!11!oneone!”, I know my limits here and also I know why I am doing it: for the fun. I want to make a game that is a blast to play that someone else might also enjoy. There is little point in doing it if by the time I am done, the window of opportunity has slammed down on my fingers and rendered the effort pointless.

So a turning point has been reached. I recognise that cobra-art, as stylish as I fool myself into thinking it is, is not suitable for a published game. Furthermore, it takes me bloody ages to draw anything and my repertoire consists of snakes, germs, giraffes (necks and heads only), one toaster, a pigeon (he took hours) and some other unconnected junk. Drawing hundreds of little animating sprites and map blocks across three different themes as well as designing the maps themselves is, well, a little like saying that I am hungry enough to eat a hippo and then actually doing it. It’s over-optimistic by a massive margin and I’d never get enough barbecue sauce.

Now I moan about this indecisiveness leaving lots of unfinished stuff behind, but this is different (hahahaha!) no, really, it is different. I look at the book ideas folder on my computer and see tons of stuff. Will I ever finish them? Of course not. Are any of them unborn classics? Unlikely. Will I raid them and cut them into little bits for future blog posts? Possibly. The thing is, I don’t write for a living. I knocked out some books when I was younger so I have a sorta been there, done that. It is the same with this game. It is pure fun. I want to see if I can do it: me, a couple of volunteers and a year or so’s effort leading to a mobile game that is not rubbish. The key here is that it leads to something. The effort is worthless if there isn’t a game to enjoy at the end whether that game is published or not.

Needless to say, I have another idea. It is something that has been forming gradually in my mind for over twenty years. It is something that, until now, I could not see being possible without a huge team and a suitcase full of money. Then, whilst soaking in a particularly relaxing bath a week or two back, I had a bit of a brainwave. I finally figured out how to do it quickly and easily: like figuring out how to make a 10,000 piece jigsaw puzzle assemble itself using nothing but the power of bacon. It is terribly exciting. I have had a (non sexual) tingle of anticipation over this idea that I have not felt for a while. Like all massive strokes of good fortune, I am currently in the ‘surely there is a catch’ stage. I have not found said catch yet so I am going to give it some thought during the next month or so. July is a busy month for me work wise so I will let the idea roll around my braiiiiins for a bit and perhaps sketch a few ideas and maybe even try out an algorithm or two to see if my hunch is right. In the meanwhile, there are BBQs to be had and much wine to be drunk.

Posted in My iPhone game | Tagged , , , , | 5 Comments

Germs! GERMS!

Vicious Germs

They got me, next, they'll GET YOU!

Ihad a four day week last week! So, on one hand, yeah! On the other hand, bloody hell. What happened to Wednesday? No, seriously, where did it go? Now if I wasn’t the typical yellow-bellied male who believes that even the lightest sniffle is the plague, I’d say I had flu, but I am so let’s just say that it was a god awful cold caught from baby Cobra who dealt with it considerably better than me.

Anyhoo, there’s this “scene missing” in my life from about, oh, 9PM last Tuesday that stretches through to about 8AM Thursday. I vaguely recall managing to cook a stir fry Wednesday night to feed the Cobra family and I have absolutely no idea how this happened without me blowing up the kitchen or myself. Also, there was was something about something or something. Who knows. Either way, last Wednesday was a day of mystery and I’d not even been drinking. Still, fortunately, my immune system finally got its arse in gear at some point Thursday and started doing what I pay it to do and got out there with knives and guns and started murdering germs. Whilst they look cute, the little buggers are nasty. Watch out, you could be next…

Posted in Miscellaneous rubbish | Tagged , | 2 Comments

Scheduling the baby out with the bathwater

When it comes to true innovation, try you must or do you will not. Whilst the larger companies have whole R&D departments dedicated to experimentation with new techniques and technologies, the smaller outfits or individuals have to innovate as they go along. One of the first casualties of war when it comes to tight schedules is the wistful experimentation that leads to great leaps forward. Playing and fiddling with new technologies, new ideas or just exploring whacky thoughts is what ultimately invents the new stuff that’s really exciting. It also exercises the brain, develops new knowledge and expands horizons. When you lose the chance to play in this fashion, then you’ve damaged your ability to develop the quality of software that, ironically, your clients would really love you for.

As Douglas Adams once said, “I love deadlines. I like the whooshing sound they make as they fly by”. Other than the detailed specification, never has a more comprehensive pack of lies been produced than the software project schedule. They don’t all start out that way, but arrive there via a collective negotiation of errors. Amongst the bottomless pit of reasons why schedules are so difficult to get right are the yin and yang of incorrect estimations:

  1. You are fundamentally scheduling invention and
  2. There is heavy pressure to keep the duration and costs low

The first one is obvious: unless you are purely assembling simple parts, then your estimate is, at best, going to be an educated guess based on your experience. The second is where the pain usually comes from. Whoever is paying for the work wishes to pay the least amount possible and wants the project delivered as fast as possible, which is only reasonable given that money doesn’t grow on trees and nobody likes been bent over a barrel for a thorough ripping off. This creates an enormous amount of pressure to take your first best-guess schedule and shrink it in order to make everyone happy.

The problem was that you were already 50% out with your estimate and any further shrinkage is going to make a bad situation even worse. It’s like receiving a punch in the face whilst being kicked in the balls. Let’s visualise the problem using one of the scheduler’s best torture tools, the Gantt Chart!

Schedules

You see that red bar? Unless it's in your spare time, that never gets done, regardless of its benefit. Irregular Pigeon is here to point out just how irregular this should be. Little does he know, eh?

If you’ve been involved in software development then this might have given you a cold chill of familiarity. Note from the overflow that there is a substantial miss, usually by at least 50%. If you work at a games company and you’re not towards the top end of the chain o’ command, then this massive schedule overrun is usually compressed at your expense using the medium of “crunch time”. This genius process is where employees are guilted into working shudderingly long weeks (80 hours plus are not unknown) for months (often without any additional pay) in order to cover up for management’s piss-poor, over-optimistic scheduling, under resourcing or whatever else contributed to the error. Of course the full blame is assigned to the technical people who were pressured to deliver such outrageous estimates in the first place when, in fact, they probably only deserved a third of the blame for not realising why their estimates are grade-A bollocks:

  • Gantt Charts encourage a task oriented rather than problem oriented schedule. It is utterly impossible to describe the entire problem’s task list in advance of doing it
  • Your client’s specification is a variable, not a constant. This variable is tweaked by them and you. They change their requirements as they learn and you change the requirements as you learn – it is part of being smart enough to change to meet changing needs. This will absorb most of the rest of the contingency. The act of doing clears the mists
  • Things never go right all the time. Half of your contingency will be used by things that you could never possibly have predicted and many will be totally out of your control (what’s that? Another massive incompatible SDK update?)

The approach I like to believe that I take is the Scotty Approach1. I am asked how long something takes, I estimate then I double it. That way, when I am inevitably talked down, I can remove a smidgen of the contingency and still have time to exceed everyone’s expectations and deliver on time. This would not have worked for me twenty years ago because I did not have the experience to make any of these estimates accurately. Now, though, generally I have the knowledge to schedule invention without being light-years away from reality (even if those schedules are generally ignored). Even with this approach, there isn’t much room to manoeuvre. The actual formula I use to turn an estimate into something half-accurate is this:

  • Create best possible estimate, let’s call this X.
  • Multiply X by 1.5.
  • Then add another 10% for good measure and round up to the nearest month.

Example: you estimate that a piece of software is going to take 12 months to develop. X = 12. Now multiply by 1.5 leaving you with 18. Now add 10% leaving you with a shade under 20 months and round up to 20. Crikey! 20 months! But it’s surely only a 12 month project! No, no it isn’t. It’s a 20 month project when you add everything else in.

Total time = ((estimated time) x 1.5) x 1.1)

Ok, you can simplify this formula but I prefer to see it broken down like this. The 50% is all the extra stuff that you and the client didn’t consider at the outset. It’s the stuff that was forgotten and the stuff that becomes important as the project develops in order to deliver something that is suitably excellent. The 10% is the contingency. To be honest, I’d like it to be 20% as it’s genuine extra time that dictates the quality of the cake’s decoration. It also provides proper time to review and test the software — something which is usually the first thing to get cut.

The net result with my normal formula is that if it is stuck to, you deliver high-quality software on time and on budget and are in a position to exceed expectations of all stakeholders whilst delivering excellent value for money… so long as you are a half decent developer.

Then, sometimes, despite all your experience you make one or both of these errors:

  1. You agree times and budgets without a decent or full specification: the “gentleman’s agreement error”
  2. You end up quoting X, or worse still, slightly less than X under immense pressure to reduce time and cost

Either way, you are now set up to crash and burn. You end up delivering the full formula’s worth of work, but you can usually only bill for less than half of any over-run, if at all. Professional pride ensures that you run it out to the line but the lateness is a cross you bare: further projects will inherit the bad estimates and you run the risk of being locked into a continual nightmare of under billing for increasingly large amounts of work.

All words, no answers

I have no idea what the answer to this is. Unless you’re EA squeezing out another iteration of one of their evergreens or are in such a position that you can simply say “this will take as long as it takes”, then scheduling is always going to be a tough exercise in educated guesswork: travel past the mysterious specification of incompleteness, through the woodland of over-optimistic estimates and then wade knee-deep in the swamp of unrealistic expectations. The larger, more evolved, better resourced companies can mitigate and control the risks through process: proper change-control and staff who’s job it is to deal with all this stuff. Whilst you procedure your way out of a whole stack of creativity, you do create a situation where slippage is minimised and controlled with the added bonus of potentially being able to avoid it altogether by simply managing the situation professionally. For the small or individual developers this kind of management overhead is simply unrealistic: you either do the work or manage the work but you can’t do both effectively without some compromise somewhere.

I make the scheduling mistake all the time. I ignore my gut feeling, bow to pressure and agree to schedules that are going to be tough to achieve. That isn’t to say that they can’t be achieved, but I condemn myself to additional work either paid or unpaid that should be spent rocking backwards and forwards in a hammock with a gin and tonic in one hand and a good book in the other. Take a look at my independent iPhone game: I’ve already ignored my own formula for calculating its duration. It should be a seven month project but fortunately, I don’t care. It’s for the fun so whether I deliver it or not is not really the point but I accept that I am a special kind of hypocrite for lecturing on the subject of bad scheduling decisions whilst making those bad decisions.



Why task-orientated, tight schedules for games don’t work 101:
Take this snake-oriented game. The snakes indicate the area of the specification that is unchanged. Oh! What’s that? Giraffes? That’s right. Turns out that adding vertical snakes with giraffe patterns on them made a better game: but not a single giraffe existed in the documentation when the project started. The original task-oriented tight schedule contained less than half of the tasks that were eventually implemented. Thus, it was whoppingly out from the start. This is on-going specification dilution. It’s normal. It’s good. It shows you’re smart enough to not flog dead horses: fail to build this into the schedule and terrible things happen with milestones. They end up like concrete boots.

Personal hatchet job aside, though, “accurate” scheduling is done only if the parties involved accept that;

  1. the up-front knowledge of the scope of the project will be under by a good 30%,
  2. the act of doing will change the project scope,
  3. scheduling by detailed individual tasks is doomed to failure,
  4. unexpected surprises are so normal that they’re really expected surprises,
  5. testing always takes longer than anticipated and needs to be factored in as a continuous process and finally,
  6. you’ll still need contingency to experiment, learn and try: schedule this out, you lose the little touches that allow your solutions to really stand out

To spot the expert, pick the one who predicts the job will take the longest and cost the most”

For the work that pays the bills, though, pressure to deliver is high and over the years I’ve delivered a shocking amount of work that I am not able to charge for for one reason or another. Other than being truly independent financially, it is difficult to place yourself in a position where you can quote realistic times and budgets without someone else being prepared to undercut you knowing that they won’t deliver, but figuring that getting their foot in the door is more important than delivering quality. Winning contracts by quoting the least amount of time normally means that QA and contingency have been scheduled out of a schedule that was probably already utter fiction anyway.

Quality, well structured, reliable software development is hard to come by. Endless warranties that stretch to infinity are even rarer. It surprises me that the impression is that this stuff is easy to do – it is not. Quality, as it does in all areas, comes at a cost. That is not to say that there isn’t a sliding scale of value, but it’s amazing to me that so many people expect first class service for third-class costs.

In the meanwhile, though, yeah, sure: I can shave a couple of months off that schedule…


1 I say “like to believe” because this ideal situation exists purely in my dreams. I dream that I estimate it’s a year’s work, quote two years and they say “OK, Mr Cobras, that’s great, but we’d love it if you can do it in, say, 22 months.” I say “Yes, I can manage that” and then love, happiness and general excellence washes over the world at large.

Posted in Software development | Tagged , , , , | 11 Comments

It lives!

Night Snake

Programming-Rattle-Python celebrates development success outside his evil castle lair

Et voila, a map editor was born. It took a couple of hours longer than I expected, but I got a tad carried away with the odd extra feature or two as well as bumping into the unexpected.

Fortunately, I had the help of Programming Python (who, as you’ll note, is actually a rattlesnake, but he has python capabilities thanks to some nifty genetics) otherwise it would have taken even longer.

As a Cocoa beginner, some things that I thought would be easy turned out to be a little more challenging – and not because they were hard, but because they were different to the way I’d done things under Win32. Take mouseMoved() events. Turns out, you also need to specifically enable these babies and you need to be the first responder or jack shit happens. Thus, this:

- (void)mouseMoved:(NSEvent *)event
{
	NSPoint nsEventPoint = [event locationInWindow];
	Vector2 eventPoint(
		nsEventPoint.x, 
		GLEngine::GetInstance()->GetScreenHeight() - nsEventPoint.y);
	g_pMapEditor->MouseMoved(eventPoint);
	return;
}

Without this:

[[self window] setAcceptsMouseMovedEvents:YES];
[[self window] makeFirstResponder:self];

Equals “is it beer time, yet?”. If I was totally honest about how long those two lines took to write, we could all have a little cry. Then there was the NSSavePanel. What tripped me up here was not that it was complex to use (it wasn’t, I had it up (ooerrrr) about 2 minutes after finding it in the documentation), but that I had to extract a filename out of the darn thing that fopen() would use.

[savePanel beginSheetModalForWindow:window completionHandler:^(NSInteger result)
    {
    if (result == NSFileHandlingPanelOKButton) 
        {
        // Close panel before doing anything:
        [savePanel orderOut:self]; 
        g_pMapEditor->SetFileName([[[savePanel URL] path] fileSystemRepresentation]);
        g_pMapEditor->SaveMap();
        }
    }];	

That innocuous little line that calls the SetFileName() function in my map editor class took a whole whopping hour to solve at about 7AM yesterday, and I think we can all agree that 7AM is an inappropriate time to be programming at all let alone suffering over something that should be unbelievably easy. Still, now I know, so it will be easy for my other projects.

The final thing that really kicked me around was scrolling a NSOpenGLView using scrollbars on a window. I use OpenGL to provide my 2D display since I stole the whole engine, give or take a poke here and a twiddle there, from the iPhone game. Plus, I have a decent library of functions for drawing stuff. Mere words cannot describe how frustrating this bit was: it’s one of those things that you either know, or you do not. Looking it up isn’t enormously helpful either as you have to draw from many examples to finally get working code particularly as everyone’s individual problem was slightly different: some were scrolling 3D views, some wanted scrolling to adjust the display beyond scrolling, others wanted a window resize to scale the image and so it goes. Ultimately, it involved taking offset information from the NSScrollView:

NSRect clipViewRect = [[scrollView contentView] bounds];
const float leftOffset = clipViewRect.origin.x;
const float topOffset = clipViewRect.origin.y;

And feeding that into the glOrtho() call correctly later on after clearing the colour buffer:

glOrtho(leftOffset, leftOffset + viewPortWidth, 
	topOffset + viewPortHeight, topOffset, 
	-1.0f, 1.0f);

It’s always amusing to note that the final answer is actually bloody obvious when you see it. I still have an annoying problem where the vertical scrollbar scrolls “upside down” because I insist on being an awkward bastard and specifying that -1.0f in the glOrtho() call above: it makes the origin top-left rather than bottom-left. This is because it’s what I am used to and I pay the price all the darn time. Perhaps it’s time to let the bottom-left-ness of OpenGL to wash over me…

Still, the final spanner almost wrenched from the application’s cogs and gears, I was creating levels!

Map Editor Demo

Temporary graphics a-go-go! Still, I remember when it was all fields around here.


Obviously these are not the game’s graphics. These are some random blocks I knocked up in Seashore, a free open-source art package. I’d eat an entire nest of ants if I could get Paint.NET on the Mac. As much as I appreciate the fact that I have a free art package that’s fine for the odd cut-out-type-thing, this was the best I could do in thirty annoying, frustrating minutes. It’s based on GIMP, I understand, which is probably why it has more issues than I did when I was a teenager in the 80s. It’s almost as if someone specifically set out to irritate the hell out users. Perhaps I should dust off the wallet and actually consider purchasing something in order for Cobra Art to thrive as it deserves to.

The editor is workable now in that as of last night I’ve successfully created a level with it and loaded it into the iPhone game. There is still much to do, though:

  • Better block choice with visual representation
  • Operation IDs from a nice drop-down combo
  • Neater UI and on-map display of game-play flags and operation IDs
  • Show animating blocks on the main display
  • Entity placement and behaviour specifying (still manual at the moment)
  • Parallax editing: those radio buttons you see are in the GNDN1 category

All in, a day or two over the coming month will yield a pretty good editor, I reckon. Now, if I can just find a victim volunteer to use it, all will be well! And let’s face it, we’ve all learnt something about scheduling today: add at least 50% to every estimate you make and you’ll still be wrong.

On the bright side, it’s pub lunch day today for no reason other than the day begins with a “W” and the weather is excellent. Still, I can bask with a pint knowing that the update report for May won’t look nearly as grim as April’s, eh?.


1 Goes Nowhere, Does Nothing. From Star Trek. Yes, that’s right, Star Trek. Honestly, this is a developer’s blog, what did you expect?

Posted in My iPhone game | Tagged , , , , , | 3 Comments

Progressing backwards through time

Empty Class

Yeah, MAKE that progress! Just 99.9% of the application to go and I'm there!

If you’ve followed the last two updates, you’ll know that in a period of ten weeks I’ve made just the odd hour or two of progress on my iPhone game. Indeed, given that most of that time is required just to figure out where I was and that the SDK keeps changing it’s fair to say that the list of things that I need to do is growing faster than I’m not clearing it. It actually feels as if I am going backwards, as though my software is un-programming itself and that soon, in a few months, the source code will reach zero bytes, remove itself from the repository and the local copy place itself into the trash can. Code germs will roam the world attaching themselves to the backups and will munch each byte into oblivion. Finally, my braiiiiin will forget that I ever started on the project and this blog will be the only record that the project even existed.

As it happens I find myself with a few extra hours today that I didn’t expect to have. Whilst there are things to do, I have decided to fit a Map Editor for the game in and around those other things. It’s extreme programming. As in “extremely over-optimistic”. Needless to say, I suspect that at the end of today I’ll come back to this post and… um… “accidentally” edit it to change this to something less grand than completing a Map Editor. If you’re reading this after the 23rd of May, perhaps it merely suggests that I’ll download the latest SDK and sort through my documentation.

Anyhoo, Mr Map Editor isn’t going to program himself, despite my hopes, so I should get cracking. As you can see from the image, I’ve not made much progress yet, but the day is young, the clouds are ominously grim and the coffee machine is on. I do, though, have a decent framework running and I have boiled the problem down to the actual Map Editor functionality itself: i.e., the next line of code I write is progress on the problem rather than preparing for the problem. Gotta love Cocoa for that — it’s insanely easy to get to this stage.

Wish me luck.

Posted in My iPhone game | Tagged , , , , | Comments Off on Progressing backwards through time

Wow… just wow

If you’re remotely into software development, you’ll have probably already have heard of this already. If you have not, you need to check it out right bloody now and bask in something that’s going to blow your socks off even if they’re glued to your feet:

My God, it RUNS

My, my, little Javascript. You have come a long way, eh?

You’re looking at Linux booting on an almost-486 CPU, that’s old hat, but this 486 is an emulation written in Javascript running in your browser1. Don’t stop with one, run many!

The mere fact that this is possible indicates that we’re heading towards another threshold moment with software development. The first one for me was when I switched – out of choice – from assembly language to C for the vast majority of my software development. Up until, oh, ’92/’93, the memory and performance hit from developing most games in C was utterly prohibitive. Indeed, for the Amiga 500 type machines, the baggage associated with using C was so vast that entire genres were utterly impossible without hand-coded, hand-optimised 68000 assembly language. 512K didn’t go far. Then, something amazing happened: the compilers got good. Whilst this was going on, target machines got faster and gained more memory. To top it off, though, processors started to get so darn complex with their fetch-execute pipeline, out-of-order execution and cache management that, well, frankly, the compilers generally did a better job than I could.

Whilst I didn’t celebrate kissing goodbye to an assembler as my primary development tool, I probably should have. Life became much, much easier when I stepped up to a higher level language. When I moved up to C++ in the naughties, things became easier once again. Now, I could manage programs of a size that I’d never before imagined with ease. Recently, playing around with Objective C and the Cocoa Apple stuff I’ve seen another step change that had managed to completely pass me by until now. Creating applications with beautiful user interfaces and rich functionality is so much easier than it was on the PC that I kept thinking “hey, it can’t be this easy, surely.” The best bit, though, was that the development tools were a sheer pleasure to use! I was up and running in no time and even when moving from major version to major version the transition has been straightforward. It’s refreshing to see that a user-interface can be completely revised and updated without using fucking Ribbons and other such witchcraft that ensures that you’ll never find anything ever again. Microsoft Word is dead to me now, dead.

Now someone has managed to emulate a complete 32 bit 386 class CPU along with the I/O hardware required to build a virtual computer. In Javascript. Yes, you heard me, Javascript. And, as all good programmers do with something cool, he turned it up to eleven and built a Linux kernel for it. So, because, like me, you’re probably thinking “not a pint of beer’s chance in my hand”, I’ll confirm what’s gone down here:

  • The latest generation of Javascript engines are incredibly fast
  • It is possible to emulate a CPU in Javascript and get half-decent performance
  • That emulated virtual CPU can run an operating system
  • He built the drivers necessary to build Linux on it, which he then did

The first BASIC program I've written in yonks. Awesome! It's like riding a bike, you never forget, no matter how hard you may try to

So check it out. It’s incredible. And because there’s nothing like infinity, I of course, grabbed the Obfuscated C contest’s DDS 1000 byte BASIC interpreter, downloaded it, fed it into Javascript Linux, compiled it and ran it. Oh yes, oh yes indeed. It works!

So let’s recap: that’s a program written in BASIC, running in an interpreter written in C in just 1000 bytes, running under Linux which is running on an almost-486 processor emulated in Javascript running in Firefox which is written in C++ running under Unix on a Mac. I think, in the most exquisite and delicious way, my braiiiiin just went “pop”. I raise my glass to Fabrice Bellard who wrote this Javascript work of art: You, sir, are a hero!

-~-

Javascript is getting faster from both ends: computers get nippier and Javascript engines get optimised. In a precious few year’s time, the list of things that you can’t do in a browser will be shrinking faster than the low-quality burgers I gave up a while back. So long as we’re able to bring up a generation of people who are smart enough to do incredible new things with this power then it’s almost time to get out the shades.

In the meanwhile, the “good riddance” department is fluffing up the cushions of despair and opening the consolation brandy of endless toil ready for Flash to turn up – and not a moment too soon.


1 This doesn’t work in Safari at the moment: Firefox and Chrome 11 are good, though. Fabrice says this is because some Javascript implementations do not yet support W3C typed arrays

Posted in Cool stuff | Tagged , , , | Comments Off on Wow… just wow

How to take over the world

1. Take over the world.

At a high enough level, everything looks easy.

Needless to say, the devil is in the detail. Have you considered where you’re going to find a tropical island with an extinct volcano to use as a secret lair? I suspect that you have not put much thought into your insane, maniacal grin. Then there is the evil laugh – a critically important component in any world domination plan. Likewise, you will be needing minions and lots of them. These minions will, of course, have to be either genetically engineered monsters or robots capable of suddenly gaining sentience for no obvious reason. Oh, and don’t get me started on your doomsday device.

Snake lair

"Do you like my new secret lair? I had to wait for the previous owner to move out, but it was worth it."
(I can't take credit for the joke, but those snakes, they're classic Cobra snakes!

I have spent quite a bit of time on my plan. Take my minions, for example. I am planning on combining human DNA with cobra and rattlesnake DNA. My goal is to create snakes with huge braaaiiiiins, cute little arms (to hold laser guns), rattles to warn people that they are doomed and a concoction of deadly venoms for which there is NO CURE! Muuuhahahahahahah! As you can see, I am pretty sorted with my evil laugh, too. But could I do it? Am I all talk, no biochemist? Well, I know a smidgen about the subject. I know what a shaker incubator is (teeheehee), I know what a PCR machine does and what one looks like (let us be precise: I know what one specific example looks like. Yours, should you have one, may be totally different). I also know that a Toll-like receptor has something to do with mammalian immune response and that there are several. TLR4 is one of them and he’s groovy! Basically, as you have probably established, I may know what I want to do but I clearly have ABSOLUTELY NO IDEA HOW TO DO IT. Fortunately, I know that the gap between desire and ability is so whoppingly broad that you couldn’t see one side from the other with the Hubble telescope.

The problem here is that whilst I can spin a high level yarn and even use some technical terms, some of which are real, I have absolutely no idea about the low-level details that would be required to actually take over the world. Sadly, I am light years from breeding my super snakes and I wouldn’t know where to start with a doomsday device (but I think it would involve something quantum related). In fact, the best I can do is ‘draw’ my lair and enjoy the odd megalomaniac dream. 

Bottom line: you and your family can sleep easily tonight safe in the knowledge that tomorrow you will not find yourself living under a cobra overlord. This is a pity. I had great plans.

I think it works by magic

But at least I know that I am woefully unequipped to go into genetic engineering. I have no qualifications in the subject, will never have any but I’m interested enough in the subject to be unafraid of learning more. This passing interest will an expert of me not make. Where someone becomes dangerous is when they think that they know more than they do – or, for ultimate grimness, if they believe that they have achieved a level of expertise that they are quite simply light-years from achieving in reality.

Computer science qualifications are one area that I have some experience in over a decent period of time: a good couple of decade’s worth. Over this period I have seen the focus shift from how things work at a low-level to simply using them. There are highly qualified people who have absolutely no idea what is going on under the hood: they have been trained as application and computer operators, not creators and innovators.

Over the years that I have been interviewing programmers, I have met many candidates who should, at least on paper, make me look like a rank amateur. They should be able to write three compilers after getting out of bed, an operating system whilst showering and still have time to fry up some delicious bacon and sausages for breakfast. Then three questions into the interview, it turns out they knew less than Mr Pretzel Snake. He is baffling himself over a complex algorithm known as ‘what is this thing with buttons on’. Soon, he will rattlerattlerattle, then slither off to find a nice cute kitten to eat.

When you claim to be an expert in C, it is not unreasonable for you to be able to write a string copy function without needing reference material. Likewise, if terms like ‘pointer’, ‘compiler’ and ‘punch in the face’ are alien to you then you know less C than Pretzel Snake, and HE IS A SNAKE. Likewise, it is damn impolite to say that you have excellent C++ skills and yet glaze over at terms like object orientation, polymorphism or inheritance. It is a little like saying “I am the best builder in the world.” Cool, so what’s this then? “I don’t know.” It’s a brick.

It is sad that modern qualifications in computing appear to be turning out increasing numbers of computer operators. Fewer and fewer that have the faintest clue how or why they work and it’s not even rocket science (indeed, a friend of mine pointed out that most rocket science isn’t rocket science, but that’s a different subject altogether). This is an incredible shame: we have a generation of graduates who can knock out a few web scripts in some crappy language that won’t be around in a decade and have the knowledge to use a bunch of applications with an even shorter life-span. These skills are generally non-transferrable and they lead to an incredible difficulty for software development companies in finding genuinely good programmers to employ.

It is not only the fault of the education system and candidates. Technology itself has advanced to the point that the apparent complexity is frightening. Computers consist of hundreds of millions of transistors on multi-layered boards with enough wiring to run from here to Scotland and back. Back in the 80s, any old fool (like me, for instance) could build a working computer from chips – it was like a really cool join-the-dots. Furthermore, computers were so simple that a whole generation of incredible software engineers were created who understood the underlying fundamentals that enabled some extraordinary innovations in software to take place. These days, you have to understand five bible’s worth of API documentation before you can even stick your bloody name on the screen.

Cars are similar. It wasn’t that many years ago that you could open the hood and point out all the major parts: that’s the horse and those are the propellers. Hell, I am no expert, but even I managed to fix several of my previous old cars when they broke down. These days, well, you can’t even recognise the horse and it’s not because he’s wearing a disguise. The whole bloody thing is one sealed unit cuddled by computers. Oddly though, the essential architecture is the same as it used to be but the days of tinkering with the gubbins under the hood are long over for your average ‘home user’. Needless to say, the young ones no longer grow up knowing how cars work and lose a valuable source of engineering and systems knowledge.

Raspberry Pie, Hmmmm… Pie…

Squid Pie

The bottom bit is the Raspberry Pi computer, from raspberrypi.org. The top bit, obviously, is the normal quality cobra art. Go squids!

And this is why I am enthused about the Raspberry Pi. This is a super simple computer that you plug a TV into one end and a keyboard into the other and pow, zing and pizazz you have a working Linux system. About 30 squids to you, gov’ner. What it doesn’t appear to solve is making it easier for programmers to start doing things rather than having to learn incredible amounts before they can crack on. In the old days, the computers booted into their programming language and you could start immediately. You could write a program within thirty seconds of powering up your computer and it would do something fun: it is thanks to this capability that I spent several years as a teenager annoying the hell out of shop assistants by knocking out little programs that they couldn’t easily stop. Some (but obviously not all) of that jerkishness wore off as I got older, but still, Raspberry Pi will be a far greater success if the folks behind it can solve that. Get programmers programming. Immediately. With less than a page of documentation. Boot the thing into a programming language and make it a good one: one that ensures that those using it gradually pick up the details of how a computer works. They will write better code as a result. Then the entire computing industry can look forward to a new generation of programmers in a decade’s time who will innovate us into a groovy future.

In the meanwhile, I’m going to make Raspberry Pie. I will serve it with ice cream. And custard. And a crushed flake.

Posted in Software development | Tagged , , , , , , , , | 6 Comments

April cactus: the weather’s dry, the schedule’s a tumbleweed

Well, play my piano and polish my sideboard, another month has gone by. Not a drop of rain has fallen and I recently saw the phrase “April Showers” pack his bags and trudge slowly to catch a bus out of here. He could be waiting some time. Anyhoo, it’s time for the second monthly progress update on the iPhone game, so, an HTML table that needs no introduction, here’s the schedule! *applause*

Estimated total project duration: 4 months with a month’s contingency
Start date: March 2010
Total progress so far: Three weeks (15%)
Total progress this month: Not a sausage
Estimated completion date: When the final atoms of the cold, dying universe are crushed back into a singularity and time crawls slowly to an lonely, dark end

Poor Dead Snake

An "artist"'s impression of how I expect to look when my iPhone game is finished

But there is a glimmer of light at the end of the tunnel that isn’t from the train coming the other direction. A very good friend of mine (who just so happens to be a rather splendiferous artist) has kindly offered to knock out a couple of little things for me that might help me imagine what the game could look like if, say, hell froze over, hot snow fell upwards, I was capable of shitting gold ingots and actually got this game finished.

Other developments of interest are that I have done a lot more Mac OSX development this month and have found the whole thing an absolute pleasure. It turns out that if you replace the UI with NS in front of most Cocoa Touch iOS classes, you end up with the OSX ones. Neat. Indeed, programming for the Mac is such a whopping delight of general niceness that I’ve realised I could easily write my level editor there. It’s kinda refreshing when you don’t have to fight with the development environment to get stuff done.

An OSX level editor would mean that the only reason I have to boot into the PC side is to use Paint .NET for my artistic masterpieces such as the the germs, irregular pigeon (who we’ll be seeing again soon in part 3 of my “how to look like you’re making more progress in French than you are” series), Darth Giraffe (I’m really chuffed with him) and the cobra family. If I can rope in one of my friends for level design, I could be on to something.

But let’s face it, May is a fantastic month: it’s the height of sprummer and I plan on getting up an hour earlier twice a week in order to make some genuine progress on the game. I feel fired up! And hungry. Quality burgers all round! Where’s the charcoal?


PS: On the subject of roaring successes during April, it would be remiss of me not to observe the stunning success of my micro-blogging exercise! YES! After a few weeks, I’ve achieved three, yes, three tweets and an incredible ZERO followers! What’s that? Yes, a golf clap is appropriate…

Posted in My iPhone game | Tagged , , , , , | 4 Comments

πr2: Burger maths

One of the many inexplicable things about me is my love for a certain brand of frozen beef burgers. For years, I have successfully ignored all efforts from all quarters to upgrade to something that could be reasonably classed as genuine food. The problem is that I kinda liked them, after all, fast food is nothing if it’s not addictive. Quality food is an acquired taste, sadly, which probably explains the bloke in the pub the other day who needed two chairs next to each other in order to be seated. The good news is that once acquired it sticks, becoming a delicious ladder of discovery out of the basement of doom towards the cheery treetops of munching pleasure.

Warm Sprummer Sun

The warm sprummer sun sets in: it's time for man to cook with FIRE!

Generally, over the last couple of years, my bad eating habits have fallen like dominoes. There are many reasons for this, but the biggest is that I would quite like to die peacefully of natural causes in my sleep shortly after my one hundred and fiftieth birthday. A diet that contains mostly utter shite is not conducive to this. The one real survivor (except a once or twice a year KFC when Mrs Cobras isn’t looking) were these damn burgers. Until now.

Quite how the burgers held out is a bit of a mystery. The evidence was there all along. Take, for example, the panicked slamming of windows that occurred all around the neighbourhood when I got the BBQ out. Now, it must be said that I am partial to a BBQ or six and one of the side-effects of BBQing low-quality products containing mostly dripping, vein clogging fat is the smoke. And, my word, the smoke… women and children staggering from the fog blinded and crying having failed to find me, the BBQ or the food. Over the years I have blamed every food product for the smoke except the burgers. That chicken, for example, smoky. Those sausages? Smoke machines. Then there are the lamb chops: they are containers of smoke. And don’t get me started on the peppers: the marines use those as smoke grenades. But the burgers? Butter wouldn’t melt in their mouths: a dictionary definition of pure innocence.

However, after being at someone else’s BBQ recently and observing that I could see the BBQ throughout the whole afternoon (and that includes factoring in the beer), I finally decided to accept the horrible, ghastly truth. My beloved burgers. It was them all along.

Like so many people, I selectively read portions of the product’s box. 100% pure beef, it said! Ok, so it could still be 100% pure beef and made entirely of bumholes and eyelids, but I decided to assume that meant the quality stuff. The sad reality, though, is much more likely to be a case of “we take only the highest quality ingredients… which we put over there, then we use all this crap left over to make your burgers.”

Since I like to invoke science wherever possible, I observed that using the formula πr2 that the surface area of the burgers halves during cooking. HALVES! That means that if I look at the burgers and think “hey, I could eat four of those” I need to double my estimates.

E-Colis

If you can't see your BBQ, you can't see if the food's cooked. These cute little e-colis might turn up!

And it is this subconscious doubling of burger capacity that resulted in me cooking way, way too many proper burgers recently. I purchased some fantastic Aberdeen Angus top-quality-complete-with-their-own-butler burgers for the last BBQ and… well, I was shocked. Firstly, they didn’t shrink at all which meant I had no space freeing up to put the lamb chops. Secondly, they actually tasted of something I could identify… oh, yes, that was it, beef.

The shrinking, of course, was the loss of fat. The fat, needless to say, was the smog machine in my garden. Quite how I did not become spherical in my 30s is anyone’s guess but I’m dead delighted that I learnt to enjoy good food and exercise before I started showing signs that large quantities of fat and sugar might actually start accumulating inside me instead of magically vanishing into thin air as was previously the case.

The best news of all, though, is that it is now possible for me to actually see the food that I am cooking. Helps prevent germs like the little e-coli chaps above. Bonus.

Posted in Miscellaneous rubbish | Tagged , , , , , | 1 Comment