Les Hazlewood Where Les is More

Born to Run

Because I finished reading Cryptonomicon a few days ago, I was looking for the next book I wanted to read on my Kindle. I downloaded some classics - Swiss Family Robinson, Treasure Island, Count of Monte Cristo - all of which cost me $0.00. But I wanted to read something current as well, so I browsed through the best-selling Kindle books and came across this one which had a very high user rating relative to many others:

So, I jumped on it - I was curious about the world of super-endurance and wondered if it would inspire me to one day check off "Run a Marathon" from my bucket list. I bought it and started reading.

I can't put it down! I'm so fascinated by the Tarahumara tribe - a Mexican tribe, not African like I thought they might be at first glance. The author was a previous writer for Men's Health and Running World magazine, and provides good backstory for the running-uninitiated like me. So far so great!

4.3 Hours of Streaming Flash Video on the Google Phone (Nexus One)

Here's a great (but kinda long) video.

Short story - Apple (as we already knew) was full of shit when they said that Flash couldn't be used on mobile devices, claiming that it would destroy battery life. But then again, if things were up to Apple, we'd all be stuck using QuickTime Video. *shudder*.

4.3 hours of streaming video over the web on only battery power is pretty damn good. The video was demonstrating the Flash 10.1 player, which is still in beta, but it looks like the performance improvements are a big success.

I still don't think we'll see flash on the iPhone in less than a year
- or maybe even 2 (if ever). Mr. Jobs, this is one area where you're clearly wrong.

Java.net Maven Users Have Hope!

It is no stretch to say that Java.net's Maven infrastructure (or lack thereof) is the worst I've encountered in a project hosting environment.

It looks like the boys from Sonatype are willing to help out on this front by offering Maven repository hosting on their own public Nexus instance for any Java.net project that wants it. That's a big benefit to those projects - jump on it!

Read more about their rescue mission on March 5th, 2010.

Maven 2 vs Ant+Ivy: Revisited

I've received a lot of hits and discussion concerning my previous post regarding Maven 2 vs Ant+Ivy, and I'm writing a follow up post to clarify some things.

I now firmly believe that Maven 2 is a better build and project management tool than Ant+Ivy. I was wrong.

Yep, I said it. I'm man enough to admit when I've made mistakes and that I've learned from my experiences. And this is coming from the guy that wrote a (still popular) On Java article for Ant in the enterprise.

I almost always touted Ant + Ivy as a better solution in all cases compared to Maven 2, citing:

• Maven 2 has a steep learning curve and is a pain to come up to speed
• You can't customize it easily if you just need to get stuff done
• It requires installation of a tool other than Ant
• It just doesn't work well for very large enterprise projects

...
And a few other things.

I tried Maven 2 just for kicks one or two times and ran away screaming, "I don't have the power that Ant gives me! I can thrash out anything I wanted in Ant, but I can't do this easily in Maven! It takes longer! Maven sucks! God I hate Maven!"

Blah, Blah, Blah. Boy was that an ignorant viewpoint. The truth was that yes, I had tried maven a few times, but I never actually used it longer than a few days and reverted to my beloved Ant. I never truly experienced what it was like over a long period of time in a real working development environment, with other developers and other projects. So I honestly couldn't judge Maven fairly, especially in the environment where Maven really shines - multiple project teams. Let me explain:

The thing that I loved, and what many others love about Ant is its absolute control. I can do almost _anything_ I want in Ant. Same with the newer script-like build systems like Gradle. It is uber flexible, and I know that if I needed to do something down 'n dirty, I could hash it out in Ant in a couple of minutes.

If you're a control freak, Ant is comforting. It allows you to hack out whatever you want whenever you want. But this ability is actually the very thing that makes Ant a poor choice in a team environment. It makes it a really poor choice in an enterprise environment with multiple teams, and here's why:

Even the most intellegent, super-smart, uber genius-geek that knows everything about Ant will still do things in a way that fits their personal mental model. Even worse, the same uber genius-geek god-of-all-developers is apt to continually insist that their way is the best way, and that they've worked out all the kinks, and that everyone should use their oh-so-elegant and super slick Ant build setup.

