While on vacation, the great guys developing MacVim released another update - Snapshot 33. There are a lot of changes, but I didn't take a lot of notes as I was in a Disney World resort at the time. I got the update, and if you're interested, you should too. I think this is the best Vim implementation I've seen and it's certainly the best Vim on Mac OS X.
I have been working on a problem for the last few days at the Shop - a pricing data issue, and in the past I've worked closely with a good guy in another group to solve these issues. He's a great guy, in fact, always there to help me and we support each other's causes - when he needs to get something going for me, I tell him exactly what I need, and he scrapes it together... when I have a problem with his stuff, I don't scream and rant, I give him a good bug description and don't hassle him constantly for a fix - I know he's on the case, and he'll get it to me as soon as he can.
So yesterday I wanted to ask him if he got the trace data necessary for the problem we're looking at. He said he'd given it to the support team and that he'd check with them and if they haven't gotten it fixed, he'd step in.
He's become the manager.
Why?
I know it's The Corporate Ladder, and you're expected to climb it. It's not called the corporate couch or something, but still - why?
He was (is) a good guy, very talented at what he does, and still he wants to move to a position where he's not sure he's good at it, and not sure he's interested in getting away from the coding, but he still makes the move. And he's not alone... I know most people would be doing exactly the same thing in his position. But I still don't understand why?
I've managed - in fact, this is the first position where I'm not managing since getting out of college. I've owned my own company, I've done the corporate ladder... it's just a ladder that never ends. Never. You'll climb and climb, and then get on another company's ladder and climb there, and for what? Money, Power, Glory? OK, it's nice to have money, but after a point, isn't job satisfaction important as well? When you're coming home to your family, don't you want to say "Hey, I did this today!"?
I know it's not popular, but I like building, and doing, and would rather not talk about it to death. I'll be glad to talk about other people's achievements - great tools and projects I've seen and been a part of... but to do nothing more than be the classic Dilbert Pointy-Haired Boss.... No thanks. I want my life, and here I'm talking about my work life, to be more than that.
I've spent the better part of this day trying to track down a nasty little bug in, what I think, is Windows XP IE/Firefox and the Sun JDK/JRE Applet plugin 1.6.0_06. Now I say trying because I thought I had it fenced in to a certain set of repeatable conditions, but when I went back to check them after about an hour of running other tests, they failed me and the problem vanished. Crud!
The problem seemed to be a combination of using WebStart and a specific application off WebStart, and other Java apps on my box, and a web page that uses two fat Java applets to display data. One is a table of data, the other a graph of the same data. When I went to the web page, after running the WebStart application, IE (and Firefox) would lock up. Totally locked up. Not good.
I dug into this and have come to the conclusion that it's a combination of running this app pn WebStart, possibly the applet JRE version, and certainly the loading order on the page(s) in IE. If I go to the 'problem' page first, I get trouble - keep all else the same and going to another page first means that I can safely go to the 'problem' page later. Very odd.
When I went to change the version of the JRE that IE uses in it's applet tags, I found it exceptionally hard - as opposed to something like Mac OS X has where there is a little app that controls the version of the JRE used for applets. It's these little things that really frost my cookies with Java and Windows.
Anyway, I'm spending my day not really accomplishing anything because of these large applets and IE issues. I understand that sometimes it's nice to have applets to have a limited interactive functionality, and applets are great for that. But when the applets get to the point where they are causing as much grief as this, then you've overextended the design goals of applets. They become apps and that's what WebStart is supposed to make easier to deploy.
UPDATE: after another hour or so of fiddling about, it turns out that if I use JDK 1.5.0_15 and that's all, then I'm OK. If I even install JDK 1.6.0, it's going to take over the applet duties for IE - no matter what the settings in IE say. This, then causes the problem and we get the lock-ups. If I didn't need JDK 1.6.0, I'd be OK, but we need to have Java WebStart, and the 1.6.0 version is what we're standardizing on there. This means that for now, we leave the users on 1.5.0_15 and when we have to update to 1.6.0 for the WebStart for the users, I'm sure hoping that we have a newer version than 1.6.0_06 - with a fix for this crummy problem.
I hate big Java applets. Make an application, for heavens sake! Or switch to something like AJAX, or live with the page refreshes! It's not meant to do this.
UPDATE: HA! I found a bug report at Sun where several people were complaining that they had applets that worked fine in 1.4 and 1.5, but with 1.6.0_06 they were having a lot of troubles - just like me! Sun's idea was to try 1.6.0_10 (beta) and see if that didn't fix the problem. So I downloaded the two-part JDK/JRE and BINGO! that fixed the problem. Guess Sun's had this quite a bit, and fixed it. Good enough. I still think we're pushing the limits on the applet design and we need to come up with a completely different client footprint design - AJAX and Javascript frameworks or a full-up client.
Today one of the users of my scatter graph - the guy who asked for the pseudo-z-axis capability, in fact, asked if I could make it a little easier to understand what was happening on the z-axis data, so I decided to take a swing at it.
I was really surprised to find out that by simply putting a border on the group of z-axis widgets, and moving the buttons from below the list to the right side of the list, I could get something that really looked good, and didn't take up more vertical screen real estate than the old way of doing things.
The result (above) is something where the z-axis is clear (FTSector), and the values are easily seen, and the inclusion is easy - All or None. I have to say that I think this is a big improvement.
Also, I'm trying out the posting from Skitch for the screen grab. There have been a lot of times when I wanted to do this, but didn't want to mess with it in my WordPress install. So we're going to see how this goes for a while. Not bad, so far...
I tend to agree with Joel, of Joel on Software fame, but today there's something he's saying that just isn't right. His point is that you should not hide or disable menu items because there's no feedback to the user why they can't use these, if they can see them in the case of disabling, or not see how to do something in the case of hiding.
While I can understand his logic, I have to say that I think he's taking an extreme point of view to try and make the point. His point is that your application should be easy for all to understand. And to that, I agree. However, it might be a lot easier to understand if the menu items were grayed out if the actions we're allowed. As Daniel J. points out in this rant, there's a lot of ways to indicate why without having the user try something and then be greeted with a message box saying "Hey, no can do".
It's a question of usability and your users. On a Mac, the average user is going to expect that applications behave a certain way - including having disabled menu items. On this platform, if you don't disable a menu item that is illegal in a certain context, the users will think it odd, and say it's a bug. And it is. For this platform. On some other platform, maybe not. But I think it's going to be tough to really make hard and fast rules like this without looking at the environment and the expected users.
I was trying to get some sleep last night, and I got a call from the Shop about a problem with one of my systems. It wasn't my fault, but that doesn't matter, does it? There is a problem, and it needs to be fixed, and trying to assign blame is just not going to do anyone any good. I walked the second-shift guy though the initial debugging steps, and it appeared that I had to get out of bed, get online and see what was happening.
Turns out, there's a mistake in the generation of a back-up position file, and the simplest thing was to get the primary working and base things off that. I did it, and was back in bed in about an hour or so. Not a huge deal. But then it got me to thinking about the last few weeks.
I've been asked to get "emergency" updates out for projects that aren't mine, and did them literally in less than half the time the manager of the product expected - less than 24 hrs. in all cases. I've been asked to do several things that under 'normal' circumstances I'd never have been asked to do - all because it's an emergency for one business user or another, and they needed it done right away and had no time to get one of the eight people on the project to actually do it.
Then the calls about the problems that aren't really mine, but I'll fix because that's the kind of person I am. I don't pass the buck, I don't find the problem, assign blame, and hang up. I find the problem, fix it, and then we try to make sure it doesn't happen again.
I'm the classic go-to guy here. I've been here for so long that I know how a lot of things fit together, I know what's supposed to happen, what might happen, and how to deal with it. I'm a walking compendium of environmental knowledge, and that's become what my real job is. I'm trying to come to terms with it, because I took this job to be a coder, and there are a lot of people here that have far more time with these systems than I do, but they aren't the kind that will function as I do in the middle of the night. Many will yell and hang-up, or simply not answer the phone. So I've become the person I am.
It's security, that's for sure. But it's also a little boring. I want to create not answer the same questions 53 times a week from 13 different people trying to track down what happened on this day at this time because the business wants yet another post-mortem on the problem. I understand the need for the analysis... I just don't see the need for everyone to bug me about it.
I'm going to have to grow into this role, that's for sure.
Today someone stopped by and asked if there were a way to add a grouping, or filtering, capability to the scatter graphs that I have built atop the VantagePoint graphing system. In the Shop, we use these interfacial classes as they include applet frameworks so it's easy to include them in applications and applets, they represent a simplified user interface, while still allowing the user to dig into and grab the VantagePoint objects if required.
The functionality is basically this: have the user indicate a column in the dataset - numeric or alphabetic, and then generate a list of unique values for that column. Put those into a simple JList in the graph's GUI and then allow the user to select/de-select the values and in so doing, showing and hiding the values on the graph. For a concrete case, imagine there's a column that indicates the species of an animal, and the rows are a series of animals on a farm. Many will be duplicates (cows) because there may be specific data fro each cow, but there will also be chickens, and pigs, and dogs, etc.
By selecting 'cow' in the JList, the cow's data will be show in the graph. Deselect it and the cow data will disappear from the graph. Pretty neat. It's a good idea, and I needed to think for a while about how exactly to implement it successfully.
VantagePoint allows me to easily show/hide the individual labels on points, so that's easy. But when looking at the points on the scatter graph we're in a bit of a pickle. You see, the scatter graph is the intersection of two columns - one for the x-axis and the other for the y-axis. VantagePoint only allows for showing/hiding of complete columns. So if I try to hide one point, I hide the entire graph. That's not good, and there were no documentated ways to do this 'single-point' visibility.
Then I got the idea of painting the points white-on-white. VantagePoint allows you to color each data point differently, but the problem is there's a black border on the points, and I could not figure out how to change that color. Then I thought of the size. Bingo! I had a winner.
I could make the points that I wanted to hide very, very small, so small that they didn't even render. Then when I needed to show them again, I could draw them 'normal' sized. This was nice because I didn't have to remember the color of the point - I just had to change the size of a point from 'small' to 'normal'. Sweet!
I still had a little work to do on the order of graphical operation to keep the 'flash' in the update to a minimum, but I think I have that working just fine now. It's been an interesting ride, but I'm glad I stuck with it to get this done. It'll be a nice addition to the graphing capabilities of the graph.
I was talking to a friend that was 'thinking out-loud' about starting an Open Source project for a web service that he wanted to build in Erlang. It sounds nice, but as I'm not really the most knowledgeable person about the subject matter, I'm really more of an interested observer than an active participant, but we've been friends for a lot of years, and so I wanted to listen about this idea of his.
He got around to the fact that he was also working though this issue with XML files (totally unrelated, which is the way a lot of our conversations are) and the fact that the people that created these XML files had their own XML parser that didn't adhere to the XML standard, and so all the XML code they generated wasn't standard and he had to write a job to clean it all up t then use it. "It's all about details!" he said, and I could not agree more.
Development is about details. Anyone can sit and say "I want this page/view to have this, and that, and this, and I want it to look like this, with bold here, and a pick-list there..." but it's making it work that's the tough part. Even with code generators these days, it's the details they leave out that matter most. If you really want to make a sustainable, maintainable, robust application, then it's going to require that someone get involved in the details. There's no other way to do it.
If you think you can be a developer and not pay attention to the details, then my suggestion is to get another job. You're not in the right line of work. You might as well be a surgeon that can't stand to see blood. It's that much a part of the job. Unfortunately, as my friend and I spoke, I realized that we both know of a lot of 'developers' that don't have any attention to detail. I hear it every day. It's a sad statement on the craft of development that there's no easy way to tell a developer who has attention to detail from one that does not. They both look the same.
I've been using MacVim for a few months, and reading the mailing lists about features, updates, etc. It's interesting stuff to listen to people that are as into Vim as I am my family. It's amazing how much these folks know about my favorite editor. Today the team released Snapshot 32, and with this, they hope to be turning back on the Sparkle updating from Google Code. It's been turned off for the last few updates because of issues, and they are thinking that they have them solved, and are back on track for enabling them again. We'll see how well the update is received.
I'm excited about it... and learned a new thing about .vimrc files today - you don't include the colon in each line. The guy on the mailing list pointed out that Chapter 5 of the manual points out that you don't put in the colon (':') but everything after it. So I went through my .vimrc and cleaned it up and it's working perfectly. Not that it wasn't before, but there was someone that had a problem, and this makes sure I don't run into that kind of problem later. Nice.
This morning I was doing a little checking on the projects I keep loose tabs on, and one is the gfortran compiler for Mac OS X. I've chatted with Gaurav, the maintainer, a few times and it's really nice that he's taking the continued effort to keep updating this package. I'm guessing he's using it in his work at the university, but I could be wrong.
I did a make clean; make on shark to see if there were any issues with the compiler, and there weren't any. Ran fine. Thanks Gaurav.
The MacResearch.org guys have a package for installing that has this as well as an Xcode plugin for building gfortran code in Xcode, but I'm more of a vi/Vim and makefile user for FORTRAN coding. Just don't really need the extra stuff at this point. But it's nice to know it's there, if you need it.