Getting Ubuntu's Server edition running directly on a Mac Mini proved to be a bit of a pain, with lots of partial instructions, but with lots of important bits missed out or glossed over. And lots of stuff about the Desktop edition, which has a completely different installer.

The reason it's not yet straightforward is that Apple's intel-based kit uses EFI, rather than the older BIOS based methods. The standard GRUB and LILO bootloaders don't yet know how to deal with EFI. Grub 2, in development, will do that, but until it's released and stable we have a problem. Bizarrely, the most aggravating problem I had was when it looked like I'd bricked the machine, but it turned out the keyboard I was using was too new.

There are three basic steps:

1. Partition
2. Sort out the bootloader issue
3. Install (includes more partitioning)

Actually, 1 and 2 are quite closely linked. My first thought was that I could just wipe the disk and install Ubuntu, but the bootloader problem means that really you need to keep a Mac OS X install hanging around. The solution to the bootloader problem is to use rEFIt which provides an EFI bootloader which can hand off to another bootloader, either Apple's or Ubuntu's. You install it on your Mac OS X partition. As several people have pointed out, keeping an OS X installation around means you can continue to apply firmware updates.

A digression about keyboards

I tried to get into Apple's startup manager loader thingy (hold down option on the keyboard after the power-on bong) on the Mini, a Core Duo from 2006 or 2007, and nothing happened. I tried to boot off the CD, (hold down C on the keyboard after the power-on bong). I was trying to do this because I had used the Startup Disk preference panel to boot off the Ubuntu CD, and the installer seemed like it was hanging at the first screen. I couldn't boot into OS X, and it wouldn't boot off the OS X DVD. In a panic, I took it off the genius bar. They couldn't get it to do anything, until they tried an older keyboard. Then it was fine. By the look of things, the problem is that USB is (OS) software, and before you've booted is firmware. The older firmware didn't know how to make the newer apple keyboard work, I assume because it has different special keys and such. Fortunately I had a correct-era keyboard in the office. I guess the lesson is to make sure you always have a keyboard dating back to your oldest bit of hardware. I'd be interested to know if a bog-standard generic PC USB keyboard would have worked...

End of digression.

Partition

So, you need to keep your Mac OS X partition around. If, like me, you're wiping the computer then you can boot off the installer DVD, make a small HFS+ partiton for OS X, and leave the rest of the disc as free space. You'll need 12-15GB for Snow Leopard.

If you want to keep your existing OS X install then you can use the Bootcamp Assistant (in 10.4+), or plain old Disk Utility (definitely in 10.6, maybe in 10.5) to resize your existing HFS+ partition.

Bootloader

rEFIt is the thing to use. Download it from sourceforge, and install it on the Mini. It installs its stuff in the folder /efi, which you shouldn't delete. I needed to enable it manually, which you can do from Terminal.

cd /efi/refit
./enable-always.sh

I used enable-always.sh because I want the machine to always boot into Linux.

Reboot to check that it works. If it does, you'll see rEFIt's loader screen. If you do, you're done with this bit.

Install

Download and burn the Ubuntu server ISO. Make sure you get the right architecture - the server version defaults to 64-bit, while the desktop version still defaults to 32-bit.

Insert the disc, reboot, and you should see the CD-with-penguin icon in rEFIt. Boot off the installer. Do your partitioning, making sure to leave the HFS+ and the sooper-sekrit EFI partitions well alone. Make a note of which partition you will be installing Ubuntu on, in /dev/sdXN form (i.e. /dev/sda3). You will need it later and there is no way to find out what the correct form is at the point you have to type it in.

Install Ubuntu, and at the install-GRUB step enter /dev/sda3 (or whatever the correct place is). Once it's done that it should eject the install CD and you can then reboot. You'll have to select Linux from the rEFIt screen, and it should boot.

Always booting Linux

rEFIt has a configuration file which allows you to select, more or less, which operating system will automatically boot. It's in /efi/refit/refit.conf on the Mac OS X partition, so boot into OS X and edit it.

At the end there's a couple of sections about boot choice:

