Monday, December 29, 2003

Big Dig

I passed over and through the 'Big Dig' this weekend for the first time. It was funny driving over the L.Z.B.H bridge as everyone had their cameras out taking pictures (including me).


The whole experience was rather anti-climactic. In the end the bridge is just a bridge and the tunnel is just a tunnel - a rather Spartan drab tunnel at that. Given the cost one might expect some gold plate.

When we stopped to visit down town Boston I was surprised to see workers already taking down the old elevated central artery.

In retrospect I guess its probably one of the easiest tasks of the whole project.


I read someplace recently that city folk are now worried that all the pigeons who made their home under the elevated road will now invade the city. They had similar worries about rats when the project began.



Personal Art

I received an email this week from Mike Thomas of www.somoht.com, another blogger of the blogsphere who had stumbled across this site. I of course paid a reciprocal visit and must say I really liked his site. In addition to the standard commentary of a blog Mike has scanned art he created over the years and made it available for public viewing.

I too have done some painting, drawing and sculpting. I'm not a trained artist, but have dabbled for relaxation and fun. I've never recorded any of it digitially before but it seemed like a cool idea. I've added a top level information category called Art that contains an image gallary of my current scans. All of these images are of things I created in the 80s.

I've used the PHP based photo album software called Quick Digital Image Gallary as the hosting engine.

The Year of the Digital Camera

Lots of people I know received digital cameras this Christmas. In my family there were four. If you add in friends like Bob the count goes up.
My nephew Steve said he had heard on the news it was going to be the 'Year of the Digital Camera'. When I hear this phrase I can't help but think of the David Foster Wallace book Infinite Jest in which year names have been bought by corporations and much of the narrative takes place in the 'Year of the Depends Adult Undergarments'.


My camera is a snazzy little Casio Exilim EX-Z3. 3.2 megapixel, SD card, 3x optical zoom.

Wednesday, December 24, 2003

True Companion

True Companion or T.C. as he was known died yesterday from lethal injection after a short battle with cancer. T.C. was 10 years old.


A pure bred Siberian Husky, T.C, exhibited all the standard personality traits of the breed - strong willed, energetic, friendly and very vocal. In fact, his howls contained so many different tones you could swear there a language contained within.


He will be missed.

Drink Wheel

If you are planning to imbibe a quantity of holiday cheer you can estimate your safe limit with the help of this handy web site.

Monday, December 22, 2003

Tolkien and Wagner

GirlHacker blogged today about the connections between Tolkien's Ring mythology and Wagner's. She points to some interesting content. Its well worth a read




I have to admit a certain fondness for Wagnerian music and German culture in general. If you're not familiar with the Ring Cycle, this link has a good overview of the story: Der Ring Des Nibelungen.

The Spaceship and the Zeppelin

SpaceDaily has an interesting article comparing the problems of rigid airships with those of the space shuttle.


As I think about this and the lessons it implies about software, I can't help but think of EJBs as the big bloated Zeppelins of our day. I'll show you what I mean by considering a few of the points of the article in the context of EJBS



High Unit Cost -- Complexity of building high quality EJB.

Narrow Design Base -- Design being driven by a few corporate interests

Narrow Contractor Base -- Expensive and complicated licensing

Mammoth Ground Support Equipment -- Expensive infrastructure requirements

Inappropriate Traditions -- Warmed over CORBA

Low Safety Factors -- 88.888 up time

The Publicity Spotlight -- J2EE hype machine

Fanatical Promoters -- Corporate hype machines

Saturday, December 20, 2003

Eclipse 3.0 m6

I downloaded and installed the Eclipse 3.0 m6 build today. I don't have plans yet to adopt it as my primary edit environment but I wanted to kick it's tires and see how it feels. My initial impression is that its slower and clunkier than 2.x, but heck, its beta software. Some of the clunkiness stems from the plethora of new features in the Java IDE. I really think the Java IDE has reached the point of diminishing return when it comes to adding new features. It already had lots of bells and whistles I never used - now it has even more. I'm sure I will learn to love some of these new things in time but I feel sorry for new adopters who will have to wade through all the additional complexities in order to learn the platform.

