I have a spreadsheet in Appleworks that I'd like to give out to a few people. Appleworks won't save it in an "open" format, but I can export it to a Microsoft Excel file. Alas, that incurs some minor corruption in some of the formulas. Since I don't have Microsoft Excel on my system (any of 'em), I can't load it up in that to fix 'em.

The folks I want to give this spreadsheet to generally use OpenOffice. As this spreadsheet started life as a StarOffice document, I figured having the up-to-date version in the Microsoft Excel format and the original in the StarOffice format would provide enough information to correct the corruption due to the exporting of this file to Microsoft Excel.

It seems OpenOffice doesn't read StarOffice files.

Bad developers! No biscuit!

Okay, I suppose I can install OpenOffice long enough to do the fixup, with the added bonus of being able to provide the spreadsheet in an "open" format. Since I'm using a Mac, the recommendation is to use NeoOffice.

So I go to download NeoOffice. They want a donation. I want to try before I buy, so I skip that bit. It's in a DMG, yay! Mount... and it's a freakin' PKG installer. WTF? Well, maybe it'll let me install it in /tmp or something. No joy... it demands the Administrator password.

Bad developers! No biscuit!

There's zero reason for an _application_ to require the Administrator password. I consider an application installation process that requires an Administrator password -- especially on the Mac, where run-from-the-DMG-file is almost a standard -- to be a sign of incompetence, arrogance, or carelessness on the part of the developers. Laziness is a virtue, but only sometimes.

And they wanted a donation?

No way. Not until they demonstrate a little professionalism and provide me, the user, a reasonable installation process.

Of course, a reasonable soul might point out that there's nothing wrong with a PKG installer, since Apple ships the PKG installer builder tool as part of the "standard" development suite. And they'd be half-right... the problem with PKG tools is that it doesn't do the right thing and allow the user to choose where and how to install an application (no matter what the developer does or doesn't do). Apple developers dropped the ball here.

Bad developers! No biscuit!

Sometimes folks wonder why "the average users" get so annoyed at developers. This is why. We have a tendency to take reasonable choices away from the end-user, instead of building our tools (especially our installation tools) to preserve the user's sense of control over the hardware that they've paid for and use on a daily basis.

So here I am, wanting to get a good set of Solaris 10 installation disks, and not wanting to go through the bother of downloading and burning a set. "No problem," thinks I, "I shall simply pay the $35 and order a media kit."

Sun's web-pages suck.

You'd think that a company with so many talented designers, engineers, graphic artists (you have to admit, their logo is cool and they have a very good eye for color), and so forth could manage to come up with a usable website. But noooo....

I suppose that $35 could be selling at a loss for them, and selling onesies and twosies isn't worth the cost or infrastructure -- but why then offer to sell it to me anyway? What's the use of teasing me by offering to take my money, and then going through all sorts of effort to make it difficult?

No wonder they're in trouble.

Update

Yay Sun!

They fixed it. Or I found an alternate approach at http://www.sun.com/software/solaris/ that worked. For free. And the media kit arrived in just a couple of days.

Of course, it's a DVD, which means I have to go juggle hardware now....

So there I was, with too many open projects, contemplating the purchase of a 160GB 2.5" Seagate Momentus drive. This laptop needs more storage, so why be stingy?

A little bit of poking around, and I end up at the ProVantage website. And there they clearly point out that if I want to offer to give them money, I must disable my Javascript-stripping proxy and enable Javascript in my browser.

Nice of them to be so clear about it. It saves me a lot of time and aggravation, plus, since I won't do that, it saves me all that money. I mean, if they don't want my money, that's fine with me, I'm sure I can find something else to spend it on, and it's not like I don't have sufficient projects to consume my time anyway.

So it's a big thank-you to provantage for not wanting to take my money.

Must be nice to be so flush you can treat customers like marks.

Where we left off: I wanted a remote for my JVC TV, and I discovered that the JVC website sucked.

But that's not the end of the story.

I still wanted a remote. I googled for the TV's model number, and got a couple of hits that claimed to have the remote for my TV. I went with the less-reliant-on-Javascript site -- PartStore.com -- and by searching on the TV's model number, I found a remote that was "compatible".

Yay.

"Compatible" ought to be good enough. All I really need is a way to navigate the menu so I can change aspect ratios and suchlike without having to stand next to the TV. So I order one.

