I did need to alter Matt’s approach a little, though, because it didn’t work for me as it was. I would have just commented about this on his blog, but comments are closed.

When I ran my installer, I got a vague error saying that the custom action had failed. Running the MSI from the command line with the logging switch, and looking at the MSI log file didn’t help. There was output saying that it was going to run the custom action, but no indication that it had failed, no result code from the Appcmd process, and nothing from stderr. It did show the complete command line for the action, however, so I copied it out into a command prompt and ran it. That failed saying I needed administrator privileges. Running in a command prompt started with “Run as Administrator” worked just fine.

It turns out that by default, custom actions impersonate the user that started the install, without the administrator elevation that the installer itself runs under. This can be changed by setting the CustomAction’s Impersonate attribute to “no”. That also required adding Execute=”deferred”, and as a result, having the custom action run before InstallFinalize rather than after.

Here’s what it looks like:

<InstallExecuteSequence>
  <Custom Action="ConfigureAppPools" Before="InstallFinalize"><![CDATA[NOT Installed AND VersionNT64 >= 600]]></Custom>
</InstallExecuteSequence>
 
<!-- Snip -->
 
<CustomAction Id="ConfigureAppPools" Execute="deferred" Impersonate="no" Return="check" Directory="TARGETDIR" ExeCommand="[SystemFolder]inetsrv\appcmd set apppool /apppool.name:&quot;[APPPOOLNAME]&quot; /enable32BitAppOnWin64:true" />

The Future of C# (AKA C# 4)

Rob’s first presentation introduced what the C# team is working on for the next release of the language. A lot of the focus is around exposing support for dynamic programming and interoperability with dynamic languages like Python and Ruby. This is done by deferring the evaluation of method and property calls on some objects until runtime. At compile time, the normally strict static type checking of the C# compiler is relaxed when a method call doesn’t seem to exist in order to allow for the possibility that such a method will be added dynamically sometime during program execution. To indicate that this behavior is wanted, you use the dynamic keyword like this:

dynamic customer = GetCustomer();
Console.WriteLine(customer.FirstName);

At run time, whatever actual object is stored in “customer” needs to have a property “FirstName” or an exception is thrown. Otherwise, the actual type is unimportant. This is also known as “duck typing” where capabilities of objects are more important than actual types — if it looks like a duck and acts like a duck, it might as well be a duck.

Some people in attendance were confused about how the dynamic keyword differs from var. The var keyword really just saves keystrokes — the type is still static but figured out by the compiler. Objects that are dynamic however, have their method calls bound at run time.

The ability of C# to handle dynamic types also makes it easier to interoperate with Javascript. Rob showed a Silverlight application that called out to Javascript functions pretty much identically to calling regular C# methods.

The next version of C# will also have default and named parameters, which have been supported in other .NET languages, and will make COM interop a bit nicer. I’ve written a bunch of calls to Office where it seems like you’re passing in ten-thousand Type.Missing parameters to some of the methods, and that will no longer be required.

Silverlight Toolkit

Shawn Burke, one of the guys behind the AJAX Control Toolkit, is now heading a team to create Silverlight controls. This presentation showed the controls that they are working on, and described the distribution model.

The controls are things like AutoComplete, NumericUpDown, TreeView, DockPanel, WrapPanel, and others that would be really useful in building a typical modern GUI application. There is also charting support, which Rob said comes fairly mature by virtue of Microsoft’s assimilation of Dundas code and engineers. There is also support for theming applications.

The controls are to be released on CodePlex frequently, with some controls eventually making it into the official Silverlight SDK or even the Silverlight Core. The Silverlight Toolkit, not to be confused with a CodePlex project called the Silverlight Control Toolkit, has a nice sample application that shows off all the new components.

REST with WCF

My coworker, Ryan Jameson, went to a Microsoft event last year where the REST Starter Kit for WCF was one of the topics. He came back saying with a smirk that Microsoft had apparently invented REST, the way they had presented it. Rob implied no such thing, even joking that in every presentation about REST, there are people ranging from those who have never heard of it, to those that know Roy Fielding’s middle initial (which would be T, by the way).

REST is a philosophy for providing web services in a way that embraces the “way of the web”, such as:

• Most everything is addressable through a URI
• There are standard representation formats
• Interactions are stateless
• The HTTP protocol

Rob asked rhetorically if these principles might work OK given the success of the web, and summed up the philosophy by saying, “If you use GET for something other than getting a resource, you’re Part of the Problem.” And don’t even think about using POST to get something.

I haven’t done more than play around with web services, but it seemed to me that by using URI templates, WebGet and WebInvoke attributes, and WebProtocolException, you could suffuse a high degree of RESTiness into your WCF web service.

Things got pretty loose in this presentation, with Rob dodging pot shots about IE and standards conformance, switching to a Mexican accent for a bit of the delivery, and demonstrating that Notepad is a REST client. Kind of fun.

Azure

The last presentation was a lot to grasp, as Rob warned it would be. The denotation of “azure” is the blue of a clear or unclouded sky. But Microsoft’s Azure is about cloud computing. What does that mean?

