dotNoted

Icon

Observations of .Net development in the wild

Do sales/marketing folks fall into the trap of convention more easily than anyone else?

When you see enough advertisement, you see patterns emerge. Someone does something which is pretty creative in order to help their message, and thus their product, stand out; soon it’s showing up everywhere as others copy it, looking for the same freshness and appeal.

After a while, certain designs or phrases become almost an institution in their own right: “new and improved”, “this weekend only”, “no payments until January 2008”. I don’t really hear these phrases anymore, and almost missed even thinking about what they might mean. For example, I heard the “no payments…” one since I was a kid, when I had no clue what a payment was. So, I didn’t think about it until more recently, when I finally understood what they were trying to tell me (and trying not to tell me, like you still have to pay the interest on those months you aren’t paying, fool). Did the constant repetition make it invisible or did it finally do it’s job and get me to listen? I don’t know. You decide.

I came across this add in a Fry’s sale flyer. I think this marketer fell into the convention trap, and didn’t think of what the term meant in the context of the product. I know I got a bad feeling when I saw the word and the device, only because the word almost always means something bad when paired with it.

Ill-chosen word for a hard drive

This would make an interesting AI problem to get a computer to understand the inappropriateness of this ad.

Filed under: Metathought

VS 2005 debugger watch gets a bit lost in the stack when chaining IEnumerable instances

In the spirit of deferring execution to the last possible minute, which on .Net means using IEnumerable and in C# 2.0 the yield keyword, I’ve built a graphics rendering engine which returns rendered objects as an IEnumerable stream. The interface to this engine allows access to an IEnumerable of the rendered objects, which in turn delegates to an object-specific renderer, which in turn delegates to a graphics-system specific renderer. All each one does is to return an IEnumerable to the client object, and defers rendering or otherwise doing computation until the enumeration is iterated. Then it processes each object in turn. This is a nice way to stream computation, since the cost of computation is amortized over each object from the beginning, and each additional one is a marginal, predictable cost, rather than having a huge cost for the first object and then a diminishing cost for subsequent ones. Ad-hoc decision making during the streaming, such as a decision to cancel, is therefore cheaper, since you didn’t have to pay for almost all of the result up front. If you’ve done functional programming, you already know this. We programmers who have done imperative programming most of our lives are just now catching on…

It seems that there are some technical challenges to stacking your IEnumerables high, however. VS apparently does a stack trace to figure out which debug watch language to use, and gets it wrong when it has too many to go through and you get some BCL code iterating your enumeration. Here’s what I get when I call List.AddRange on the graphic engine’s Render operation for some unit test:

VS debugger watch is a bit confused

Note that the code is C#, but the watch popup thinks it’s dealing with C++/CLI.

Filed under: .Net Graphics

Wow, my former classmates really _were_ on the same frequency…

Update: Paul Beard notes the apparent scam that Classmates.com is pulling here. Read the comments there for an interesting attempt at astroturfing by some Classmates.com commenter (comment #28).


Once upon a time, I went to Classmates.com and signed up to see what it was all about. Of course, I’ve been getting emails ever since. I’m not too surprised about that. One day, however, I got an email that said someone signed my guestbook. That, on the other hand did raise my eyebrow. It deserved a look since, well, as you can imagine, given my interests in life, I was not the kind of person to attract friends in a small town high school.

I clicked on through. When I arrived, it appeared that Classmates wanted me to upgrade to see who signed it. I toyed with giving up my numbers for a month of charges, but since the minimum charge is $15 (3 months at $5 / month) I decided seeing who this one soul was could wait until the information was cheaper.

Then, soon afterward, I got another notification that another old skooler signed my guestbook. It was long enough since the first notification where I probably took the same steps as above. The next few months are a blur with all of the activity in my life.

Last month I got another. Suspicious, I decided to look at the list of signing events. That’s when I spotted a curious pattern. Here is a shot of the list:

Classmates Upgrade Trap

Odd how the number of the month of the signing event is (last event’s month + 1). Sure the day of the month is random, but how hard is that to model? It looks like a marketing campaign with a requirement to have a monthly teaser if I’ve ever seen one. I’d predicted in August that the next would come in September. Let’s see how long this pattern continues.

Filed under: Entertainment

InternalsVisibleTo needs the whole public key in CLR v2.0 RTM

Hopefully, this post will help the search engines to set the record straight about the InternalsVisibleTo attribute for creating friend assemblies. A number of notable .Net voices (Oliver, JuvalJames World) used this attribute in pre-RTM code, when the public key token was used, but Microsoft changed it in the release.

In one post in particular, a commenter, Neil, was trying to say that PublicKeyToken isn’t available for InternalsVisibleTo – only PublicKey is. C# MVP Oliver Sturm counters by explaining that it seems pointless to use the whole public key, since it is so much longer to copy than the public key token. While this is true, he apparently was unaware of the change when he wrote this. It was changed in .Net 2.0 RTM. MSDN, after remaining inaccurate after release for some 9 months, now shows the correct syntax.

Update: David Kean also points this change out, and notes that it was changed in RC1, which if I recall correctly was released right after the PDC and right before the November RTM. David also has a nifty utility which generates the otherwise onerous attribute for you. Nice.

Filed under: .Net Basics