Early Impressions of Some New Choices

My team and I were recently tasked with a pretty monumental project. We are basically building the services that will power a whole host of extremely high traffic websites that can do everything from paying a bill to streaming video content to an iPad. The complexity of this type of project is very appealing and I’m really happy be a part of something this ambitions.

As part of this endeavor we were given the freedom to choose just about whatever tools and technologies we wanted to build the most scalable, maintainable and bullet-proof system we could. After about a week spikes on different languages, frameworks and tooling we came to the initial conclusion that we would adopt:

  • Git for version control
  • Spring for DI and other stuff (which we since removed, see below)
  • Scala as our primary development language
  • Gradle for our builds
  • MongoDB for persistance

This blog is one of many to report on my impressions of these choices and the tradeoffs they are (or aren’t) causing us to make versus a standard J2EE/Spring Java project that just about everyone on my team has done in the past successfully.

First, Git.

Git. Is. Awesome. Seriously, it is amazing. I’ve been using Git for about two years but, before now, only in very small projects. I thought it was good before, but I’ve really grown to love just how much flexibility and speed it buys me personally not counting how much it buys our team in terms of ease of branching and an easy (now) to understand code history. If you haven’t yet adopted Git as your SCM system, you absolutely should.

Secondly, Spring.
We’ve all used Spring pretty heavily in the past and have a good track record of success with it. However, as we began coding our DI, we came to a very startling conclusion: we probably don’t need it anymore.

Relying on our experience with DI in general and our understanding of what Spring does “under the covers” as it wires objects together, we were able to create a native Scala DI solution that is statically typed, easy to understand (read: no XML or annotations) and, given that it’s simply part of the language, extremely quick to bootstrap. There is no ApplicationContext to wait for or mock for testing. It does its work when the classes are executed (and slightly later if we’re using the lazy modifier which we usually do) and that’s that. While I’m sure we’ll be refining this solution over time, the fact that we own it and it works as well as it does for us makes me suspect that we, as a team, have grown “beyond” the need for Spring. Spring helped us (and me in particular) understand the need for things like DI and AOP and caused me to think of my code in a very decoupled manner. Thanks Spring, but we’ve grown up!

Next, Scala.
I’m not sure what I think of Scala yet. It’s a daily thing. Coming from a lot of Groovy and JavaScript work, I have grown to like the free love devil-may-care type system. Some of the recent code I’ve written in those two languages is the best work I think I’ve ever done. However, I do see the value in a stricter type system and there are many things about Scala I love.

The biggest concern I have is how ridiculously complex Scala can be if you let it. The community has yet to (as far as I can tell) establish a concise set of patterns (something like Effective Java) and many teams (including ours) spend a lot of time trying to figure out what esoteric features to take advantage of and which to ignore. The exciting thing about this is that we are building our own Scala “way” of doing things internally in our team. That’s also the scary part. However, so far, it’s been relatively smooth aside from those times when I think “my god this was so much better in [Groovy|Java]” which are becoming less frequent as I continue to learn the language.

I had high hopes for Gradle when we started the project. We moved from a combination of Gant and Maven and, at first, we were loving the combination of convention and extendability. It really allowed us to customize our build and do some pretty neat stuff with very little effort.

My biggest complaint, which is starting to sour my whole opinion of the tool, is how slow it is. Running gradle tasks in our project on a quad-core Xeon takes 17 seconds! Running a build from scratch takes almost 30 minutes. And, since there isn’t yet great IntelliJ support for it, running a gradle idea (which I do several times a day to refresh the .iml dependencies) takes 4 minutes.

These are all unacceptable timeframes in my opinion. Granted: much of the 30 minutes I mentioned above is spent downloading dependencies (perhaps the majority of it), but the other tasks download nothing and still take far too long.

As gross as it sounds, I’m actually missing Maven. Not necessarily for configuration and dependency management (which were and still are a pain in many cases) or its contrived complexity and “xml hell” but more because it was faster and had first-class IDE support. These things are all missing right now with Gradle and I feel like it might be causing us to lose velocity rather than gain it as the time saved setting up the project does not match the time we all spend waiting for tasks to complete on a daily basis.

We may be doing something wrong and I’m open to doing what it takes to modify our setup, but I feel like what we’ve done is extremely reasonable and a relatively “common” case in terms of project structure and dependencies. To verify that assumption, I ran the same types of commands using another complex project: Gradle itself. I had similar results to those I see in our project. I’m hoping things improve in this regard after a smart colleague of mine attends Gradle training next week.

Finally, MongoDB.
I don’t have much of an opinion on this one as we haven’t integrated to it just yet. I’m interested to see how it compares to CouchDB as that’s where my previous NoSQL experience lies.

Again, I’ll be writing more as we get farther into the project. I feel (mostly) pretty good about the decisions we’ve made and the team I’m on. It’s been, and will continue to be, an awesome ride!


Why Chrome OS Likely Doesn’t Matter Anymore

In July of 2009, Google announced a new operating system based on the Chrome browser: ChromeOS. The idea was all applications would run inside the browser and the underlying OS would only provide enough functionality to allow the browser to load. All data would reside “in the cloud”.

