So I’m thinking about the fact that folks generally can’t remember how to spell “Paraesthesia.”  I like the name, I’ve had it for a while, but I think there’s a memory barrier there.  I own “travisillig.com” (which currently redirects you to my site).

What do folks out there think about the idea of making “travisillig.com” my primary domain and having Paraesthesia redirect?  Would it be easier?  Do you care?  It would be no trivial amount of work and I’d lose a bit in the way of Google results/ranking for a while, so I want to be sure if I start thinking about doing that.  (I would definitely make sure any existing links out there would continue to work.)

What do you all think?

I figured out the problem with my URL absolutifier HttpModule (which I’m calling “UrlAbsolutifierModule” - gasp).  I was hooking into things too early in the request lifecycle, so when the Subtext RSS handler attached a GZip filter to compress the RSS feed it was GZipping things first, then I was trying to process URLs.  Attaching later in the lifecycle allows me to wrap the GZip filter so I can do my processing before the contents get encoded.

If you’re reading this site through RSS, pictures should now properly display.  Here’s a little picture of my cat so the RSS folks can see it in action - if you see the picture in your RSS reader, you’ve got the cleaned up feed:

If you don’t see the picture in RSS, it’s not working.  Should that be the case, please leave me a comment to that effect.

I’ll test this out for a while before I release it.  If it works, I’ll put it out there for folks to consume.

The topic of Day 3: Development.

Keynote - John Lam

Lam’s keynote was primarily a demo of IronRuby and an explanation of how they arrived at where they’re at with the project as well as where they’re going.  It was very interesting to see a Ruby app on Mono running Windows Forms… but I realized as I watched this that I don’t think I’m nearly as interested in the whole Dynamic Language Runtime thing as everyone else out there is.  I mean, it’s cool and all, and maybe I’m just burned out on it, but when people say “DLR” I don’t instantly think “Yes!”

The Right Tools for the Right Job - Rocky Lhotka

This was less a presentation on tools (as it sounds like it might be) and more a presentation on application architecture urging you to use the right tools - and patterns - for the solution you’re creating.  In most cases, this boiled down to the fact that you need to have the discipline to keep your application layers (presentation, business, data) separate so you can appropriately accommodate technology changes.

Model-Based Design - David Trowbridge, Suhail Dutta

This talk was specifically geared around the modeling tools built into Visual Studio Rosario.  Three modeling tools were shown:

• Logical class diagram - An enhanced version of the exisitng class diagram functionality.  Generate class stubs based on the diagram and update the diagram based on code changes.
• Sequence diagram - An extension from the logical class diagram.  Show how classes interact in a standard sequence diagram.  As you add method calls to the sequence diagram, it updates the class diagram, which allows you to generate code.  What I didn’t see here was whether the actual sequencing in the diagram generates any code.
• Dependency analysis - They called this “Progression.”  Pleading ignorance, I don’t recall why.  Anyway, this frankly looked like a watered-down version of NDepend.

Dependency Injection Frameworks - Scott Densmore, Peter Provost

A discussion on the principles of dependency injection more than specific framework usage, which was just fine.  I won’t go over the whole thing because there’s plenty out there on dependency injection.  The two things I liked were the list of different types of dependency injection and the potential drawbacks.

Types of dependency injection they mentioned (who knew there were so many?):

• Service locator (not really dependency injection, more late-binding to services)
• Interface injection
• Setter injection
• Constructor injection
• Method call injection
• Getter injection

…and drawbacks of dependency injection.  (I liked this because proponents of dependency injection rarely mention these things as drawbacks, instead calling it “good design,” which is debatable.)

• Lots of little objects - you generally have to break things down into very, very small pieces.  Rather than two-1000 line objects, you might have 20-100 line objects.
• Runtime wire-up can be complicated and difficult to visualize - figuring out which objects were populated by what context and how the dependency came to be can be hard to wrap your head around, especially in systems of any size.  Couple that with the “lots of little objects” drawback and you might realize you have a defect… but which of the bajillion little objects is it in?
• Interface explosion - everything gets an interface because everything’s gotta be pluggable.

They recommended that if you write reusable libraries with these techniques, you should wrap the public facing stuff with a facade to mask this confusion from the library consumers.

Designing for Workflow - Ted Neward

A two-part talk on things to keep in mind when designing for workflow (specifically, Windows Workflow Foundation).  The first part started out by basically saying that there’s not enough info out there to be able to identify best practices for workflow development.  That said, keep in mind the goals:

