Last week was the crucial week on my current Lucene -> Solr project for making our goals.  A lot of work the previous couple of weeks came together.  I wanted to take a couple of minutes and just record some of the little things that I’ve been learning about:

Solr

Sunspot is the up and coming solution for integrating Solr into Ruby on Rails, and fortunately enough, the 1.0 release (followed quickly by 1.0.1!) has just come out last week.  Between acts_as_solr and Sunspot, Sunspot wins hands down for it’s support of a master/slave Solr configurations, embedded Solr for testing, richer indexing semantics, and not being tied to ActiveRecord.  The companion sunspot_rails gem does give wonderful ActiveRecord integration however.

Solr cores are the bees knees!  We’ve built a simple RoR webapp using HTTParty and the Solr API that allows you to perform all the admin functions for cores, and allows you to quickly clone a core for your own nefarious purposes!  Simplifies hacking around with a new schema or configuration without having a local copy of Solr running.  Allows multiple QA environments to potentially share a single Solr infrastructure.

Solr master and slave setup in a single VM.  While pointless from a scaling perspective, it’s a really great way to work out the kinks!  It’s funny to see a slave core polling the same Solr VM its in for updated segments!

JRuby

Doesn’t suck after all.  Actually, maybe I should say that JBoss, when combined with JRuby, means that JBoss doesn’t suck so much.  I had the aforementioned Solr core admin tool bundled up as a WAR file with JRuby, and was able to deploy it to an existing environment that had JBoss installed!  I didn’t have to install ruby on the box, (or JRuby for that matter!)  I just deployed the WAR file and bamn, off to the races.  Ops folks get the JBoss they love, I get the Ruby on Rails that I love.

And on a related note, Warbler was the key to thinking JRuby is cool.  I’d never actually had to package up a RoR app, so Warbler came to the rescue.  And you know what?  It was nice to build a single file that I knew had everything that I needed in it that could be scp’ed around!  And thanks to some cool code in the environment.rb, my app was able to load up the right configuration file for the environment based on an environmental variable set in JBoss.

Virtual Machines

I recently migrated a Linux VPS based RoR + Solr app (see a trend in tech choices )  to a Windows environment.  And to deliever the new Windows environment, I used VirtualBox to host the Windows Vista environment on my Mac laptop.

A couple of notes:

• VirtualBox may not have all the snazzy integration points of Parallels with the host computer like seamless application sharing, but it seems to be much lighter weight.  Starts up quicker, and I don’t get the spinning beach ball of death as much.
• If you are shipping a 11 GB file, you can’t use a 16 GB USB Memory Stick…  Turns out the biggest file is 4 GB.  (Although I never tried formatting the stick as NTFS, maybe that would have allowed a single 11 GB file???)
• Uploading 11 GB to a remote out on the internet server will take a long long long time.  Even on a really fast network. connection.
• If you need to format an external USB hard drive as NTFS on a Mac, it is possible!  Just fire up your trusty Windows Vista image in Parallels, plug the USB drive in, download and install the correct USB drivers so the drive doesn’t show up as a network share mapped to the Mac, and then use the built in reformatting tools!  Warning: This will take a loooong time!
• Lastly, if you are using VirtualBox, and you attempt to create a Windows XP machine, and attach a Windows Vista hard disk image to it, VirtualBox will let you!  And then Windows won’t start.  sigh.

Last week, the U.S. Federal District Court of Northern California found a software developer liable for unattributed use of a Java Model Railroad Interface.   The lack of attribution, as required in the license, the Court found, violated the Digital Millennium Copyright Act.  While the Court’s finding has limited legal jurisdiction, it does set a precedent which will surely be cited in future cases looking for both damages and to set further legal precedent and define more fully the cases in which stare decisis will apply.

While, analogously, no different than any other license violation, I predict that this finding will have a ripple effect in government adoption of open source projects in their applications, further dampening the adoption rates.

• Many government agencies are skeptical of open source in the first place.  Open source projects, rightly or wrongly, have a blanket aura of the two high school kids in a garage image.  Most government agencies like controls and process, which they don’t perceive exist in open source projects.  If some of them tried to become committers on major projects, perhaps the perception would change.
• Very few open source projects have sales representatives.  The sales representatives at major software companies such as Microsoft do an excellent job of the appropriate education and shepherding to provide assurances to the government buyers.
• Walking through a purchase process gives the perception of license compliance.  A contracting officer can say that they have made a purchase and have a license and feel like they are in compliance, although audits oftentimes reveal shortcomings.  With an open source project, anyone can download source code and deploy the software onto a system, creating manifold increases in risk of license violations.
• Most legal counsel isn’t familiar with open source licensing requirements and restrictions.  Rather than digging into and understanding GPL or “copy-left” restrictions, it’s easier to just stay away from it.  Again, there are probably as many, if not more, EULAs than accredited and accepted open source licenses, but there are also sales representatives to walk through EULAs whereas the open source projects do not have such champions.
• It’s easier to create blanket restrictions than to make judgments on each case based on the specific merits of the case.  The finding in Jacobsen v. Katzer makes it easier to point to a known and potentially quantifiable risk to deny use.  The Government is, and in most cases rightly so, risk-averse, and this finding creates a potentially big risk.  The risk may be a black swan, but it is very hard to measure and, in a perfect (in the Government’s view probably an imperfect) storm, could be potentially exceptionally large.

