Archive for October, 2007

Adding the Ability to Customize the Legend in Graphs

Wednesday, October 31st, 2007

comboGraph.png

A developer came by today to ask me if it would be possible to add the ability to change the foreground and background colors on the Legend in the BKBaseGraphApplets. Also, he wanted to know if it would be possible to remove the border. Basically, he didn't like the grey background and the 3D border and wanted something that seemed to fit in the same plane as the graph itself. Seems reasonable, and after doing it, it actually looks reasonably nice.

Anyway, the work wasn't that hard - took me about an hour for the whole deal. But an interesting part was that you had to disable the 3D effect on the legend in addition to disabling the border. Seems the two are different visual objects. Nice of them, to add that level of customization. For now, however, turning the thing off or on is good enough.

Comcast and FTP

Wednesday, October 31st, 2007

I'm glad I no longer rely on Comcast to serve up my web site. They recently decided that the FTP TLS/SSL was no longer "necessary", and have removed it. Maybe it was part of the 'upgrade' they did, but in the end, it's gone and my tools are some lame web site uploader or unsecured FTP. If I have to put something up there, I guess I'll go the lame uploader, but I'm stunned that a group so intent on security to give away anti-virus software and spam blocking is not coming up with a better solution for secure FTP uploads.

Maybe they think all their people are too dumb to know. I'd hate to think that, but I can't come up with a reason to drop secure uploads via third-party apps. I guess I'll check back later and see if they have something - or maybe write them and see if they respond. Not that I'm expecting anything, but if you don't complain about poor service, you get exactly what you deserve.

UPDATE: OK, I sent a nice email to them asking for something - WebDAV with SSL might be very nice, but I'd take FTP TLS/SSL back. We'll see what they say.

Their response was almost automated:

Thank you for contacting Comcast Cable Bob.

I understand that you would like to have the option returned to allow FTP TLS/SSL for secure uploading to PWP from third-party FTP clients.

I have forwarded your comments to the appropriate members of our development and management teams for further review and action. We appreciate that you took the time to help us keep our commitment to quality customer care.

I do not really expect them to do anything about this - they have the silly web uploader, but if you don't ask for it, they'll never know that taking it away pissed off at least one somebody.

The State of Java on Leopard

Wednesday, October 31st, 2007

java-logo-thumb.png

Well... it appears that the current Java 1.5.0 on Leopard is not all that great. Add to this that there's not even a pre-release version of 1.6.0 available for the early-adopters to use and it makes a somewhat compelling argument to hold off on Leopard for at least a little bit until Apple releases the 1.6.0 JDK. I'm sure it's coming, Macs have been for the last several years the Java development platform. But with the fact that 1.6.0 never fully materialized for Tiger (10.4) and that it's not in Leopard (10.5) - yet, it makes those hard-core Java-types say that Apple is out of touch. After all, Windows uses the Sun-provided JDK and Apple insists on writing it's own.

But let's recall a few things folks... with Mac OS X 10.3 and JDK 1.4.2 Apple made the apps load very fast and run even faster. So much so that Sun asked to have a look under the hood to see how they did it. With each successive release of Mac OS X the bar has been raised. Unfortunately, right now, 1.5.0 is almost two releases back and 1.6.0, while not widely adopted, is widely available for a long time.

It's a matter of timing. I'm sure that within a few weeks JDK 1.6.0 will be out on Leopard and it'll be once again setting the standard for Java development platforms. There are just those that are hearing all the hype and cheering from the new release that they need to put it all in perspective - which isn't a bad thing, as long as it's not use to just knock things down.

Leopard is fine, it's new, and it's got a lot of differences, and I'm still waiting for PHP and PostgreSQL for 10.5 to be available from Marc Liyanage as they are the best packaged, fullest-featured, versions of those tools. When he's got time to update them, I'll move to Leopard. I'm guessing that by then I'll be updating to JDK 1.6.0, or soon after. It's just a matter of a few weeks. Have a little patience.

UPDATE: interesting note about Java on Leopard... is seems like the guy got a lot of press for whining about a specific application instance. In general, it's better and faster, but there may be times that you have to actually code against the defaults to get optimal speed. In any case, one less thing to worry about with Leopard.

Expanding PList Capabilities to BKHashTree

Tuesday, October 30th, 2007

BKit.jpg

A very long time ago I put in a simple plist reader to the BKHashTree so that I could read in the plist files off my Mac OS X system into a map of maps, as the BKHashTree is, and display them in a nice graphical tool that I was building. The GUI widget I created has found a lot of use in the code I've written over the years, and when talking to a fellow developer late yesterday it was clear that what we might really need was a full-featured plist reader. I remembered something about this, looked it up, and sure enough, I had the basics of this already coded up. While he had found something that looked to have all we needed, it had somethings we didn't need, and I wanted to take a shot at cleaning up the reader I'd made, add a writer, and augment the data types allowed in the plist file.