Azure comprises a huge pile of stuff, which makes it pretty hard to talk about in a meaningful way. Hearing the presentation reminded me of when .NET was first announced. Everything at Microsoft was .NET then: Visual Studio .NET, Windows .NET, Clippy .NET, etc. The short version is that Azure combines typical operating system facilities with utility computing. In one sense it sounds like outsourced IT, where you let Microsoft worry about the data center, dynamically scaling resources as needed. But it is also more than that — an umbrella of networked stuff covering the “Live” services, SQL, raw data storage, and much more.

Rob says that Azure is Microsoft’s big bet right now. I wonder if things will settle down a bit when Microsoft gets a more fully-formed vision, much like they did with .NET.

Frameworks and DDD (Tim McCarthy)

On Friday, I spent most of the day in the Domain Driven Design track, hosted by Eric Evans. The first speaker was Tim McCarthy, who has recently written a book on using DDD with.NET and C#. Tim raised an interesting question with his talk: How do you keep your domain code clean when working with frameworks? By frameworks, Tim meant broad frameworks like ASP.NET as well as more narrow, application frameworks like SharePoint. The challenge is that with frameworks, and especially the wizard/designer approaches to coding sometimes advocated by Microsoft, it can be really easy to become inappropriately coupled to persistence, specific APIs, etc.

Unfortunately, Tim had a couple of problems in his presentation that made it less valuable to me than it might have been. The first problem was being sort of backward in terms of audience (for me at least). He worried about whether people knew what SharePoint was, but breezed over DDD terminology. The second problem was getting bogged down in details of code from a real-world system. I’m sure that there were good ideas in there, but they were hard to see because of the context that needed to explained. There’s always something nice about real code for demonstrating a point, but in a presentation, maybe simple examples would be better.

Ultimately the point was that DDD provided strategies for a decoupled system.

Rebuilding guardian.co.uk with DDD (Phil Wills)

I met Phil on Tuesday over lunch, so I was looking forward to hearing his presentation. It got off to a rocky start due to technical difficulties. The number of Macbooksat this conference really drove home the point that this wasn’t a Microsoft conference, but after a couple of failed attempts to get the presentation going with different Macs, Martin Fowler (whose machine was one of them) quipped that Macs being so superior is bullox.

Once the presentation got underway, Phil gave a little background about the Guardian. The newspaper has its roots in the 18th century, and is now the largest online newspaper in Europe. They put their first web site up in 1996, but over the years the system became problematic:

• Editors had to do a bunch of tedious manual work
• There were multiple URLs for the same resource
• New developers were hard to recruit because of the outdated technologies in use
• There was a lot of technical debt preventing big new features

To rebuild the site such that it would be “of the web, not just on the web” and ready for the future, they took an ambitious strategy of going agile, using new technologies and different design approaches (DDD). They got some help from ThoughtWorks to make it up the steep learning curve involved in such radical change.

Phil shared a few things they learned along the way. One thing was the importance of using the language of the problem domain everywhere, which allowed even the non-technical people on the team to contribute in unexpected ways. An example of this was a big breakthrough in terms of object composition. Phil showed an original object hierarchy and a much cleaner one. He said that of course, big breakthroughs always seem obvious and trivial in hindsight, but it was a non-engineer that came up with it. Another example he cited was a time when one of the users came over to a developer’s machine for a feature demo. While the develper was getting things set up, the user looked over his shoulder at the code and commented, “Does this do what I think it’s doing? If so, that’s not right.” Because the code used the domain language for object names and methods, he was able to understand it well enough to spot a bug.

Another thing Phil and his team learned is that the database schema is not the model. The model is the code — even though sometimes people get a false sense that if something isn’t in the database, it isn’t really the model.

He also talked about the utility of “value” objects. In Domain Driven Design, “entities” are the big stars, representing the main business objects. But it can be really valuable to have small, simple objects as helpers to the entities. These are objects that might just be represented as a string or an int, but if you discover some logic associated with that particular kind of string or int, encapsulating that logic into a slightly more specialized object can result in simpler entities.

Facebook Architecture (Aditya Agarwal)

I took a break from the DDD track to hear a little about the architecture of Facebook. Aditya is the director of engineering at Facebook, and after hearing his presentation, I came to a couple of conclusions:

1. I haven’t ever had to worry about scalability anywhere near this, and
2. I’m kind of glad about that.

Facebook is built on the LAMP stack, but pretty much every component has been customized and optimized for their particular application. They also use memcached, which Aditya said was a huge factor in the performance of the site. This agreed nicely with Tim Bray’s talk from the other day: databases are too slow for this kind of scalability. Aditya said their memcache distributed hash table consumes 25 terabytes of RAM.

When asked if they intend to submit their changes to LAMP components back into the main projects, Aditya said, “I don’t think they’d accept our hacks,” which got a chuckle from the audience. The slightly cynical part of me thought, that’d be an interesting way to keep from having to share GPL changes: saying, “Naw, you wouldn’t really want this hacked up stuff…”

