What's it all about, Alfie?

I guess this really isn't the fault of the tech salesforce, but it's the illusion that they are really providing something in the transaction. Oh, sure... there are some turn-key solutions where all we really need to do is to buy the hardware - speced out to the last detail, get the install disks from the vendor and that's basically it. But those solutions are really few and far between. Most big systems have to interface with systems in-place in your Shop so it's not a plug-n-play solution. Which is the supposed reason for the technical sales force (aka consultants) from the vendor.

Here's what happened... we have asked the vendor to be on the next version of their product - something that's a complete re-architecture from the currently shipping version. Totally different. But in a way, that's good. The existing system was a mess and could not possibly do what we need, and the new system may be new and green, but at least it's got a chance of being the 'right thing'. So we need some hardware to run this beast on, and I put together a list of a minimal set-up to get us going. I know it's probably not enough, but it's close and has a decent chance of being all we need for production. I send this to my manager, explaining why I've chosen this configuration, etc. and said "Approve this and we get moving". One of the guys who's not above me in the org chart, but has fewer boxes to the Big Boss said to run this by the tech sales person and see if it's OK.

Normally, I'd say "Great!", in fact, I would not have made the list myself but asked them for a list. But that's not really possible now. There's a totally new architecture that they've never delivered to any client, doing things that they never did before. How do they know what our situation is going to take? They don't. But even if they did... my guess was 'reasonable' - let's say the knew what it'd take. If it was less than this I'd be very surprised because the system we have now doing this task is using this same hardware and only doing a fraction of the job this system will be required to do. So doing more for less? Hmmm... then there's the fact that the existing system is all in C++ and this has significant parts in a scripting language. While I'm not saying it's slow, I am saying I'd be very surprised if it were faster than what we have now.

So let's say it's slower, and they know it. Are they going to say "Hey, this is only about half of what you need." Not a chance. We'd say "Half!? What's wrong with this thing?" So they'd keep it to themselves and realize that this will get us started, and as we get into the project we'll see that it's not enough and order more.

So all this asking them is a wasted exercise. We're not going to get any useful information from them. The product is like nothing they've ever delivered before - totally new. They're guessing just like we are. But by asking them we're delaying doing anything on the project for several days to get this useless bit of information. When you're putting something together for the first time you can't expect cookie-cutter answers. You have to use your experience, understanding of the problem, and goals and stick a finger in the air and guess.

If you're good, then your guess is pretty darn good, and you go from there. Asking someone else doesn't increase the confidence in your guess. Just do it.

Today a developer stopped by to say that one of the graphing classes - the combo graph (bars and lines), had problems when you degenerated it to a bar graph (no lines), and to a line graph (no bars). I checked and he was right on the money. Now one might ask why this is important, but there are times you'd like to just code it up and not worry about the number of lines or bars and have the GUI widget smart enough to just do the right thing. So I dug into the code to see how hard it might be. Interestingly enough, and I probably should have seen this coming, one was a lot easier than the other.

In the VantagePoint scheme, the combo graph is a subclass of the bar graph (hint, hint) and so the first thing I tackled was the case where there were no lines at all. The problem I had was that when I saw that the user didn't specify any lines in the combo graph I simply did nothing, and that's not the best thing to do in this case. What I needed to do was to see that there were supposed to be no lines, and then set that in the graph. Pretty easy.

Then I tried to do the same kind of thing for the bars, and surprise! that didn't work. NullPointerExceptions deep within the VantagePoint code that had clearly undergone some kind of code obfuscation so that the classes and method names meant nothing to me. Finally, through trial and error I came to the idea that VantagePoint was simply not going to allow a combo graph to have no bars. (well.. duh!)

I changed tack and said "Hey! A combo graph without bars is a line graph!" and what I did was to have the applet code detect the 'lack of bars' condition and switch the graph to a line graph and then plot the lines on that graph. Bingo!

I suppose I should have seen the lack of bars on a combo (bar) graph as a non-starter for VantagePoint, but I assumed that if it had either type of variable it would be OK. That was a mistake. The bars are the driving variables and the lines are the 'decorations' on the base graph. Makes sense now, but finding it in the VantagePoint NullPointerException was not easy. But I got it.

Like a lot of places, it seems, we have gone through our fair share of people. Most don't fit, and detect this and get another job. Many are happy moving on, while some find that they really had it a lot better here than at the new place. Grass being greener syndrome. Every now and then there's a person that is asked to leave. While there are just a few basic reasons: not enough work, not enough money, or bad fit, there are a few in that last category that have either become people that would not have been hired, or were such consummate con artists that they were always this way and just hid it well enough in the interviewing process to get in the door. These last group of people really don't last very long, but the mutators are an interesting breed in their final days.

Such is the time I find myself in this week. One of the developers has decided to leave - right ahead of being asked to leave. I have no idea where he's going, nor do I really care, but it does amaze me to think how he could have gotten a job with the attitude he has displayed here for the last year or so. Understandably, people respond to their environments differently. And if there's a hostile environment there is always the fight or flight response. But there's more to it than that as we're supposed to be evolved beings.

If you find yourself in a job that you really don't like - change something. Change the way you do your job, change the way to approach your job, change the hours you do your job, change something to try and make it better - or change your job. Don't sit and complain all day about your situation... no one wants to listen after a bit. Don't complain that they aren't giving you enough advancement opportunities - go out and make some, and if you can't, then find some place that you can.

If you can't change anything about your job, and you can't find another, then you're in a pickle because it probably means that you shouldn't have been hired for the job you have, and need to think about another line of work. Write a book, change careers, do something.

Alas, the developer who is leaving here is most likely doing none of these things. He's probably interviewed just well enough to get a job based on the business knowledge he's gained while being here. His work ethic is bad - I can't remember him coming in regularly before the market open. His development skills are very marginal - I can't think of one compliment he's gained from a fellow developer in all the time he's been here. Most importantly, he's a complainer. It's just hard to work with guys like this for a long time. It's draining.

So rather than finish up his two weeks with a little bit of class, he's taken to coming in even later, doing even less, and when given the chance to get out of the last few days of his last week, chooses to put off doing things which would allow him to have a little time off between jobs. It's really almost amazing. He's not even actively leaving - one more thing he's not very good at.

People at his new workplace are probably going to see this and figure out what we have figured out. Sure, he may work harder because he likes the environment there better than here, but I have a feeling that in the end, it's more about him, than his environment. You either are a good worker, or your not. It doesn't matter what job you have, you either do it with some sense of quality and conviction, or you don't. And if you don't, no job is ever going to stop you from complaining.

I've been working with SubEthaEdit a lot in the last few days, and also with BBEdit, trying to get the few features that I don't like fixed/cleared up, and while I really like both of these editors for their unique approach to the problem of a developer's editor, there is a lot to be said for Vim. I have done more coding in Vim than probably any other editor in my life. I've used it on so many systems it's amazing, and I've never had to compile it myself. There seems to be someone who's already figured out how to get it to work on every platform I've needed. The community support is really amazing.

I have been using the Vim package from macvim.org, and it's currently at 7.0.224 for Mac OS 10.4 (Tiger). I am able to use all the nice fonts, syntax highlighting, everything that I expect in Vim, just on my Mac. The only problem is that it's stuck in Vim's view of the world. That means you can't have multiple windows open on the same application instance. On Unix this isn't an issue because you typically start a Vim session from the command line, but on Mac OS X, it's a limitation that I find... well... annoying, and it makes me not use it as much as I might.

There are also several things that the other two do that are very nice that Vim misses out on. It's not horrible, but when given the choice, I really end up using SubEthaEdit and BBEdit more on my Mac than I do Vim. But it's close. Many of the requests I have in to the SubEthaEdit developers and BBEdit developers are things in Vim that I wish they'd do - or do better.

Still... I can't complain. Vim has been very very good to me and I hope they come out with a Leopard release (Mac OS 10.5) very soon so I can upgrade my laptop to it and keep Vim with me.

As reported on Mac Rumors, there seems to be a way in Leopard to disable the shelf-style Dock in favor of the Tiger-like window-style Dock. The tip is pretty easy:

    $ defaults write com.apple.dock no-glass -boolean YES
    $ killAll Dock

and the Dock is back to the Tiger-style Dock. I'm not sure which I'll like more, but I had a feeling that the new "glass" style would be something that annoyed me to no end as I typically hide my dock, and when it comes up, I want it to look more like a window and less like a shelf.

Let's not forget about the defaults value that makes hidden apps visibly hidden on the dock:

    $ defaults write com.apple.dock showhidden -boolean true
    $ killAll Dock

I've used this one for a long time, but I'm not sure if the upgrade to Leopard is going to remove this, so I'll keep it handy just in case I have to re-apply.

The way to enable the root user on 10.5 is to open the Directory Utility in the Utilities folder under Applications. Unlock it for changes and then under the Edit menu, select Enable Root User and type in the password for the root user. No need to login as root, but it's proven itself very handy when making backup scripts, etc.

I read this from Ars Technica this morning about the new Verison FIOS 20/20 plan, and all I can say is Wow!

Some residents of New York, Connecticut, and New Jersey who live inside the boundaries of Verizon's FiOS network will be the first to be able to take advantage of Verizon's new 20/20 FiOS service. As the name implies, 20/20 FiOS is a symmetrical 20Mbps connection (same speed in both directions), and it's one of the first symmetrical services to target the consumer market.

Available today, 20/20 will cost $64.99 per month and will include Verizon's Internet Security Suite and 1GB of online backup (up to 50GB can be purchased at "competitive rates").

20 Mbps down and up. It's just what I've been hoping would come to Chicago, but they don't seem any too interested in rolling it out to these parts - yet. However, it would be nice if Comcast responded with something like 10/10 which I'd be all over. The problem I've run into in setting up my home network services is not the uptime of my boxes, it's the speed and unreliability of the link. From home, in download mode, it's great. But accessing services from the road has always proved really quite hit or miss.

I look forward to the day when I don't have to worry about what's a home versus what's on my laptop. It'll make getting things done a lot easier.

This week marks the time when we have to make final preparations for going off Daylight Savings Time (DST) which is important because Hong Kong does not observe DST, and so we're going to loose an hour at the end of our day and the start of theirs. This is important for trading and risk apps like mine. The original solution was to make my app run 24x5 without any interruptions. This was a significant technical challenge and after about a day or two of this, I decided that it'd be better to make use of extra hardware to have two servers - one that covered the US and Europe, and another that covered the Far East.

Problem was, this meant that there was going to be a lot more maintenance of the system to keep two systems up and in sync. After hearing me say this, most said "Yeah, yeah" nodding their heads, but thought I really didn't understand the situation. When I came back with a list of things that would have to be done each evening to make this work, all of a sudden the easier solution to the problem appeared.

The problem really comes down to the fact that we typically didn't start the nightly processing until about 5:30 pm, Chicago time. This was 6:30 am Hong Kong time, and after the DST change, it'd be 7:30 am Hong Kong time. Given that the start is then, it's likely that we are not up and going by 8:00 am local time in Hong Kong, and that's the problem. So I had suggested that we move up the end-of-day processing, but that got nowhere. Then they saw what they'd have to do to support the two servers capable of giving Hong Kong the data they needed when they needed it.

All of a sudden, the end-of-day processing was moved up to 4:15 pm Chicago time. Plenty of time before Hong Kong would need it.

While I'm a little frustrated by the fact that I wasn't listened to earlier, I have to take solace in the fact that eventually my ideas found ears, and things started to move in the right direction. Now the second hardware is for disaster/recovery and there's only one server covering the globe. It's simpler, and while there are bound to be bumps in the road, things are going to be better by moving up the end-of-day processing.

