Lars Wilhelmsen

In the first installment of this pre-PDC blog post series, I published the list of the sessions I’ll likely attend and a list of sessions that would be cool to see, but that isn’t really target material (for me).

Microsoft has now published the time & location of each session, and I must say that I’m (at least at the moment) quite disappointed that www.microsoftpdc.com lacks two important features:

• Export to Outlook / ICS. Both for single sessions and the possibility to link the whole My Sessions view into Outlook.
• An Outlook-ish calendar view, that visualize conflicting sessions (Just like my normal Outlook calendar – when my coworkers book me for three different meetings at the same time ).

That said, I hope Microsoft hasn’t revealed all features of the PDC website yet.

Since I haven’t found the floor map for LACC on www.microsoftpdc.com (yet), I’ve scanned the floor plans from PDC ‘08. Click the picture to bring up a larger version. Note that the layout of stands/booths in the Expo area are probably different from what it will be this year.

Since it’s getting closer to my departure, I’ll put up a list of stuff I’m bringing both for the trip and stay – hopefully, there may be a trick or two for a first-timer travelling to a large conference.

• Be sure to bring your passport if you’re traveling in from another country. If you’re a resident of a country in the European Union, or another country that is covered by the ESTA Visa waiver “program”, you need to register yourself here before you travel.
• Business Cards – network, share and LinkedIn later.
• Money / credit cards – Mo’ money, mo’ problems? Tips: bring at least two major credit/debit cards (VISA, Eurocard, Amex) and leave one your hotel room’s safe.
• Sun glasses / Hat / Sunscreen. Here in Norway it’s mostly dark at this time of the year, but in LA, the sun is hot – protect yourself from those nasty UV rays.
• Pocket camera / phone: voice/txt/twitter et cetera.
• Computer(s): I’m bringing my Dell Precision M4400 and Latitude E4300. The latter is perfect to bring to the LACC at daytime – the first one is my portable workstation. I have a US power chord to my laptop’s power supplies – it’s always a hassle to bring an extra power converter to the conference center.
• Fiber, fiber, fiber. Well – how should I put it? The American (conference) diet SUCKS. No fiber – and a lot of sugar. I need my fiber, or I’ll turn up constipated and grumpy.
• Omega-3, Ginseng, vitamins: when traveling, remember to super charge on extra vitamins etc. An exhaustive week with jet lag and activities from 6 in the morning to late night does something to your body.
• Sleeping aids; I’ve found some prescription-free sleeping aids that are available in the drug stores (in the US). Be sure to buy some before you leave.
• NoDoz caffeine pills. Generally, I don’t like to pop these – but I bring them for emergency situations.
• A good carry-on laptop bag that you can’t stuff more than a tiny computer in is at least vital to me. I’m not sure if it is to you – YMMV.

Warning: coming up is an ugly formatted HTML table with some pictures to give you a mental note if some of the items you shouldn’t forget at home Mouse-over will give you a description of each item.

A last note before I end this blog post; I love TripIt as a tool to organize my trips – it’s also great for sharing information with people you’re traveling with – or people that may be in the neighborhood during your stay.

So, we’ve reached November 1st – the day after Halloween and it’s only 15 days to the PDC! (Woohoo! )

I’m travelling with two of my colleagues and we’re staying at the Omni from the 14th, send me a message (typically on Twitter: larsw) if you want to hang out before / during the conference.

A couple of days ago (give or take) Microsoft enabled the “My Sessions” feature at www.microsoftpdc.com, and today I’m presenting my first draft of my planned session list. I’m already sure of two things; a) I’ve overbooked, and b) during in the “fog of war” I won’t make it to all of the sessions.

Since I’m a Connected Systems guy, it shouldn’t come as a surprise for anyone that my session list is very CS-centric, but my #2 priority is to attend sessions about features/technology that I really want to learn more about (e.g. where I’m more or less a n00b now

Since the sessions aren’t “mapped out” yet (at least not on the public site) I’ll have to wait a bit before I can do the hard prioritization.

