As Ruby web developers we all know the pain of managing client
side assets in (not only) Rails applications, especially in legacy
applications. I have had enough and that's how http://rails-assets.org
was born. The main purpose of this talk, besides spreading the
word, is to show some details of how rails-assets works and to
compare it with existing solutions
Ruby and associated frameworks are notorious for employing
magic in the name of developer productivity, especially when
building web applications. In this talk I'm going to peel
back the layers of voodoo and show you how we go from a raw
TCP socket to a Rails app via rack applications and middleware.
We'll be coving:
Very high level overview of TCP connections and a minimum
viable web server with netcat
Rack applications, middleware, and how they're typically chained
How Rails chains together rack middleware to do what it does
(i.e. tracing the code path of a request from class Railtie all
the way down to your apps controllers).
There will be live coding, so I request that you sacrifice a
llama or three in the name of the demo gods before the event.
The talks end at around 8pm, but you'll find many attendees will continue the meeting by heading to The Slaughtered Lamb. This is a great place to grab a bite to eat and a drink and discuss the talks with the rest of the attendees and the speakers. If you can't make the talks, do feel free to just turn up straight at the pub.
In the past few years robots have started to invade our lives, as
toys or tools for around the home or at work. These robots are
often much more user friendly and more importantly, hackable, than
traditional industrial robots, which has lowered the barrier to
writing software to control robots.
We'll look at one particular ruby library, Artoo, a micro-framework
for robotics that lets you connect to multiple different hardware
devices and robots at the same time with some live demos as well.
Ruby is not the first language you might think turn
to when tackling natural language processing problems.
But it has a lot of features that make it suitable
for NLP tasks and a number of gems are being actively
maintained. This talk introduces those features and gems
and discusses how you can build solutions to your
language processing problems within your Ruby-based apps.
After the talks many of us head over to The Slaughtered Lamb to continue the evening. The speakers are usually there, so it's a perfect opportunity to ask them more in-depth questions about their talk, or just thank them for their effort. If you can't make the talks, it's totally fine to just come along for this part of the meeting; we get there about 8pm.
Ragel is a State Machine Compiler, which can generate Ruby
code (as well as C, Java, Go, and more). It can be used for
writing robust protocol implementations, parsing data formats,
and performing lexical analysis of programming languages. Ragel
is used in many open source projects including Gherkin,
Radiant, and Hpricot.
To demonstrate Ragel's capabilities we'll model Vim, which is a
Finite State Machine. We'll do so by parsing a stream of Vim
keystrokes, using Ragel state machines to manage the transitions
between Vim's modes. We'll see how to generate state chart
visualisations with Ragel, and how these can be used to debug
our state machines. The resulting program will enable us to
analyse and visualise the interactions of a Vim user.
are a little known class in the standard library.
I'll discuss where they're used in stdlib, how you can
implement them and (at least) one practical example where
they might be the right solution.
After the talks the evening continues in a more informal style at The Slaughtered Lamb. It's a great place to discuss the talks directly with the speakers, or chat to other rubyists about the great debates of the day. If you are unable to make the talks, for whatever reason, do feel free to turn up for this part of the evening. We're usually jostling for space at the bar from around 8pm.
With Rails 4, Concerns have become the “official” solution
to the big-models problem. However, there's a fair amount
of controversy about this topic in the community. Not
everyone is convinced that Concerns are the “right“ solution
to the problem of AR models becoming too big.
In this talk we will see what Rails Concerns are and how can
we use them to keep our models fit. More interestingly, we'll
discuss the trade-offs of this technique, the different views
in the community and a couple of alternatives.
When a Rails application becomes a big fat monster, the moment
arrives to split it into small services that speak to each other.
I'll discuss how are we attacking this problem in a progressive,
iterative way and which tools we chose for each situation; some of
which are not limited to Ruby.
Our talks finish at roughly 8pm and we move on to The Slaughtered Lamb for the rest of the evening. This is your chance to talk to the speakers without the rest of the crowd scrutinising your questions, and to talk to the rest of the crowd without interrupting the speakers. If you can't make it for the talks, perhaps because you didn't register in time, then do turn up just for the pub bit.
Most of us have heard the vague, hand waving spiel about why
DI is important for writing flexible, reusable code, a
little harder to come by are examples of how one actually
goes about doing it in a (cost) effective manner.
Rather than a dry introduction to DI, this talk will be
packed full of code examples demonstrating practical
techniques you can start using straight away, no gems,
meta-programming or magic required. We'll also explore how
you might persuade your Rails app to benefit from DI.
When you're working in an architecture with multiple
services, there are a lot of available options for how to
communicate between them. Which do you pick?
I'll be talking about why RabbitMQ can be a great choice,
how and why we're using it here at GoCardless and covering
some of the ways we've simplified using RabbitMQ's
Topic Exchange in a ruby environment with 'Hutch'.
I'll then talk about some of the issues we encountered
around scaling and setting up multiple rabbit nodes as a
cluster, highlighting some of the potential failure points
and edge cases this brings with it and a tools we built to
make sure we had them covered.
The two talks will take us to about 8pm, at which point we move on from Skills Matter to the second venue of the evening: The Slaughtered Lamb. There's no agenda here, just visit the bar and seek out those rubyists you've been meaning to say hi to for a while. Attendance at the talks is obviously not required for attendance at the pub, so do come along anyway!
Most developers don't do ops, and though the idea of devops
is slowly permeating through the industry, it's probably
not the norm yet. So why should we, as devs, care about
configuration management? What has it done for us lately?
I'll try to explain how Chef can improve your life, even if
you never touch a production server. I'll give some
examples of ways in which configuration management can
simplify your development environment, improve your
debugging abilities, and give you a better overall
understanding of the way your applications fit together.
I'll also share some strategies for breaking down the
intimidating task of introducing Chef if you've already got
hand-configured servers, so that change can be gradual,
with progress along the way as nature intended. I'll also
mention some of the tools that make life much, much simpler.
Over the last year I’ve worked with numerous teams
implementing creative, non-standard ways to building and
I’m going to talk about them.
This will be relevant to existing teams and people
thinking of starting a team in the future. Overall I think
it will be beneficial & interesting for everyone, even if
you’re not thinking of starting your own team any time soon.
Our talks finish up no later than 8pm, but that's not the end of the evening. Most of us wander over to The Slaughtered Lamb to have a chat. You don't have to attend the talks to turn up for the pub, so please do come along!
In this talk I present a simple ActiveRecord-based alternative
to the many popular state machine gems.
Suppose you're dealing with a school application system.
Applications can be submitted, rejected, approved. Then
you would have
class Submission < StateTransition end
and so on. StateTransition is an STI subclass of
Inside each 'concrete' transition subclass, AR
validations determine whether the transition can be
created, given current system state. Callbacks make
changes to other models that result from the
transitions, as well as trigger other effects like emails.
This shifts emphasis from the models to the transitions
themselves. Model classes don't get cluttered with
logic related to multiple transitions - that logic
lives in the transition classes. It works nicely
with REST. You are literally creating an Approval,
rather than "approving". Logging of transitions is
front and center. Nobody has to learn a new lib and
you're never beholden to yesteryear's state machine
We'll finish the formal talk-based part of the meeting at about 8pm and start the informal pub-based part about 5 minutes later in The Slaughtered Lamb. If you can't make the talks, do come along just for the pub, someone can get you caught up on what happened and no-one will know you weren't there!
Also, the nice folks at Yammer are putting some money behind the bar to provide some drinks for us, so there are even more reasons to make it along!
Data Context Interaction is recently invented programming paradigm,
which aims at separating behaviour from data model, by extracting
interactions into roles, which can be played by objects in various
This presentation is going to give brief introduction to DCI,
propose ways to implement roles' injection in Ruby and discuss
how DCI could be used to supplement Rails' MVC paradigm.
While most of us know what mruby is, few of us have had a
chance to kick the tires, poke around a bit and see what
makes it tick. In this ~30 minute workshop-presentation,
we will help each other to get mruby built locally, do a
classic "Chunky bacon" test, and have a go at writing our
own rbgems to extend the language with custom functionality.
Bring your laptop, and get your hands dirty with mruby.
Randy will be sending out instructions on pre-requisites in a few days to the mailing list. Don't miss it!
The talks usually finish up around 8pm, but that's not the end of the meeting! We continue at The Slaughtered Lamb which is about 5 minutes away. Attendance at the talks is not a requirement on coming to the pub, so if you can't make it to them do feel free to turn up afterwards!
Rails showed us the power of the full-stack framework.
It was good, but some of us felt the power was at the
expense of lightness (and joy?).
Sinatra showed us the joy of simple. The bare essentials
to start working with http requests gave us back some
of the Zen of creating a codebase that did exactly what
it should and nothing more. Sadly, this Zen meant
reinventing wheels that Rails had already rolled.
Padrino came after both of these projects and the
developers learnt from them. They re-imagined the
full stack using Sinatra as a base and building from
there. Sinatra++ you might think.
I will be speaking about app deployment, good production
practices, CI and CD and app versioning (never replace a
working production app instance with a new deploy).
deliver is a single
utility to rule one's deploys to gh:pages, Jekyll, Ruby,
node.js etc, even legacy PHP code (we all have it). The
talk will also touch on S3-backed site deploys & Route53
IP failover to that S3 site.
We're a friendly bunch, so if you don't make it to the talks you can still join us for a drink afterwards. The talks normally finish up by 8pm and you can find us crowding the bar at The Slaughtered Lamb shortly after.
Also, the nice folks at House Trip are sponsoring some drinks behind the bar, so there are even more reasons to make it along!
February is our annual lightning talk evening and as usual we're using the 20x20 format for the talks. If you've never encountered this format before it's when the 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.
Once we finish up with the talks we head over to The Slaughtered Lamb to continue the evening in more informal, if admittedly slightly noisier surroundings. If you can't make it for the talks feel free to pop along to the pub for about 8pm, which is when we usually finish up.
Also, the nice folks at Globaldev are sponsoring some drinks behind the bar, so it's an even better idea to come along than usual.
To ease us into 2013, Murray Steele will be running a pub quiz. We last did a pub quiz meeting way back in 2007 and it felt like it was about time to revisit it. Also, it provides an easy template for us to copy:
The quiz format will be as follows:
Round 1: London
Round 2: Ruby (community and history)
Round 3: Users (famous folk)
Round 4: Group (music)
Round 5: picture round (a hand out to complete during the other rounds)
Teams should have no more than 4 members. Utilising internet devices to obtain answers will be severely frowned upon. There will be extra points available for best team name.
When the quiz ends and the prizes have been handed out, those with an appetite to continue the pub element of the quiz will head over to The Slaughtered Lamb. If you can't make the quiz, do feel free to turn up just to the pub later on. Our normal meetings end no later than 8pm, but the quiz may run on a bit.