We all love ruby, but sometimes ruby is not enough. Whether it be a
performance bottleneck, a killer library written in C or some
platform specific functionality you just have to have, sometimes you
need to drop down a level.
There have been many talks that show how to take the first steps in
writing a ruby C extension. This isn't one of them. I propose
instead to give an overview of different ways of extending ruby and
show what each approach brings to the table. I intend to cover
'classic' C extensions, RubyInline and FFI across a range of ruby
This is an introduction to scalable background processing in Ruby
(and Rails) applications. It discusses best practises on task
management, managing and scaling long running processes in apps
and overviews different solutions from high end of Delayed Job
to more detailed ones like Event Machine.
The talks will finish around 8pm, but that doesn't mean you have to go home. Oh no! Us LRUG folks are a friendly lot, and so we continue the evening over at The Slaughtered Lamb which is a short walk from the Skills Matter office. Do join us there if you can't make the formal talks.
A lot of importance is placed on good GUI design but it’s easy to
overlook good command line interfaces.
Taking from our experiences writing the Brightbox Cloud cli (and years
of using cli tools, both good and bad), this talk will show you some of
things you need to consider when designing a good cli interface (with a
focus on Ruby!).
And all this without turning to ncurses!
DTrace + Ruby
Anuj Dutta has been poking about with DTrace, a performance analysis and troubleshooting tool, and wants to talk to us about it. He describes his talk as "An introduction to DTrace and it's current state in the Ruby world". You should care because hooks for DTrace are being added to ruby as we speak, (although they are targetting Ruby 2.0).
The formal part of the evening is usually done no later than 8pm, but that's not when we go home. We continue the meeting in a more relaxed setting at The Slaughtered Lamb. If you can't make the talks there are usually plenty of rubyists propping up the bar and arguing long into the evening about their preferred hash syntax, so please do come along!
There are so many things we take for granted writing Ruby code -
initialising hashes and arrays, doing basic arithmetic with floats and
integers, using subscript accessors for containers. Trying to do
these basic things in Objective C requires writing screeds of
Well, it's time to have another look at Objective C.
The latest version of the compiler includes some wonderful shortcuts
to make your code more concise, readable, and a lot more like Ruby. In
this talk I'll give you a whirlwind tour of these changes.
A zero-downtime deployment configuration is important for
critical systems that need to handle every request (i.e.
financial system) and lately for systems following
continuous delivery principles since there could be many
frequent deployments . This talks present a simple
configuration for zero-downtime deployments for ruby
Our talks finish around 8pm, but that's not the end of the evening. We carry on at The Slaughtered Lamb which is a short walk from the Skills Matter office. There's usually lots of conversations going on after the talks, so if you can't make the talks please do feel free to pop along for a drink at the pub.
Also, the nice folks at Yammer are sponsoring some drinks behind the bar again, so it's an even better idea to come along than usual.
Gems underpin almost every piece of Ruby code we write – and so, being
able to write your own gems is not only incredibly useful, it provides
an avenue for code reuse and open source sharing. I'll be talking about
the ecosystem around gems and the fundamentals for writing your own gem
from the ground up, plus some of the tools available to assist with
this, along with ideal approaches and best practices for gem
nil points: a talk about nothing, NULL, undefined, Maybe, and other ghosts in Ruby and beyond
nil in Ruby is neat, simple, and convenient. But it's also problematic.
It infiltrates our code, silently, until boom! 'undefined method foo
for nil:NilClass' (or - true story, there's no time to explain -
suddenly thousands of Mark Zuckerbergs).
In this talk, I take a deep dive into nil, NULL, undefined, Maybe and
other ghosts in Ruby and beyond. I want uncover important concepts that
I think are obscured by by nil's convenience. And I think nil can be so
corrosive it's worth asking why we need it at all. Can we eliminate it
completely? Can it be improved?
Sure, there are decent Ruby patterns and practices for living with nil,
and I'll take a look at them. But I'll also try to illuminate nil by
way of a vintage Soviet computer, Jainism, a billion dollars, a
Peruvian tribe, and a Victorian wooden adding machine. And, since this
is Ruby, there will some reckless live monkey-patching.
We have to be out of the venue by 8pm, but we don't stop the meeting then. We make the short walk to The Slaughtered Lamb and continue in more informal surroundings there. It's a large pub so if you can't make the first part of the meeting there'll be more than enough room for you at this second part.
Also, the nice folks at Yammer are sponsoring some drinks behind the bar, so it's an even better idea to come along than usual.
Happier deployments through gradual feature rollout
Sam Phillips is going to tell us all about feature switching:
Releasing a big change to an application, whether a large overhaul of
the UX, system migration or upgrade to the internals, can be daunting.
Will the change work technically? Will it make your users happy and
improve the desired metrics? This talk discusses strategies and
technologies you can use to gradually roll changes out to gather early
feedback and prove your assumptions. It includes in-depth looks at
some technologies available (including the rollout gem), as well as the
part that gradual feature rollout has to play within your agile
These are all true stories, most of which I've been involved in. I'll
cover experiences of products and projects of varying sizes, talk
about different solutions for different environments and, just to be
fair, I include the humiliating (character-building) mistakes I've
made along the way.
Ruby is an amazing language, it has an beautiful object model, a
concise syntax and it allows you to write functional code
elegantly. It's probably one of the most powerful programming
languages out there, yet, there are still some things it cannot
do. Let's explore those aspects because it'll open our minds to
think differently but most important, because it's fun!
The speaker-based part of the meeting finishes at 8pm, but that's not when LRUG finishes. No! We head over to The Slaughtered Lamb for the chat-based part of the meeting. Attendance at the first part of the meeting is not required if you just fancy a pint with some ruby geeks.
Frederick Cheung came back from RailsConf with two things. The first was one of the 2012 Ruby Hero awards, and the second was that he was fired up to give a talk to his local user group. Who are we to say no to a Ruby Hero? Exactly, so he's going to tell us about Elasticsearch:
> Most apps need some form of search or filtering at some point
> (even if they don't need full text). Elasticsearch is a new(ish)
> search engine built on top of Lucene with some interesting features
> that set it apart from other search engines such as sphinx or solr.
> I'll show what we've used elasticsearch for and why we picked it over
> competing solutions such as solr or sphinx.
Matt Wynne and Steve Tooke are going to give us a version of their Hexagonal Rails talk (which they'll also be giving at SRC and Goruco later this year):
The things that make Rails great in the first few weeks of a new project are
precisely what makes it hurt after a few months. Anyone who has worked on a
medium-sized Rails app will have experienced pain like:
High coupling, meaning you have to run all your tests all the time to check
Logic littered in view templates or helper modules.
Changes get more and more expensive to make, and the fun grinds to a halt.
How can you stop this from happening? And more importantly, how can you turn
around a project that’s already hit this wall of pain?
You need to pull your app away from Rails.
In this practical talk, we describe an architecture for mature Rails
applications where the framework becomes a plug-in to your application.
With hands-on demonstrations, you’ll learn how to define clear boundaries
between your application’s domain and Rails’ domain. Now Rails can stick
to doing what it does best – providing the persistence and HTTP stack –
and your valuable business logic will be in plain oldRuby objects that
are fast to test and easy to reason about.
We have to be out of the venue by 8pm, but that doesn't mean you have to go home! We wander the short distance to The Slaughtered Lamb to spend the rest of the evening chatting about the talks and what's going on in the Ruby scene in general. If there's some reason you can't make the talks, feel free to turn up at the pub and say hi.
The Garbage Collector: how does it work?
What does it mean when people speak about stop-the-world,
mark-and-sweep, generational garbage collectors?
How does ruby fare at collecting its own garbage?
What does it mean when they say 1.9.3's garbage collector has improved?
This talk will explain those concepts, what the impact of garbage
collection is on our programs, and what future could be.
This description is taken from her pull request on EuRuKo's github-based cfp. If you like her talk, or have any comments, feel free to get involved over there to let the EuRuKo organisers know that they should select it.
Dependency Injection, the Dependency Inversion Principle, and You
Tom Stuart is also going to give us a version of his EuRuKo proposal:
It's received wisdom that Ruby doesn't need dependency injection
frameworks. In this talk, I'll claim that this is at least in
part because we don't apply the Dependency Inversion Principle
properly. I'll explore the intent of the principle, its benefits
for maintainable and testable code, and show how to improve
existing code through its application.
I'll then go on to explore how to create objects with dependencies
wired in, hoping to settle the question of whether we need a framework to do this.
Tom's talk is also available for discussion on the EuRuKo gothub-based CFP. Comments, notes, etc.. should go there if you have them.
After the talks we continue the evening in The Slaughtered Lamb. If you can't make the talks, we're usually in the pub by 8pm, so you should come and join us.
dRuby stands for "Distributed Ruby" and it's one of less known Ruby
standard libraries. It is one of the first use of Metaprogramming
long before Rails. dRuby creates proxy objects which lets you to
"automagically"(In Matz's word) delegate method calls to remote objects.
While I was translating The dRuby Book: Distributed and Parallel Computing with Ruby
from Japanese to English, I had a chance to work with Masatoshi Seki,
one of the Ruby core committers and has been using Ruby since
version 1.2. I learnt a lot of interesting Ruby technique from him
and would like to share some of them with you.
Converting a Rails project from MRI to JRuby
Peter Vandenabeele want to talk to us about his experiences converting an Ruby on Rails app from MRI Ruby to JRuby:
Starting from a scaffold Rails app with RSpec and mysql/postgresl
what are the steps to get rspec to pass on JRuby:
* use .rvmrc to switch between MRI and JRuby
* switch out gems (db, server side js, factory_girl 3 vs. 2)
* require_relative => use proper load path
* using 1.9 compatible mode for new style hashes
* waiting for rspec takes longer …
* use JRuby to connect to a Java lib (e.g. HBase jar) :-)
Whatever we end up doing during the formal part of the meeting, we know it has to end by 8pm. After that we head over to The Slaughtered Lamb fore more fun. Attending the talks isn't mandatory for attendance of the pub, so if you can't make the talks you really should come along for the pub.
The nice folks at Yammer are sponsoring some drinks behind the bar, so it's an even better idea to come along.
The format on the night will be that we'll have a couple of short opening statements from the panel to seed the discussion and then get going on the discussion. The fishbowl format means that we have 5 chairs at the front, 1 of which is empty. People on the chairs can speak, and if someone from the audience wants to add something to the conversation, they can go up and take the empty chair. As soon as this happens, one of the original panelists must go and sit down.
The initial panel will be:
Stuart Eccles - Writing tests before validating the business value is pointless
Joseph Wilk - The cargo culting of TDD without considering if and why
Tom Stuart - The "fast specs" paradigm is a red herring for producing better code
Murray Steele will act as moderator, but anyone can get involved by claiming the empty fifth chair.
It'll probably be a lively debate, and we'll want to carry on after 8pm. We do this by heading over to The Slaughtered Lamb where we can continue in more informal settings. If you can't make the talks you really should come along for the pub.
As is now traditional, we devote our February meeting to lightning talks. Not just any old lightning talks either, we use the 20x20 format for the talks. Each speaker has 20 slides that auto-transition after 20 seconds, giving them a total of 6 minutes and 40 seconds in which to get their point across.
Chris Parsons: The crowd-sourced talk. One slot at these evenings is given over to someone prepared to do a talk on something that the mailing list suggests, Chris is bravely wearing that mantle this time.
This is not the running order, on the night we randomise the order of the speakers for even more fun!
With all these talks on the night, you're bound to want to chat to at least one of the speakers afterwards. Have no fear! We do that in The Slaughtered Lamb, which is only five minutes from Skills Matter's offices. We'll be there from about 8pm, so if you can't make the talks come along just for the pub bit.
Skills Matter ask that you register your attendance with them if you are coming to the meeting. There's usually plenty of space for everyone so it's not a huge problem if you don't register, we'll still be allowed in. However, it does help with arranging the room to make sure there are enough seats laid out, and it's polite (don't forget MINASWAN), so please do register.
You can also follow this meeting on lanyrd, but be aware this is not a meaningful way to tell Skills Matter you wish to attend. It's just for the lols, innit?
I'll talk about building Judge, a client side form validation gem for
Rails 3. I'll explain how I've tried to keep it lightweight and
what I learned about Rails i18n, form builders and HTML data
attributes along the way. I'll also give a brief introduction to
Travis, the distributed build system that I've been using for
The night doesn't end at 8pm after the talks though. Oh No!. We're a fun-lovin' gang so we head over to The Slaughtered Lamb to have a few drinks and continue the ruby chatter well into the night. If you can't make the talks you really should come along for the pub.