Ruby implementation of Grue

I wrote a pet Grue to play around with on IRB.

class Grue < Array
  def eat(foo)
    puts "Grue eats a #{foo}. Om nom nom!"
    self.push foo
  end

  def poop
    puts "Grue starts to strain. Out comes a..."
    self.shift
  end
  
  def barf
    puts "Grue isn't feeling very well. Up comes a..."
    self.pop
  end

  def dance!
    puts "Grue dances. The contents of its stomach jiggle around..." 
    self.sort!
  end
end

>> require 'Grue'
=> true
>> g = Grue.new
=> []
>> ['human', 'monkey', 'cat'].each { |meal| g.eat meal }
Grue eats a human. Om nom nom!
Grue eats a monkey. Om nom nom!
Grue eats a cat. Om nom nom!
=> ["human", "monkey", "cat"]
>> g.dance!
Grue dances. The contents of its stomach jiggle around...
=> ["cat", "human", "monkey"]
>> g.barf
Grue isn't feeling very well. Up comes a...
=> "monkey"
>> g.poop
Grue starts to strain. Out comes a...
=> "cat"

I hear you say,
“It extends an array!”
But also, this Grue
Is a stack and a queue!

Right, stop that! This post is silly. It started off as a nice demonstration of array methods in Ruby, but now it’s just got silly.

BBC Micro 4 Lyf

Somebody linked to this logo in an IRC channel today, and it brought back a lot of memories. So, mostly for my own nostalgia, here are a few of the ways in which I spent my time with this wonderful machine.

Repton

In this game, you played as a green-headed lizard man, finding your way through a maze of sandy material, collecting big diamond shapes, shoving boulders around and avoiding some sort of enemy alien thing.

I never quite understood the objective of the game, but the music was great.

Chuckie Egg

Chuckie Egg was a simple but addictive platformer in which you played a rotund, yellow hat-wearing man collecting eggs and piles of grain for points. Birds were your enemies: the early levels just had flightless, aimlessly wandering blue birds, and in later levels the yellow caged bird (in the top left of the screen) was released, and could fly anywhere on the screen.

What made this game so playable was the simple but smooth controls. I was very young (maybe 5 years old) when I played this game, but I easily mastered jumping onto ladders and lifts, and avoiding pitfalls.

Magic Mushroom

When I played this game, I was unaware the blatant drug reference in the name, nor did I wonder why I was playing a crazed-looking fat magenta man determined to overcome any obstacle in order to pick up the magic mushrooms.

This was a really fun platformer, with lots of interesting hazards: slippery ice, quicksand and conveyor belts to name a few. The best thing about it was the level editor. I spent hours arranging my own levels, but was unable to save them because I never had any blank floppy disks.

That’s all the games I can be bothered writing about this evening. There are many more games that I remember; they were mostly educational and not nearly as fun as those above.

Installing Ubuntu 8.10 on an Asus Eee Box

Yesterday I took delivery of a new Asus Eee Box. It came pre-installed with Windows XP, which I had no intention of using. I wanted a quiet, low-power Linux system which I could use as a headless server for various development experiments, but which could also occasionally function as an extra desktop PC. I chose Ubuntu because I had read a few success stories on forums relating to its installation on the Eee Box.

The Box

It’s a dinky piece of hardware, about the size of a slim, medium-sized paperback book. It runs extremely quietly, with no audible fan noise unless I put my ear a few inches from it. There’s an occasional faint click and whirr from the 160GB hard disk drive, but this isn’t enough noise to stop me from sleeping (unlike the 10,000 rpm Raptor drive in my main PC).

My Eee Box came with a wired keyboard and mouse, both compact and made from cheap, lightweight shiny black plastic. They’d be crap for everyday use, but I’m not going to be using them every day.

The Installation

I already had an ISO of the Ubuntu 8.10 (”Intrepid”) release candidate ready, but the Eee Box has no optical drive. Fortunately I had a 1GB USB flash drive lying around. I downloaded a copy of Unetbootin for Windows, which allowed me to create a bootable USB drive from the ISO.

After some faffing with the Eee Box’s BIOS (the bootable USB drive needs to be selected on the hard disk drives boot screen, not the boot device priority screen) I booted from my USB drive and installed Ubuntu. This wiped out the Splashtop instant-on screen, possibly because I chose to format the entire drive. For my purposes though, the Splashtop screen wouldn’t have seen much use, as I planned to leave the Eee Box running 24/7.