Now, I’m pretty, pretty sure that when I sum up after the PDC, the list of sessions that I’ve actually attended will be quite different

From browsing through the 22 pages of sessions, I’m a bit disappointed that we won’t see Anders Hejlsberg on stage (at least not in a normal session).

Build error: Value cannot be null. Parameter name: path1.

Now that’s a cryptic title, right?

First of all; a big thanks to Jason Barile/MSFT that set me in contact with Aaron Hallberg that in turned found a workaround for the bug I’m about to describe.

Second; The bug is fixed in MSFTs trunk version of TFS 2010, so you don’t need to run over to connect.microsoft.com to report it.

With the release of the Visual Studio 2010 and Team Foundation Server 2010, I thought it would be cool to check out the new TFS Basic mode running locally on one of my laptops.

I was amazed that the whole installation process took only about 20 minutes – something that is way better than the near-nightmare scenario of installing a full TFS 2005 or 2008 (I haven’t tried to setup a full scale TFS 2010 yet).

In addition to the TFS 2010 itself, I also installed the Team Build Controller and Team Build Agent locally on the same laptop (and of course Visual Studio 2010 Ultimate).

I imported a small pet project / demo I’m working on into the source control, and set up a build definition for it so that I could do continuous integration builds when checking in future changes.

Right-click.
Queue new build…
Building…
Bang. Build Error

Now, I tried all sorts of things to try to figure out what caused the build failure, and I got some input from Jason Barile, that didn’t work out either (turned out that I’ve set the build server’s working directory to the same directory for it to drop the result to).

Luckily, I twittered my need for someone that could take a look at my problem, and that’s where Jason entered the scene; we did a SharedView session, and as I’ve already written, we didn’t get very far. But Jason works with a brilliant guy named Aaron, that was more than willing to take a look at the problem too.

We did a SharedView where we discussed what I’ve already tried, and tried to narrow down the possible things that could mess up my build. After checking up a bit internally, Aaron came back with a small piece of source code we checked out locally; a bit of code that tries to infer the location of MSBuild.

