What's it all about, Alfie?

I know I shouldn't be surprised to see technology enter the medical profession, but with a sister that's a doctor, and her husband, and three roommates from college that are dentists, and after working with optometrists and doctors with their office automation, I have to say that I was honestly surprised to see that our local hospital, Edwards in Naperville, doesn't have xrays on film anymore. Well... maybe they do, but when you go to get a copy of them, you don't get films, you get a CD. "Hey!" I thought... "technology!".

Then I tried to read them on my Mac only to find out that they are a special file format: DICOM - Digital Imaging and Communications in Medicine. This format is not universally understood by apps like GraphicConverter or the like, but I was able to find that ImageJ could read the uncompressed DICOM files - which is nice because my wife's hand xrays came as uncompressed DICOM, but when I tried to load my son's rib xrays it said that it wasn't able to read compressed DICOM files. Crud.

I did a lot more googling and then came across OsiriX. What an amazing piece of open source software. This even has awards from Apple for it's excellent design - and tutorials on the Apple web site about how to use it. This is better than many large commercial outfits and yet it's totally free.

Let me give you a quick run-down of the application. First, it's Universal, and my guess is that they'll update it to Leopard to get the 64-bit processing on the Intel hardware as I believe it's capable of being 64-bit on G5 hardware. Second, it's got a built-in database that's smart enough to allow you to run it in a 'cache-only' mode (more on this later), but also capable of loading up xray series off CDs and keeping them on disk for later viewing. Thirdly, it's got automatic update checking, 'metal' theme (soon to change with Leopard), and responds very quickly to all user requests. It's a top notch Mac app.

One of the first things that made me say Wow! was the fact that on the toolbar there's an icon for importing a complete CD of xrays:

I hit that, and whoosh! everything from the CD is available in the app! I was stunned. I've been trying to get these xrays viewable for about 3 months, and all I had to do was to get this one program for my Mac, and click a button and everything is there - all the fields populated with when/where/why, etc. That's an amazing piece of coding!

But it didn't end there... oh no...

The default behavior is to have the application remove the entries from the database as soon as the CD is unmounted. This makes sense if a doctor is using it - there's no need to keep the images around if the disk is out of the drive. But for me, I want to keep the images around so I don't have to have the disk with me to look at the xrays. In order to do this you need to go into the Preferences for OsiriX and go to the 'Database' pane and select Copy files to OsiriX Data folder if: and then select If files are on a CD/DVD. This will mean that all the files will be copied from CDs. But we're not through yet... Next, go to the 'CD/DVD' pane and uncheck the option: Automatically remove images from the database when CD/DVD unmounted. This will then make sure that the images remain in the database once you remove the CD.

With this, I can carry around all the xrays of my family's accidents. I know it may sound a bit grizzly to some, but it's one of those things that makes me feel more connected to them.

I've been working with SubEthaEdit a lot in the last few days, and also with BBEdit, trying to get the few features that I don't like fixed/cleared up, and while I really like both of these editors for their unique approach to the problem of a developer's editor, there is a lot to be said for Vim. I have done more coding in Vim than probably any other editor in my life. I've used it on so many systems it's amazing, and I've never had to compile it myself. There seems to be someone who's already figured out how to get it to work on every platform I've needed. The community support is really amazing.

I have been using the Vim package from macvim.org, and it's currently at 7.0.224 for Mac OS 10.4 (Tiger). I am able to use all the nice fonts, syntax highlighting, everything that I expect in Vim, just on my Mac. The only problem is that it's stuck in Vim's view of the world. That means you can't have multiple windows open on the same application instance. On Unix this isn't an issue because you typically start a Vim session from the command line, but on Mac OS X, it's a limitation that I find... well... annoying, and it makes me not use it as much as I might.

There are also several things that the other two do that are very nice that Vim misses out on. It's not horrible, but when given the choice, I really end up using SubEthaEdit and BBEdit more on my Mac than I do Vim. But it's close. Many of the requests I have in to the SubEthaEdit developers and BBEdit developers are things in Vim that I wish they'd do - or do better.

Still... I can't complain. Vim has been very very good to me and I hope they come out with a Leopard release (Mac OS 10.5) very soon so I can upgrade my laptop to it and keep Vim with me.

OK, I'm trying to be fair and even-handed about this, but this morning I got another gotcha from Java (1.6.0_02) and IE (6) and Firefox (2.0.0.7). It's this thin client development that is 90% of what's needed but when you hit that 10% it's a pain in the rear to try and get around it. This morning I spent several hours doing just that.