It arrives in just a couple of days. Far faster than I expected.

Yay again!

So I unpack the remote, verify it's what I ordered, and go to try it out. It's even a JVC remote.

"Compatible" obviously means something different to the folks at JVC. There's virtually no useful feature of my TV that matches up with this remote.

A quick email to the support address and I go to bed, annoyed and frustrated. I am not a happy customer.

I get back a response informing me that I should call the toll-free support number. This I do.

And this is where the story gets short... after a couple of minutes on hold, I am on the line with a real human being. A helpful human being. He determines that yes, I did get the wrong remote for my TV.... and takes care of it.

I'm feeling like a customer. It's amazing. I was expecting to be told I was SOL, that the Computer Does Not Make Mistakes, and so on and so forth, and to end the evening in a lousy mood and a worse temper.

It's almost a let-down. Problem taken care of. End of problem. Finis.

The new remote arrived in two days. It's exactly the remote I need. As a bonus, it also can control the JVC VHS deck. (The remote that came with the VHS deck died. The universal remote isn't. But this one works. It's a bonus.)

This kind of service needs to be encouraged. I'm now wondering what other parts I need. They'll be the first stop.

But I won't use their webpage to order. I'll call to make the order.

And I'll ask for Don.

(The one downside of this is the FedEx website. Javascript Is Required, or you have a ton of manually parsing some convoluted javascript and source. Someone should take a stick to someone's kneecaps and knuckles over at FedEx.)

Well, it turns out I need a replacement remote for my JVC television. The so-called "universal" remote can just about power the thing on and off; I still need to go up to the TV and use the "menu" interface to change the aspect ratios. This is tedious and error-prone and distracts from the movie-watching experience.

"No problem," I say to myself. "I shall go to the JVC website and purchase one."

You can see it now, can't you? What a silly boy I am. I get to the JVC website, and it looks pretty, but I can't get it to do anything useful. No doubt I'm expected to "have an experience", but I can't see how that would benefit anyone if they don't make it dreadfully easy for me to part with my cash. I want to have experiences using their product, not their website.

I wonder what sort of thinking goes on in businesses these days. Has no-one pointed out the futility of having a pretty website that doesn't work for their customers?

Or do they expect that frustrated and annoyed customers are going to spend more money, and go around telling people (even strangers) how great their company is, than happy and satisfied customers?

What alternate dimension is this, and how did I get here?

So far as I am concerned, the goons in the TSA are thieves and vandals.

It's either that, or they're incompetent.

If you travel enough, you might begin to see a pattern. Stuff disappears when TSA gets involve -- not the expensive stuff, necessarily, but little things. Things that may only have sentimal value. And stuff gets damaged. Not everytime, surely, but at a high enough level to be aggravating.

I'm not saying that all TSA employees gleefully vandalie the contents of suitcases, or steal trinkets and suchlike from duffel bags. But it seems that some do, and the rest apparently don't care. Trying to report this sort of thing puts you into a voice-mail hell, and contacting a human tends to result in a "so what?" attitude.

(The alternative, that the TSA inspectors are, in general, incompetent to pack suitcases, brings up a worse issue -- if we're hiring incompetent goons for security, how does that make us any more secure? Assuming incompetence has far scarier implications... I don't want to go there.)

It's preposterous that by travelling, we should be expected to give permission for some faceless cretin to damage, steal, or lose our possessions, despite all the money we spend buying quality luggage to protect those possessions.

I think we need some basic rights back in our travel. Nobody, but nobody, should be allowed to search your possessions without your presence, and if they damage your possessions, they should replace them and be penalized for the damage. Automatically. Making someone run a bureacratic gauntlet is just another penalty for daring to complain. And that's just wrong.

Well.

It seems that thinkgeek has a laser-keyboard widget. Yay! There's one problem taken care of right there.

Alas. There's still no way configure it with a non-Microsoft OS. Custom drivers still required, it seems.

But... it's looking better. Maybe the next version of OS X will fully support this sort of device naturally. We'll see.

Well.

Some time ago, Microsoft didn't think things through, and introduced a bug into Outlook that caused problems if you used the word "begin" and it happened to end up at the start of a line, followed by a couple of spaces. As they redefined the world in their terms, they called this an "attachment", and this caused problems.

See http://lists.jammed.com/ISN/2002/02/0042.html -- essentially, the Microsoft "solution" was to stop using the word 'begin', or to capitalize it no matter where it was in the sentence. Instead of fixing the bug, they tried to change the language.

That just pissed me off. I started using "begin quoting..." as an attribution line. This pissed of some people, but they weren't generally willing to file a bug report... so screw 'em. Others started pissed at me, but got pissed at Microsoft after discussing the issue. A brief search, and I found someone actively trying to get others to join in at http://www.ichimusai.org/oe/.

However.

It seems that Microsoft finally fixed the bug: http://msmvps.com/blogs/spywaresucks/archive/2005/06/18/53813.aspx

Huzzah!

I want one of these.

But I can't have one. First, not available in the USA. Wah! No explanation given. Oh, well, there are ways around that.

But.... it requires M$Windows to install drivers on PDA. Wah! I don't do MSWindows, and I do my damndest not to do business with companies that demand that I do do MSWindows.

It's not like I'm picky -- I have several Macs, several Linux machines, and several Solaris machines. I've successfully purged the microsoft operating systems from my home network (for usability, stability, and security reasons).

Bad vendor. No biscuit.

Well, SCALE was interesting, educational, and fun.

The CA Cert folks had a booth, doing a brisk business in verifying identies. Nice guys.

The panel on OpenVZ was interesting, and the product seems to have quite a nice feature-set. And the logo is just gosh-darned cool.

Hans Reiser talked about Reiser 4, mostly about performance and efficiency... stuff I regard as interesting in an abstract way but not so really important for home use... and had a short digression into the elegance of the design, which *is* important, as that has a strong bearing on maintainability and stability, which are important for home use.

And then in response to a question at the end from jaqque (easily the best question of the presentation, in my opinion), talked a little bit about views and masks. This is Way Cool stuff, and is certainly a reason to look at Reiser4.

The most impressive panel that I attended was about using dtrace for debugging linux applications by running Linux under OpenSolaris using the BrandZ container.

Every developer should look at what dtrace does, and how well it does it, and then ask themselves why they don't have a solaris or opensolaris box -- Sun put an extremly powerful tool into the hands of developers, it should be used.

Every administrator should look at what dtrace does, and how well it does it, and them ask themselves why they aren't running their critical services on a solaris or opensolaris box -- Sun put an extremely powerful tool into the hands of the administrators, and it should be used.

If managers aren't getting demands from their developers and administrators for (open)solaris machines, they need to point their developers and administrators to dtrace.

Oh, and there was a toaster running BSD (NetBSD I think) on the exhibit floor.

My wife and I were given TurboCAD as a gift -- mostly because we keep talking about remodelling the house, and bashing out the various ideas takes a lot of paper.

What are my impressions? Well... I haven't gotten very far, yet, but already I'm forming some significant impressions: The installation process is hindered by copy-protection and mandatory registration. You have to let the software vendor (IMSI or somesuch) snoop on your system. Well, okay, just once.

I don't object to paying for software (I rather approve of the idea, considering), and I realize that a lot of people out there do, so a reasonable level of care is okay. But I had a sneaking suspicion. . .

So I installed it on our (shared) Mac Mini. I logged in as the administrative user, and did the registration-all-of-our-customers-are-thieves-and-scum dance... and then tried using it. Whoops! It's not REALLY installed, I have to type in an obnoxious string. And then my wife tried using it, and look, here it is that dialog again! Then me... and again! WTF?

In short, the copy-protection mechanism is designed to be unfriendly and obnoxious. We'll have to see if they get any worse, but considering that I tried to find a place to leave feedback on their website, and noticed that "support" costs $1 per minute...

Y'know, I like recommending software to friends and acquaintances. I like telling folks "Hey, here's a good program, go buy it." I've barely started to use this program, and already, I can tell I won't be doing that with TurboCAD. I'll be telling people to go find some other software -- just so that can avoid the experience of paying for software broken in such a deliberate and fundamental manner.

Features? Who cares? This is the sort of treatment that customers should absolutely not put up with. And calling to complain will cost me $1/minute? That's a disincentive for me to call and a disincentive for them to provide me with actual, reasonable, timely support.

Something to look for boys and girls: if it says IMSI on the box, put the box down and go get some software from a vendor that doesn't despise you. Or at least one that doesn't shuffle the task of copy-protection off on to the least competent programmer in the house.

This is why open-source software will win -- given a choice between this and free-as-in-beer-and-won't-treat-me-like-scum software that does half the job in twice the time using three times the resources, it's a no-brainer. I'll take mutual respect any day of the week.

Interesting problem this week...

It appears that one cannot connect, via JMS, to two separate Weblogic Appservers. At least, I have code that can connect to one, the other, but not both at the same time. So far I haven't found any documentation the describes someone doing just this (but then, the Web often hates me).

I have found a description of talking to two JMS servers at once, but they used a common JNDI service, which is cheating a little bit.

Very odd...

I just ran across an article on the evils of cut & paste, and I find my reactions mixed. I don't recall reading anything by Jef Raskin before, but he seems to be an articulate guy, and his argument stands by itself.

He starts off talking about UI faddishness, which I agree is a problem, and then discusses the problem with cut & paste. Namely, it's a bad idea, because while something's cut, you don't remember what it is, and you're likely to lose it.

To me, this borders on calling the user stupid, which seems a bit strong.

He then discusses the "often-proposed fix" of select-and-drag. He then discusses the problems with select-and-drag, and uses that to introduce an example of a "classic mode error".

Now, although I loathe select-and-drag, I haven't made this 'classic' error he refers to -- when re-selecting text, I first select some text, or click in the background, or do something to unselect the text. Handling the modes of "no selected text/have selected text" isn't really a problem for me. I have, however, accidently selected and then moved text (click-and-grab to move, except that the the click accidently strayed into an area where 'select' was an option), which is one of the reasons why I don't like select-and-drag.

Anyway.

He then goes on to describe his preferred solution -- the 'move'; that is, the selection doesn't go away until the new insertion point is specified. He goes on to point out that he's eliminated one command -- you use a move, instead of a cut AND a paste.

Well, sorta.

First, I don't buy the modes-are-always-bad line of thinking. Too many modes are, but no-modes/one-mode are almost just as bad -- there's a happy middle ground in there somewhere. But that's a different rant, for another day.

Second, then, is that it's not necessary that the buffer used in cut & paste be "invisible". For a long time, I used a tool called xcb (the X Cut Buffer) that allowed me to look at what I had cut. It also allowed me to keep several cuts on hand, so a new cut wouldn't necessarily cause the previous cut to be lost. The only problem with xcb was that it took up screen space, and there was a tradeoff in sizing the buffer display large enough to be useful, and small enough to stay out of the way.

But this leads us to consider some other possible solutions. The buffer doesn't have to be invisible. Multiple buffers can exist to be selected among, and/or a stack-approach could be used to keep all buffers around. After all, most of the time, you don't forget what you just cut.

Third, the 'move' command "solution" doesn't eliminate a command from your toolset, only from that one operation. You still need a command to cut-and-discard, and you still need a command to duplicate a chunk of text. When programming, we sometimes talk about the "minimal necessary set" and the "minimal usable set" of functions.

When you build an API, you want to keep in mind these sets. Otherwise, you clutter up your API with a bunch of convenience functions that do what you could do with only a little more work. The cluttered API is harder to learn and harder to use than a simpler API, especially for those who aren't experts in that API. Even those who are moderately familiar with the API will have to spend time looking through the options to find what the "best" way is.

When we edit text, we want a way to delete a chunk of text. Backspacing over a whole page could do the job (minimal necessary set) but being able to select-and-delete saves a lot of effort (minimal useful set). Likewise with copying text. We could just type it in again (minimal necessary set) but a paste saves us a lot of effort (minimal useful set).

So our "useful" set of commands for editing text provides a delete and a paste (select is implied). If we paste the most recent selection, we get our 'move' functionality for free, and our commands work on a very simple and consistent model.

If we add in our 'move' command, it looks like a more complicated version of what we can already do: select, paste, delete. If we choose to force our users to use the move command instead of the cut & paste sequence, we can say that the delete command discards the most recent selection entirely, and our user now needs to remember three commands instead of two.

Ah, that's only one more command! Where's the problem?

Not there, not really. But if every sequence of useful commands is replaced with its own command, we have done the user a disservice and made their life more complicated than it needs be.

That being said, I don't dislike the idea of a move command. I think it's a much better solution than select-and-drag, and I would use it in preference to select-and-drag (although I wouldn't avoid cut-and-paste as well, just select-and-drag). But a better solution yet would be to have a non-invisible buffer-stack, as that offers up new ways of working on certain problems, and doesn't presume that the user is an idiot.

IMNSHO, of course.

Recently I had an interesting discussion about version-control features. One feature that's frequently brought up is "file renames", and that's a feature that I just can't seem to see my way to considering all that useful.

First, if you're renaming a lot of files, it means you didn't do much thinking about your code before you started. As that seems to be the way of things these days (thinking ahead is hard and should be avoided, it seems), however, that's hardly much of an objection.

Second, how do you puzzle out cycles?

Consider a version control tool -- vct -- that supports a "rename" capability. And further, consider two files, A, and B, that might be renamed.

% ls
A B
% vct rename B C
% ls
A C
% vct rename A B
% ls
B C
% vct rename C A
% ls
A B
%

We've just swapped two files. When we look at the history of "A", do we see the thread back to B, or do we see that A was removed and later replaced with B? It seems that BOTH bits of information are important, depending on the question being asked.

Lather, rinse, repeat. The history becomes terribly convoluted. Obviously, we need a "swap" capability as well. . . which leads us to:

Third, a file rename is only the simplest form -- what about splits, swaps, and refactorings?

If we buy that renaming is an important operation for a version-control tool to support, we can't stop there. As we've seen, a swap operation CAN be composed of several renames, but that's not efficient. Therefore, we're compelled to clamor for file-swap support.

But it doesn't stop there.

More often than file renaming, we have splitting. A file gets just too big, or perhaps it encapsulates two relatively independent concepts, so we split out the functions/methods/whatnot into two or more files. You don't necessarily rename the file, you just copy it and delete all the bits out that are in the other file, and vice-versa. We record this in the version-control system by saying something like "Extracted -related methods into ." -- obviously, that's not good enough. We need to add in an "extract" capability.

Along those lines, there's the refactoring operations that ought to be supported. Many refactorings are along the lines of "extract code", and surely this should be tracked by the version-control tool explicitly, rather than relying on the user to remember to correctly document what was changed and where. Some of the 'extraction' operations aren't quite that simple, however...say, the extracting of an interface from a class.

So the various refactorings need to be supported. We can see that "extract_interface", "extract_superclass", "extract_abstract_class", "push_method_up", "push_method_down", "move_method", etc. etc. will be capabilities that need to be programmed into our version-control tool. And since the list of possible refactorings isn't all that static, we'll want to have a team to keep up with the refactoring community so that the version-control tool can keep up. Or we make our tool pluggable so that all someone needs to do is to write a plug-in to handle the NEW sort of operation.

Of course, the tool is now so awkward and difficult to use, we'll have to invent a process to manage everything. Otherwise those pesky developers will just go back to making changes and annotating what they did when they commit their changes, rather than using the many useful options our tool provides them.

We'll have to do something about that.

One of the ways to divide the programming community up is to consider the role of proactive and reactive coding philosophies. That is, do you look ahead and try to guess the sorts of changes that you may have to make in the code, or do you worry not at all about such things until the time comes to actually make the change?

Critics of the proactive approach (and generally proponents of the reactive approach) often sneer when asking if it's actually possible to see the future. Crystal balls are a favorite metaphor. Eventually, someone talks about "programmer efficiency" and the "inevitable" requirement to 'back out' a generalization or an abstraction.

Critics of the reactive approach (and generally proponents of the proactive approach) scoff at intractable codebases and point out that rewriting everything is only suitable for trivial problems anyway. The phrase "highly coupled" may be heard.

Like most things, a balanced approach is probably best. Somewhere in the middle -- where we peer into the dim future with the lenses of past experience to choose a path (but not rails).

I believe that one's experience has a strong effect on which stance we generally disapprove of least. If we've been burned by Process, or vacillating customers, or non-existent requirements, we're going to have less objection to the looser, more reactive approach. If we've been burned by trying to maintain code written by people who know they won't be the ones to maintain it, and who eschew structure in favor of "make it mostly work then ship it", we're going to have less objection to the more constrained, deliberative approach.