This is something I see all too often across teams and companies. This mentality actually hurts a team and has a bigger negative impact on multiple teams. The reality is is that one guy (maybe 2 if you're lucky) is the brains behind the build system. They're the only one who knows how do things cleanly. They know the best practices, and their environment, no matter how elegant, is often confusing to many people. Their mental model is not always the best one for everyone.

So, you end up having this one (or two) nazi-build-master(s) maintaining a bunch of ant scripts, making them more complex over time (breaking them into separate files because it makes sense to them, but harder to trace for everyone else), and getting upset if other people try to modify them. Then team members that should be allowed to modify the build to meet a new need can't or are afraid to.

In any event, the overall team productivity related to builds and continuous integration often slows to a trickle. This trickle causes frustration, alienates people and discourages their interest and help, and costs the company money. It is clearly a bad, bad thing.

Maven remedies this all too common situation and many others. Once a few developers use the Maven XML structure and understand what those tags do, they can jump from project to project, as business requirements deem necessary and immediately understand another project's build environment. That means they can build the software and start testing it right away. This efficiency translates into enhanced developer and team productivity and that means real money saved for the company.

And guess what? Newer developers hired in to the company that have Maven experience can also jump right in on a project and understand its build environment for the most part. That is a big benefit. At my workplace it used to take a new hire almost a week to feel comfortable understanding and building a very large project. After converting to Maven, new hires are literally up and running in under an hour.

But this efficiency is not just valuable for the company. It is valuable for developers' sanity. I am comforted now by knowing that I can jump from projects at work to a few hosted Apache projects to some other 3rd party projects and, if they use Maven, I am right at home and understand exactly what is going on. I know immediately how to

• download dependency source code
• run tests
• generate JavaDoc and other documentation
• Start up a test web environment if it is a web product
• view a continuous integration environment
• see source control repository details
• understand how the project is broken up into modules

...
and so much more. That I no longer have to think about these things, things that were very very time consuming when having to manage yourself, even with Ant, is a big load off of my mind. I just don't want to mess with this stuff anymore. I want to have it all work, not waste my time, and allow me to have my piece of mind so I can go crazy worrying about other things like deadlines. That I can get this piece of mind from project to project and team to team when Maven is employed is a real benefit.

And to my previous comments about Maven not working well in very large enterprise projects because of the possibility for a lot of 'one off' custom logic? That didn't hold. I'm working with a very large codebase at work that sometimes takes over 30 minutes to build, not including integration tests, and Maven fits the bill beautifully. Sure, there are those few 'custom' things that we needed done, but we learned to write a Maven plugin or two (as you should) and use them extensively. Sure, I couldn't thrash out an Ant hack to get what I needed done, but so what - the team understands what these custom plugins do, they are self documenting, and easily maintained and managed in source control by other developers because Maven plugins themselves are fairly conventional and easy to understand once you learn about them. This goes back to continued efficiency...

Don't get me wrong - there are some gripes I have with Maven, but they're not really a big deal compared to all the benefits we receive. It is not a silver bullet - nothing is - so you take those few frustrations and set them aside, knowing the alternatives are much more painful. So maybe I'll call it a bronze bullet?

And so, as JSecurity has moved to Apache and has been renamed to Apache Shiro, we too have moved to Maven 2. We have also moved to Maven 2 at work as well, and we now benefit from some other amazing tools like Nexus that integrate well in a Maven ecosystem.

Overall, life with Maven is good. I'm glad that I was able to swallow my pride, really give it a chance, and in turn reap the benefits. I haven't used Ant in over a year since switching, nor have I ever felt the need to go back.

IntelliJ IDEA Performance : A Big Boost

Just jotting down some recommendations from a friend:

1. Create an EXE4J_JAVA_HOME environment variable that points to your JDK installation (i.e. export EXE4J_JAVA_HOME=$JAVA_HOME).
2. Delete the <idea install dir>/jre directory
3. Add the following JVM options to what you may already have in Idea's JVM config (<idea install dir>/bin/idea.exe.vmoptions on Windows):

   -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode

Linux, java.awt.headless and the DISPLAY environment variable

Just a quick note to self:

After looking at the JDK source code today, we found that even when setting -Djava.awt.headless=true, if a script executes with the DISPLAY environment variable set, the AWT graphics environment will still use a GraphicsEnvironment representing that DISPLAY.

A major problem with this is if the shell that launched the script that started the java process ever executes, the GraphicsEnvironment reflecting the DISPLAY will be removed and any Object instances reflecting that environment would be invalidated or Classes once available will no longer be available. resulting in a NoClassDefFoundException.

Bottom line: on Linux, if setting -Djava.awt.headless=true in a script, ensure that you unset DISPLAY in the script before starting the java process. It will save some headaches in debugging.

BMW Paddle Shifters

A friend of mine recently pointed me to this forum thread, and I'd like to add my thoughts, based on actual long-term experience in driving a 535i with the Steptronic transmission with paddle shifters for over a year.

The BMW's paddle shifters don't work like Ferrari or Formula 1 cars, where the right paddle up-shifts and the left paddle down-shifts. In the BMW, both paddles can both up and down-shift: when you pull back on either paddle, you up-shift and when you push forward on either paddle, you down-shift.

Therefore, when I received my 2008 535i and started using the paddles, I was rather confused and frustrated because the only experience I had with paddle-shifting was playing GranTurismo where paddle-shifting was modeled after Ferrari/Formula 1 - myself never having been fortunate enough to drive a Ferrari or Formula 1 car . This is what I, and probably a whole generation of game and racing enthusiasts became used to and comfortable with.

However, now that I've been using my paddles for a while, I'm convinced that BMW got it right. Technically there is no right or wrong on this issue since it is purely preferential, but I think they are "more right". I think I was, and the majority of other video-gamers-who-drive-sporty-cars are "less right". I believe BMW broke convention for a better solution relevant to their target audience.

F1 cars can do the right=downshift/left=upshift paradigm because they don't often turn hard corners that requires a tremendous amount of turn in the steering wheel. Even hair-pin corners don't require much hand deviation around the circle compared to mass-produced vehicles (of course there are tracks where this isn't the case, but it doesn't happen all that often). That's because the steering mechanisms are far 'tighter' and don't require as much movement.

Contrast this with mass-produced vehicles, where even in precision vehicles like BMWs, the degree in hand movement around the circle is more significant - the steering wheels are much larger than the yoke-style steering wheels of an F1 car, and they are not as 'tight' - there is still significant traversal around a circle. Your hands have to move much further away from the 'home' position compared to a F1 car.

So, when you're pushing this type of car with more give in the steering wheel around a turn, the left paddle will become the right paddle and vice-versa, depending on how sharp the corner is.

Think about that for a second: in tight corners at higher speeds, you actually have to move your hands from the home position and situate them around the steering wheel as it moves to corner properly. If it is a sharp enough corner, you don't want to remember which paddle is the one you're supposed to use. You should be focusing on cornering and exiting the turn efficiently.

With BMW's paddle design, you can choose whichever paddle the situation deems as most efficient, not your preconception. This allows you to more easily focus on the road and cornering, rather than where your hands should be for optimal shifting.

So, like I was required to, I ask the many nay-sayers to actually try it for a while and try to ignore your preconceptions of what it should be based on video games or cars that we may never get to drive. Instead, just trust the BMW engineers, who, except for probably a very small number of readers of this post, know their craft (with a F1 heritage to boot!) far better than we do.

On the Auto Bailout

Since it just makes good sense to understand a problem before we dole out the cash, let's ask ourselves a question before we go spending (quite a bit) of our tax dollars.

Why are the U.S. auto makers in a crunch? Of course our economy isn't great and that's one reason, but you must still ask "Why are they doing worse relatively compared to the foreign competition?"

A lot of reasons: Reliability rankings. Worthless bureaucratic unions. Poor management. Inability to adapt to consumer demand, inferior engineering discipline, etc, etc, etc.

Each one of these reasons, and more, are worth their own posts entirely, but since I don't have time for that at the moment, let's continue.

So, we've identified why they are suffering. We've identified a problem. Now let's come up with a solution.

Let's think of what the auto bailout is supposed to do: give cash to auto manufacturers, which affords them a liquid capital cushion, which in turns enables them to keep people employed. Keeping people employed is good for the economy - they can go out and buy things and keep the money cycle flowing.

But what happens a year from now when the money has run out?

They'll still be producing inferior cars. The worthless unions will still exist. Management for the entire industry won't be likely to change that fast. They won't be able to engineer new cars that meet consumer demand that quickly.

We as a nation will be in even more debt and we'll still have that big glaring economic problem staring us in the face. This is typical Congressional behavior, "Let's spend money to put a Band-Aid on the problem and hope it goes away. Never mind that we're not addressing the root cause of the problem...". That's Congress' solution. A Band-Aid that solves nothing.

No one is addressing the fundamental problem - that U.S. auto manufacturers produce an inferior product under an inferior system. In a capitalistic society, as ours clearly is, the most efficient entities (corporations, processes) 'win'. It is cut throat. If you can't compete, you get swallowed up. This is what is happening to the U.S. auto manufacturers. They're imploding under their own inefficient weight. The rules of capitalism are prevailing.

So, any attempt to give them money without fixing the problems is completely futile. It's a waste of time, energy, and our hard-earned money. The problem won't go away, and we'll be further in debt.

I encourage you to contact your Senator and U.S. Representative and make known your feelings. Don't stand for a 'band-aid'. Demand more!

This nicely sums up the situation: