What's it all about, Alfie?

I've been on the Coda mailing lists for quite a while and have heard the rumblings about the possible death of the product. Nothing more than rumors. A small shop like Panic needs to pace what they are doing to make sure that they deliver a good product year after year. In contrast to popular belief in Corporate America, you can't expect to have a home run app (or release) every month on a tight budget. So we have had to wait.

Coda 1.5 is finally out, and it looks to have some significant improvements, and yet some significant omissions. Maybe these follow a certain usage pattern, and if so, then it's my usage of the tool that's abnormal. For instance, Coda 1.5 has built-in support for Subversion. Great. Why not CVS too? It's not that different. The core tools are on Mac OS X, so they don't have to worry about that. Still, it's nice that they have something in the way of source control, I only have to make a subversion server and migrate a repository to there, but that's a weekend.

Secondly, they add find/replace across multiple files (along with a significantly improved editor - don't know what that means for SubEthaEdit) which will help people fixing multiple links in a web system, but they have no facility for invoking a graphics editor like Photoshop, Acorn, etc. You can drag an image into a page, and it'll place the img tag there, but you can't shell out to a third-party graphics editor? Seems that would be an easy addition and then even if it's not "all in one", it's available for seamless workflow.

I like the tool. It's slick and polished. I don't have a great use for it at this time because I'm not maintaining a dozen websites daily. What I have used it for, I like, and will continue to try and fin things to work on with it. But even I can see the trade-offs they had to make on this release. It's showing more of how it's meant to be used, and what it's not meant to do.

Today I was face-to-face with a bug that's been giving me grief for quite a while and I would like to say that I've solved it, but I only think I might have solved it, and we'll have to wait for time to tell to see if I really have solved the problem.

The problem relates to my market data server and it's connections to my ticker plant. In theory, these connections are reliable - breaking and re-making connections as needed to make sure that the requests get through and serviced as quickly and efficiently as possible. But there seems to be an issue with my production box and it's connection to it's ticker plant.

Upon restart, everything is fine. But after a few days, the data returned from the server - provided by the plant, "flip-flops" from a valid value to zero and back again. It's most annoying, and very difficult to track down. It doesn't happen on my development box, and developing or testing in production is just way way too dangerous.

So I was thinking it might be these connections. So I told the server to drop all connections to the plant and create new. This had the same effect as a restart in that all the requests were good then. This leads me to believe it's not in the main server but in the satellite processes that talk to the ticker plant. Armed with this, I dug into that code to see if I could see anything.

What I saw, what I hoped to see, was that I was depending on the connection to the ticker plant to be 100% reliable. Why? Well... because it typically is. But why not just use the connection methods to see if the connection is valid? And if it's valid, why not send a simple ping to the server? If either of these fail, then drop the connection and create a new one. Seems far more reliable than simply assuming that the connection will take care of itself.

The overhead is minor and this is only done once per request from the server, so the overhead should be minor. What I think was happening was the flipping was when I was hitting different connections to the ticker plant and it was just the luck of the draw which one I got. Why some went bad and didn't heal themselves on the production box, I don't know. It doesn't happen on the dev box. Maybe there's something in the networking... I don't know. But I'm hoping that this change will make the server much more reliable.

We'll have to wait and see.

I got a visit from a developer who is using a shared Java library of mine - BKit, and two components of it, specifically: the BKTable and the expression parser - BKJEP, itself based on the JEP parser while it was Open Source and free. They have since closed the source on JEP and upgraded it's capabilities, but for what we need it is more than adequate, and I really don't want to get into a licensing situation with a group that started Open Source and then closed it down. They sound like they're on the brink of closing shop.

Anyway, the developer wanted to return a null value for the computed column. Originally, the idea of the computed column was to give the ability to the user of the BKTable a way to create a simple computed column without having to do it themselves. They could say "Give me a column called 'Area' that is 'width * height'" - where the columns called 'width' and 'height' were already defined in the table. When either 'width' or 'height' of any row in the table changed, the resulting 'Area' column was also updated. Nice, but not Rocket Science.

It got more complicated when they wanted to have Excel-like functions. Things like dateFormat() to turn a Date object into a String for comparison... isNull() to test if the value is null... and then if_then() to give it a simple conditional. And it's this last one that's opened the particular can of worms I'm dealing with right now.

When data is set in the expression, it's impossible to give it a true null value. The core JEP parser simply doesn't allow it. So we encoded the null to be a special String (__null__ if it matters, and it doesn't) so that it could be 'set' and 'get' from the expression. We also created the isNull() function so that you could test for it. So far so good. But what if the output of the if_then() is to be a null? Ah... there we have an issue.

There was no way to create a properly encoded null value within a JEP expression. This developer was the first to ask for it. There's a lot of good that could be done with this variable defined in all expressions... but there's a lot of danger as well.

Say the user snuck an expression past us that generated a true null value. Then used that value in the test: x == null... well... the value of 'x' would not have been encoded to the proper string constant and so it'd fail. So we have the problem that there are cases where something that should work - won't work. The easiest way to think about this is to just be careful and use the variable 'null' only when you have to. And test... test... test.

But with that, I think this adds more than it harms, so I added it in.

UPDATE: wow... that was a lot harder than I had originally thought. The first cut I had seemed to work, but it really didn't. I had assumed that within JEP the constants and the variables were kept apart as the first are immutable and the second aren't. But in fact, they are the same storage class. So... when I scanned through the variables in the BKTable's method, I still caught them and they didn't appear as column headers and so the expression was tossed out.

I had to change the way the BKTable's method worked. When I got a variable from the expression I had to check to see if it had a defined value. If it did, then it was a constant as only constants had defined values at this point in the processing of the expression. This skipping was essential to get the expressions not only passed in, but also properly evaluated. I ran all the tests on the table and they all came up OK. Whew! That was a lot more complex than I had originally thought.

I was looking at my pencil today and noticed that I had been using the same pencil - or copies of that original pencil, for more than 22 years. It's the Pentel Kerry pencil, and it's about as great a writing instrument as I've ever experienced.

I love the removable cap that protects the tip of the pencil so that it doesn't get bent, but can easily fit into a pocket where it might otherwise damage the garment - or get damaged by rough handling. The way in which the pencil can operate either without the cap on the back - or with it, shows incredible attention to the engineering of the instrument.

But the biggest thing is the balance. The weight is perfect, and while you can write without the cap on the back, the balance is really far better when you have it on the back. Then, it's a joy to use. Absolute joy. If you've ever tried a mechanical pencil and found them wanting in one regard or another, please, do yourself a favor and try this guy out. It's something I doubt you'll regret.

Oh... and mine are all in black. I have three on my desk right now. They are incredible.

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.

I haven't had a lot to do today on current projects as I'm waiting for others to get things lined up or deployed for me to do my stuff. So I've spent most of the day transferring the contents of my HTML journal at work to the WordPress weblog I've got there. I accomplished about 4 months of postings - quite a lot of work, actually. At this rate, I should be able to get all the entries into WordPress in another week.

But even making this nice progress is tiring. I'm really tired. Sitting still... hammering in changes. Trying to stay focused so as not to make mistakes... it's just plain tiring. But it's still good to see the "To Do" list shrink. My goal is still to get it all into WordPress - even if it takes longer than a week to finish.

Today is the first day of school for my kids. They are all excited - some more nervous than others. I can remember loving school and being really excited to go back in the Fall. It's a great time to be a kid. Sure, my new High Schooler is a little intimidated - as all changers are... but after a week he's going to love it! Have fun kids!

UPDATE: everyone had a great time. Joseph didn't get lost in the halls at the new High School... Marie loved being in 7^th grade and knowing the school like the back of her hand... and Angelina loved being the big 5^th grader and Traffic Guard. It was a banner first day!

It's not been a particularly great day... nothing really outstanding has happened at all. I'm keeping busy moving things from my old journal to the WordPress blog... I'm getting faster at it. It's pretty interesting when you make competitions with yourself to make the time pass more quickly. It's doubtful that anyone is going to say "Hey, this is great!" when I'm done, but it keeps me from sitting doing nothing.

Some days, it's just a matter of slugging through the day-to-day mud of a job. It's not glamorous, it's not even really interesting. It's just the job. Today is one of those days.

I'm taking off a little early because I'd like to have a nice long weekend. Nothing planned... just no need to be here, as evidenced by the fact that there's nothing really to do.

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.