PE version 0.82

I've updated PE to version 0.82. Along with some bug fixes this version introduces a tab bar for changing open edit buffers.

Friday, December 19, 2003

How Tree Syntax works in Groovy

Thanks to Jame's feedback I've been making steady progress in learning Groovy.

Today I had a few minutes and wanted to learn more about how the tree syntax mechanism works. What I found was surprisingly simple and elegant. Instead of this feature being a special part of the language, it's just a cool use of the core Groovy features. Imagine code like this.


builder = NodeBuilder.newInstance();
builder.people() {
person("Pete");
person("Jayne");
}


The code builder.people() is evaluated as a simple method call. In Groovy a method is called by calling the invokeMethod() method on the objects class. So at runtime this code will call BuildSupport.invokeMethod(...'people'...). The BuilderSupport base class (base class of NodeBuilder) has overridden invokeMethod() and rather than attempting to find and execute the method 'people', as most classes would do, the builder class instead creates a new Node with the name of the method - in this case 'people'.



The block

{ 

person("Pete");
person("Jayne");
}
is also just core Groovy syntax, in this case its a Closure that's executed in the context of people (and builder). If you aren't familiar with Closures I'm not the one to explain them to you. But the short description is they are (very cool) anonymous callback methods that inherit the context of the object which they are called from. As this Closure executes it attempts to run the person() methods on the people Node() (via Node.invokeMethod(...'person')), but that fails because Node doesn't have a method called 'people', the Closure then falls back on its 'delegate' object and attempt to execute the person method again. The 'delegate' object in this case is the NodeBuilder so instead of actually looking for a methods called person() , just as before, it makes the new Nodes of that name.
This is very cool OO stuff.


Wednesday, December 17, 2003

Guess the movie

GirlHacker has posted a little quiz that asks you to correlate a movies rating description with the actual movie. It's fun.

Groovy GPaths

I finally got a chance to play around with Groovie's GPaths. I encountered some confusion in using them but did surmount the problems with the help of some System.out.println statements (why no println command?). I started my exploration with a another look at tree syntax but this time I used a NodeBuilder instead of a MarkupBuilder. This change let me build a tree of objects instead of output some markup.
 

protected createTree() {
builder = NodeBuilder.newInstance()

root = builder.people() {
person('James') {
location('London')
projects {
project('geronimo')
}
}
person('Bob') {
location('Atlanta')
projects {
project('drools')
project('jessy')
}
}
}
return root;
}

I then tried to build a Gpath that selected a person who participated in the jessy project.

tree = createTree()
s = tree.person.find {
it.projects.project.any {
return it.value() == 'jessy'
};
}

This snippet finds a person who has any project that has a value of 'jessy'. If I call System.out.println(s) I will see a value like:

person[attributes={}; value=[Bob, location[attributes={}; value=Atlanta],
projects[attributes={};value=[project[attributes={}; value=drools],
project[attributes={}; value=jessy]]]]]

I did find it confusing that I was required to call .value() in the comparison. I was assuming that some sort if automatic string transformation would occur when I compared node to string.

Epigrams in Programming

These quotes from Alan J Perlis seem to have been around for a while, but I'd never seen them. I tracked them down after reading
19. A language that doesn't affect the way you think about programming, is not worth knowing.
in the Nice manual. Others that spring out from the list:
31. Simplicity does not precede complexity, but follows it.

58. Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.

95. Don't have good ideas if you aren't willing to be responsible for them.

104. The proof of a system's value is its existence.

Tuesday, December 16, 2003

Bloggerhythm or Blog Tide

I want a new word or phrase for a trend I've noticed in my blog postings and those of the bloggers I read. There are clear peaks and valleys in posting rates that don't always directly correspond to the blogger's time to blog. The two candidates that jumped into my head are: bloggerhythem - their bloggerhythem is slow this week and blog tide - my blog tide is rising but the more I think of them the less I'm convinced they describe the problem appropriately. Anyone have a suggestion?

Generic throws clauses in Java interfaces declarations

