BDD not so much, really? Part II

on May 28, 2009 @ 07:38 AM

I think there’s a confusion that BDD == toolset (ie. Cucumber, Cucumber+RSpec, rspec). That needs to stop. BDD is an approach to software development. You drive your software by focusing on behaviour. This is usually done by focusing on behaviour from the outside-in. This starts by identifying the behaviour of the application, then driving inward until you get down to the low level components.

Focusing on behaviour may yield different tools throughout the process. Cucumber and RSpec are just two examples. You could very well use Cucumber plus test/unit, or perhaps just RSpec, or maybe nothing at all. These are just tools to support a development style. They are NOT the development style themselves. You can use Cucumber in a way that doesn’t support BDD. Same goes for RSpec and any other tool.

I realize there are people who don’t buy into the RSpec philosophy. To them it’s just another take on unit testing. I do buy into RSpec. From day one RSpec’s goal has been to be a BDD tool that tries to get the words right. Can you use xUnit libraries in a way to achieve the same affect? Yes you can, but most of those usages have been heavily influenced by RSpec which was built on the ideas and motivation for BDD and “getting the words right”.

Without this focus many of the high level test/unit style add-ons (especially in the ruby world like context, shoulda, test/spec, etc.) wouldn’t exist. So to me, this makes the subtle differences very important as it changed how everyone wrote their tests.

For me personally, testing is an activity after you write code. I find it refreshing to talk about writing code examples to drive design and tests to talk about actual testing. Perhaps it could be phrased as, you start with examples and when you’re done you end up with tests. Similar to starting with user stories and ending up with features. Right now that works in my head, but it’s late and I may need to revisit that thought after a few hours of sleep.

Example is just a better word then test to. When you talk to someone and you don’t understand what they’re talking about you don’t say, “give me a test”, you say, “give me an example”. Well, that language is more natural. You are providing an example of how something should work. This example ends up providing regression (test) value once its implemented, but you didn’t start with a test, you started with an example of the code you wanted.

BDD not so much, really?

on May 28, 2009 @ 06:05 AM

Updated May 29, 2009

This rant is in response to http://robertlally.com/post/bdd-not-so-much

BDD didn’t start off as a replacement for TDD. It started off a way to better understand and explain the process of TDD. The name change as I understand it was to communicate the intent of TDD in a clearer and more direct way. You’re not writing tests for the sake of writing tests, you’re driving behaviour. Focus on the behaviour you want to achieve first and foremost. Use that behaviour as the driving force for your examples (or tests).

Corey Haines nailed it on his comment to the same post, “BDD is no longer a replacement for TDD, but, rather it is a workflow for creating a system that more closely resembles what the client is looking for.” I think two of best tools which exist to support the BDD workflow of outside-in are Cucumber and RSpec. Cucumber for higher level system behaviour and RSpec for driving lower level design.

In the article, the author criticizes the “should” language. Rather than simply scoffing at the idea of replacing “assert” with “should”, I tend to think about it in terms of natural communication. The reason I like “should” language over “assert” language is that when I’m communicating with another developer I don’t say, “assert equal one day to do things good”. That doesn’t make any sense. I say, “one day to do things to should be good”. It’s much more natural for me to write closer to the language I think and communicate than it is to translate it to assertion-speak. I want to communicate in my code more closely to how I communicate to other people.

While the term BDD is a few years old it takes a while for dialogue to happen, and understanding to occur. I’m sure a lot of people hear about BDD, read about it from Dan North’s Introducing BDD . BDD started as a way to explain and better understand BDD, but what I think was realized was that it was much more than simply TDD.

Many tools are emerging which claim to support BDD-style development. It’s important to note that BDD isn’t the tool. You can have many tools support BDD style development in different ways and to different degrees. Although a good tools makes any process easier, what makes BDD is the mindset you have and how you go about writing software. Certain tools emerged with this in mind and are thus labeled BDD tools. Cucumber, RSpec, and JBehave are some examples.

