{"person" => { "city=>nil, "name"=> "Foo Bar" } }

It appears somewhere on the road to 2.3, the JSON encoding changed so there is no longer a top level node:

{"city"=>nil, "name"=>"Foo Bar" }

The end result of this change means that if you have consumers expecting JSON in a typical “Rails” format, with a top level element denoting the class, there will be pain. We just hit this in a project when trying to use ActiveResource to consume some models exposed via standard restful actions.

The following demonstrates how this breaks down exactly:

# in the backend web app
Person.create! :name => “foo”

person.attributes # returns a hash in the format of { “person” => { “name” => “foo”…}, which is where the problem lies

It appears this issue is fixed or on the way to be fixed in the 2.3 stable branch, but for now be wary of JSON support in general on 2.3 until more of the below tickets get resolved.

References:

We’ve added more Git knowledge to this release, courtesy some great work from Muness. Your deployment notifications will now contain the branch they were deployed from and a list of all revisions included in the deployment (since the last deploy, of course).

There was also a overhaul to the internals. Muness refactored all the email logic to a presenter, so it should easy to change the notification email to your liking. CapGun now uses Jeweler and Micronaut, to match the rest of the standards for Relevance open source.

Keep us honest by checking the build status on RunCodeRun, and file feature requests and bug reports on Github Issues.

Those are tough questions. Software is not a science, and there are no double-blind, randomized controlled projects. The study of software development barely approaches the level of a social science. Its easy to discuss the flow and intuitive sense that agile works with other people who have experienced it, but try expressing that to someone who has never stepped beyond the waterfall model.

Things are getting better in the area of real, hard studies done on agile. One example is the work being done by Microsoft’s Empirical Software Engineering Group (ESM). The summary from the TDD study is worth citing:

“The results of the case studies indicate that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects that did not use the TDD practice. Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD.”

I’ve included full links to some of the standout papers on my @to-read list below.

• Realizing quality improvement through test driven development: results and experiences of four industrial teams

• Do Cross Cutting Concerns Cause Defects? (my alternate title: “why the hell should I care about AOP?”)

• Pair programming: what’s in it for me?

• The Influence of Organizational Structure On Software Quality: An Empirical Case Study

First, make sure you have the latest portfiles:

sudo port sync

Deactivate any preexisting versions - not sure if this is strictly necessary, but I’ve seen failures when I don’t.

sudo port deactivate git-core

Install the new hotness, with all optional add-ons.

sudo port install git-core +svn+bash_completion+doc

Verify it:

git --version
# => git version 1.6.1

Note that there is a MacPorts ‘upgrade’ command, but I’ve seen it fail to actually upgrade things from time to time. Doing the install this way always works for me.

~ $ sudo port installed |grep ruby
ruby @1.8.7-p72_1+thread_hooks
ruby @1.8.7-p72_2+thread_hooks (active)

The defect on MacPorts Trac has more details, along with links to a relevant ruby-talk thread.

Its worth pointing out that this issue went from discovery to being fixed and released into the port stream in about a days time. MacPorts has really come a long way from just a year or two ago. Fairly major packages used to lag behind the latest stable releases by multiple versions, but now I find everything I care about stays up to date with ease from MacPorts. They are even able to keep up with git releases, an impressive task considering how fast and furious releases git releases come.

Kudos to the MacPorts team for doing a fine job and making developers’ lives easier.

Tarantula is a big fuzzy spider. It crawls your Rails application, fuzzing data to see what breaks. It can verify HTML validation across all your pages, ensure you don’t have 404s, and pretty much anything else you want via custom handlers.

Don’t let the version number fool you, we’ve been using Tarantula across many projects at Relevance and its very stable. This release fixed a number of annoying bugs, including namespace conflicts with other classes due to Rails dependency loading, improved gem spec with correct dependencies, and clean up on the html reporter.

Install it via the Github

gem install relevance-tarantula --source http://gems.github.com

or via Rails 2.1+ gem handing:

config.gem "relevance-tarantula", :source => "http://gems.github.com"

My capistrano task was a very simple call out to the ‘get’ helper, which just uses scp under the hood. The task ran and looked as if it completed, only nothing was ever transferred and the scp progress bar never came up. Sometimes it would block and do nothing, which was real fun, too.

The solution was simple - change all the bash scripts we use to not output any echo anything when running. I deployed the new scripts to all servers I needed to scp with, and the issue was resolved.

Since this is a known issue in the faq, it won’t be fixed or improved with a better error message. It’s just something you need to be aware of and work around, either via detecting if the session has an interactive terminal before sending output or removing your output statements altogether from you startup scripts.

Ok, so a 26 meg repo takes almost three times as long to copy via a recursive cp than a local git clone. Thats a fairly small repo, lets try something bigger:

The rails repo at 75 megs is still ~ 3 times faster.

Obviously, this is not scientific at all, but the point is pretty clear. Git is doing some magic that lets it move files around locally 2 to 3 times faster than a plain copy. From looking at the man page, I would guess it has something to do with git using hardlinks for things in .git/objects when cloning locally. My linux fu falls down a bit here -- what are the ramifications of using hard links versus doing a "real" copy?

(This also makes me want to try out gitbak even more...)

Looks fine, right? Maybe you've hit this already, and you see it immediately.

The symptoms are that the DateTime.now always seems to be a bit off - maybe you just restarted your server and its a only a few minutes off.

The bug is that DateTime.now gets evaluated at the time the class is loaded, not when the finder is run. What makes this easy to miss is that it will always work fine in tests and development, as everything is constantly getting reloaded there.

The fix, obvious once you've spent a combined time of over an hour trying to figure out what is going on:

• You have to turn transactions off for the scope of the test, or suffer very confusing issues, since Bj itself wraps the job submittal within a transaction. The way I did this was just overriding the use_transactional_fixtures method in the one specific spec.
  PLAIN TEXT
  RUBY:

  1. describe Foo
  2.   def self.use_transactional_fixtures
  3.     false
  4.   end

• Remember, bj = background job. This may seem obvious, but whatever you submit to bj will be running in an entirely different process, so in our spec you need to wait for that job to complete before trying to assert things. You can do something as simple as this:
  PLAIN TEXT
  RUBY:

  1. MAX_TIME = 10.0
  2.     seconds = 0.0
  3.     while(job.pending?) do
  4.       job.reload
  5.       seconds += 0.5
  6.       sleep 0.5
  7.       raise if seconds> MAX_TIME
  8.     end
  9. # normal assertions here

  This gives your job up to 10 seconds to finish, and will timeout if it takes too long, which usually means something has gone wrong.

• You now have to watch multiple logs to figure out what is going on. So tail your test.log and tail the bj log as well, and run the script in isolation to make sure you understand where exceptions and syntax errors will go. I wasted some time scanning logs when I really need to check the job.stderr field that bj populates, so be sure to output that for common test failures.

Overall, I've been pleased with bj, besides some open questions I've still been working out by perusing the source. Check it out if you need a easy to use persistent job queue.