What's it all about, Alfie?

Last night, I had a mix-up with my daughter's basketball practice schedule - I was sent to the wrong school by my wife. I realized that I needed to put the schedule into iCal, and once there, there should be no reason I couldn't publish it and let her have a look. Even if she didn't, there was value for me in learning how to publish iCal calendars.

I knew the publishing is over WebDAV, and so I started looking for public WebDAV servers that would host this content for me. I have been disappointed that HostMonster doesn't have WebDAV support - but I decided to send them an email this morning just in case they may have recently added it.

[UPDATE: no they do not have any plans to support it.]

I also looked at a site called Box that said it was WebDAV, but I think that's been pulled and it's a less-general web-based file sharing system now. Shucks.

I ended up seeing iCal Exchange a lot, and it turns out that's an incredibly easy way to do it. They have public and private calendars, and it's got adds if you look at the calendars online, but it just works if you don't.

I ended up getting an account, and then publishing the calendar from within iCal to the base URL of: http://icalx.com/public/drbobbeaty/ - this, they tell you right on your account page at iCal Exchange. Very slick.

Once it's published, you can subscribe to the calendars by using the URL: webcal://icalx.com/public/drbobbeaty/nameOfCalendar.ics - it's pretty much idiot-proof. You can even make it a link on a page so that people don't need to know how to type the URL. That's not anything new about URLs, but it's a nice thing about the integration of iCal into Mac OS X.

So I ended up publishing the calendars for our volleyball team, the Rampage and Angelina's basketball team, the Comets. If I update the calendar in my iCal, it pushes these changes to the server, and each subscribed iCal picks it up. Sweet.

This morning I happened to try Transmit to get to a WebDAV server I was looking at, and I noticed that an update was out. This update fixes a few things with improving performance and the ability to deal with large files on Amazon's S3 storage. Also improved performance on a few things. Not bad.

I have to admit, it's not my favorite FTP Client, but it's very good.

I got a call from a recruiter the other day telling me about a position that was open in a smaller prop (proprietary) trading firm here in the city. This place is small. Less than 20 people in all of IT, and less than a third of that developers. That's small.

But it's bigger than Port-to-Port, my old place. Maybe it's time to head back down to the smaller shops? It got me to thinking.

Certainly the big downsides of a smaller shop would be the job security and the pay. Chances are, they are not going to pay as well, and they have a far greater risk of folding than a multi-national bank with 65,000 employees. But there are a lot of upside there too.

If I got along with the folks (a requirement, to be sure), then the place would be far more accommodating about change. Maybe they'd be willing to look at different platforms, or at least more willing to look at different ideas and ways of doing things. I'm no fool... there's politics everywhere, and coming into a small shop means you have to make sure you like the people there, because that's simply all the people there are. No way to walk to another floor and chat with an old friend - the place doesn't take up two floors.

But if you get along with the people, you are more closely tied to the things that happening in the shop. Decisions about platform and process are going to be a lot more out in the open, and because of the small size, there's going to be less tolerance for the "process as a work product" as opposed to just getting things done. Given the last 8 months here, that is a very attractive possibility.

But in the end, I don't have to move. It might be nice, and if something really stupendous comes along, then great. But if not, that's OK too. I'm not in a horrible place, and I believe I'll know if it's the right time and right opportunity to take.

The BKBaseGraphApplet can read the data it uses to put on the graphs from the applet PARAM tags a row at a time... or a complete table... or even as a part of the supportData table. This guy was meant for data that didn't make sense to put into the main data table, but was needed to support the proper graphing of the data.

Think colors of scatter points... mouse-over labels... that kind of stuff. More "style data" and not as much "numeric data". But today I realized that the parsing of the supportData and the augmenting of it to the primary data was not working properly.

I had made changes to allow the parsing of a complete table of data, in addition to the row-at-a-time method. But when I did that, I didn't follow-through with all the implications. For instance, the way the code was originally written, it was possible to leave out the primary data table completely, and then pull in parts of the supportData table as the "plotting" (aka primary) data.