The article mistakingly sheds Cucumber in the light of solely driving the design of code and suggests its a bad tool to do that. Of course it is! It is not a tool intended to drive the design of your code from a low level. It is to communicate in plain text how the application should behave. The plain text is something that is business readable, something that adds value not at the code design level, but at a higher level: communication and understanding requirements!

Cucumber is equivalent to a high level integration test for those of you who come from a testing background. It runs the entire application (or whatever can be reached through automation, different types of systems have different limitations). It works in combination with a tool used to drive out the design of your application using lower level code examples. For example, RSpec.

The #1 output of BDD is a working application that is behaving as expected. In addition to that you have an application-level regression suite in which you can run against the code base at any time. You also end up with smaller, more focused code examples which provide regression against isolated behaviour of the system.

Combined, you end up with documentation at two critical aspects. The first is business readable scenarios that the system supports. The second is developer documentation made up of the lower level code examples. Since these are often written more clearly than assert-style syntax it’s easy to produce human readable behaviour specifications for focused pieces of behaviour. And in the end you have a repeatable process which allows you to confidently produce the working software.

I also don’t see where UML to BDD comparisons make any sense. UML is a modeling language. BDD is more of an approach or methodology. A more accurate comparison would be plain text scenarios vs. UML. Although that makes little sense as a comparison because UML is not something you can give a non technical person to write, read, and edit.

BDD by itself doesn’t fix any problems. It provides an approach which focuses on behaviour first. To me, there’s no point in building a low level library if you’re not aware what higher level problem you’re solving or objective you’re adding value to. This boils down to a person still has to “do the work” to make it successful.

At the end of the day though I cannot speak for anyone else except myself. Shifting my focus on behaviour rather than “tests” led me to write better code examples. Often times I would write less of these because I was writing better examples. It’s also helped improve communication between myself and my team, customers, and other developers. BDD may evolve into something else, or perhaps a new perspective will come around that will take the world by storm. I am all about continuous learning and improvement. And I invite any ideas Mr. Lally or anyone else brings to the table.

Also, BDD never claimed to be THE answer. Any process that claims to be THE answer will surely not be THE answer for everyone in all situations. BDD has been an answer for many people though and as of now it will continue to be an answer for me in how I work.

A good resource worth checking out for BDD, it’s philosophy, and how to apply it in practice is The RSpec Book

rspec/cucumber ML email etiquette

on May 09, 2009 @ 03:18 AM

Aslak Hellesoy requested on the rspec/cucumber mailing list the other day that folks stop top posting. His words:

