Old Dog's Blog

They've done some re-modeling in Building 20 here in Redmond, including a nice new firewall for the server farm.

Server racks with Firewall 2.0 installed. Hack this one and you'll get your fingers burned.

I have to admit that I'm a lot better at admiring a nice set of colors to serve as a “palette” for a web page than I am at picking the colors from scratch. I also find it hard to be imaginatative in picking nice looking complementary colors, given a “main” color.

It had been some time since I google for “color schemes” or “web colors”, but this time when I tried a search on “web page effective color schemes combinations”, I came across this marvelous website:  EasyRGB.com/ Although I was wanting to experiment with color schemes for a website I'm helping my church set up, when I found this site I immediatly wished I had known about it last winter when we were getting ready to re-paint our house. What a gem -- here's a way to have the consultation of a color consultant . For free

One really neat feature was their “Search a Tint”. This tool will let you pick any of about 20 different paint companys color palettes, then type in a color name. You don't need to know any of their fancy names -- just try the basic color you're interested in. For example, I picked Sherwin Williams, then typed in Green, and here's what came back:

1   1172 PEACEFUL GREEN 218  222  207  #DADECF MatchCalculatorHarmonies 2   1174 GETAWAY GREEN 118  127  105  #767F69 MatchCalculatorHarmonies 3   1179 SEAFOAM GREEN 216  221  208  #D8DDD0 MatchCalculatorHarmonies 4   1182 MALACHITE GREEN 76  89  73  #4C5949 MatchCalculatorHarmonies 5   1194 MYSTERY GREEN 151  160  149  #97A095 MatchCalculatorHarmonies 6   1196 ESTABLISHED GREEN 68  84  74  #44544A MatchCalculatorHarmonies 7   1203 EDWARDIAN GREEN 51  73  71  #334947 MatchCalculatorHarmonies 8   1406 SAVANNA GREEN 134  115  71  #867347 MatchCalculatorHarmonies 9   1407 LEA GREEN 210  202  162  #D2CAA2 MatchCalculatorHarmonies 10   1420 LODEN GREEN 104  100  70  #686446 MatchCalculatorHarmonies 11   1421 PRIMITIVE GREEN 202  206  161  #CACEA1 MatchCalculatorHarmonies 12   1432 GREEN TWILL 174  189  142  #AEBD8E MatchCalculatorHarmonies 13   1438 GREENISH 222  230  209  #DEE6D1 MatchCalculatorHarmonies 14   1439 MOOR GREEN 166  189  144  #A6BD90 MatchCalculatorHarmonies 15   1442 GREENROOM 191  214  187  #BFD6BB MatchCalculatorHarmonies 16   1688 SPRITE GREEN 238  238  180  #EEEEB4 MatchCalculatorHarmonies 17   1689 BABYLON GREEN 239  238  196  #EFEEC4 MatchCalculatorHarmonies 18   1692 AVANT GARDE GREEN 221  226  91  #DDE25B MatchCalculatorHarmonies 19   1693 FESTIVE GREEN 213  217  42  #D5D92A MatchCalculatorHarmonies 20   1696 MINUET GREEN 233  238  195  #E9EEC3 MatchCalculatorHarmonies

 

Now if you want to find complementary colors, just click the “harmonies” link, and you'll see a full range of harmonizing colors.

But it gets better!!!  This was apparently the initial site to do something like this, but now there are some specialized engines for generating palettes of colors. Check out these:
Color Mix rematch ,
Traumwind 6-Colormatch
ColorMatch 10k - I like this one because it lets you save up to 4 palettes for quick comparison.

I've been doing some very preliminary performance tests comparing the new generic collections in .NET 2.0 to the performance of non-generic collections. Based on these first results, I think I can say that there are definite performance improvements.

To test performance, I created a simple class--"Thing", that has two properties, a string "ThingName", and an integer "NumberValue". I then use a loop to first instantiate and add a large number of "Things" to a collection, capturing the time to do so, then I use another loop to iterate the collection and access the "NumberValue" member of the object. I first captured times for a conventional collection, an ArrayList. Then I ran the same tests for the GenericList, GenericLinkedList, and GenericCollection classes. Identical tests were written in VB.NET and C#.

As I said, these results are preliminary. I will be very interested to get feedback on the methodology, and any additional tests that might be thought to be needed, but here is what I am finding:

Environment:
VirtualPC w/768mb
Whidbey Beta 1 build

Test:
Debug Build
Collection size: 1,000,000
Numbers are average for 50 repetitions of the test (times are ms)
After loading the collection, it was iterated two ways: once with a ForEach loop, and the second time with a plain “for“ loop that referenced the items by their ordinal.