In fact, it was possible to augment that as well. Very flexible, and nice, but by putting in the table parsing of the primary source, I broke it. (Well, to be brutally honest, another developer had a crack at it and I just cleaned up what he had written) So... I needed to go back in and clean it all up. Restore all the functionality I had intended to put in there.

The first step was to realize that the easiest way to resolve this was not to have the semi-merge code in the applet... Nope, that's a waste. I have the BKTable's merge() method, all I really needed to do was to put a filter on the supportData table - letting through only the columns the user wanted to merge into the primary data table, and then do the merge(). It was far simpler, and removed a ton of code from the BKBaseGraphApplet's class that was strikingly similar to the BKTable's code, and it was implemented better in the table's class.

Then I had to make sure that all different possibilities worked. No table, some table, etc. This way I could be sure that it was going to work.

In the end, it worked like a charm. The mouse-over is coming from the supportData table, and it's merging in the data exactly as it should. Perfect.

Today I had my first outage at HostMonster, my hosting service. That's pretty impressive. More than a year and a half and no significant problems. This morning I couldn't post an article to my weblog and saw that the MySQL database server was down. Pretty easy to see.

I sent in a trouble ticket, and with the hour things are back up. I have to say, for the price I pay (which is not a lot) this is fantastic service. Sure, it's not a lot to them, but it's their business, and something I don't have to worry about. I have enough of those things.

So kudos to HostMonster. Not for being perfect, but for being really good.

[12/11] UPDATE: the tech support response from HostMonster said that if MySQL went down, it would repair itself and come back up. Seems reasonable to have it restart. Good enough.

I have listened to a lot of people say that multi-threaded programming is dangerous, and can be avoided with careful planning. I can see their argument: a properly created finite-state machine with sufficiently small processing chunks can appear to be processing many things at once on a single thread, but that's an illusion. A bad one at that.

First, the effort to write good multi-threaded code is simpler than making the equivalent finite-state machine code. I know, I've done both. You can do the finite-state machine, and it's great on old hardware, or single-core machines, but it's not necessary. Most machines now are multi-core, and getting more and more with each generation. No. You need to know how to write multi-threaded code in today's high performance systems. No two ways about it.

Second, there are times when the overhead of 'polling' in the finite-state machine construct overwhelms the processing that really needs to get done. There's a reason we went to interrupt-driven I/O over polled I/O - one is much more efficient than the other - but harder to code. Suck it up, Boys! Code like you're worth the money they are paying you! Write the code that should be written - not the easy stuff - the hard stuff.

I've been working with a package that has a central object repository, and caches in each API instance. This is smart in that it allows for the client to grab something, and then hold on to it for many requests so that there's not a continual re-fetching if the data doesn't change. Nice. Problem is - they made the API cache single-threaded. This means that in order for a client to get any updates, it has to ask for them.

Normally, this isn't a horrible problem, but if the asking requires a re-fetching (as opposed to getting just the updates), then the more things there are in the cache, the worse it is on performance. Remember - this is single-threaded, so they aren't going to let you do anything until the re-fetching is done.

What they should have done is to make the cache update in a background thread with a simple "complete replacement" when the update arrives. Keep the bulk of the API single-threaded, but as updates flow into the API's cache, allow them to update a hidden copy of the object, and then lock the API thread, swap out the objects, and unlock the thread. This way, the cache stays consistent with the data in the central object repository.

Why is this important?

Because let's say I get an object and modify it. I've got a new copy, and I save it to the central object repository. Now another user does a similar action. They get the copy, modify it, and now my copy is stale. This is bad, because if I don't ask for updates, I may try to edit it more, and save those changes. Well... that's not going to do because my 'before' copy is not what the central object repository has. This means it's going to throw an exception.

But what about my edits? They have to go. No choice. I have to re-fetch, and then start over again.

Without even the simple flag like "re-fetch me", which could easily be added to the API under the covers, I have no idea that my work will be in vain. But it will.

