Tag Archives: prototyping

A simple website on Cloud Foundry

I’ve been remiss in blogging since switching job roles, so it’s about time to change that!

One of the goals of a Platform as a Service (PaaS) – like Cloud Foundry – is to enable developers to be more productive, more quickly. It’s about getting out of the way, removing the barriers and setup steps, and enabling developers to write and deploy great code as quickly as possible.

Something I’ve needed to do fairly often since starting work with Cloud Foundry is to quickly put up a “static” web site. The platform supports a number of runtimes and frameworks (Java, Ruby, node.js etc) but it doesn’t currently[1] have an runtime type of “website”. So, I can’t simply put together a bunch of HTML, CSS, images and client-side Javascript files, run vmc push, and have my site online on cloudfoundry.com – I need an “application” to serve the web content.

That’s exactly what my sinatra-static-web project does for me. I’ve found that it’s a very handy and quick template application which enables me to get simple static sites up on Cloud Foundry, and a good starting point to build out from if I want to stretch my Ruby skills 🙂

To use it, simply fork or clone the project using Git; replace the entire contents of the public directory with your HTML, CSS and JS files (with an index.html file as the main page); potentially adjust a couple of settings in the web.rb file; and vmc push the app. You can take a look at the sample site I’ve added to the app, of course… it’s just a load of junk content based on Twitter Bootstrap and with some random Lorem Ipsum-style text to fill it out.

There’s no real need to go near the code, and it is trivial at any rate – but let’s take a quick look.

# a super-trivial Sinatra-based webserver
# for static content
require 'sinatra'

# set all the settings!

configure do
  # this is arguably not necessary... 'public'
  # folder is the static content location by default
  set :public_folder, 'public'

  # optionally configure Cache-Control headers on responses
  # set :static_cache_control, [:public, :max_age => 300]

  # if using mime types not known to Sinatra, uncomment and
  # configure here (by file extension)
  # mime_type :foo, 'text/foo'
end

# serve the files!

# route to starting page (index.html)
get "/" do
  redirect '/index.html'
end

# route to custom error page (404.html)
not_found do
  redirect '/404.html'
end

The code uses the super-handy Sinatra framework for Ruby, which allows an application with multiple URLs to be defined very quickly. In this case, we simply declare a dependency on Sinatra; set the public folder as the one where the static content resides; and then create a default route, so that when a user hits our root URL / they are redirected to the index.html file. We also create an error route so that if the user hits a URL that doesn’t exist, they receive a customised but simple 404 error page (assuming that such a file exists in the public folder!).

As you can see, there’s really only a few lines of code here, and the rest is handled by the framework. I’ve commented out a couple of optional parameters that can be used if desired, but without any changes this will serve the contents of the public folder perfectly happily.

I’ve used this a few times now, for sites of varying levels of complexity – in particular the resources site I created for Cloud Foundry’s sponsorship of Young Rewired State was based on this (the source code is on Github if you want to take a look at that, too – it’s understandably extremely similar!). I was also able to use it to help a number of students who I worked with at YRS 2012 to get their sites online. More on YRS, shortly…

Just a simple little resource that you might find handy for prototyping your next web UI – you don’t even need to know Ruby, Java, or node.js to get going!

[1] … note that I’m not saying that Cloud Foundry should have or will have such a type of container in the future – but the code base is Open Source, so there’s every chance that someone will come along and add this kind of thing one day!

Update 05 March 2013: I just pushed a few changes to the app to reflect a slight change in the way Sinatra apps work on Cloud Foundry now. Use the source!

Community, telephony, and prototypes: Make-a-thon

Warning: long post! the first in a series covering some of the events I’ve attended or been involved with lately.

Background

At January’s London Internet of Things meetup, I had the privilege to hear Haiyan Zhang speak with passion about various topics, including how she had collaborated with hackspaces in Japan in the aftermath of last year’s earthquake and subsequent nuclear disaster.

It was only the first time I’d come across Haiyan, so I was surprised but delighted that she invited me to the OpenIDEO Make-a-thon this past weekend, after tweeting about events like the London Green Hackathon.

I had only a vague idea what to expect of the Make-a-thon. When I saw some of the project briefs being published ahead of the day, I knew that it would be a little different to hackathons and other tech events I’d been to in the past. The briefs spanned issues such as improving local communities, bike safety, and several supporting campaigns by Amnesty International to use technology to support human rights activities.

My initial impression that it would not be a “run of the mill” tech event was reinforced when I arrived at the IDEO offices in Clerkenwell on Friday afternoon – it was a very different crowd to the ones I typically encounter – full of product designers, makers, human factors specialists, as well as web coders and developers. I rocked up with a bunch of Nanodes and other electronics with a vague thought of doing something hardware-related, but in the event I didn’t get that far!

IDEO’s typical approach to design revolves around prototyping and directed brainstorming, and in the event we divided into 8 teams of around 6 each, with diverse skills but with common interests around the briefs on offer. Friday afternoon was spent first understanding and exploring the brief, and then rapidly prototyping a rough idea before presenting it to the rest of the group. Saturday was spent refining the idea and producing an “experience prototype” which was intended to have been tried out “in the real world” if possible.