• Capture long-running processes.  (Be able to “pause” and “resume” a long-running process.)
• Provide “knowledge workers” with the ability to edit a process.
• Provide a component market.  (Developers create activities - components - that knowledge workers can use to compose workflows.)
• Keep workflows decoupled from the environment.  (What if you started a process on a Blackberry and resumed it when you got to work and logged into the web application?)
• Embrace flexibility in workflow hosting.  (You might host the workflow in your web app, in a Windows forms app, etc.)

The second half of the talk was open discussion.  The key that came out here was that, when working with workflow and looking for patterns, don’t neglect work that’s already been done.  Check out the Workflow Patterns site for some documented workflow patterns.

Panel: The Future of Design Patterns - Dragos Manolescu, Wojtek Kozaczynski, Ade Miller, Jason Hogg

An open forum to debate whether future investment in pattern education for the masses should occur in tools (creating tools that more easily allow you to introduce patterns into your code) or in materials (web sites and books that educate you about patterns).

No real resolution was reached, but there were definitely some strong feelings on both sides.  Some felt that simply giving people tools would make it too easy for junior folks who don’t understand the patterns to shoot themselves in the foot by misusing the tools and making bad code even worse.  Others felt that there’s already enough material out there and investing in even more would be a waste.  And, of course, there are the middle-ground folks who say we need both.

But if you can only have one of those things, which would you take?

EntLib Devolved - Scott Densmore

An exploratory discussion on why the Enterprise Library is the way it is and ideas on how it might be made easier to use.  Wouldn’t it be nice to be able to say EnterpriseLibrary.Get<Database>("Sales"); or something as simple as that?  What’s stopping us?

The answer: Nothing.

They’re working on it.

An Evening With Microsoft Research - Jim Larus

A peek at some of the stuff Microsoft Research has been working on.  You’d be surprised (or maybe not) at the breadth of topics they look at.

I think my favorite one was the analysis they did on a developer’s day including all of the interruptions and task switching that goes on - things you might not even notice - and how that impacts not only that developer but others around them.  They call it “Human Interactions in Programming.”  Looking at a graphical representation of a 90 minute period that shows interruptions for several developers was fascinating.  They even analyzed what the most frequent question types were that people interrupted to ask (“Why is my code behaving like this?” sorts of things) and how satisfied they were with the answers they got back.

Neat stuff.

I’m still working on a decent solution to the absolute URL problem I’m seeing in my RSS feed (which is why the images in my RSS feed appear broken - the images are sourced from a relative URL, like “/images/foo.gif” which, paired with FeedBurner, make it look like the images are supposed to come from FeedBurner, and they’re not).

Anyway, I have a sort of general-purpose HttpModule for filtering response output and converting URLs to absolute format, but it’s not working with Subtext’s RSS feed when compression is turned on.  I think I’m inserting myself too late in the request lifecycle so my filter is trying to process GZipped content and is puking on it.

So… I’ve got some more testing and coding to do.

Another stumbling block I hit and wasn’t even thinking of - I wrote my first run at the module to filter HTML… but what it really needs to filter is XML with embedded encoded HTML because that’s what RSS is.

That leaves me with a little bit of a design quandary - I can make it a general purpose module at the cost of increased development and testing or I can narrow the scope to my specific case and reduce the set of customers that would find it useful.  Ah, isn’t that just the typical development dilemma?

The topic of Day 2: Agile.

Keynote - Steve McConnell

McConnell gave one of his usual interesting and insightful presentations on Agile development practices.  I think the thing I liked the best was that he talked about how you don’t have to stick to every single Agile ideal to the letter to call yourself Agile - in practice, doing what works for your team and your company is what’s important.

A couple of interesting quotes:

“We see XP fail more often than it succeeds.”

“We see Scrum succeed more often than it fails.”

Practices he’s seen succeed in Agile environments:

• Short release cycles.
• Highly interactive release planning.
• Timebox development.
• Empowered, small, cross-functional teams.
• Involvement of active management.
• Coding standards.
• Frequent integration and test.
• Automated regression tests.

On the other hand, things like daily stand-ups should be evaluated - make sure you’re not meeting just for the sake of meeting.  And don’t oversimplify your design - YAGNI is a good principle, but don’t use it as an excuse for a design that is too inflexible to accommodate for change.

Agile is More Than Monkey-See Monkey Do - Peter Provost

Provost started this talk with an altogether-too-close-to-home story called “An Agile Tragedy” about a team that attempted to adopt Agile practices only to sacrifice certain key tenets and have a project fail miserably and wind up with a very unhappy team.

Basically, just following Agile practices doesn’t make you Agile.  You have to actually subscribe to the principles, not just go through the motions.

Empirical Evidence of Agile Methods - Grigori Melnik