Strategic Design (Eric Evans)

Back to the DDD track, to hear “Mr. Domain Driven Design” himself. His premise for this talk was:

Not all of a large system will be well-designed.

We wish it isn’t so, but it just seems to be a fact of life. He then talked about the oh so common situation that a development team finds itself in. We’ve got this legacy system, and it has all the problems that typically make us unhappy with legacy systems: poor design, old technologies, accidental complexity, etc. So what do we do?

Plan A: Scrap it and start over. Eric had a diagram showing the big ball of mud becoming this beautiful pyramid of a system. What ends up really happening? Everything seems fabulous at first as a solid base gets built up. Then, at the point where parity with the legacy system is supposed to appear, panic sets in. The is the classic case documented by Joel Spolsky where you suddenly realize that all that seemingly pointless cruft was actually important. So you finally end up with a system, two years later, that does exactly what the original system did, and that final phase of “add cool new features” never seems to happen.

Plan B: Refactor. Eric argued that this approach doesn’t really work either. There aren’t enough tests to really work something over, and while you’re trying, other people are continuing to hack the code base and mess up your perfect plans. He joked that the hackers are irresistibly drawn to the code that you just cleaned up.

Plan C: Plan to hack, since that seems like what will happen anyway.

Leaving behind the plans for a while, Eric talked about the different parts of the domain. He said that this is covered in chapter 15 of his book, but I’ll try to summarize as I understood it from the talk.

The biggest part is the generic subdomain. This is all the framework and code that is pretty generic and applicable across the whole software development practise. Next is the supporting subdomain, which is code that starts to be more specific to the problem domain you’re working in, but could still be applied somewhat generically in a specific industry. Finally, the smallest bit, is the core domain. This is what makes your system worth building in the first place. This is what gives you your competitive advantage. This is why people will buy your stuff. Another perspective of the three levels is stuff you buy, stuff you outsource, and stuff you build, respectively.

Next, a question: Why do irresponsible programmers become heroes? It’s largely due to mistakes that responsible programmers make. What do responsible programmers do? They build frameworks because they don’t trust that the hackers can build something without some kind of scaffolding. They go around cleaning up other people’s messes. As a result of these, they don’t produce the sexy new features, and shield the hackers from the consequences of their poor practices. The key, though, is that the heroes are working in the core domain.

Plan D: Distill the core domain from the ball of mud. Instead of considering the legacy system a liability, look for the assets. Build what Eric calls an Anti-Corruption Layer, which sounded kind of like the façade pattern to me. Instead of transforming the ball of mud into a beautiful pyramid, focus on building the very cap of the pyramid (the core domain) and making that beautiful, while connecting to the ball of mud as necessary, but with a clear insulating layer.

This topic is really intriguing to me, but I can’t say that I understand how to apply it. Eric remarked that all of this stuff is in his book, but being toward the end, some people don’t, uh, quite make it that far. Guilty as charged. Well, although I’ve got the book, I haven’t really made a serious effort to read it yet. Maybe it’s time to fix that.

Publishing and Protecting the Model (David Laribee)

Since Eric Evans’ talk was so good, I thought I’d finish out the day with the last talk in the DDD track. This was by David Laribee, who is billed as the ALT.NET ring leader. ALT.NET is a community that I’ll unfairly and over simply summarize as “I can write C# on a Mac”.

Dave’s talk was about keeping the model clean, given that it has to be exposed to the unwashed masses to be useful. Or something like that. Maybe after three full days of presentations I was just full, or maybe Dave wanted a cool presentation more than a pragmatic one, but I had a hard time following this one. It started out at a high philosophical level, and by philosophical I mean classically so: Plato and Aristotle. It ended with C# 3.0 extension methods. I’m sure I’m not doing it justice.

Shifting Storage (Tim Bray)

The day started with a keynote from Tim Bray, of XML fame. Tim spoke about the application stack from this perspective:

• Application code
• Object-relational mapping
• SQL engine
• Operating system/file system
• Cache/disks

He mainly focused on the O/R mapping layer and the SQL engine, where technology, to quote Tim, “sucks”. O/R mapping is really hard, and it’s too bad that object databases never really got commercial success (Martin Fowler in the front row nods in agreement). SQL engines are too slow, driving people to distributed hash tables like memcached instead, or even skipping the database engine entirely to go to the file system. SQL engines are also complex and laden with features that never get used. This is inspiring projects like Drizzle, a database forked from MySQL in an attempt to slim things down.

Tim also had good things to say about CouchDB, a document-oriented database that is accessible only via HTTP. I don’t know anything about this project, but Tim’s exact words were, “I’m infatuated with this” and “frighteningly elegant”.

Another topic was comparing the relative speeds of the storage stack, from CPU registers down to hard drives. The interesting technology coming into this area is solid state drives. His benchmarks show that write speeds are about that of a middling hard drive, but read speeds are really, really good.

Given that most web applications are I/O limited, it can really pay off to keep your eyes on up and coming technologies like alternate data strategies and solid state drives.

