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
Convert your Sass
sass-convert --from sass2 --to sass --in-place --recursive app/stylesheets/.
will convert Sass 2 to Sass 3
will convert Sass 2 to Sass 3
Labels: Rails
Memcached undefined class/module in development environment
I had some trouble tracking down the cause of a undefined class/module error from the memcache client so I thought I would share my findings.
The memcache-client uses the ruby core Marshal.load to retrieve the cached values from the memcached server. In this context, Marshal.load does not have the benefit of the Rails class-loader, which results in the above error.
The memcache-client uses the ruby core Marshal.load to retrieve the cached values from the memcached server. In this context, Marshal.load does not have the benefit of the Rails class-loader, which results in the above error.
To fix:
- Set cache_classes=true. This is probably already set to true in every environment except development. The class will have already been cached before the Marshal.load if caching is turned on.
- Make sure that cached classes are referenced in the controller before cache retrievals are attempted. This is usually accomplished with a before_filter in the application_controller.rb
- Leave cache_classes=false and set the cache_store to a server:port that is not running memcached. When rails encounters the caching block, it will try to fetch from cache and find nothing because it cannot connect to the memcached server. It will then execute the code inside the cache block successfully.
Option 1 is is not desirable because server restarts are required for clients to see updated server classes. I really don't like option 2 because we are adding development-only code to production code. I like option 3 because I don’t need memcached running in development mode.
config.cache_classes = false
config.cache_store = :mem_cache_store, '127.0.0.1:11211', {:namespace => "dev"}
Labels: Rails
Remote Pair Programming
I have been successfully pair programming remotely almost every day for the last 3 years. It is very much like local pair programming with some minor differences.... OK. Some major differences, too.
Major
Instead of sitting down with your partner and sharing the same monitor and possibly the same keyboard, the screen will need to be shared virtually. There are many options including GNU Screen, iChat, Skype, yuuguu, yugma, and TeamViewer. Also, something like Google Talk or Skype should be used for voice chatting.
Minor
You know when you are talking on the phone that your attention is more focused on the conversation than when you are locally talking to someone? The same happens in remote pair programming. It is very intense and productive because both developers are extremely focused. You really need to remind yourself to take breaks, switch navigators, and go to lunch!
Labels: Agile
Teamicide
A couple of years ago I had the benefit of seeing agile contrasted against waterfall with the same development team on the same project. The team had recently delivered the 1.1 version of a global web application. The customer then took over the project by replacing the project manager and business analysts with people who had no agile experience.Up until after the 1.1 release our highly productive team absolutely loved coming to work in the morning. We were eating up storing points with an insatiable appetite and pressure to perform came from inside the team. Frequently our roles would cross. Developers would help out Testers and BAs as needed and the Testers and BAs worked very closely together to document proper story acceptances.
When agile was dropped for a more traditional process, things deteriorated very quickly (teamicide). I noticed major negative consequences in user stories, project planning, management, and software development.
Stories
The agile team that was together from inception through release 1.1 benefited from testable stories with high value features. Developers worked with Business Analysts to identify tasks within a story that would require significant development time so that the Product Owner could make informed decisions on whether or not a particular feature provided enough business value to warrant the cost. The BAs also enjoyed lower cost alternatives provided by developers. Only minor changes to a story were allowed after a pair of developers started on it. Significant changes required a new story.
After release 1.1, pseudo-stories were created with many nice to have, but not critical requirements with no developer input. Story requirements changed throughout the iteration including after the story delivery.
Planning
The agile team assigned points to stories during the inception. The amount of points completed during an iteration determined the team's velocity. The average velocity over the last two iterations was used to predict release dates.
The new project manager on the post-1.1 team planned out the next four releases in Microsoft Project with no input from the developers. The releases had unrealistic delivery dates for features that were not yet defined. This is the classic "phony deadline" technique used by managers to (de)motivate developers.
Project Management
The agile project manager was deliberately inattentive to enable the team to self-organize. This resulted in very high morale because developers felt free to contribute ideas and felt a sense of project ownership. The agile project manager's primary role was to remove obstacles that would otherwise distract the team.
The new project manager micromanaged all aspects of the project. We continued to have a stand-up every morning, but as each person gave a status, the PM would ask further questions like "how much longer until the story is completed?".
Development
Pre-teamicide, pairing time was protected, the velocity was high, the code quality was good. Pressure to perform came from other developers. All of this was achieved a sustainable pace with little or no overtime.
Post-teamicide, development time was highly fragmented through frequent meetings, phone calls, and IMs. The velocity was very low and pressure to perform came from the project manager who had set unreasonable deadlines. Large amounts of overtime were required, which led to many more bugs in design and code.
Conclusion
This project thoroughly convinced me of the effectiveness of the agile methodology. It was a great learning experience, but I hope it is not repeated!
Labels: Agile
Subscribe to Posts [Atom]