I find it really hard to follow conversations that use top posting (http://en.wikipedia.org/wiki/Posting_style). If you have a [Cucumber] topic, please respond with inline comments. And use plain text email – not html.

I agree with Aslak’s request for the most part. There are times when top posting is perfectly acceptable, but those are too often blurred by the countless times where people are just plain lazy. While most of the replies have been rather humorous in response a couple recent replies have the look of actual requests to the community: snip out things not pertaining to your reply and the removal signatures.

The only part I don’t agree with is the text email. I’m sorry, but if you use an email client which can’t show html, or can’t not show the html part of an email then you need to find a new email client. I have the feeling Aslak was referring to folks that only send HTML email, void of a plain text part. If that’s the case I am in full agreement with his request.

Aslak’s request was well intended and thoughtfully brought about. I hope the replies stop before there is a giant list of dos and donts, followed by a flamewar that will most likely have a negative impact on such a wonderful community.

RSpactor, love Cucumber

on April 28, 2009 @ 10:02 AM

If RSpactor loved Cucumber it’d be even more amazing. From the ticket request:

It would be amazing if RSpactor integrated with Cucumber although 
it would need to be a different than how it currently works with 
RSpec. Now that Cucumber has tag support I think this good be done 
in a reasonable way that improved the developer workflow for 
projects that utilized Cucumber.

Here's an example. When I am working on changing how money is 
managed in my app I know that I want to run the features tagged 
@accounting. At the start of my work it'd be great if I could 
add the @accounting tag to RSpactor so it would run those 
features after it successfully ran specs. 

Perhaps there would also be a preference setting which auto 
ran the Cucumber scenarios after specs ran, or one that forced 
you to manually hit play. Although if you had typed in tags, 
it the play button would run cucumber with those tags. 

Got a better idea for Cucumber integration? Join the discussion! http://github.com/rubyphunk/rspactor/issues/#issue/1

Managing Client Expectations

on April 08, 2009 @ 01:15 AM

Managing client expectations is simple, but like most things simple—it’s very hard to do, do right, and do consistently. I think this is a common problem in today’s web development companies. The industry has a lot of young, creative, and smart people building companies with little to no experience in customer relations. For every person who is naturally gifted or good at managing client expectations there are probably several more people who just don’t get it. And the worst part, is that they probably aren’t aware of the fact that they don’t get it.

I’m one of those young, creative, and somewhat smart people in the industry trying to build a company in the web industry, but this is an issue that has been nagging me for months, and it’s to the point where I feel like it needs to be shouted from the mountain tops (although this blog is probably more like a anthill). It may not be the best business decision on my part since it encourages competing companies to become better. If they do it will make us humans work that much harder.

I’m sorry to say it, but few web development companies seem to do a good job of development and a good job of managing client expectations. Maybe your company is good at development, but stinks at managing client expectations. Or maybe it’s the other way around and you are great with the customer, but your team is a bunch of junior developers who crank out crap. Oddly enough, if your company falls into the latter you have a much better chance of being successful and surviving than the former.

Before look at some of the effects of managing (and failing to manage) client expectations let’s start with a simple definition:

Managing client expectations is the ability communicate proactively with the client in a reasonable and realistic manner that allows them to take ownership of decisions that may affect their project or business.

Managing client expectations is about communicating honestly, openly, and often with the client. It requires informing them of things that have the potential to impact their business or their project. I use the term proactive in the definition because you’re not doing it right if you do something and than communicate after the fact. Heck, doing that is like this the plumber who came to your house and failed to manage your expectations:

A plumber comes to your house to fix your toilet. At first glance it looks like it’ll take an hour to do so you set aside $100 on the counter to cover the cost and leave so the plumber can work in peace. While working the plumber discovers a much bigger plumbing problem. He’s really in the zone though, so rather than calling you he just does what’s necessary to fix the issue. You get home later in the day, and on the counter you see your $100. Next to it is an invoice for $2,200 and a note that reads: I ran into a bigger problem, but I was really in the zone so I replaced the plumbing in the basement because it would have had to have been done.

Do you feel the plumber did a good job of managing your expectations? Would you hire that plumber back? Would you pay the bill? I would answer three hell nos. Yet, many web developers and young web entrepreneurs find this perfectly acceptable and they wouldn’t think twice about doing it. To them it’s just how you move a project along its merry little way.

For folks who aren’t aware this is a problem—it is a problem and you should stop doing it. For folks who do it and know they do it, wake up, its unhealthy for your client, you, and your business.

I think it’s universal knowledge that finding a new client is more costly then keeping a client. Every time you interact with a client you have a chance to increase or decrease your likelihood of keeping them as a client. When you manage their expectations well you will most likely keep them. Here are three general reasons why:

• build a healthy relationship
• build trust
• empower the client, giving them ownership

Positive effects of managing client expectations

Build a healthy relationship

Every time you interact with a client you have the ability to build a slightly better relationship. Setting clear expectations with the client with good solid communication strengthens the bond between you and your customer. Customers who have a healthy relationship w/their suppliers are not likely to jump ship.

A new developer joins your team. Every time you work with him you notice he takes the time do things right rather than just quick. He also seem to ask questions and raise questions at all the right times. You find yourself comfortable working with him and before you know if you even think that you do better when working with him. When the developer’s 90 day review comes up you’re first to speak up and ask the team to keep him.

Build trust

Part of building a healthy relationship is trust. To me, trust is like trying to level a character in EverQuest. As you build up stats and level you gain a new skill or perhaps a new magic. The higher you level the more your character is capable of. The same is true for the relationship with a client. As you achieve new levels of trust with your client you achieve new capabilities for doing things. Perhaps your client sends you more work. Perhaps your client refers you to his peers and to other companies. Perhaps your client invites you to more business-oriented meetings because he wants you involved in streamlining technical aspects of their business. Perhaps you become the goto shop for your client’s organization. Without trust this is not possible.

A new developer joins your team. After the first few months of working with her you find she is a good, honest, hard working, and capable developer. You build up trust in her as a developer. A potential client comes in and you need to send over a couple developers to help kick off the first Planning Game and do some story estimation. You send her. You know she’ll do a good job, ask questions, and be honest.

Empower the client, giving them ownership

Empowering the client is something that we really need to do a better job of in our industry. Managing a clients expectations lets the client own the decisions that need to be made that impact their project or business. These decisions are not ours to make, they are our clients. When the client owns the decisions, they own the project, they own the direction of the project. This isn’t to say we don’t guide or assist our clients in finding that direction. This is one of the many reasons we are often hired, however, when a client gives you permission to make decisions for them, they made that decision. When that’s not the case and we make decisions for the clients we are simply being lazy and bad vendors.

As a developer who practices Behaviour Driven Development I want my customers to own the scenarios that are written to drive the development of an application. The customer may physically write any of the scenarios. I may type them while sitting with the client, or during a phone call, but I am merely being a scribe. They own the scenarios. I never want the customer to feel that scenarios are written simply to translate business speak to technical speak, I want the customer to own the scenarios so its clear to them what they are paying me to build. Doing this empowers the client, it gives them ownership. They are usually much more engaged in the project when this happens.

Negative effects of failing to manage client expectations

Now, when you don’t manage client expectations you can have the opposite effect:

• hurt the relationship
• lose trust
• empower yourself, taking ownership away from the client
• increase the risk you negatively impact the clients business

Hurt the relationship

Not managing client expectations hurts the relationship. You may get away with it once, twice, or even three times, but sooner or later you will guess wrong and your customer will be ticked off. This is usually when they start looking for a new vendor.

Your customer has a feature they want added. You estimate 50 hours. It ends up taking you 110 hours. You don’t tell the client, you simply send them a bill. The customer is ticked, he asks that you stop working until the bill can be addressed. He wants to do a phone call with you to dispute the bill. Your customer is not happy.

Lose trust

Losing trust is a part of hurting a relationship, but trust is so important on its own. Most companies want to be a partner with the client. They want the client to leverage their expertise in solving a problem. If we don’t have that kind of relationship we lack the trust required for the customer to to utilize us in that way. Every time we fail to manage a client’s expectations we lose a level of trust. At some point its gone, and we’re out of the picture.

Empower yourself, taking ownership away from the client

Making decisions that affect the client’s project or business are a big no no. It takes ownership away from the client and only empowers yourself, but that empowerment only lasts a short while. You may have won the battle, but you will surely lose the war. First of all, decisions that impact the client’s project or business are theirs to make—not yours. Sometimes an emergency arises, the app is down! Chaos ensues! What to do? One of the very first things you do is call your client and give them the ability to say “no, don’t fix it”. Even though that answer may be highly unlikely, its not your decision to make, unless you have an arrangement with your client to make those decisions. Perhaps you have an agreement which covers what to do in those circumstances. If you do, more power to you. If you don’t, you may want to consider getting one.

Maybe you’re wondering what happens if you can’t reach the client? Do you wait to fix it until they call you back? I would say that depends on the nature of the issue. At minimum you should leave a voicemail and send a quick email, both which have your contact information. Doing this allows you to do everything reasonably possible to contact the client of the issue. And it may add 30 seconds to 2 minutes of overhead. This is usually reasonable. However, this is one of those times where it depends based on the relationship you have with your client. Fixing the issue first and responding later may be acceptable based on your arrangement. My belief is that if that’s not your arrangement than you should be contacting your client. Well, you should be contacting them anyways—that’s just being a good vendor.

The client’s site goes down. You get a call from one of their programmers (not a decision maker or gold owner) about it. You log in, evaluate, and decide to tackle it. Some time later you get it fixed! Woot! Invigorating, wasn’t it? Then you send a bill to the client. The person who pays the bill and has decision making power for paying the bill is very upset. Why a $1,200 bill? And why wasn’t he made aware of it? He heard from his one of his programmers their was an issue, but that it got resolved, why is the vendor sending a bill?!!

Increase the risk you negatively impact the clients business

Every time you make a reckless decision on behalf of your client without having some kind of prior arrangement or relationship in place you increase the risk that you will negatively impact their project or business. These are risks that are not yours to own, they are your clients. They always deserve the ability to say “no” even if it seems highly unlikely. The only time they shouldn’t have that option is if someone’s physical health is in immediate danger, but I haven’t seen any webapps running medical equipment, handling stop lights, or coordinating the release of water at Hoover Dam.

BDD w/Rails Class

on April 03, 2009 @ 02:30 AM

Shortly after RailsConf and while The RSpec Book is hitting the printers I’m going to be teaching a BDD w/Rails class with the amazing guys at Collective Idea

• Official announcement – http://mutuallyhuman.com/2009/4/3/bdd-with-rails-class
• Offical Course – http://ideafoundry.info/behavior-driven-development

Hope to see you there!

Scenario Observation

on March 20, 2009 @ 12:00 AM

One of the hardest things about being the developer and the scenario writer is that we’re in the thick of it. Once we get something written down we want to get it to work and then move on. This may involve copy and pasting part of an existing scenario to just get the job done. We get antsy.

One of the benefits of having the customer (or someone else) write the scenario is that we get to be the critic and not the author. We can focus on the scenario and ask questions like: does it read well? Is it doing too much? Is doing little? Can I understand its intent? etc. etc.

When working with a pair our pair should really challenge us to write good, communicating, intention revealing scenarios (just like they should be doing with code). This can be hard when we are working solo because we may just be staring at the screen for too long, and we can’t see the forest for the trees. If that’s the case grab someone else for a quick review, even if it’s after you finish implementing the scenario. Refactoring applies to scenarios to.

Scenarios are like code, if we don’t tend them well, they will grow messy and hard to maintain. We are best served to spend a little time upfront to keep them tidy rather than wait until we have hundreds of steps that don’t do a good job of communicating and require people to have to read through all of the step definitions to figure it out.

Go forth and code! ;)

