What's it all about, Alfie?

Because I was out of communication on vacation for all of last week, I wanted to check my favorite apps to see if there had been any updates to them in my absence from the net. There had been, in fact - Skitch was updated and after the update I noticed a wonderful feature that I hadn't used up till now, but I'm sure to use it more and more in the coming days - it's the Window Snap.

Basically, when you do a constrained snap with Skitch if you just click on a window, it'll automatically select that window - with or without a shadow, on white, the desktop, or a transparent background and save it as your latest picture. You can then draw on it, save it, share it, all the regular Skitch stuff.

I've been looking for a simple 'window grab', and was looking at Flickr for pictures for the web site, but Skitch is just too good. I really like this app. Excellent stuff.

One of the really nice things I like about MarsEdit and WordPress is the ease with which you can put images into your posts. Sure, it's not rocket science, but there's writing the image tag and then there's point-and-click. I like the latter when there's a really nice interface. So I've been doing a little experimenting with the image options with MarsEdit.

There's the images that you upload to WordPress, and that's OK, but it has a limit on the upload of only a few kb. It's not horrible, but when I was trying to put up 20kb images it often times didn't work, and it's probably as much to do with the connectivity as anything else - but this is the connectivity I have, and if it's unreliable, then it really isn't a matter of why as much as it's a question of how to get the images up to the site?

Many months ago I read about Skitch, and watched the demo and thought Hey, this is sweet! and signed up for an invititation. After a few months, I got an invite and have been using it ever since. It's been a simple way to take iSight pictures and screen shots and get them up to a place where they can be saved and served.

Flickr is the same kind of service (so I thought) and so I was recently looking at the different Flickr clients - settling on 1001 as it seemed to be a nice small app that did what I needed and didn't make a big deal of itself. The wrinkle with Flickr was not Flickr - but MarsEdit. When you place an image into a post from Flickr you get a 'mini' version of the image and a link to the Flickr page where the image resides.

This is OK if you're really wanting to forward folks to Flickr, but if you want to just display images in your posts, this isn't the best thing because the way it's integrated in MarsEdit. However, if I put the screenshots up on Skitch then I have to go to the Skitch page to get the URL and then paste it into the post in MarsEdit. It's like I have to do the work up-front or force the readers to do it on their own.

Neither is ideal. So I posted a request to the MarsEdit forums about adding Skitch support. Ideally, I'd be able to put something on Skitch (like I can in Flickr) and then MarsEdit can preview those images and I can include the links easily - but as regular images and not links to pages with images.

Daniel wrote back about the future plans, and if he does the plug-in I think I'm going to have to write a Skitch one as this is just about the neatest little snap-n-share application and service I've ever used. If you haven't seen it, take a look.

I've spent the better part of this day trying to track down a nasty little bug in, what I think, is Windows XP IE/Firefox and the Sun JDK/JRE Applet plugin 1.6.0_06. Now I say trying because I thought I had it fenced in to a certain set of repeatable conditions, but when I went back to check them after about an hour of running other tests, they failed me and the problem vanished. Crud!

The problem seemed to be a combination of using WebStart and a specific application off WebStart, and other Java apps on my box, and a web page that uses two fat Java applets to display data. One is a table of data, the other a graph of the same data. When I went to the web page, after running the WebStart application, IE (and Firefox) would lock up. Totally locked up. Not good.

I dug into this and have come to the conclusion that it's a combination of running this app pn WebStart, possibly the applet JRE version, and certainly the loading order on the page(s) in IE. If I go to the 'problem' page first, I get trouble - keep all else the same and going to another page first means that I can safely go to the 'problem' page later. Very odd.

When I went to change the version of the JRE that IE uses in it's applet tags, I found it exceptionally hard - as opposed to something like Mac OS X has where there is a little app that controls the version of the JRE used for applets. It's these little things that really frost my cookies with Java and Windows.

Anyway, I'm spending my day not really accomplishing anything because of these large applets and IE issues. I understand that sometimes it's nice to have applets to have a limited interactive functionality, and applets are great for that. But when the applets get to the point where they are causing as much grief as this, then you've overextended the design goals of applets. They become apps and that's what WebStart is supposed to make easier to deploy.

UPDATE: after another hour or so of fiddling about, it turns out that if I use JDK 1.5.0_15 and that's all, then I'm OK. If I even install JDK 1.6.0, it's going to take over the applet duties for IE - no matter what the settings in IE say. This, then causes the problem and we get the lock-ups. If I didn't need JDK 1.6.0, I'd be OK, but we need to have Java WebStart, and the 1.6.0 version is what we're standardizing on there. This means that for now, we leave the users on 1.5.0_15 and when we have to update to 1.6.0 for the WebStart for the users, I'm sure hoping that we have a newer version than 1.6.0_06 - with a fix for this crummy problem.

