The problem is that there are apparently issues with installing the dependencies on a box running Lion with Xcode 4.2. The following solution worked for me. I hacked it together from that StackOverflow thread as well as the Octopress Setup Guide:

1. Install RVM:

   bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)

2. Add RVM to your shell as a function:

   echo '[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm" # Load RVM function' >> ~/.bash_profile
   source ~/.bash_profile

3. Use RVM to install the latest Ruby:

   rvm install 1.9.3 --with-gcc=clang

4. …and use it:

   rvm use 1.9.3

   (This also resulted in the latest ruby gems (1.8.10 at the time of writing) being installed for me

5. Download Octopress:

   git clone git://github.com/imathis/octopress.git octopress

6. Change your current working directory to the octopress folder:

   cd octopress

7. You should get an alert from RVM, asking you if you want to trust the .rvmrc file in the folder. Respond with (y)es, and you should get an error:

   WARN: ruby ruby-1.9.2-p290 is not installed.
   To install do: 'rvm install ruby-1.9.2-p290'

   Resolved this by editing the .rvmrc file and changing its contents to read rvm 1.9.3 instead of rvm 1.9.2 (RVM will ask you to re-confirm that you want to trust the file after you've updated it.)

8. Check the Ruby version

   ruby --version

   . You should see ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-darwin11.2.0]

9. Install dependencies:

   gem install bundler
   bundle install

10. Install the default theme:

    rake install

11. To test your new blog:

    rake preview

    then hit it in the browser at http://localhost:4000

12. To learn how to deploy your site, etc., follow the links in the "Next steps" section of The Octopress Setup Guide (by the way, why have people stopped adding anchors or ids to their headings? One small id for you, one big deep link for everyone else.) :)

That's it, that should get you up and running with Octopress (and the latest Ruby–as of this writing, 1.9.3-p0), on a box running OS X Lion and Xcode 4.2.x.

One of the files in the tutorial is the package.json file for managing dependencies in the (absolutely lovely) package manager npm. When I wrote the data structure out in CoffeeScript, however, the compiled data structure wasn't valid JSON according to JSONLint (it was nested between parentheses, had unquoted keys, and a trailing semi-colon, as you can see in the code snippet.)

({
  name: "blog",
  …
});

(The CoffeeScript compiler generated the surrounding parentheses even when I used the --bare compiler flag.)

The resulting file also had a .js extension, instead of a .json extension and I couldn't find a way to change that (although there is a compiler flag to change the folder the file gets created in).

So, to cut a long story short, I just whipped up a little shell script to convert my original CoffeeScript data structure into valid JSON simply by removing the extra characters the compiler had thrown in and adding quotes around the keys. Here's the (pardon the pun) gist of it:

coffee --print --compile $1.coffee | sed '1s/^.//' | sed 's/  });/}/' | sed "s/\([^ '\"].*[^ '\"]\):/\"\1\":/" > $1.json

