Off to Florida

Welp, it's that time of year again. Every year my wife and I head back down to Tampa, FL where all of our family is at, and spend the week running around from house to house to make sure we see everyone. This year is a special treat because we have *4* events to be at on the 4th.

But we love seeing the family, and though it's a bit of a drive (about 9 hours) it's worth it.

I'll be without internet for most of the time we're there, so see you all again next Friday!

Clairvoyant contractors and employees

I recently stumbled across a blog called Anonymous Lawyer that is supposed to be the fictional blog of a lawyer in a large law firm. Good reading. But one of his/her posts in particular hit very close to home. How many times have you been told by your company, or by a client, that you should be more of a people person. That you should have a long term vision, and be able to see problems coming that no one else can see, so you can fix them before they happen?

I have, and I've always thought it a bunch of bull hockey. Companies don't want you to do anything other than make more money for them, and not cause a stir. They should just tell you that in the interview. They do want you to solve their magical problem before it blows up, but they don't want you to make a big deal about the ones that aren't going to blow up, because those aren't really problems. This snippet couldn't have said this better:

Today's moron told us they fired their last firm because there were issues "they could have spotted in advance had they paid more attention, but instead they waited until they were real problems, and it ended up costing millions more to solve them." Well, sure, in a fantasy world, we'd solve problems before they ever became problems. But that's the client's fantasy, not ours. Do you think the firm they fired is upset because the jobs cost millions more of the client's money? No way. Economically, where's our incentive to find the problems early anyway? You're willing to pay more when you're being sued then 6 months before when you "might" be sued, "if" the customers ever find out. At that point you don't want us telling you there's a problem. You're not willing to pay us the money it would take to fix it anyway. It's not a problem yet. You just want to ignore it. So stop lying and telling us you want us to find problems early. You don't. You want us to find the one that's going to erupt into a lawsuit, but the nine that won't, you don't want us touching. And we're no better at fortune-telling than you. - Anonymous Lawyer

Exactly. Solve the issues that are going to be problems before they become problems but don't bring up the other issues that aren't going to be problems becuase we don't want to hear about those now. Maybe that's why I liked the years with the fire department as much as I did. There was no question what the people wanted you to solve when they called you. Usually if there were "fires to put out", it was literal, and very obvious what was on fire, and what the dangers were of it continuing to burn. Of if someone had "hit a wall", they weren't just stuck in their work, they were very often trapped in their car, which we had to carefully pry away.