# List legacy options first. When enabled, legacy BIOS based boot options
# (e.g. Windows, Linux via LILO or GRUB) will be listed first. This is
# intended as a quick fix to change the default boot choice until full
# configurability arrives.
#
#legacyfirst

# Set the default menu selection.  The available arguments match the
# keyboard accelerators available within rEFIt.  You may select the default
# loader using a one-character abbreviation for the OS name ("M" = Mac OS X,
# "L" = Linux, "W" = Windows).  You may also specify a digit between 1 and
# 9, in which case the Nth loader in the menu will be the default.  You can
# also select a rEFIt tool entry ("S" = EFI Shell, "P" = Partitioning Tool,
# "U" = shutdown).  This is intended as a quick fix to change the default
# boot choice until full configurability arrives.
#
#default_selection L

I uncommented default_selection L and that seems to work fine for me. I imagine YMMV.

Acknowledgements

The basic outline for this came from Victor Costan's post about installing the Desktop edition, plus assorted reading of the Ubuntu wiki and rEFIt documentation. Thanks for the info.

I've been using [Selenium] [1] and [Cucumber] [2] together for a few months now, and I've really enjoyed being able to actually test the Ajaxy parts of my apps. The initial setup was a bit of a pain, and most of the tutorials I found advocated completely separate and parallel Selenium and non-Selenium Cucumber feature directories. I didn't want this, worked out a more integrated way, which changes to Cucumber have since allowed me to make even more straightforward. I'm going to assume you want to set up Selenium with Cucumber, or want to improve your setup, rather than introduce either thing.

The basic setup

Installing Cucumber and Selenium is a simple matter these days. You can follow the first couple of paragraphs from the Setting Up Selenium wiki page, which essentially amount to:

1. Install the selenium-client gem
2. Make really sure you're using the right version of selenium-client for your version of Webrat
3. Tweak your Cucumber config appropriately

I can't emphasise enough how important that second point is. If your selenium-client and Webrat gems aren't bang on you'll get the worst kind of total, baffling, failure. A simple point-update to selenium-client will be enough to throw them out. You have been warned. The cucumber wiki page above usually has the correct version numbers, although it seems to be out of date. selenium-client 1.2.17 works with webrat 0.5.3 for me.

The less basic setup

What I wanted was a way to pick out certain Scenarios from a Feature to run through Selenium to run, and not to also run those through Rails integration tests. Cucumber's tags provide a good mechanism for that, but don't solve the problem of needing to use an entirely different setup and Webrat mode. After much fiddling, I managed to get a pretty sane setup by tweaking the standard Rake tasks and using Cucumber profiles.

To cut a long story short, the selenium profile sets an environment variable that we pick up in support/env.rb and use to set the right Webrat mode, and whatever other tweaks are needed. Ben Mabey's database_cleaner gem provides a way to keep your test DB under control, since you can't meaningfully use transactions in your steps with Selenium as the app under test is running as a completely different process, and won't see anything done in any transactions you do use...

With that done, you then use the @selenium tag to mark Scenarios (or whole Features, if you want) which ought to be run with Selenium. The standard profile is set to ignore things tagged @selenium, and the selenium profile is set to ignore everything else.

To run them, I set up more Rake tasks. You can either tweak the Rake tasks Cucumber comes with to add Selenium tasks and make the standard tasks invoke the right profiles, or add new ones. I chose to tweak the standard ones so I didn't keep accidentally running the Selenium-specific Scenarios.

I've created an example rails app on GitHub, at http://github.com/fidothe/cucumber_selenium_example. Looking at that's probably the easiest way to figure out how to make it work since you have to tweak in several places. The whistlestop tour looks like this:

Cucumber profiles

The Cucumber profiles (in rails_app/cucumber.yml) I used look like this:

default:      --color --tags ~@selenium,~@wip        --format pretty
wip:          --color --tags ~@selenium,@wip:2 --wip --format pretty
selenium:     --color --tags @selenium,~@wip         --format pretty cucumber_mode=selenium
selenium_wip: --color --tags @selenium,@wip:2  --wip --format pretty cucumber_mode=selenium

