Thoughts on the Aloha on Rails conference (Part 1 of 2)
I had a great time at the Aloha On Rails conference (Oct 5 and 6), getting to meet other Ruby on Rails developers and listening to the speakers. It was great being able to see the people behind some of the blogs I read, or gems/plugins that I use. I really really hope that this becomes an annual event.
Here are the top pieces of takeaway value that I personally got out of the conference from Day 1 (for a description of each session, see Aloha On Rails Sessions). I'll write more on Day 2's sessions in another post.
From Chad Fowler's keynote: Passionate Programmer:
- A lot of developers hate having to do marketing. (like me) But marketing is a moral imperative. If you believe that you have a great product or that you have a great service to offer that will be of value to others, then you're cheating others if you don't tell them about it.
- What are you spending your passion on? As passion drains away, execution drains away.
- The problem with inspiration is that it is not consistent. You need to systematize it. Calling software development an "art" is just an excuse to not systematize it.
- The framework for succeeding in the software industry is: choose market, invest, execute, market, systematize
- Something that I thought was odd was that Chad said that he wouldn't do programming if he didn't get paid for it. I love to program, and my favorite projects have been the ones I don't get paid for. And there's all the developers who truly enjoy doing open source. Chad does say to practice though (Code Kata and Ruby Quiz), but I guess he means it with the goal of practicing so that you getting paid more later on.
From Blythe Dunham's session: Hey is that your database crying?
One group of tips I was reminded of is: While Rails does a good job of doing validations, it is useful and safer to also put some of those validations in the database as well, such as having "not null" columns, using unique keys, and default values right in the migrations.
From Greg Pollack's session: On the Edge of Rails Performance
I pretty much got my full registration cost back from the value of this talk. Greg went over 9 awesome plugins/libraries for rails performance and optimization. They are listed here:
From Marty Haught's session: Lean Teams - How To Do More With Less"
Essentially just stay focused on adding nothing but value, learning from the users, maximize flow/minimize effort, and ship features when ready. Also he introduced me to the "kanban" system which is an agile methodology which seems to increase the flow of value by limiting the number of works in progress. Here's the link for kanban: Limited WIP Society - Home of Kanban for Software Development
Desi McAdam's session: Dragons, Riddles, and Rails Applications
One practice I haven't heard much of but makes a lot of sense is: "Keep explaining to the client what you were doing for the client." This is especially useful when the work doesn't involve changes that are apparent/visible to the client, such as rescuing/refactoring nightmare legacy code so that it can be more maintainable or enhanced.
Pat Maddox's session: Domain Driven Rails
- A good metric of code quality is WTF's per minute when someone is reading through the code.
- Check out the resource_controller plugin
- Sometimes ActiveRecord callbacks (after_create) can make it harder to follow the code.
- Sometimes moving things from the controller to the model might may testing slow/hard and code hard to follow (ex: an after_create activation/verification email delivery for a User model), in which case a service class would be more appropriate. Look at alternatives to callbacks: service classes, command objects, event handlers
- Stuff that goes in the <title> tag should really use a yield and content_for, rather than being set in the controller or model, since this really is part of the view.
Yehuda Katz's session: Rails 3 Public API
In Rails 3, some of the big long methods are being broken down into smaller parts, which means it can be more easily customizable. We'll be able to get stripped down "metal" versions of many of some of the fat bloated classes and choose which modules/mixins to put in.
Michael Nieling and atthew McVicar's session: You Don't Need A Logo
- Details matter, be consistent, design is never done
- Design and details differentiated Starbucks, iPod, and Flickr from their competitors who had similar producs. They had the best design and looked at all the details of the entire experience.
- Design stewardship - everyone needs to be involved in complying with the design. Have a Design Usage Guide. An design needs to be at almost every point of the process.
- When using a design agency, get them to explain/justify every design decision, and provide you with documentation. Have to be able to justify how it is delivering actual value, rather than just based on "taste".
- Most people can't tell the difference between good and #1 (Chad vs Kelly Slater when surfing), but can tell between a beginner vs good.
- Get the client to tell the "what" and the "why". We'll figure out the "how".
Panel session: Is Agile Too Slow?
- Identify your sacred cows and question them (always write tests for everything? etc)
- Sometimes putting together cucumber scenarios helps out to flesh out requirements. They let you know when you are done.
- Selenium - lets you test the UI
- When is hacking (going without tests) OK? "If you're not getting paid for it", or "at the start" if you don't know if the project/prototype will go forward
Filed under //
Aloha On Rails
Ruby On Rails
Comments [0]