Laid off, looking for work.

February 26, 2009

[ Note:  The following status replaced with 2009-03-24: Start Date at Monsanto. ]


As of this morning, I found myself a participant in the second round of layoffs at my (now former) employer, Asynchrony Solutions.  They’ve been a great place to work — the people, the work environment, the opportunities to improve myself and to help our customers solve business problems.  But the current economic environment has been very hard on Asynchrony:  Loss of projects and delayed sales have cut income to the point where the expenses of the company, primarily employee salaries, simply had to be cut.


So, as of this morning, I am looking for work.


I have substantial experience as a consultant and contractor — leading, coaching, and contributing to software development projects in a variety of technologies in both Java and Microsoft environments.  (…including .NET, C#, VB, C++, COM, etc.)


I currently live in the Saint Louis, Missouri metropolitan area, and I am willing to relocate to just about any reasonable location.  (I have a preference for the West coast, or possibly Texas, should there be interesting opportunities available.)


For the short term, I have a job search to start.  And blogging is not my primary strategy for finding a new job.  ;->


Thank you for the interest!

     – jeff

Why Matthias Ernst’s “Chaining: A Modest Language Proposal” for Java would be nice to have

February 14, 2009

OK, shouting at my MP3 player hasn’t been doing me any good; it’s just helping other drivers recognize how passionate I am. ;-> So I’ll try writing about it instead:

After listening to recent Java Posse podcast episodes, I’ve been working my way back to earlier episodes, and I keep tripping over discussions (as in Episide #151) of Matthias Ernst’s “Chaining: A Modest Language Proposal” — which would make the compiler enable a method chaining / “fluid interface” convention on methods returning the void type.

Like the Java Posse members, I’m also somewhat bothered by the idea of reinterpreting void return types, but I think it will be helpful to consider this example of code that would be fixed by his proposal:

Consider these two classes:
public class Base {
  public Base setBaseStuff() { /* ... */ return this; }
public class Sub extends Base {
  public Sub setSubStuff() { /* ... */ return this; }

This code works:
  new Sub().setSubStuff().setBaseStuff();
This code doesn’t compile:
  new Sub().setBaseStuff().setSubStuff();

The problem is that when you’re using method chaining on classes that extend other classes and which add methods…  You MUST call subclass methods before calling superclass methods.  Otherwise it won’t compile.

With the “Chained Invocations” proposal, if the methods returned void, both method calling orders would compile and work fine.

This happens because the compiler knows more about the type of the callee than the method declaration: When the compiler assumes that void methods return ‘this’, it knows the specific subclass type of ‘this’ — while the method declarations don’t.

In essence…
  new Sub().setBaseStuff().setSubStuff();
  Sub s = new Sub();

This may not seem like much. But what happens when you have a significant number of methods, and possibly several inheritance levels?

Consider these classes:

  public class A {
    public A a1() { /* ... */ return this; }
    public A a2() { /* ... */ return this; }
    public A a3() { /* ... */ return this; }
  public class B extends A {
    public B b1() { /* ... */ return this; }
    public B b2() { /* ... */ return this; }
    public B b3() { /* ... */ return this; }
  public class C extends B {
    public C c1() { /* ... */ return this; }
    public C c2() { /* ... */ return this; }
    public C c3() { /* ... */ return this; }

And this expression:
  new C().c1().c2().c3().b1().b2().b3().a1().a2().a3();

Like this:
  new C().c1().c2().a2().c3().b1().b2().b3().a1().a3();

So are we on the same page now, as to why this change might be nice to have?

New Google Mapplet release: GPS Location

February 12, 2009

I just released a new Google Mapplet, I’m calling “GPS Location“. [Click on the “GPS Location” link to add it to your Google maps as a “My Maps” tool.]

I was inspired to write this by using Thomas Duebendorfer’s “Position Finder” Google Mapplet: I’ve been using it for several months, but have been frustrated with its limitations, and how much I have to “futz” with its output to get suitable results. So I wrote my own.

What makes my GPS Location Mapplet better than Position Finder is…

  • I round the latitude and longitude values to a reasonable number of decimal places, given the current zoom level. It was just annoying the heck out of me when Position Finder gave me coordinates that were 8 to 10 orders of magnitude more precise than the maximum resolution one can legally get in public satellite maps. I was always rounding the results by hand.
  • GPS Location supports multiple points on the map simultaneously. And you can move them.

I’m still trying to figure out how to jsUnit test my little GPS Location Mapplet — both integration tests within Google Maps, and Test Driven Development (TDD) code writing with mocks for the Google Map APIs. But those are stories to be implemented another day.

Tim Ottinger’s “Technical Debt” card

February 12, 2009

I like Jeff Langr and Tim Ottinger’s “Technical Debt” card, as a suitable reminder of the costs of accumulating technical debt. I posted one in our workspace. Thanks to Tim and Jeff (L.)!

LINQ for Java? Anders Norås’ Quaere Library

February 8, 2009

I just heard about Anders Norås’ Quaere Library yesterday:

My friend Google was easily able to direct me to additional information at…

  • [Anders Norås’ Blog entry, “Introducing Quaere – Language integrated queryies for Java” is no longer available online.]
  • TheServerSide article, “LINQ for Java: Quaere”

Naturally, this prompted me to document this development in my favorite place — a LanguageIntegratedQueryForJava page on Ward’s Wiki.

Quaere doesn’t seem to offer database or XML operations. But I don’t see why this idea couldn’t be expanded to do such things. It’s a very interesting idea. I hope it’s successful.

What blogs are good for

February 6, 2009

I’m warming up to this “blogging” thing…

I’m thinking that the value of blogging, for me, is that it provides a better place to speak my piece in my voice than Wikis or discussion groups.

It’s a good place to…

  • Tell stories / Talk about my history.
  • Talk about what I’m doing right now. (I am so not into Twitter.)

But I’ll always remember My very first blog post. (As well I should, as it was only three days ago! ;-)

Property-Field Transparency

February 6, 2009

I learned Object-Oriented programming (and a great many other things) while working in the Electronic Data Systems (EDS’s) Research and Development department in the late 1980’s. A lot of EDS R&D work was done in an internally developed OO language called “OWL” — a language that was inspired by Smalltalk, had an S-Expression text syntax for code, and could be interpreted by or compiled into C, running on Sun Unix workstations.

One particularly interesting feature of the EDS OWL programming language was that it supported “Property / Field Transparency” — meaning that there was no absolutely no difference, in client usage syntax, between use of “public fields” and the use of “properties” (where data access is mediated through code in getter and setter methods).

The big advantage of Property-Field Transparency is that you can safely DoTheSimplestThingThatCouldPossiblyWork, while writing code, by making all business object fields public. Should you discover later that you need an additional layer of abstraction, you can easily change a public field to a Property, and code the appropriate getter and setter methods, without making any changes to the code that uses that class at all. Thus in languages supporting Property-Field Transparency, you can avoid the source code clutter and maintenance expense of maintaining a great many meaningless repetitive boiler-plate getter and setter methods; and yet you can still quite easily and safely insert them later, where needed, with minimal impact. There isn’t even any need for refactoring support in your IDE, or multiple file checkins.

So it was with great interest that I noticed increasing levels of Property-Field Transparency support in modern languages in recent years: Most scripting languages in the Java environment do this, following the Java Bean standards. (But the Java language itself continues to steadfastly buck the trend!) And in the Microsoft environment, COM and then the .NET environment seem to have embraced support for properties — giving developers fairly good Property-Field Transparency across the board.

But it still annoys and troubles me that most of the industry seems to be avoiding taking advantage of Property-Field Transparency to simplify their code and reduce their costs. Sometimes most of the industry seems to be hooked on “Cargo Cult” practices and ideas — that is, we keep doing things that were the best thing to do at one time, but may no longer be appropriate now — possibly because the practitioners have long since stopped thinking about WHY they’re doing the things they’re doing, and just continue rote practices with the justification that “A great man said that we should do it this way some years go. How dare we question that?”

It was my experience with Property-Field Transparency in the EDS OWL language that inspired me to post some of my ideas on this topic by creating the PropertyFieldTransparency page on one of my favorite web sites, Ward’s Wiki: