What's it all about, Alfie?

Today I needed to set up Tomcat for servlet development and aside from Tomcat itself, the biggest challenge was in getting the new web app set up properly. It wasn't that bad, really, it was just a lot of moving parts with no error messages to speak of to let you know you had the moving parts hooked up wrong. For instance, I made the silly mistake of having my web.xml file in the root of the /web directory in my project. It was supposed to be in the WEB-INF directory in that directory. Without it being in the right place, nothing was seeming to work. But there were no errors indicating my mistake.

While I can understand that this is a user error - I did eventually figure out my mistake, there's nothing to say "Hey, here's a web app with no web.xml file" which would have put me on the right track a lot sooner.

Once I got it all set up properly, things seemed to flow pretty nicely. I was able to get a lot of good work done, and by the end of the day I was very close to a working prototype. I'm guessing by the end of this week I should have the first good cut all done. That will be a great relief.

It's all in the configuration. Watch it.

One of my favorite apps - MarsEdit, has just been updated to 2.3 with Tumblr support, that I'm really not that hyped about, but others will be, and a much improved media manager when loading lots of pictures. Doesn't sound like much, but I know Daniel was working on it for a long time.

Glad to see the update.

I have been spending the last several days - let's call it a week, getting familiar with a guy's code. Now I'm not going to say it's bad, or good - it's different from what I'd have done in that it's over-designed like a Spring app might tend to be - certainly J2EE has nothing on this design pattern, but that's really not the issue. It's his code, and I was learning it in order to be able to support, maintain, and extend it. Things were going pretty well, I think, and then I started to get the inkling that this wasn't in his comfort zone.

So I asked him.

What came out and asked him about what he'd do. He's been a very nice guy, almost to a fault of not telling me what is going to take him out of his comfort zone on this project. His answer revealed what he was comfortable with - me not touching his code. Fair enough.

Hey, you have to face facts. I'm the new guy. I've been here for a grand total of two weeks and until I can produce something that's good, going on great, and it deploys around the firm, and runs like a top, there are going to be a lot of people that, rightly so, have doubts about me.

This guy is no different, and I don't blame him.

What I do wish he'd done was to be honest with me as opposed to nice. It would have saved us both a week. I can do what I need to do now by building something outside of his codebase that simply makes calls to his system and saves the results. It's not ideal, but it's possible. It's also going to be built in such a way that it can run alongside his code in a Tomcat instance so that should the time come to more closely integrate them, the first thing we can do is to put them side-by-side and then merge the codebases.

It's understandable that I'm the new guy and need to prove myself. I also appreciate this guy's kindness. I just wish he'd been a little more honest with himself, and me, and it would have saved us both a bunch of time.

Today I was able to finish up the first complete cut of my work on the Java classes for the Google Visualization API. For the last two days I've been hammering out a class structure that allows me to easily create tables of data that are then easily serialized to the Google widgets. This is a core component of the project I've been working on here since my arrival. With the incredible elegance of the Google Visualization widgets, it was a natural fit to make the data we have fit the API, and then be able to easily change the widgets on the front-end.

One of the nice things I added was a DatabaseTable that sub-classed the basic DataTable and created a constructor that takes a simple JDBC ResultSet and from that builds the DataTable for easy serialization. This will make it easy for me to make a servlet that will use the Google API to receive a GET message with a SQL statement in it, run that query, build a DatabaseTable from the results, and then serialize the data back out. Efficient and elegant. Nice.

Additionally, I wanted to complete the Google API with it's CSV and HTML output formats. These were pretty easy given that I'd already done the JSON version, but it's going to make it nice for debugging the code and checking on the data. They didn't take long, but it was worth the effort.

So it's looking like it's time to move into the Tomcat codebase. I need to put in the H2 in-memory database and then back-end it with MS SQL Server, and then put the servlets on the front end that I built this code for. Making progress. Lots and lots of progress.

