What's it all about, Alfie?

I've used a lot of different source control systems in my days. Some have seemed to be really nice, only to be replaced by others that are even nicer. Some were replaced by worse systems, but for the most part, it's about the integrity of the development process. Period. Some make it easier to work in teams, some make it easier to work in a distributed manner, but all should have the same key feature: it allows you to version your files so you don't loose anything.

Which is why I was stunned to be in the middle of a discussion about the "one" source control system we should be using. Why? We've used ClearCase, and it worked OK, but then they didn't like supporting it and told us to move to a different system. We've used CVS for ages and it's never failed us. You can use Subversion now, and it's fine. I'm not sure, but I'm willing to bet that just about any reliable SCM is going to work. Just pick one, make sure it's safe, backed-up, and then get on with the job.

To say a group needs to use one at the exclusion of another is silly. You don't use one development environment at the exclusion of another - use Eclipse if you want... use Emacs, use Vi... just get the job done. Why would a group of professional developers even consider making rules like this?

OK, maybe some places feel it's important to have a single tool for each category so that people can get used to it and not have to change. Fine. Then by that logic, if someone is using a tool, don't make them change. If it's working, then it's solved. If it's not, then fix it. But making rules like this when nothing's broken is just plain silly.

When I've used projects that are in Subversion, I used subversion. When they were in ClearCase, I used that. What's the big deal? There is no one tool that's so vastly superior to the others that it can't be made to work, just pick one for a project and stick with it. Seems pretty clear to me.

But I'm in the minority here, it seems. They want to say all new development needs to be in one system. Until they don't like that and move to another, as they did when they moved to this one they are favoring now. It's crazy, but that's corporate life, I guess.

This morning I was able to restart the last of my servers that had a re-configuration with the MindAlign system to disable it. These were the 10 authentications per minute that were spamming the authentication server... well... the last of them are finally disabled and things seem to be going swimmingly. Good for me. I wrote up the documentation on how to re-enable them once MindAlign decides to allow bots once again - whenever that is. I just wanted to make sure that if I got hit by a truck, someone could read the docs and get things going again.

I know from experience that this is not going to make any difference in the MindAlign stability, but they have been rather insistent that we shut down these spamming bots and so I have done it as quickly as is prudent. We'll see if they are as quick to restore complete MindAlign service.

I'm not holding my breath.

Over the last several days we've had significant issues with what appears is non-ASCII data entering the MindAlign servers and bring them all down. Since data like that is very unlikely to be entered by a human, it's thought it had to be a bot. Fair enough.

I've been sent messages by the MindAlign support group that I needed to shut down all the MindAlign bots I had because I was spamming the authentication server with connection requests. I've checked, and we're talking about approximately 10 requests a minute. Hardly excessive, and certainly not the source of continued instability in the system.

Yet I get messages to shut them down.

But to do so is to update/patch several production systems - not the thing you want to do quickly or in haste, and since I've never run these production apps without chatting, it is going to be easy to miss one or two places where the chatting is done. So it's a significant production support risk - all for 10 hits a minute. Hardly seems worth it, so I haven't done anything about it.

Until today.

Today I got a call from one of the MindAlign support folks and he told me what his email had said. I then pointed out the risk to production systems and he actually started to laugh. Clearly, he knew this was a much a fool's folly as I. I even said so. We shared a little giggle and I told him that he had done his job and I'd look into it.

After all, 10 requests a minute is certainly reason enough to cause global chat instability. Hmmm... he didn't think so either, but confessed that he was just 'under orders' to pass the word. I told him his duty was done and he laughed at that as well.

In the end, I put in the changes as best I could, tested them as best I could, and will get the final few restarted this evening/tomorrow morning so as to shut off this spamming. But the problem will remain, won't it? Certainly, because these bots that are so important have been tested and re-tested so many times under so many conditions that they are so unlikely to be the cause of the problem it should be an acceptable risk to leave them on.

It's the bots that are new in the last few days, or those that might chat binary data. Not these that have been working fine for years. It's just silly.

But we're putting production services at risk for this. All for 10 requests a minute. And no one but myself and the guy that called and laughed about it seems to see how incredibly thoughtless this is. But that's how some things go - no one stands up to the Emperor who has no clothes.

I've been working a lot with MindAlign lately, and specifically with the case where the login credentials are not valid and the server returns 'ERROR:504' as opposed to the package that the protocol indicates. Since I hadn't seen anything like this in their spec, I have just been assuming that it's a protocol error and throwing it up the exception chain as a general error in the code I'd written for MindAlign in BKit and CKit.

Well... that's no good. So I took the few minutes to clean that up and create a generally more informative exception message saying that the authentication server didn't like the login. This isn't going to revolutionize anything, but it might save someone 5 mins debugging, and that's good enough.