ar-extensions 0.8.2 released

on March 17, 2009 @ 02:09 AM

ar-extensions 0.8.2 is released. This release fixes compatibility issues with Rails 2.3.1 and Rails 2.3.2. It should show up soon at a rubygems mirror near you.

Thanks to Stephen Heuer, Glenn Rempe, and Michael Murray.

gem install ar-extensions -v 0.8.2

CachingPresenter has moved

on February 14, 2009 @ 11:03 PM

The new home for CachingPresenter is: http://github.com/mhs/caching_presenter

What is CachingPresenter?

CachingPresenter is a very small presenter pattern implementation in Ruby. In short, the presenter pattern is a technique used to separate presentation logic (aka display logic or view logic) from domain logic and from the view templates themselves. There are a number of reasons this pattern is beneficial when used:

• it stops presentation logic from creeping into domain objects and muddying up their implementation and their business logic
• it stops unnecessary logic from creeping into the views themselves which should be as simple, flexible, and changeable as possible
• it allows you to organize presentation logic in better ways than simply maintaining helper modules that are included everywhere

CachingPresenter seems to be benefit most web-based projects where there is benefit from a separation between the view templates and corresponding presentation logic. It works superbly with Rails, but it is not dependent on Rails. You can use it for any ruby project, web-based or not.

