Had a bit of a discussion on Twitter with Kevin Darty about TypeScript. It started off with this tweet:

Please RT if you actually know JavaScript and don't need a crutch like CoffeeScript, Dart or TypeScript.

— Kevin Darty (@kdarty) October 12, 2012

I'm still a bit puzzled by all the hate for TypeScript. There seem to be a lot of NaySayers, but I've still yet to see a single example of a codebase that couldn't benefit from TypeScript. Since it's a superset of JS, you don't have to do anything to start using it except rename your .js files to .ts, and then you can add TypeScript only where you think it will add value.

It's like having a magic switch that helps you find errors and refactor. How can it possibly be a bad thing?

I don't buy the "it'll stop people learning proper JavaScript" argument. I don't know a huge amount of Assembly or IL. Sure, there might be situations were knowing more of them would be useful, but is it really worth the time investment when I could instead be improving my C#/other skills that I use every single day?

Does it matter if I can't type javascript without looking it up to hook up subclass prototypes in JavaScript if TypeScript can do it for me? No. Does it help if I understand the generated code? Sure. Is it a requirement? No. All that matters is I understand how it behaves and any limitations of it. The same way I don't need to understand 100% of the IL generated when I write C#.

I'd actually argue that TypeScript will actually improve most peoples ability to write this kind of JavaScript. Think of the workflow... Chances are, you'll store both .ts and .js files in source control (that's how I'd probably do it, so code reviews can see the actual code going to the browser, and we don't have to worry about devs seeing different code to what's being deployed by the CI server). That means when you're viewing your diffs prior to committing, you'll review both your changes and the generated changes from TypeScript. I'd say this will teach you how these things work in JS. You'll become more aware of how sub-classes work, the behaviour of "this" in event handlers, etc.

I'm still generally curious; I'd love to see someone present a codebase that can't benefit from TypeScript and prove me wrong. I genuinely can't think of how anyone could write JavaScript to run in the browser that wouldn't benefit from type-checking (whether it by their own objects, or access to the DOM) in any way. If you're a NaySayer, then take this challenge! :-)

There was also some discussion about Dart following on from +Kevin Darty's tweet, like:

@cdhowie what about how MSFT Devs everywhere ripped Google a new one for Dart but are embracing TypeScript with open arms. Hypocritical?

— Kevin Darty (@kdarty) October 13, 2012

I can't speak for all MS devs, but I thought it worth sharing my opinion... I certainly LOL'd at the Hell World JavaScript created from Dart, but that was kinda funny (moreso with recent talk of Tree Shaking being a huge advantage of Dart). In general, however, I think Dart is a good idea, but possibly this effort could be better spent doing things slightly differently (more on that later).

I think Dart is a very ambitious project. I really hope it catches on and we see support in all browsers. However, I just can't see it happening :O( Dart and TypeScript solve some of the same issues but coming from the exact opposite sides.

TypeScript is designed to be compatible with JavaScript so you can use all of the existing JS libraries out there, and slowly/progressively add TypeScript to your code.

Dart goes further, and also provides a runtime, which brings huge performance benefits (where it can be executed natively). It compiles to JavaScript for compatibility (a necessity to ever gain traction). It tries to do so much more than TypeScript, however the trade-off is that it doesn't integrate with existing JS libraries.

In an ideal world, the decision to use something like TypeScript vs Dart should be based on things like:

1. Whether a Dart runtime is available to the majority of your users
2. Whether you need to interact with a lot of existing JS libraries
3. Whether you need to interact with a lot of your own JS (legacy projects)
4. Whether you can invest the time required to learn Dart (there's a lot less to learn with TypeScript)

However, I can't help but think that the decision is actually going to be based on one thing only:

1. Are you using Visual Studio or an Open Source IDE?

I just can't see TypeScript support ever being as good in non-VS IDEs. Nor can I see Dart support in VS ever being as good as it will elsewhere.

I actually think we could do much better than Dart or TypeScript. Scott Hanselman described JavaScript as the "Assembly Language for the Web". I think this is the first problem to address. We need something that runs in all browsers that addresses the issues with JavaScript, but it should be more like an intermediate language that other languages/tools can compile to (like we currently do with JavaScript, but less shit). That way, the choice of language can be decoupled from the browser support. If you want to write C#, VB.NET, Dart, Java, etc., it shouldn't matter. As long as they can all be compiled to a standard "IL", they should be deployable to a browser.

I don't know whether any of the existing technologies are good candidates for this (could we compile C#/Java/etc. into Dart? NaCl?), but I think it would be the best solution for all. People could use the IDE and languages they feel most comfortable/productive with.

In the meantime, compiling to JavaScript is the only thing we can do for compatibility. But in the background, I wish the standards bodies and browser vendors could get their heads together and agree on a new way of executing code in the browser in a way that they can all offer the experiences they wish to their devs. It doesn't matter whether it's based on something existing or new; the important thing is that it's not tied to the web development language and that the browser vendors and the companies with huge influences in development get behind it. If we can develop desktop apps and server-side code in the language of our choice; why can't we do the same for the browser? This would allow huge amounts of code reuse across our applications that we don't currently get.

Chrome already has NaCl, and will presumably have native Dart support soon. I wouldn't be surprised if IE ended up with native TypeScript support. This is going backwards, not forwards.

I don't like the idea of paying for (or installing) a tool to just show me some simple relationships between my Visual Studio projects, but it's something that is pretty useful when trying to tidy up a huge legacy codebase.

I whipped together a quick PowerShell script that spits out project references in a format ready for pasting into yuml.me to draw a chart:

The output will look something like this:

Over the past few weeks, I've been claiming control of more of the build/deployment processes where I work. I was getting tired of seeing a red icon on CCTray because half of the company projects didn't build, and the few that had unit tests weren't even running them :-(

With all that addressed, I turned my attention to the process of deploying code to the staging servers. We wanted this to be as simple as possible, however it needs to be a conscious decision - we could not just have the public stage systems (used by clients, trainers, etc.) constantly building every time someone commits.

I like the way GitHub works but sadly we have no chatroom/chatbot to order to deploy for us! :-( We decided that a reasonably simple solution was to have a Mercurial tag called "Stage" to act as a flag for deploying. Once we're happy to push to stage, we can just pull the Stage tag up to the correct revision, and the build server can run with it.

To do this, we needed to add another project to CruiseControl.NET. One will build continuously (and update local test sites, for non-devs to test during development), and the other will deploy to the public staging environment. The problem came when I wanted to set up this new project to build from a tag. The CruiseControl.NET documentation (if you can find it - Google is polluted with tons of copies of old/stale documentation!) didn't seem to give any option for checking out a tag, only a branch! I tried putting the tag name in there in the hope it might still work, but sadly, no such luck!

I came across some info online that pointed me to "hg help urls" which shows you can use URL fragments to check out revisions, like this:

hg clone \\myserver\Development\MyRepo#Stage

This worked great on my machine, so I configured CCNet to use this as the repository. Unfortunately the build failed immediately, with this error:

abort: repository \\myserver\Development\MyRepo#Stage not found!

At first I thought maybe CCNet was doing something fruity, but after trying the same command on the build server from a command window, I discovered that this functionality has become broken in a recent version of Mercurial!

I've filed a bug on the Mercurial site and for now, rolled the server down to 1.7.3 (the version I had on my desktop, which I knew worked). This meant uninstalling TortoiseHG, but that's not the end of the world, right? ;-)

Now the CCNet config looks something like this:

<sourcecontrol type="hg">
    <repo>\\myserver\Development\MyRepo#Stage</repo>
    <autoGetSource>true</autoGetSource>
    <workingDirectory>$(WorkingPath)\$(ProjectName)</workingDirectory>
    <purgeModifications>true</purgeModifications>
    <revertModifications>true</revertModifications>
</sourcecontrol>

With this now working, things were starting to come together. To make things even easier, I added an alias in my Mercurial.ini file:

[alias]
stage=tag -f Stage

There's still a little way to go to fully automate the process of extracting the build on the server, but what used to take 30+ minutes is now as simple as:

1. Type "hg stage"
2. Go and make a cup of tea for the team
3. Build server will:
   • Check out the Stage tag
   • Overwrite the AssemblyVersion attribute in a shared AssemblyInfo.cs file with the CruiseControl label
   • Build the project using MSBuild/NANT
   • Run all tests
   • Zip up the resulting build and store it alongside previous versions
   • FTP the zip file up to the staging server ready for deployment
4. Extract the zip file into the "Latest" folder (this is where most client IIS hosts point)
5. Profit

Automating the last part is a little more tricky because we'll need something on the server to extract the zip (possibly a web service we can call, or a services that watches the folder for the releases), but if you consider that I deployed 6 times in the last 2 days and it's taken only 4-5 hours to automate this much, it's clear the savings will mount up!

Version 1.3 of G+ Notifier (for Google+) recently went live. Unfortunately, due to an error with 1.2, you might not be notified about the update by the application unless you leave it running for 12 hours!

Here's some screenshots of the current version:

Unfortunately, with absolutely no warning, Google suspended the G+ Notifier account I'd created on Google+ to announce updates. I'd asked a number of times whether this was ok, and got no response. As a result, if you want notification of updates without all of my unrelated posts on Google+, the best way is to follow @GPlusNotifier on Twitter. Yeah, really.

Of course, if you don't mind the personal posts, the best place to follow G+ Notifier is my account on Google+.

If you have any ideas and suggestions for G+ Notifier, please submit them to the support site. You can also vote on other peoples suggestions there to influence the things worked on next!

You're also welcome to fork the code and send pull requests. It's a good idea to let me know in advance, just to ensure someone isn't already doing the same thing. There are already a few people (Adam Simmons, The Configurator and Andrew Nurse) contributing to the project!

The first version of my G+ Notifier is now live, ready to download!

The first version is pretty basic, but it's still incredibly useful. It sits in the notification area and shows how many unread notifications you have (and shows balloons periodically). Double-clicking the icon (or single-clicking a balloon) will launch Google+ in your default browser.

For full info and a download link, visit gplusnotifier.com!