Les Hazlewood

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

Groovy is by far my favorite scripting language, since it leverages and integrates with all the Java stuff I use (applications, tools, server software, etc). It is just as expressive and powerful as Ruby, Python, etc., but feels a little simpler or cleaner, depending on the comparison.

Here are two fantastic resources in the ‘Cookbook’ fashion, showing how to do many useful things with Groovy:

The Groovy website Cookbook
PLEAC’s Groovy Cookbook - a Cookbook similar to Perl’s original Cookbook.

This post outlines how to re-create a subversion repository after a total failure or loss (disk overwritten, disk crash, accidentally deleted, etc) when you have no repository backups and only developers’ working copies. If you’ve lost your SVN server and have no backups of your repository, and you don’t want to do manual per-file copying from the old working copy to a new working copy, this is your only option - you have no other choice.

Background:

At my current client’s site, we were using a makeshift Subversion repository (one of the best RCSs available) to overcome problems with Clear Case, aka THE WORST REVISION CONTROL SYSTEM EVER. God how I despise Clear Case, that eternally flawed disgusting dung substitute attempting to be an RCS. Just to be clear, in case you might have misunderstood me, I’ll restate: Subversion is amazing, Clear Case only wishes to approach the beneficial status of say, fungus on the wall of an abandoned Vietcong prison.

Anyway, we set up Subversion to use as our primary repository, but unfortunately, didn’t set up a nightly backup process to a different machine. That bastard Murphy struck: after only 2 weeks of using this box, the hard drive failed and we lost the repository in its entirety. Lesson learned - always always backup your SVN repo to another machine nightly. Continuing on…

Naturally the developers on the team all had our local working copies, so we still had all of our code and nothing was permanently lost. Now if the original problem were a mere disk failure and no one had changed their working copies since the last SVN update, this would be an easy problem to solve: just create a new SVN repository, import only one of the working copies, and everyone then does a fresh checkout of the new repository and continues on their merry way.

But as Murphy would have it of course, we all had modified our local working copies for about a day and a half after the hard drive crash. We couldn’t just kill productivity until the new one was rebuilt over the next two days. So we kept working and subsequently our working copies became out of sync with each other.

Solution (nearly identical to this email thread, but elaborated):

When the new Subversion server was back online, I performed an svn export of my existing local working copy, which produced a ‘clean’ directory tree. I then svn imported it into a brand new repository on the new Subversion server, creating version 1. At this point it is worth mentioning that my existing working copy before export was at version 395. After importing the clean ‘exported’ tree, the new repo will start with version 1. Forget about trying to recover revision history from your existing working copy after a total repo loss - its not possible - versioned changes related to the old repo are lost forever.

So although we had to start over at version 1 again (not as ideal), at least we had a proper repository again with no significant code loss.

But what about the other developers who had made changes the last two days? They need to get their changes into the new repository.

You CANNOT do this with say an ’svn merge’ or ’svn switch’ (even with –relocate - it won’t work). If you tried to even get the log from within a working copy from the old repository, you’d see something like this:

> svn log
svn: No such revision 396

So, how do you do a proper merge of your old-repository-but-latest-code-working-copy into the newly-checked-out-working-copy?

The only way is old-school diff and patch programs. Trust me, there is not another way, I researched for hours so you don’t have to. Anyway, here’s how to do it. Each developer had to run the following steps:

If you’re running Windows, you can still execute the following steps, but you’ll have to download and install GNU DiffUtils and Patch for Windows:

1. Download and install GNU’s Windows DiffUtils
2. Download and install GNU’s Windows Patch
3. After you run both setup programs, they will be installed into C:\Program Files\GnuWin32\bin. Open up Start > Control Panel > System > (Advanced Tab) > Environment Variables. Add this directory to the front of your %PATH% environment variable. This will allow you to call diff and patch on the command line.

Ok, now for *nix users and Windows users who have completed the above 3 steps:

1. Check out a new working copy of the brand new SVN repository to a directory different than your current working copy.

   For example, on my machine, my ‘old’ failed-repo-working-copy is in ~/projects/projectName-old/trunk. My new checkout was made to ~/projects/projectName-new/trunk.

2. svn export the failed-repo-working-copy to a temp dir. When this was completed, I had the following directory:

   ~/projects/projectName-old-export/trunk

3. svn export the new working copy that you just checked out a second ago. When I was done I had a directory:

   ~/projects/projectName-new-export/trunk

4. cd to your new working copy (e.g. ~/projects/projectName-new/trunk) and diff and patch this working copy:

   > cd new_WC_dir
   > diff -ru new_WC_export_dir old_WC_export_dir | patch –p0

   For example, this is what I did:

   > cd ~/projects/projectName-new/trunk
   > diff –ru ~/projects/projectName-new-export/trunk ~/projects/projectName-old-export/trunk | patch -p0

   When this command was finished, I had a bunch of lines printed to the console patching file …

5. Commit your new working copy back to the new subversion server. This is just a normal commit at the root of the new working copy e.g.

   > cd ~/projects/projectName-new/trunk
   > svn ci -m "Committing out-of-sync work resulting from hard drive crash"

   You can then check-out/commit as normal from this point onwards.

   I strongly recommend deleting all the other directories and renaming the existing ‘new’ directory to just the project name to avoid confusion moving forward:

   e.g.

   > cd ~/projects
   > mv projectName-new projectName
   > rm -rf projectName-new-export projectName-old-export projectName-old

   Cheers,

   Les

So I was at work today, hammering away on the keyboard, when out of nowhere, as if coming through faint elevator speakers off in the distance, I heard Hiki’s first song on her latest Ultra Blue album, entitled “This is Love”.

I thought to myself, “Man, am I hearing things? What the hell? I know this can’t be coming from the sound-deadening cubicles of a large Southern corporation…”.

But I got up and searched for a bit. About 5 cubes away is someone showing off his iPhone to a fellow co-worker. When I arrived, there wasn’t any music playing, but I asked anyway. “I’m sorry to interrupt, but was someone here playing Utada Hikaru?”

They looked at me a bit funny at first, but then the guy holding the phone thought a second and said, “Oh, this?”, and played the song.

I was like “Yeah! That’s it! I love that girl…”

He said, “Oh yeah, its a song my daughter put on to my iPhone - she’s into Japanese things.”

Then I proceeded to tell them about my interest in Japanese culture, having been there once, etc. It was kind of cool.

But mostly I was really surprised to hear that song in this building. It was bizarre, since most people in the South have no clue who Hiki is. (My future wife just to clarify for you in case you don’t know)

Good stuff