While it won’t have an immediate effect, the end result, I expect, will be an even more rigorous set of processes to complete for approval of the use of most open source software within the government.  I hope this is not the case, because there are many cases where open source software is the best solution.  Furthermore, I truly believe that:

• By and large, open source developers are not a litigious group.  They want to write software which makes life easier, and as long as they get the credit and attribution they want, they’re happy to share.  It’s what’s written in the licenses.  Plus, legal paths are expensive, and very few can afford to go down that path.  Compliance with a very few legal requirements or selection of a different platform will avoid any potential legal pratfalls.

Thanks to Onlyopensource for pointing out this article!

Today, Microsoft announced that it was abandoning development of the FAST search engine for Linux and Unix.  Given that Microsoft paid $1.2 billion for FAST, the move is an apparent revelation of a strategy to get non-Windows based users to move to an enterprise Windows platform rather than to continue to support FAST.

This move seems to be risky.  The Microsoft bet is that its FAST customers are more loyal to FAST than they are the operating platform, and the perception of switching costs are higher for moving from FAST to another enterprise search engine rather than the opposite–a loyalty to the operating system and a perception that search engines are interchangeable.

Microsoft might be right for most of its customers, but this announcement will certainly be grist for the mill in IT departments over the coming weeks.  Many companies built their IT infrastructure around a Linux-based platform, and being forced to change to a Windows environment may be a pill that is too hard to swallow.  The alternative will be to look to other search engines, which can do nothing but help Solr and Lucene.  With an established user base, enterprise grade support packages from companies like Lucid Imagination, and a significantly lower total cost of ownership than the FAST + Windows package, Solr will appeal to many a CTO who might otherwise have continued to gladly pay the licensing costs for FAST but is now forced to reconsider his or her decision.

Rather than supporting FAST on both platforms at the cost of a few developers, Microsoft may lose many more customers and revenues because of its insistence on one platform.  It will be interesting to see how companies like Lucid respond to the new opportunity.

Yesterday, the House of Representatives introduced S.2989, the Small Business Revitalization Act, which punishes government prime contractors for failing to pay their subcontractors after the government has paid them for work performed.

While noble in trying to ensure that small businesses get compensated for work performed, the bill seems to miss the mark on the bigger issue with small business subcontracting.  I admit, I cannot find the text of the bill (and would love it if someone could point it out to me), so I could be wrong, but based on the article linked above, it appears that a couple of key issues are not addressed:

• Prime contractors actually meeting their subcontracting requirements.  In most large contracts, prime contractors are required to have a subcontracting plan and meet certain thresholds of work sharing amongst disadvantaged groups.  Very few enforcement mechanisms exist to ensure these thresholds are met, and this act does not address the issue.
• Prime contractors actually using the teams that they proposed in RFP responses.  If a prime wins a contract by describing teaming arrangements with certain companies, then it should actually utilize them as proposed to the government originally, or replace like-for-like on the team.  Again, no enforcement mechanism exists unless a contracting officer writes a constraining and binding contract.

As I have written before, set-asides and subcontracting goals go against my libertarian nature, as I want the most value for my money as a taxpayer; however, if they are going to exist, then the least the government can do is make sure that the rules are enforced.  Unfortunately, the Small Business Revitalization Act, it appears, fails to help meet those goals.

In a memorandum dated October 16, 2009, the CIO of the Department of Defense published guidance on the use of open source software within the DoD.  The CIO’s assessment of the perception of open source sums up quite well the obstacles we have seen time and time again:

“Unfortunately, there have been misconceptions and misinterpretations of the existing laws, policies and regulations that deal with software and apply to OSS, that have hampered effective DoD use and development of OSS.”

I wonder how long it will take for contracting officers to get the memorandum (so to speak) and to try to find ways around the guidance, spelled out in Attachment 2:

“In almost all cases, OSS meets the definition of “commercial computer software” and shall be given appropriate statutory preference in accordance with 10 USC 2377 (reference (b)) (see also FAR 2.101(b), 12.000, 12.101 (reference (c)); and DFARS 212.212, and 252.227-7014(a)(1) (reference (d))).”

We also eagerly await broader acceptance within the DoD information assurance community, but do not expect rapid change, despite the following guidance:

“DoD Instruction 8500.2, “Information Assurance (IA) Implementation,” (reference (g)) includes an Information Assurance Control, “DCPD-1 Public Domain Software Controls,” which limits the use of “binary or machine-executable public domain software or other software products with limited or no warranty,” on the grounds that these items are difficult or impossible to review, repair, or extend, given that the Government does not have access to the original source code and there is no owner who could make such repairs on behalf of the government. This control should not be interpreted as forbidding the use of OSS, as the source code is available for review, repair and extension by the government and its contractors.”

In sum, this is good news for those of us who believe that open source has a place in the Department of Defense.  However, word spreads slowly in the Government, and I expect that this policy will take many months, if not years, before gaining significant traction in DoD contracting policy.  A good place to start would be providing correct links in the policy memo.  Clicking on the link currently leads to a 404 error.

Thanks to the Powdermonkey blog and Dr. Mark Drapeau for sharing this!

So, is James Bach (@jamesmarcusbach) the bad boy of testing?

I flew up to Boston on Monday to lead some workshops on Continuous Integration. I checked into my room at the Hyatt and then went downstairs to see who was around. I ran into a couple of speakers milling about, and eventually joined one of them, and we headed over to the MIT Press bookstore, me to look for my Solr book. I wasn’t too sure of the name of the other speaker I was with (I asked once, but couldn’t quite remember what it was…). So we got to the book shop, I ask my fellow speaker again: James Bach. The name I was familiar with, but couldn’t quite place it… I ended up buying Parentonomics, and then we go for coffee.

So, over coffee, he asks me about what my topic is, and I gave him the brief summary of my two CI related workshops. Wow.. Little did I realize that I was sitting with the guy who rails against the “fetish” that Agile folks have for automated testing! That his entire approach to “testing” is to use skilled, motivated folks who do “sapient testing”. And I’m the guy who’s selling an approach that REQUIRES automated tests! That encourages expanding the use of automated testing!

He actually walked me through a process of talking about how to “think like a tester”, and it was really great mini-workshop.. He definitely subscribes to the socratic approach, and believes in his message, I was sweating at the end of it! That chat probably sparked more ideas in less time over that coffee then anything else this week. I also heard a lot of ideas and phrases that were echoed in Michael Bolton’s keynote later on in the week. Clearly a lot of collaboration between the two!

Probably the biggest idea that James and chatted about was the idea that automated tests really aren’t automated tests, they are automated checks. They verify that the expected behavior of the code was met. His argument that if you want to do testing, real testing, then computers, automated processes can’t meet that need, only people can.

Now, I don’t know if I believe that is completely true, but I am very aware that the “manual testing” where long test scripts written as Word documents are executed by human beings by hand are really a waste of human potential. And that those test scripts are really, to use James terms, “check scripts” because the people are not using any creativity! In fact, a lot of my interest in CI comes from the idea that people should not do monkey testing, that machines can do it much better, and my frustation with the perception that testing is a low value activity and can be easily shipped off to low skilled folks.

I think that this shift away from the term “test” for automated tests is actually happening in many places. In the Ruby world, we have libraries like Shoulda that are moving from using words like assert to other words like should. A Cucumber test really shows how controlled the space that a test needs to be to work well in an automated fashion:

Scenario: See all vendors
Given I am logged in as a user in the administrator role
And There are 3 vendors
When I go to the manage vendors page
Then I should see the first 3 vendor names

So while I don’t know if I am bought in on the idea that only people can do “testing”, and machines can only do “checking”. Tools like Heckle try to simulate aspects of what a human can do. While not suggesting that we can automate the “does my website look okay after someone changed the CSS” type of work today, in the future our automated testing will be more capable then just “checking” because we will move beyond the very constrained tests we have today to ones that mimicing the richness of the simulators that Airline Pilots use. Instead of testing the training given to pilots, we’ll be testing the robustness of software via simulations!

At any rate, James Bach, while taking a rather provocative approach to sharing his ideas, does subscribe to my favorite bullet in the Agile Manifesto: Individuals and interactions over processes and tools.

Here is him giving a great presentation with the subversive title of “How to Fake a Project” that was incredible entertaining, and also quite thought provoking:

What do you think? Automated testing is a fetish of the Agile community?

Today, the United States Marine Corps announced that it was banning its Marines from using social networking on the job.  Citing security risks, the Marine Corps has said that it will block and ban social network sites while Marines are on the job, but doesn’t stop them from doing so when they’re not at work.

To me, this seems to be a case of letting a small bad outweigh a large good.  While I understand the desire not to expose Marine networks to hackers and not to expose secrets to the world at large, these are problems that the Marines and the military face on a daily basis.  Simply banning the use of social networks while at work will only move the problem to a less scrutinized venue.

Here are 5 reasons that the Marines shouldn’t ban social networking:

1. The security risks aren’t going away.  People are going to use their social networks at home if they’re not being used at work, so the same secrets will get out regardless.  These transgressions will range from a slip of the tongue to intentional OPSEC violations but if these occur on government computers, then there’s a better chance that they’ll be caught sooner than if they occur at home.
2. It sends the wrong message to today’s Marines.  The bottom line interpretation of this message, to the average Marine is “we don’t trust you.”  While today’s Marines and soldiers are being asked to do more at lower ranks than they were in the past–a large amount of responsibility being placed in the hands of teenagers and twenty-somethings–this message implicitly says that for all of the responsibility, there is still no trust.
3. It sends the wrong message to potential recruits.  Recruiters want to go where the recruits are, and most of them are on social networks.  Not allowing social networking sends the message that the Marine Corps is backwards and antiquated and doesn’t care about what it’s like to be a youth in society.
4. It keeps the Marines from knowing what’s being said about them.  Social media is turning into a major media outlet, and it’s often one that has a different take on events than mainstream media.  By banning the use of social networks, the Marine Corps has hamstrung their own public affairs office from both telling a good story about the Marines and knowing what is being said in the arena of public opinion about them.
5. It stifles a culture of innovation.  Terrorists continue to innovate, and as is pointed out in the NDIA’s own magazine, “to defeat terrorists, the military must innovate and disrupt [them].”  By banning the use of an innovative means of collaboration and interaction, the Marines suppresses the culture that leads to the innovations needed to win post unilateral hegemonic conflicts.

I predict that in the end, the Marines, the Pentagon, and the government will come to some sort of compromise that allows limited usage.  Giving up rights is part and parcel for live in the military; hopefully the sacrifice doesn’t come at the cost of leaving a generation of future cyberwarriors behind.

Scott Ambler wrote a very interesting article for Dr Dobbs Journal recently entitled “RFPs the Agile Way — or — Fear and Loathing in the Procurement Department.”  I first came across the article when Deborah Hartman Preuss wrote an excellent commentary on InfoQ about Scott’s article, entitled “Using the RFP Process to Hire Agile”.

As Ambler points out, the use of a formal RFP often implies that the client uses a traditional development method like Waterfall.  Procurement writes an RFP, and then the consultant responds with a detailed proposal dictating timelines and cost estimates, and perhaps an up front design.  All before ever meeting with the client.

The RFP process is a necessary evil of the consulting world, particularly in government contracting.  But RFPs don’t lend themselves well to the very collaborative discussions you can have with a client when you are using an Agile process, or if you are securing the contract in person rather than electronically.

This topic relates somewhat to my upcoming presentation at Agile 2009, “How to sell a traditional client on an Agile project plan.”  Although a lot of the advice I give in that talk can be done in proposals, most of it works better in person.  And so I think that’s a real challenge to accurately respond (in an Agile way) to an RFP that assumes a waterfall development model.

At first I didn’t quite find the answers I was looking for in Ambler’s article.  I don’t say that as a knock against the article at all, because it is well worth the read and I think it frames very well the problems with RFP processes.  However, Ambler is mainly encouraging procurement people to change the way they structure RFP’s so that Agile people can respond to it better.

I’m not sure the procurement people are going to read his column or see the incentive to do so (which he acknowledges, and asks readers to send this article to procurement people they know).  And so while I believe my Agile 2009 talk offers some strategies for how to positively discuss Agile in a proposal, I’m still in search of the holy grail.  How exactly do you respond to an RFP “the Agile Way”?

But after reading Ambler’s article again, perhaps he does lay out some of the answers I’m looking for.  He just does it from the opposite perspective.  He suggests this advice for what procurement people should look for in an Agile response to an RFP:

(rather than lift all his text, I’ve just included the highlights below.  I suggest you read his article for the full explanation)

The supplier should provide resumes

Follow a reasonable set of rights and responsibilities for both the customer and the supplier to adhere to … how they will collaborate together.

Propose how they will work with the customer.

Produce potentially shippable software to the customer every X weeks.

Allow the customer to monitor their work and work products.

Follow the customer’s corporate development guidelines.

Do full regression testing throughout the lifecycle.

Provide a minimal set of deliverable documentation, particularly user documentation, operations documentation, support documentation, and high-level systems overview documentation. The customer should provide examples of such documentation if they’re available.

Shared-risk strategy [for payment] which is fair to both customer and supplier.

Indicate rough estimates and schedules, in the +/- 30% range.

That’s a great list of ideas for consultants to incorporate into proposals, even if the customer is not looking for them.  I’m glad to see that we already do many of them in our standard proposal template at OpenSource Connections.  In particular, we always talk about our “Open Approach” to projects, ie, the highly collaborative and open way that we work with our customers using Scrum.

This is all a sign of the increasing maturity and adoption of Agile processes, and if nothing else, that’s a good thing.  Perhaps the procurement people will sign on eventually after all.