Again today we're having problems with a key infrastructural communication system. Whose fault it is is really unimportant... we're not changing this component out anytime soon - it's a key component in a company that literally spans the globe. It's here.

That being said, it is interesting that today I get a mail from them saying it's going to be running in a restricted mode for the next week. This places a non-trivial squeeze on most of my applications. I use this in every app to communicate with it - control it... monitor it... check health... lots of stuff. So to be without it for another week is non-trivial and more than a little annoying.

Sa as I was saying, they are asking us if we can migrate to a less-secure version that we used to all be on about a year or so ago. It was a multi-year effort to get everyone migrated to the new secure product, but they want to know if we can move back in a few days. What? Oh... yeah, that's right... when you can't fix your own stuff, the best ploy is to ask the users to change and hope that they can change fast enough not to get sick of the outage and decide to move off your product for good. I mean, can these guys be sincere about this?

For me, it's less than a dozen applications, and in some cases the changes are simple configuration changes and some are more structural. But if we change to the old system it's going to mean a ton of logistics... new login credentials for each of the 120 connections I have... new names of channels... lots of chances to get something messed up in the change.

That's why it took more than a year to get the move up right. It had to be sure not to break anything. I don't know what the problem is with their system - it could be really tough to figure out. But to get hundreds of applications reconfigured only to reverse it when they got it all cleared is a little more than a simple exercise. It's silly.

They need to find and fix the problem. If they have to call in smarter people, then do it. If they have to get in new servers, do it. I can think of any of a number of ways to hack the system to work in a pinch, but they aren't asking me and I'm not offering unsolicited advice. But the mere idea that we can easily manage the risk of a global change like this in a few days is absurd. It'd take weeks, and they had better be able to fix this problem faster than that.

We use MindAlign in the Shop to have a secure chat environment, such as it is. Over the last few days, it's been problematic to say the least. Today, in fact, they have narrowed down the problem to a global corporate loss of DNS due to MindAlign.

I am not going to bad mouth MindAlign, it's a package that the corporation has picked, and we're going to use it. Period. But today when I came into work I noticed (again) that almost all my production applications (servers and services) had one core/CPU hammering away doing seemingly nothing - but very very fast.

I found that once again we were having MindAlign problems and I decided that this morning I'd dig into the problem and find out why they were all spinning like mad. The first step on that path was to get a few stack dumps, and it's a lot easier to do that in Java than it is in C++, so I did a few thread dumps on an afflicted Java app and after three of them, it because pretty clear where the problem was - in the BKIRCProtocol object. That's the thing that talks to the IRC server, which is the core of MindAlign.

It appeared that the IRC protocol was trying to throw an EOFException because the socket was not returning any data, and was, in fact returning an error code indicating that it wasn't all there anymore. The problem was, that at the higher level, where the EOFException was being caught, I was assuming that the socket was closed - which is why I'd get the EOF condition in the first place. By making that assumption, a socket with an indeterminate state talking to the MindAlign server was "there", but not "there enough".

