# Wednesday, 04 August 2004

I realize this is a rant, and not strictly technical, but here's one soapbox (among many) I'm willing to step up to. 

For ~95% of business software, the actual code needed to implement them ends up being, if not trivial, then at least not technically challenging.  Business software projects go over budget/schedule etc. because the business rules aren't known (to anyone) or because no one in the organization really knows what they want.  As a further complication, people who are tightly focused on a particular domain tend to make things sound way more complicated than they turn out to be because they aren't building their models at the right level. 

When it actually comes down to writing the code to implement the loosely defined business system, it's almost always "just code".  Not challenging to write, often tedious and time consuming, but not in any way difficult from a CS standpoint. 

So, the challenge when writing such software is in cutting though all the BS to get at which little bits of "just code" you have to write.  Once you get that part out of the way, the actual coding bit is easy.  So when people complain that projects are going way over budget/schedule/what have you, it's almost always (in my experience) due to the fact that engineers spend 6 hours a day poring over vague and conflicting sets of documents, and 2 hours writing code. 

Along the same lines, anyone who's looked seriously into enterprise level web services understands that the barriers to real business to business communications aren't technical barriers.  They are organizational.  If only two or more businesses could agree on what the schema for a purchase order should look like, we'd see a real renaissance in B2B computing.  The technologies are all there, the hard part is getting the organizations to work together.  That's the problem to solve. 


Wednesday, 04 August 2004 11:42:05 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [2]  | 

I'll be teaching at OIT (in Portland/Beaverton, not K-Falls) again Fall term.  This time it's "Practical Web Services".  If you're interested, sign up through OIT.  The course number is 15048.  Description follows:

Practical Web Services

Web Services sound like a great idea, but how do you actually go about using them?  How do you go about actually writing your own Web Service to expose your data or functionality?

This class will cover all the details involved in using and building your own Web Services using the Microsoft .NET platform.  The first half of the class will cover the building of a client application to consume a Web Service from the Internet.  The second half will focus on building an equivalent Web Service using ASP.NET.

Students will leave this class with a firm understanding of how to use Web Services built by other people, and how to implement their own Web Services using the .NET platform.

Students should either have taken the previous "Web Services Theory" class, or have instructor approval.  All work will be done in C#, so a firm understanding of C# is required.

Wednesday, 04 August 2004 09:47:02 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Tuesday, 03 August 2004

In pursuit of my new nerdy hobby, yesterday I got a new radio.  A Yaesu VX-7R.  I'm amazed by three things so far:

  • How small the thing is (it's tiny, the antenna is about 2.5 times as long as the unit)
  • How amazingly complex the UI is (and how small the buttons are)
  • How fabulous the receive audio sounds.  I was listening to some guys yakking on a repeater last night, and it was amazingly clear.  Much more so than the old Kenwood I've been using.

The UI is amazingly complex, and I have a few issues with it so far.  Given the very limited space they had to work with and the paucity of input controls, they actually did pretty well.  But there are a few instances where you have to press an additional key to edit something, or an additional key to finish editing something, and they aren't always the same, so you "just have to know".  That's frustrating.  Much is accomplished with the tuning dial, which is pretty cool, but again it's not obvious when it works and when it doesn't.  Given all the space and control limitations I'm willing to forgive a lot though, so overall I'm pretty favorably impressed.  Which isn't to say I don't want to get the programming cable so I can just edit all the memories on my PC.  That'd go way quicker. 

Tuesday, 03 August 2004 14:42:34 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Friday, 30 July 2004
Eric Gunnerson points to a post by Jeremy Rule about how he flash-cooked a hamburger using a giant Fresnel lens.  Pretty groovy stuff, although Jeremy says the burger wasn't very tasty.  It got me thinking, though, that a really fun project would be to take one of those giant Fresnel lenses and see if one could build a miniature solar-thermal generator, like these.  A nice big cast-iron pot with a lid, a few holes drilled, very small steam turbine...  See where this is going?  Unfortunately I'm way to lazy to actually try it myself.  I haven't even gotten around to trying out the DIY solar pizza oven.  :-(
Friday, 30 July 2004 14:26:39 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [1]  | 

After an inspirational post by Loren Halvorson, we decided to emulate his team's use of an Ambient Orb to track the status of our continuous integration builds. 

After being backordered for a couple of months, it finally show up yesterday.  It's happily glowing green on my desk as I write this.  Unfortunately, what we didn't know is that in order to bend the orb to our will and get it to show our build status, we have to shell out $20 a quarter for their "premium" service.  Humph.  Plus, I've been having some "issues" with it.  It's supposed to reflect the current status of the DJIA, which is down right now, but the orb is green, which is supposed to indicate that the Dow is up.  I can't seem to make it be anything but green.  I know it's not a problem with the lights, because when it was "synchronizing" it strobed through just about every color there is.  After it's done though, I only get green. 

Anyway, all that together has prompted us to order their serial interface kit, so we can control the thing directly without depending on their wireless network.  Maybe not as elegant, but it should be deterministic, which it more important in this case.  Seems like a lot of work for what was supposed to be a funny toy.  :-)

