Archive for the ‘programming’ Category
Another install-related entry. This time, I’m attempting to install the Ruby Gem, DataMapper, for a small project – a mini app for pulling S3/Cloudfront download stats for my Verbose (iTunes link) podcast. The app pulls a date range worth of logs from S3, then digests the logs, putting the relevant data into a Postgres database, so they can be mangled at will later.
I’ve installed Postgres.app on my MacBook Air, because I like the icon. I could have homebrew‘ed the database in, but since I don’t use it that often, it’s trivial to remove when bundled into the app. DataMapper has worked well for me in the past, so I’m sticking with it.
The whole reasoning behind using Postgres in the first place is that both AppFog and Heroku support it as their default SQL database. There’s no performance constraints, or scaling requirements here, since this is just a tiny, personal app. The main technology consideration is get-out-of-my-way-and-let-me-get-this-done-for-cheap.
But there’s always something. In this case it’s installing a Ruby gem with native extensions, when the collateral for building those extensions resides in a non-default location.
Making the install work involves using bundle config, an aspect of Bundler I didn’t know about. It allows you to override the arguments to the configure execution for native gem components. You can directly override when installing a gem, or you can register an override that will be stored in your ~/.bundle directory and remembered for future use.
Here’s the incantation that worked for me, for a once-off install:
gem install do_postgres -- \
Homebrew is my go-to tool for non-App Store or prebuilt app installs on Mac, and has been for ages, just because I’ve found it easier to use than fink or macports. There’s been precious little trouble moving to mavericks, but Erlang is one item that didn’t install smoothly for me. The solution was to add a configure switch to specify a later version of OpenSSL that isn’t installed by default on Mavericks (on beta 3 at least). Right now, brew only supports extra configure switches through altering the brew formula, and I didn’t want to muck about with that.
With thanks to Steve Vinoski for some tips on the configuration of the Erlang source code build:
$ brew install openssl
will get a recent version of OpenSSL that Erlang likes. At the end of the install you’ll get a message
This formula is keg-only: so it was not symlinked into /usr/local. Mac OS X already provides this software and installing another version in
parallel can cause all kinds of trouble. The OpenSSL provided by OS X is too old for some software. Generally there are no consequences of this for you. If you build your
own software and it requires this formula, you'll need to add to your
build variables: LDFLAGS: -L/usr/local/opt/openssl/lib
The Erlang source build needs to know about that /usr/local/opt/openssl directory. Go download the Erlang source – if you are intending to install Elixir get the 16B01 version at least. Unpack the source, change into the source directory and issue the build configure like this (line breaks for legibility – paste-able version at this gist).
$ ./configure --disable-hipe
Once you’ve configured the build, you might want to skip a couple of things – for example wxWindows and ODBC
$ touch lib/wx/SKIP lib/odbc/SKIP
$ sudo make install
Check that erl has found the crypto module ok
Erlang R16B01 (erts-5.10.2) [64-bit] [smp:4:4] [async-threads:10] [kernel-poll:false]
Eshell V5.10.2 (abort with ^G)
User switch command
Now for Elixir, it’s just a matter of going back to using homebrew and all should behave as expected.
$ brew install elixir
Erlang R16B01 (erts-5.10.2) [64-bit] [smp:4:4] [async-threads:10] [kernel-poll:false]
Interactive Elixir (0.10.1) - press Ctrl+C to exit (type h() ENTER for help)
There’s been some buzz about CoderDojo in the news recently. The CoderDojo was founded by James Whelton in 2011 to introduce kids to coding at an age when they are still in school, in an environment that supports learning. With support from Bill Liao, CoderDojos have sprung up in nine locations around Ireland.
This is relevant to my interests, and I wanted to see what the whole thing was about. To get in, you need a kid, so I brought the ten year old rugby fanatic that hangs around my house and eats the food. He chose the Programming Games with Python session – no doubt wanting to fulfill his dream of getting a decent rugby game on his iPod touch at some point.
Let me digress briefly on the subject of teaching kids how to manipulate computers with software code. We use physical tools to supplement our physical selves – pushing a nail into a piece of timber with your thumb is rarely successful. We need to use computational tools to supplement our own mental computing capabilities and allow us to enhance our reasoning processes. We are already equipped to pick up a hammer, see a nail and get a fair idea what to do next, but pick up an iPod Touch and put a rugby game on it? It’s not obvious how to get there, so instruction is required. And instruction needs to be imparted early, not because we want to make more developers, not because we want kids choosing a career in coding, but because we want to give them the tools they need in the 21st century to allow them to take advantage of every opportunity that comes their way.
Back to the dojo. Our host Eugene had his work cut out for him: 25 or more young humans, with vastly different capabilities in the area, short attention spans and different laptops all around. I decided take Mr. Rugby ahead with a copy of a simple Python text game involving choosing a cave and hoping the dragon therein doesn’t eat you, taken from the syllabus book.
The programming journey went like this – at each stage we thought of a goal and massaged the existing code and added new code to get to it. The kid did all the typing, saving, running, copying, pasting. I just pointed out now and then similar chunks of code that he could reuse and got him through any blocks.
- I say – let’s extend the game from a choice between two caves, to a choice between three.
- Kid says – let’s print out which cave was which at the end of the game, so you can see which was the right one.
- We discover that strings and integers were different 🙂
- We discover that when one chooses three random numbers in the range 1..3, there’s a good chance two will be the same, and it doesn’t make sense to have a bad dragon and a good dragon in the one cave – they are territorial.
- Kid surprises me by coming up with a simple but effective way to make sure that the numbers wouldn’t clash, and we implement it – without using the modulo operator
Then we were done with where we wanted to go. Eugene was taking the kids along, helping each individually if he need to do so, and going down the same path initially, making an extra cave in the game.
But our local journey hadn’t finished after all. The kid had decided that now it was time to do some visuals and had sketched out a picture with three caves with numbers over them. Here’s where having a software savvy dad and the internet is a win: we grabbed a free pixel art program, muddled out how to use it, and while he drew the screen, I frantically researched free Python game libraries.
Aside – before we got onto the visuals, I spotted a few areas in the code to put in a couple of for loops, and suggested we ‘tidy up’ the code a bit so that I could show these and explain them. Why? was the response, the thing worked didn’t it? The important thing at this point is to shrug and agree – the lad is not a professional coder, he doesn’t need to refactor, he just needs results. In fact the whole thing needs to be results-driven. This is why you use a tool – not because it’s lovely or elegant or makes you feel special, but because you have a job to sort out. Then you put the tool down. It’s only when you get trained in how tools work can you start making your own tools. cf. lightsabre etc
Eventually I stumbled over pygame, which turned out to be just the tool we needed. We made a plan to write a small programme to try it out, and there was palpable excitement when our extremely amateurish drawing of caves popped up, surmounted by a hand-scrawled Danger!! sign.
On the way home on the train, we designed an rugby-themed 8-bit scroller for the iPod Touch and set up the kid’s github account. When we arrived home the kid insisted, with uncharacteristic determination, that we finish the Dragon game – adding keyboard control, putting in dragon graphics, conveying the result visually. Next challenge: the rugby game. Yikes!
Very little of this article has been on the details of the CoderDojo, but you may have already realized how the CoderDojo was instrumental in making this tiny but important success work. It provided us (and I write ‘us’ deliberately) a place in which learning was the norm; it provided a place where myself and himself were on the same team working towards an external goal; it provided a place that wasn’t dominated by adults. And that last one is the key one I think.
Many thanks to Eugene and the team behind CoderDojo Dublin for their commitment and patience in putting the series together, they are providing an really valuable service, on their own time.
Update: Ok, speaker notes have turned up at this point! Also, @matthutchin did a bang-up job of editing some moody video and sound of the talk into this video+slides presentation!
Update: Still no sign of the speaker notes on Slideshare – here’s a bit of ruby to grab them from the slideshow and format them into an HTML page: https://gist.github.com/968161.
This the talk I gave at the Ruby Ireland meetup last night. I think it went over well – there’s plenty of interest in the plethora of non-SQL style databases, but the problem is over population of choice and the amount of time investment required before you can make a properly informed decision. I think the best approach is to try to find as many testimonials from companies that have incorporated these newer technologies into their data storage arsenal, and read them thoroughly. These will epitomise the (fleeting) state of the art.
In an ideal world, there would be a group of volunteers running a funded lab that can create independent assessments of all the different approaches and products.
Versioning in APIs is vital if you want to control the lifecycle, rather than it controlling you. If you are using Sinatra to do routing for your Web API, then you can easily stuff all the version compatibility testing into one place – a filter – and not have to propagate it through all your routes. Follow the gist to see the code.
On May 10, I’ll be giving a talk on Constructing Web APIs with Rack, Sinatra and MongoDB at the monthly Ruby Ireland presentation gig. It will take place at Seagrass in Portobello, Dublin. Kickoff is at 7pm.
I aspire to having the talk slides up on Slideshare beforehand – this topic may be old hat to some of you hard-core Ruby types, but it’s relatively new and interesting to me, and may be so to others. In any case we’ll be looking at some new stuff, in the case of MongoDB and having some fun with it.
Bí ann nó bí chearnóg, mar a deirtear.
Hope to see you there.