I hate big Java applets. Make an application, for heavens sake! Or switch to something like AJAX, or live with the page refreshes! It's not meant to do this.

UPDATE: HA! I found a bug report at Sun where several people were complaining that they had applets that worked fine in 1.4 and 1.5, but with 1.6.0_06 they were having a lot of troubles - just like me! Sun's idea was to try 1.6.0_10 (beta) and see if that didn't fix the problem. So I downloaded the two-part JDK/JRE and BINGO! that fixed the problem. Guess Sun's had this quite a bit, and fixed it. Good enough. I still think we're pushing the limits on the applet design and we need to come up with a completely different client footprint design - AJAX and Javascript frameworks or a full-up client.

Yesterday afternoon I noticed a message from Adium saying that it could not connect to ICQ because the version of libpurple had expired. That's odd, I thought, and checked then for an update to Adium to see if I had missed something. Nope... no update. Since I don't get a lot of chats on ICQ, I figured that there was nothing to do, and I let it go.

This morning, Adium 1.2.6 was available with (surprise) an updated libpurple so ICQ is once again working. I got it and everything is fine.

What surprised me the most, I guess, was that an open source library would expire like that. Maybe it was the protocol at ICQ that required it, but it seems so counter to the open source ethos that it should expire. Very odd. But... I have to say, the Adium folks were on top of it quickly. Good enough.

This morning Acorn v1.2.1 was released with a lot of bug fixes and no real feature enhancements listed in the release notes. I hadn't noticed a lot of issues with it in my usage, but after reading the release notes, it was clear that there were some drawing/rendering and such issues that would have annoyed me, had I been using those features in my daily work.

Glad they fixed them, and got a new release out. Interesting aside, I noted on Twitter that Gus was doing the build of 1.2.1 as he was tweeting about it. A few hours later - Bingo! a new release. Twitter is the portent of new releases. Cool.

Also this morning, NetNewsWire v3.1.7b1 was released with the singular bug fix of working much better with Growl, which I use every day for all kinds of notifications. I hadn't noticed any real performance hit, but there must have been something significant going on or there would not have been the need for the fix (and update).

So... good enough. Polish on an already nice app - can't beat that.

I noticed today that my image of the Firefox app icon had a black pixel on the lower-righthand corner of the image. I pulled up Acorn and fixed it, and moved it to HostMonster, and it looks fine if I hit it directly from a web browser. I also copied it but in MarsEdit and removed the old thumbnail image to let MarsEdit re-create it, and still... in MarsEdit's Preview Pane, the old image remains. I'm stumped.

So I posted a message to the MarsEdit online forums and got this reply back from Daniel:

Hi Dr Bob - try deleting the MarsEdit cache folder that is creating by WebKit:

[Home] -> Library -> Caches -> com.red-sweater.marsedit

I'm not sure why some items are cached so aggressively even when they've changed.

So I tried that... still the old image remains. In fact, after stopping/starting MarsEdit a few times the directory is never created. This tells me that this is not only not the place the image is being held, it's not even used for what the author expected.

I'm at a bit of a loss to understand where the old image is being held. It's not on the web server, it's not in the cache I just deleted, it's not in the MarsEdit application support data... I'm stumped. And yet I'm sure it's still there. I can see it. Every Firefox post has this image and it's that way in the preview pane of all of them.

Bugger. I'm going to have to see if I can force MarsEdit to reload things. Or I'm going to have to find out where the image cache is really located and wipe that image out.

[1:15 pm] UPDATE: I've cleared the Safari cache, I've verified that the images on the web site are the correct ones, so it's a simple matter of my laptop thinking that the file hasn't changed, and therefore, not to reload it for MarsEdit. I've updated the post on the support forum to say what I've tried and what hasn't worked, and I guess I'm going to have to wait for another idea. Googling 'image cacheing WebKit "Mac OS X"' gives me nothing of real relevance, and too much noise. So I'm going to have to live with it until it thinks the image needs to be replaced.

[2:00 pm] UPDATE: Daniel suggested looking for a 'MarsEdit' directory in ~/Library/Caches/ and deleting that. There was one there as well - with lots of stuff in it, but removing it didn't effect a thing. Also, it was not recreated after several start/stop cycles. Very odd. I've updated the thread on the forum and we'll see what he comes back with.

[2:30 pm] UPDATE: I've removed the old Ranchero MarsEdit defaults, and while I didn't think they were doing anything, I didn't want to take the chance. Also, the icon database in ~/Library/Icons/WebpageIcons.db didn't hold the key either. I removed that, restarted MarsEdit, and still no difference. Wherever these images are, they are pretty well hidden. I looked at the defaults for the app and say nothing that would point to a different directory. It's a real stumper, I'd say. I think I'm giving up for now. I'm just running out of ideas.