Collection Type	Iterations	Load	ForEach	Ordinals
VB ArrayList	1000000	1278	58	45
CS ArrayList	1000000	1437	58	54
VB Generic List	1000000	1478	47	43
CS Generic List	1000000	1391	48	55

The results are a mix of the expected and the unexpected. I certainly did not expect that the VB collections would give better performance than the C# collections, but that is what these numbers show. (admitted, it's so minor that when you round things off on the forEach column, the difference disappears.) On the expected side, we see that the load process (which also involved constructing the objects for the collection) took far longer than referencing the objects, and in a similar vein, the performance numbers for building the collection were inconclusive.

It is in accessing the elements of the collection that we see the significant numbers. Although I included iteration by ordinals, I think that the ForEach numbers are the ones that should interest us the most. I'll come back to that thought in a moment. Looking at the ForEach iterations, both C# and VB showed almost a 20% gain in performance while referencing the collection.

The reason I think it is the ForEach performance that is of interest is because ForEach uses an iterator to access the collection, which is the same thing the data controls do when data binding to a collection. What this performance gain translates into, therefore, is the potential to speed up data binding operations when binding to a collection of objects. We'll have to test this later.

There are still quite a few tests to run. For a start, I want to run the same tests I ran here, but with Release builds. Let me know what other collections you'd like to see tested, and how.

Generics are one of the important new features of the .NET CLR for Whidbey. But .NET is not the only platform that will eventually support Generics -- also known as "parameterized polymorphism". In googling around the internet looking for articles and comments recently, I came across the following interesting comments about Generics in Java:

---