This talk was a discussion about the metrics we have that support the value of Agile development practices.  What it brought to light is that we don’t actually have a lot of metrics - Agile is largely measurement-free and most experiments that have been done are too trivial to count or have inherent design flaws.

What’s New in Rosario’s Process Templates - Alan Ridlehoover

“Rosario” is the version of Visual Studio that comes after Visual Studio 2008 (Orcas).  It’s built on the VS 2008 technology and adds features.

This talk focused on the Team System features they’re adding to Rosario to support a more integrated Agile development process.  Specifically, they showed some of the templates they’re adding that allow you to manage your backlog and work items.  It looked, to me, a lot like VersionOne meets Visual Studio.

Other features that stuck out to me:

• Continuous integration support - They’re building in a continuous integration server that’s supposedly better than CruiseControl.  I’ll have to see that to believe it.
• Drop management - Once you’ve built something in your continuous integration server, where does it go? How long do you maintain it? That’s what this does.
• Test impact analysis - If you change a line of code, this will tell you which tests need to be run to validate the change you made.

Lessons Learned in Unit Testing - Jim Newkirk

Some very interesting discussion about things learned in the creation of NUnit and other experiences in unit testing.

• Lesson 1: Just do it.  You have to write your tests and they have to be first-class citizens.
• Lesson 2: Write tests using the 3A pattern.  Arrange, Act, Assert.  Each test should have code that does those things in that order.
• Lesson 3: Keep your tests close.  Close to the original code, that is.  Consider putting them in the same assembly as the code they test and ship the tests.  One possibilty to still maintain the ability to not ship tests includes using multi-module assemblies - put your production code in one module and your tests in another.  When you’re debugging/testing, compile both modules into the assembly; when you release, only include the product module.  Unfortunately, Visual Studio doesn’t support creating this sort of assembly.
• Lesson 4: Use alternatives to ExpectedException.  The ExpectedException attribute, part of NUnit, breaks the 3A principle because it puts the “Assert” - the ExpectedException attribute - at the top.
• Lesson 5: Small fixtures.  Keeping test fixtures small helps readability and maintainability.  One idea is to create one main test fixture class and each method’s tests go in a nested class/fixture.  (Of course, this does introduce nested classes, which isn’t supported by all test runners…)
• Lesson 6: Don’t use SetUp or TearDown.  The problem is that they become a dumping ground for every test’s setup/teardown even though they apply to every test.  Forcing each test to do its own setup and teardown makes each test isolated and more readable… but it will introduce duplicate initialization code.
• Lesson 7: Improve testability with inversion of control.  This was sort of a nod to “design-for-testability” with interfaces that allow you to swap in test implementations of objects at test time.  (Dependency injection centralizes the management of this.)  The benefits are better test isolation and decoupled class implementaiton.  The drawbacks are that it decreases encapsulation and risks “interface explosion” (a high proliferation of interfaces
  • every object ends up with a corresponding interface, even if it’s just for testing).  Plus, in many cases a dependency injection framework is overkill.

Very interesting stuff, even though I disagree with some of the lesons (no SetUp/TearDown, inversion of control/design for testability).

Agile Security - David LeBlanc

This was a talk about how secure coding practices like threat modeling can work into an Agile project.  There were some good general ideas, but the main point was that you need to work it into your own process - there’s no one way to get it in there.

Ideas include:

• Appoint a security owner, ideally someone who’s interested in it.  That person will be responsible for ensuring the team meets security goals.
• Agile threat modeling is sometimes just as good as a heavyweight process.  Sketch data flow diagrams on the whiteboard and make sure threat mitigations get added to the backlog.
• Use code scanning tools daily or weekly.  Also use peer code review - this can not only catch functional defects but security defects, too.
• Build security tests at the same time you build your other tests.

“Yet Another Agile Talk On Agility” - Peter Provost

This was an interactive session where we actually used an Agile process to, as a group, ask questions about Agile, add them to a backlog, rank the priority of each question, and get the questions answered.

An interesting exercise and lively discussion about a wide variety of Agile development topics.

“Open Source in the Enterprise” - Discussion Panel hosted by CodePlex

Ted Neward, Jim Newkirk, Rocky Lhotka, and Sara Ford sat in on a discussion panel to talk about different topics related to open source - getting management buy-off to allow use of open source projects in development, contributing to open source projects, mitigating risk when using open source projects, etc.

After a while, it became more audience-participation-oriented and speakers started swapping out.  For a time, I was even up there with Jim Newkirk, Sara Ford, Stuart Celarier, and Rory Plaire.  I have to say, it was pretty sweet sitting up there with that crowd.  Maybe I need to seek me out some speaking gigs.