Friday, 30 July 2004 11:36:02 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [1]  | 
# Friday, 23 July 2004

Back in the day I went to High School in what passes for "inner city" in Seattle (Garfield HS: Go Bulldogs!) and was therefore exposed to a pretty fascinating cultural milieu. :-)  Anyway, out of pure nostalgia for days bygone, I couldn't resist picking up copies of Breakin' (1 and 2) on DVD.  While not great pieces of cinematic history, they sure are fun to watch.  My 9 year old son is totally into them.  He says #1 is better.

I wonder what every happened to the lovely Lucinda Dickey?  Her career just wan't the same after Ninja III: The Domination.

Now I just need a copy of Krush Groove:-D

Friday, 23 July 2004 14:53:36 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [1]  | 

This should be totally obvious to those with XML experience, but to those who don't fall into that category, keep in mind that it's of utmost importance to not mix data and meta-data when designing your XML.  For example, when creating an XML document for a purchase order, I've often seen stuff like

    <name>widget x</name>
    <name>widget z</name>

This is what i mean by mixing data and meta-data.  By naming elements "item1" and "item2" you've mixed data (ordinal values "1" and "2") with meta-data (the description "item").  Now when you go to write a schema to match this document, what do you do?  Explicitly name elements item1 and item2?  What happens when you get a PO with 3 items.  You're screwed. 

Again, to those who are used to working with XML, this is readily apparent, but I found out from the class I taught this summer that it isn't obvious to everyone.  A much better solution would be something like

  <item number="1">
    <name>widget x</name>
  <item number="2">  <!--[Update:] fixed.  Thanks Haacked-->
    <name>widget z</name>

In that case the meta-date is property separated.  In this particular case, you don't actually have to specify the number at all, since the elements are inherently ordered, but you get the idea. 

Remember, friends don't let friends write bad XML.

Friday, 23 July 2004 13:10:29 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [3]  | 

Our continuous integration efforts came crashing down around our ears yesterday.  Our build started failing on Wednesday evening, after someone checked in a ton of changes all at once (not very continuous, I know).  That turned into a snowball of issues that took Scott and I all day yesterday to unravel.  Even after we'd fixed all the consequences of such large code changes (that was done maybe by noon) things continued not to work.  To make matters more dicey, at some point during the day our CVS server went TU, and had to be rebooted.  Builds continued to fail, mostly with weird timeout problems.  We were also seeing lots of locks being held open which was slowing down the build, contributing to the timeouts, etc. 

We ended up building manually just to get a build out, which was suboptimal but necessary. 

Thankfully, Scott was able to track down the problem last night.  Turns out that when the CVS box went down, our build server was in the middle of a CVS "tag" operation, a.k.a. labeling.  That left a bunch of crud on the CVS box that meant that subsequent tagging operations failed miserably, thus causing the timeouts, etc.  A few well placed file deletions on the CVS server cleaned things up, and we're (relatively) back to normal now. 

While I think that continuous integration is a fabulous idea, it's times like these that bring home just how many things have to go right at the same time for it to work.  What a tangled web we weave. :-)

Friday, 23 July 2004 10:54:00 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Monday, 19 July 2004

Just in case I wasn't a big enough geek before, I'm now officially KE7BJG.  That's right.  A licensed amateur radio operator (Technician class). 

I got interested in the idea of amateur radio through the emergency responder training I had last year.  I'd previously had no idea, but it turns out that in times of disaster/emergency, hams are instrumental in providing emergency communications through programs such as ARES and RACES.  That's a pretty important service, and I decided I'd like to be able to help out. 

In the process of studying for the licensing exam, I found out that the whole art and science of radio wave propagation is pretty darned fascinating. 

Ah well, it's not like anyone didn't know I was a nerd before :-).  My wife just shakes her head and sighs.  She says if I ever put up a tower in the backyard for antennas it's all over between us. 

Monday, 19 July 2004 11:33:16 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [1]  | 
# Thursday, 15 July 2004

I finished up my Web Services Theory class at OIT last night.  Just the final to go on Monday (mwah ha ha).

We ended with some stuff on WS-* and all the various specs.  I tried to spend minimal time on the actual syntax of WS-*, since some of them are pretty hairy, and spent more time on the business cases for WS-*.  That seemed to go over pretty well.  I think it's easier to understand the business case for why we need WS-Security than it is to understand the spec itself.  Unfortunately, on of the underlying assumptions about all the GXA/WS-* specs is that eventually they will just fade into the background, and you'll never see the actual XML, since some framework piece (like WSE 2.0) will just "take care of it" for you.  What that means is that the actual XML can be pretty complex.  The unfortunate part is that we don't have all those framework bits yet, so we have to deal with all the complexity ourselves.  Thankfully more tools like WSE 2 are available to hide some of that from the average developer.  On the other hand, I'm a great believer in taking the red pill and understanding what really goes on underneath our framework implemenations. 

Thursday, 15 July 2004 16:40:53 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  |