HTTP Status Report (Mark Nottingham)

I went over to the REST track for a little bit, chaired by Jim Webber, a noted expert on man boobs. The speaker for this session, though, was Mark Nottingham, the chair of the HTTPbis working group. They are essentially rewriting the HTTP 1.1 spec, but not trying to add any new features. Why bother? Mark explained that the existing spec is ambiguous, not well organized, not very approachable, and occasionally requires consultation with one of the authors to understand. As a result, everybody pretty much gets the main parts right, but there are a bunch of other things that are not very interoperable between implementations. HTTPbis, targeted for completion in about six months, will hopefully clarify the spec enough to eliminate incompatibilities.

Mark also spoke briefly about what might be expected for the future of HTTP, like a standard set of conformance tests, better authentication, transport over SCTP instead of TCP, and others.

Joys and Pains of Long-Lived Code (Jeremy Miller)

I had just read Jeremy’s Cohesion and Coupling article in MSDN last week, so it was nice to put a name to the face. Jeremy gave a retrospective of StructureMap, an IoC container he has been writing and maintaining over the past five years. He talked about the changes that have happened over the life of the project, both in the .NET community and the .NET platform itself, and how things he had done with StructureMap made adapting to those changes easy or hard.

These are some of the lessons he learned.

• Good design at the class level is crucial.
• Bad tests make it harder to change the code rather than easier.
• TDD as refined to BDD is best (I need to learn more about this).
• Getting abstractions right not only improves the code, it opens up new possibilities.
• DRY – even a little duplication is bad.

I also appreciated a comment he made when answering a question: don’t use an IoC container when writing tests. I’ve seen people do that in the past: they have a constructor injected set of dependencies and try to reconfigure the container to inject mocks. Just pass the mocks in the constructor!

F# (Don Syme)

While I have heard a bit about F#, I’ve not really spent much time trying to understand it. What better opportunity could you have than to get the designer to provide an introduction? Of course learning a language is best done by writing code, not hearing a presentation. Still it was interesting to get a high-level overview and to see a few examples. One of Don’s favorite things was to show the difference in lines of code between functionally equivalent bits of C# and F#. An asynchronous I/O example had three pages of C# code to a dozen lines of F#.

Don said that F# is well-suited to problems dealing with data transformation, but not so great for building user interfaces (even though all the .NET UI libraries are accessible from F#).

TDD and DbC (Greg Young)

I’ve posted about design by contract in the past (part 1, part 2), and sort of intended to talk about unit testing and DbC at some point, but never got around to it. So I was interested to hear what Greg had to say. The first part of his talk was an overview of DbC, showing some spec# code to demonstrate the concepts and letting the code verifier find the problems. I noticed that Microsoft had announced a contracts library at PDC, so the exploratory work of spec# will be incorporated into the framework instead of as language extensions.

The main point of Greg’s presentation is that tests and contracts are complimentary. Tests should focus on the behavior (another reference to BDD) while contracts focus on constraints. Having contracts means fewer tests to write because you don’t have to write all the dumb tests that check that an argument exception is thrown when parameter x is null. In fact, not only do you not need to write those tests, if you try anyway the code verifier will complain. So you almost can’t write those tests, and therefore contracts push you toward testing the meaningful behavior of the code.

Democratizing the Cloud – MS Volta (Erik Meijer)

I’m again impressed with the caliber of speakers here. Eric Meijer is the guy who designed LINQ, among other things. Currently he is working on Volta, which put bluntly, is GWT for .NET. Volta allows translation of MSIL to Javascript so that you can build client apps writing .NET code. If you happen to have Silverlight on the client, you can also target that as the runtime environment instead of going to Javascript.

There is also a development work flow in which you write a single tiered .NET application, then split it into client and server tiers by simply annotating the code — saying which bits should execute on the server and which on the client. Greg Young, from the previous presentation, immediately started pushing back citing the 8 fallacies of distributed computing. Erik simply skipped ahead a little to a slide showing the 8 fallacies, and assured the audience that programmers would still be in control enough to avoid the pain.

Erik’s description of the translation of IL to Javascript was interesting. They are not making any attempt to produce Javascript that follows typical Javascript style. Instead they use it like an assembly language, and focus on preserving the precise semantics of the .NET code. This gets a little tricky in some cases, such as jumps. Javascript has no goto, but IL, being very low-level, uses them extensively. Erik showed how they used switch statements to get the same behavior. It’s not pretty Javascript, but that’s not really the point.

The presentation went down a little bit of a rat-hole when Erik talked about some security issues. There was quite a bit of debate from some folks the audience about whether they were doing it right. While it’s neat to see that kind of interaction, I’m not sure it is a good use of time for people seeing this for the first time to try to give informed design criticism.

Volta is still a work-in-progress. It will be interesting to see if it can mature into something that will give as great a development experience as Alex Moffat described yesterday with GWT.

Agilists and Architects (Martin Fowler & Rebecca Parsons)

As much of Martin Fowler’s stuff as I’ve read, I hadn’t ever heard him speak in person. He and Rebecca talked about software architects, including some of the stereotypical ivory tower thinkers that come up with beautiful, elegant systems that have no possibility of actually working in the real world. A video clip from The Matrix Reloaded set the tone: the architect of the matrix considers Neo to be an aberration in his otherwise mathematically perfect construct.

Part of the problem with architecture is that it is hard to define. It may be simply design when we want to make it sound more important. I remember a guy I used to work with for whom everything was architecture. “If you think about the architecture of these two classes…” Martin liked Ralph Johnson’s definition of an architect as the person who thinks about the hard stuff — whatever that happens to be for a particular organization.

Another problem is that architects have a hard time defining success for their role, and an even harder time attaining it. Sometimes that’s because of organizational dysfunction, like companies that insist that architects not write any code. Other times it is through poor practices, like inventing frameworks in anticipation of a yet unproven need.

The speakers emphasized, however, that architecture has a useful role in spite of some of the difficulties with having it filled effectively. The architect is the one who worries about supportability, rampant proliferation of tools, and keeps in mind the grand vision of the product. They are also responsible for the quality of the code, which is not just an abstract, academic thing once the code works. The quality of the code has a real cost that is realized when new features need to be added. It can be hard to make that cost visible to people, but one approach suggested might be to give two estimates: one for the new feature built into the mess we’ve currently got and one for the imaginary clean system we wish we had. I don’t know, that still sounds kind of hard.

Web as Platform (John Musser)

John is the founder of Programmableweb.com, a sort of catalog site for various APIs available over the Internet. In his presentation, he talked about trends in web APIs. Some trends are technical such as the rising use of REST vs. SOAP (though since REST is more a philosophy than a standard, it can be hard to classify something as REST as opposed to REST-ish). Other trends are around the ubiquity of APIs — it is now expected that if you put useful functionality on the web that it will have an API, and not just a user interface. Even media producers like The New York Times and NPR have APIs.

What makes a good web API? First and foremost, the underlying service has to be valuable. Beyond that, the API should support the business model of the provider (eBay wants to optimize adding listings since that’s how they make money) and should be easy to access both in terms of openness and the developer support provided.

Hard Rock: Silverlight 2 (Scott Stanfield)

Scott is the CEO of Vertigo, a consulting firm that was named Microsoft partner of the year for 2008. It was nice to have some Microsoft technical representation since the conference so far seems heavier on the Java side. Scott spoke about building the Hard Rock Memorabilia site working with marketing firm Duncan/Channon. Duncan/Channon originally intended that the site be done using Flash, but Deep Zoom turned out to be the killer feature that made Silverlight the clear choice.

Scott said that the Silverlight story of independent graphic design and programming is completely playing out as advertised. He showed a little demo of an Etch-A-Sketch app that Vertigo programmer Michael Moser quickly coded up, but was then beautifully skinned by a graphic artist.

Scott also asserted that the adaptive streaming of video in Silverlight gives the best video on the web.

One interesting tidbit on the Hard Rock site is that Vertigo spent some significant effort getting a set of different sized pictures to line up in such a way that the final arrangement creates a nice rectangle. This looks like possibly a variation of the packing problem to me.

Also interesting was that Scott was using a Mac with Vista running in a VM. Come to think of it, all the presenters in the RIA track seemed to have Macs.

Flex and AIR in the Trenches (Scott Delap)

Scott Delap gave a presentation about using Adobe tools to build some online components of a video game, League of Legends. His perspective was comparing Flash/Flex to doing Java UI development with Swing. He seemed reasonably happy with the platform and development tools, but thought that things felt sort of like Java year 2000. That is, not quite up to state-of-the art. He is, however, a convert to declarative UI specification. Like the Java UI developers I’ve known, he never really trusted visual designers for Swing, but says the designer experience with Flash is great.

Scott talked about evaluating a lot of frameworks for various things (dependency injection, remoting, unit testing, functional testing, etc.) which is a typical exercise for open source development stacks.

10 Ways to Improve Your Code (Neal Ford)

This talk covers some of the same material that is in Neal’s book The Productive Programmer. I sort of got the impression that maybe after writing a book and giving this presentation who knows how many times that Neal might have lost some of the passion associated with this topic. That’s not to say that the presentation was dull, it just seemed a little like, “OK, here we go again…”

Neal’s 10 points were mostly things I know (and even do successfully at times) such as TDD, using static analysis, YAGNI, etc. There was an interesting point on polyglot programming. He said that polyglot programming ideally doesn’t mean multiple platforms, but multiple languages on a single platform. Java and .NET are both multilingual platforms, so take advantage of that to use the best language for the problem at hand while still keeping the benefits of a common runtime environment.

As an intermission, Neal talked about 10 bad smells, my favorite of which was “Our lawyers say we can’t use any open source software”, which led to Neal having to buy a “license” for CruiseControl (written by Neal’s employer, ThoughtWorks) so he could use it with a client.

Real World GWT (Alex Moffat)

