29 November 2007

Cyber Monday Success Linked to More Expensive Java Developers and Agile

As much as people like to joke about the women in the Overstock.com commercials saying it's all about the O (c'mon, read into it), evidently the Overstock.com website received some of the heaviest traffic on Cyber Monday earlier this week and it handled it very well (what a pathetic society we have become - we have names for shopping days). And Overstock.com's ability to handle all of this traffic and commerce has actually been linked directly to some of the topics about which we geeks spend so much time discussing, using and writing.

According to Overstock.com CEO Patrick Byrne:

"We had three developers on staff three or four years ago; now we have over 40 developers," Byrne said in an interview. "We found it's worth it to pay up for more expensive and more serious people."

According to the article titled Overstock.com Divulges Secret to Its Cyber Monday Success, Overstock.com used to use off-shore developers, a single C++ application and a single database. This year it overhauled everything to use on-site developers, Java and Agile methodologies:

"I was the biggest proponent -- as a stupid, Dilbert management kind of guy -- saying let's outsource. Now I've come completely 180 degrees to the agile approach," Byrne said. "Programmers sitting side-by-side with businesspeople designing functionality -- that's one trend," Byrne said. "The other is taking your software development and moving it to China or India. You see those two trends are antithetical to each other."

Maybe the world is beginning to see that real experience and talent are difficult to find and expensive once you find it.

As Napoleon Dynamite would say, "Yesss!"

28 November 2007

Using the Proximity Maven Repo Cache/Proxy

Recently I got frustrated with the latency of accessing Maven remote repositories, so I sought a solution. What I found was Deng Ching's blog entry titled The Hype About Repository Managers. Somehow I wound up downloading Proximity and what I discovered made me very happy.

Proximity is somewhere between a Maven artifact cache and a Maven repo proxy. It runs as a web application locally and by pointing Maven at the local URL for the web app, Maven will look up dependencies for any given project build using Proximity. If the Proximity cache doesn't contain a dependency, Proximity does the work to fetch that dependency from a remote repo and stuffs it in its cache. So the first build when using Proximity is slow becuase it's propulating its cache with artifacts but subsequent builds are damn fast.

Upon first downloading Proximity, I dug through the docs trying to figure out how to add another repository and I couldn't find anything. So I pinged Tamás Cservenák, the creator of Proximity, via IRC for some assistance and he was incredibly helpful in working with me to accomplish this task (thanks again, Tamás!).

To add another Maven repo to Proximity, I had to edit the proximity.properties file to create another FSStorage.baseDir, the proximityRepositories.xml file to add new LogicDrivenRepositoryImpl, WritableFileSystemStorage and CommonsHttpClientRemotePeer bean definitions for the new repo and the proximityContext.xml file to add point to the LogicDrivenRepositoryImpl bean definition. Next, I had to tell Maven to use Proximity as a mirror of everything by adding the following mirror definition to the ~/.m2/settings.xml file for Maven:

<name>Proxmity mirrored central.</name>

This tells Maven to look at the local Proximity URL for all artifacts and at that point, Proximity takes over. I've made available a ZIP archive of Proximity with my edits if you're interested. Using what I configured is as easy as downloading it, running it using the included jetty.sh script and editing your settings.xml file using the mirror config above. Then move aside your own local Maven repo so that a new one will be created.

In using Proximity so far, I've found that letting it spawn HTTP connections to download artifacts seems to be far more efficient that Maven. Chris started using Proximity and we're no longer seeing a huge amount of open sockets from downloading artifacts. So now I'm curious to peek at the Proximity source to see how this is being handled.

Also, Proximity is being adopted by Sonatype and it will be known as Nexus. For more info, see Jason's blog entry titled, Proximity Lives on as Nexus for Maven Users.

java.util.UUID FAQ

Recently I had a need for a universally unique identifier (UUID) and I stumbled upon this wonderful java.util.UUID mini-FAQ. If you have to use the java.util.UUID at all, you should give this little FAQ a quick read because it's got some great info to save you time in your own digging.

For example, there are 122 significant bits in a version 4 UUID (a pseudo randomly generated number) - that's 2^122 ( 5,316,911,983,139,663,491,615,228,241,121,378,304) or:

five undicillion,
three hundred sixteen decillion,
nine hundred eleven nonillion,
nine hundred eighty-three octillion,
one hundred thirty-nine septillion,
six hundred sixty-three sextillion,
four hundred ninety-one quintillion,
six hundred fifteen quadrillion,
two hundred twenty-eight trillion,
two hundred fourty-one billion,
one hundred twenty-one million,
three hundred seventy-eight thousand,
three hundred four

Man I hope that's correct - that's a damn big number!

24 November 2007

John Butler Trio

Raible and I saw the John Butler for the second time this year at the Ogden Theater in Denver last night and this show was much better than the first one! Not only were we much closer, but the Ogden is a pretty small venue which made it a very different show than at Red Rocks last Summer.

All I can say is WOW! What a talented band! Watch this live clip of them:

I will definitely be seeing JBT again. These guys have only just begun.

19 November 2007

Interface21 is Now SpringSource

It appears that Interface21 is now SpringSource. You can read all about the name change in Rod's latest blog entry but it seems to be the case that they wanted the company name to reflect the product base. I think that Neelan's latest blog entry says it all:

...the Spring Framework is spreading like wildfire throughout the application development and runtime universe—most as a response to developers frustrated with the complexities of Java EE