Anyone who has written an EJB to expose a POJO (Plain Old Java Object) has encountered the problem - your POJO implements an interface and you would like to reuses that interface declaration when you write your EJB's remote interface declaration; but you can't because the remote EJB methods must throw RemoteException and the base interface methods don't. So what do you do? Pragmatic Programmers out there might write some code generation code that builds the remote interface but more likely than not you copy-paste-modify the original interface. All this leading inevitably to a future maintenance problem


This isn't just a J2EE issue either, other code can have layering designs that change the sort of exceptions that are thrown but not the basic signature of the methods. (Its just such code I'm dealing with today at work that's sparking this rant). What I'm dreaming of is support of some sort of generic exception declarations in an interface. Rather than always declaring the throws I would like to be able declare an exception agnostic interface and then derive exception explicit variations from that base version. Here's an example in my dream pseudo Java:



A simple generic interface class with no explicit throws


public abstract interface AbstractFoo {
void methodOne() throws *;
void methodTwo() throws *;
}


A derivation of the generic interface that throws SomeException

public interface Foo extends AbstractFoo throws SomeException {
}


Another derivation of the generic interface that throw RemoteException and SomeException.

public interface FooRemote extends AbstractFoo
throws SomeException, RemoteException {
}

I wont hold my breath.


Saturday, December 13, 2003

Tree like structures in Groovy

As I've mentioned before, Groovy is a Java scripting language being developed in part by the prolific James Strachan. I was home sick on Friday and spent some time looking at it.

One aspect of the language I find particularly intriguing is its built in support for tree syntax. Here's a little HTML generation snippet I wrote in Groovy that uses the tree syntax

h = new MarkupBuilder()
h.html() {
head() {
title("Page Title")
}
body(){

h1("Hello World")
div(id:'Foo') {
div("Content")
}
}
}

This code would generate some simple HTML like:

<html>
<head><title>Page Title</title></head>
<body>
<h1>Hello World</h1>
<div id='Foo'><div>Content</div></div></body>
</html>

The cool thing is that the content of the tree syntax can be more Groovy code. Instead of just outputting one h1 with the message Hello World I could write something like this:

h = new MarkupBuilder()
h.html() {
head() {
title("Page Title")
}
body(){

for (x in ["World", "Pete", "Bob"]) {
h1("Hello "+x)
}
div(id:'Foo') {
div("Content")
}
}
}

The language also has an XPath like syntax called GPath that allows you to select subsets of these tree like structures. I haven't played around with this yet but it looks very powerful. This is an example from the doc.

>>> println( listOfPeople.findAll { it.location == 'UK'}.name );
["James"]

The language is still evolving so it has some rough edges. Also the doc is pretty sparten so be prepared to dig through the test code to find some examples.

I've been frogged

See the frog comment below. I didn't make that. I do like frogs however.

Friday, December 12, 2003

frog

frogs

Debuggers

A lot of bloggers are talking about the merits of using debuggers vs. print statements. It all seems like a mighty waste of time to me. Both are very useful and should be in the skills toolbox of anyone doing development. My current project at work is multi-threaded networking code that's hard to debug with a debugger but that doesn't mean I don't ever use one. In fact the whole topic is so stupid I don't know why I'm wasting any time blogging about it. Arg.

Thursday, December 11, 2003

Gary Devendorf's Blog

I keep finding blogs of people I know. This is pretty cool. Most of you that read this know Gary but if you don't he's a ex-Iris/IBMer now working for the evil empire - Microsoft, not the Yankees. Gary was my mentor for public speaking and we did a few LotusSphere and Dev Con presentations together.

Starburst Memorials

The Columbiad company will send you into space for only $12,500. Catch is you must be dead.


You have to love their logo - a flying urn. They have a pretty website too.

Wednesday, December 10, 2003

Pay the Ground


In keeping with the holiday season I wanted to share this information on one of the odder and funnier Christmas traditions I've ever heard of- the Caganer. The Caganers was originally brought to my attention many years ago by an entry in memepool.com but the links that post contains are now dead. I thought it was interesting enough I wanted to bring it back again.


