Here's Part 2 of my thoughts on the Aloha on Rails technical conference that I attended earlier this month. (Oct 5-6) I want to write down what I personally got out of the conference before I forget it. I meant to do this sooner, but I've been busy applying some of what I've learned. This post covers the sessions I attended on Day 2 of the conference.
Jim Weirich's session: Grand Unified Theory of Software Design
- Jim introduced a term called connascense, which for software design purposes means the way two pieces of code are coupled, or two things that have to change together when one of them changes, in order to preserve correctness. There are different degrees of connascence:
- Connascence of Name (CoN): where two components use the same name to couple, such as passing named parameters within a hash, or using the name of a method or variable to refer to the same thing.
- Connascence of Position (CoP): where the order matters, such as the order of parameters in a method call, or where positions in arrays are hardcoded. The coupling can be made more robust by converting this down to CoN.
- Connascence of Meaning (CoM): using values to mean something for the two components. (Like "404" error code means page not found). These can be assigned to constants to somewhat reduce to CoN, but even in the assignment of values to constants, there needs to be contranascence (where two components have to be different, in order to preserve correctness) between the values to that the same value isn't assigned to different constants that are supposed to be different.
- Connascence of Algorithm (CoA): the two components depend on the same algorithm to work right. For example if there is a method that creates a checksum (add_check_digit) and a check method to verify that a checksum matches. Can DRY (don't repeat yourself) it out by having a separate method that does the algorithm, and having both these methods call that method. (CoA->CoN)
- Rule of Software Locality - Within the same module, there is stronger connascence. When it is farther away, use weaker forms of connascence.
- Rule of Degree - convert higher degrees of connascence into weaker forms.
- Thoughts: I can see how this makes software easier to understand and more maintainable - certainly for Ruby On Rails, this seems to be the way it is evolving. I'm not sure this applies as well to lower level languages though, or when optimizing for performance. Say you want to write a highly optimized device driver, or you want the data to be as small as possible (sending an array in json using CoP and CoM, as opposed to sending a json hash), you might want to use a stronger form of connascence.
- There were several more forms of connascence he talked about, that seem to be a bit different than the previous ones:
- Connascence of Timing: using mutual exclusion in race condition
- Connascence of Execution: Depends on the order of execution
- Connascence of Identity: getting two separate objects to represent the same logical object (two pointers to the same object)
- Connascence of Values: constraints on the values: in graphics, left < right, top < bottom
- Connascence is only part of the grand unified theory of software design. There are other parts: cohesion and comprehensibility (human factor).
Chad Pytel and Tammer Saleh's session: You're Doing It Wrong
- When refactoring (when working on a legacy code rescue project) talk with your client to see if they actually still need the feature
- In rescues where there are no existing automated tests, write integration tests for existing behavior, and unit tests for new features
- Webrat & Selenium are key for doing these tests
- Add functional tests for new controllers, one at a time
- Rake tests can be tested too by moving their methods into a model. Make the rake task skinny.
- Rails views are composed of many parts (html, css, js, ruby). Know your rails helpers and how they change across rails releases.
- Use the yield/content_for helpers to do page titles (the <title> tag in the head) for better MVC separation
Charles Nutter's session: JRuby From Zero to Awesome
This talk/demo was amazing! Charles gave several demos of JRuby projects that just blew me away on how easy it was to use java functionality from ruby, calling methods in a very ruby-friendly way. If I have to build new stuff on top of legacy java code, then I'll definitely consider using JRuby to do it.
Blake Mizerany's session: Forget Kindergarten, Learn to Scale
Some tips on scaling, based on cloud computing with heroku
- Don't keep state on the local environment. Everything must be disposable.
- Share nothing. The server is not for persistent storage of dynamic assets. (temp uploaded files)
- Be impatient: Keep everything under 200 ms. Use caching if it is needed. Rack::Cache and Memcached
- Procrastinate: If it takes over 200 ms, run a background job.
- Be unfair: handle monsters separately
Anthony Eden's session: Technical Debt - Rewrite or Refactor
- technical debt is inevitable, so plan for it, or pay it back with interest or time
- TATFT!
- minimize code so you can pay back technical debt quickly
- pair programming disseminates knowledge
- Set aside (schedule) time to deal with technical debt
- Tasks:
- get rid of cruft (commented code)
- remove methods that are no longer invoked
- write tests for untested code,
- use the client to see if any more code can be thrown away
- refactor existing monster code into smaller pieces, DRY it up
- Candidates for rewrite:
- if there are no existing tests, you're very likely going to need a rewrite
- low quality code
- owner of code is no longer there
Corey Donohoe's session: Everything I Know About Being an Open Source Hacker I Learned From Indie Hip Hop
I learned much more about the Hip Hop community than about the Rails community from this talk. Key takeaway points for me:
- Meet other developers, perhaps at a local meetup, or attend 2 conferences a year
- Check out other developers' code on github, and post your own.
Panel discussion: Modeling Maturity
- railsmaturitymodel.com
- There are very different views on this. Some very strong opposing views against having a Rails Maturity Model (reminds of all the bad things of CMM)
- Related question: How does the client know who is legit and uses best practices, and who is a charlatan?
- Check ruby-toolbox.com for good new plugins
Benjamin Sandofsky's session: Staying Above the Ghetto
- RoR is a luxury brand: affected by the economy, and frequently copied
- Our values as a rails community: aesthetics, pragmatic, freedom, passion
- Our bane: commodity developers - the kind who write corporate training sites, cheap, and don't care
- Learn, create, share
__________
For me personally, I've got some todo's based on what I learned:
Comments [1]