This blogpost includes forward-looking statements within the meaning of Section 27A of the Securities Act of 1933 and Section 21E of the Securities Exchange Act of 1934 […] It is uncertain whether any of the events anticipated by the forward-looking statements will transpire or occur.
Google is buying Motorola, and I love how they use the small print of that announcement to say “predictions about the future might not come true”. Lawyers; don’t you just love em.
Pop-upView Separately

Hyper 0.4.1

bug

I’ve released version 0.4.1 of Hyper, my Ruby framework for small HTML websites. This release fixes a bug that stopped Hyper from serving status assets (images, javascripts, stylesheets, etc).

Install with rubygems:

$ gem install hyper

I’d love to hear feedback: check my “Hire Me” page for my email address (and if you’re wondering about the photo, it’s a bug!).

Image from staflo on Flickr

Apple Wants You For Your Wallet, Google Wants You For Your Mind

I’ve read a lot — a lot — of Apple vs Google posts over the past few years, since Android was released. So many, really, that I’ve stopped caring who has the bigger market share and who makes more money. Both companies, both platforms (iOS and Android), seem to be doing pretty well. 

But let’s not confuse the issue: Apple and Google want different things. Apple want to sell their stuff to you; Google want to sell you to their advertisers. 

The whole “what’s more important, profit or market share” conversation is pretty much irrelevant: Apple are making a ton of money, Google are reaching more people. It’s a happy (if slightly uncomfortable) arrangement for both sides. 

A Font For People With Dyslexia

Check out the demo video, which explains the theory behind the font’s design. My brother and some of my best friends are dyslexic, so this naturally caught my eye.

Hyper: A Framework For Ruby Websites

Hyper

I could have called this gem Yawf: Yet Another Website Framework. Do we really need one? I think we — or at least I — do, so I built it.

Hyper is a micro-framework that supports small, static HTML sites with some Ruby magic thrown in. Its focus is on building and launching a site fast: there’s zero configuration, no route definitions, and definitely no databases.

Why Build Hyper?

I could have used Sinatra or Rails for my personal projects, but I wanted something lighter. I wanted a framework that could take me from a standing start to a functioning website without any configuration (I’m impatient: even Sinatra’s get '/url' route definitions felt like they were holding me back).

Most importantly, I wanted the experience that comes from building something for myself.

Quick Start

$ gem install hyper
$ hyper new cool_site
$ cd cool_site
$ bundle install
$ bundle exec rackup

Your new site is now live at http://0.0.0.0:9292/.

Magic

I want Hyper to hit the sweet spot between plain HTML (no Ruby) and dynamic frameworks like Rails. Routes are automatic:

/        # maps to templates/views/index.html.erb
/about   # maps to templates/views/about.html.erb
/contact # maps to templates/views/contact.html.erb

Because Hyper does this automagically, I can just drop my content into the correct file and move on. Every URL is handled in this way, and there are no exceptions: this behaviour covers 99% of my needs, and if I want something more dynamic I can use a different framework.

Helpers

Because this is a Ruby framework, you get a helper module: 

# in lib/helper.rb
module Hyper::Helper
  def say_hello
    "Hello world"
  end
end

# in templates/views/hello.html.erb
<p><%= say_hello -%></p>

And because it makes sense to split HTML into layout and views, Hyper does just that: shared HTML lives in templates/layout.html.erb, and page-specific content lives in templates/views.

Fast Deployment With Heroku

Right now, Ruby developers have an amazing hosting service in Heroku: prices start at free and the platform supports any web app that’s based on Rack. Can you guess what Hyper is based on?

$ cd cool_website
$ heroku create
$ git push heroku master
-----> Heroku receiving push
-----> Rack app detected

Boom: your website is now on the web.

Share And Enjoy

Hyper is available on Github and via Rubygems: right now it’s is working great for me; I hope it works for you too.

Photo by phunk on Flickr

The Edge Of Space Map

Small site I build using the Google Maps API and Hyper, my own framework for small static websites on Ruby. It’s pretty self-explanatory: a map shows you which parts of the world are further away from you than space! (Hint: space is closer than you think).

Check out the site here.

Sculptural rails!
Pop-upView Separately

Sculptural rails!

Namespacing Core Extensions In Ruby Gems

If you’ve spent any time developing your own Ruby gems or libraries, you’ve probably added some custom methods to Ruby’s core classes. This post is about the best place to keep these methods.

A Contrived Example With Parrots

Here’s an example of how I might extend a core class, and then use the extended class in my code. Imagine I’m building a gem called “parrot” which takes a string and repeats the string back to the user (it’s groundbreaking stuff):

This looks good: everything are well-organised, my core extensions are kept in their own files (named after the classes they’re extending), in their own “core_ext” folder. If I want to load my extensions to Array, I know exactly where to go: core_ext/array.rb. Also I have a talking ruby parrot, which is cool.

This setup is great 90% of the time, but that doesn’t mean we shouldn’t care about the other 10%: we could run into problems when the parrot gem is used alongside another gem which also extends Array. Put simply, the issue is:

  1. Both gems extend Array
  2. Both gems keep their extensions in gem_name/lib/core_ext/array.rb
  3. Both gems use require "core_ext/array" to load their extensions
  4. When both gems are used together, that require statement becomes ambiguous

In short, when both gems work together it may not be possible to say for sure which file require "core_ext/array" will load (I’m assuming that the load path is setup to allow each gem access to the other gem’s lib folder: this is normally the case).

I think it’s worth going the extra mile (or extra few lines of code) to preempt this problem. Here’s how I handle it:

I’ve moved core_ext/array.rb to parrot/core_ext/array.rb. By namespacing the file under “parrot”, I can avoid clashes with core extensions in other gems: require "parrot/core_ext/array" will always load my core extensions (and another gem, if they’re taking the same approach, can require "other_gem/core_ext/array" to load their own extensions).

It’s a small change but one that — I think — makes for better-structured code.

The Hitch

The BBC’s Tim Weber on Microsoft’s acquisition of Skype:

The hitch: Microsoft boss Steve Ballmer will have to work hard to integrate Skype, to ensure the voice/video-over-the-internet company is not strangled by his firm’s notorious bureaucracy.

I remember when Skype was bought by eBay: I thought “there goes a great service”, but I’m still using Skype today — so I’m willing to give Microsoft a chance. But I’ve just recently had to use Hotmail, and I’m really hoping none of those UI “innovations” get hammered onto my Mac Skype client.

This is the way acquisitions work:

  1. Business A builds something cool/useful/profitable
  2. Business B sees value in business A’s service
  3. Business B buys business A

Normally this is great but sometimes that something cool/useful/profitable is a product of some unique circumstances at business A, which circumstances promptly cease to exist when business A is taken over (strangled?) by business B. Then the takeover is like picking a beautiful flower and watching it die: once you’ve got what you want, you loose it.

In all honesty, I can’t see Microsoft doing anything more with Skype than eBay did (i.e., nothing). But I’m willing to lower my standards: I’ll be happy as long as a Bing search bar doesn’t pop up every time I make a Skype call to one of my clients.