Commoditizing Web Services

After a discussion with Collabnet sales today, I reached an often reoccurring realization of the power of web services. Collabnet, who is trying to sell their version-control services to large and small enterprises around the globe, hosts Subversion version control servers and also manages the process around tracking enhancements, defects, etc. All of these services can be run from the Collabnet servers. No mess for our company, no need to hire people to manage servers, the service is up as long as we pay the bills. Awesome...

Many companies spend money to hire, train, and retain people to manage apps internally. Why? Why would a company spend the time and effort to build up their own in-house expertise when for much smaller amounts they can just get a domain setup on a service providers website often within minutes.

This is the future. When I can buy version control services for a small amount every month and be up and running within minutes of signing up, we are reaching the point where each service is as ubiquitous and easier than say getting your water turned on at the county water department. Google desktop, Salesforce.com, Collabnet, and many others know this. I believe the rest of the world is catching on.

Subversion Merge Tracking

I have been pimping Subversion now to every company I have worked with over the last 5 years. I believe with the upcoming Subversion 1.5 release has really moved Subversion over the top as far as version-control tools go. Here is why....

1.) Subversion is still free.
2.) The new release 1.5 addresses one of the most common criticisms of subversion. This is the lack of any embedded merge tracking.
3.) Subversion is still free.

Let me address #2 a bit. Subversion has always been a powerful tool, but in many ways the tool worked best in a single trunk or structured environments with controlled integration from multiple branches. The problem with that is that there are many development groups that are not structured, and do not have nice integration paths from multiple branches.

Many times groups over 10+ developers teeter on being chaotic, and the threat of chaos to the process was fine up to a point. I believe many larger development groups can go past that point in Subversion when complex branch and merge tasks are attempted on a daily basis. Groups often give up on spending the time on a good branching strategy (Bad Idea #1) and move to commiting to the trunk only. I think this is a huge mistake, and something a little update in subversion could probably fix.

The Subversion 1.5 release attempts to address the large development groups' integration issues, and I believe will help Subversion compete at the larger companies against the Clearcases and other high cost tools.

Here's the list of new features added to 1.5...

• Handle Repeated Merges
• Cherry Picking
• Record Manual Merges
• Rollback Merges
• Block/Unblock Change Sets
• Automated Merge

I believe that adding these features to the existing features (simple clients, atomic commits, hands-off server maintenance, open source, etc. etc.) makes Subversion a great tool for almost any environment.

BTW, If anyone needs help convincing their company to adopt Subversion, feel free to email me. I could write a book on what to say and what not to say :)

Passing arrays from JSF to Javascript

JSF can be a bit tricky and sometimes unfriendly when working with other tools especially Javascript functions that are not the simplest of implementations. One issue, that I have found very little documentation on the internet was how to pass arrays from JSF to a Javascript function.

Here's one way to accomplish passing an array to a Javscript function. This is limited by the amount of memory required to store a String, but in my case my upper bound of my array is well below the memory boundaries of the String.

1.) Create a String from an Array in your JSF page bean. This can also be set anywhere you JSF page can access the String value (i.e. session beans, etc). Use a delimiter between the elements of the array when converting the elements to a String to enable parsing later in this process.

2.) Reference the String created in step #1 wth an inputHidden. Here is an example...

<h:inputhidden id="bizStringAry" value="#{secure$BusinessEntry.businessStringAry}"></h:inputhidden>

3.) From the Javascript function reference the inputHidden field and place into a string. Use the Javascript split function on the String to remove the delimiters in step #1.

var bizname_array = document.getElementById('form1:bizStringAry').value
biz_fields_ary = bizname_array.split("?")

The biz_fields_ary is an actual Javascript array. You will need to reference the element(s) needed to process in your Javascript.

I hope this helps. Good luck!