Everything except the wireless network adapter seemed to work straight away. There is a utility, ndiswrapper, for installing Windows network drivers on Linux systems, but ndiswrapper wasn’t installed and without network access I couldn’t use the package manager to download it. So I used my Windows PC to grab ndiswrapper-common and ndiswrapper-utils, transferred them on the USB drive to the Eee Box and installed them just by double-clicking the .deb files.

I found the Windows XP/2k wireless drivers on the Eee Box’s support CD and copied r2860.inf and r2860.sys via the USB drive too.

Then the following commands got the wireless adapter drivers installed:

sudo depmod -a
sudo modprobe ndiswrapper
echo 'ndiswrapper' | sudo tee -a /etc/modules
sudo ndiswrapper -m
echo 'blacklist rt2860' | sudo tee -a /etc/modprobe.d/blacklist
sudo ndiswrapper -i rt2860.inf

To confirm that everything had worked, running ndiswrapper -l showed the following output:

rt2860 : driver installed
device (1814:0781) present

After a reboot, the wireless adapter was working.

My Eee Box now sits on my bookshelf, running cron scripts while I sleep and acting as an SSH gateway to my network so I can check up on things while I’m out of the flat.

Don’t go to Facebook Developer Garage unless you’re a wanker

I never blogged about the Facebook Developer Garage when I attended a few months ago. So here’s an excerpt from an email rant that I found myself spewing today when asked if I wanted to return.

I don’t really fancy going again; we left early from the last one we attended.

The speakers waffled at great length about how great their ideas were, and skimmed very briefly through any mention of actual development.

Many of the speakers bragged about their own proprietary frameworks that their companies had for building the apps, and how much money it was going to make them; nobody seemed remotely interested in sharing the knowledge among other developers.

The ’showcase’ app talk was the most pointless of all. It was pure masturbation. A few powerpoint slides with screenshots of a shitty pointless film tie-in app and some user statistics; absolutely NO mention of what the actual functionality it was or how they built it.

Waste of time.

So, there you have it. Don’t waste your time, unless you’re just looking for an opportunity to show off. Nobody is interested in helping you write code. You’ll be lucky to get one slice of pizza. Sorry.

Winamp WiFi Remote

I feel like a proper life hacker this evening.

Using Arkadiusz Wahlig’s Python Winamp Control module and my own scant knowledge of Python network programming, I created a server which listens for Winamp control requests.

These requests come from Apache with mod_python, where I’m hosting a rudimentary HTML page with a few form buttons for dispatching these requests.

By pointing Safari on my iPhone to this page, I can control my music from anywhere in my flat, or indeed anywhere on the Internet thanks to Dynamic DNS.

w00t!

(The reason for the dual server approach is that for some reason the Windows messaging used to control Winamp doesn’t work in Apache’s environment, but what I can do is handle the control in a separate environment and pass the requests through a socket.)

Django

Django is “a high-level Python Web framework that encourages rapid development and clean, pragmatic design”, and this weekend I battled through the tutorial for a second time (and the first time since its 1.0 release).

My head still hurts a little, but Django is gradually winning me over from PHP. PHP is fab and quick and easy to pick up and gets simple things done quickly, but to me it is still at heart a language for little scripts embedded in HTML. I use a great PHP framework in work, but PHP’s lack of introspection places limits on how much time it can save me.

I might be being optimistic, but Django’s database API almost looks like the end of writing dynamic SQL; the end of needing to roll a new function every time I think of a different way to filter some data. The automatically generated (yet highly customisable) admin interfaces make me weep little tears of joy, because one of my least favourite parts of a big project is slogging through coding a form for every table in the database.

As if more reasons to get excited about Django were necessary, it will run (albeit after modification) on Google App Engine.

Google Chrome: First thoughts

Google is right on about how web applications suck at the moment. Or rather, the way they run on current browsers sucks. As a web developer, I don’t enjoy writing JavaScript and AJAX mash-ups: I always get the feeling that this isn’t what the technologies were intended for.

