Agile Corporation
Regarding processes and practices, a lot of what is published or promoted in the Rails world comes from the consultant point of view. I think it’s fantastic these companies and individuals share their lessons learned and there is great value in those lessons. If you are in a Rails shop looking at these examples as templates for organizing your team please take this information as guidelines. Very good guidelines indeed, but not everything that fits for a consultancy will directly translate for your organization. It is important for your team to discover what works for you in your environment. Here’s the discovery process we went through, hopefully this will help you and your team.
Many months ago we started down the wrong road trying to do things in a rigid agile manner. Sound weird? Well it was, but we didn’t know any better at the time. We were ignoring our gut instincts hoping this agile thing would prove us wrong. After a short time, the word agile became an excuse used by some to avoid any architecture (any thought into the long term goal). In fact, the term architecture became a symbol of everything anti-agile and therefore evil. It was at this point for me that agile became an evil term and a symbol of avoidance. These were not good times.
After a couple of missed deadlines and the realization that the ‘extra’ time wasn’t producing a better product, we revolted. Now this isn’t like we had opposition during this revolt, just the opposite. We given charge of this and the revolt was against our own blind stupidity. It was embarrassing.
We then decided that nothing was sacred. From the tools we used to the processes we employ, anything could be challenged and changed.
As we were just starting down this path we had the great fortune in having Hashrocket come aboard and pair with us. With their help we delved deeper into the practices we already employed: pairing, bdd and daily scrums to name a few. We were also introduced to tools like PivotalTracker and Campfire.
Some of the practices we were doing (pre-Hashrocket) were so weak that saying we employed them was almost laughable. We got a lot of help in those areas. We also were given rules for some practices that just did not transfer to our environment. Did we expect them to? Well yes, but that was incorrect to do so. What we have done is taken the ideas as a starting point and let team define the rest.
Are we done, do we have everything ironed out and run flawlessly? Absolutely not, but our team has grown in fantastic leaps and bounds and while things will continue to evolve, here are a few of core practices we will not abandon. They are the reasons we will continue to learn and improve.
**wow that was a really long intro for a short list
Weekly Retrospective
Every Friday afternoon our dev team gets together, closes the door and talks about the week. What we should keep doing, what we should stop doing and what did we learn are all discussed. We have removed/added/altered processes, practices and tools from the result of these meetings. This is the single greatest impetus for change.
Iteration Leads
In order to spread knowledge about the different projects across the team we assign someone to the iteration lead role. This is the go to person for the iteration and is responsible for seeing it through to a successful release.
Team Board
This is simply a rolling whiteboard that we use to show the following:
- Pairs for the iteration and what they are working on.
- Iteration leads
- Release dates
Daily Standups
We actually have two different sessions every morning. Since we have multiple products, the dev team breaks apart and goes to their product related standup. We then get together and have a developer only standup to relay any information. This divide and conquer technique has proven to be very efficient.
Last and not least:
Pairing
This one is a post in itself, I’ll only briefly cover pairing. Pairing is good, but like most things in the computer world doing something ALL the time usually fails. At a minimum, I think there are times when pairing should be approached differently. For example: If the pair is tasked with researching something that neither knows, I think researching the problem individually and regrouping later is a better approach. Not everyone process information the same way. More on this later, but as a basic rule: Pairing is good.
Over the past few months I have become more and more interested in what people are doing in the corporate setting. I even went so far as to create RubyTrends.com in an effort to get a picture of the entire Rails landscape, not just the consultancies. While the site is rough right now (updates are coming soon), I would appreciate you voting on the projects, books and practices you use. I think this information would be beneficial to us all.
Thanks for reading,
-stonean
Using ensure to reset a value
I have a bunch of links I need to build on page, links that are a modification to the current path. I wanted to be able to do my modifications and return the modified path (@updated_path) without changing the original path variable (@path).
This isn’t difficult stuff, the only thing that I had to ponder on for a moment is how to get the updated path and reset it to the original state (@path.dup) in one nice little call.
This worked out nicely:
def updated_path
@updated_path
ensure
@updated_path = @path.dup
end
The updated_path method will return the old value and reset it afterward. Nice and simple, I like.
config.gem
When the config.gem statement was introduced I was pleased. It was great to have a centralized list of what gems were required by your application and with the rake gems:install task it would, in some cases, install the gems defined. More about that later, in another post.
After some time issues started to surface due to the lack of thought put into how to use config.gem. Here’s a list of some do’s and don’ts:
- Use absolute version references!. This is really important when you want to roll back. If you update gems as a part of your deployment and your config.gem statement has :version => “>= 0.9″ and version “1.0″ had api changes. When you roll back, you’re still going to pick up the new version and potentially go boom!
- Don’t put config.gem statements related to your application server. e.g. don’t put references to mongrel, passenger, etc… That’s a pain when you develop with passenger but deploy to mongrel boxes.
- Use :lib => false, if you don’t want Rails to require the gem.
- Do put testing related gems in your config/environments/test.rb, don’t put them in environment.rb (even if you use :lib => false, I think it’s a better practice. )
- Don’t install the gem then add the config.gem statement. Add the config.gem statement, then use rake gems:install. This will help you find any issues before you deploy.
If you have some best practices that have saved you, I would love to hear about them!
Thanks to Hashrocket for at least one of the above. Can’t remember where each one originated.
RubyTrends.com
On Sunday I released RubyTrends.com. As I had only worked on this site for a few days, it was definitely an early release but I thought there was enough there to start gathering feedback.
There are a couple things I will add over the next couple of days: openid login and badges. OpenID login is self explanatory. Badges may not be, so here it goes. I hope that developers put a simple link to RubyTrends to get people to acknowledge they use the project. I’ll put sample code on the trend view page that links to the site. It will direct the user to login/register and then count the vote. This hasn’t been done yet, but will be soon.
The more action the site gets, the better we will be able to determine which projects people are using (based on tags). That is the goal. Just as much for me as someone new to Ruby.
So, if you have some ideas I’d love to hear them!
Convention of Configuration
My company is currently working on multiple Rails sites simultaneously. This involves multiple development groups and an infrastructure team tasked with providing multiple environments (continuous integration, qa, staging and production) for each project. There are many elements required to make this happen and we are in the process of working through the kinks. This post is about one of the solutions, convention of configuration.
There are definitely some things that have been done with the current version of Rails to help us. There are definitely some things I would like to see changed in a near-future release (3.0?) of Rails that would provide a more ideal configuration solution. I’ll get to that in a bit, but let’s start off with what can be done now.
Take advantage of the environment files in RAILS_ROOT/config/environments. These should be THE place you look for your applications’ configuration. Take advantage of the fact you can provide a default setting in RAILS_ROOT/config/environment.rb and then override that setting in RAILS_ROOT/config/environments/production.rb or any environment you choose. Also take advantage of the fact you can create an environment called staging and as long as there is a corresponding RAILS_ROOT/config/environments/staging.rb, you’re good.
How do you take advantage of this? This simplest solution I’ve found is to create a file in your RAILS_ROOT/config directory that defines the configurations you need. Here is a sample file we’ll call mycompany.rb:
module MyCompany
module Configuration
def google
MyCompany::Google
end
end
module Google
class << self
attr_accessor :api_key
end
end
end
Rails::Configuration.send :include, MyCompany::Configuration
Then in your RAILS_ROOT/config/environment.rb add the following line after the require for ‘boot’:
require File.join(File.dirname(__FILE__), 'mycompany.rb')
This will require your file and allow you to do something very simple and expected in your Rails::Initializer block:
config.google.api_key = 'THISISSSOMEVALIDAPIKEY'
If you create a default in environment.rb and override for other environments it will work as expected. You can later reference this through your app as MyCompany::Google.api_key.
As you need more configurations, you can expand your mycomany.rb functionality and you will have your one expected place to go for both the development and infrastructure teams.
This is good, but it’s not perfect. We can’t attempt to reach perfection with the current configuration construct provided by Rails.
What’s wrong? Well, instead of having the RAILS_ROOT/config/environments directory contain environment files, I would like them to contain environment directories. For example, RAILS_ROOT/config/environments/production/environment.rb would be ideal. This would allow applications like Capistrano to take advantage of this construct and place its environment related files in these directories. A single place to look for production related settings would rock!
In order to avoid conflicts between development environments, development and test should not be stored in your source control. Instead, give everyone a helping hand and start them out with an example (that should be in source control):
RAILS_ROOT/config/environments/development/environment.rb.example
This example should be updated as needed to provide the latest configuration examples.
Another feature wish for the RAILS team is to do away with database.yml. I think these settings belong with the rest. Think of the code duplication you could save! I could set my adapter, encoding and database in RAILS_ROOT/config/environment.rb and leave the username password and host to be overridden by my different environments.
You could start out with this:
config.database.adapter = 'mysql'
config.database.encoding = 'utf8'
config.database.database = 'my_database'
Then in RAILS_ROOT/config/environments/production/environment.rb you could just
config.database.username = 'super_secret_user'
config.database.password = 'super_secret_pass'
config.database.host = 'another_host'
I would like to hear what you think and if there are other conventions your team has adopted. The more we can reduce the amount of documentation required between teams and develop an expectation, the more efficient our company will be.
We are working every day to reach this goal and I will continue to share our findings in hope that they can be further refined.
Git: Branch from a tag
In git, you can’t update a tag directly, but you can branch the code to create a new tag. Here’s how you would do that:
First, you need to checkout the tag:
git checkout <tag_name> Then create a branch:
git branch -b <branch_name>After you make your changes, commit them (there are a few ways to do this, keeping it simple):
git commit -am 'my descriptive comment on this commit'You can create a new tag:
git tag <new_tag_name>Then you can push the tag:
git push --tagsLockdown ATLRug presentation
My first presentation ever was at the ATLRug meeting this past Wednesday.
It’s a little rough, but I’ll get better at them. Since I didn’t pay attention to where the mic was, you’ll have to turn up the volume to hear me. This is fine until the end, the applause (thankfully) is loud, so remember to turn down the volume.
Also take the time out to listen to ReinH’s ‘Ruby loves you’ presentation, it’s very good.
Lockdown 0.8.1 Released
Lockdown version 0.8.1 has been released!
The session[:access_rights] was being constructed as a nested array structure instead of a flat array structure when a permission had multiple controllers associated to it.
Thanks to Robert Rowland for finding and reporting this issue!
Lockdown Tip: access_rights_for_permission
You can use Lockdown::System.access_rights_for_permission(:perm_name) to get the array of access rights associated to the permission.
This is handy for testing.
Lockdown 0.8.0 Released!
Lockdown version 0.8.0 has been released! New DSL for defining permissions, better documentation and more specs on the gem, all good stuff.
Next up: Model level security! woohoo!