It provides a default profile which ignores the @selenium and @wip tags, a WIP profile which ignores @selenium WIP features, but runs non-selenium ones, and Selenium versions of those, which ignore things which aren't tagged@selenium.

The cucumber_mode environment variable is used later to pick up that we've been asked to run with Selenium, because all the tags do is affect which Scenarios and Features are presented to be run, rather than the environment they're run in.

features/support/env.rb

I test for which mode (:rails or :selenium) Webrat should use by checking the cucumber_mode environment variable:

case ENV["cucumber_mode"]
when "selenium"
  webrat_mode = :selenium
  db_clean_strategy = :truncation
else
  webrat_mode = :rails
  db_clean_strategy = :transaction
end

I also decide which database cleaning strategy Database Cleaner should use here, using DB truncation for Selenium, and the faster transaction method with Rails' integration testing.

Scenario tagging

The final piece is to actually mark some scenarios for running with Selenium. This is just a matter of tagging the Scenario (or entire Feature) with the @selenium tag. A trivial example:

Feature: Example
  In order to demonstrate using Selenium
  As the developer
  I want one of these Scenarios to invoke Selenium, and the other not to.

  @selenium
  Scenario: Via Selenium
    When I go to the homepage
    Then I should be on the homepage

  Scenario: Not via Selenium
    When I go to the homepage
    Then I should be on the homepage

The end

Have a look at the example Rails app I put together, which is on GitHub at http://github.com/fidothe/cucumber_selenium_example. That app puts all the pieces together, and you can look back over the history to see exactly what I had to change.

I've got a longer post about setting up your Cucumber/Selenium environment coming, but since this is a hot issue I'd thought I'd address it. In short: There's a problem running the firefox.sh script on Mac OS X 10.6, which is the definitive way for things to invoke Firefox. Selenium RC runs firefox.sh to run tests, and Cucumber in turn uses Selenium RC. The result is that if you use Cucumber with Selenium and upgrade to 10.6, all your Selenium tests fail. The problem is detailed in Firefox's Bugzilla bug #513747 and Selenium's bug SRC-743. After a bit of poking about, I found a workaround. It's not great but it does get you going again...

The bug is that the Firefox runner script sets the environment variable DYLD_LIBRARY_PATH which causes Firefox's version of SQLite to override OS X's, which causes the crash. The solution is to get Selenium to invoke Firefox without setting that environment variable. You don't seem to be able to invoke the Firefox binary directly, because it crashes with the same error. I got it to work using a wrapper script:

#!/bin/sh

/Applications/Firefox.app/Contents/MacOS/firefox-bin $@
exit $?

Next, you need to tell Selenium to use your wrapper script. I use Cucumber (through Webrat) to define and run my Selenium tests, so this next bit is Webrat-specific.

In your Webrat configuration (usually features/support/env.rb with Cucumber) in your Webrat.configure block you need something like:

Webrat.configure do |config|
  config.mode = :selenium
  config.open_error_files = false # Set to true if you want error pages to pop up in the browser
  browser_key = "*chrome"

  # special browser script iff we're running on Snow Leopard
  browser_key = "*chrome ./script/selenium-firefox" unless (`uname -a` =~ /Darwin Kernel Version 10/).nil?

  config.selenium_browser_key = browser_key
end

I use a test on the result from uname to figure out if we're on Snow Leopard. There may well be a better way to do that which doesn't involve shelling out. That's it - Firefox and Selenium should now successfully collaborate again.

The only caveat is that, for me at least, the Firefox instance spawned by Selenium doesn't quit after a test run. This makes it pretty tricky for use in an unattended environment (like on a Continuous Integration box). I'm keeping my CI box on 10.5 until this is properly resolved.

Having just about survived making the newspaper, enjoyed the last day of Greenbelt enormously, and spent the last couple of days recovering, I'm sat in the Brighton Dome waiting for the dConstruct fun to start, I thought it would be good to reflect on the newspaper experience. [Actually, it took me another week to get around to finishing this, but most of it was written over the dConstruct weekend.]

