Monday, April 13, 2015

Presenting Abstract Feature Branch at Montreal.rb April 2015

I am giving a talk at this month's Montreal.rb user group, taking place next week on April 21, 2015:
http://www.montrealrb.com/2015/04/april-21th-meetup/

Abstract:

How many times do you find yourself near the software release finish line on an exciting new feature only to be pulled off by management in the last minute to sneak in some higher priority emergency fix? What do you do with the unfinished feature's code if parts of it were already functional and merged into master? Do you pluck it out and move to a remote feature branch? Do you simply comment out the code not ready for exposure to the customer? What about some of the nice software design improvements that were done as part of the feature and are being put to good use by the team today? Do you also put design improvements off till the feature is deemed by management high priority again?

These questions typically get decided on by the team on a case by case basis, and often with big compromises affecting both project delivery and code quality.

While consulting for Sears in 2009 and working at Groupon.com in 2012, I happened to work in teams that adopted a very effective and inexpensive solution to the problem called "Branch by Abstraction", a technique originally popularized by Martin Fowler, author of UML Distilled and Patterns of Enterprise Application Architecture.

In this talk, I aim to explain Branch by Abstraction and demonstrate how to apply in Ruby using a gem I wrote called Abstract Feature Branch, partly inspired by the internal team libraries used at Sears and Groupon. The gem has already had over 50,000 downloads from rubygem.org and has been utilized in several of my newer projects, including launch of EarlyShares.com and enhancements of Factor75.com.


Attendees should walk out with basic understanding of Branch by Abstraction and enough knowledge of Abstract Feature Branch to be able to explore further in their own projects after the talk.

Tuesday, April 07, 2015

SuperModule v1.1.0 is the New Sherif in Town!

After posting an article on AirPair.com about SuperModule v1.0.0 and getting quite a bit of feedback on it in the form of article reviews and reddit posts, I decided to make a new revision with quite a number of improvements, which was released yesterday as SuperModule v1.1.0:

What's New in v1.1.0?

  • Brand new self-friendly algorithm that ensures true mixing of super module singleton methods into the including base class or module, thus always returning the actual base class or module self when invoking a super module inherited singleton method (thanks to Banister for reporting previous limitation on Reddit and providing suggestions)
  • New included_super_modules inherited singleton method that provides developer with a list of all included super modules similar to the Ruby included_modules method.
  • No more use for method_missing (Thanks to Marc-AndrĂ© Lafortune, a Ruby language contributor, for bringing up as a previous limitation in AirPair article reviews)
  • New dependency on Banister's method_source library to have the self-friendly algorithm eval inherited class method sources into the including base class or module.
  • Refactorings, including break-up of the original SuperModule into 3 modules in separate files
  • More RSpec test coverage, including additional method definition scenarios, such as when adding dynamically via class_eval and define_method
Cheers...