The problem came up because one of my servers uses a web client to maintain it's internal data. This is nice in that the previous 'editor' was a Java application and it was a lot heavier than the support staff needed to have. Plus, with the web delivery, it was easier to have these folks support the server from London and home. But there's always a cost.

One of the things I did a while back was to have the users able to edit start-of-day (SOD) positions for the instruments in the master file. In order to do this in a reasonably useful way, it meant that I had to have a Java applet. This was not the first Java applet on the editor, and I knew that there would be IE/Firefox issues and how to get around them to make sure that the applet launched, etc. Nothing new there. What was new was the fact that I needed to send back data when the user hit 'Save'. I'd probably have been happy enough with Java applets if I hadn't had to do that. But I did.

Moreover, I had to send these updates through CGI scripts where the old and new data were arguments to the GET request. Not terribly hard, but when you find that IE still allows JDK 1.6.0_02 to send URLs to a server and get back answers, and Firefox doesn't, then we get into the lovely realm of applet signing.

It's not that terribly hard, but I didn't want to get a certificate that would mean the users would have to manually accept, so I went on a search for the location of the certificate that the web developers have built to enable them to sign their applets. This way, I know the certificate is allowed on all the boxes, and I don't have to worry about that.

Easier said than done, and honestly, it wasn't Java's fault. But the idea that in these days of corporate intranets and apps deployed on them, it would seem reasonable to have the security system say "Hey, if it's on this domain, it's OK". I know that's not necessarily safe, but coupled with the fact that there's security in the assignment of IP addresses and the domain naming, it's very unlikely that someone is going to put a box on the net with the right IP and domain to publish fake jars. Could happen, but it's not likely.

So I had to sign the applet. Interestingly enough, Googling this revealed that it wasn't until a recent release of 1.6.0 that this difference in behavior between IE and Firefox came to light. Previously, the behavior of IE and Firefox was the same in that it'd allow the URL connections from the applet to a machine not hosting the applet. So this might change again in the future. Yum...

The next problem was NFS... and it's likely a linux problem, or a difference in the NFS system we have in the Shop, but it turns out that if you copy a file from one machine to a shared filesystem, there's about a 70% chance that the web server will think this is a corrupted file. So, after seeing that the ClassNotFound exception was on the Java console, I went to the web server and copied the file to the same shared location. This finally worked.

After all this, things started to click and I got all the issues worked out.

Now I know that Java isn't perfect, and it's a lot better than ActiveX, which came before it, and I'll even say that it's a alot easier to deal with than AJAX, but I keep thinking that there has to be a better way. I know that AJAX is making strides, but it's not really a revolution, more an evolution. I'm wondering where's the revolution in thin clients? Where's the easier system of making clients deployable easily and run cleanly. I've seen Java WebStart and its a lot like Marimba - you download the app and run it. Yeah, it makes deployment easier, but it's no different than fat clients.

Throwing together a Java RMI server would be possible, have the applet connect in and send the updates - that'd get rid of the CGI scripts, but it's not going to make the security issues with Java any more manageable. Make it easier to write powerful apps that are easily deployed remotely. Tons of OSs have done it - X, NeXTSTEP, even VNC does this. But these are for something large, like a desktop or a big app. I'm thinking small - like most applet work. That would be nice to find.

When my daughter wanted to have her web site include Flash-based form submission software I needed to make sure that PHP on frosty, my iMac running OS X 10.3, would be able to email out properly. As I found out, 10.3 is not set up to allow this, but it's easy enough to configure once you know how. I Googled the problem and found most of the answer, but there was one line missing and that turned out to be a critical line for the forwarding of emails while in a PHP script. The low-down is that you just need to properly configure postfix on the box, as it's already installed and most of the work is already done for you. So here goes:

First, look at /etc/hostconfig and make sure that there is a line that reads:

  MAILSERVER=-AUTOMATIC-

Next, you need to edit the file /etc/postfix/main.cf and make sure it has the following lines:

  ...
  myhostname = frosty.themanfromspud.com
  ...
  mydomain = themanfromspud.com
  ...
  myorigin = $mydomain
  ...
  inet_interfaces = all
  ...
  mydestination = $myhostname, localhost.$mydomain
  ...
  mynetworks_style = subnet
  ...
  relayhost = smtp.comcast.net
  ...

and then you need to uncomment the line in the file /etc/postfix/master.cf to look like:

  smtp     inet  n    -    n    -    -    smtpd

At this point, if you restart your box, the email will send out from the host to any email address on the net. This is also very helpful in that my crontabs are now able to send me email off the box and this makes it a lot easier to keep track of them.

I've done this on Mac OS X 10.3 and 10.4 and it works great on both. I just wanted to write this into the journal before I forgot how to do it in the event that I need to do it again.