Firstly, we actually made it, got it to site and handed it out. That was the first critical thing, the proof that we could do it. Even better, people seemed to really like it. Really like it, actually. That's the second critical thing, the proof that it was worth doing.

The third thing, of course, was that in the possibility space of newspapers covering a three-day, very specific, slice of the internet (stuff relating to Greenbelt 2009 written over the course of the event) we only managed to occupy the slightly rubbish bit in the corner. For a first, utterly unprepared, attempt this is brilliant, since it leaves a thing which was wonderfully received space to become something far, far, better.

You can download the paper from the Greenbelt Blog article about it. James and I still have some copies of the real thing, so if you're desperate to see it, let me know.

It's harder than you think...

Well, duh.

We had two distinct sets of problems here. The first was that we'd done no prep work, because we didn't think we'd got the money to do it. As I reported before, Hewlett Packard stepped in and forced our hand. We could have done a 4-page A4 (one folded sheet of A3) mono thing, but suddenly we had the money to go the whole hog.

Leaving aside the question of the design itself, our biggest single problem was securing content. We had originally thought that there had been some people who had agreed to write guest posts for the Greenbelt blog over the festival, but we hadn't chased any of that up. We had our wires crossed, so we had to scare up the writers. Since this was a prototype paper, we had planned to rely on stuff created by people close to Greenbelt-the-organisation, using the paper, post-festival, to engage the wider greenbelter community for next year's effort (assuming there was one).

The next biggest problem was our layout work rate. Because we only had one Mac with InDesign and the paper on it, only one person at a time could work stuff up into laid-out pages. Right at the end, as the deadline loomed, this meant we didn't have time to include either late-arriving content (we had some), or planned-but-unfinished content (we had some of that).

There were really only two of us working on this, and with chasing around for content we were overstretched editorially. We really needed another body to turn the raw material for some of our ideas into text or illustrations we could hand over for layout.

Everything takes time too, and more time than you think it will. Making the photo pages was a case in point. You had to make the grid of container boxes, fill them with images and then add the correct flickr URL to the key at the bottom. This was essentially cut-and-paste-template-page, followed by dropping in picked images and URLs. It was the easiest thing we did in the paper, but even this bit took around 20-30 minutes for one page. That's a lot time when deadline is approaching, and it doesn't include the time taken to do the picture editing work to pick out the pictures, and the time to generate and check the URLs (we were using short URLs which can only be obtained via an API call, or generated from a URL template and a base-conversion of the photo ID from base 10 to base 58).

The final element was the printing. We'd spoken with Newsquest Printing, but had had to cancel our print slot with them because we hadn't been able to get the money together. I emailed them on Thursday, after they'd closed for the day, and hoped they would get my message first thing Friday and that there would be a print slot available. Lisa Carmel and David Denham at Newsquest were brilliant and we were able to negotiate our way into a print slot late on Sunday night at their plant in Oxford. David Cheetham from Newsquest's Oxford pre-press team talked me through the submission process and checked over our test pages, which was really helpful.

Planning (that we ought to have done)

I had originally planned to do a couple of days work on design prep for the paper, working up a grid, headline styles, text styles and various configurations of pages (different numbers of stories on a page, various size ad spaces, combinations thereof). I eventually spent all of Friday on this, followed by several hours tweaking over the weekend. I basically could have saved a work day during the festival, and produced a vastly better designed product, with good prep. We had a problem with equality of attribution, where stories got a byline and URL, but photos just got a URL, and a short URL at that. So, we managed to be unfair to the photographers by not mentioning their names anywhere. We could have avoided that with a solid design.

To avoid spending hours hunting for photos we used Flickr's interestingness as a measure, and because we were allowed we added Greenbelt's official non-CC licensed photos to the mix of Greenbelter-uploaded photos. The fact that Greenbelt's own photos were being uploaded regularly through the festival meant that they had a lot longer to register on the interesting scale than Greenbelters' own. In hindsight, I'm not surprised that we didn't use anyone other than Greenbelt's photos -- the effort required to dig out CC licensed ones from the mass of interesting official ones (there were half a dozen official photographers' work being uploaded to the Greenbelt account) was prohibitive given our available time. I'm not sure exactly what we could have done to prevent that (or even whether we'd want to), but I would have liked to have been able to chew it over.

