What went down at the @skillsmatter LRUG Lightning Talks
Monday, 10th February saw the return of the London Ruby User Group to Skills Matter. It struck me that LRUG has near as dammit grown out of this space - the room was jam-packed with extra seating laid on. I didn’t even get a complimentary pen and pad!
The lightning talks followed a 20x20 format - 20 slides that auto-transition after 20 seconds, giving the speaker a total of 6 minutes and 40 seconds to get their point across. This made for some spectacularly fast horse racing commentator-style delivery from the speakers (and made for a miserable affair for anyone foolhardy enough to try and transcribe this stuff).
#1 - Jeremy Tapp and Daniel Cooper - Balancing Development and Management Objectives
Jeremy and Daniel from Homeflow gave a convincing improv performance of a conversation between a developer and a manager. Basically, a developer presents his manager with the fact that the company has accrued significant development debt, and that the app needs refactoring.
The manager responds that ‘we haven’t got time’ because they have clients chomping at the bit for features. The developer counters by suggesting that their development issues are related to deploying and testing changes to the app and therefore slowing down all work. The manager didjdojdopjdo that they are dedicated to building better stuff and keeping up tech hygiene.
They decide to try service orientated approach (SOA) and experiment on their client Country Life - a high-end property magazine - to refactor the way search works on their website. Using a combination of Liquid, Cthesis, Hestia and MongoDB and ditching MYSQL (roughly front to back). By breaking up the app horizontally into these different layers they were able to make changes much more easily.
This approach also had a business benefit (taking it back to out manager/dev exchange), as they had turned product into a service, this platformisation of the website into different horizontal layers could be a service they provide for other clients as a platform as a service.
#2 - Alice Bartlett - Five Facts about Small
Alice Bartlett delivered a stunningly fast listicle breakdown of the history of the science of smell, or lack of. The obvious question - what does this have to do with Ruby? Her response:
‘I knew I had nothing to tell you guys about Ruby, so I thought I’d do this instead.’
Anyway, here’s the list:
- Humans have 3 chemical senses.
- 1.2% have no sense of smell. Alice is one of those 1.2%. She didn’t know that she had no sense of smell until she was about 7 years old. In hindsight she thinks she thought smelling was a learnt skill, rather than an a priori sense, so thought she was just yet to pick it up.
- Some smells are smellier than others and no one knows why!
*sublist alert* Alice then broke down a list of what are the apparently the smelliest smells. You’ll have to ask her nicely what’s on this list that she can’t smell. Or, you know, google it.
4. There are 7 ‘primary odours’. This is a pseudo-scientific list, used mainly by those who work in perfumery, which is: putrid, pungent, minty, ether, floral, musk and camphor.
5. We don’t know how humans detect smell (but there are a couple of theories). We do know that you have between 5 and 6 million smell receptors of 347 types, called olfactory sensors, and some of these are able to work in combination to perceive yet more smells. Shape theory - the smelly molecules and the olfactory sensors fit together like lock and key. Vibration theory - similar to shape theory, except that it’s the vibration of the sensor and the smelly molecule that match up.
In a move straight out of the public speaking playbook 101, Alice left us with a quote credited to Alexander Graham Bell:
#3 - Pablo Brasero Moreno - FirefoxOS. On Rails.
Pablo, who works at new Bamboo, took us through getting FirefoxOS, and open-source mobile operating system from Mozilla, working on Rails. This acts as a wider intro to building mobile operating systems on Rails, and opening up the options for an open mobile web.
In classic developer fashion, he didn’t follow the UX guidelines, and hit lots of pitfalls. He had a horrible, overly linear OS, but it worked. For version 2.0 he started from fresh using what he knew and went for Rails. He used OmniAuth so he could sign in to applications on the OS and hosted it on Heroku.
For testing he used Selenium to automate a web browser for him. This was still a testing setup however, so he precompiled to pull of his assets together, and used wget to pull files from his local server. He zipped up the lot and then published it.
He ran a live demo to finish up, running RunKeeper on his rails-based operating system. He explained that the point was that he was using basic existing web tech like Ruby, PHP, NodeJS, Python and so on to provide a potential alternative to how we run operating systems on mobile devices.
#4 - Camille Baldock - How to visually represent memory leaks in Ruby applications
Camille described a nightmare situation where a client’s (she wouldn’t say who) app had such memory bloat that they only had enough memory to run the application for users for a maximum of 15 minutes before it fell over.
This memory bloat occurs when you have too many objects at once (this grows with the data set), combines with memory leaks (which are never released by the garbage collector) and memory churn (the repeated allocating and deallocating of a lot of objects) for a painfully slow app.
In looking for a solution, they started with Oink - an open-source gem that runs in the background, counting active objects. This showed an enormous min-max heap.
That was useful, but still didn’t adequately give them a measure on the memory leaks. Instead Ruby object graphs helped them identify the leaks, which while being an abstract way of doing things, they could now at least visualise the bottleneck that was occurring. The object graph visualises the object system at a particular time. This way, instead of just counting objects, you can find the hotspots and try to tackle these.
A quick bit of learning was to ‘stop using global state!’ as these are stored in your memory, which contributes to the problem.
Unfortunately after two weeks of work, the app was still slow, which takes us to memory churn. Memory churn (the need for large number of garbage collections) when processing large data sets can be dealt with by setting limits on allocation, but with that Camille was out of time!
#5 - Gerhard Lazu - The Path to Continuous Delivery 1
Gerhard posited a scenario where he had a Rails application requiring MySQL and Redis that he wants to be able to host himself. He suggested a very clean and simple approach using Ansible and Docker, for a powerful, fast-loading infrastructure that can be manipulated remotely with minimal effort.
Ansible is a system orchestration tool that uses python and ssh, that comes with extensive libraries of modules for controlling every possible different combination of tools, from databases to cloud providers.
Docker is a tool for creating virtual Linux containers for shipping apps. As opposed to a VM that requires an operating system on top of the host, Docker leverages Linux containers.
Ansible will set up Docker on a remote system, while on Gerhard’s local machine he sets up an API key from his hosting service and sets up his shell environment.
Gerhard then reeled some apparently very fast loading speeds for his application but unfortunately I wasn’t fast enough to catch them.
Gerhard suggests that we should think of Docker as snapshotting and transporting processes in the same way Git does with code. This means that you have a self-contained process, because everything needed to run that process is in there, regardless of where you decide to host it.
Ansible comes in, because without leaving his local shell, Gerhard can take actions remotely - setting up new instances, cloning a git repository and so on.
#6 - Tom Cartwright - AngularJS for Rubyists
He builds a Ruby app and places the Angular instructions in the header of his markup.
Angular has an automatic way of updating the view whenever the model changes, and updating the model whenever the view changes. This eliminates DOM manipulation from your workflow, and you can express the behaviour in a clean and readable format without updating the DOM.
Angular does this by ‘dirty checking’ the many rows and making any changes required. While Angular essentially speeds up the process of testing, Tom used the jasmine gem for testing.
It sounds like you can do an awful lot with Angular, but to summarise, as opposed to declaring static information as you would with normal HTML, it allows you declare dynamic views in one-page web applications. This really speeds up the development process and neatly ties into the Ruby ethos as a dynamic and straightforward way to build and easily test web apps.
#7 - Swathi Kantharaja - Create your own blog using Jekyll
Swathi starts by explaining that Jekyll is a ruby gem that can transform plain text into a static website. (It’s also what powers Github pages, but she doesn’t mention this). She proceeds to give us a blow-by-blow explanation of how we can build a fully functional blog (with drafts, articles, and different styling for different pages) from scratch with a bit of Jekyll.
When you launch Jekyll with a few lines of code on your local server like so -
~ $ gem install jekyll
~ $ jekyll new my-awesome-site
~ $ cd my-awesome-site
~/my-awesome-site $ jekyll serve
# => Now browse to http://localhost:4000
You see a default blank homepage, on which you can start to develop. From here Swathi starts creating templates using a bit of Shopify’s Liquid markup in the header tag, but you can use CSS or whatever you prefer.
So for example, we can create a blog post. We customise the URL in a yaml file and we set the ‘front matter’ (like html metatags) here - so the name of the article, the date, the heading and so on.
Swathi recommends using the syntax highlighter Pygment to wrap the code with Liquid tags so it’s styled up.
When you’re ready, push from your local server to Github!
#8 - Despo Pentara - Issuehub.io
Despo described her open source project issuehub.io; a project to welcome more people into contributing to open source. An ingenious idea, it overlaps with some of her other projects like Codebar - an intuitive way of teaching and learning to code.
Despo explains that a new codebase can be hard to get started with, even for experienced developers, let alone someone who is just starting. For this reason, it's easier to pick up something small and trivial to tackle. Or you could work on a bit of documentation until your understanding grows and there is more familiarity with a project, from which you will be able to contribute more, and transfer this learning to other projects in future.
When you are logged in to Github, issuehub.io allows you to start contributing to open source projects, by finding smaller easier-to-break-down tasks that are right for you.
Issues are tagged with labels - from ‘trivial’ through to ‘refactoring’ - it’s up to the managers of open source projects to do the labelling, and thereby enjoy the fruits of free labour, and help more inexperienced contributors to learn all in one go!
#9 - NTLK - 10 things I hate about your documentation
NTLK describes their experience finding open source software to help with her work on Rails app. NTLK finds what they think they are looking for - in this case an open source CSS framework to make managing email architecture a little easier to handle in Rails apps - it sounds perfect!
Now to go looking for some documentation. There is a readme file but it is just a Github sample readme. No problem, thinks NTLK, I’ll just check out the wiki. There you are presented with a message -
At this point NTLK checks out the Google APIs Client Library for Ruby, but there’s no information there either.
What about tools that aren’t just on Github? As an alternative to solving the email problem, NTLK checked out Mailgun by Rackspace. Here the documentation is decent overall - there are examples and so on.
NTLK clicks on one of the features - ‘tracking opens’ and there is a comprehensive list of all the things you can do with it. But examples are always better.
Trying to find some examples, NTLK clicks the links, but they just lead back to the explanation, not to an example. NTLK thinks: ‘Maybe I’ll just set up a small test webhook’, but even this isn’t possible.
NTLK’s message to people building tools: UX matters, and documentation is part of that experience. Teaching is a revolutionary act: your imparting information in this way could lead the way to scaleable teaching solutions.
If you’re in town, LRUG is always worth a look or hardcore Rubyists and rank amateurs alike. The 20 x 20 format struck me as a little bonkers at first, but works well to keep things moving, and means if one talk leaves you cold, there’s another one on a very different subject coming straight after.
See you at the next one!