The Nordic Ruby conference is a really great conference. I think the secret is: it’s small (they set a limit of 150 people which was reached), single track, 15 or 30 min sessions and 30 min breaks, great party and you have lots of time to talk to very passionate speakers and attendants.
The quality of every single session was extremely high, both interesting subjects as well as good and amusing presentations. There were only a few sessions that were very technical with slides containing source code (which is not a bad thing – just an observation).
If you plan just to attend one Ruby conference then you should definitely consider attending this one !
GitHub Flavored Ruby by Tom Preston Werner (founder of GitHub)
Readme Driven Development. You should do just enough specification before coding. Start a new project by first describing it and its API in a README file. When you have started coding you can have two files: the actual implementation and specification in a README, and the planed future specification in a SPEC file (simple text file).
TomDoc – an alternative to YARD and RDoc (like JavaDoc for Ruby). TomDoc is very simple and is designed for humans to read, no complex annotations that is only needed for the computer in order to generate HTML from the source code. He argued that it’s complex to describe with annotations a Ruby method in a tool like YARD because of the dynamic nature of the language (meta programming).
The only negative thing about TomDoc I can think of is that the RubyMine IDE can use the YARD annotation to do clever things, check http://blogs.jetbrains.com/ruby/2011/03/whats-mining-understanding-yard/ However, I have not tried it and I’m not sure how useful it is compared to just having a simple and clean text description of your API.
Semantic Versioning and Public API. Talked about this: http://semver.org
When you brake a public API you should change the major version number, even if the code change is small. This should of course be avoided.
Modularization. At github they modularize by open source components.
Example of open source components used internally by github: jekll, albino, guilt, markup, gollum, resque (jobs), nodeload (impl in node js), ernie (impl in Erlang), proxy machine, stratocaster, chimney, ghromosome, giraffe, bert (rpc), failbot, heaven (deploy from campfire).
They use bundler with filepath dependencies a lot for internal components.
Semantic versioning, public API, open source modularization helps against the classic dependency hell.
API Design Matters by Anthony Eden from DNSimple
We all produce APIs. APIs are products that outlives the implementation.
API’s should: be easy to learn, produces readable code for people using the API, be easy to extend, be hard to misuse and be sufficiently powerful.
He talked about the 5 C’s: Consistent, Clear Intention, Convenient (should at least be easier then implementing it your self), Concise, Complete
Open URI is an example of not having a API, but instead “stealing” an already existing API (the ruby file API). The best API is the no API at all.
How to design an API ?
Ask the client first and think. Address your audience. Choose good defaults.
Separate API & SPI. Try to keep the public API as small as possible but still convenient. More info, check http://www.infoq.com/presentations/effective-api-design by Joshua Bloch
There are lots of tools for doing this:
The Limited Red Society by Joseph Wilk (15 min talk)
Talked about metrics and getting feedback of what your are doing.
Showed examples of visualization used in various sports and how to provide feedback to players. Would it not be cool if we could visualize and try to find patterns when we are doing refactoring and test driven development. How long do we spend in a failing test state, what was changed ? Failure/Change rate.
The metric is the husk which surrounds an insight. Once the insight is exposed, toss the metric away !
Must it always be about sex ? by Joshua Wehner
In USA only 18% of the computer science students are girls. At a ruby conference typically only 5.6 % girls. Only 1.5% girls does open source development.
Not only about sex but also about age, colour and economic situation. More black people have died from lightning than have become professors of computer science.
3700 women left working as engineers. Reason: 25% family related , 75% culture at the work !
How to writing an recruitment advertisement addressing both sexes, don’t use words like individual, rock star, best.
A great programmer who is not sympathetic and does not work well together with other people is not a great programmer (the “No Asshole” rule).
Infinite data – finite solutions, by Randall Thomas from Engine Yard
Last year he talked about classical (frequentist) statistics and tools. This year he talked about the Bayesian approach, which is often used in machine learning. A Bayesian approach updates the prediction when it gets new data.
He had a demo of the weka java tool/components (http://www.cs.waikato.ac.nz/ml/weka/) – very interesting.
Lightning Talks 5 min. each
Anthony Eden, Alternate way of indexing RubyGems: let’s use DNS ! see this
Use Code KATA, The Coder’s Dojo, Cyber Dojo, by Emily Bache
I’m now even more inspired to finally do the above activities.
Whenever.js by Paul Campbell
This guy released his open source project to github on stage in a lightning talk !
A really fun and crazy (?) idea – how about express your code in a cucumber like syntax ? Apparently it’s already popular after one day on github https://github.com/paulca/whenever.js.
Check the slides < href="http://whatever-js.heroku.com/">here
Is this a bad idea ? (Sorry can’t remember his name)
What do you think about this: each developer is allowed to deploy to production at any time, there are 1000 servers and 6000.000 pages views a day, only one branch – and there are no tests at all. I repeat: no test before production deploy at all. For a Ruby developer this is just pure madness. He said that for wordpress.com (php) it has been a great decision. His explanation why it does work is that there are many tiny deploys every day (around 30) and therefore it is very simple to find bugs.
A brave guy talking about PHP and not testing at a Ruby conference (the Ruby community fiercely advocate the TDD process and have created many great testing tools).
I think he miss something – TDD (or BDD) is not really about testing, it’s a design methodology that helps you to create high quality code. But it has a nice side effect: TDD can also be used to find bugs. So, the question is wrong, it should be “is it a bad idea to develop software without TDD ?” instead of “is it a bad idea to not run tests before production deploy ?”
Actor on Stage by Elise Huard, 15 min
Had an introduction to Actors and talked about different actor implementations, like Celluloid (http://www.unlimitednovelty.com/2011/05/introducing-celluloid-concurrent-object.html) for Rubinius and JRuby. Talked very positively about Akka, Erlang and Clojure. There is no great actor implementation for MRI. but one can use clojure or akka from JRuby.
Beyond Ruby, by Jakob Mattson (from Burt in Göteborg)
He claimed that Ruby still is a rather static language and that we want/need a language that can change itself. Really interesting stuff.
The usual talk that everything in Ruby is an object is not true. For example the ‘end’ statement or the ‘.’ syntax element should be objects.
Operators on steorid – should be possible to define your own operators, eval order etc.
Pass by expression instead by reference/value. send in the whole expression instead of the result as an argument to a method.
Fewer and less enforcing primitives.
When you look at a new programming language, you should not ask what the programming language can do, but what it can’t do.
Fewer Constraints, more Concurrency by Ryan Smith from Heroku
Talked about Gene Amdahls Law – The speedup of a program using multiple processors in parallel computing is limited by the time needed for the sequential fraction of the program.
He describe a concurrency problem with a message queue and the solution he had for one application he had been working on. Instead of introducing a new tool like none blocking I/O (statemachine, nodejs …) or using a standard message queue he used the tools that was already in use – the PostgreSQL database.
His problem with the message queue:
Worker a takes job 0
Worker b takes job 1
Worker a slows down
Worker b speed up
Worker b finish job 1
Worker a finish job 0
This is not good if you only need “fuzzy” fifo queue – all the messages from one day should come before the next day (micro order does not matter but macro order did matter).
He showed a simple and elegant solution of a spin lock algorithm for this implemented in PostgreSQL DB. This was a good architecture choice (having the queue impl in the DB instead of a standard MQ product) since there was only one application using it. It also gave much better performance compared to using event machine (a none blocking I/O solution which probably was to slow for this application).
Mountain Dew and My Trails of Tears, Aaron Patterson AT&T
A great and fun speaker ! Watch this if you want a good laugh.
I like his attitude – life should be fun but you can still be very serious about your craft.
Talked about what to do about legacy software and some classic techniques for refactoring and testing. In Ruby you have more possibilities because of the dynamic nature of the language – very easy dynamically change legacy code without touching the code.
Example, use the “ruby -I” swich to force the program to use your code instead, Class.new, Object#extend, define your own constant/class.
He also asked if you need a mocking/stubbing framework in Ruby when it’s so easy to do it your self. Read: Working Effectively with Legacy Code
Chad Fowler “Legacy”
The word “legacy” should not be a negative word. Beethoven, Miro produced a legacy ! So, if you want to create software that last or even outlives yourself then the question should be: “how do you create legacy software ?”
The success rate of finishing a large software product is very low and not getting any better.
What makes software survive/last ?
Examples of old legacy system that still exists are usually small unix tools or
systems made up of small unix like tools.
How does nature manage to build complex system – homeostasis. Components should be replaceable and should be replaced all the time. What is a cell or a organ ? It has well defined interfaces.
Force heterogeneity – language, operation system, frameworks will change over time. If it’s hard to do then do it all the time !
One reason of death of a software product: It only run on one hardware that now no longer exists.
Must Try Harder by Keavy McMinn
Talked about how she managed to do two Ironman triathlon. After that talk I got the feeling that anything is possible if you really want it and have a process to follow. Here are some notes:
The goal must come from your heart. Consistency in training. Develop a process to follow, set your goal, be realistic and flexible with your goal. Break down goal into sub goals. Apply some stress in a positive way. Allow to recover in order to adapt. Reflect what you have done and analyze failure or success – what event caused it. Committed practise, practise what you find difficult. Do a thing every day that scares you. Go outside your comfort zone. Embrace fear, try to understand your fear. Get a coach (She talked about her fear of heights and how she got help from a good coach cycling in high mountains)
Exercise control. Practise consistence, x hours a day = ?
Nice with reward but practise is also rewarding.
Judgement, should I stop achieving my goal, why am I doing it ?
concentrate on the process not the end result.
So, the question after this conference is; when can I buy the tickets for the next year conference ?
I guess one have to register very early next year in order to be one of the only 150(?) lucky attendance that they will accept.