- Vs2008 version of Dsl Book Samples
-
We've finally converted all the samples for our book on Domain Specific Development for VS2008. They can be downloaded from www.domainspecificdevelopment.com.
- Agile platform development. The problem.
-
Classic scrum
Our team uses Scrum to manage it's software development. A key tenet of Scrum is that there should be a product manager (PM) who own's a backlog (that is, a ranked list) of customer facing stories. Scrum organizes development work into sprints, typically 3-4 weeks long. Before each sprint, there is a sprint planning exercise, where:
- the PM communicates the stories to the engineering team
- the team tell him or her what's possible and where the engineering dependencies are
- the team estimate how long it's going to take to build each story, and, by identifying 2-3 day tasks required to develop that story
- the engineering capacity for the sprint is worked out, taking account of vacation and other activities
- they all agree what the main theme of the sprint is - what's the overall goal of their work this time round
- with all that information the PM and engineering team narrow down the scope of stories, re-rank, and draw a cut line
Need - build a (tooling) platform in an agile way
Now I'm part of a team in the business of creating a tooling platform, including tools built on the platform to build other tools that work on that platform (tools to build tools). And my job as a program manager is to come up with those stories that can be used to drive sprint planning. And I also want to do it in an agile way, so that it can be managed by the same process, and in a way that fully exploits the creativity, ideas and expertise of all members of the engineering team for whom I have the deepest respect.
Problem 1: Mind the gap
A problem we've identified with classic scrum is that it doesn't take into account the often large gap between business need and the software solution proposed to fulfil that need. Indeed, the process assumes that somehow the product manager will pluck out of thin air customer facing stories which are fine-grained enough to make sense to feed into the sprint planning process. That may work if the project is about adding new functionality to an existing website, say, but with a platform it's not so obvious how this should work.
Problem 2: Two or more customers
When building a platform, you've got two customers at least. You have the customers who use applications built on the platform, and you have the developers who use the platform to build (author) those applications. I tend to call these users and authors. With a tools platform, there's also a third customer, which is the one who uses the applications built using the tools built on the tooling platform. This impacts the way you write scenarios/stories, specifically there are stories targeted at the user and stories targeted at the author. It also impacts the meaning of 'agile'. Platform has to be delivered in time for the authors to build the applications on that platform that their customer needs. If the author is running an agile process to build their application, then you're going to need to understand their stories some sprints before the author is going to implement them, so that you can get the platform pieces in place for them to build on in time. Or you try to do it all at once, but there lies a hornets' nest.
After 5 years experience of doing this in Microsoft, I'm starting to get a handle on a process that seems to make sense, and I thought it would be fun to try and relate that process here and see what others think.
So watch out for postings with a title of the form:
"Agile platform development. ..."
I'll also tag them as follows...
- Catching Up
-
So now I've found myself some time to get the blog started again with Long time no blog, UML and DSLs here's a little catch up on all things VSX and DSL.
People
Jean-Marc Prieur has recently joined the team as a program manager. Jean-Marc is a colleague of mine in Cambridge, and it's great to have him join us. Jean-Marc will be helping with both product work and driving community activities in Europe.
Links
As usual, Gareth has been summarizing others'
blogs with lots of interesting links. Take a look at Couple more VSX bloggers and A rash of bloggers.
http://www.netfxfactory.org/ has recently published a paper about adding prototype (pattern) support to your DSL. There's a video to go with it.
Releases
In case you missed it, VS 2008 SP1 Beta has been released, together with a matching SDK. See Visual Studio 2008 SDK 1.1 Beta has shipped from Quan for details. Service pack releases focus on fixing bugs and increasing overall quality. For the Dsl platform, we fixed some bugs around line routing when using nested shapes. For those of you who have our book, this means that you can follow the instructions on pages 443 to 446 to implement nested shapes, rather than adopt the workaround on pages 446 to 453. The bugs we fixed remove the problem described at the top of page 446. We also provided a print preview feature. Run your designer on SP1 and you should see this capability just appear.
Technorati Tags:
DSL Tools,
VSX
- Long Time No Blog, UML and DSLs
-
Technorati Tags:
DSL Tools,
UMLEmbarrassing, but true. Last time I blogged was back in February.
I'm on one of my regular trips to Redmond, and jet lag still means I'm getting up at 4am. Usually on these trips I use the early morning to do a bit of work, then go for a run. However, last trip I stumbled on a tree root when out running and fractured my ankle. It's the first time I've broken a bone, so I didn't know what to expect. In fact, at first I didn't really believe the doctor; x-ray looked fine to me. Little did I expect that I'd be back in Redmond 7 weeks later, still limping and definitely unable to run. So I find myself with more time in the morning, and an opportunity to contribute once again to the blogsphere, though any readership I may have had has probably already given up on me.
So what's there to talk about. As the title suggests, I thought I would touch on the subject of UML and DSLs given a recent post on UML + DSL from Cameron Skinner, who now leads Visual Studio Team Architect. In the article, Cameron talks about a new set of designers that Team Architect are working on, which includes some UML designers, as well as some graphical DSLs. The goal is to 'make modeling more central to a broader range of people' as well as to 'seamlessly connect the two approaches [UML and DSL]'. We've found that DSL Tools is very appealing to customers who've already bought into modeling. It allows them to create their own customized model driven solutions fairly quickly. However, for those not already into modeling it's a harder sell (although, we have had customers who have seen what others have produced and decide to build something similar which focuses on their domain). To really get modeling out to a broader audience it's necessary to have tools that people can use straight out of the box. I'm still convinced that if you want to dramatically increase productivity then you should be using DSLs driving code generators, or further model transformations, or visualizing abstractions discovered from existing artifacts, or some combination of all three. On the other hand, whatever your views are about the effectiveness or not of UML, it has significantly raised the awareness of modeling with a broad audience and it is something that many people are familiar with. So I'm really pleased that Team Architect has now stepped up to drive a strategy that delivers on both sides of the modeling coin, and connects them up.
What is more, I'm really enjoying helping them deliver on this strategy by providing a great platform to build on. Because, as Cameron points out, many of the designers being built by Team Architect (including the UML ones) are being built on the DSL Tools platform. Not only is this further proof for the robustness and flexibility of this platform, it is also helping to drive new features into the platform which will benefit anyone wanting to build their own DSLs. We're not ready to talk about those features in detail yet, but my list posted a few months ago is still fairly accurate, although there are a couple of additions and some changes in priority. Worth calling out are the features to allow a designer to be extended with new metadata once it has been deployed, and support for designers and models to interact. This will allow the designers delivered by Team Architect to be extended, and for new, third party DSLs to interact with them. Both these are key aspects of connecting UML with DSLs in the UML + DSL story that Cameron speaks about.
Finally, you may also have noticed that Steve is changing his role, by going back to Team Architect in order to help them deliver on the UML + DSL vision. This means that Steve will be more of a consumer of the platform that he helped create, and I'm sure will be driving hard to ensure that it meets his needs. Steve and I still share an office in the UK and will still be working closely together. Should be a fun ride, this.
- If you're a student, get Visual Studio Pro for free
-
If you're a student, then Microsoft has just announced a new program called DreamSpark to get Visual Studio 2008 Professional Edition (and Expression Studio and Windows Server 2003 and XNA Game Studio and SQL Server 2005) for free.
As Aaron points out, once you've got Visual Studio you can download the VS SDK (also for free) and start extending it.
If there are any academics reading my blog (I'm hoping that some of my academic colleagues might take a peek now and again), please let your students know about this.
Putting on my Lecturer's hat, I'd encourage all Computer Science students to try out both Visual Studio and Eclipse before they leave college, as it's very likely that a potential employer will be using one or other, and sometimes both. Also, the more experience you have with different development environments and programming languages the more transferrable and rounded your computing skills are likely to be.
- More rapid deployment of VS extensions
-
Over on Deep's blog I came across the following comment to his post on Tools for Tools.
I had looked at creating a DSL for one of our projects a while ago, and in the end decided against it because the deployment was too complicated. In particular, here is how I want deployment to work:
In my normal solution of my project, I add a new DSL project, along with my other C# projects that constitute my end piece of software. In the DSL project I define a new DSL that I can then use right away in the C# projects that are part of the solution as well. That is, I don't want any setup at all, but rather want the DSL to be loaded as for example WinForm custom controls and the designers that go along are loaded from a dll project that is simply part of the solution of the consuming project.
Why is this so important? First, this would automatically solve the version problem. In my case we would rapidly (or shall I say "agile" ;) change the DSL as the project goes along. With a model where the DSL is installed wia a setup program on a machine wide basis, we run into huge trouble when we want to work with a previous version of our source code (say a branch from the source code repository that corresponds to a previous version). We would need to make sure that our DSL project can always load old versions, i.e. we would need to be super backword compatible. But I don't want that, I want the DSL versioned along with the source code so that I get a predictable match of tools and source code artefacts.
Also, of course, deployment via setup is just a pain, I really just want my solution file to have all the info about tools (be it DSL, compilers what have you) needed to build it and take care of that.
Any chance that we might end up with something like that?
Generalizing this scenario a bit, I think what the commenter is asking for is the following two capabilities:
1) For VS extensions (in this case DSLs) to be checked in the rest of the code on a project, so that you can manage the tools used to build your code just in the same way that you manage the code itself.
2) Not to have to go through an expensive process (e.g. install an MSI) every time you want to reconfigure VS with the tools (extensions) needed for a particular project, or when you want to update those tools.
There are things you can do now to get over these two problems.
For (1) you can have a separate tools authoring solution that is checked in and used to rebuild the tools. You can do this now, and I don't see any issues around this. Indeed I would argue that it's not a good idea to mix your tools authoring solution and application development solutions, just because I think it's a good idea to keep these two concerns separate. However, you still need a way of getting revisions of tooling quickly out to developers, rolling back to past versions and so on. And making sure that before you build your application code, the right version of the tools is built and installed.
For (2), if you don't want to go to the trouble of installing an MSI, then, today, you could do the application building in the experimental version of VS (though you'll need to have the VS SDK installed for that). Building the authoring solution will install the tools in the experimental hive, and then you just need to remember to launch VS Exp rather than VS to do your work. So once you've updated your machine from source control, you'd go an build the authoring solution, then you'd go an open the experimental version of VS and continue with your development. You can reset the experimental version of VS anytime to mirror main VS, when you want to switch projects.
An alternative is to work in virtual PCs (our team does much of its development this way). Then to roll out a new version of the tools to your team, you build a new VPC with the tools installed and distribute this. The advantage of this approach is that you can set up multiple VPCs for different projects and then it's very easy to switch between them. Of course there is more upfront cost taking this approach. This is a good solution if you are distributing tools to a team of developers, you want to retain some stability in the toolset they are using, and you expect developers to be needing to switch context between projects.
Ideally, what I'd like to see happen is that when a developer signs up for a Team System project, they get their machine configured automatically with the necessary tools, and, further, that designated members of the team (which could be anyone) can go and make changes and rebuild those tools, which then get pushed out to other members of the team via Team System. When you switch to a different project, VS reconfigures itself with the tools required for that project. This won't be achieved overnight - it requires some platform changes to VS - but it's certainly on the radar.
- Book on VS Extensibility
-
I've just seen in the VSX newsletter that there is a book on Visual Studio Extensibility soon to be published. Details on http://nayyeri.net/.
- Quan started blogging about VSX
-
Quan is a new (and, I should say, very productive) PM on the VS Ecosystem Team. He's now started blogging about VSX stuff, and good posts there are too.
If your new to VSX then the following post might help you get into it. He's included both VB and C# versions of the code:
Building your own Visual Studio Source Code Outliner extension
- Great links from Gareth
-
Gareth is obviously settled in the US now, because he's starting to become a prolific blog poster again. Unlike me, who only manages it in spurts.
He's recently put up a series of posts with some great links. So for those of you who don't already read Gareth's blog here's some stuff worth investigating:
On code generation:
Fun use of T4 to generate strongly-typed web navigation
More general-purpose T4 goodness
Help in tackling the hard problem of model -- code synchronization
On using DSLs as part of Software Factories:
Wojtek at Wicsa
Team Architect Case Study with Software Factories
On evolving DSLs:
Gerardo explores domain-specific language evolution tools
On getting started with VSX:
Inovak learns VSX - Now!
And finally, a video of a situation which I find myself in many times as part of distributed development team in Microsoft...
Too much of life wasted on this soundtrack
- Great posting on distributed development
-
One of my colleagues (thanks Blair) pointed me at this:
http://blogs.msdn.com/eric_brechner/archive/2008/02/01/so-far-away-distributed-development.aspx
Our team is distributed between the US and UK and many of the points mentioned ring true in our experience. Eric stresses the need to maintain as high bandwidth communication as possible.
We try and make maximum use of livemeeting and office communicator and use video cameras with those which makes a huge difference. And, by the way, I've discovered that connecting wirelessly to the newtwork introduces impedance which can really impact the reliability of those channels. Since I've stopped using wireless at home, I find I can trust those tools now.
If any of you have your own experiences of distributed development which you'd like to share, pleas add a comment.
- Jobs on our team (in UK and US)
-
Our team is continuing to expand. We now have jobs available in both Redmond (US) and Cambridge (UK). Gareth provides the details.
- Hiking in the snow
-
I've been visiting Redmond to work with the team over there. I stayed over the weekend and got to go hiking in the snow with Andy Bliven, a developer in Team Architect. We were blessed with a gloriously sunny, but bitterly cold day between two snow storms. First time I've experienced my hair freezing. I'm now looking forward to planning the next expedition with Andy on my next trip. I'm the short one on the left...
- Sample of hosting a DSL in the VS2008 isolated shell
-
A new sample has been published of a hosting a DSL in the VS2008 isolated shell. See http://www.codeplex.com/storyboarddesigner.
The isolated shell is a stripped out VS shell who's UI and splash screen you can customize. VS packages, including DSLs, can be hosted in both full VS and in your own customized shell without change. This sample shows how to do this specifically in the case where you want to host a DSL in a custom shell, for example to distribute to a designer to non-developer stakeholders. See the VSX development center for more details.
This sample shows a storyboarding DSL, which a product manager or business analyst might do to envision the requirements of an application. In addition to demonstrating hosting in the shell, the sample also shows a couple of cool customizations on a DSL, including a very simple approach to linking diagrams, generation of web pages for the storyboard, and export of images off the design surface.
Here's a screenshot:
Thanks to Clarius for putting this up.
- Help with using the VS2008 Shell
-
Pablo has written a series of posts that should be of help to anyone thinking of hosting their applications in the VS2008 shell:
Customizing a VS Shell application
Integrating a VS Package with a VS Shell application
VS Shell application deployment
Creating a bootstrapper for a VS Shell application
VS Shell and the registry
VS Shell application switches
- Three things to know when using Visual Studio 2008 DSL Tools
-
In preparing for my presentation at TechEd, I got a chance to try out a couple of new things with DSL Tools on VS2008:
- The T4 editor from our friends over at Clarius, available at http://www.t4editor.net/. I installed the VS2008 beta 2 version on a VS2008 release candidate and it seemd to work fine. Makes editing text templates much easier. Nice job, Clarius. Can't wait for the other features promised in the future.
- Using LINQ to write validation constraints. I was blown away by the power of LINQ. Steve has a series of posts about using LINQ for this purpose - well worth a read.
Also for those of you who have wanted to automate the code generation step as part of the build process inside VS, here's a handy hint from one of our own MCS consultants, Jelle Druyts:
Add the following definition to the EnvironmentEvents macro (open Macro Explorer, MyMacros, EnvironmentEvents):
Private Sub BuildEvents_OnBuildBegin(ByVal Scope As EnvDTE.vsBuildScope, ByVal Action As EnvDTE.vsBuildAction) Handles BuildEvents.OnBuildBegin
DTE.ExecuteCommand("TextTransformation.TransformAllTemplates")
End Sub
Then build and it’s done. This will now always transform the templates before any build. Very neat.