Well, it  turned out that when it parsed a value from the registry (or something) it took my current regional settings into account, and here in Norway we use , (comma) as a decimal separator – something that is different from the US standard; . (period.

The fix for it was to hardcode the path to msbuild in the BuildTemplate.xaml file that is actually the workflow that is used by the build server. Aaron sent me a version that I plugged in – and bam! Green build!

Thanks again Jason & Aaron – I love the openness a great attitude of every MSFT employee I’ve met so far

The modified .xaml file can be downloaded from here.

Hi, and apologies for being so awfully quiet the last couple of months. Expect the traffic to pick up again (I’ll explain the silence in a blog post later).

Now, when unit testing WCF Services, I’ve often ended up with cluttering my tests with a lot of plumbing code to wire up the SUT; that is – the WCF service I want to exercise.

Now, being a lazy guy, wiring up (redundant) plumbing code again and again, I often end up trying to extract the essence and put together a tool or helper class.

So, this is my first shot of a fluent helper class that lets you test your WCF services.

The screenshot below pretty much sums up the functionality. It should be pretty self explaining; You end up writing an Action<TContract> implementation that acts as the client.

It will wire up an OperationContextScope automatically, but it can be disabled if you don’t need it.

The state/quality of the code is “Proof of Concept” and can be found here.

Hi,

I’m about to move the blog to a new more sane hosting provider that wordpress.com. If the blog is temporarily out of order, please go to the alias for this site larsw.wordpress.com instead. Thank you.

Update 2009/06/02: Transition to the new hosting provider should now be done. Please contact me if experience any errors.

From time to time, I need to “restock” my book shelfs, e.g. order a batch of Computer Science-related books from Amazon.

I placed a new order on Thursday and hopefully I’ll get them all during the week to come.

	xUnit Test Patterns: Refactoring Test Code Author: Gerard Meszaros Hardcover, 833 pages Published: 2007
	Continuous Integration: Improving Software Quality and Reducing Risk Authors: Paul M. Duvall et al. Paperback, 336 pages Published: 2007
	Refactoring to Patterns Author: Joshua Kerievsky Hardcover, 400 pages Published: 2004
	Semantic Web Primer Authors: Antoniou et al. Hardcover, 288 pages Published: 2008 (Second edition)

So, if the math’s correct, that’ll be 1857 pages of fun to get through this summer

A few days ago, Gøran Hansen of Capgemini and a an active member of the Norwegian Microsoft scene – as well as active in the Twittersphere, wrote a blog post called “A Software Craftsman’s Bookshelf” containing a picture of his book shelf with Software Development-related books, as well as a brief review of the titles. He tagged a bunch of other people – including me, so here’s my contribution to this book shelf meme

(I actually wonder why a UI-geek like Gøran chose a dull jpeg for visualizing his book shelf, so I’m stepping up – to show off that Mr. Non-UI guy can use the Stitch functionality in Deep Zoom Composer. The final product is hosted on DeepZoomPix – a Microsoft site for hosting Deep Zoom pictures.)

Update: Seems like the stupid wordpress.com blog hosting strips javascripts and object tags, so until I’ll get around to move this blog to a more sane hosting provider, I’ll have to put up a preview picture that hyperlinks to the DeepZoomPix site

(A click on the image will bring you to the real Deep Zoom image)

I actually thought about rotating the stitched picture counter-clockwise, so that the titles of the books would be easier to read, but I postphoned it to a moment when I have more time to stuff like this

A description of the books + Amazon links, as well as a list of people I’d like to tag will be added later.

Since I started exploring the possibilities of the various bits of codename “Oslo”, there has been one thing that has really annoyed me (and this is not Oslo’s fault). The lack of a decent tool to do syntax highlighting of M, MGrammar & custom DSLs is vital to be able to communicate the intentions of a bit of source code when you blog about it.

Since I’ve been using the bits in System.Dataflow in a couple of projects now, I knew of the existence of the Lexer etc. in the assembly. I started to investigate further with .NET Reflector and found one class that seemed quite relevant for the tool I wanted to write; System.Dataflow.LexerReader. You initialize the LexerReader with a ParserContext and a stream of input data (typically the source code) and iterate over the tokens that the Lexer discover.

So, the basic requirements for the utility I wanted to create were:

• Take a compiled MGrammar (Mgx) as input.
• Take a piece of source code that complies to the MGrammar as input.
• Output a HTML fragment with syntax highlighted source code.

Since the MGrammar language has a notion of attributes, and more specific; supports the @{Classification} attribute that lets the language developer classify/group the different tokens into Keywords, Literals, Strings, Numerics etc., I started digging into the System.Dataflow to hopefully find a mechanism to retrieve the metadata during the Lexing phase.

After some hours of intensive searching with .NET Reflector and the Visual Studio debugger, I found the solution; when you iterate over the LexerReader instance, you end up with ParseTokenReference instances that both describes the token and its content. It doesn’t contain the classification information directly, and that was the big puzzle I had to solve. It turned out that the DynamicParser instance, that I used to load up the Mgx file and build the ParseContext had a GetTokenInfo() method that took an integer as the only parameter; tokenTag – and the ParseTokenReference instance had a .Tag property. Bingo!

So, I’ve put together a small spike that I’m intending to clean up – it’s located here at the moment and will be licensed under the Apache License.

Below is a sample output  from the utility – the input is a MGrammar that I wrote for a answer to a thread in the Oslo/MSDN forum.

For the first version it will probably be a command line tool – but it would probably be a good idea to create both a ASP.NET frontend and a Windows Live Writer addin for it.

20 minutes ago, this Twitter appeared in my TweetDeck. I’m currently watching the re-run of the first keynote of Mix’09 on one monitor, and idly checking twitter on another one.

So, for those of you that doesn’t know Jennifer; She’s a Developer Evangelist working out of Ann Arbor, Michigan for Microsoft. I had the chance to meet her again during the Global MVP Summit, and the thing that amazes me about her is her how she treat the people around her. That plus her exceptional technical skills and her work for Women in Technology makes her a woman in Technology I admire

In the first installment of this series we took a look at the basic grammar for parsing the command line with MGrammar. In this part I’ll show you how we can load in a compiled version of the MGrammar and parse the input (i.e. the command line) to produce a valid MGraph that we in turn can process in the backend code.

A quick reminder from part 1; the code is located here:
http://github.com/larsw/larsw.commandlineparser

You can download the code either by using git or downloading it as an archive. Once you’ve done that, open the solution LarsW.CommandLineParser.sln in Visual Studio 2008.

Most likely you will be presented with the following dialog box, informing you that opening the solution (or more correct the LarsW.CommandLineParser C# project inside) can pose a security risk. The reason for this is that I’ve included the a MSBuild task for compiling MGrammar files (.mg) into .mgx is that included in the Oslo SDK. Select the “Load project normally” and press OK.

We can first take a look at the extra plumbing I’ve added to the project to get the .mg file to compile. Right-click the LarsW.CommandLineParser project in the Solution Explorer, and choose Unload Project. Next, right-click it again, and choose Edit LarsW.CommandLineparser.csproj. This should bring up the project file will be shown as raw XML in the editor window.

In the first <PropertyGroup> I’ve added seven lines that I borrowed from a project created with the “M” template. They basically set’s up the path to various M-specific tools and auxiliary files.

The only line of these that really matter and that I had to tweak in order to get this right is the <MgTarget> element. Out of the box this is set to Mgx, that instructs the Mg compiler to spit out the result of the compilation as a .mgx file. As we will see later, the value needs to be set to MgResource in order to get the DynamicParser to load the .mgx as a resource.

If you navigate to the end of the project file, I’ve also added an <Import> element that imports some MGrammar specific MSBuild tasks and the most important thing; in the last <ItemGroup> section I’ve changed the element type from <None> to <MgCompile> for the cmd.mg file.

Well, we’ve been mucking around in the MSBuild plumbing too long now, haven’t we? Right-click the project again and choose Reload Project. When the project has loaded up again, build to ensure that everything is fine and dandy. Even though I haven’t stated it before, it should be obvious that the project depends on the latest (as of now that is the January 2009 CTP Refresh) Oslo SDK.

The core component is the CommandLineProcessor class.

It loads up the language (the compiled version of the cmd.mg) with DynamicParser.LoadFromResource(). The reason why we had to specify MgxResource as the MgTarget earlier is that if we don’t, and add the compiled .mgx file as a plain resource, the .LoadFromResource() method won’t find it. As of now, it seems that it will only look for resources with the .resource extension.

We then pass in the command line with a StringReader instance to the .Parse<T>() method on the DynamicParser instance. Even though it’s not specified, the T has to be object or a type that implements System.Dataflow.ISourceInfo. The internal/inner Node classes in GraphBuilder is what that will be handed out per default, but you can also create your own GraphBuilder and produce nodes from your own domain model.

So, by calling parser.Parse<object>(null, commandLineReader, ErrorReporter.Standard) we will get an instance to the root of the Abstract Syntax Tree (AST) returned if the input matches the grammar. The AST is basically a representation of the MGraph.

The next step is to traverse the AST and act upon the different node types. The grammar for this project is quite trivial and is mostly done by the private ProcessParameter() method in the CommandLineProcessor class. I suggest that you take a look at it if you’re interested in doing something similar.

So, just create an instance of the CommandLineProcessor and pass in an instance of an arbitrary class that contains method that will handle the command line arguments. To specify that a method is a argument handler, decorate it with the CommandLineArgumentHandler attribute. It will take in three parameters; short form & long form of the argument keyword and a description. For now the description isn’t used for anything but the idea is that the command line processor can auto generate a usage screen for you (typically shown with –?).

That’s about it – if you find it useful or modify the code, please let me know. With git you can push me a change set and I will try to merge it if you’ve come up with a cool feature.