I remember that announcement very clearly and how excited I was. I even went around buying up domain names of web applications I thought ChromeOS would need and I would famously build in my spare time (anyone interested in a barely used http://www.chrometunes.com?) I felt ChromeOS would be the perfect solution for casual users like my parents performing relatively lightweight tasks like viewing and storing photos, music, and documents. The ultimate “thin client” had finally arrived.

On January 27, 2010, Apple announced the iPad and things began to change. Many people, including myself, grew to think that a tablet could fill the casual computer user space better than a small notebook. The iPad is cheap, light, easy to use, and gets stellar battery life. And, not only does it have a very healthy app ecosystem, it also runs modern web applications extremely well. It’s the best of both worlds. Android also stands to perhaps fill that need in the near future with the same split of a native app ecosystem and an advanced web browser.

A few days ago, Google finally released reference hardware of ChromeOS to a fair amount of fanfare. While I’m still intrigued on the concept, the overall idea is much less exciting to me. Before the iPad, I could easily picture an ecosystem that didn’t bother with native applications.

Now, I’m not so sure.

The Platform
There’s a reason the “thin client” model never really materialized and I don’t see that changing any time soon. For the end user, and especially the casual end user, the fact that the “OS is a browser!!1!!1!” doesn’t matter nearly as much as the actual experience. Browsers have come a long way, but curated and tailored experiences are still very valuable and users have demonstrated they are willing to pay a premium for them.

In short, the application platform is really irrelevant to most people. What matters is a great experience. Both the iPad and MacBook Air turn on almost as quickly as you can press a button or open a lid … just like ChromeOS. Does it matter that one is a “thin client” and the other two aren’t?

The “Cloud”
I agree that remote data storage is a valuable thing for casual users. Issues of privacy aside, it’s extremely convenient to have access to documents, photos, and media regardless of location.

But we already have that. We can view and edit documents stored on the Internet from your phone, laptop, and desktop today. We can access Facebook and Netflix from a Samsung TV or an iPhone. What exactly is ChromeOS providing that adds something unique and new? Will it do it dramatically better? So far, I’m not seeing it.

Before the iPad, the cheapest way to get into casual computing was the relatively poor experience of an entry level “netbook”. Today, you can easily get a great casual computing experience for under $500. ChromeOS may have promised a much lower price point and better quality in 2009, but the bar has moved a lot since then.

I don’t know what’s going to happen with ChromeOS, but I honestly don’t see it gaining a lot of momentum. I see a future in which casual users will connect to their data with tablets, TVs, and phones and the more advanced users will continue to use powerful laptops and desktops.

Cycling Season 2010: Organized Event Recap

In early March, I purchased a brand new Specialized Roubaix in anticipation of an epic cycling season. I wasn’t disappointed. Between the beginning of March and the 7th of November (roughly what I consider to be the cycling season here in Colorado), I put in over 3500 miles on the Roubaix and close to 4000 miles total (I have a mountain bike as well).

At the beginning of 2010, I got together with a couple of my best friends and we mapped out the organized event rides we wanted to do for the season. There are a lot of these types of events all over the place, and it was a challenge to narrow it all down. Here are the ones we chose and my thoughts:

  • Elephant Rock (06/06/2010): This ride is commonly known as the kickoff of the summer riding season. It has been around for a long time and has a lot of distance options for various skill levels. I rode the century option which includes close to 6,000 feet of climbing.

    Elephant Rock

    Taking a turn on the Elephant Rock ride

    The course started and ended in Castle Rock traveling in a loop including a dip into Monument. There were ample rest stops along with the way and, despite some wind, was a reasonably great kickoff to the season. On the downside, the food wasn’t so great and, because of the sheer volume of riders on the course, there were times when congestion was a real issue. I’ve decided to ride it again next year as it helps set an early season fitness goal, but there were better rides this year no question.
  • Bike MS 150 (06/26/2010-06/27/210): This was a two day event. We rode from Westminster to Fort Collins, stayed the night, and then rode back the second day. Both days were roughly 75 miles leading to a grand total of 150 combined miles over the weekend. There is also a century option on the second day for people who want to ride a little farther.

    Finishing up the MS-150

    The ride itself was beautiful and relatively easy, with only about 1,500 feet of climbing over Horse-tooth Reservoir. We averaged close to 20mph on the way up. The food was outstanding and the volunteers were extremely fun and helpful. I’d definitely do this ride again except that the price of admission has gotten relatively high. Each participant is expected to raise $400 minimum to ride, and I ended paying the majority of that out of pocket. If you’re one of those people who love asking for money, then this ride is definitely for you.
  • Sunrise Century (07/24/2010): This ride was a 100 mile (with 7,000 foot elevation gain) loop from Boulder into Lyons, over to Nederland on the Peak to Peak, and back down into Boulder via Left Hand Canyon. This loop and its variants are extremely popular due to some challenging climbing and incredible scenery. It was likely the hardest ride of the year for us.

    Happy to be finishing the Sunrise Century

    The ride, however, isn’t something I’ll likely do again. I spent a lot of time on the Peak to Peak this year before and after the event, and didn’t really feel as though it was worth paying for the organized version. The food wasn’t great and the ride felt disjointed. If you feel like riding this course (and you really should; it’s a great course) I recommend doing it on your own.
  • Copper Triangle (08/07/2010): This was, hands down, the best ride of the year. The organization was outstanding, the food excellent, and the course incredible. There were the perfect number of people on the road and just about everyone was nice and courteous. We stayed the night before and woke up to one of the best days I’ve ever had on a bicycle. I’m most definitely going to be doing this ride again next year!

    Copper Triangle finish line

  • Tour de Fat (09/11/2010): This was a great family ride from our house to City Park and back. The total distance was about 35 miles. We took the family and kids along and had a great time listening to music and drinking some outstanding beer. The crowd there is always lively, and everyone is expected to be in costume (we dressed up as Mormons :)

    Amber and Leslie at the TdF

    Waving Hello at the Tour de Fat

    The baby at the Tour de Fat

Next year, I plan on doing Elephant Rock, the Denver Century, Deer Creek, the Copper Triangle, the Crooked Roubaix, and the Tour de Fat (of course). Also, probably the most exciting thing for me in 2011 is the inclusion of my wife on at least a few of those rides along with the weekly group rides.

2011 is going to be quite epic … I can’t wait!