Monthly Archives: October 2008

Getting Oslo’s Intellipad to show MGrammar Mode

[EDIT: You can just launch Intellipad with Samples Enabled, from the Start Menu. For some reason my first port of call was to run Intellipad from the command line]

Ok I’m beginning to dive into Oslo, so I can at least Appear knowledgeable for the PDC Fireworks talk next week, but there was one thing that was holding me back…

To me the most interesting thing in Oslo is the M language and ability to create on the fly Domain Specific Languages, at the moment this functionality is pretty simplistic but there’s a huge number of applications I can think of, not least with my interest in testing side of things (something that Jeremy Miller alluded to).

As such I wanted to get to grips with how the M language works and how to write grammars and models.

I quickly followed this tutorial but found that the Intellipad experience wasn’t as advertised.

As such here’s a quick primer of how to get the three column view up a little like this:

First navigate to the Oslo SDK Bin Directory (on my machine with x64 windows server 2008 it’s located at C:Program Files (x86)Microsoft Oslo SDK 1.0Bin), open the Intellipad folder and you’ll find a sample sources folder, in this folder is a visual studio solution, Open up and build this solution.

Media_https3mediasqua_xbefh

Once the solution is built, back in the Intellipad directory you should have another folder (samples), open this folder and copy the directories to the Intellipad components folder

Media_https3mediasqua_jvxtd

Ok so now we have MGrammar support in Intellipad, you can open Intellipad by clicking on ipad.exe in the Intellipad folder

Lets’ open up a grammar file and try and get the three pain layout as described in the article.

From the Intellipad open menu navigate to the Oslo SDK samples directory and the song directory under MGrammar

C:Program Files (x86)Microsoft Oslo SDK 1.0SamplesMGrammarSong

open the Input.song file

This is the easiest way I’ve found to get the three window layout, open the input file first.

Once the input file is loaded you can press Ctrl+Shift+G to turn the mode to MGrammarMode, this will give you extended menu options:

Media_https3mediasqua_qfazj

From this menu click on Tree Preview this will bring up the open dialogue again, this time select the Song.mg file in the same directory as the Input.song file.

if all is well you should end up with the input.song being in a DynamicParserMode window, the Song.mg being in an MGrammarMode window and a GrammarPreviewMode window.

Media_https3mediasqua_oaoid

Changes to the input on the left get run through the grammar in the middle and produce the output on the right.

Hopefully this will save some people some time and effort playing round.

 

O

Tagged

Like footprints on the moon: beware your software legacy

This post has been brewing for some time:

A couple of weeks ago I was very amused to get a tweet from Daniel Cazzulino (the guy behind Moq)

Media_https3mediasqua_cbota

The reason I found the text funny was the idea that Daniel found it strange to have legacy parts of an application within a year of starting the application. I realise (in this instance) the emphasis was more on having to separate the API to allow people to continue using the original MOQ syntax without having to modify everything to be in the more Arrange, Act, Assert syntax. However I don’t believe that it’s unusual for developers to overlook the fact that every line of code they write is somehow creating a legacy of it’s own.

There is one inevitable truth that we all have to learn early (or go down in a death spiral of glory) the rules will change. No matter what the project, the expectations will change as people gather more understanding of the problem they’re trying to solve. We all know this, and yet people are unwilling to write code as if it will change.

I’ve come to embrace throw away code. In the essence of the JFHCI approach I find I’m constantly writing stuff that I KNOW i will be rewriting soon.

Why?

  • because it gets me and the people who make the changes to the point where they understand what they really want quicker.
  • because I can, I surround my code with a safety net of expectations
  • because refactoring simple code is much easier than refactoring complex “well thought out but wrong” code.

Get used to writing code as if it’s not hear to stay, get used to it.

After all it’s the truth.

Tagged
Follow

Get every new post delivered to your Inbox.