I've been coding for a little over a day and have written a little over 3,000 lines of commented, debugged, unit-tested code. Wow! It's been a wild day. I can't remember the last time I was this productive. It feels incredibly tiring, but also exceptionally satisfying because it means that I'm starting to really produce here and in a few days I should be able to finish this all up, and start to look at using this code in the servlets to hook into the Google Visualization widgets.

Yup... it's a great feeling to be exhausted. Great.

This morning I noticed that VoodooPad Pro 4.1.1 is out with some nice changes for the iPhone sync capabilities. There's a few other things there, but it looks to be really focused on this aspect for the release. Good enough, I'm not syncing to an iPhone now, but good news for my friends that are.

Today I'm finally getting to be productive on the job. I've got all the pieces worked out in my head, and on paper, and it looks like the best way to go about putting together this intraday P/L tool is to take an existing P/L service and add an H2 in-memory database with triggers to save it all to a back-end MS SQL Server for persistence, and then use the Google Visualization API to present the data fetched from the H2 database for the client.

It's got a few, solid, working components, and while they probably haven't been used in just this way in the past, there should be very little concern that they are going to work in this instance. The only trick is that there isn't a Google Visualization API Data Source in Java. They have Python, PHP, and .NET, but not Java. OK, so I need to create the DataTable and supporting API in Java for the servlets to use. Not bad.

So I fire up BBEdit, create a git repo, and create the classes I need. Since the Shop is big into unit testing, I'm trying JUnit, which isn't bad, but it's nothing you can't do in isolation, and writing good tests is still a non-trivial task, and slows down coding significantly. However, it'll let everyone feel like I'm fitting in if I do all the tests like they would - or maybe even a little better.

Finally, I need to start to use ant as that's another big thing here. I like Makefiles, but the only real difference I see in ant is the name of the file (build.xml) and the format (XML). Other than that, it's targets and actions. Can't get much simpler than that.

So thankfully, I'm productive again - with git (yeah), JUnit and ant. Not bad for a day.

This morning I noticed that Coda 1.6.3 is out and I got the update which includes a lot of bug fixes. Among the many things are a raft of changes to SVN usage and how it interacts with SSL and the uploading process. Nice to see, as I've been reading about that in the Coda mailing list for a while. There also seems to be just a bunch of little things all cleaned up. It's turning out to be a sweet little tool. I'm glad to see it.

I think everyone that's looked at the Google Finance page knows the really nice time-series graph that Google puts up on that page to show price history with annotations. Well, today I spent some time checking to see if it would be possible to use that in some time series viewer we're making at the Shop. Turns out, there's an entire API and widget set built around the Google Visualization API. Amazing.

The API is really pretty simple, and they give you a few reference implementations as well as the exact results you need to return for a specific query. But in essence, it's a table of data and then it's up to the widget to take that DataTable and turn it into a nice looking visualization. They even make a toolkit to bridge these to Java - which is a big plus.

The test code is simple, easy to follow, and after a couple of hours of reading, it was very clear to me that this was going to be an ideal way to partition the data-generating back-end from the front-end visualization. Oh sure, I have more reading to do, and there's plenty of coding yet to do, but my goal is to put some kind of in-memory database, backed by a SQL database, in a Tomcat instance and then put this request/response on top of that and then slap the GUI widgets in a simple web page on top of that.

It's clean, simple, and most of all - beautiful. Let's face it... the visualizations they have already done are nothing short of stunning.

So I'm going to be going down a road that I haven't spent a lot of time on - Javascript and Google APIs. I think it's going to be an interesting ride.

I'm not a big peer-to-peer downloader, in fact, I think I've downloaded just two things - a couple of Eddie Izzard tracks that we owned the DVDs for, but I wanted just the soundtrack. But when I needed to get that, I got Acquisition, and it's done a fine job for the limited used I've had for it. Today, I saw that they have released v2.1, and it includes Sparkle support and a few design tweaks and connectivity improvements.

So if you need something like this, I can say it works, but can't say it's all that much better than the other things out there. I just haven't had the need to look around that much.