Friday, July 27, 2012
Is velocity meaningful?
If you are estimating based on time to complete instead of relative complexity, NO.
If you are using it to compare two different teams, NO.
If you are doing just-in-time story estimation in your Iteration Planning Meeting, NO.
Relative complexity.
We want to estimate stories relative to other stories. Start by picking an “average” story and assigning it points. We’ll say that our average story is a “3”. We then estimate the remaining stories relative to our average story. If it’s simpler, give it a “1” or a "2". If it’s more complex, give it a “5”. If it’s a lot more complex, consider breaking it up into more stories.
Different teams.
It’s very likely that one team’s “3” is much different than another team’s “3”. It’s also likely that estimating skills are very different across teams.
Just-in-time estimating
Estimating stories at the iteration planning meeting for purposes of velocity is less than ideal. It’s easy to imagine a story getting different points assigned to it based on the iteration it was estimated because different people could be estimating or the understanding of the “average” story’s complexity is a moving target.
The right way.
It’s best to estimate all of the stories created in inception all at once by a few developers to get a meaningful baseline. With baseline estimates, a burn down chart can be used to predict release dates based off of “yesterday’s weather”.
Yes there are things that are going to be missed when the baseline estimates are given, but the thought is that for every story that is overestimated, there will also be an underestimated story.
If you are using it to compare two different teams, NO.
If you are doing just-in-time story estimation in your Iteration Planning Meeting, NO.
Relative complexity.
We want to estimate stories relative to other stories. Start by picking an “average” story and assigning it points. We’ll say that our average story is a “3”. We then estimate the remaining stories relative to our average story. If it’s simpler, give it a “1” or a "2". If it’s more complex, give it a “5”. If it’s a lot more complex, consider breaking it up into more stories.
Different teams.
It’s very likely that one team’s “3” is much different than another team’s “3”. It’s also likely that estimating skills are very different across teams.
Just-in-time estimating
Estimating stories at the iteration planning meeting for purposes of velocity is less than ideal. It’s easy to imagine a story getting different points assigned to it based on the iteration it was estimated because different people could be estimating or the understanding of the “average” story’s complexity is a moving target.
The right way.
It’s best to estimate all of the stories created in inception all at once by a few developers to get a meaningful baseline. With baseline estimates, a burn down chart can be used to predict release dates based off of “yesterday’s weather”.
Yes there are things that are going to be missed when the baseline estimates are given, but the thought is that for every story that is overestimated, there will also be an underestimated story.
Friday, September 30, 2011
Translatable - Manage I18N translations on redis
I recently finished an Open Source Rails 3.1 app named translatable. It can be used to add/edit/delete I18N translations that are stored in redis.
If your application is using redis for its I18n backend, translatable might be useful to you. Just fork it and customize as necessary. You probably only need to update the config/settings.yml.
It's convenient because non-technical people can use translatable to easily manage the translations for your site.
Labels: rails rails3.1 redis
Friday, March 11, 2011
Ruby Formatter written in Python
I recently switched from TextMate to Aquamacs to MacVim and finally to Sublime Text 2. Sublime has some great features, but it was lacking ruby code formatting until now.
Get the source from https://github.com/perryqh/prettyruby
Installation:
1) Place prettyruby.py in ~/Library/Application\ Support/Sublime\ Text\ 2/Packages/User/
2) Bind a key to pretty_ruby. I changed "super+b" from "build" to "pretty_ruby"
Get the source from https://github.com/perryqh/prettyruby
Installation:
1) Place prettyruby.py in ~/Library/Application\ Support/Sublime\ Text\ 2/Packages/User/
2) Bind a key to pretty_ruby. I changed "super+b" from "build" to "pretty_ruby"
{ "keys": ["super+b"], "command": "pretty_ruby" }Migrating from Heroku Postgres to Amazon RDS MySQL
I recently moved from Heroku's built in postgres database to Amazon RDS to take advantage of Read Replica.
The following steps will get you there, too.
The following steps will get you there, too.
- Signup for Amazon RDS
- Download the Amazon RDS Command Line Toolkit
- Install the Toolkit
- Unpack toolkit. I did this in /Users/phertler/Applications/RDSCli-1.3.003
- export AWS_RDS_HOME=/Users/phertler/Applications/RDSCli-1.3.003
- Make sure you JAVA_HOME is set. export JAVA_HOME=/Library/Java/Home
- Configure credentials
- cp $AWS_RDS_HOME/credential-file-path.template $AWS_RDS_HOME/credential-file.txt
- Update credential-file.txt with your Amazon Account credentials
- Create a security group for your database
- rds-create-db-security-group --db-security-group-name mygroupname --db-security-group-description 'my database security group'
- Launch a RDS instance with an instance named myinstance database named mytestdb. Be sure to remember your username and password.
- Allow current local machine to connect to your new mysql database
- rds-authorize-db-security-group-ingress --db-security-group-name mygroupname -i
/32 - List your instances to be sure you can connect
- rds-describe-db-instances
- Now you can connect to your database from you local machine. You will need to find your RDS instance's endpoint from the AWS console. It will look something like myinstance.clxktpjkersojt.us-east-1.rds.amazonaws.com
- mysql -h myinstance.clxktpjkersojt.us-east-1.rds.amazonaws.com -u yourusername -p
Now you are ready to migrate your heroku database to RDS
- Allow heroku to connect to your RDS instance
- rds-authorize-db-security-group-ingress default --ec2-security-group-name database --ec2-security-group-owner-id 098166147350
- Add the heroku rds addon
- heroku addons:add amazon_rds url=mysql://user:pass@rdshostname.amazonaws.com/databasename
- Port your current Heroku Postgres database to your new Amazon RDS MySQL database
- heroku db:pull mysql://user:pw@myinstance.clxktpjkersojt.us-east-1.rds.amazonaws.com/mytestdb
Finished!.....well, now you can also set up the Read Replica and then set up a Master/Slave database with https://github.com/plaxis/multi_db
Labels: ec2 rds heroku
Friday, February 25, 2011
Setting up Heroku
Here are the steps I use to set up a heroku.com application. This examples sets up an application name myapp-qa. I also set up myapp-uat, myapp-staging, and myapp-production environments.
1) Create the application on the ruby 1.9.2 stack
heroku create --stack bamboo-mri-1.9.2 myapp-qa --remote heroku-qa2) Make the application use the qa.rb environment file instead of production.rb
heroku config:add RACK_ENV=qa --app myapp-qa3) Don't bundle test, development, and cucumber gems
heroku config:add BUNDLE_WITHOUT="test:development:cucumber" --app myapp-qa4) Push the code
git push heroku-qa master5) Migrate the database
heroku rake db:migrate --app myapp-qaFriday, December 3, 2010
TDD Adoption
Many developers I talk to say they have tried TDD, but it “didn’t work for them”. Why is this so often the case? I believe that the main reasons are 1) it wasn’t done correctly 2) the effort was too quickly abandoned 3) the benefits were not obvious to the developer.
1) It wasn’t done correctly.
Doing TDD the right way is beyond the scope of this post. The best ways to learn are pairing with a TDD expert and reading some of the good books on the subject. I really like The RSpec Book http://www.pragprog.com/titles/achbd/the-rspec-book and Test Driven.
2) Abandoning the effort too quickly.
At first, development time will increase until proficiency in TDD is obtained. This improvement ravine is very well documented by Martin Fowler.
3) TDD benefits
Though the TDD benefits at the micro-level are significant, the macro-benefits are outstanding! Preventing or fixing bugs early provides a huge cost benefit to the customer. The cost of fixing design or coding bugs exponentially increases with time from bug authoring.
Some argue that the same benefits can be achieved with Test After Development (TAD). In my experience, TDD is much better than TAD for the following reasons:
1) It wasn’t done correctly.
Doing TDD the right way is beyond the scope of this post. The best ways to learn are pairing with a TDD expert and reading some of the good books on the subject. I really like The RSpec Book http://www.pragprog.com/titles/achbd/the-rspec-book and Test Driven.
2) Abandoning the effort too quickly.
At first, development time will increase until proficiency in TDD is obtained. This improvement ravine is very well documented by Martin Fowler.
3) TDD benefits
Though the TDD benefits at the micro-level are significant, the macro-benefits are outstanding! Preventing or fixing bugs early provides a huge cost benefit to the customer. The cost of fixing design or coding bugs exponentially increases with time from bug authoring.
Some argue that the same benefits can be achieved with Test After Development (TAD). In my experience, TDD is much better than TAD for the following reasons:
- Keeps you focused. At any time during the day, you should either be writing a test for a feature or writing code to make that test pass.
- Less code. TDD promotes Do The Simplest Thing That Could Possibly Work (DTSTTCPW). Let’s write code that gets the product delivered instead of frameworks that may or may not ever get used again!
- Necessarily promotes testable code
- FASTER
- it’s a lot faster getting it right the first the time!
- it’s a lot faster fixing bugs as soon as they are authored
- Testing the feature before it’s implemented tests the intent of the code. When TADing, the intent could have been forgotten
- Very high code quality
- Refactor with confidence. Behavior driven tests ‘protect’ the required features, which means that refactorings should cause test failures
- Thinking of and designing for edge cases up front promotes a better and more stable design
Thursday, October 28, 2010
Authlogic for Rails 3
I forked Authlogic because I was tired of the Rails 3 deprecation warnings in my project. The forked project is Rails 3 compatible. I just made a few minor changes to how Users are saved and changed some scopes. Enjoy!
gem "authlogic", ">=2.1.6", :git => "http://github.com/perry3819/authlogic.git", :ref => "044b20289316ef6e338d"
gem "authlogic", ">=2.1.6", :git => "http://github.com/perry3819/authlogic.git", :ref => "044b20289316ef6e338d"
Labels: Rails
Subscribe to Posts [Atom]