I saw this trend starting back around 2002 when we formed Apache Geronimo and even moreso in 2003 I was still doing some consulting work with application servers (and, this was a major driver for Geronimo's very modular architecture allowing you to roll your own app server assembly). Also, in 2003 I started using the Spring Framework and really began moving beyond application servers. Now, everyone from developers to architects are finally realizing that a big app server is not necessary on every node, especially when you have the Spring Framework.

Long live Spring ;-).

13 November 2007

IntelliJ IDEA JVM Options on MacOS X

I hunted for this for a while to find this, so I figured I'd post it to save others some time in locating it. If you have a need to change the JVM options for IntelliJ IDEA on MacOS X, take a peek in this plist:

<IntelliJ IDEA install location>/Contents/Info.plist

I had to change the memory options for the JVM and Chris gave me some other options to improve the garbage collection performance. Here's what I have in the VMOptions field:

-Xms128m -Xmx768m -XX:MaxPermSize=120m -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:+AggressiveOpt -XX:+UseBiasedLocking -XX:+DoEscapeAnalysis -Xbootclasspath/p:../lib/boot.jar -ea

One option tells the JVM to do escape analysis which performs some additional optimizations on your code. Some info on escape analysis in the Java VM is available in yet another excellent article by Brian Goetz titled, Java theory and practice: Urban performance legends, revisited. If you're at all curious about the internal workings of the Java Virtual Machine, this article is well worth the time it takes to read. I'm also telling the JVM to be more aggressive with its optimzations using the AggressiveOpt option. I'm also using biased locking which improves performance for uncontended synchronization as explain in the Java Tuning White Paper.

As always, YMMV (your mileage may vary).

08 November 2007

OSSummit Postponed until Spring 2008

I found out today that the OSSummit (a merger of ApacheCon Asia and EclipseCon) has been postponed until Spring 2008 due to a low number of registrations. I have heard that other conferences experiencing the same issues upon first being held in Eastern Asia. I have been told by many people that Asian companies are not used to attending conferences, let alone paying for developers to attend. I believe that this is simply a new event to which Asian companies are not yet accustomed. Just like the United States and Europe, it will take a while for open source to catch on there.

Now I'm just hoping that the postponement won't place the OSSumit (in Hong Kong) next to the week of ApacheCon EU (in Europe) :-0.

07 November 2007

Apache ServiceMix 3.2 Released

The long-awaited Apache ServiceMix 3.2 has finally been released. See the release notes for a long list of the bugfixes and improvements that are included. Many thanks to the ServiceMix team for all the hard work!

Java 1.6 Missing From MacOS X Leopard - Take It Easy Folks

There's been a lot of banter lately regarding the release of MacOS X Leopard and it's lack of Java 1.6. I understand that this is a letdown since it was included in the Leopard betas that were released, but is it really that big a deal? I think everyone needs to relax a bit on this issue.

I understand the interest in using some of the new features that Java 1.6 has to offer. I have even blogged about Apple's lack of communication about its plans regarding Java and I stand by what I said. But seriously, how many companies are actually using 1.6 for development or even in production yet? IMO, the real issue is not that Java 1.6 is not available yet as much as it is about Apple's continued lack of communication regarding Java in general.

Now is a good time to take another look at Eric's OS X Java Definitive Timeline. This diagram does a very good job of helping us remember how Apple has behaved with its Java releases to date. Given this past behavior, I'm really not worried at all. I am, however, still a bit miffed that Apple's ability to communicate its intentions with Java technology has not improved at all. I think this is what we should all be lobbying for.

If we're going to try to affect change, we need to start with some realistic expectations. Trying to make Apple release a product faster is like trying to make Apple move a mountain faster because we say so. No matter how much people bitch and moan, it's just not going to happen any faster. C'mon, be realistic here. We're all developers and we know that having someone asking over and over, 'is it done yet? is it done yet? is it done yet?' won't speed the delivery of the solution. Trying to make Apple understand that we'd like more communication is far more realistic. This is like asking Apple to talk about the mountain it is going to move. Given that we're all Apple fans, we should be telling Apple that we can't wait to get our hands on Java 1.6, could you please, please, puh-lease give us a status report? Requesting more information is something to which Apple might actually respond. Getting testy and demanding that Apple release Java 1.6 NOW is not going to help the cause.

So, to repeat, I'd like to see Java 1.6 on MacOS X as much as everyone else. I just think we need to reassess the tactics being used so that we can positively affect the situation instead of painting Java developers using MacOS X to be demanding and pushy.

Oh, BTW, here you go, Geert: 13949712720901ForOSX

06 November 2007

St. John's, NL Canada

I arrived in St. John's, Newfoundland, Canada Sunday night at 2am and today to work with a team of folks in the IONA St. John's office. It's a great bunch of folks here and city itself is very inviting and pleasant. Unfortunately I'm only here for a couple days.

Last night we visited O'Reilly's Pub to hear some Newfoundland live music. This evening I got to visit Signal Hill, the reception point of the first transatlantic wireless signal in 1901. It's a great vantage point to see the entire city, even at night. Even though it was quite cold due to wind and dampness from the ocean, the clouds cleared and we could see the lights of the city really well. In the other direction we could also see Cape Spear, the most easterly point of land in all of North America. Thanks guys!

Tomorrow morning at 5am I'm off to Phoenix, AZ for a couple days and then back home to Boulder. Originally I was supposed to head back to Dublin to speak at the Irish Java Technology Conference but the last time I was in Dublin I talked James into taking my place. And it's a good thing, too, because it seems that Air Canada changed its routes for the winter just a few weeks ago so there's no overnight flight from Toronto to Dublin. Thanks, James!