We wanted to do some infographics around festival statistics (size of the site, number of people), and we only managed a silly (but very effective) site size comparison diagram. We really should have planned what we were doing in advance so that producing the charts was a matter of adding the live statistic to the right set, rather than getting a live statistic and trying to figure how to represent it and what to compare it with.

A much more detailed page plan than the one we had (which essentially said that there were 16 pages, with a photo to go on the centre spread) would have allowed us to filter, or commission, content which reflected the range of the festival's content. Our content was very words-focussed, and we didn't really cover any of the other aspects: no music, no visual arts, no performing arts, no comedy, no childrens or youth stuff, and nothing about site setup and build... I would have liked the paper to be much more representative of the whole arc of the festival.

We hadn't finalised any plans for any of the mundane practical things we needed to do once the paper had been printed, and we ended up finalising a plan to collect the papers after they'd gone to press. I drove a car to Oxford, shoved the papers in the boot, and drove straight back. We also hadn't really thought through how to distribute the papers on site once we had them. Last Orders came through for us and advertised it to their 1000+ plus audience on Sunday night, and James got the Venue Managers to agree to having papers in each of the talks, and some of the music, venues. Transport was a problem there too, and we ended up hiring a Greenbelt Taxi to drive us and 4,000 papers round site to the various venues on Monday morning.

Practicalities

I think we'd forgotten that there would be work in converting things from HTML to InDesign, and I'd certainly forgotten exactly how long it takes to lay things out, even with a solid grid and stylesheets. We ended up being bottlenecked by the fact that we only had one Mac on which we could do layout (i.e. one which had a large enough screen to work with any speed on).