This is the case for multi-threading that I'm making. There are times that you need to simplify the problem into multiple threads and have one dedicated to the simple task of making sure the cache is consistent. It's simple, surgical, and not hard to do. The results would be dramatic in the simplification of the client code.

So learn how to write multi-threaded code. Many times, it's the simplest way to get what you need done. And in the era of 60-core boxes, you're going to need it to get the most out of any box.

I was talking to a co-worker this morning - just after we arrived. I told him I heard that he'd be doing some web development - something I heard from the management team yesterday when they asked me about setting him up with a development box and such. He didn't look thrilled. I don't blame him. From his point of view, it's bad bad news. The one guy in this place that he outwardly hates, and outwardly hates him is the IT manager. This puts him under this guy and subject to his (often quite loud) rants. I've come to understand that they are as much a part f life here as the carpet and window cleaners. He's not yet at that point.

So he's trying to put a positive spin on things, and see it as once again, paying his dues, in order to get back to the place he was, and hopes to be again - quant trader-guy. Certainly an admirable goal, but there are many things standing in his way - not the least of which is the open feud between this guy and the IT manager.

My friend plays politics very poorly. He admits this. Maybe he's got a plan to learn better political skills, or maybe he's just going to sit tight and keep his mouth shut and try to ride this out. Not surprisingly, the "shit down and shut up" plan works remarkably well here, I'm guessing because so many people are pretty smart, and there's nothing a fragile ego likes more than to boss around someone who they fear is superior in some way.

But I'm not sure this is going to end up all that well. With the current financial crisis as the backdrop, there have been a lot of cuts - people and things, at a lot of organizations. I haven't heard anything definite about this place - yet, but it would not surprise me if the Bank as a whole decided cuts had to be made, and we ended up having to cut a few people. Wouldn't make it right, but it wouldn't surprise me.

Given this, I plan on doing what I've been doing, and simply acting like a little, neutered, slave and say "Yes" to everything they say. Oh, I'm not afraid I'm going to get cut, but there's no reason to ask for the unwanted focus at this time, either. Keep your head down, and let the storm blow over - it will... eventually.

I'm just not sure if my friend is capable of that. Maybe so, and if he is, he's learning, I'll give that to him. Previously, he'd have stood up and told them all they were acting timidly. It would have been right, but politically, it was suicide. So now he's looking at doing web pages.

He's a decent guy that doesn't deserve to have the political problems he has, but he did admit that he brought them down upon himself. I just hope this doesn't come back to haunt management or my friend.

This morning I noticed that Coda 1.6.2 is out, and the release notes indicate that there are a few FTP bugs fixed as well as some cosmetic highlighting and a maintenance issues. Not really earth-shattering, but I'm guessing that with the FTP process being so critical to Coda's functionality they wanted to get this out as soon as possible.

Once again, it's great to have products that are created by indie Mac developers. They see the problem, fix it, and post a release. It's that closeness with the customers that I like.

Just when you think corruption can't set any worse, this story breaks, and you realize that you can't honestly support a person who does this, no matter what good they might have done.

Selling a Senate Seat.

I shake my head at the complete absurdity of the notion.

People who represent us should know better. Hopefully, with this, they will.

In the winter I wear my hiking boots as I want my feet to be warm and dry throughout the entire, miserable, season. OK, no more editorializing. The problem was that I had a squeak in my left boot, and it was getting louder, and I was thinking it's time to get a new pair.

But I hate replacing things if I can fix them. So I went to Google for 'squeaky shoes'. I love the internet.

Turns out a really good fix for squeaky shows is to take out the insole and slather a bunch of lotion or ChapStik on the inside. I went with the lotion because I have a jumbo Baby Lotion at my desk, and I love the smell of the Baby Lotion - reminds me of my kids when they were little.

Anyway, I smeared a thin layer over the bottom of the boot, put the insole back in, and Shazam! the squeak was gone. I'm blown away. I love the internet.