(Update: Thanks to Max's comment, I was able to boil down the script to a single line and get rid of the temporary files – thanks, Max!)

Not rocket science and I'm not a sed wizard so it may not be the most efficient way of doing things but it works.

So, if you want to write your static data structures in CoffeeScript and have them compile into valid JSON:

1. check out the gist
2. Save it in a file called coffeetojson
3. Don't forget to chmod +x coffeetojson to make it executable
4. Then, assuming that the coffeetojson script is in the same folder as your .coffee script containing your data structure (let's assume it's in a file called mydata.coffee), enter the following:

./coffeetojson mydata

That will create a file called mydata.json with the valid JSON version of your data structure. (I haven't tested this exhaustively at all so there's a big chance it might fail – if it does, I'll be very happy to receive your patches.) :)

Why go to all this trouble, instead of authoring JSON by hand initially? Well, because as easy as JSON is to author by hand, CoffeeScript – with its barer syntax – is simpler still. And I'm lazy! :-)

Here's hoping this helps someone out there who is as lazy as I am!

If you're Google, you decide to go it alone, implement what you want to anyway, and then tell the world that it is going to replace JavaScript.

What's the problem with Dart? Apart from the fact that it looks like a Java developer's wet dream and will possibly mean the existence of two client-side programming languages for the web, thereby confusing the heck out of anyone just coming into web programming, it's a solution for problems that mostly Google has. How many folks out there are creating Gmail or Google Docs? And what are the costs of the additional complexity of a language like Dart for people who aren't creating Gmail and Google Docs (in other words, the majority of the web?) And, instead of throwing your toys, flashing the middle finger at the rest of the web community, and going it alone, maybe the thing to do–if you believe in an open and standards-based web–is to play nice with the other kids.

Heck, can you imagine what the fallout would be if Microsoft declared, ‘you know what, we've decided that C# should be the language of the web. Today we're declaring that it's going to replace JavaScript and that every browser should implement it. We're going to start with IE10.’

Remember a time when you thought Google was good? Because it's beginning to look like the playground bully to me. Personally, I hope that no one apart from Google gives Dart–that convoluted and unnecessary ECMAScript 4++ of a language–any notice whatsoever. And here's hoping Google realize their folly before they bloat my favorite browser (Chrome) with that shite.

I just put a new iteration of the Update conference web site live, inspired by and in collaboration with designer Clare Sutcliffe. About a week or so ago, Clare – quite out of the blue – sent me an iteration on the Update site design that I absolutely adored. In organizing Update I'm wearing lots of hats at once and I couldn't do it all without the frankly humbling support and help I've been receiving from my friends.

For the past few days, I've been incorporating much of Clare's input into the site. Any implementation issues you may encounter, of course, are entirely my doing.

Here are the main points that Clare helped me evolve with the design:

• Panel overlays. Collecting all interface elements in the panels into a horizontal panel at the left. This has helped to create a much stronger grid and makes it easier to skim the site. It also leaves more space for copy and creates contrast for the section titles.
• Cleaned up the header. The old header used an image that I love and use in my presentations – the look of wonder in the little boy's face reflects the sort of magical experiences I know we – as designers and developers – can create. However, as Clare pointed out, it said nothing about the conference. The new image says mobile – which is what the conference is about. Adding the white overlay under the title helps contrast it against the photo. To this I also added a blur to the photo itself under the overlay to increase the legibility of the title and draw attention to it.
• Tidied up the ticket bar. I don't know what I was thinking when I created the ticket bar but, in hindsight, it definitely wasn't aesthetics. Clare's design cleaned that up and added another little mobile touch.
• Workshop panel backgrounds.Clare mentioned that the background on the Workshop panels just wasn't working. So I recreated them. They're much more vibrant and representative now.
• Half-size panels for the Brighton Digital Festival and Twitter visually distinguish them from the horizontally-scrollable full-size panels.
• Whitespace. The panels now have room to breathe and the whole design benefits from that.

When working on the first iteration of the Update web site I was concentrating mostly on getting the interactions working well (and across desktop, iPhone-tier, and iPad-tier devices). The second iteration brings with it a much needed visual overhaul. The third iteration will bring additional content and hopefully a few more usability enhancements. I only wish I had more time to work on the site in addition to actually organizing the conference itself.

I hope I'll get some time to go into detail on the changes between the first two iterations in a future post.

And, here's a huge thank-you to Clare – without her initiative, this update would not have been possible. I'm hugely enjoying collaborating with her on the site.

Under Snow Leopard, the following code would work (you'll find variants of this code floating around the Internets):

var cssFile = new File();
cssFile.open('w');
cssFile.write(css);
cssFile.copy(cssFilePath);

In OS X Lion, it doesn't. Instead use:

var cssFile = new File(cssFilePath);
cssFile.open('w');
cssFile.write(css);
cssFile.close();

Hope this helps the one dudette in Sweden who runs across the issue in 2013 :)

The cause: Not providing the supposedly-optional-but-not-always-optional-for-every-browser-third-argument to the addEventListener method in JavaScript.

I had:

document.body.addEventListener('touchmove', function(e){ e.preventDefault(); });

I should have written:

document.body.addEventListener('touchmove', function(e){ e.preventDefault(); }, false);

Firefox, I hate you. Love, Aral (who hasn't slept yet and it's almost 11AM) xxx

I initially thought I could record an action to do this, but the Photoshop file I have for the graphics has dozens of layers. I thought I could use the Layer comps to files… script that ships with Photoshop but – while it let me export layer comps to files – it wouldn't let me add custom actions in the middle of the process (in this case to unsharp mask the image once it was resized).

So, I thought I'd bite the bullet and write my own script. The process was surprisingly painless. Adobe have done a rather awesome job with ExtendScript. Using JavaScript, and the Adobe Photoshop CS5 JavaScript Reference (PDF), I was able to whip up a quick script that cycles through the range of image sizes I need to support, unsharp masks all the layers, then activates each layer comp in turn and saves it out to its own file.

Here's the script:

/* 
    The original files are 960x319.
    
    Image sizes to save:
    
    * 800x266 - Retina for 480x320 resolution (400 logical pixel wide panel areas)
    * 740x246 - Desktop and iPad
    * 616x205 - Retina for 320x480 resolution (308 logical pixel wide panel areas)
    * 400x133 - 480x320 resolution
    * 308x102 - 320x480 resolution
    
    The various states (each image) is in a layer comp.
    
    Process:
   
    1. Loop through the image sizes.
    -- 2. Save history state.
    -- 3. Resize to the current image size.
    -- 4. Loop through layers
    ---- 5. Apply unsharp mask
    -- 6. Loop through layer comps
    ---- 7. Save image
    -- 8. Restore the history state to return to the full-sized image.
        
*/

var docRef = app.activeDocument;

var layerComps = docRef.layerComps;
var numLayerComps = layerComps.length;
var layers = docRef.layers;
var numLayers = layers.length;

var imageSizes = [
    ["800px", "266px"],
    ["740px", "246px"],
    ["616px", "205px"],
    ["400px", "133px"],
    ["308px", "102px"]
];

var exportOptionsSaveForWeb = new ExportOptionsSaveForWeb();
exportOptionsSaveForWeb.format = SaveDocumentType.JPEG;
exportOptionsSaveForWeb.includeProfile = true;
exportOptionsSaveForWeb.quality = 70;

parentFolderPath = Folder(app.activeDocument.fullName.parent).fsName;

// 1. Loop through the image sizes.
var numImageSizes = imageSizes.length;
for (var i = 0; i < numImageSizes; i++) {
    var currentImageSize = imageSizes[i];
    var currentImageWidth = currentImageSize[0];
    var currentImageHeight = currentImageSize[1];
    
    // 2. Save the history state.
    var savedState = docRef.activeHistoryState;
    
    // 3. Resize to the current image size.
    docRef.resizeImage(currentImageWidth, currentImageHeight);
    
    // 4. Loop through layers
    for (var j = 0; j < numLayers; j++) {
       var currentLayer = layers[j];
       
       if (currentLayer.name == "Overlay") {
           $.writeln("Not going to unsharp mask the overlay.");
           continue;
       }
       
       //  5. Apply unsharp mask
       currentLayer.visible = true;
       // $.writeln("About to unsharp mask: " + currentLayer.name);
       currentLayer.applyUnSharpMask(50, 1.1, 1);
    }

    // 6. Loop through layer comps
    for (var k = 0; k < numLayerComps; k++) {
        var currentLayerComp = layerComps[k];
        currentLayerComp.apply();
        
        var documentPath = parentFolderPath + "/images/" + docRef.name.substr(0, docRef.name.length - 4) + "-" + currentLayerComp.name + "-" + currentImageWidth + ".jpg";
        var file = new File(documentPath);
        
        // $.writeln("About to save: " + documentPath);
        
        // 7. Save image
        docRef.exportDocument (file, ExportType.SAVEFORWEB, exportOptionsSaveForWeb)
    }
    
    // 8. Restore the history state to return to the full-sized image.
    docRef.activeHistoryState = savedState;
    
}

It probably won't be too much use to you in exactly its current form but you can easily modify it to suit your needs and it might just get you to start playing with ExtendScript – it's like Actions on steroids. Enjoy!

Take your favorite content slider and try this: on a Mac notebook, two-finger scroll. I'll bet my hat (easy to do when you don't wear hats) that the component will go nuts. For one thing, it will most likely be mapping your vertical scroll gesture to a horizontal scroll. I don't know who first decided that was a good idea but I think we can safely agree that it doesn't make any sense. And every content slider out there that I've encountered does this! So much so that I actually thought that you simply couldn't get horizontal scroll information from the "mousewheel".

But you can.

Here's a little example I just hacked together that demonstrates it.

It uses the jQuery Mousewheel plugin by Brandon Aaron which gives you a neat callback with the deltaX and deltaY of the mousewheel/trackpad two-finger scroll.

I've only tested this on Firefox and Chrome on my Mac and it worked on both.

So, dear content-scroller-makers-of-the-web, let's use that lovely little deltaX property to actually map horizontal scroll gestures to horizontal scrolls and leave the vertical scroll alone so that the web page can, y'know, scroll like it should.

Update: I improved the example with a nifty little compass. Nicer to look at. Not sure why I had to do that at almost 1AM but hey, enjoy!

Mark had written a blog post about how his wife finds it difficult to use some iOS apps because they do not implement a means to increase text size:

I have a particular bee in my bonnet when it comes to accessibility, my wife is registered blind and I am constantly frustrated when she is unable see things (like text on a screen) especially when I know that this is avoidable… What I don’t understand is why there is no way to change font size system wide, or why app developers don’t provide that facility. Yes I know that you can switch on zooming, but honestly – have you tried using zooming on a phone?

So I dutifully retweeted Mark's tweet – as you do – and went on battling with cross-browser issues for the site (you really get to appreciate how wonderful an experience it is to develop for a single platform when you go back to battling with cross-platform development). I also told Mark that in Feathers, you can pinch-to-zoom the tweet text in the main text view. (Goodness knows, having as custom UI as it has, Feathers has a long way to go in terms of accessibility itself.) Mark responded with: "ha! so text scaling is doable. Thanks @aral! care to explain how so others can follow suite?"

OK, Mark (and other iOS devs), here goes: it's actually really easy.

You simply create a pinch gesture recognizer and attach it to a text view. Then you adjust the font size (and hopefully persist it for next time so the user doesn't have to keep doing it every time she uses your app).

It's about as much code as it is to explain in English, so here's a snippet from Feathers:

// Create a pinch gesture recognizer instance.
self.pinchGestureRecognizer = [[[UIPinchGestureRecognizer alloc] initWithTarget:self action:@selector(pinchGesture:)] autorelease];

// And add it to your text view.
[self.myTextView addGestureRecognizer:self.pinchGestureRecognizer];

// ... 

- (void)pinchGesture:(UIPinchGestureRecognizer *)gestureRecognizer
{
	NSLog(@"*** Pinch: Scale: %f Velocity: %f", gestureRecognizer.scale, gestureRecognizer.velocity);

	UIFont *font = self.myTextView.font;
	CGFloat pointSize = font.pointSize;
	NSString *fontName = font.fontName;

	pointSize = ((gestureRecognizer.velocity > 0) ? 1 : -1) * 1 + pointSize;

	if (pointSize < 13) pointSize = 13;
	if (pointSize > 42) pointSize = 42; 

	self.myTextView.font = [UIFont fontWithName:fontName size:pointSize];

	// Save the new font size in the user defaults.
        // (UserDefaults is my own wrapper around NSUserDefaults.)
	[[UserDefaults sharedUserDefaults] setFontSize:pointSize];
}

I hope this helps and I hope seeing how simple it is to implement will mean that more developers will implement this in their apps. Thanks for bringing it to my attention, Mark.

Update: sorry everyone, the event sold out in under 24 hours but there is a waiting list you can sign up to in case anyone drops out. Thank-you all for your overwhelming interest and here's looking forward to seeing a bunch of you there in March!

Watch as Sarah Parmenter and yours truly pummel Andy Clarke and Remy Sharp in the first Geek Ninja Battle Night in Brighton this March.

It's Web vs. Native, as we explore the myriad of options open to digital creatives designing and developing for mobile devices.

Come join us for an evening of talks, debate, and drinks at the first community event organized by Geek Ninja Factory. Tickets are just £10 and already selling like hotcakes.

(Actually, they're selling like hotcakes would sell if they were tickets to this awesome event.)

Reserve your place today to avoid disappointment and possible exposure to Hungarian Hairy Hamster disease.*

* We would like to take this opportunity to inform you that you won't really catch Hungarian Hairy Hamster disease if you don't attend this event. In fact, Hungarian Hairy Hamster disease is no laughing matter and we profusely apologise for even mentioning it in the previous paragraph. We promise never to mention Hungarian Hairy Hamster disease on this blog ever again (or at least until the next post, whichever is sooner).