That first bump was last night when I got a call on the train. It was from someone asking if there was a way to edit the data that's sitting in the middle-tier of the application. I said "Nope, it flows from the server, and that's already thinking it's tomorrow." I knew what they wanted to hear, but it wasn't going to happen. The data in the middle-tier is too complex to simply edit with something like a text editor. The values are interrelated and computationally intensive calculations need to be done in order to derive some values from others. It's not easy. Which is why there's no easy editor of that data. But because of the early restart, the guys didn't check on the state of the system early enough in the afternoon to make sure that it would be good to go for the earlier restart.

Lessons learned. Like I said... a few bumps in the road, but it's a better place we're going to.

Several years ago I got an iBook after not having owned a Mac for many years. When I was at Auburn I was a big Mac Fan because I'd tried to write papers using PCs, and there just wasn't a reasonable set of tools on DOS/Windows that even remotely compared to the tools on the Mac. But when I went into business for myself, I targeted the largest audience possible and that meant PCs. Later, when the only thing that mattered was what I wanted, I got the iBook. I looked around, and while TextEdit was OK for somethings, and ProjectBuilder used it, I wanted a little more powerful editor. I went with BBEdit.

I haven't regretted the decision, BBEdit has been a wonderful tool. But a while back, Hydra was written by some interesting guys in Germany. Collaborative text editing. I could see that being a big deal. They had to change the name, so they picked SubEthaEdit. It was shareware for a while and then they went full commercial with a 30-day trial period. There were some things about BBEdit that I didn't like, and as importantly, I wanted to like SubEthaEdit. So I gave it a spin.

I liked the syntax highlighting a lot better than BBEdit's. I liked the collaboration, though I have to admit that I've never really needed to use it. Probably most importantly, it looked more like a Mac OS X app as opposed to a converted Classic Mac OS app - which is where BBEdit originally started. There were a lot of things that I thought could be better, and my philosophy has been - if you want to ask for more, pay for it. So I did. And then I sent in the requests.

Things got a little better, and now with version 3.0 several things have gotten a lot better. The speed of syntax highlighting is vastly improved. They have added the ability to save an editing session with all the meta-data so that it's easy to pick up where you left off. They also added SSL encryption on the communication so that you can edit in secret. Nice features, to be sure. And while I appreciate that they are not interested in making a bloated package, there are a few things that I'd still like to see:

• Fix the method signatures in the method list - this is a complaint I have with BBEdit as well. Both apps have a touch time getting the method signatures right. This is a big deal when you're trying to quickly find the method you need to work on. If I have a C++ file with 10 different add() methods, it doesn't help a lot to see 10 add() entries in the list - I need to see add(int) and add(double), etc.
• Allow for marks to jump back to - this is one place where Vim beats BBEdit and SubEthaEdit - the ability to set little marks, go somewhere else in the code, do what you need, and then jump back to the place you left. BBEdit is close with it's Marks, and I've added the key-combinations to make it easy to set them, but jumping is still a mouse-driven process. I'd love to be able to use the keyboard alone. SubEthaEdit doesn't have the feature at all.
• Allow Page-Dn with the cursor - most editors allow the user to 'page-down' the file with the cursor by hitting some key combination. BBEdit does this with Option-<Arrow> and SubEthaEdit allows you to page-down, but you don't move the cursor. It's a mouse action to do it in SubEthaEdit.
• Fix the highlighting of -1.0e-12 in FORTRAN code - I submitted this bug a while back and they didn't get around to fixing it. The problem is that for the number 1.0e-12, their C++ highlighter works wonderfully, but their FORTRAN highlighter colors the '1.0' as a number, the 'e-' as text, and the '12' as a number. It needs to be consistent. Also, both their C++ and FORTRAN highlighters miss the leading minus sign ('-') on negative numbers and color it as text as opposed to the numerical constant. It needs to be tagged and colored with the number - not as text.

The thing is, I still want to like it. I want it to get better. So I get the upgrades, pay the money and send in the requests. After a time, maybe they'll see that I'm serious about supporting them and get the few little features that I keep asking for. I can't think of another way to make it happen, and I'm pushing on BBEdit the same way. I have no desire to write my own, and if BBEdit and SubEthaEdit don't turn out, I can go to Vim and be happy enough, but I want a Mac experience in my editor, and one of these guys is going to get there. I hope.