(For those interested: I found the above site in the Time magazine 50 Coolest Websites which I'm glad to have stumbled across)

Back up and running

Over the past week, I've been working on updating the packages on my home machine. I'm running Gentoo, and have for the most part ignored emerge -u world until this week. I finally took the plunge to actually read about it, and after fixing some blocking packages (Yes, you can emerge -C mozilla-thunderbird without it wiping out your existing mail and profile) I started it up.

After about a day and a half of running (including some various errors) I noticed my desktop was behaving a little strangely. So I logged out, so I could reboot. Then X crashed. And stayed crashed. Nothing I could do would get it back up and running.

After about 10 hours of working on trying to get it back up, I decided to just let emerge update my entire Gnome install, and 14 hours later, rebooted and everything is back up and running. I like the updated Gnome too (coming from 2.4 Gnome to 2.10 Gnome is a nice improvement!).

QOTD Award: I hope you're really charming

A recent post on the Joel on Software boards asked a time-old question, "Need to cram for Java interview, what will they ask?"

The response? Perhaps one of the best quotes ever, coming from one BenjiSmith:

Well, they might ask you about the Java programming language.

In which case, you'll probably be screwed.

I hope you're really charming.

Let's go crazy - accessing Timberline / Pervasive Data from a SQL Linked Server

The latest project I am working on introduced me to the wonderful world of Timberline. This is one of the few times when I truly wish the customer we're building this for would have used Access. Really!

But, Timberline (an accounting package that sits on top of Pervasive SQL which sits on top of Btrieve) has been around for quite a while, and has a large enough user base in the construction industry that it bears looking at how we can provide a mobile solution for them.

Anyway, one of the things is that we need to be able to sync with their data. I'd looked at some options for ad-hoc querying of the database, including using the Pervasive OLEDB driver, the Pervasive ODBC Driver, and the Timberline Driver. While I have the data dictionary for the app, I wanted a better way to inspect what is in the database.

Luckily, Google Groups pointed to a post with someone talking about doing a linked server in SQL to Pervasive. I was able to get this work using the Timberline ODBC driver, and there are enough quirks to merit a post on it.

The basic concept is that after creating the linked server, we would then query it using SQL statements to pull the data from Timberline. This gives us some more options as far as flexibility of the interface.

To get the linked server working, you have to first create the linked server. Actually, you need to first create an ODBC Connection in your Server DSN, but that's pretty straightforward. So in Query Analyzer, run the following:

EXEC sp_addlinkedserver
@server = 'TimberlineTest',
@provider = 'MSDASQL',
@srvproduct='Timberline Data',
@datasrc = 'DataTest'
--@Server is the name of the new linked server
--@Provider is the SQL Provider
--@datasrc is the name of a local ODBC DSN
--@srvproduct is the Timberline Driver
--@datasrc is the Server DSN you created

(BTW, if you need to drop the linked server the command is "exec sp_dropserver TimberlineTest" (without the quotes))

So, now that you have that created, you can get all the available tables:

exec sp_tables_ex 'TimberlineTest'

Finally, you can query a table by issuing the following command:

select * from [TimberlineTest].[C:\Timberline\Accounting\MyData]..[PRM_MASTER__EMPLOYEE]
--First, the name of the linked server
--Second, the path to the data Files
--Third, Nothing
--Fourth, the table name.

And that's it! As I work through this I'll post if I come across any other oddities.

Negotiating

A recent thread on Joel on Software talked about negotiating. I read a book about a year ago by a brilliant guy named Herb Cohen called /Negotiate This, By Caring But Not T-H-A-T Much/. I highly recommend it if you do any kind of negotiating - even over things like what you'll have for dinner.

Spying on Novell

So I check into my hotel in Provo, UT after all kinds of airport fiasco stuff. I open up the window and what do I see?



That's right, I'll be darned if I didn't check in next to Novell headquarters. I completely forgot they were out here. It's a *very* nice looking campus, mountains all around.

Provo is so nice that I'm trying to convince my boss to let us open a satellite office out here since we already have one employee. Don't think it'll happen, but man is it nice out here!

I'll be taking some more pictures tomorrow evening and will be trying to get them up.

Off to Utah, and HttpUnit and JsUnit

Heading off to our satellite office in Provo, UT this morning. Was supposed to leave last night, but the rain in Atlanta pretty much solved that mystery, so it all got shifted around a day. Will be flying back to family arriving at the house, and as soon as they leave, I leave again for Asheville, for a music and worship conference. Busy, busy, busy.

But, it will give me a chance to take a closer look at HttpUnit and JsUnit. Both are part of the xUnit family, but are targetted at Html and Javascript. I had an interesting discussion on the TDD mailing list with a gentleman who believes that the right tool still isn't out there for regression testing of web pages, because he could have complex Javascript that a change to some baseline would cause something to fail 5 or 6 clicks in. He is also, I think, interacting with a website over which he has no control.

My position is that, as I showed in my Code Camp presentation, it is possible to put everything under test, and with that, you don't need some browser automation tool. All you need to do is run your tests, and that will tell you if it failed.

So, over the next week or so, I am going to work on a way to prove myself right (hopefully). I truly believe it is going to be a pain to do, but if I can get an entire interaction under test, including ASP.NET, HTML, and Javascript, it will be a lot closer to the tool he was looking for.

Of course, I also have to begin work on the J2ME pages for my current project at work. My goal there is also to develop a testing wrapper for those. Should be a little more interesting because of the limited memory space we have to work with on the phones. This limited memory means that I'll have to eventually factor performance into the whole thing. But, since Unit Testing is all about being able to refactor confidently, I'm looking forward to how it all comes out.