I've been running Growl for a while now on several of my Mac laptops (PowerBooks then MacBook Pro). It's a beautiful little service that I have always thought would have great uses, but it was going to take developers to get on board with it to make use of it. There was no way to put the hooks in after the fact. Thankfully, it seems that Growl has achieved a critical mass and is looking to be a 'necessary feature' in a lot of the better Mac software these days.

About the only apps I use that don't support it are the Apple apps (Mail, Safari, Xcode) and the apps where it makes no sense to support it (Acorn, BBEdit, etc.). I'm not sure that there will ever be support for it from Apple, it seems to put a reliance - allbeit a weak one, on the Apple apps. But certainly they should consider it for Xcode and other things that could really use the notification capabilities.

Recently, the Growl developers released 1.1 and then 1.1.1 of Growl and I have been a faithful updater. I didn't get into a lot of the problems that the changes in these version addressed, but I can imagine that I might have if I were using just a few more Growl-enabled apps. Growl, like Sparkle, is one of those things that were I to make an app for Mac OS X, I'd certainly put in the support for it. There's just no reason not to - it's just too neat.

Ever since I found Marc Liyanage's page for Mac OS X builds of PHP and PostgreSQL, I try to stay reasonably current on my laptop and my iMac back at home. I want to keep them in sync because often I'm coding up something on my laptop to test out at home, or I need to run something at home because it has continuous access to the internet while I may be moving around with my laptop.

Anyway, today I saw that he'd updated both recently, and so I decided to upgrade them both. I really love that he's gone to all the trouble to make this as painless as possible. It makes me want to start work on Xconq again - just so people can have a decent OS X Universal Build that they can run with. The problem has always been that when I asked folks about it no one knew exactly how to build it as the last Mac builder as left the scene and didn't leave build instructions. So it'd be a challenge. Still... it'd be nice to be able to give something back.

So now I'm at PHP 5.2.4 and PostgreSQL 8.2.4. All in all, a wonderful couple of upgrades.

This morning I was spending a little time trying to get a few more images uploaded to my WordPress weblog - one for Coding and another for Cube Life. I had picked out some nice images from Xcode and the web, and the Xcode one uploaded as nice as can be. But then the trouble started.

Try as I might, I could not get this one image uploaded. It was about a 50kb JPEG image and I tried it several times. No good. So I tried a little more compression to bring it down to about 25kb, and still no good. So I tried PNG - both 50kb in size and 25kb in size. No good. So I decided to look at the XML-RPC logs of MarsEdit. No help there.

Finally, I logged onto HostMonster and saw that the smaller PNG image actually got uploaded and the thumbnail image was created. Hmmm... I know that the images are also stored in a plist for MarsEdit and an image directory, but when I went to add it manually, it looked a lot more complex than a simple edit session, and I was afraid of messing things up. So I tried a few more things, and then finally emailed everything to Daniel at Red Sweater Software.

I wanted to send him the image and the RPC log from MarsEdit so that he could see what was happening. Maybe there's something happening that I didn't see, or something in the way the file is being encoded. Don't know. Interestingly, on the test case, the image made it up to WordPress, so I think I'm going to try and edit the plist to see if I can force it into the system.

UPDATE: this was an interesting puzzle to crack, and in the end I don't know that I've cracked it as much as I know what works and what doesn't. So, here's what I found out:

• Use Photoshop's Save to Web for maximum compression - this may be extremely obvious, but I tried using GraphicConverter and it wasn't a lot of help, and I tried saving it to different formats, but in the end, it was Photoshop that told me what I needed to be saving it as, and it showed me side-by-side images to allow me to choose what to do. That's the important first step: get the image size down to as small as possible.
• Somehow, get the Image to WordPress - this was interesting because in some cases, the failed upload from MarsEdit did actually get the image up to WordPress. Sometimes it didn't. I had greater success with smaller GIF files than PNG or JPEG files that were a little bigger. I'm guessing you can upload images from the WordPress Dashboard, but I haven't figured that out, and MarsEdit was good enough.
• If you have to replace an image - delete and then add - this is most easily done by deleting the images in the MarsEdit directory, and removing the entry in the plist, and then going to WordPress' Dashboard and deleting the image there. Then add it back in. This way, you get the thumbnails made by both programs.
• When adding an image to MarsEdit omit the thumbnail - MarsEdit will create the thumbnail if you just place the image in the MarsEdit directory, create a new plist entry with the right values and omit the thumbnail image and plist entry.

With these tips, I was able to remove images from both locations, replace images, and in general, get around these uploading problems that I've been having. When I was exchanging emails with Daniel on this issue he was surprised about this behavior and wanted me to send him more files that I run across that have this same problem.

