Update

Just a quick update since I have not posted in so long. What have I been up to?

Well, I am currently on my second week this year of unpaid leave that my company has forced us to take. I'm not sure how I feel about that. I guess it is better than losing my job, but I would obviously rather be working and making money. This week is March Break here for the kids, so between keeping them busy and pet-sitting my brother's golden retriever Charlie while they are in Florida, I haven't really accomplished anything yet. It is only Tuesday, so I guess there is still hope.

Things I want to personally accomplish this week include:

• Getting some work done on the next batch of guitar amps that Todd and I are designing.


• Play around with and learn JavaScript.

Other things on the TODO list:

• Become a rock star.


• Solve the world's energy problems.


• Come up with a unified theory of everything.

I figure if I at least solve the last item, that *should* take care of the second-last one, and perhaps the rest will come naturally. For now, I'm off to make some juicy burgers for dinner. We have to enjoy this beautiful, 14 degree weather while we have it!

Validating Archive Contents With Ant

Have you ever wanted a quick way of validating the contents of an archive as part of your Ant build? I'm sure there are many ways to accomplish this, the most straightforward being to inflate it to a temporary directory, but yesterday I crafted up this little nugget to validate an archive in-place and it seems to work great. And the best part is there's no messy cleanup needed afterwards!

<!-- Compute the difference of the actual JAR and the expected zip entries -->
<resources id="artifact.set.discrepancies">
  <difference>
    <!-- Create a resource set from the actual archive -->
    <zipfileset src="${path.to}/some_archive.jar" includes="**/*" />
    <!-- Create a resource set of expected items -->
    <resources>
      <zipentry archive="${path.to}/some_archive.jar" name="afile.ext"/>
      <zipentry archive="${path.to}/some_archive.jar" name="anotherfile.ext"/>
      <zipentry archive="${path.to}/some_archive.jar" name="a/path/to/afile.ext"/>
      <zipentry archive="${path.to}/some_archive.jar" name="some/other/path/to/afile.ext"/>
      <zipentry archive="${path.to}/some_archive.jar" name="META-INF/MANIFEST.MF"/>
    </resources>
  </difference>
</resources>
<pathconvert property="set.difference" refid="artifact.set.discrepancies" />
<condition property="artifacts.verified">
  <resourcecount count="0" when="eq" refid="artifact.set.discrepancies" />
</condition>
<!-- Fail if any differences are found -->
<fail unless="artifacts.verified"
      message="The following artifacts were not expected: ${set.difference}" />

Note: I believe a minimum version of Ant 1.7 is required for the resources stuff to work.

Ant Wizardry

I've been spending a lot of time messing around with builds lately and that means reacquainting myself with my old friend, Ant. Back in the old days, I always wished there was an easy way to do simple string replacement/concatenation, creating a new property as a result. Sure you could use the antcontrib tasks, but I usually did not have access to them when it really counted and it was one more dependency to worry about. The other option is to mess with temporary files or some other naughty-feeling hackery (I think I used pathconvert once to do something like this and felt really dirty about it).

Anyway, as of Ant 1.7, check out what is possible. Run the following build file:

<project name="test" default="test">

  <target name="test">

    <loadresource property="abc">
      <string value="One two three four" />
    </loadresource>
    <echo message="abc=${abc}" />

    <loadproperties>
      <string value="one=two${line.separator}three=four"/>
    </loadproperties>
    <echo message="one=${one}" />
    <echo message="three=${three}" />

    <loadresource property="test">
      <string value="${one} two ${three} four" />
    </loadresource>
    <echo message="test=${test}" />

    <loadresource property="test2">
      <string value="${test}" />
      <filterchain>
        <replaceregex pattern="f(ou)r" 
                      replace="f\1l"
                      flags="g"/>
      </filterchain>
    </loadresource>
    <echo message="test2=${test2}" />

  </target>

</project>

And you will see this output:

C:\testing\>ant -f testbuild.xml
Buildfile: testbuild.xml

test:
     [echo] abc=One two three four
     [echo] one=two
     [echo] three=four
     [echo] test=two two four four
     [echo] test2=two two foul foul

BUILD SUCCESSFUL
Total time: 0 seconds

I wish I had this in my back pocket about four years ago...

Programming? What's That?

So it occurred to me that since I actually write code for a living, why haven't I posted anything related to Eclipse or Python (the former being basically my life at least 8 hours a day, and the latter being my favorite programming language). Hmm...I wonder if that says anything about my real interests?

Anyway - on to today's topic. I guess something that has been quite interesting (and also talked to death recently) has been Google's Android and their announcement of the Open Handset Alliance. I still find it amazing that me, being the tech nut that I am, still do not own a cell phone. I guess I have just never found one I would consider a) worth the money, and b) useful beyond making phone calls. I have dabbled with PDAs in the past, but nothing really impressed me. I think I would like a Crackberry, but the service is too damned expensive. The iPhone was mildly interesting for the cool technology factor, but so locked down it was ridiculous. And I could never see myself joining the "Apple crowd" anyway.

But I would buy a phone based on Android. Of course, I would probably go for a high-end model, or even take a shot a building up my own if that was an option. I think it would be really cool if a whole homebrew hardware community grew out of this as well. That would interest me.

What I find particularly interesting about this is how Google dealt with the whole Java <-> Sun mess. There is a very good summary of it here so I won't go into the details, but I am going to make a bold prediction:

The next language Google will announce (I say 'announce' because I'll wager an implementation already exists) for their Dalvik virtual machine will be Python.

Now *that* would be something. One can only hope.