What's it all about, Alfie?

This morning I got a notice on the MacVim Google Groups that they cut Snapshot 34 and so I had to go get it and kick the tires. It's great that MacVim is available - and the updates they make to it are really amazing. Now there's a plug-in interface to be able to write add-ons without digging into the core code. Incredible. Not Vim macros... compiled plug-ins. Cool.

This is something that I love having and use it all the time.

This morning I checked for an update to Adium and found that 1.3.1 was out! Excellent! I got the update right away and as I read the release notes, there were a ton of fixes to the app. It's wonderful to see progress on something like Adium as I use it every single day and would be lost without it.

I know they are planning on putting in video conferencing as well, but I'm not connected to enough fat pipes during most of my day to take advantage of that. But I do love IM.

I read an interesting message on the MacVim mailing list this morning about the speed of opening new windows with the mvim command - a shell command that's included in the MacVim package. What the developer (the main maintainer) did was to time several ways of opening up the window and the sub-components of that process. What he found was that the fork() was about two-thirds of the time! Surely, there is a faster way to do this.

And there is... he even had an answer: don't fork on opening a new window from the command line. The change to the mvim script is pretty easy. Change the script from:

  if [ "$gui" ]; then
    # Note: this isn't perfect, because any error output goes to the
    # terminal instead of the console log.
    # But if you use open instead, you will need to fully qualify the
    # path names for any filenames you specify, which is hard.
    exec "$binary" -g $opts ${1:+"$@"}
  else
    exec "$binary" $opts ${1:+"$@"}
  fi 

to:

  if [ "$gui" ]; then
    # Note: this isn't perfect, because any error output goes to the
    # terminal instead of the console log.
    # But if you use open instead, you will need to fully qualify the
    # path names for any filenames you specify, which is hard.
    exec "$binary" -g -f $opts ${1:+"$@"} <&0 &
  else
    exec "$binary" $opts ${1:+"$@"}
  fi 

This takes the launch time from a little over a second on my MacBook Pro to less than half a sec. OK, sure... is this that important? No, of course not, but the change is not bad, either. Not forking is a good way to keep system load down. Doesn't hurt, and that it's faster is even better.

So... if you're using MacVim - think about updating the mvim script and try it. It's a good idea.

This morning v3.1.7 of NetNewsWire went 'final', and while it was the same as the last beta, it's now official, and so I certainly updated. There's one thing that's been interesting me about NetNewsWire - where does he go from here?

I mean it's free now, and NewsGator has decided that it can support that product, but where to go from here? Does he try to tack on new features like an entirely different viewing system? I read in his weblog that he likes to take away features to keep the application lean and on point. So I wonder really... where to go? My guess: Nowhere. It's done.

I was doing some work with MacVim yesterday and I was a little disappointed to see a bunch of little 'blips' on the window. I'm a stickler for clean and while I know they said the ATSUI renderer might have some strange artifacts, I didn't expect to see them. Once I did, I knew I had to go back to the default renderer.

Also, with my tests, the redraw speed on my MacBook Pro is virtually identical for the two renderers. So there's no real solid benefit to putting up with these artifacts. Also, CoreText is supposed to be the way to go, and Apple might just slap the default renderer on CoreText and let that be that. Who knows? Anyway... for now, it's back to the default renderer.

I was working way too fast yesterday and skipped over some obvious bugs in the parser that were related to the addition of the JEP and BKit constants to the mix. The first was that pulling back a null valued variable returned a String with the value "__null__" - our tag for the null variable. This isn't right. I had to put the same value-mapping on the getVarValue() method that I had on the output of the expression parser. With that, it was fixed.

The second one was that the addConstant() method wasn't properly mapping incoming null values to the null tag, which was a problem I was having yesterday and simply wrote it off to the super's method getting called. I should have known better, but I was in a big hurry to get this done for the developer. The problem was in the missing null mapping, and when I added that in properly, everything worked just like I had expected it to.