Evolution of the “Karma Phone”

Several of the briefs interested me, but I joined the team focused on the concept of Postcode Gangs – how could we build something to develop and improve community facilities within a postcode – essentially an arbitrarily-delineated area – in London? We spent some time brainstorming ideas around what “makes” a community before needing to rapidly decide on something to build for our rough prototype.

IDEO Makeathon

“What if” – there was a ringing phone in the middle of the street – and on the end of that phone, someone who knew something, had something to offer, or who was needed something? “What if” – we could create a new local hub with current and historical information about an area, enabling people to explore and meet their neighbours?

So the first prototype of what came to be called Karma Phone involved a lamppost (named, erm, Dan!) with a phone on it, which would randomly ring as people passed by – people could call it with a need and that others could then try to address. On the other side of the lamppost (also known as, Dan’s back) we imagined a large touch display with information about current events, realtime information, historical maps, and so on.

Karma Phone – The Outcome…

The team changed overnight, as Hayley and James were not able to stay for Saturday, Lydia joined us, and Victoria could only be involved for a short time on Saturday. We weren’t all convinced that a ringing phone would be answered, that the system wouldn’t be abused, that there wasn’t a social barrier around providing home address and asking for help, etc. How could we get an actual phone into the street and ringing, too? So, Saturday morning involved some rapid rethinking of what we wanted to build!

We settled on what turned out to be a subtle evolution of the original idea – a public phone which could act as a hyperlocal information service and skills exchange.

While we were brainstorming how to hack a physical phone, run a long cable into the street, use a mobile chained to a metal box, etc etc I remembered Twilio, which I’d been following for a long time, but never had the chance to hack on in anger. Within about 30 minutes I’d demonstrated the ability to initiate calls between two users from a web page, to the rest of the team.

Karma

Steve and Dan set about implementing the web UI; Tim started working on a physical enclosure; Victoria and Lydia managed to source a real “traditional” phone handset; and I remained hard at work writing PHP to talk to Twilio.

A couple of minor wrinkles along the way:

  • network issues meant that I had to use Tim’s phone to tunnel through to my webserver’s console, since it was apparently impossible via the event wifi. Evidently IDEO had just had a network provider change, so it was just an awkward time, but I lost some time fiddling with hosting in the early part of Saturday.
  • at a certain point on Saturday afternoon, I realised that attempting to call from the Twilio web client on the iPad was never going to work… since it requires Flash. I thought of a number of workarounds, but the one that finally stuck was that we were able to use Skype on the iPad, and use the skype:// URI scheme to launch the app from the web client. It wasn’t seamless as we needed Skype credit, and also had to tap an extra “call” button in order to start the call, but it was good enough for a prototype.
  • I’d wanted to make the web app, a standalone launchable web app on iOS. Weirdly, adding the usual meta tags to the page header to instruct iOS to treat the app as standalone launchable, meant that it was no longer possible to invoke Skype from within the web UI… so I backed off from that idea. The only cosmetic issue that presented was an inability to hide Safari “furniture” like the header, but that wasn’t a big problem for a prototype.

Here’s how the final system hangs together:

KarmaPhone-overview.png

Impressive Outcomes…

I spent so long coding and tweaking on Saturday (the commented and documented code is here – ignore how short it might seem – it was an intense few of hours!) that I missed most of the physical assembly. Tim and Dan did an amazing job of creating an enclosure for the iPad and handset. It might have been made from foam board, a box folder, and vinyl, but the final result was beautiful. And most importantly – it was fully functional!

IMG_5753

We would have loved to get the prototype out on the street for public testing (I suspect none of us more than Steve and Lydia!), but time worked against us. The final experience prototype was presented as a live demo with willing audience volunteers – one example call going to an answering service, and the other redirected to the local expert on Scotch Eggs (Tim!).

I’m happy to say that Karma Phone won Best Digital Prototype at the event, and I was (apparently!) Best Tweeter. Nice accolades 🙂

So – conclusions? I really enjoyed the way we worked together as a team of very unique and different talents; and seeing the Karma Phone prototype realised so brilliantly. However, I also think the experience of the Make-a-thon was humbling… listening to the experiences of people illegally detained abroad, and seeing some truly brilliant ideas from all 7 of the other teams, was wonderful.

A huge thank you to everyone involved in the first IDEO Make-a-thon – a really unique hackday. The IDEO team in particular looked after us brilliantly, with superb facilities, a great welcome, and more-than-adequate quantities of the hacker staples (coffee, sweets, pizza and beer).

Read a full recap including information on all of the project briefs on the OpenIDEO site. There’s a gigantic set of photos from the IDEO team, and a much smaller one from me shot on an iPhone at lower quality.

Tim, Dan, Hayley, Victoria, Steve, James, Lydia – Thank You. It was a pleasure!

All of the other teams – you rocked. You did great things. I salute you!

Makers. Creativity. Learning. LEGO FTW.

It began, as these things sometimes do, with a childhood passion.

One of my earliest memories is of kneeling on the floor at the back of my bedroom making LEGO cars – it was in version 1.0 of my bedroom as I grew up, before new furniture and decoration. I must have been about 4, or 5. I had a castle, knights, some space stuff including base boards with little moulded “craters”… lots of fun as a child.

When I became a man, I put childish ways behind me.

I’d long known that many of my friends and colleagues have remained huge LEGO fans (Cerys has just blogged about her interest; Ben made some fun timelapse videos of building his Christmas present). For me, a key moment was Roo‘s 3 minute masterpiece of a paean to the medium at Interesting in 2008, embedded here for your enjoyment. Listen to the audio slidecast – closest you can get to having been there, and Roo did a wonderful (and amusing!) job.

Also, a memorable talk at the CRIM Crystal Ball Conference in Montreal in April 2010 (at which I also spoke) came from then Professor of Innovation at LEGO Group, David Robertson – a tale of Rebuilding LEGO, and how the company had saved itself from bankruptcy by refocusing on its core values and customer needs. It was a fantastic story and I was rapt.

More recently, I went along to the Internet of Things meetup in London last month, and was delighted to see Ken “monsonite” Boak – creator of the Nanode, a fantastic UK-grown prototyping platform akin to Arduino – use LEGO as his metaphor for a talk exploring Open Source electronics. Ken was kind enough to pop his slides up on Slideshare today, so you can take a look. He’d just been out to get some LEGO the previous weekend…

That talk was more-or-less the moment when I realised – I needed some LEGO. I wanted some. Both as a way of seeing where things had gone to, and to help me to prototype things, and just… well… just because! I’d already started to use dioramas featuring minifigs in a couple of presentations recently and had good feedback, so I figured that was another excuse 🙂

So, on Saturday I decided to dip back into my passion for LEGO. It started with a bucket of bricks from the nearest toy shop… but then I noticed the LEGO Star Wars sets with slight discounts[1]… and I figured well, obviously I’d need some wheels of some kind so picked up some City sets… and some of the foil-bag Minifigures…

The splurge quickly developed into a binge via a @darachennis-inspired trip to the LEGO store in Westfield White City on Sunday… picking-and-mixing bricks from the back wall, and signing up for the VIP program. There may be no hope left for me…

Celt Bucket o' bricks LEGO splurge

So what have I learned?

  • Minifigs are brilliant. The aforementioned David Robertson gave me his business card, his details printed on a minifig resembling him, in Montreal in 2010 and that reawakened my interest. When I was a kid they all had the same pair of staring eyes and identical pleasant non-threatening smile, but the range of looks and expressions now available make them as much fun to customise as the full sets.
  • People talk about the beauty of Apple’s designs – both inside and outside of the product (not that I’ve ever cracked open an iPhone to look inside). LEGO is blocky and “harsh”… but the designs and assembly process is beautiful. Assembling little cars and other sets on Saturday evening, following simple pictorial instructions, I realised that every piece had a place and it all fitted together wonderfully, perfectly. That (re)discovery had me as delighted as an adult, with a more architectural and design-oriented brain, as I was as a kid with the sheer enjoyment of being able to build and modify things.
  • In my opinion, all kids should be given some LEGO, and allowed to build the models from the boxes themselves (much though I’m sure as an involved adult I’d be itching to take over!). I’ve blogged recently about my excitement for the maker culture, and this is really where it can all begin.
  • I need to keep an eye on my bank balance, and a check on my excitement. I love it, but I bought it for “professional” reasons… 🙂

Last week, the UK Government announced that ICT courses would be replaced with Computer Science, including a programming element (one of the campaigns I’ve been passionate about). At an event from The Education Foundation in London the next day – The Future of Technology Education – I was privileged to hear one of my personal heroes Ian Livingstone (of Fighting Fantasy books, Games Workshop and Eidos fame) speak and refer to “digital Meccano” – and I owned Meccano as a child too.  He also highlighted the need to combine science and art to push the digital boundaries.

Here’s what I think: we should be giving children a choice of physical LEGO, Meccano, and other toys; encouraging their creativity and building skills; and helping them to bridge between both the digital and physical worlds. No child should be excluded, and none should be pushed down a particular path. We should be supporting and helping every child to discover their passions and explore them; recognising that not every individual will want to program, or draw, paint, build, or write – but never belitting anyone for their talents or interests.

I’ve rarely been as excited about the future than I have been right now!

[1] as a child in in the 1980s I owned significant numbers of the Palitoy Star Wars figures and vehicles[2]. Whoever thought of combining LEGO and Star Wars is a genius – so much MORE FUN than the original, inflexible, non-customisable toys. So much more interactive, and through the video games, adding a humorous new twist on the Star Wars saga. LOVE.

[2] … I never had the Millennium Falcon or the Death Star, though… always wanted those…