Experts say the Enron executives' testimony is extremely risky for the pair.
They will have to overcome the obvious conclusion that they knew they were robbing hundreds of employees and thousands of investors before company collapsed. Stay tuned.
Former House majority leader Tom DeLay is not seeking re-election. This is the best political news I've heard in days.
I'm going to bed as happy as I can be back in Nashua.
I mentioned Friday that I've completely refactored the section of the Inner Drive Extensible Architecture™—the Idea™—that handles quantitative functions. (I've also decided to make some SDK documentation available.) The actual design of the IMeasurable classes—Length, Speed and the like—bears more discussion.
What I have, essentially, is a collection of .NET structs that implement IMeasurable, one for each kind of thing you want to measure. The old design had a single struct called Numeric that could represent any kind of measurement at all. The change means that the measurement type is now enforced by the compiler rather than the run-time engine, because instead of this:
Numeric meters = new Numeric(10d, new Meter());
Numeric pounds = new Numeric(10d, new Pound());
Numeric compilesFine = meters.Add(pounds);
> IncompatibleUnitException thrown
You get this:
Length meters = new Length(10d, new Meter());
Mass pounds = new Mass(10d, typeof(Pound));
Length wontCompile = pounds.Add(meters);
> Compiler error: no overload of Mass.Add takes Length as a parameter
One thought I had, though, was: why not make each of the units a measureable type to further constrain the design? So you would have this instead:
Pound pounds = new Pound(10);
Gram grams = new Gram(10, MetricExponent.Kilo);
Pound pounds = pounds + grams;
Simply: that would require either dozens of nearly-identical structs, or I would have had to use classes instead. Remember that a struct can't inherit from anything except System.ValueType. So each struct either has to contain all the relevant code (about 1200 lines of it for each of my IMeasurable classes, including documentation), or it has to compose most of its functionality from other, static objects—which is actually quite difficult in this context.
Structs are small very fast, and immutable, which makes them the best choice for small, fast, immutable things like measurements. I'd rather represent measurements with structs than objects, but I'd also like to avoid writing and unit-testing dozens of nearly-identical classes. So I compromised: representing each type of measurement with its own struct (so there are now only 8 of them), and allow the abstract Unit class to define how the individual units interact.
Check out the Quantitative SDK and let me know what you think.
Usability guru Jakob Nielsen has a new column today reminiscing about the hype of 1997 because it's back in vogue:
The fads and big deals that get the press coverage are not important for running a workhorse website. To serve your customers, it's far better to emphasize simplicity and quality than to chase buzzwords.
There is endless coverage of a few atypical stories in the trade press, mainstream media, and even on specialized Internet-focused websites. Once again, it's worth remembering: your site is different from the ones in big stories. Focus on fixing the basics to get a simple and communicative website. Simple steps don't get hyped, but they drive much more business value for the average site than the issues that everyone writes about.
He includes a sidebar about the fads of 1997 and how they're doing today.
Krugman weighs in (sub.req.) on the immigration debate roiling the GOP:
For now, at least, the immigration issue is mainly hurting the Republican Party, which is divided between those who want to expel immigrants and those who want to exploit them. The only thing the two factions seem to have in common is mean-spiritedness.
Nicely put.
Appyhay Aprilhay Oolsfay Aday!
(Evenhay ymay eatherway itesay ishay inhay hetay piritsay.)
In January, I wrote about framework classes I was working on, and how I wanted to simplify the Inner Drive Extensible Architecture™. I followed up in February with a conundrum concerning how to model the problem. It turned out to be tricky, and time-consuming, and considering I wrote most of it at The Peddler's Daughter in Nashua, N.H., there was a lot of Smithwick's Ale[1] involved.
But today, at last, I've got a new demo.
The demo page has a lengthy explanation of how the new version works, and includes a bunch of source code showing how simple the stuff is to use and to extend. I still have a little polishing to do, but I'll probably be putting the full SDK documentation for the IDEA™ up on the Inner Drive website later this month.
I think this is some of the coolest stuff I've ever written.
[1] I would have linked to the official Diageo site, but it's so annoyingly badly written—it whisks you away to a page requiring your birthdate and it tries to cookie you—that on principle I won't have that as the primary link to this product.
One final quick hit for the morning: I completely forgot that yesterday was the 25th (25rd?) anniversary of President Reagan's attempted assassination. It's hard to grasp that it was that long ago.
I got a mailing from my undergrad alumni association exhorting me to go to the "23th Annual Dutch Festival." I last went to the 9rd one, or maybe the 10st, so I may just have to visit.
One of my fans sent me this Passover-themed link. Share and enjoy.