Recent Changes

:requiring is removed in favor of :accepts

The :requiring option has been removed in favor of :accepts. This allows all additional arguments to be optional. For example:

1
2
3
4
5
6
7
8
9

class NinjaPresenter < CachingPresenter
  presents :ninja, :accepts => [:sword, :agility]
end

# supplying all options
ninja = NinjaPresenter.new :ninja => Ninja.new, :sword => Sword.new, :agility => 100.percent

# supplying only some options, previously this would yell at you for not supplying :agility
ninja = NinjaPresenter.new :ninja => Ninja.new, :sword => Sword.new

Caches hash-reader methods

If a presenter defines the #[] method or if what is being presented on responds to the #[] methods all calls to the presenter using hash-like accessors will successfully be cached. Previously this would die.

1
2
3
4
5
6
7
8
9
10

class SamuraiPresenter < CachingPresenter
  presents :samurai, :accepts => [:stats]

  def [](key)
     @stats[key]
  end
end

samurai = SamuraiPresenter.new :samurai, :stats => { :dexterity => 80.percent }
samurai[:dexterity] # => 80.percent

Does not try to cache writer methods

Usually you don’t use writer methods on presenters, but every now and then there is a good reason. Previously, CachingPresenter would completely fail if you writer to define an writer method, now it doesn’t. And it will successfully not be cached.