In short, Alex and his team love GWT. And I have to say that seeing Blueprint in action was pretty spectacular. It really looked like a desktop application, but done entirely with HTML and Javascript. GWT is the magic behind it all, which is Google’s toolkit for compiling Java to Javascript.

If you work in a Java shop, it seems like a great development story: use all your familiar tools and write Java code and you get a great web app.

Just You Wait (Kent Beck)

Kent Beck, like Martin Fowler, is another industry heavyweight that I first heard speak today. He got started a little late because his talk came right after the break in which beer was served, and I guess it’s hard to compete with that. Being a non-drinker, I had a seat right up front.

His talk was as an amateur futurist, looking at trends and imagining where they might go, and unintended consequnces. For example, what happens if you extend the trend of releasing software more frequently? Maybe releasing software with every keystroke? Well, OK, editing a live web site would almost be that (if your editor saved continuously).

Some other trends he expects are the end of “free” stuff on the web, and a decrease in status for programmers as other people begin to understand technology more and programming seems less mystical. Even if that latter point proves true, he says that we can still make a difference in the world with what we build, and how we build it.

Thinking of the Brazilians that were recognized in attendance, I flinched a little during the talk when Kent digressed slightly about how his son says “cool”, but to be really cool leaves off the ‘L’. There’s another unintended consequence for you, riffing on a word that is vulgar in Portuguese.

An example of an expert forgetting the jargon of “user story” is in a small section of Mike Cohn’s otherwise great book User Stories Applied. Here, the author is talking about the benefits of user stories over other ways of specifying requirements:

Additionally, a study in the late 1970s found that people are better able to remember events if they are organized into stories (Bower, Black and Turner 1979). Even better, study participants had better recall of both stated actions as well as inferred actions. That is, not only do stories facilitate recall of stated actions, they facilitate recall of the unstated actions. The stories we write can be more terse than traditional requirement specifications or even use cases, and because they are written and discussed as stories, recall will be greater. 

While I haven’t read the study mentioned (maybe this is the abstract?) I doubt they were studying agile “user stories” back in 1979. From what I’ve been able to gather from secondary sources, they were studying how stories (in the narrative sense) have a more abstract representation than the actual words that are said, and that memory relies more on that abstract representation such that it’s hard to remember if something was explicitly said in the story or just implied.

In short, applying the results of this study to user stories is pretty bogus.

“That’s stupid, there’s nothing here!” I remember saying, a bit more harshly than was appropriate. I think my mom was a little taken aback, and didn’t bother to try to justify why the place deserved to have a name: It separates Utah valley from the Salt Lake Valley, and the counties with corresponding names; it’s the highest point on I-15 through the Wasatch Front and the place you’ll most likely hit snowy roads.

I realized later that I was just experiencing culture shock. After an email discussion with a coworker today, I realized that culture shock is possible between programming environments.

My coworker was announcing that he was going to create a new class for working with file paths, because the .NET classes FileInfo and DirectoryInfo were unintuitive, awkward and poorly conceived. Among his concerns was that it seemed stupid that FileInfo.Exists on a path returns false even if there is a directory there. You have to use DirectoryInfo.Exists to know if there is a directory at a particular location. He had a couple of other complaints as well, but I want to focus on this one.

My coworker is a proficient Java programmer, and if you look at the .NET Framework design decision to have both FileInfo and DirectoryInfo from the perspective of someone coming from java.io.File, you can understand his discomfort.

At the same time, I can imagine a .NET programmer deciding that java.io.File is messed up. Where’s the logic behind File.isAFile()? That’s like Apple.isAnApple(). And isn’t it really awkward that in order to know if a file (and not a directory) exists, I have to use both File.exists() and File.isAFile()? Ah for the simplicity of FileInfo.Exists!

I began to think that his complaints in this respect were more a matter of Java to .NET culture shock — it’s not what he expects, so .NET is wrong. That’s not to say that I’m dismissing his concern by giving it a label, but I’m noticing that it is an important thing to be aware of as you become familiar with a new environment. It’s really easy to flip the bozo bit when you see something new that you don’t immediately understand. And I think it is a mistake to reject the idioms and patterns of a programming environment because they’re not like back home.

For a sort of ridiculous example, consider an English speaker learning German. Compared to German, English is a fairly genderless language. Don’t the Germans understand, though, that getting rid of gender would be so much more efficient? Instead of having to remember nouns andtheir gender, I can just remember the noun itself. Therefore, when I speak german, I’m just going to say “the” instead of the pointlessly complex “der”, “die” and “das”.

I also realize that I’m currently suffering from reverse culture shock. I used to write a lot of Java code myself, and absolutely loved JetBrains IntelliJ. I was thrilled with the discovery of each well-crafted feature. It was agonizing to have to go back to Visual Studio in order to write some native code.

But then I had to spend more and more of my time doing native development. Visual Studio 2005 came out and life started getting better (hallelujah! I can do a “rename” refactoring!). If I ever had occasion to get back into the Java code to look at something, I’d double-click the IntelliJ icon and then get out a magazine. Five minutes later the application and project would finally be loaded and ready to work with. And good grief, look at the memory footprint of that thing.

