Tuesday, June 24, 2008

Useful SQL

Crafty way to create a temporary table (view) with some rows in it:

CREATE VIEW Xyz AS
    SELECT 'A' AS id
UNION ALL
    SELECT 'B' AS id
UNION ALL
    SELECT 'C' AS id
UNION ALL
    SELECT 'D' AS id;

Creates a table:

Xyz
id
A
B
C
D

Tuesday, June 17, 2008

Maven

With some recent projects I have been instructed to use Maven to fetch and build software. I was struck by how hard it was to do anything and how much time I spent faffing with the build environment rather than doing anything productive!

I felt like I was back in the 70's building some mainframe UNIX OS - not trying to build some trivial open source library for Java!

Is it just me or does Maven represent a massive step backwards? Here are my pet gripes (in no particular order)
  1. Centralised software "catalogue" - I don't think this is a good idea for the same reason library catalogues suck. One man's "popular fiction" is another man's "crime novel" etc. How can you find stuff?
  2. It is full of very deep voodoo parameters (so are most builds) and settings files spread liberally around the filesystem
  3. It fails in some spectacularly unhelpful ways
  4. When you read the documentation and support forums - most of the focus is on nursing the beast into just working. Surely it working should be a "no brainer"... only when I want to fiddle with stuff do I need to read the detail?

Maybe I am just looking at a bad example project that does not use the tool correclty? But I can't help but think: what does this tool do for my build environment that a decent build document and a set of human friendly tools (an IDE?) don't.

Can I more easily set up new team members with a productive build environment? Is it faster than copying a Virtual PC image and clicking "start"?

Layering Abstractions

Just a braindump/moan...

In my work I often see people writing library code (A) that "wraps" and "simplifies" use of another library (B). When I see this it immediately makes me think:

  1. The person who wrote the (A) automatically assumed (B) was going to be too hard to use.
  2. They Google'd some feature they were looking for and found (A) supported it. But (A) supported lots more besides, so (A) did not look exactly like what they had imagined.
  3. They did not bother to learn how to use (A) properly, before then creating an application using (A).
  4. Instead they learned to use (A) by creating a wrapper (B).
  5. Does (B) add any value - simplifying is not value.
  6. There is this idea that if you keep abstracting the final application that "joins them together" will somehow write itself.
  7. Creating re-useable libraries is what good programmers do. I am a good programmer -> I must create some libraries.
  8. If I had written (A) I would have done it more like (B).
  9. (B) Provides a "layer of indirection" allowing me to choose to swap (A) for an alternative library (C) one day in the future.
  10. Writing (B) makes you look busy while you deliver the work of (A) wrapped up with your name on it. It's basically plagiarism!

But (B) just introduces more maintenance? Worse still it makes maintenance harder while developers pick through unnecessary "proxy" and "interface classes".

Why not simply write an app that uses a subset of (A) directly?

To me it smacks of a work avoidance technique. Rather than think about how to address a customers problems, or stick your neck out and make a bet on a library... it's easier to write an abstraction layer, which will allegedly "make it easier" to write the business app one day in the future.