So apparently Chrome is designed from the ground up around the web applications we use today. No doubt Google has more rich web apps up its sleeve to rival and surpass Mail and Maps, and they should run much more smoothly on Chrome than other browsers. (Until the other browsers absorb some of Chrome’s under-the-hood design, that is.)

I think the interface is the least important thing about Chrome at the moment, but I don’t dislike it. In fact it makes Firefox on Windows look as old-fashioned, bloated and busy as Firefox on OS X looks compared to Safari.

Apache2, PHP5 and MySQL on Cygwin

Just for fun, I installed Cygwin on my Windows machine a few days ago. Today, I’ve got what seems to be a fully working CAMP stack—except that I’ve cheated a little bit; MySQL is the Windows binary and not built in Cygwin.

It’s been a lot of work to get this far, but it would have been even more difficult without Cygwin Ports. Getting Cygwin Ports to work eluded me for a while, until I discovered in a mailing list archive that adding Cygwin Ports’ download site (ftp://sunsite.dk/projects/cygwinports) to Cygwin Setup requires running ’setup.exe -X’ from a Windows command prompt, else verifying the downloaded setup files fails (this might be fixed in the future).

CAMPing it up

The ‘A’ in my CAMP stack is the Apache2 package available from the standard Cygwin download sites. To get Apache2 to start successfully, I had to install and run a Windows service called cygserver. I managed this by starting a Cygwin Bash shell with Windows administrator privileges, then running ‘cygserver-config’ from the shell to install the service. I’d reached my first milestone—pointing my browser to ‘localhost’ showed me the “It works!” page.

As I mentioned earlier, I cheated with MySQL. I did install the mysql package available from Cygwin Ports, which seemed to be working at first, but it didn’t stay up for long and kept restarting itself with cryptic error messages. So I used the Windows x64 installer for MySQL and I’m connecting to it via TCP on 127.0.0.1 using the default socket.

PHP5 is where Cygwin Ports came to the rescue, after several attempts at building it from source which only resulted in me getting more and more lost in dependencies which I had no idea how to resolve on Cygwin. Cygwin Ports’ version of PHP5 has a few dependencies, but thankfully they’re all available by using setup.exe. As well as installing PHP5, I needed to install the apache2_modphp5 package from Ports as the Cygwin apache2 package came with no PHP support.

Installing Ports’ version of PHP5 puts cygphp5.so in the apache2 modules directory. Running ‘cygcheck /path/to/cygphp5.so’ from the Cygwin Bash shell found some unresolved dependencies for me (I needed to install libxml2 and minires using setup.exe). Then I added the necessary lines to httpd.conf to load the PHP5 module, to recognise the .php extension and to serve index.php if a directory is requested (this is all good fun if you’ve always taken PHP support in Apache for granted).

For reasons which I don’t fully understand, once all this stuff was installed, to get it to work I had to end all Cygwin processes, run ‘<cygwin-base-dir>\bin\ash.exe’ from Windows command prompt, then run ‘/bin/rebaseall’ from ash. After starting Apache again I could finally view the output of a phpinfo() page in my browser. The only problem I noticed was a warning about timezone settings, which I solved by adding a line to php.ini to set my timezone. (Actually, I had to create the php.ini file too.)

PHP on its own might be good for learning PHP, but it’s been ages since I did any work that didn’t involve some extensions. Most obviously, to complete my CAMP stack, I needed php_mysqli (and php_mysql for good measure; both available from Cygwin Ports). I also wanted to use GD; GD itself is available from the standard Cygwin packages list, and the php-gd package from Ports let me use it with PHP. After each new installation I had to run rebaseall again.

My final milestone, for today at least, was installing phpMyAdmin. I’ve always found the wanton complexity of the phpMyAdmin config file nothing short of bizarre, but I eventually got it connected to my Windows MySQL installation, using ‘127.0.0.1′ as the host and ‘tcp’ as the connect_type. I found a couple of loose ends to tie up: phpMyAdmin complained that I had no mcrypt extension and no mbstring extension, so I installed these using Ports (and ran rebaseall again).

Conclusion

What have I gained after all this work? I’ve got an environment much closer to the LAMP I’m used to than I previously had using an all-in-one WAMP installation. I’m used to managing servers using a Bash shell, so being able to do it from the Cygwin Bash shell instead of a Windows GUI menu is great. And at the same time, without needing to dual-boot, I have all my Windows comforts close at hand.