I’ve been living on the command line for a while now, mostly in Cygwin’s
Bash shell. I like it, but it’s not perfect. Nothing is, of course, but maybe this will
be a bit closer.
Friday, October 31, 2003
MONAD - the Next Generation Command Line
Monday, October 27, 2003
Sometimes It Makes You Proud to Be an Alumni
This
CNN article talks about how some MIT students have figured out a a legal way to
stream MP3s and cut the record companies out...fantastic! Just because
I don't like it when people copy music without paying for it doesn't mean that I side
with the RIAA. Quite the opposite. So the fact that they figured out how to have it
both ways makes me happy.
A Retratction
Recently, I mentioned that I thought the Microsoft Application Blocks were not mature. I sited a general documentation bug and a Configuration Management Application Block threading bug as key indicators that the software isn’t ready for prime time. And I said that I hadn’t heard back from them after reporting the bug.
Well, I’m going to eat my words on two of those: the threading bug doesn’t exist, and not only did the Patterns and Practices group get back to me, the email was written before I posted the blog entry…I just hadn’t checked that particular email inbox that day. And the team is aware of the documentation bug and plans to fix it.
For the record, the threading bug I thought I saw was related to a Hashtable maintained in the MemoryCache class. I noticed two things about it: First, that they weren’t using the Synchronized wrapper. Second that even though they were taking a lock on writes, they weren’t locking on reads. This is not, in general, safe to do. In particular, it’s not safe to enumerate over a Hashtable at the same time a write is occurring.
As it turns out, the CMAB implementation is safe because they never enumerate over the collection. And since the Hashtable is a private field, no one else can, either. Not using a Synchronized Hashtable is fine in their case because they do the lock on write (which is all the Synchronized wrapper does anyway). Locks on simple reads through the indexer are not necessary with a Hashtable – only on enumeration.
On top of all this, the response from the Patterns and Practices team was really good. I think I got about four phone calls and twenty or so emails from Microsoft people in response to my feedback. And the dev lead himself walked through the code, took the time to verify that the problem I thought I saw wasn’t there, and let me know…over the weekend. Kudos!
Now I just have to figure out if it’s worth it for me to go in and change my code around to use the Configuration Management Application Block again. I wrote my own version that I’m employing, and of course it’s slightly different, and tailored specifically to my view of the configuration management problem. Microsoft’s stuff is obviously superior in many respects, as it has been more carefully architected and more thoroughly tested…and they’ve clearly got a great team backing it up. The only thing stopping me from leveraging their stuff is that what I’ve got now works. I think. :)
Friday, October 24, 2003
C# 2.0 Spec
Niels reports that the C# 2.0 (Whidbey) spec is now online here. Guess I need to find some time this weekend!
Wednesday, October 22, 2003
Microsoft Application Blocks Not Mature
So, I’ve spent some time over the past couple of weeks looking at Microsoft’s
Application Blocks. If you’re not familiar with these, you should know that
they’re basically software written by the Patterns
& Practices group that’s aimed at solving common problems. For example,
the Data
Access Application Block is a set of helper classes aimed at making data access
easier. They’re generally the sort of thing that you write yourself after you’ve
written the same two hundred lines of code three or four times. Only now Microsoft
writes it for you. They even give you the source code.
Unfortunately, as much as I hate to say it, I think these aren’t quite ready
for prime time. I really wanted to like them, not least because I had a nice conversation
with Ron Jacobs from the Patterns & Practices group about them, and he seemed
like a smart, helpful guy. But there are a bunch of little things that just tell me
I’m not likely to get much use from them. Like:
· The
Data Access Application Block currently only works with SQL Server. You can get bits
from gotdotnet that make it work with Oracle, but it doesn’t do anything to
make the differences between the two databases go away. Not that I necessarily think
they could – but at that point, what value am I getting from the code?
· The Exception
Management Application Block only does some of what the Enterprise
Instrumentation Framework does. Granted, it was written sort of simultaneously
with EIF, but again, where’s the value if there’s something better available?
The really telling ones, though, are things like:
· The
documentation contains factual errors, claiming at one point that the CLR will load
the assembly with the highest build and revision number where the major and minor
version numbers match the requested version. This was true briefly in one of the betas,
but has never been true in the released CLR.
· The Configuration
Management Application Block – which at first looked to be one of the most
useful of the bunch – contains some fairly rookie-type threading bugs.
These last two just kill me. If I’m really going to use this code in my products,
it has to inspire confidence that it was written by someone who knows the problem
domain at least as well as I do. Demonstrating a misunderstanding of the platform
and of basic threading principles don’t achieve that. I emailed the team about
the thread bug, hoping to hear back from them, but it’s been over a week and
nary a word, so here I blog.
That said, I should point out four things. First, that these blocks are the group’s
first attempt, and no one gets anything right on the first try. I expect their next
version will be significantly better. Second, that I didn’t get elbow-deep into
all the blocks, so I might be missing a cool one. Third, that what doesn’t work
for me might work for you. And finally, that the group produces a lot more than just
these blocks, including some fairly decent whitepapers on things like security and team
development with VS.NET – all stuff I’ve heard my clients beg Microsoft
to do for years. So they’ve moving in the right direction.
Friday, October 17, 2003
New Direct3D Tutorial Available - Dealing With Device Loss
The Direct3D device can become lost due to a variety of events - screen savers kicking in, computers being locked, or machines going into standby. In this tutorial, we'll see how to gracefully deal with these events.
This Weblog Unavailable Saturday and Sunday
Because of a scheduled outage by the power company that services the DevelopMentor offices in California, this weblog (and all other staff.develop.com resources) will be unavailable from 11PM PST, Saturday, October 18th, 2003 through about noon PST on Sunday the 19th.
Note that this outage will not affect the main DevelopMentor website, nor will it affect the discuss.develop.com mailing lists.