Extending the Provenance Commits idea

Context: Refer my 2008 posting, particularly the "Provenance Commits Idea" 2/3 of the way down.

A person who's not a committer, and who's made a change on their (say) Github fork of a project, with a consequential 'pull request' for the originator to consume the change as a contribution, could sign each commit.

Whether the CLA is as I penned it, or one like Apache's or Google's for accepting back contributions, the contributor could a line detailing the hash of the contribution they have made.

It gets merged in too, along with the actual change, and consequentially has a lasting presence in the bottom of a "contributions.txt" file that has the CLA as the first few paragraphs in "we, the undersigned" style.

Source control gets to prove that the contribution is correlated with the CLA signing. Such contributors have to keep re-signing subsequent contributions to cover for the eventuality that they are one day going to change employers.

Full blown committers should be exempt from this process of course, but then they are likely to not do business in nom-de-plume style, be be known to the other developers.

Note also that committers could reject pull requests until the contributor had completed the workflow of adding to the contributions.txt file.

Maybe Github could add some workflow/automation around this....

Update:
A question from an OSS buddy: Is that "sign" as in "cryptographically sign" or some other sense?

The hashes of changes are irrefutable an part of git's way of working. The follow-up addition of that hash to the contributions.txt file would be committed by the same user (by convention), and also hashed as a change in the same way.

Now the person COULD effect both of those without PKI being involved, but they are authenticated as far as Github is concerned, but virtue of other their id/password. Its as good as cryptographic signing to all intents and purposes. Provided Github has no XSS issues (etc) where someone can commit in the name of another.

Selenium 2.0-beta-1 (WebDriver) released.

Of course, the 'beta' label for WebDriver is somewhat late, seeing as many companies have been relying on it for at least three years, but the beta-1 was pushed out yesterday.

WebDriver started at ThoughtWorks a few years ago. Its lead, Simon Stewart, and his now Google colleagues have spent a lot of time on it since. The Selenium-1.x team (Jason Huggins, Pat Lightbody, Dan Fabulich, & many more) and new committers and friends have helped production harden WebDriver to the extent where its an admirable replacement for Selenium-RC (1.x).

There is a little brand confusion as to whether this is Selenium 2.0 or WebDriver that will resolve in time, but it is true however that Selenium 1.x will have no more major releases. That means no more Selenium-Core or Selenium-RC (other than bug fix releases). The reverse takeover that is WebDriver emulating the old Selenium is good enough for prime-time usage. Actually it has probably been good enough for some time.

As a side note, when Jason and I charted the course for 'Driven Selenium' (which became Selenium-RC) we noted that it was an ill-advised idea. We were committing to porting driver code to half a dozen languages, and maintaining a JavaScript hairball that was the in-browser 'core' runner. We shuddered at the scale of the Continuous Integration build needed to make that. Simon's fresh start with WebDriver was no less ill-concieved in terms of the hodge-podge of technologies needed to complete it. The reverse take over nature of the merger back then gave us much relief because we knew that sooner or later the 1.x codeline would be dead and we would toast that overdue demise!

Good work Simon and all involved!

Watch http://seleniumhq.org/download/ for updates.

JBehave 3.0 released

The team is happy to announce the release of JBehave 3.0. This major milestone has been lead by friend of ThoughtWorks, Mauro Talevi (still no blog) and pushes the usability and nomenclature of JBehave quite a bit.

Read the announcement and release notes.

Summarizing the release notes a little: 7 bugs, 45 improvements, and 11 new features later, JBehave 3.0 is now happily a Git citizen, with repos mirrored from Codehaus to Github.

If thought of as a JUnit plugin (which is an over-simplification) JBehave 3.0 is perfect for "in the box" enterprise development now. Note also there are now plugins for Guice, Spring and PicoContainer to allow Dependency Injection to play a part in the composition of Behavior Driven Development (BDD) tests.

Frank: Automated Acceptance Tests for iPhone and iPad

Announcing Frank, a lightweight UI automation framework for iPhone and iPad applications.

[Click Here to watch the screencast in a more sensible size!]

Frank sews together several open source tools, notably UISpec, cocoahttpserver, and Cucumber. The goal is to automate basic UI-level acceptance testing of an iPhone or iPad application, integrated into a Continuous Integration system.

You can read more about Frank here.

Code Complexity Visualization for Ruby

Image from http://www.osnews.com/story/19266/WTFs_m

WTF implies lack of clarity. Clear code is easier to understand, easier to maintain and easier to extend.

Announcing saikuro_treemap -- an easy to setup tool to generate complexity treemaps of ruby code.

See a demo for yourself.

Mockpico beta

Mockpico is an interesting tool. It leverages Mockito and PicoContainer to allow easy instantiation of Spring Controllers for unit testing. Often controllers have many dependencies injected into it via constructors, setters, fields. Sometimes these would be annotated with @Autowired, sometimes not (old fashioned XML composition). When in unit tests, you don't really want to have to specify every injectee as the particular request mapping you want to test might not use them all. With Constructor Injection you kinda have to specify them all of course, though 'null' might be an OK thing to specify.

Anyway, Mockpico makes it easier :- http://github.com/paul-hammant/mockpico (scroll down for colorful diagram)

It is pushed out as beta-1d as you can see here http://oss.sonatype.org/index.html#nexus-search;quick~mockpico. A Maven/gpg learning curve conspired to make this work on its fourth attempt (a thru d).

ProxyToys 1.0 released

Five or so years in development prior to the 1.0 moment, ProxyToys has finally shipped. Well it was perfectly usable in its 0.21 incarnation, but 1.0 makes ProxyToys fully JDK 5 compatible, and changes much more too:

• Use JDK 5 language features.
• Added builder classes for all toys (refer Martin Fowler's FluentInterface).
• New FutureToy to run methods asynchronously
• New PrivilegeToy to run methods as privileged actions.

In case you did not know, ProxyToys takes Java Classes/Interfaces and makes specialized implementations like NullObject, Pooled, Multicaster, Decorated. The project was first started by (now ex) ThoughtWorker Dan North, and pushed forward by many others since then.