What's it all about, Alfie?

My office is filled with great, old machines. A nice SPARC20, an SGI Indigo², a NeXTSTation, a Canon ObjectStation - lots of cool old hardware. But to be honest, it's not anything like my laptop or iMac for speed. I hardly ever use them. They are using power and heating up my office, and it was time to realize that they were my friends, and I'll try to hang on to them, but they are past time to retire.

I turned off five of them. I left on my two iMacs and a computer that's nothing but a print server, and as soon as I get new desks for the office, I'll put the printer on the G3 iMac and turn that guy off too. I'll go from nine to three. Big difference.

The heat will go away... it's already tons quieter, and I really haven't lost anything. I've got a lot more space in my office, and the new tables (from IKEA) will make it possible to put in a nice little loveseat that will be nice to sit in when I'm working on my laptop. Face it... that's what I do for 90%+ of the time I'm on a computer in the day.

If I get a new Mac Pro, I'll have room to put it in the new space, but at over $6,000 for the kind of configuration I'd want, I think it's a lot more likely that I'll just be upgrading the laptop when the new ones come out and leaving it at that.

It's a big change for me, and I'm a little sad about the silence. But at the same time, I'm excited about the possibilities.

Today I threw out my back. I've had a lower-back herniated disc for many years. It takes something - or nothing, to aggravate it into making it so that I can't stand up straight and walk like a hunchback. I don't like it one bit.

[9/3] UPDATE: I went to the doctor today and got the steroid pack to reduce the disc swelling. It's going to work, but it's going to take time. I really don't like this. But it's part of the recovery process.

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.