I'm glad I went back and scanned what I was doing to make sure it was all done. These little loose ends are annoying and erode your credibility with others. Don't be sloppy - even if you have to be fast, go back and make sure it's all cleaned up.

IMAP vs POP3 - classic debate these days. IMAP has 'push' email, POP3 doesn't. Pop3 is old, IMAP it new. GMail is using IMAP now... MobileMe is using IMAP... Everyone is using IMAP - or so they might have us all believe. So I looked into it this morning and decided that POP3 is really quite good enough for me.

First, I had to see if the email servers I hit supported IMAP. First, Google's GMail - Yup. Next, HostMonster - Yup. Lastly, Comcast - Nope. Shucks... we'll, 2 out of 3 isn't bad. I could still move those two to IMAP. And then I started looking at the security of IMAP - just to be safe.

See... I use POP3 and SMTP over SSL to all my mail servers. I simply do not want my mail snatched as I send or receive it. Sure, from server to server it's all in plaintext, but that's going to take a lot more effort on the part of the "snooper" to intercept a major ISP's email. Sure, they can do it, but it's harder. For the last several years, I've been using POP3/SMTP over SSL and have been very happy with it. Every mail server I've needed supports it... and it's just plain secure.

IMAP is plaintext. Period. I'm not a big fan of plaintext passwords and the logins to GMail and Comcast are the logins to my accounts there. So if they snoop it once, they are golden for those accounts. I don't like that.

So I'm going to stick with POP3/SMTP over SSL. It would have been nice, but it's just not something I'm willing to compromise on at this time. Security of my email comes first.

My favorite IM client - Adium, released version 1.3 this morning and I had to get it. The release notes indicate a ton of improvements, but there's enough bug fixes to make it worth the time to download the version.

They have made it a big deal to revamp the entire contact manager system in the app. Now you have much more control over your buddy list as well as being able to set different activity alerts (sounds, events, etc.) for each buddy's different actions. While I don't do that now, I can certainly see why that would be a very nice thing to have.

There's also now Facebook chat as well as new MSN chatting libraries to make that smoother than before. It's a heck of an upgrade, and if you haven't tried it, you really should. Highly recommended.

Today I was back-filling a lot of journal entries from my old HTML-based work journal to my WordPress work weblog and I noticed that there was a serious problem with the table representation. There was a hugs gap at the top of this one table, and on another the gap was smaller. I could not, for the life of me figure out what the problem was until I glanced at the page source one time and looked at the data in the table.

I'd been focusing on the CSS and classes and such, but when I looked at the table's data, I saw that there were TD tags and not td. This may seem very innocent, but I've learned from experience that WordPress does not like the upper-case tags, and will not even recognize them. What was happening was that WordPress was putting line breaks ('br' tags) at the end of each row, and somehow that was getting turned into the large gap at the top of the table.

When I went back and made all the TD tags td, the gaps at the top of the tables were exactly the same. Then I went into the CSS for the theme I was using and made classes for the header row, and even and odd rows so that I didn't have to remember the coloring of each row. This is going to make the tables all look the same and that's a lot nicer.

Also, I learned an interesting point. In a margin: statement, you can use negative values to "encroach" on someone's space. I used this to offset what I thought was an excessive buffer at the top of the table. Works like a charm now.

Because I have had some spare time today, I've been transferring some of the old journal entries from my work journal to a WordPress blog I created for just that purpose. The old system was a single, giant HTML page, and while it loaded quickly, and you could do searches of sorts, it wasn't as flexible as a WordPress system. Which is, of course, why I made the change.

Anyway, it's not all that bad if you get the data formatted reasonably well. Sure, it's tedious, and it's not something you'd do for fun, but if you want to move the entries into the system it sure beats re-typing all those pages. I'm close to getting 2008 into WordPress, but that still leaves 2006 and 2007, and that's a ton of entries.

Baby Steps... just keep taking baby steps.