What's it all about, Alfie?

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.

We have had an upgrade of our infrastructural ticker system - that which my ticker plant is based on. It happens - things move forward, get better, all that. The problem has been that for the last two days - that's the first two days of the new infrastructure, we've had a good number of pricing issues from this new infrastructure. Not good.

So I was very interested in getting to the bottom of these issues today so that we don't have the same problems next week. What I learned from my contact in the infrastructural team is that this was a bug in their stuff when they restarted it. If we do a clean restart - clearing the cache, after their restart, then we should be OK. They have a bug fix in testing and as soon as I can get ahold of it, I will and kick the tires and give it a good check.

I don't want to get caught in the position where I'm getting these wacky prices. It's a major pain. Like a 2:30 am phone call 'pain'.

The last two days have been very interesting for me, professionally and personally. Yesterday I was sitting in a meeting with a project team and my Boss asked me if the process created by two other team members was error-free and ready to go. Since it hadn't worked for my part of the project, I had to couch my answer as saying I could not speak to the entire process, but the part where my stuff was impacted did not work. Yet.

Basically, I didn't want to make it appear that these guys failed in their efforts. First, they had precious little time, secondly, I had no idea if my part was 1% or 50%, and if it was 1% and the other 99% went smoothly, then there's reason to be optimistic. Basically, I knew very little because there had been very little time.

I tried to be diplomatic, but my Boss started yelling. At me. Even though it was clear that I was not responsible for this process, and more importantly, I said I just didn't know. Ask someone that knows. He didn't like that answer.

Often times, my Boss will put me on things because they are critical and he knows I'll complete them and make him look good. This has often times made me disliked by the other folks in the Shop as it puts me at odds with their little parts of this and that. This was no exception. I had been told by several levels of managers that these two guys had this process, and it was theirs.

So I left it to them. To my Boss' clear anger.

He yelled - considerably. I said I'd take care of it. It ended up not being right, and there were significant issues that had to be fixed, many of which were uncovered by me - not them. But since I'd taken the yelling, I was allowed to help. Lucky me.

Today I went into my Boss' office and told him that things were on track, and he mentioned that the manager of the two guys stopped by with that same news earlier. Good. I then wanted to talk to him - respectfully, about his behavior towards me in the meeting.

Yelling at me, when it's not my responsibility, success or no, is not professional. It's over the top. Way, way, over the top.

I attempted to tell him the position he puts me in - directly at odds with the managers on the floor - expecting me to simply work it out and make things happen. Well... after seven years, I'm tired of that. Certainly on this project. Where I had started that way and been slapped down so many times, I just didn't feel like getting up.

My Boss responds with "I see your point, but I'm not going to apologize."

I was stunned. Why not just leave it at seeing my point? Why did he have to make the point that he's not going to even offer a trivial apology? In retrospect, if he's the kind of guy that would yell at me in the first place, I shouldn't be surprised that he would not offer even a shallow apology.

My point of writing this is two fold: first, it's significant and it show the mentality of the people I work for, and second, I think there's no doubt in my mind this will happen again. And when it does, I'm going to pull this out and replay it to him. Not that it'll matter, but then I'll send it to HR, and they will have a talking to him.

May not change a thing, but I have warned him.

I saw a tweet this afternoon that BBEdit 9 is out! I had to get it. Well worth the $30 upgrade from 8.7.2 that I was using. The list of new and updated features is impressive. I like the 'Ponies' feature myself. 🙂

What I think I'm going to like most is probably the under-the covers changes like rendering speed and such. It will also be nice to have the ctags colored differently than the standard language-binding tags. I use ctags a lot in my code.

I might get into the habit of using the auto-complete with the delay timer. I'm not sure as I do a lot of typing very fast, and the odds that I'm going to hit that are slim, but it's something to play with.

I general, if you like BBEdit, get it. Great tool.

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.

Today I got a somewhat sketchy bug report that, if it was true, would possibly have pointed to a section in my code where I was deleting things from an STL std::map using the erase() method whose argument was an iterator on the std::map. The original code looked something like this:

  InstrumentAliasMap::iterator    ia = mInstruments.begin();
  while (ia != mInstruments.end()) {
    if (ia->first == anInstrument) {
      // found a match - erase it
      mInstruments.erase(ia);
    } else {
      // no match, check the next one
      ++ia;
    }
  }

where my thinking was that the iterator would be updated to the next, valid element after the erase. I think that was a major boo-boo. In all honesty, I didn't really know, but it seemed to test OK, and so it went. The problem is that after the call to erase() the iterator, ia, is invalid and can't be moved to the next valid element in the iteration.

I did a little searching on this as I was sure there was something simple about this. What I read was that the right way to do this was to take advantage of the properties of the post-increment operator which will increment the value (move it to the next element) but return the original value. So the code becomes:

  InstrumentAliasMap::iterator    ia = mInstruments.begin();
  while (ia != mInstruments.end()) {
    if (ia->first == anInstrument) {
      // found a match - erase it
      mInstruments.erase(ia++);
    } else {
      // no match, check the next one
      ++ia;
    }
  }

In this code, the iterator is moved to the next valid element and yet the original iterator value is returned to the argument of erase(). This then removes the element from the map and we're sitting on the next, good one.

I like this a lot more, and it's clear what I should have done all along. I won't forget this guy.

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.

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.