The tradition of the Caganer comes to us from the region of Spain known as Catalan. The Caganer is a figurine that's typically added to Nativity displays to bring good luck. The odd thing is that figurine is depicted defecating or "paying the ground" as one maker of the figurines described it. (That's a nice earthy euphemism)


The e-shop Caganer.com has quite a collection of figurines if you're interested.

Doug Ross's blog

I stumbled on the blog of an old co-worker and friend today. Doug moved back to the Midwest quite a few years ago and except for a few email we haven't kept in touch. It will be fun to hear what he has to say.


Doug's a very smart and entrepreneurial guy with a wide range of interests. I have to give Doug a lot of credit for my progress as a developer. He was preaching unit tests and black box object layering way before it became vogue.

Blogger bug?

I've lost the text of two posts in as many days because of some issue with my session disappearing and Blogger requiring me to re-login. It always seems to occur when I run a spell check but I don't know if that has anything to do with it. Regardless I'm a little wary of that feature right now so forgive my horrible spelling.

Tuesday, December 09, 2003

Inner classes

I love Java's inner classes. Most non-ui Java developers seem to ignore them, but I think that's a mistake. Here are a few ways I like to use them:



1. Common implementations of an abstract type.



Using interfaces in an API instead of classes is usually a good idea but it adds a level of indirection. You can compensate by using inner classes to make your API a little easier. Let's say you have a class and a related interface like this:




public interface Value {
int getIntValue();
String getStringValue();
}



public class Foo {
public void doit(Value v) {....}
}


Using the interface instead of an explicit object add a lot of flexibility but unless you provide a default implementation of the interface you've pushed off some tedious work onto your callers. Rather then creating a separate implementation class I like to use inner classes in this case. You could start out with the most common implementation like this...


public interface Value {
int getIntValue();
String getStringValue();

public static class StringVersion implements Value{
private String _s;
public StringVersion(String s) {
_s = s;'
}
public int getIntValue() {
return Integer.parseInt(_s);
}
public int getStringValue() {
return _s;
}
}
}


and then add on later. This works really well when there is more than one implementation as it keeps a level of direct association between the interface and the implementations that isn't there when you use new top level classes.



2. Exception hierarchies



Exception hierarchies are all over the place in the core Java libraries but its rather hard to keep track of the associations without following all the links in Javadoc. I think using this method of child Exceptions being declared as inner classes or the root exception keeps things simpler and easier to maintain.


public class NetworkException extends Exception {

....

public static class Bind extends NetworkException {

public Bind() {
super("Bind Error.....");
}
}

public static class Host extends NetworkException {

public Bind() {
super("Host Error....");
}
}

}




....
throw new Bind.NetworkException();
....


3. Tightly coupled parameter classes/interfaces



Bundling associated parameters into a class or interface is a often a good idea. It allows you to modify the parameters of the method without always needing to find and modify every instance of every call. Rather than create a new top level class or interface for such a construct, use an inner class (or interface) instead.


public class Foo {
public static class Params {
}

public Foo() {
}

public void method(Foo.Params params) {
}
}




Nuclear Space

It's been exciting to hear some of the latest talk coming from the Whitehouse regarding space policy. I wonder whether the folks at nuclearspace.com will find a voice in them. They have an interesting vision, albeit a bit unsettling. I can't help but think of the mad scientist from Repo Man.
Radiation, yes indeed! You hear the most outrageous lies about it. Half-baked goggle-boxed do-gooders telling everybody it’s bad for you. Pernicious nonsense! Everybody could stand a hundred chest X-rays a year. They ought to have 'em too.

On the topic of Repo Man, these folks have the entire transcript. Its a fun read. The movie had such classic lines.

Wednesday, December 03, 2003

Elephants missing link

Here's an Interesting science tid-bit from Reuters on some new fossil finds in Ethiopia. Fossils Bridge Gap in African Mammal Evolution

Bloggers Block

I think I need to read this page: Overcoming Blogger's Block.

 
The Out Campaign: Scarlet Letter of Atheism