News flash for developers doing this (such as Intuit, in TurboTax): I’m not thrilled about manually typing my 20 character random password. Just let me copy it from my password vault and paste it into your field.

In the case of TurboTax, it diminishes the value of data import if I have to type more characters for my password than there are numbers on the form to input.

TurboTax's castrated password field

The currently winning smartphone platforms are the gated and guarded community of iOS, and the wild-west of Android. Palm/HP had the vertical integration of Apple with the openness of Google. Maybe in today’s polarized society, the middle has no appeal. But don’t think that when I say “middle” I mean not as good as either extreme — it’s more like the best of both worlds.

Here are some of my favorite features of webOS:

1. Fantastic muti-tasking that no one else has yet matched.
2. A UI that is is richer than iOS and more beautiful than Android.
3. Over-the-air activation/updates/etc. Attaching it to a PC is never required.
4. Unobtrusive notifications that can be ignored without being lost.
5. Merging all of your contacts/calendars from wherever they happen to live.
6. Acceptance that Flash is still a significant web technology.
7. No jailbreaking required – but rather a completely sanctioned developer mode that gives you root access to the device.
8. HTML 5 application development as a first class citizen.
9. C++ application development for gaming, etc.
10. A cloud-based IDE allowing app development in a browser.
11. It is Linux, so skills are transferable.
12. Inductive charging, so you don’t have to plug in cords — just drop it on the charger (OK, technically a hardware feature rather than webOS per se, but still awesome).

I have applications that I wrote myself or with co-workers in both the HP App Catalog and the Apple App Store. I definitely prefer coding in JavaScript as opposed to Objective-C, but the thing that makes my blood boil in comparing the experience is Apple’s provisioning profile system. It’s as if Apple said, “Please poke yourself in the eye at regular intervals so that we can be sure you’ve paid us your developer program fees.” Having developed and submitted for webOS, it becomes obvious how pointless the Apple system is. I wouldn’t go to the trouble for a personal project — but what does Apple care about that?

I haven’t developed for Android, but I like Java, so it could be a good experience. But the Android ecosystem seems like total chaos.

I did do some preliminary investigation into developing a video-centric application for Android, but got stuck when trying to figure out what video decoder support exists for the platform. Sure, there’s something that says H.264 is supported, but at what level and profile? Those are kind of critical to know, but the information just isn’t available. I guess Google just left it up to the device manufacturers to do what they wanted, which means trying to figure it out for every device. Compare that to the webOS information on video formats.

So I find myself in an unfortunate situation, hanging on to an aging phone and not sure what I’d do if I accidentally dropped it on the sidewalk tomorrow. Maybe, like I did the last time Palm imploded (with Palm OS), I’d have to give Windows a try, and hope that it isn’t the soul-less experience it was last time.

Of course, the easy way is to just get the latest from the TFS repository and add all of the files to the new SVN repository, but change history is valuable and I didn’t want to:

1. lose it
2. be required to go back to TFS to get it

I found tfs2svn, a tool written by Kevin Colyar expressly for the purpose of migrating while preserving the change history. If you’re going to run this on a big, mature TFS repository, there are a couple of things you should know:

1. It’s going to take a long time.
2. Stuff is going to go wrong.

This is no disrespect to Kevin — that the tool is available at all is a great help. I also have to confess that I hacked the source code a bit, so there’s a possibility that some of what went wrong was my own fault.

My Scenario

The repository I migrated has about five and a half years of history, comprised of nearly 21,000 changesets. It also had code from several projects, and I really only wanted to migrate a subset of the tree. We already have a Subversion repository with some source in it, so I wanted to get the TFS source into there.

Strategy

My plan was to create a local, temporary Subversion repository into which I could do the conversion. This would let me mess up in various spectacular ways without risk to the real SVN repository that would be the code’s ultimate home. It also seemed like it would be faster than running all of the SVN commands across the network to the Subversion server. Once the migration was done locally, I’d use svnadmin dump to generate a version of the repository that could be imported into the “real” repository with svnadmin load.