Java? IntelliJ? Eh.

But I do think “point of the mountain” is just as natural as can be now.

I use FrontPage 2000 to write my articles. Then I run an Ant script that uses the HTML content of the site to build an RSS feed, a home page with recent articles, the archive page, a Google site map and finally run the content through an XSLT to apply the common page elements.

Since FrontPage 2000 doesn’t output, or even tolerate XHTML, I use a custom Ant task, styler, that lets you do XSLT transformations on HTML pages, even when they aren’t actually XML. My poorly formed result pages were the result of an XPath goof of selecting html/body when I should have done html/body/*.

But I started to take a look at the community technology preview of Microsoft’s new Expression Web Designer, which is one of the successors of FrontPage. It supports XHTML, which might make me finally upgrade when it comes out. I wondered if I could replace a bunch of the stuff in my Ant script by just using Web Designer features.

The first interesting thing was Dynamic Web Templates, which are actually a FrontPage 2003 feature. They provide essentially the same functionality as my XSLT transformation — centralizing all the common page elements into a single place. There were a couple of things that bothered me about the feature, though. First, every time you save the template page, it asks if you want to update all the pages that use it. I guess the idea is that you won’t edit your template much once you get it right, but for habitually frequent savers like myself, it was a little annoying. Second, when doing real writing of content, Web Designer shows a dimmed template and provides you an editable area where the content ends up. Maybe I’m just quirky, but I’d rather compose articles in a pretty minimal layout. I don’t really need my site banner and search side bar — just give me a nice plain HTML editing surface, please, with a simple CSS for fonts. In fact, that’s really how I’d prefer my articles to be anyway — nice simple XHTML instead of being filled with automatically replicated layout tables and presentation-oriented div tags.

Next I decided to take a look at ASP.NET 2.0. I’m pretty ignorant of all versions of ASP, to be honest. But I worked on a web application before ASP 1.0 ever came out, building something that maybe would have been kind of like SharePoint had NextPage had a hundred times the resources that we did. We had to build our own presentation framework, and it suffered from neglect even when we started to learn some things about how to build web applications but had more pressing requirements.

In my foray into ASP.NET, I learned about master pages, which functionally overlap with Dynamic Web Templates but are in fact dynamic, whereas Dynamic Web Templates are, from a typical programmer point of view, static.

A master page has placeholders for content, like this:

... <body> <asp:contentplaceholder id="Body" runat="server"/> </body> ...

When creating the content to go in that placeholder, I initially thought I’d be able to create a nice XHTML page, sullied only slightly by some extra ASP tags to match up with the placeholders in the master document. That’s not the case. The content page can only have the blocks of ASP tags:

<!--Page language="C#" title="My Content Page"--> 
<content runat="server" contentplaceholderid="Body" id="Content1">  
 
OK, here is my body text. 
 
</content>

If you have more than one placeholder in the master, you have the same number of top-level asp:Content tags in the content page. So what is this strange thing that I’m supposed to store my content in? It’s not HTML — you’re not even allowed to have an <html> tag in the page. It’s certainly not XML because there’s no root element if there are multiple content blocks. So how are you supposed to author your content?

Of course you can author in plain text, writing markup by hand, but that seems kind of primitive. You can use Visual Studio, but that doesn’t give you spell checking or a UI geared toward English composition. Finally there’s Web Designer, but the rendering is messed up (but it’s only a CTP after all) and it has the same “edit in full context” UI as Dynamic Web Templates. And what do you end up with when you’re done authoring? Some non-standard text file.

People tend to agree that XHTML to the browser is a good thing, but isn’t it a good thing for authoring, too? A variety of authoring tools exist, and it’s so much easier to manipulate source material in XHTML. But master pages seem only concerned with good markup for the browser delivery portion of a document’s lifecycle.

I’d like to learn ASP.NET better at some point — I’m sure it’s excellent for lots of things, but the master page system doesn’t feel right to me. My XSLT approach feels better — clean source documents combined with a “master page” that pulls in the appropriate content. The content pages don’t have any special markup saying “this section will go into some other page at location X”, they just have markup.

So I decided to stick with my current system, fixing the body problem and taking advantage of Web Designer and HTML Tidy to have XHTML sources and XHTML delivery. I’m content with it… for now, anyway.

J. Ambrose Little wrote an editorial about object-oriented design vs. data-oriented design that solidified some vague thoughts I’ve had about how one should go about building software. It has always seemed strange to me when people start application design based on what the database tables are going to be, but I thought that might be just due to my own ignorance.

In his article, Little’s main point is that applications are frequently built by shoehorning the domain into a DataSet instead of building objects specific to the domain. In other words, many people are still not doing object-oriented design and programming, and gaining the benefits of domain-specific abstractions. One reason for this is that Microsoft tools make DataSets really easy. I’ve found that, while sometimes seeming like a second-class citizen, I’m able to use DataSet-like functionality like data binding in Windows Forms with my own custom objects with reasonably good results.

I’m sure I still need to become better acquainted with traditional database development, but hopefully my experience will allow a balanced view of how to design such systems.

Design by Contract Part 1

Benefits of Language Support

These are some of the benefits of having language support for design by contract:

• Automatic invariant checking upon exiting methods, without any extra effort like calling a helper routine or creating some kind of automatic object that checks invariants when it goes out of scope.
• An “old” keyword that provides easy syntax for referencing the state of variables as they were before the current method began executing.
• Contracts are automatically cumulative down an inheritance tree. In other words, if the base class has a contract, any subclasses automatically have that contract.
• Related to the point above, language support can also help ensure that contracts on overridden methods follow the rules of contract inheritance: preconditions can only be the same or weaker, and postconditions can only be the same or stronger.
• Contracts can be part of declarations. For example, if you are trying to simulate DBC in C++, you can’t put the contracts in the header file except as comments.
• Contracts will probably be understood by a debugger, which might be more convenient than debugging something like the output of a preprocessor in the absence of language support.

Languages Supporting Design By Contract

Obviously Eiffel supports design by contract. I haven’t personally used Eiffel for a programming project. There is, though, a version of Eiffel that compiles to MSIL, so if you’re a .NET shop, maybe it’s a real possibility.

Another language with contract support is the D Programming Language. D is kind of a cool language in its own right. It has a lot of the conveniences of “modern” languages like Java and C#, but it compiles to native binary code instead of an intermediate code requiring a big run-time environment to execute. It is still a bit immature, and lacks much industry support, but I kind of wish it would catch on. The creator of the language, Walter Bright, has written an excellent essay about the design by contract support, comparing it to how one would attempt similar functionality in C++.

Preprocessors and Libraries

In the book, Mitchell and McKim give examples in Java using a free preprocessor called iContract. It lets you do DBC by writing special Javadoc comments which the preprocessor then converts to Java code. I’m not sure what the current status of iContract is, though, since the book’s reference to iContract’s source, http://www.reliable-system.com, has a big for sale sign on it. Links to the book’s own web site are also broken, though if you’re persistent you can find the publisher’s site for the book that has even more broken links on it. There’s an iContract Ant task, but I’m not sure how to get a hold of the preprocessor itself such that the task will work. The Ant documentation points to the same broken links as elsewhere. 

For C++, the best DBC library I’ve come across was posted on The Code Project by Jarl Lindrud. I haven’t had a chance to use it, but it looks promising. It makes heavy use of the magical Boost bind and lambda modules to pretty good effect.

Adding Language Support

There is research going on to add DBC facilities to existing languages. There is a proposal to extend standard C++ to provide contract support. It adds preconditions and postconditions to methods and invariants to classes and namespaces. Here is an example from the proposal:

int factorial( int n ) 
precondition 
{ 
    0 <= n && n <= 12; 
} 
postcondition( result ) 
{ 
    result >= 1; 
} 
{ 
    if ( n < 2 ) 
        return 1; 
    else 
        return n * factorial( n - 1 ); 
}

The proposal also includes an oldof keyword to support writing postconditions.

In addition to C++, there is also work being done to potentially add contract support to C#. Spec# is the name of the extended language. The researchers claim that contracts in Spec# will be more robust than those in Eiffel, handling some situations that that language didn’t do so well. One really cool aspect of Spec# is its integration with Visual Studio. It does static contract checking on the fly. If you type code that violates a contract, you get the red squiggle. You can download the current implementation from the project page and take it for a spin. In my brief experience, there were some more complicated constructs than are found in Eiffel (such as a concept known as “exposure”), and the documentation was virtually non-existent, but I still remain excited about the potential.

Syntactically Spec# has some nice features. One of the most common preconditions is that some argument is not null. Spec# expresses this with a single character, an exclamation point:

public static void Clear(int[]! xs) 
{ 
  for (int i = 0; i < xs.Length; i++) 
  { 
    xs[i] = 0; 
  } 
}

In this example, you can safely dereference xs without checking for null because the exclamation point in the method signature guarantees that it is non-null.

Spec# also uses keywords requires and ensures, which feel more natural to me than precondition and postcondition, or even Eiffel’s imperative require and ensure. Here’s the C++ example from above translated to Spec# (possibly even correctly?):

public static int factorial( int n ) 
  requires 0 <= n && n <= 12; 
  ensures result >= 1; 
{ 
    if ( n < 2 ) 
        return 1; 
    else 
        return n * factorial( n - 1 ); 
}

There was an MSDN webcast last year on Spec# that I sat in on that gave a good overview of where the project is going, as well as how it is addressing problems beyond what Eiffel does. It is now archived for on-demand viewing.

Conclusion

If you don’t have language support, or some kind of library or preprocessor, you could at the very least assert preconditions. That’s the advice of Mitchell and McKim (see p.205). Much of the benefit of contracts comes from simply thinking about them. Sometimes I’ve thought that the behavior of a function I’m writing is obvious until I stop to consider what the function requires and what it ensures. It adds a level of precision to your work to do that extra thinking.