Friday, November 28

orm lies

[Edit: when I originally wrote this, I was frustrated.  Looking back, I do not completely agree with how I expressed these ideas -- I think they have validity, still, but I doubt they convey that validity to the reader.   For the moment, though, I am going to limit myself to appending patches for what I think are the worst of the problems, in bracketed comments.]

ORM seems kind of neat, but it seems to be based on some lies [or, probably: mistaken understandings].

A fundamental lie [mistake] was espoused by C.J.Date (but I can't find his book where I read this): that you can not properly implement a relational database in an object oriented system.  

Here's an OO description of a relational database system:
  • A row encapsulates a table and an index into that table.
  • A table is a named collection of columns which all have the same length.
  • A column is an array of items which all have the same type.
How about the other direction?

Well, since a RDBMS has a specific object model, we probably should not expect that casting all objects into that model will be a good thing.  The whole point of an RDBMS is to organize data in a regular fashion, so efforts to use an RDBMS without organizing the data seem ... pointless.

That said, one of the objections raised about RDBMS has to do with the lack of support for encapsulation.  But in any decent RDBMS you have security which can disallow access to any part of the system.    Objecting that the administrator can have full access to the database is like objecting to the use of debuggers that can see private data in an OO system, or to the use of programming tools that can edit the private structure of a class.

Don't get me wrong -- SQL does not provide enough abstraction -- but given its relational roots I believe that that abstraction should have a certain character, and "object oriented encapsulation" doesn't really focus attention on the right areas.  But that's fuel for another rant.

Wednesday, October 29

not not cached?

I use google's search features quite frequently.  And, more often than not, I like how their system works.  But sometimes I want to say "do not show me any hits unless you have cached copies of them".

Paging through screen after screen of google "hits" where most of them are useless to me (where I would need to pay money just to inspect them to see if they were relevant) gets old.

One of these days, I am going to write some browser side code that scrapes google's search results for hits with cached (or alternative html) results and discards other hits.  I've been meaning to spend some time picking up grease monkey, maybe this will motivate me.

Meanwhile, I will note that uncacheable hits almost never contain the text I was searching on, which is supposedly against google policy.

Wednesday, October 22

X is a Y!

Any time you see a sentence of the form "X is a Y", the narrative has turned into a dictionary exercise.


Tuesday, October 21

Vista has a "nifty new feature" where you can adjust the volume of each application independently.  But Microsoft's implementation of this "nifty new feature" is so bad that it could cause hearing loss for some people.

Essentially, you have two volume controls for each application.  First off, you have a "device volume" which is the volume control for your audio device.  Every application shares this volume setting, and this volume setting persists across reboots.

Second off, you have a "per application volume" which is different for each running application.  When an application starts this defaults to 100% volume, and if you adjust this it's typically not saved across application reboots.

The UI that microsoft presents gives you a sliding volume control for each of these volumes -- one for the device and one for each running application.   The running application's volume control is depicted as having the potential full range of volume of the device.  If you adjust the application's volume above 100% the device volume gets adjusted upwards to make this work.

The problem, unless you have really awful hardware, is that to get good dynamic range from your sound system you need to have the device volume set high and rely on the application to keep sounds mostly quiet.  If you do this, you can get really nice quality sound.

But if you do this, other applications [and windows itself] can be so loud that they can damage your hearing.  And if you try turning off windows sounds you will still have a "beep device" which runs at full volume.  And you can disable that device if you try hard enough, but some later windows update might re-enable it.

So, you have a choice: shoddy audio quality or hearing loss.

Now, hypothetically, someone could write a third party application which modifies windows and addresses this problem.  But would it always work?  What if, for example, someone is running a real time application (maybe a game) that prevents the third party audio safety application from getting enough time slices and you wind up with a second of damagingly loud beep, or something like that?

I wonder what conditions would have to arise for Microsoft to be hit by a personal injury lawsuit from this issue?  Certainly this issue is so poorly documented that they haven't taken any steps to prevent such a lawsuit (like: including rudimentary configurable mechanisms in their default volume settings).

But wait, Windows XP was worse, why is this a Vista problem?

XP did not advertise the ability to set application volumes independently.

Fortunately for Microsoft, this should not be hard to fix without any major redesign.  All they have to do is arrange so that the system volume (which is used for windows' beeps) is inherited by all starting applications.  Then allow the user to adjust application volume up without changing the volume setting that newly started applications would use.

This would probably require an internal layer of abstraction that Vista currently doesn't have, but it's not like Microsoft couldn't afford to create that.

xargs -0

In the unix and cygwin word, I frequently use a command line like
   find . -iname '*.abc' -print0 | xargs -0 whatever
(changing abc and whatever as I see fit).

Now, a few years back someone got the bright idea that the -print0 and -0 arguments to find and xargs were "bad' and marked them obsolete.  Fortunately, more recent copies of documentation seem to have lost this "upgrade".

There were two reasons this was bad:

[1] It was a gratuitous change.  It did not solve anything.  It made the code slightly simpler, but interfaces are more important.

[2] It would have made dealing with file and directory names with spaces in them nearly impossible.

There was one supposed reason that this was good:  

[A] Using null character delimiters does not fit very well with some of the other documentation about these commands.

But whoever came up with this idea did not bother thinking that through.

Anyways, a different approach -- a much better option -- would be to add to xargs an option to use newlines to delimit words.  This would require no changes to find, would allow the use of other commands between find and xargs and would do the right thing for file names with spaces in them.

This would do the wrong thing for file names with newlines in them, but you could still use the null terminator approach for them.  And when have you ever encountered a file name with a newline in it?  That's just broken. 

Actually, I think we should get some kind of command to walk through a directory structure and find file and directory names that are outside some reasonable range (perhaps printable ascii, perhaps printable unicode, perhaps those characters which correspond to some language or some code page, if you want to overengineer the thing) and give them unique names that are within that range, and also generate some specialized before/after report that says what was changed.  Or perhaps better, generate a rename script that properly escapes the problematic characters.  And if that's not possible it points out other areas of the OS which need to be fixed.  But that's another story.

For now: xargs NEEDS to have an option to recognize words delimited by newlines.

   find . -iname '*.abc'  | grep def | xargs whatever
no such file or directory c:\Documents

Monday, October 20

Quaternions are "complex complex" numbers, and unit magnitude quaternions are handy for representing three dimensional rotations.  And there's a variety of ways of representing them.  But opengl wants us to use x, y, z, w here "w" would be the "real" part and "x, y and z" would be the "complex parts".  this gives us compatability with x, y, and optionally z being graphical coordinates in other contexts.

Anyways, if we do it this way, and we multiply the quaternion x, y, z, w with the quaternion X, Y, Z, W, the result would be 

This is posted all over the place, and can easily be found by searching for "quaternion multiplication", but is just arbitrary enough that it does not get much support in hardware nor in many programming languages.

Also, some people like to use a slightly different expression that is equivalent to this only for unit quaternions.  But given how modern computers are architected, I am dubious of the value of that approach.

Anyways, rotations can be represented with unit magnitude quaternions, and rotations can be combined by multiplying their quaternions, arranging them in right-to-left order (the first rotation must be furthest to the right).

But you can also use quaternion multiplication with non-unit quaternions to represent the rotation of points in space.   A point in space has a w value of 0, and x, y and z are the coordinates of that point.  If we call this quaternion P and our rotation quaternion R, the rotated point position is RPr.  Here, r is the conjugate of R (in other words, using opengl's convention, -x, -y, -z, w where R would have been x, y, z, w).

So... why do we need 'r'?  My informal take on this is that we first have to rotate space around in the opposite direction from R, then we move out to our point, then we rotate space back in the R direction.  The result has our point P rotated by R.

war and iraq

"It is fatal to enter any war without the will to win it."  (Douglas MacArthur)

I have a problem, though, when I read our National Strategy for Victory in Iraq, I see only two ways to win:
  1. Stay there forever
  2. Completely destroy the country
Our rhetoric, and our budget, [and, idealistically, our common sense] says that we will not be doing either of these.

We seem to have defined our victory condition based on the presence and actions of an ambiguous and unquantifiable group of people with lots of them located outside the country where the fighting occurs.

Rock on... :/

(Nevertheless this whole "surge is working" thing suggests that maybe someone does have an idea of how to win this war, and that the problem is more in how the victory conditions are described rather than anything else.  I dunno, though.  War sucks.)

cjdate and orm

Here's how to represent a relational table in an object design:
  • A table is a named bag of columns where all columns must have the same length
  • A column is a list of items where each item must have the same type
  • A row is refers to an instance of a table with an index (which is typically private)
I think C.J. Date has made some different, perhaps even conflicting statements about how relations and objects work together (or do not work together), but I would need to dig up copies of his books to find them.

Anyways, this is not complicated, unless you try and pretend that rows are supposed to be simpler than tables.