[4:30 pm] UPDATE: it turned out that if I reloaded the page in the Preview pane, the same bad image came back. But if I reloaded it again then on the second reload, the right image was there. So, lesson learned - reload a few times to make sure you get the very latest.

[6/26 3:43am] UPDATE: it turns out from this article that in 10.5.2 Apple changed the location of the WebKit cache from ~/Library/Caches to /var/folders - not for any reason of security but simply performance - the home directory could be on a network drive but /var is on the machine itself. So, to clear the cache, you have to clear out /var/folders. Unfortunately, it's not easy to find the cache entries, and you have to really search (ala find) to find the ones you're looking for. FOr this case, it's:

  pushd /var/folders
  find . -name \*marsedit\*

and you'll find the directory you're looking for. Delete that, and the cache is gone.

Yesterday, I got a tweet from 'MarsEdit' saying that 2.1.4 was released, but it was too late in the day for me to have the time to download it and see what's what... so this morning that's the first thing I wanted to do.

The changes really don't seem to effect me much as they are for Blogger and a few things to do with drag-n-drop in the preview window. Not bad, and I'm sure there were a ton of people clamoring for these changes, but I'm still looking forward to the time when I can resize the main Edit Post window smaller than it's current default. Also, an improved media library window would be nice - things like the size of the icons... organizational features like folders, etc. All these would be nice, but it's not essential.

Anyway, it works, and it's nice to stay up to date even if you don't need the updates right away.

I've been working pretty feverishly the last several days on getting my market data server updated with a new API from one of my data vendors. It's been a significant update because of the fact that in this new API they have implemented (and forced us to enforce) login validation and data permissioning. I don't begrudge them the validation and permissioning because it's their bread-and-butter, and it's up to us to decide if it's too much to deal with, but it's the way in which they are doing it that's a real pain.

Based on experience, exchanges charge fees to see their data. Seems reasonable. But they don't really care if you see 1 instrument's price 1000 times in a day, or 1000 instrument's price 1 times a day - or even if you only see 1 instrument's price 1 time a day - it's still the same price. So the permissioning for standard exchange fee-liability is by exchange. Very reasonable.

Given this, we should be able to have a list of valid exchanges for an individual user and then check each instrument for it's exchange and be done. It would mean that we'd have on the order of a few dozen exchanges per user - a very manageable set. But this vendor isn't like that - they want to be able to know exactly what instruments you're asking for, so you have to permission the data at the instrument level. This, too, isn't horrible, but it does mean that instead of having a few dozen things to track for a user, you now have upwards of a few hundred or more. It's still possible, just a lot more work to do with each request.

Then there's the way they do the permissioining... a user has a list of entitlements, and each instrument has a list of entitlements and we need to find a common entitlement between them for the user to see the instrument's data. Why not have a single ID for a user - or an instrument? Why have lists? I'm sure you can have the degenerative case of one item in a list, but from the looks of things, that's not the way it's going. Just really odd. Not impossible to work with, but odd.

So it feels good to be out from under that weight. It's all working, and we'll be able to move to the verification phase with the vendor (certainly understandable) and then on to the roll-out to production.

This morning I noticed that Fantastico at HostMonster had gotten the update of WordPress to 2.5.1 - so I took the time to upgrade. It's pretty simple, and I keep the roll-back instructions in VoodooPad Pro (just in case), but I doubt I'll ever need them. I'm pretty sure the 2.5.1 upgrade is for security issues, and there aren't a lot of additional features in this guy, but it's always nice to stay current with these things - just in case someone decides to create a 10 million machine bot storm to crack all WordPress sites.

I'm still looking forward to the Google Summer of Code work for putting a caching system into WordPress. While I don't get enough page hits to really need a cache, you never know when you might be Slashdotted, and for that, a cache can be a lifesaver.

Today has been a very heads down coding day where I've spent almost all day getting the new features of the Vendor's new API working in the server and clients of my market data server. I was originally going to have the client-side code handle the authentication as I've done that in the past with pretty good success. But I know that this vendor is not really big into speed on his responses, so I was hoping to be able to build this all on the server-side and then cache the positive results for a day so that subsequent requests for the authentication would not hit the vendor's back-end systems all day long.

I was happy to see that they had what I needed - even if it took a little poking and prodding to get it to work, and know what data I needed to pass to it. In the end, I was able to incorporate it as a regular server-side feature which is going to make the cache a very welcome addition. Not the least of which is that we no longer are limited to their client-side code and response times.

With all this put into the market data server, I'll start tomorrow on the authorization - or the exchange-based filtering of the data. Again, I'm hoping to find it in the server, and I have a few leads to chase down before I'm sure, one way or the other, that I can or can't do it. It sure would be nice, though.