UPDATE: I figured out that the FORTRAN syntax coloring problem was in the Fortran77.mode file that I got from them - but was not a built-in syntax mode in SubEthaEdit. This meant that I could edit it and fix all the syntax colorization issues without having to wait for them to fix them. So I did. I fixed several problems, in fact. In the end, I went to the bug tracking system and updated the bug entries saying I had solved it. Unfortunately, I was unable to upload the changed Fortran77.mode, but I left a note there for them to contact me if they wanted me to email it to them.

I was taking a break this morning, trying to get rid of a headache that is really killing me, waiting for the Advil to kick in, and was thinking about the fun games that have really held my interest for a long time. There aren't many. But what has kept my interest are the really great games that I've been playing for a very long time.

Risk - this classic board game is a pain in the neck to play with people because if you don't have a good group of at least 5 people, it's not really that fun, and can really get quite annoying if you have a few people that don't even try to play the game. Thankfully, there's iConquer on the Mac which is a superb version of Risk with decent, though not really super challenging, computer opponents. It's a great for 15 to 20 minutes, but if you want a real challenge, you're going to have to play against something with a pulse. They have network play, but again, there's the need to get 5 good people together.

Xconq - this classic adaption of Empire is about as fun as strategy/turn-based games get. There have been a lot of these in the 'bookshelf' games over the years, but again, since this guy has pretty decent computer opponents, it's a great way to spend about an hour. Unfortunately, they are dropping the native Mac OS X interface from the project, and it's even questionable if anyone is supporting it any longer. It used to be worked on by guys from Apple and RedHat, but it's gotten away from these guys and into the general SourceForge community. I haven't received a message on the mailing lists for a very long time. Still nice, so long as I can get it to run, but there will come a time it's dead, and that will be a sad day.

ChopLifter - this has been on Apple ][, Sega, Mac OS X, and probably a dozen other platforms as well. It's the classic 'rescue the guys' game and fun for about 10 min. After that, I get a little bored and my interest falls off. It's fun enough every now and then to hold my interest for those 10 mins., but I can't say that I really look forward to playing it - it's just "there", and I play it for a bit.

I've played a few FPS games - no real interest. Networked games are nice, but only as a way to get those critical people together. I guess I'm just Old School - or just Old.

Whew!

It's been a week.

Pretty much all this week I've been heads-down coding this 'infinite' precision floating point number first in Java and then in C++. There were a lot more issues to deal with than I had expected to run into in this little class - face it, it holds a number, adds, subtracts, multiplies, and divides. That's it! But, boy-o-boy, there's a lot more to just that than it sounds.

I've talked about a few of the issues in the post I made after the Java version was done. But then the conversion was pretty easy for many things, but had quite a few gotchas in the C++ codebase. Little things like clearing memory on creation - thought that was covered, but then I realized No, of course not... and had to fix that. Then there's the locking scheme - mutexes are great, but it's nice that Java allows the same thread to "relock" a section of code without blocking. I'm guessing that I could probably do the same thing on the CKit's mutexes, but it might be a bit dodgey, and so I may just hold off on that idea.

The Java class was 2442 lines, and the C++ was over 3700. Lots of comments, or course, but still... that's a ton of coding for a week. The test apps were another 390+ lines each - so I was plenty tired of typing by the time I got the C++ version ported along with the test app.

I'm glad it's done and all checked in.

As an aside, this all started from a problem a developer came and talked to me about last Friday. Since then, his initial work-around failed for one condition and others put in their $0.02 to say that they didn't think it would be that hard to do. Silly people... If I spent a week on this then it's hard. Impossible? no. But it's a lot harder to get right than most people think. I know it was a lot harder than I thought it would be. I figured a few hours for the Java version and then a few more for the port. I should have thought "days" as opposed to "hours". Glad it's done.