I put in an explicit disconnect() on the socket connection and that should take care of things. Simple one-line fix (with an accompanying 10 line comment to say why it's being done. Then I was on to the C++ version.

Thankfully, the code is very similar, but the socket communications isn't. But I dug into the code about the same spot - a socket that's almost dead, but returning that it's still connected even though it's not returning any data. What I found was code that looked like this:

  // now read up to the "\n" NEWLINE that the IRC server sends
  if (!error) {
    retval = mCommPort.readUpToNEWLINE();
  }

where readUpToNEWLINE() should return only when a line is received from the IRC server terminated in a NEWLINE (\n) character. The problem was, it was returning an empty string and that was all I needed to know. If it returns nothing, then the only acceptable reason is that there was a timeout. So, check for that, and all other conditions cause us to disconnect from the server and on the next pass, a new connection will be created.

Something like this:

  // now read up to the "\n" NEWLINE that the IRC server sends
  if (!error) {
    retval = mCommPort.readUpToNEWLINE();
    /*
     * It's possible that the data is empty - but the only way for
     * that to be acceptable is for a timeout to have occured. So,
     * if the data is empty and a timeout *didn't* occur, then we
     * need to disconnect this guy and the next pass through, we'll
     * be able to connect again and set things up properly - we
     * hope.
     */
    if (retval.empty() && (errno != ERR_READ_TIMEOUT)) {
      disconnect();
    }
  }

At this point, I think I have the MindAlign issues under control. There's still the issues with the corporate servers, etc., but I can't do anything about them, and we'll just have to wait for them to get fixed up properly by the support teams. It's just nice to have these fixes into BKit and CKit so that I won't get bitten by this problem in the future.

Twitter is nice when the applications you use post their updates on it, so that you get notified as soon as possible of the new release. Another wonderful such happening occurred today with MarsEdit 2.2.

This release has an improved text-clip manager for the images and files - very nice. It's got a few new defaults and supposedly a lot more speed. So much more speed, it seems, that the default is for the preview window to open when editing a post. This is a significant change as previously this was cautioned against due to the processing hit it would cause.

I've updated, of course, and am busy posting this on the new version. Hopefully, I'll be happy with the speed, but the one bug/feature that bothers me most is the minimum size of the composition window. I know he's not going to change it, but it would be nice if he decided to re-do the GUI and as a result, relaxed the window width.

That's all I want... just relax the minimum window width. I can do it in Interface Builder, but that's a step I'd really rather not take.

UPDATE: one of the most striking things is the launch speed. It's on par with TextEdit, and that's saying something. Very impressive indeed. I wonder what other speed improvements there are waiting for me to find.

I read this on one of the RSS feeds I read and it mentioned that an 'inside source' at Amazon was saying that a new version of the Kindle was going to be coming out this fall. Something with a little smaller footprint and colors. I'm not sure that I'm ready to replace my Kindle yet, but I tell you I'm certainly planning on keeping up-to-date with these devices as they improve. I've become a true believer in the Kindle and Amazon's service.

I love reading and this is without a doubt the best reading aid I've ever had. Sure, it's not perfect, but it's so far better than paperbacks it's not even funny.

This morning I was updating one of the Numbers spreadsheets I had and was trying to push the envelope a little more and see what tools Numbers really had for - well... crunching numbers. I had some data that I wanted to have massaged a little more automatically, as opposed to the brute-force method that I had been using for the past year - since I moved the data from Mesa to Numbers.

The first thing was to have a better calculation of the YTD comparison of monthly numbers. The issue was that I only wanted to look at those months I had data for this year in the previous year. Making it as apples to apples a comparison as possible. The trick there was that the comparison needed to be a sum of the data, so it was possible to make a new column with the IF() function, but it was done even better with Numbers' SUMIF() function.

By simply making the test range this year, and the comparison ">0" and the sum range the previous year's data, I get the sum for the previous year's data for only those months that I have data for this year. Excellent! One thing done automatically that I needed to do.

The next thing was to have the year-on-year monthly changes automatically computed without messing up the sums or averages by putting a '0' in the cell. This was pretty easily done with an IF() call where the conditional was the value for this month of this year being great than zero, and the true clause was the percent change. The false clause was simply the empty string, and that worked out pretty well.

When I was done with the process I had a workbook that looked the same, but acted entirely differently, and much more like a cool, complex, spreadsheet should operate. Now I put in the raw data and shazam! the complete workbook gets all the data it needs. Very cool.

Yes, I realize this isn't that big a deal, but the little I do with spreadsheets is very much brute-force and the steps to find out these functions and use them well was an interesting exercise.

OK, I've been coding for a long time. I've used lots of development environments and the only one that I've found that really holds my interest is ProjectBuilder/Xcode on Mac OS X. From the first time I used it on NeXTSTEP 3.3, I knew it was something far beyond an editor with build tools. It was just so clearly built by developers, for developers. I'm still of that same opinion today.

This morning I read about an interesting tool that analyzes the Obj-C/C code and tells you where you might have issues with leaks, etc. Nothing that hasn't been covered a dozen times before in a dozen different tools, but this one is a little different. First, it's a syntax checker. Again, lint did this for decades, but this is different in that it knows about the idioms of Obj-C and the class structure that Mac OS X uses. That's huge.

Next, it's slick in it's reporting in that it's all web-based and generates all this very simply. I'm not a big fan of web apps, but for reporting, it just can't be beat. What they have done here is the very best of web reporting for coding issues, and I have to say it's remarkable.

I decided to put in one of my projects to see what it might find. Interestingly, it found a possible error in one of my classes in that I wasn't creating a - (void)dealloc method for the instance. Now, technically, the class involved is the main controller class, and it would not get deallocated except on shutdown, so there's no real problem there, but it's nice to keep things clean and try to do the right thing all the time. So I added the very simple method and re-ran the checker. Clean, save for a dead store issue that I'm not about to change as it's really just the last part of a method that doesn't return the error code. It's more of a coding style than an error, but I appreciate that it's telling me about this.

While I'm not doing a lot of Obj-C coding these days, it's tools like this that make me want to change jobs so that I did do a lot of Obj-C coding. The Mac is a wonderful platform, and its development tools are the best I've ever seen. With the addition of tools like this code analyzer, it's even better. Long live the Mac!