Les Hazlewood

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.

Ok, I’m about to go on a rant, because I come across something regularly that really, really, REALLY irritates me:

Whenever you see a class that implements an interface SomeName, and the name of that class is SomeNameImpl.

Guess what folks, EVERY implementation of an interface is an ‘Impl’. If you suffix ‘Impl’ at the end of your class name, you’re being short sighted and portraying a potential lack of understanding of Interface-Driven Design: that you can have more than one implementation.

What if you ever create a new implementation? What if, when testing other components, you create a TestSomeName implementation or a MockSomeName implementation? Then the SomeNameImpl doesn’t make much sense anymore, does it? It could be a cause of confusion as to why you have more than one ‘Impl’, or, worse, perhaps it might make people think that you should only ever have one ‘Impl’.

Instead, if you need a default implementation, and can’t yet think of other cases where you might have other implementations, just call it DefaultSomeName. Then you’re telling the world, “Hey, this is our default implementation of this interface, and if any more ever are needed, we can create them, prefixed with a more meaningful name.”.

Yes, I’m an OO naming zealot, but you’d be surprised at how this little change, in conjunction with other ‘trivial’ changes, make code more readable, easy to understand, and most important, adaptable to change over time.

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:

As part of my Kendo Shodan （first degree black belt) examination （剣道の初段の審査）, I had to answer a question regarding one of Kendo’s fundamental principles - that of ‘ki ken tai ichi’ I’ve included my answer here in hopes that it helps people better understand Kendo in general.

Ki-ken-tai-ichi, from the Japanese kanji 気剣体一, describes the condition when all essential elements of a Kendo strike are unified in a single instant culminating in the perfect strike. The resulting strike, called the yuko-datotsu , or 有効打突, “valid strike”, is a goal all Kendoka should strive to achieve.

Dissecting the Kanji into sub-parts can give a better understanding of the term’s meaning.

気, ‘ki’, is the kanji representing “spirt” or “energy”. In the context of ki-ken-tai-ichi, it represents the Kendoka’s mental assertiveness and instinctive focus that both initiates and finalizes the strike.

剣, ‘ken’, is the kanji for “sword”. In ki-ken-tai-ichi it is naturally the actual instrument that manifests the mental (internal) and physical (external) intentions of the Kendoka when executing a strike. As such, it should be regarded as an extension of the Kendoka, not a separate disconnected element.

体, ‘tai’, is the kanji for “body”. In context, this represents the physical element of the Kendoka’s intent – his body, the mechanism by which the mind’s intentions are executed resulting in the end goal.

一, ‘ichi’, the kanji for the number one (1). This is added to signify that the ‘ki’, ‘ken’, and ‘tai’ should not be considered separate elements at the moment of impact, but a single unified construct.

The final kanji, ‘ichi’ is the most important. It means that all three elements, the spirit, sword, and body must be realized as a single cohesive element if the resulting strike is to be considered ideal. The ability to obtain ki-ken-tai-ichi consistently is a goal of Kendoka of all ranks.

The JSecurity team had a recent discussion on whether or not to use Maven 2 or Ant+Ivy moving forward. At the end of the day, I didn’t really care that much about which system we used, but I had three requirements:

1. JSecurity releases must be pushed to the Maven 2 repository for easy access by both Maven and Ivy users
2. When executing a build, I want versioned dependencies automatically resolved and downloaded for the builder. This way things are ‘hands off’ and the JSecurity release .zip file doesn’t have to be 14 megs. Excluding dependencies would drop it to maybe 3 megs - much nicer.
3. I don’t want to manage builds much at all. Anything that takes my time away from JSecurity coding or writing documentation is less than ideal. Whatever system we chose, I wanted to spend maybe 2 or 3 days at the most configuring it and then just leave it alone (but still have it be clean and flexible enough for inevitable changes down the road).

What was the outcome? We ended up choosing Ant+Ivy, but I’ve outlined how we came to our conclusions based on the above 3 requirements for anyone that might find this useful when making their choice. This represents why it was a good choice for us, and may not be the same reasons for you. Everyone is different - choose what works for you based on your needs and desires.

Satisfying requirements:

Point #1 is handled trivially by both frameworks, so no need to speak of that further.

Point #2 is is handled by both frameworks without any problems, but that’s not the whole story: With further investigation, we found Ivy’s dependency resolution process to be more elegant, which had great appeal to us after we found out about it:

For any given dependency, both Maven and Ivy allow you to also control your dependencies’ dependencies that are downloaded. These are called transitive dependencies. For example, if your project requires hibernate to build, and hibernate requires JTA to build, does that also mean that your project needs JTA to build? In most cases this is not the case, and either framework will allow you to do excludes as necessary.

But Ivy has something more that turns out to be very powerful, something they call “configurations”. Configuration xml snippets in the ivy.xml file are more or less what I call dependency “views”. For example, one configuration entry (view) can mean “for a hibernate test, only require a, b and c jars”, or a “for minimal runtime requirements, only require x and y jars.” Here’s the best part - other projects can depend on these views so they only download what they absolutely requre, allowing configuration of transitive dependencies across projects. Extremely powerful, much cleaner, and arguably ‘more correct’ for proper software configuration management.

Another area related to point #2 where Ivy won out for our team is that only Ant is required, which is pretty much ubiquitous in all Java environments. Maven not so much. Ivy is even less so, but our plain ‘ol ant script will download Ivy for you if you don’t already have it, make ant aware of it, and then kick off Ivy as normal. NO software installation beyond Ant. That is just fantastic as far as I’m concerned, since we don’t want to force Maven on end-users who want to build the project. You’d be surprised at how something like that can make or break potential users. This all goes back to the lowest barrier of entry for people who want to use our project. This stuff matters to us.

Point #3: Maven actually won out here because of its black magic. It is easier to set up a Maven project for starters because it has so much built-in to it, whereas a similar Ant+Ivy setup requires plain ‘ol Ant setup + knowledge of how to incorporate Ivy. It might take a day or two to set up Ant+Ivy depending on your familiarity with Ant.

Although this is a powerful benefit of Maven, I feel it is beneficial for only small or simple projects. If you have a moderately complicated build environment, or one in which any level of specific customization is required, its far easier to do with Ant instead of fighting with Maven’s black magic quirks. Once you spend the initial day or two getting Ant+Ivy to just work, you rarely have to touch it again.

Add in the big ant benefits of macrodef and import and you quickly get an ‘OO-like” build approximating what Maven can do. Yes it requires more effort, but when you can do what you want, whenever you want, well, I enjoy that piece of mind. I don’t want to fight with my build system when I need something - I want it to adapt to my needs.

In the end, it took me a couple of hours to set up Ivy and play with it and read the documentation and and continue to play with my ivy.xml “configurations” (views). But, now it is smooth sailing. I’m loving Ivy, and I’m glad that we made the choice we did.

- Les