I’ve previously written some thoughts on service oriented architectures and since then I’ve wanted to explore beyond the currently accepted standard of sending and receiving JSON data over web APIs. Protocol Buffers With JSON there’s an overhead of transmitting plain-text over the wire coupled with parsing that text in your application once received. For many cases this is probably acceptable but for a large-scale distributed system this can represent a not insignificant cost in terms of bandwidth and computing resources.
Filed in "ruby"
Some common pain points seem to keep cropping up time and time again as applications grow in size and complexity: tests get longer to run deployments become a much more involved process making a small fix to one area of code can often break something in another it can be much harder to reason about the system as a whole These large, monolithic applications are affectionately known as monorails in the Rails world and the common wisdom is to start splitting up the codebase into services: to extract areas of functionality out into self-contained, independent applications which work in unison to deliver the original capability.
Since I last wrote about my experience working outside of Northern Ireland I’ve returned to the UK, turned down prospects of contract work in Belfast and have set up shop in London. Serendipity A good while back Rob and myself had discussed the possibility of London. He’d been working remotely with a company based here and due to changes in his circumstances leaving N. Ireland was a valid option. Lines of communication between the two of us dropped off for a while as a result of travel, work and such like and when I finally got caught up with him I discovered he’d already bitten the bullet and was moving over.
I’m currently sitting in Melbourne enjoying the Australian summer and a well deserved break from work. I can barely remember the northern hemisphere winter I left behind a few weeks ago. I’ve only briefly mentioned working away from home before but January past marked two years since I last worked in Belfast. The pace has been hectic at times and I’ve spent more nights in hotels than I care to recall but from my first contract in Dublin to my last in the south of England I’ve found a consistant theme: being treated with more respect, working on more interesting problems and for higher pay.
It has become common practice these days to use tools like RVM and Bundler to manage a project’s dependencies. When these pacakages are in place, getting up to speed with another project is a breeze. The Pain But how about installing these tools themselves? How about other dependant pieces of software such as databases and the like? What if they have to be compiled from source? What if they have to be installed with a package manager?
Tonight I gave an introductory talk about Sinatra at the second meetup of BelfastRuby. The Converser platform I’ve been building this last while uses a lot of Sinatra so when I was asked to give a talk about using Ruby to develop web apps without Rails it wasn’t hard to think of a subject. This was my first technical talk and apart from a touch of nerves and forgetting some of the jokes I had in mind I think things went well.
I’ve often joked about putting together an app to track my coffee consumption, such is my reputation for consuming the black goodness. Like a lot of my other personal projects, the idea had a prolonged gestation period and was finally born through a welcome spark of motivation. Crafting fine web APIs Over the past 6 months the bulk of what I’ve been doing day to day with Vigill has involved building web APIs for consumption by mobile clients.
I think I first heard the term “Rack-app” when I started using Heroku to host a couple of projects. I didn’t know an awful lot about Rack but I did know that it helped a great deal when it came to getting my Rails and Sinatra apps off my workstation and onto the web. Tonight I thought I’d have another quick look at how it works, what it takes to build a Rack-app and what information about the request is available to the handler.
Last year I started researching how CouchDB could be used for the BodyGuard web-app QA platform. Unfortunately I had to put my tinkerings to one side when some extra freelance work came in; contracting during the day and freelancing in the evenings quickly put an end to any spare time and my fitness efforts took a hit but I was only self-employed for a short while and it seemed the thing to do.
Just a quick reminder to myself on how I installed RMagick on a Debian 5.0.4 “lenny” VPS. All commands to be run as root. Build ImageMagick from source curl -O ftp://ftp.imagemagick.org/pub/ImageMagick/ImageMagick.tar.gz tar xvzf ImageMagick.tar.gz -C /usr/src/ cd /usr/src/ImageMagick-6.6.6-6/ ./configure make make install Install the RMagick Gem gem install rmagick Bingo! As an interesting aside, ImageMagick handles a lot of image formats via delegate libraries. I previously installed RMagick on a CentOS box and had to separately install TrueType fonts which were necessary for the project in question.
Background A few months ago I was tasked with migrating and maintaining a bunch of legacy Rails apps and a couple of them were misbehaving. Requests were hanging which was tying-up the front-end Apache child processes and resulting in all the web-apps on the server becoming unresponsive At the time I didn’t know what was causing the hanging requests, it wasn’t happening in a predictable manner and on the surface I had all the apps dependencies in place.
Last year I created a nano-app which attempted to answer the question, is it raining in Belfast? I was never completely pleased with it but the objective was to get something done and get it done fast, which was achieved. This weekend I’ve been tinkering with another project and hit a bit of a stumbling block getting various pieces of software to co-exist. I decided a break from the problem would be beneficial but I still wanted to have some sense of achievement from the weekend and redeveloping this app seemed a good idea.
Some time ago DW and myself had an enthusiastic conversation about logging various aspects of our electronic lives: emails sent and received, RSS feeds read, incoming and outgoing phone calls, the list goes on. At that time I’d already started tinkering with apps to track my efforts in the gym and changes in my bodyweight, I’ve used notebooks for this for years and thought it’d be interesting to have this information in electronic form.
The past while I’ve been busy providing technical consultancy to BT and haven’t had much drive to work on anything on my own time. The itch has returned the past couple of weeks though so I thought I’d see what I’ve been missing in the Rails world and in what better way than getting a basic Rails 3 app up and running. My environment was already setup for Rails 2.3.* and Yehuda Katz' post served as a guide to get me up to speed with the beta loveliness.
I’ve just released the latest iteration of hometi.me, a little nano-app I’ve mentioned before. Deliberate Practice It’s only a trivial app but I’ve a bit of free time before the start of a contract so I thought it would be good practice to redevelop it, a task I’d been ignoring for a long time. Goodbye CakePHP, Hello Sinatra The original app was put together quickly with CakePHP, a PHP-based framework I’ve used since my first paid programming gig.
At the moment I’m in between paid work and have been using my time to generally enjoy life but to also improve my skills. I’m all about the skills. As an act of deliberate practice to hone my skills with web-application development and to deepen my understanding of the Rails framework I’ve been adding to my collection of nano-apps. A while back I had an idea to develop a URL shortener just to see how little code would be required but decided the world really didn’t need another one.
Well, it only took me 2 and a half years but I finally used Rails to develop a catalogue for my DVD collection. The catalogue loosely fits in with my series of nano-apps and is hosted on movies.stevenwilkin.com. The code is publicly available on GitHub for anyone who’s interested. All’s left now is to actually use the system and fill in the details of my collection!
In my last post I considered transforming stevenwilkin.com into a Sinatra app. Well, I did it, although I’m only mentioning it now. Not only was this my first experience with Sinatra but I also decided to try using HAML for the markup and Blueprint CSS to help with the styling. If I’m going to play with a new technology why not play with a few new technologies? I found Sinatra quite straight forward: you match up a HTTP verb (eg ‘GET’) and a url (eg ‘/') with a block of Ruby and the results can be sent directly to the browser or an optional view template can be rendered.
I released my first production Rails application, hugagoth.com, last night. I first started playing with Rails over 2 years ago and it has taken me until now to take an app through from conception to initial deployment. And an interesting journey it has been. When I first started investigating Rails I had never used a web framework before and the Ruby language really confused me, but there were a few things I liked.
Last month Giles Bowkett in the trawls of his hypergraphia wrote a post on Nano-Apps, quirky one page apps which serve up a piece of trivia or answer a question like is George W. Bush still president? Previously I had put together hometi.me, a little AJAX-y app to let me know how much longer I had to go until I could leave work for the day and when a new nano-app reporting Belfast’s goodonpaper’s coffee drinking habits surfaced the bug bit me and I wanted to do something and do it quick.
To date, a lot of interesting applications have been built on top of the Twitter service with new apps being released almost daily, each one more ingenious than the last. In my spare time I’ve been tinkering with Ruby, my motivation being to learn something new and to see if Ruby lives up the hype that has been surrounding it in recent years. In conjunction with this I’ve also been experimenting with obtaining content from existing web sites and services, content being king after all.