This afternoon I was doing a little work in Coda and wanted to try the SSH Terminal access built into it. I checked my login password and tried. No good - invalid password. Now I should have known what the problem was, but I was not thinking about how SSH authenticates if you have key files on the remote end, I was thinking "login, password" - easy. Well... not really.

I tried a few more times, convinced that I had forgotten my password - something I've never done - but this was telling me that there's a first time for everything. I was sure I had it right, but the login failures were telling me that I was wrong. Also, the fact that I use ssh-agent and key files makes it so that I didn't need to login after getting the key files over. So now I was getting desperate.

I started writing a ticket to the HostMonster support and then thought - Hey... why not get to another machine without ssh-agent running and then try to ssh into the box? Of course, when I did this, it asked me for my pass-phrase, and I typed it in. Then I thought: I wonder if it's using the pass-phrase as the password? Bingo.

I had been thinking that the SSH protocol passed the real password even if the key files existed, but it doesn't. If the key files are there, it doesn't care about the password - it cares only about the pass-phrase in the key files. When I went back and tried that in Coda it worked like a champ.

I was so convinced that I had forgotten my password, but I hadn't - I had forgotten how SSH works in the presence of key files. Wow... glad that's cleared up. I won't forget it.

Here's what I'd love to see: a JVM plugin for Apache, like PHP, for combined Java/HTML/PHP/etc. Think about it - this is what I don't like about using Java on a web server - you have to use Tomcat (or something like it) and then you have to set up the project with the directory structure, build it, restart it or tell it to reload itself. It's a mess. What would be better? I'll tell you, what.

Look at PHP. Not as a language but it's integration with Apache. You can place PHP files in any directory in the web server. Any directory. You can put the static HTML next to PHP - or even both in the same file. Imagine the same with Java. Wouldn't that be nice? There's the Bean Shell for the same kind of thing for CLI environments, but nothing for web pages.

There are J2EE/JBoss fans that will say how easy it is to make a simple web site with JBoss, etc. But I have to laugh at them. Make something like the JSP pages but with the CLASSPATH specified in some config file or as an option in the tag that starts the Java code section of the page. Then you can simply Page.out.println() the HTML you want. Sure, it's not the same as Tapestry, but a lot of the time I don't the complete MVC for a web page. Many times what I want is a simple (and I mean simple) web page that accesses a service/server from within Java. Simply make a connection to a server, get the data, and make a page of it and then quit. Nothing complex. But it's Java.

It's interesting that PHP has the classes, the add-ins, the connections to databases, etc. It's got all that you'd need for simple (and maybe not-so-simple) pages. But you can drop the pages anywhere you want and you can edit and view immediately. No need to rebuild, restart, etc. I wish there was something for Java like PHP.

I don't want to re-write a different version of the Java classes into PHP just for a few simple pages. I can make that happen a lot of different ways - calling out to a Java app is one simple way to do it. Likewise, I don't want to set up a Tomcat/Tapestry instance just to vend a few pages. That's the key - just a few simple pages. No major web app. Just a few pages.

One of the things that I've wished I had was a good version of SSHKeychain. The problem with the 0.7.1 version (aside from being PPC-only) was that it didn't allow for X11Forwarding and I use that a lot on the connections to my unix boxes. Interestingly enough, it's not just the graphical apps - Vim checks to see if you have X11Forwarding on and if not, then it complains a bit. A hassle, yes, but so easy to include when you can configure your ~/.ssh/config file to suite your needs and hosts.

So I got the 0.8.1 version and I sent off the question about the X11Forwarding to the author to see if it's there now, or if not, can it be? I'm guessing that it's likely that since he doesn't use it, it's not in there. But maybe he'll take my suggestion and put it in there. If that were the case, then I'd gladly drop my scripts to start ssh-agent and stop messing with that. It's a hassle and I'm worried that Leopard will break it again. Hard to tell. But it's great that he's back at the coding on SSHKeychain... maybe I'll get what I need yet.

UPDATE: I read this off Daring Fireball this morning about SSHKeychain. Seems there's a new developer on the project and he's a little more security conscious and the setuid on the tunnel app and the way the SSH pass phrase is stored in the KeyChain is not very secure at this time. He's hoping to change that, and the work-arounds are reasonable for the tunneling - which I don't do, but the suggestion for the pass phrase is to not put it in the KeyChain - which defeats the purpose of the app, in my opinion. There's still the outstanding issue of the missing X11Forwarding which I need to have. He sounds like he's going to get to these things, but it'll be a few releases before I can stop using ssh-agent.