Clemens Weighs in on AOP

I was out at The Daily Grind today (ego surfing my referrers log, of course) when I noticed this link to Clemens Vasters’ blog. In it, he discusses his experiences over the last year with his COM+-based aspect-like framework. A lot of it is about the guts of what he did, but towards the end he has some very interesting things to say about how hard it is to compose what are non-orthogonal services in an orthogonal manner. Sound familiar? J

"I told you so" implications aside, I have to say I find it very interesting to hear Clemens' viewpoint, since he's been hammering so hard on this problem for a year. I think his ideas around providing rollback semantics for aspects sounds like COM+ all over again, but he's been spending a lot of time in this space, so I'll be curious to see what he comes up with. Good luck Clemens!

Sign then Encrypt or Encrypt then Sign?

I was doing some research online at work today, trying to optimize
some of the security infrastructure I’ve been working on for my client. I ran
across this article in
my search to remember whether, when both signing and encrypting a message, one is
supposed to sign first or encrypt first. I knew that doing it one way was bad, but
couldn’t remember which was which.

The article goes on at length about the many issues around signature
and encryption, but I mostly want to point out the first part, where it talks about
why you should always sign first, then encrypt second.

I started a new book today

 Don has started a new book. His first sentence is a good one.
I have some idea what he’s writing about (but I’ll let him reveal that
in his own time), and I think it has the potential to shake up the way a lot of people
think. I’m looking forward to reading it!

Here's the first sentence:

 

Software lives at the boundary between objective
and subjective reality.

 

More to follow.

[Don
Box's Spoutlet]

Escaping and Learning

 The discussion over on Sam’s
Wiki about the future of RSS continues. I wish I had the cycles to follow this
more closely, but Tim Bray has this writeup about one of the interesting issues being
discussed:

This entry is specifically about a particular
technical issue in the next-gen syndication-format design
exercise, but more generally about the wonderful experience of getting a better
understanding of complicated things. The lesson continues... update #1 (skip to end)....

[ongoing]

NGEN Improvements

Jim Hogg of Microsoft posted this little nugget on the DOTNET-CLR list in response to a question about how to get NGEN running as part of a setup script.

NGEN stores its results into the "Native Image Cache" -- physically, a collection of directories below \windows\assembly -- it's not actually the GAC, but brought to us by the same dev team.

Note that there's a couple of items to watch out for with using Custom Actions to trigger ngen: they need to run during a setup phase where it has SysAdmin privs; and as a consequence, there's a gotcha if the user disables rollback, yet ngen fails.  (I don't understand the details: my info is second-hand).

Also, beware of "servicing" issues.  For example, the user upgrades his machine; or changes security policy.  In these cases, your NGEN'd images may be rendered unusable.  In which case, the CLR will silently fall back to JIT'ing -- so it's not a fatal disaster -- all your Apps still work.  To guard against this, you might think about providing a small command file that the user can run to re-NGEN your assemblies, putting Humpty Dumpty back together again.

(As use/importance of NGEN grows, so we're working on making NGEN "self-healing" in the face of servicing -- for the Whidbey release)

I think the most interesting part about his (very nice) response is the last paragraph. Seeing hints like this about Whidbey is always interesting.

 

What’s especially interesting in this case is that it sounds like they’re about to make NGEN (potentially) a whole lot more useful. If you don’t already know, NGEN is the tool that pre-compiles your assemblies, to save the overhead of the JIT compilation that occurs at runtime. Today, NGEN isn’t very interesting, because any change to the system rightfully invalidates the compiled image and causes it to fall back on the regular JIT compiler. If NGEN images were self-recreating, it could provide a performance improvement, especially around startup times, which is where most of the JIT cost is. The tradeoff is a larger working set, but that might be worthwhile in some scenarios.

Pair Programming

Sam posts
a link to this
article which defends the use of pair programming, where two programmers collaborate
in front of a single computer to write software.  I’ve never tried this
formally in a professional setting, but I do have some experience with the phenomenon:
as an instructor I routinely write small programs in front of an audience. Anyone
that’s done this knows that the viewers don’t have to know the technology
you’re using very well to catch mistakes that you make.

In addition to this, I’m involved in a project right now where
the team is geographically distributed. I spend a lot of time on the phone, and even
with that relatively poor communication mechanism, we’ve had good luck working
through code together, both authoring and debugging. We got together in Minnesota
a few weeks ago, and had even better luck when we did the same thing with the code
up on a projection screen.

Of course, I think one of the contributors to the productivity increase
is that it makes you focus more. If I could write code for two hours straight on my
own without checking email or the web – something I wouldn’t do when I’m
using someone else’s time, too – I suspect I’d get more done. The
paper Sam references has some quantitative results, but I’d be curious to see
something more rigorous. And to try this approach myself some time, on some real project,
end-to-end.

I Like Pie

Tim Bray  posted this recently:

Sam Ruby has, over the last week or so, been quietly
at the center of a lot of intense discussion with the goals of clarifying
what a “log entry” is, and now building
a roadmap around it. Now they’re asking people to put up their hands and
say whether they support this or not. I support it strongly, with (a typically lengthy
list of) caveats, amplifications and digressions....

[ongoing]

The gist of it is, it might be time to pitch RSS, take the best ideas
out of it, and start over. Given the tarball that RSS is right now, I don’t
think this is a terrible idea. Had we done the same thing with HTML in about 1995
(and perhaps again around 1998), we might be in better shape today.

Certainly, the discussion on Sam’s
Wiki is interesting enough to be worth noting.