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.