1
2
3
4
5
6
7
8

class SamuraiPresenter < CachingPresenter
  presents :samurai, :accepts => [:stats]

   # previously this line would have failed miserably
  def sword=(sword)
  end

end

Questions / Docs / Contact / Etc

Any questions, checkout the github page and its corresponding wiki . If all else fails let me know, zach dot dennis at gmail dot com

ar-extensions 0.8.1 released

on February 10, 2009 @ 01:15 AM

ar-extensions 0.8.1 is released. This is primarily a bug fix release to ensure it works successfully with Rails 2.2.2. Here are the changes:

• fixed issue in http://zdennis.lighthouseapp.com/projects/14379/tickets/14-join-table-conditions-broken
• Updated usage of Inflector to point to ActiveSupport::Inflector
• Fixed bug where finder conditions which use arext-suffixed keys and normal field keys would fail when using a conditions hash. (Gabe da Silveira)
• added timestamps options to not automatically add timestamps even if record timestamps is disabled in ActiveRecord::Base (Thibaud Guillaume-Gentil)
• Updated to use alias_method_chain so that multiple aliased finders remain intact (Marcus Crafter)

It may take a little while for the gem to show up in the rubygem mirrors. Thanks to everyone who contributed!

Long time, no see

on January 06, 2009 @ 09:13 AM

It’s been a long while since I’ve written. It’s been more due to time constraints than anything. Last spring I joined Mutually Human Software full-time, then in the early summer spoke at RailsConf, and then in the late summer started working on the RSpec Book. 2008 was a very busy year all the while spearheading a project for the state of Nebraska.

I have a lot of rough draft articles I’d like to clean up and push out, as well as finish Annex—the soon-to-be 1.0 release of ar-extensions. In the meantime I am going to be pushing some things out to MHS’s blog like the recent post on Using custom ActiveRecord events/callbacks .

We’ve also just wrapped up the year with finishing a project for one our clients. If you need assistance with an existing project, or are looking to get a new project off the ground, or are interested in training/consulting we do that over at Mutually Human. Our specialty is web applications. Be sure to drop us a line at zdennis at mutuallyhuman dot com.

