A few months ago I visited the Swedish Ruby conference Nordic Ruby 2011 in Gothenburg. This was the first time for me and I hope to come back again. The conference had a pleasant size, friendly atmosphere, nice format (30 min talk, 30 min break), and great speakers. Oh, and awesome coffee.
While I was at the conference I took notes during the talks so, for what it’s worth, you’ll find them below. I feel it is appropriate to apologize in advance for possible errors in this post; information flows very fast at a conference and it is easy to misunderstand.
Day 1
Tom Preston-Warner: GitHub Flavored Ruby
Gist: Some useful techniques we use at GitHub that may be useful to others.
Readme Driven Development is like User-Guide Driven Development for libraries. The basic idea is to write the README file first. To not confuse other users, call it “spec” or similar to start with. As soon as a new feature is done, copy that part of the spec to README.
TomDoc is not like RDoc or YARD. For humans, not machines. Read more: tomdoc.org
Semantic Versioning is a great way to number versions for public APIs. Numbering scheme: major.minor.patch.
- Major level: For changes that are backwards incompatible
- Minor level: For new functionality, big internal change, bug fixes (must be backwards compatible)
- Patch level: For bug fixes only
~>2.4 Pessimistic operator: Use any compatible version bigger than or same as 2.4 Read more: semver.org
Modularisation. Work as you would open source any part of your system.
Anthony Eden: API Design Matters
Gist: We should all think about APIs from the client perspective. You are an API designer.
5Cs for API design:
- Consistent (with itself or your other APIs), “economy of concepts”
- Clear in naming, descriptions, intent
- Convenient, easier to use than rewrite
- Concise, brief
- Complete
Bad example: HTTP::Net. Good example: Typheous, open-uri (uses File.open with block)
Book tip: “The little manual of API Design” by Jasmin Blanchette
Thorben Schröder: Bridging the Gap
Gist: Ruby and JavaScript are two great worlds that need to work together.
Problem: Integration will sometimes lead to duplication, e.g. validation code. Solution: Extract common parts. Use at both places. Either JS from Ruby or vice versa.
For examples, to use JS from Ruby, check out:
- The Ruby Racer: To embed a JS interpreter into Ruby.
- CommonJS: To modularise JS
- modulr: To use CommonJS modules in Ruby
- rack-modulr: To use CommonJS modules in your Rack/Rails applications
- include_js: Use CommonJS modules in Ruby using Ruby Racer
Joseph Wilk: Limited Red Society
Gist: Red = Spec/Test not working = Work in Progress is a necessary state but we should avoid staying in that state for very long.
Being “in the red” is necessary but has bad implications. You can’t integrate, deliver etc. Spending longish times there is not good. Think of it as batch size. Therefore, we want to discover when and why we do this and learn how to improve.
Process: Limit Red -> Measure Red -> Visualise Red -> Learn
Limited Red. Tool posting data from test runs automatically to website.
Coders Dojo: Katas with simple visualizations of red state included.
There are patterns for limiting red state, check out Industrial Logic, Joshua Kerievsky.
Recommended refactoring books:
- “Refactoring in Ruby” by Wake, Rutherford
- “Refactoring – Ruby Edition” by Fields, Harvie, Fowler
Joshua Wehner: Must It Always Be About Sex?
Gist: We have several diversity problems and we should fix that. Otherwise we will otherwise miss out on lots of customers, employees and simply human capacity in general.
Fact: 18% of CS salary to women (2009), down from 37% (1986). 1,5% of commiter in OS are women. Not only gender, also racial and age.
Project Implicit: Test to reveal biases.
Imposter Syndrome: Feeling of being revealed as a “faker”, often felt by people in minority.
Language matters, can introduce a bias just by wording.
The “No Asshole” Rule: People who do extraordinary things but demean others should be considered incompetent. They should not be fired, they should be fixed.
Nice rule: “Fight as if you’re right. Listen as if you’re wrong.”
People deemed to be “lucky” consistently introduce variety in their lives. Unlucky people do the same things every day. Is it luck then? Experiment: Count photos in newspaper. Unlucky people never saw add that state how many photos there were. They even missed big ads with monetary reward.
Recommendations:
- Reprogramme the “assholes”
- Anonymise applicant profiles
- Step outside your comfort zone, every day
- Be weird
Randall Thomas: Infinite Data, Finite Solutions
Gist: Bayesian statistics are preferrable to regular statistics for real-world problems. Statistics assume infinity and other unrealistic conditions. Bayesian statistics start with a guess and improves guesses based on empirical data.
A Bayesian Belief Network (BBN) is Bayes + DAG.
Weka is a project to create a BBN from data, e.g. a CSV file. Downloadable JAR, use with JRuby.
Joe O’Brian: Taking Back Education
Gist: University training in CS is broken. We need to find new ways to train people. Companies should do it themselves, because they are better at it.
Quote: “First book I give to apprentices is “Pragmatic Thinking and Learning”.”
Most things we learn in education is never used. We are “business developers”.
Idea: Code School. Based on apprenticeship, older students mentoring younger.
Quote: “When was the last time you inspired someone?”
Day 2
Paul Campbell: In Search of “Mé Féin”
Gist: “Mé Féin” means myself. Make the world better by just doing good stuff. Only you know where you want to go. Don’t let the external world affect you.
This talk was basically a story on Paul’s life, discovered through the lens of his last week. Each day was a part of his life. Full of fun references, for example:
Quote: “You never know when inspiration is going to strike. Just be ready for it.”
Elise Huard: Actors on Stage
Gist: The actor model is a promising model for solving the concurrency problem.
Completely stateless, message passing between actors. An actor can send and respond to messages as well as create new actors.
The Ruby MRI does not have good support for it and Matz seems reluctant to develop it.
Elise made cunning use of photographs of silent movie stars interleaved with slides with quotes to create a beautiful presentation.
Jakob Mattsson: Beyond Ruby
Gist: Everything is dynamic – except Ruby.
According to Jakob, Ruby is not as moldable as it could be. Everything is not an object. Jakob wants to make a DSL in Ruby that looks like JavaScript or LISP. He calls it Blub.
Ryan Smith: Fewer Constraints, More Concurrency
Gist: To increase concurrency you may have to loosen some of your fundamental assumptions.
How much concurrency do I need? Amdahl’s Law: S = 1 / ((1 - P) + P/n). Speed increase is determined by how much of the computation must be performed sequentially (e.g. network calls, database calls). Number of processors (n) is not as important. Adding more processors to a 90% parallelizable process does not create a great speed-up. We need 100% (or close).
What can I trade? Discovery in example application: Trade FIFO property of work queue. It was not vital for this application. Found: “Fuzzy FIFO”: Take any job above the top boundary. By doing this, more workers could work concurrently.
What does concurrent code look like? There are two different paths though code depending on state. In this case it was the NOWAIT part of an pgSQL query. It requires thinking but it’s not impossible.
Aaron Patterson: Mountain Dew and My Trail of Tears
Gist: Legacy code can make you cry but it doesn’t have to.
Pro tip: Use “ruby -w”, verbose turned on, warnings will be displayed.
Aaron is the only person both on Ruby core team and Rails core team.
Legacy Code contains knowledge and it solves something, but is often painful to work with. Aaron presented his own quasi-math “formula of tears”, to show how much he has wept when working with legacy code. For a single week it turned out to be two large bottles! 😉
Techniques mentioned:
- Liskov Substitution Principle (LSP)
- Single Responsibility Principle (SRP)
- Method Extraction (or Extract Method)
Object#extend: Insert module before ancestors- Extract Object: attack huge classes, find groups of methods and fields
- Pass in delegate in constructor
Seams: Ways to modify execution without modifying the code, for example ruby -I to modify the load path.
Chad Fowler: “Legacy”
Gist: A legacy should be something we strive to achieve, not something generally loathed, but in software very little actually survives.
1st def of Legacy is inheritance, bequest, something beautiful. Examples: Beethoven, John Coltrane have left musical legacies, still noticeable in music today. Kurt Vonnegut books, Gaudí architecture, Comme des Garçon clothing, Miro paintings.
Software projects often fail and have very low life-expectancy (like 5 yrs). Tough quote: “No-one will remember your work when you die.”
How do you create legacy software? Idea: Look at biology. Species survive because they are the fittest, most adaptive. Richard P. Gabriel has researched systems with trillions lines of code. Biology uses homeostasis, cell’s ability to regulate internal conditions using feedback loops. Small components and systems seem in common for oldest surviving software as well. Maybe we should focus on building cells and systems consisting of cells?
Suggestions:
- Tiny components, as small as possible (cells)
- Kill and replace cells regularly, static means death
- Force heterogeneity, the environment will change
- Simple Interfaces, e.g. Unix pipes
Keavy McMinn: Must. Try. Harder
Gist: Really applying yourself is worth all the hard work – no matter for what.
- The goal has to come from your heart. The French cheer with “Avec courage!”. The word “courage” actually means “from the heart”. You need to put it all out there. You will need the support of others.
- Develop a process (and follow it). Set (flexible) goals. Break it down. Apply some stress – then recover. Reflect.
- Practice. Don’t ignore the fear, try understanding it. Celebrate your achievements. Try to control what you can control and ignore the rest. Think positively. Practice consistently.
The Blogging Terrier | Den bloggande terriern 