Because we were only using photos with appropriate licenses from Flickr, I was able to script indesign so I could generate a Flickr short url from a picture in InDesign (as long as it was a Flickr photo whose filename hadn't been mangled). That saved important thinking time, and made attributing photos take 5 seconds instead of 5 minutes, and massively reduced the chance for error. All of these are important when you have 5 minutes before your print deadline.

I also cooked up a tiny Hpricot-using script to take HTML, make the URLs for links in it into plain text on the page, and spit the HTML back out, which saved hours of digging around in view source, and typing and retyping URLs (which is always error-prone at the best of times).

I'll stick these both up on Github when I've retrieved them from a backup.

The biggest practical triumph, and the biggest problem, we had was with the printing. The triumph was that the quality of the printing was superb. I last did newspaper stuff with the student newspaper at Reading University in the late '90s. The registration was often bad, and pictures often looked off-colour and, particularly when the registration was bad, muddy and horrid. Newsquest's printing was immaculate. The registration was perfect, the colour was great and the pictures looked amazing. I'm really, really, happy with that side of things. There was, however, a problem (and if you've seen it, you'll know about it).

The layout-to-printing-press part Newspaper printing these days is basically a human-free process. You upload some PDFs to a server, the system their puts them in order and makes plates from them. All the pre-press stuff happens before you start. We verified that we were making the right kind of PDFs on the Friday of Greenbelt. We sent files with images (always problematic) and text (fonts, always problematic), and everything was fine. So far, so good. However, if you've seen the final printed product you'll have noticed the enormous print problems on some of the pages. What happened was that we weren't told that if you leave white space at the edges of your PDFs, the computer system at the press will simply scale them so that there's no white space left. This would have been fine if we'd known about it. A simple line down one edge, or dots at the corners, would have solved it. Unfortunately our test pages had all had images to the very edges of the page, so this didn't show up when were dealing with the pre-press guys. The lesson: make sure your test pages are representative of your final output.

So, I think my top tips for doing this again:

1. Arrive with a designed, tested, well thought out, and simple page grid already made.
2. Make sure you've ironed out any potential production bugs with the printer through a set of good test pages. You don't need proper articles and photos from the event, Lorem Ipsum and photos of your dog will do provided that you try out picture file formats, fonts, space on the page, full-bleed, special file names, that sort of stuff.
3. Have enough people working on it that you can have a picture editor (if pictures are important), someone to sub stories (to make links explicit, that sort of thing), and someone to chase down stories and/or authors.
4. Have more than one Mac, split your paper up into several files accordingly. (probably one per day, or one per spread)
5. Automate everything that can be automated. You will get tired and be unable to think: automation means you don't need to think as much. (Automate it beforehand though.)
6. If you want involvement from punters, make sure that you've advertised your existence before the festival, provide information about how you'll be aggregating stuff (tags, notification to an email address, whatever), and (if you want punters' photos to be used) provide somewhere they can upload photos for free. (If it's not free, they'll almost certainly wait until afterwards which is, annoyingly, too late.)
7. Have enough people involved that you can do shifts and thus everyone involved can actually see some of the festival...

Thanks and Acknowledgements

First off, a big thanks to HP for sponsoring the paper. They've stumped up the cash to pay for the whole thing, which is really what made it possible.

A big thanks to James Governor for putting us in touch with HP.

Thanks to Ian Usher and Wilf Whitty for their help with things photographic, and to all Greenbelt's official photographers for allowing us access to their amazing stuff.

Thanks to Jenny Brown and the Media Capture team for providing us with the stills and descriptions from their videos

Thanks to Lisa, the Davids, Mark Wackrill, and the printers at Newsquest for pulling everything through at the last minute and providing us with such high-quality printing.

A big shout to James Stewart, my long-suffering co-conspirator, and many thanks to Clare for putting up with my vanishing/overwork act at the festvial.

Most importantly, thanks to all our contributors:

• Matt Burgess
• James Cary
• Elaine Duigenan
• Simon Jones
• Steve Lawson
• Stefan Metzler
• Mike Radcliffe
• Kari Stewart
• Andy Tate
• Jonathon Watkins
• Ben Whitehouse

The possibilities for this little slice of post-digitalia are enormous so, if you're at Greenbelt next year, look out. We may well have something MOAR AWESOME up our sleeves.

A couple of months back, James and Jenny thought it would be a good idea to nick Russell & Ben's Things Our Friends Have Written On The Internet for Greenbelt. There's loads of people there, and some of them write things while they're there, went the thinking. So far so good.

One of the things Greenbelt has been thinking about for the last couple of years is how to communicate what happens at the festival beyond the festival, and how to give people at the festival a glimpse of the bigger picture - the stuff they haven't made it to, the vibe, what things looked like (we have a great team of photographers creating tons of great images over the festival, not to mention contributions on Flickr from a host of festivalgoers). So, the paper seemed like a good fit. We talked with Russell, Ben, and Tom about them bringing their Newspaper club system to Greenbelt, but time, tide, and August got in the way.

We decided to do it ourselves, which is pretty much where I come in. We arranged printing with Newsquest in Oxford, and we would fund with ad sales. Which was fine, except we were a bit late in the day and couldn't sell enough ads. So, that was that. Except it wasn't. We decided to try and hire a big A3 laser printer and do a four-page A4 news sheet, except we couldn't get a straight answer on hire charges and costs and it looked like that was going to fall through to. Then we had a brainwave. James and I share an office with James Governor of RedMonk, whose clients include HP, who make printers. Maybe he could persuade them to lend us one?

It didn't look good, in fact, it looked like a dead idea. So, when I got a call from him on Thursday night (I arrived on site on Wednesday). There was no printer, he said, but Hewlett Packard would sponsor us. How did that sound? It sounded very good, actually. And when we found out what HP were prepared to offer as sponsorship we realised that actually, we could do the original newspaper! We were pretty stunned, particularly since we were on site and had given up all hope on the project. So big thanks are due to James Governor, and, of course, massive thanks to HP!

So, now, with none of the design preparation I'd originally planned to have done, without a printer, a ruler, or a layout pad, I'm holed up on site making a newspaper which is going to press tomorrow night, come hell or highwater. We'll be distributing it (for free) around site on Monday. I may not get much sleep, but it's going to be great.