The first thing that was missing in my code was the list/array element. Basically, we wanted to be able to provide the user the ability to specify a list (Java ArrayList) of elements as simply as possible:

    {
        names = (Bob, Fred, John);
    }

It was pretty easy to see that the simplest way was to process the array as a single argument (value, in this case) to the routine that I had that picked the correct object type of the element and made it available for placement in the Map. This worked for a while, but pretty soon I ran into serious limitations. What I needed to realize is that the array processing is very similar to the map processing - just with a series of values as opposed to a series of keys and values.

This was a major simplification in the code. I had a map processor and an array processor and they called each other. Should one of the elements of an array be a map, it passed control over to the map processor, which returned a Map to place in the array. Likewise, if the map processor hit upon an array it sent the code over to the array processor which returned an array that would be used as either the key or the value. Very nice. It was only at the very lowest level that we needed to look at the elements and determine the data type they were.

The next thing to do was to add in the URL and binary data types. The URL was pretty easy - it's a string with '://' in it and no spaces. The binary data was a string starting with '0x' contained within <> like this:

    {
        password = <0x347ab0ef21>
    }

There's still the limitation that there can't be a space after the '<' and before the '0x' because the BKData needs to look at the string it's given as starting with '0x', but that's something that I can fix without too much trouble - should it become a real issue. Right now, I can't imagine what we'd use the binary data for except passwords, and those we wouldn't be hand-edting because they'd probably be encrypted or at least Base64'ed.

The final thing I worked on today was the writing of the data and while the writing itself was easy, making it look decent when written wasn't. I tried to balance the ideas of putting individual items on a different line and making it look more readable by putting small arrays, etc. on the same line. I know it's not perfect, but it's very readable now and that's enough. It's not meant to be a beautiful output- only functional.

This all got started because we wanted to have a distributed Preferences system in Java that didn't have the current limitations that the current crop of Preferences Factories has in Java. More on that tomorrow.

Initial Leopard Reviews

Monday, October 29th, 2007

Apple-logo.jpg

This morning a ton of reviews are out and, as I expected, all over the map. There are install problems and people with the same hardware with no install problems. There are people loving the new interface and others hating it for the same reasons. There's no way to please everyone, but Apple has done a good job by all accounts, and an excellent job by some.

The Ars Technica review is nice, balanced, reporting of the pros and cons that you can expect to see in the first week of use. Even they agree that there's no way to review an OS in one shot, so they look at the high points. Fair. They spend more time than I would on the visual elements, but that's what they do, so no big deal.

There have been a few others that I've read that are totally taken aback by one little thing that they state they'll refuse to use it. The Dock is a lightening rod... Java 1.5.0 is another... Ruby is yet another. I mean really people, is this all about one little feature? Sure, it'd be nice if they had made it easy to change the Dock's visual appearance, but they did allow you to revert it in the defaults system. Sure, it'd be nice to see 1.6.0 on Leopard, but they have 1.5.0 and there aren't that many apps/applets/servlets that I've seen that require 1.6.0 because it's not really that widely adopted yet. Sure, they added Ruby on Rails, and it might have been nice to put in the very latest Ruby, but they went for stability.

In all these cases, people are mad because their pet project or tool isn't as well supported as they had hoped. Given a little perspective this list isn't bad. Java will be updated, Ruby will be updated, life goes on. I'm just sifting through all the reviews looking for real issues that might make me delay my conversion more than a few weeks.

Leopard-specific Updates To Do

Monday, October 29th, 2007

Apple-logo.jpg

I'm getting ready for the update to Leopard (10.5) and while I'm updating all the apps that I have before I update Leopard, there are some that need to be updated after. Here's my list of things to update after I get Leopard on my laptop.

  • Forty-Two DVDVX Plus v3.2 - this is the nice DVD ripping software that has made it so easy to get a few of my DVDs into iTunes for the road. They are saying that version 3.2 is for Leopard only. I'll wait for this as I don't have any ripping I plan to do in the near future, and if so, I can wait until after the upgrade to do it.
  • Lingon - this is a launchd GUI tool for Leopard only. I've not used it a lot on Tiger, but in the event that I need it, it's been there. Typically, I just get down into the files and restart the service, but it might be helpful if I come across a need.

As I find more things to add to this list, I'll expand on it. For now, it's a placeholder of the specific updates I need to do and that's good enough.

Technical Salespeople – What a concept!

Friday, October 26th, 2007

cubeLifeView.gif

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.

Interesting Edge Conditions on VantagePoint Graphs

Friday, October 26th, 2007

comboGraph.png

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.

The Final Days at a Job

Thursday, October 25th, 2007

cubeLifeView.gif

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.

In the end… Vim is Amazing

Thursday, October 25th, 2007

vim.jpg

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.