It is important to note that since casting is still being performed behind the scenes, your Java programs will not receive a performance boost from using generics. The addition of generics to the Java language is not intended to improve performance, it is intended to increase program readability and reliability while maintaining backwards compatibility with existing programs.  (http://www.ociweb.com/jnb/jnbJul2003.html)

---

Indeed, if you spend a bit more time researching generics in the Java world, you find that the focus is on the programatic benefits such as type safety (which leads to earlier coding error detection), binary-level code reuse and clarity in the code. But improved performance is definitely NOT one of the advantages given for generics in Java. All you will find are statements that generics won't “hurt” performance for a Java application. [I also came across some opinions that the Java runtime had gone far enough in tuning performance, that current Java performance was “good enough“ and that Moore's Law could be counted on to make up the difference, but that's another story.]

Generics in .NET offer all of the advantages mentioned for them in the Java world, but unlike the Java world, in the .NET world we do find potential performance gains mentioned as an advantage of using .NET generics. Technically, the reason appears to be that the Java implementation is based in the Java compiler which simply generates an ordinary collection wrapped with type casting, just as we would use without generics to build a type-safe collection. But in .NET generics are implemented within the CLR, so that the code itself is type safe and type-casting is eliminated. Thus the expected performance gains.

But is it so? Is there any kind of performance _gain_ from generics in .NET 2.0 over ordinary collections. Yes, there are more uses for generics than collections, but I expect that generic collections will be by far the most common use for the feature. I'll blog that in a separate post.

According to some ancient sages, "A fool and his money are soon parted". More recently, we hear from many folks that "time is money". By extension then, we could say that "A fool and his time are soon parted." I recently proved the truth of this deduction. I have agreed to write a few chapters in a book on Whidbey. More information will be forthcoming. For now, we've finalizing the chapter assignments, outlines, deadlines and such. Looks like I'm on tap for about 6 chapters over the next 6 months. Doesn't sound unsurmountable, but as anyone who has ever undertaken book work knows, tempis can fugit faster than you would ever imagine.

I think it was Ben Franklin who once wrote “Keep your words soft and sweet, for someday you may have to eat them.” Back in April, I certainly had some “hard” things to say about My IBM Stinkpad. Now I'm going to have to eat them. Or part of them anyway. The case of the T23 is still just as weak and prone to break as ever, BUT...

There's nothing like shopping for a new laptop to help you appreciate the feature set IBM manages to design into the Thinkpads. That was my situation last month. I was anticipating the arrival of the Whidbey beta, and the need to stop “fiddling” with it and get down to some serious using of the product. As I looked at what I had available in the way of hardware, what I saw wasn't encouraging. An almost three year old desktop, and the afore-mentioned Stinkpad T23. Time for something new.

I decided up front that I was willing to spend some reasonably serious money, not just pick up the current loss-leader or such. For a whille I vacillated between a desktop and a laptop. For the price range I was willing to spend, I found I could get a reasonably high-end desktop and toss in a 20 or 21 inch LCD monitor (or a pair of smaller ones for a dual-monitor setup). But OTOH, I have become rather fond of being able to get up and move around the house, sitting in whatever place appeals to me for the moment, and still keep on working. That implies a laptop, not a desktop. So I started looking at higher-end laptops.

My requirements, for a laptop, were (in order): “enough” power and memory to run Whidbey-class apps in a VirtualPC session and get reasonable performance; SXGA screen; Centrino technology for both the battery life and the wireless, reasonable weight; a good keyboard. Along the way I looked at the usual suspects most might comtemplate -- Dell's Inspiron 8600 and 600 being the leading candidates. I liked the 8600 for some of the higher end configurations it offered, and the 600 for it's size and weight, but I just didn't like the extra weight or size of the 8600. For the 600 there was an SXGA screen but only in 14.1”, which was too small, and at the time, they didn't have a 7200rpm hard drive option for the 600. I looked briefly at Alienware's Sentia, but it suffered from the same screen problems as the Dell 600, and Alienware hadn't yet done anything with the newly shipping “Dothian” mobile processor.

Enter IBM's new Thinkpad T42, the latest in their “T” series.
** Power? It was available with the latest mobile processor, and had a 60gb/7200 rpm hard drive option.
** Memory? A factory config with 512mb and an open slot that I could (and did) populate with an additional 1gb stick, for 1.5gb total.
** Screen? a 15” SXGA. Just right. 
** Full Centrino support, wireless antenna in the lid for good reception, and a claimed battery life on the “normal” battery of up to 4 hours (I have gotten over 4, with wireless on). There is also a heavy-duty battery that can giveyou up to 6 hours on a charge, and a drive-bay add-in battery that can add another 2+, so with the heavy-duty main battery and the drivebay addin you can come darn near to a work-all-day-on-batteries setup.
** Weight? Under 6 pounds with “basic” battery. 
** Price: less than Alienware, more than Dell

I've had it about a month now and couldn't be more pleased. I'm running the Whidbey beta bits on a VirtualPC image and it's faster than it was on my old T23 on the main OS. The screen is crisp and clear, and that extra inch of size helps the text to be a comfortable reading size (when my glasses are clean). The battery life is superb, routinely going 4 hours and more on the standard battery. I bought a spare “heavy duty“ battery for it, but have not yet used it long enough without charging to find out just how long it will go. Wireless reception is super. Keyboard has that touch that seems to be the hallmark of IBM--why can't other manufacturers do it that well? It can't be that hard to do.

Oh, and the case? Those thin rails that break so easily are now over a quarter-inch wide.

But it's still fun to call it a Stinkpad. 

Session DEV411, Steven Walther

A very, very interesting session. Steven went through a number of scenarios, comparing the time to get the data and render it on a page. There were some expected results, and some surprises.

For example, I guess it is common knowledge (or folklore) that a Datareader is “faster“ than a Dataset. BUT, how much faster is it? As it turns out, the performance gain is only 16%.

Inline script (as in old ASP style) can be up to 233% faster than the Datagrid, under Steven's test conditions.

You can gain up to a 66% speed increase with a Datagrid by disabling viewstate. This is just in time to initially render the page.

With the datagrid there is also a noticable difference between using “AutoGenerateColumns“ verses TemplateColumns. But I do wish he had included “BoundColumns“, which is my preferred method when I don't need the flexibility of the Templates.

Steven laid some important groundwork here. I think it bears further study, including something on the cumulative effects. Maybe I should do some timing of my own, to measure things like the cumulative effects of these things. Also not included in Steven's tests were the Repeater and DataList. Then there is the new GridView control in Whidbey.

Seems like almost everyone is having similar problems. It seems to be related to loosing your lease on your IP address. I've been “stable” now for about a half hour. What I had to do is release my whole IP configuration, then re-acquire a new IP address. Just how well that will work long-term here remains to be seen, but from now on when I enter a new room I'm going to completely release my IP configuration and re-acquire the connection.

I have to wonder now if this is a problem with how the network is set up, or if it has to do with how we are going about moving from room to room?

The WiFi system here at TechEd is apparently pretty high powered, BUT, not for everyone, including yours truely.

They apparently have a large number of access points, and each one seems to be providing three channels. I'm able to monitor them, and most of the time, most of them are showing good signal strength, and good s/n ratio. But it seems that the way my configuration is working, it is constantly dropping one connection and then having a hard time picking up a new one. The result is that I'll get a real fire-hose connection for a minute, or two, and then “poof”, no connection at all.

I'm pretty sure its just a matter of configuration, but so far haven't found the magic bit to turn off or on. I'm running a Thinkpad T23, XP Pro SP-1, Orinoco Gold, w/Orinoco drivers (the XP driver seemed even worse).

If anyone out there has an idea, I'd love to hear.

Or I might subtitle this one “RTFM more carefully”

Over the weekend I began some initial trials of a custom server control for the purpose of writing a review. I won't name the contol here, but when the review comes out it will be obvious what product I'm referring to here.

Anyway, I started out the way I always do with something like a new control. I installed it and got it configured in a project. Then I created the simplest page using the control I could, and without referring to the documentation. A moment or two of looking at the property sheet, and it was pretty clear how to configure the control for the simplest case, so I did that, then added a couple of lines of code in code-behind to populate the control. All worked. So far, so good.

So next I decided to try an example of a case that would be one of my reasons for buying the control. Since this was more complicated, and involved multiple controls, and there wasn't anything like an example in the documentation, this time took considerable trial and error, but no matter what I did, I kept getting the same error at runtime. Finally I emailed the developer, and he spotted my problem immediately, and confessed that he probably needed more and better examples.

The fact is, if I had just looked at that Property page a little bit more carefully, or read the included help file a little more carefully, I would have figured out my problem. But, being basically lazy, I hadn't. Shame on me. RTFM, stupid.

BUT: the developer is also correct. There should have been more examples. The few examples that were included were the most trivial. The more advanced features had no documentation beyond the listing of methods and properties in the help, which did not include any sample code.

Lessons?

• To users of a product: I really have to kick myself, but also I'll lecture those who aren't inclined to pay much attention to the documentation-- RTFM. Especially if you try something and it doesn't work as expected. No matter how sparse the help might look, look it over carefully. It may contain just the nugget you need. Give it a try before whining to someone else like I did.
• To product developers: I don't give a %&**!! how neato-keeno your feature set is. If you don't include adequate documentation and examples (preferably working examples that install with the product), users are going to miss some of your best features, or decide they don't work, or are too hard to use. Take the time over the details.

 

Not quite 2 years ago now my employer issued me an IBM Thinkpad T23. At the time, I thought I'd have it made for the next three years, since this thing with it's Titanium composite case is supposed to be one of the most robust laptops going. Now, almost 2 years, three hard drives, one motherboard and 2 keyboard bezels later, I have to wonder just how bad other laptops must be for this one to be classified as robust.

I hadn't had this unit but a few months when the original hard drive just dropped dead. No warning, no nuthin. OK, I thought, it's a fact that most failures come in the first few months of use. No big deal.

About a month later I noticed that the top part of the base--the part that surrounds the keyboard (called the bezel, I think) had broken on the left side, right over the eject buttons on the PCMCIA port. At that point the bezel is nothing but a narrow rail running alongside the keyboard. I couldn't figure out what had happened, but it affected the way the keyboard typed. A couple of days later I noticed that the other side was now broken the same way! What was going on? Oh, well, it still worked, and I just picked up the phone and called our support department, and in a few days I had a new bezel.

The new bezel lasted less time than the first one. Within a couple of months, this second one was broken in exactly the same way as the first one. Huh???  Then I started having trouble with memory disappearing. This unit has 512mb, in two chips. But Task Manager would show only 256. I opened the memory compartment, reseated the chips, and re-booted and the problem would be solved. But it kept recurring, and eventually even reseating didn't do any good. Another service call.

This time, they had to take the machine in. Next day I got a call from the tech. MB was failing tests. So was the hard drive. Sigh. This time it took them a week and a half because the depot was out of both bezels and hard drives. Luckily I had a decent desktop that could attach to our VPN so that the crash project I was working on wasn't impacted very much. And after it all, I had an almost new unit. This was back in November of last year.

So here we are now, less than 6 months later. Both sides of the bezel are broken again, but this time I caught the second one in the act!!! Or rather, I found out what I had been doing wrong. Do you own a T23. Wanna break that rail? Here's how. Open the lid partway--say, about a third of the way. Like you were pausing in your work for a few moments to talk to someone across the room and didn't want the lid up in their face.  Now, in your conversation, something comes up that makes you want to show the other person something on your laptop, so you pick it up, get up and walk over to them. Now comes the moment of truth. You're standing there and need to open the lid further. So you hold the laptop in one hand, let's say the left hand, holding it by the left hand corner of the base. Now you use your right hand to push up on the right corner of the lid. Lotta torque going on there, and “pow!” That's all it took. Just hold the unit the wrong way as you push up on one or the other corner of the lid and that rail is a gonner. Thinking back on things, that is exactly how I was accustomed to using the unit when I needed to show someone something and they weren't standing right where I could show them with it in my lap or on my desktop.

This time, I discovered that super glue seems to repair those breaks well enough, and now I'm treating this thing like an eggshell.

Aint it grand to have one of the most robust laptops on the market?