This morning I saw that LaunchBar 5 had another small step towards "dot-O" with the release of Release Candidate 3. The release notes are a little sparse, which is good, possibly indicating that we're getting close to the final product.
I have to say, it's been rock solid for me, and I absolutely love the clipboard history. It's saved me a ton of time.
Today I spent a good bit of time planning out the changes I need to make in this one project I'm taking over. It's not the way I'd build it, but that's really beside the point... it is and I have to work with that. Plain and simple.
So I'm looking at why a strike for an option that should be 1.34 is really 1.34000003674 - I've run into this before in my previous job: rounding in the format change from string to float or double. It's just the way things are. So I needed to see how things were being converted and then see where I might be able to put in code to properly round to something like 1.0e-4, or something.
I found the data in the database was stored as a real, and that's not a good sign right off the bat, as I think that's going to be mapped into a Float by JDBC as opposed to the Double that might have prevented this. But the problems didn't end there. The code I found mapped the value to a String and then later, it was mapped to a Double and then used. By then, I'm not at all surprised that it had the extra digits. Too many conversions. Way too many.
But again, in order to minimize the impact to the code, it was smarter to look at where the options were being created and insert the rounding on the strike at that point. It's not what I'd have wanted to do, but again, I had something that was close to right, and so it wasn't really worth the risk of changing all the mapping and database code when the problem could be addressed very simply in the setter code of the new option:
public synchronized void setStrike(Double value) { _strike = Math.rint(value * 1.0e4)/1.0e4; }
with this, we'll get the strike rounded to the nearest 1/100th of a cent. Easy to do, and it'll wipe out all the "problem digits" that we're seeing.
But I wasn't done yet. There was more code that needed fixing on the strikes. There was a place in the code where they were trying to create the "short-hand name" of the option and it had the following code to display the strike:
double decimal = strike - Math.floor(strike); int strikeInt = new Double(strike).intValue(); ... if (decimal > 0.) shortName.append(strike); else shortName.append(strikeInt);
where the goal is to render the Double 1.5 as "1.5" and the Double 95.0 as "95". Basically, if there's no fractional part, then don't show the decimal point. Seems good, but this is a horrible way to do it. A far better way would be to say:
DecimalFormat fmt = new DecimalFormat("0.####"); ... shortName.append(fmt.format(strike));
where the formatter will properly round to four decimal places and also drop the entire decimal part if there isn't one to display.
Sure, the DecimalFormat isn't thread-safe, but I'm not expecting it to be. Make one, use it, drop it. They are meant to be very lightweight classes - which is why they aren't thread-safe. But in this case, they are perfect for the occasion.
Then I got into another problem that I needed to tackle and realized that I didn't see where the original author had made any allowances for the feature. I looked more and still found nothing. I then shot off an email as I dug even further. By the time I talked to him, I was convinced that he simply didn't have any modeling of this particular business rule in the code. It was all based on configuration files that duplicated these business relationships he didn't want to include.
I talked to him and he fessed up about not making any allowances for this because he thought it was wrong. I pointed out that all he did was to push it into static config files in the server, and he agreed.
Right or wrong, a business rule is a business rule. It's not about "correctness". It's about how the users think of things. If they choose to think of things as "colors" then model the colors - just as they think of them. Don't make the quality judgement on the way things are - just use them.
I had done this with his code - from the get-go, but he wasn't as accommodating of the users. I told him what I needed to do and why, and was very nice about the judgement, but in the end, we need to add in this concept as it's critical to being able to do several things that are globally important, even if they aren't important to him.
It's important to understand that there's a time to correct something because its wrong, and leaving it as-is is going to cause more problems in the future, and when it's time to let it flow over you and work with the imperfect system that you've been given.
I've been using the Google Visualization AnnotatedTimeLine for quite a while. It's a pretty nice tool, and it's got the backing of Google, for all that means. Good and Bad. This morning I was pointed to the Chronoscope web site where they seem to have built something on top of the GWT that can replace the AnnotatedTimeLine pretty much completely. It even has a 'compatibility' skin where it looks like the AnnotatedTimeLine (or so the docs say).
I'm always on the lookout for something that's better, faster, and cleaner than the stuff I'm using. This certainly has a lot of things to like. Right now, my biggest concern for the AnnotatedTimeLine is the fact that it 'flashes' on all updates. It's not fast but part of that is the fact that I have to give it the entire dataset at each update. It'd be great if the dataset was able to be augmented, and in doing that, it only redrew the parts that changed.
I'm not sure that Chronoscope is the answer. It's no faster than the AnnotatedTimeLine for similar dataset sizes, but it's something to keep and eye on. Maybe it'll post some specs on speed and size and give me more reason to investigate it further.
I noticed this morning that Hulu Desktop has been updated to 0.9.4 - no mention of the changes in this release, but there's no reason not to update. I did hear a rumor that Hulu is considering charging for video streams. It's certainly possible given the new desktop client, but it's not in keeping with the way Hulu started. It's already got adds - targeted adds, even. So why ask us to pay? Maybe to get rid of the ads, that's something that folks might pay for.
Who knows. We'll have to see how things unfold in the coming weeks and months.
They have updated Java again, once again, it's an across-the-board update:
Java for Mac OS X 10.5 Update 4 delivers improved reliability, security, and compatibility for Java SE 6, J2SE 5.0 and J2SE 1.4.2 on Mac OS X 10.5.7 and later.
This release updates Java SE 6 to version 1.6.0_13, J2SE 5.0 to version 1.5.0_19, and J2SE 1.4.2 to 1.4.2_21.
So we're at pretty up-to-date versions of Java for OS X. Not bad. It's no surprise that we're lagging behind the Sun JDKs - Apple has never really pushed the envelope on JDK releases. But it's nice to be up to date just in case.
Today has been a lot of clean-up and planning for the future today. I am at a brief pause in the development cycle, waiting for the Q/A Team to certify an application of mine so that I can then put it in production and reap the benefits of the fixes and features. While I was waiting for this, and helping them out when needed, I wanted to run through all my emails and make sure that I didn't have anything outstanding that needed to be done.
Turns out that I did - imagine that.
I needed to pull two pages into one by adding a single checkbox and a simple if-then construct to pick the right URL for the request. This would allow us to choose whether to hit the in-memory database of my app, or hit the back-end database. There are a few new webapps on the server, and this addition was really needed in order to be able to maintain the app under adverse conditions. Just makes sense to consolidate these into one.
There were a few other things I needed to do as well... nothing major, just cleaning up emails, sending out status emails, checking up on folks - organizational maintenance stuff. Got all that cleared out.
Then I spent a little bit of time planning for the next new feature for the app in Q/A. I needed to make sure I could see where to update for the new information, how to make sure it'd work regardless of the conditions. In short, it's not too hard. I'll be able to add in the data to the base elements, then the existing code will automatically aggregate across it, but the new code will be able to filter on it and come up with the exact data we need.
Pretty nice.
I did need to do a bit of explaining to the original author as he came up with a pretty decent idea that will make it easier to be sure that the old test cases and code will work with the new data. It was a little strained after I agreed with his idea and he still wanted to understand what it was that I proposed. We probably went around this a few times before he got it, and that's OK - just a little miscommunication.
In the end, it was a very productive day and lots of stuff got done. It just wasn't Wow! work, but necessary nonetheless.
Very odd thing is happening to me this afternoon - I'm trying to buy a simple iTunes email gift certificate for Nina against my PayPal account (my default funding source) and it keeps saying that the credit card is refused. Not really. I can buy a song, so that's OK, but if I try to get the $20 iTunes 'card', it fails. I've put in my information several times - no difference. Odd... very odd.
So I'm thinking it's something that's temporary on iTunes Store. Gotta be. PayPal is OK, saying I created the 'Pay agreement' with iTunes, but it's got to be the call from iTunes Store to PayPal that's causing the problem.
So I had to tell Nina that she's going to have to wait for a bit to let this issue settle out and then I can send her the money. Maybe this evening, maybe tomorrow. But I feel certain it's OK as I'm able to buy a song. Hmmm... very odd indeed.
UPDATE: I bought an album, upgraded a song to iTunes Plus, all that worked. But the gift certificate didn't. Wild. I'll have to wait and see how it plays out this evening.
In my previous job I had a TextEdit document that had all kinds of notes in it about the place, the applications, what to do when, how to do things, etc. It was a "How to" of all the things I had to do and needed to remember in the job. I also had a nice blog about all the things I did during the day, and the combination of these two made a really nice package to pass on to the people that remained. They didn't appreciate it, of course, but it was my choice not theirs.
This morning I was looking at the file I was creating after three months of being here, and decided that I didn't want to leave it in TextEdit as there wasn't anything special about that. No real linking, no multiple pages, etc. VoodooPad was the answer, and since I didn't have that much to move, it was pretty quick.
Even better that the formatting and styles followed the cut-n-paste, so it took me all of 5 minutes to make the index page and then make the page for the one page I had some information typed up for. Pretty simple.
Now when I fire up VoodooPad Pro on my laptop I'll get the basic Kitchen Sink doc of mine as well as the document for work. Nice. Should make it a lot simpler. Sweet.
I noticed this morning that Firefox 3.0.11 is out and from the release notes it looks like it's a security update with a single bookmark database fix. Well... at least it's progress.
I have to say, with Safari 4 out and Google Chrome on Mac OS X making progress, the update for Firefox 3.5 should hurry up or look to be significantly lagging behind. Hope to see it soon.
This is a picture of my team at the Shop - Jeff's the manager, Jean, Raj and I are the developers, and this is in the corner of the trading floor by a window overlooking Jackson street on the 8th floor of the Chicago Board of Trade.
I have to say, after three months, it's still a great job to have and it's a real pleasure to work with a bunch of nice people.