I hoped that I’d be able to use tfs2svn to limit the migration to only the parts of the tree that I wanted, but the tool resisted my attempts to do so. I was thinking that I’d run it multiple times, changing the paths to get one relevant top-level  folder at a time. It’s not clear which path to change, though. You’ve got the TFS repository path (which would be a must), the SVN repository path and the SVN working copy path. It turns out that all of those paths are used in different situations by the tool, and I eventually thought it might be best to just migrate the whole thing.

It would be tragic to actually include everything in the final SVN repository, though, given that Subversion doesn’t have a permanent delete feature (that is, “obliterate”). All the stuff I didn’t want to migrate would be forever in the repository. But since I was going to do a dump anyway, I could run dumpfilter to remove the stuff I didn’t want.

The trouble then becomes time. It takes so long to migrate all those TFS changesets into SVN that I very quickly decided I needed to push the filtering forward in the process. This is where the hacking began.

I added a “IncludeChange” check into TfsClientProvider’s ProcessChange method:

private bool ProcessChange(Changeset changeset, Change change)
      {
          if (IncludeChange(change))
          {
              // Process file change.
              if (change.Item.ItemType == ItemType.File)
                  ProcessFileChange(changeset, change);
 
              // Process folder change.
              else if (change.Item.ItemType == ItemType.Folder)
                  ProcessFolderChange(changeset, change);
 
              return true;
          }
          return false;
      }

IncludeChange has a bunch of lines that look like this:

if (change.Item.ServerItem.StartsWith("$/Projects/Main/Applications", StringComparison.OrdinalIgnoreCase)) return false;

This combination skips any changes that were in areas that I didn’t care about. ProcessChange also now returns a boolean to indicate whether anything from the changeset needs to be committed in Subversion, saving additional time by skipping an unneeded operation.

Problems

One of the really good things about tfs2svn is the Start at Changeset# field. When something goes wrong, you can always start back up where you left off — even if you have to exit the program. Sometimes tfs2svn will even offer to fill in the Start at Changeset# field for you when it’s about to report an error.

These are some of the things that went wrong.

At first I was getting an obscure Error resolving case of [some path]. Hard to figure out, but easy to fix: I just needed to take the trailing backslash off the Working copy folder.

I also ran into a problem when a changeset moved some files from a place that I was excluding to a place that I wasn’t excluding. That didn’t turn out so well since the source files didn’t exist, having been skipped by my IncludeChange method. This was fairly early on, so I just decided to start over and not exclude the source path. I might have been able to get a copy of the files and add them to SVN in the appropriate place and retry, though.

Directory deletes in TFS frequently caused trouble in the conversion. They would result in an unresolved conflict on the directory and the commit would fail. In these cases, I just marked the conflict resolved, committed manually and skipped to the next changeset. You lose some of the history in these cases by doing that, though.

Directory adds also caused troubles at times. The tool would try to add a file to a directory that hadn’t been created yet. To fix those, I just created the directory by hand and added it to SVN and retried the problematic changeset.

There was one situation where some file renames weren’t working at all. The original files didn’t exist and the destination files did. I kind of mangled that changeset, but fortunately I knew that those files were obsolete and would all be deleted in a later changeset, so I didn’t care much about them anyway. I think this was probably caused by a situation where part of a changeset had been processed, but then there was an error. Retrying the changeset meant it tried to redo some moves that were already done.

Finally, there were some times when the network would timeout, or Subversion would report that a file or directory was corrupt or unreadable. In those cases, I just tried again and was always successful the next time.

With these errors popping up, tfs2svn required a lot of babysitting to notice the error, make a fix and get it going again. That unfortunately added to the total time span since it would invariably stop when you were busy with something else, or when you hoped to make good progress letting it run overnight.

Finish

Once the migration was done, svnadmin dump was relatively quick and completely painless. Once I could get some of IT’s time (someone with direct access to the Subversion server), the load also was quick and easy.

Update (4 Feb 2011)

I’ve noticed another problem in the migrated history. Sometimes the author of a change seems to be incorrect. According to the history, a developer from another team did some work that would be extremely unlikely if it were true. I haven’t figured this one out yet…

Update (22 Mar 2011)

A possible explanation for the “The file or directory is corrupted and unreadable” errors is a bug in Windows 7. The bug fix is included in Windows 7 SP1, which you can get through Windows Update.

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 Macbooks at 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.