Stay tuned, this is going to be an eventful Spring both at continuousthinking and MHS,

ar-extensions 0.8.0, forgot to mention

on August 16, 2008 @ 02:17 PM

I forgot to mention that ar-extensions no longer loads adapter specific functionality by itself. You need to tell it what you want. For example if you want to load import functionality for MySQL you’d have to require the right files, like so:

1
2

require 'ar-extensions/adapters/mysql'
require 'ar-extensions/import/mysql'

Sorry about that.

ar-extensions 0.8.0 released!

on August 06, 2008 @ 07:46 PM

ar-extensions 0.8.0 is finally released! All known bugs and compatibility issues with Rails 2.1.0 have been resolved.

• 0.8.0 does not work with the latest Rails edge due to some additional features on edge that weren’t in 2.1.0
• 0.8.0 should not be used with Rails 2.0.2 or below

If any feature requests or bugs please report them on lighthouse

Installing

gem install ar-extensions

Oracle and PostgreSQL users

If you’re using ar-extensions 0.7.0 with Oracle or PostgreSQL I am very interested to find out if 0.8.0 works fine. I don’t have Oracle, and I’m not a PostgreSQL user. If you’re interested in running the test suite against one of those databases please let me know.

Thanks for your patience and enjoy!

cheat --execute

on August 01, 2008 @ 03:21 PM

I hate having to continuously lookup the steps to install things every few weeks. The cheat gem works for most things to find installation instructions relatively quickly, but sometimes I just want to install something, not necessarily have to search through lines of example usage to find the installation instructions. Enter two new options for the cheat gem: dash x and dash dash execute. It’s simple. For example:

1
2
3
4
5
6
7
8
9
10

cd /some/dummy/rails/project
cheat install_rspec_rails -x

  # This is to install the latest rspec/rspec-rails into 
  # a rails project. 
  script/plugin install git://github.com/dchelimsky/rspec.git
  script/plugin install git://github.com/dchelimsky/rspec-rails.git
  script/generate rspec

Would you like to execute the above sheet? (Y/N)

I’ve sent defunkt a pull request on github, I hope it includes the change. Until then, the change is only on my fork: http://github.com/zdennis/cheat/tree/master

To install do the following:

1
2
3
4

git clone git://github.com/zdennis/cheat.git
cd cheat
rake package
sudo gem install pkg/cheat-1.2.2.gem

Enjoy,

ar-extensions, Rails 2.x followup

on July 18, 2008 @ 01:41 AM

First things first, ar-extensions moved to Lighthouse and Github. So please no more tickets or patches on rubyforge. I’ll close out or move over the ones on rubyforge that currently reside there.

• ar-extensions at Lighthouse
• ar-extensions at GitHub

Now, the fun stuff.

ar-extensions and Rails 2.x compability

For the most part ar-extensions 0.7.0 (and below) is not compatible with Rails 2.0.x and 2.1. The import functionality works, but ar-extensions will bork on some edge cases of using ActiveRecord::Base.find methods. It won’t return the wrong value, it will simply raise an exception. So if you’re using ar-extensions in your Rails 2.x app, the app itself will probably bork (and I realize that you probably already know this). If you’re using the import functionality in isolation then you should be fine.

Some of the loading issues with ar-extensions that people had are due to ar-extensions being loaded during the time that Rails goes through the loading process (if you put require ‘ar-extensions’ in config/environments/development.rb, test.rb or production.rb). You can get around this by moving if after the Rails::Initializer.run block in your config/environment.rb file.

Tonight I made several commits to get ar-extensions closer to Rails 2.1.0 compatibility. HEAD right now is Rails 2.0.1 compatible, but not 2.0.2 or 2.1.0 compatible. As soon as ar-extensions is compatible I will release 0.8.0. I am hoping for it to be released within the next few days. And by compatible I mean that ar-extensions not only passes its own tests, but it also doesn’t break any of ActiveRecord’s tests.