A small, but useful, PowerShell function that I have in my PowerShell profile that reads the default repo path from .hg\hgrc and launches it in the default browser. This means after I've done hg push I can just ype kiln to quickly get to the repo page to raise code reviews, etc.

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'm a huge fan of the Nexus 7, but one of the things that annoyed me from day one was the lack of landscape support on the homescreen. I almost always use the tablet in landscape mode, so when switching to an app I didn't already have in the open/recent apps list, I would have to hit the Home button; which flipped everything around temporarily. There was already a user-set orientation lock, and we knew Android could handle it (from other devices, and those with rooted devices changing build properties), so it always seemed like a really random restriction.

This was announced as fixed in Android 4.1.2, which began rolling out only a few days ago. As of this evening, my device still showed no update, so after finding some instructions, I decided to load the update myself.

These instructions do *not* require you to root your device or unlock the bootloader. If your device is unlocked/rooted, I have no idea what affect that might have on this process. If you're unsure about this, don't do it. I accept no liability if you mess things up. I have only limited knowledge of Android! The steps seemed fairly straight forward, which is the only reason I was attempting them!

My first problem was that I was unable to boot into recovery mode using the instructions. When I selected Recovery Mode from the boot menu, my device just booted normally. I didn't get the Android with the red exclamation mark. This was easily fixed by using adb (installed as part of the Android SDK) and running:

adb reboot recovery

This rebooted the device to the screen showing an Android with a red exclamation mark, and pressing Power + Up allowed me to select the "Update from ADB" option.

The problem was, once in this mode, Windows failed to recognise the decide/load the drivers that were previously loaded (before the reboot), which meant adb would no longer be able to connect the device:

adb: device not found

After a lot of searching online, I figured out that the problem was that the Hardware ID of my Nexus 7 when in recovery mode was not listed in "android_winusb.inf" file from the Google Android Windows USB Drivers. The ID I saw in device manager against the Nexus was USB\VID_18D1&PID_D001, which didn't turn a lot up in Google!

I decided to try adding this to the inf file manually (C:\Program Files (x86)\Android\android-sdk\extras\google\usb_driver\android_winusb.inf). As I'm running on a 64bit machine, I added the following to the [Google.NTamd64] section (note: this applies to Intel 64 bit machines, not just AMDs!). If you're using 32bit, you'd want to add it to the [Google.NTx86] section:

[Google.NTamd64]

; !-- snip other devices... --!

; Google Nexus 7
; !-- snip existing device IDs --!
; This is the HardwareID shown in Device Manager for the "Nexus"
;  device when in Recovery mode
%CompositeAdbInterface%     = USB_Install, USB\VID_18D1&PID_D001

After making this change, I uninstalled the device drivers, then reinstalled them using this inf file. I once again rebooted into Recovery mode, and this time, Windows correctly displayed the device as "Android ADB Interface", and I was then able to sideload the Android 4.1.2 update (downloaded directly from Google) by typing:

adb sideload 03a4eaf95f73.signed-nakasi-JZO54K-from-JRO03D.03a4eaf9.zip

ADB transmitted the file to the Nexus 7, then the Nexus spat out the progress as it verified the image and updated the device. A reboot later, and my Nexus 7 was running Android 4.1.2!

During some ranting about Git on Twitter, Brendan Forster suggested I blog the things I would change. I don't have time to write a lot, but I thought I could spam out a list of things based on my first 30 minutes with Git on Windows.

Note: I've just installed GitHub for Windows as a result of these frustrations. I'm not usually a big GUI fan (I use Mercurial from the CLI always), but initial impressions are good. But still, I'm blogging about the CLI for now...

I grabbed a "Portable" version of Git, as I didn't want to soil my machine with something I knew was going to frustrate me. It contained a "git-cmd.bat" file that seemed to get me to a command prompt with git in the path.

Cloning

This one should be easy, right? Even with no knowledge of Git, I knew I could do git clone url. Well, turns out I couldn't do what I was used to doing with Mercurial (though this may be Codeplex's fault). I copy/pasted the URL to my fork of xUnit from the address bar, and hit enter. I got an error: fatal: http://(url) not found: did you run git update-server-info on the server?. WTF? Is this a Codeplex issue?

No, it wasn't. It was a user issue. The clone url for a repository on Codeplex is not the same as the homepage of the project. The last part of the message is rather misleading. I've no idea what update-server-info is, but I'm going to bet that more than 90% of the time that someone encounters this error, they just pasted the wrong url (or typo'd). The text should suggest this, rather than some server-side command that is probably rarely correct.

Suggestion: Re-word this message to be useful for the majority of cases.

Repository Status

In Mercurial, I type hg st to see repository status. It works, because I've typed enough characters that Mercurial knows that I must mean status. I tried git st and was greeted with a big list of commands that I "might have" meant, including even reset! Eh?

Suggestion: Steal Mercurials behaviour, and save keystrokes.

I did a quick count on how many keystrokes it took me to do the same thing (commit an edited file) in Mercurial and Git. It was 18 + the message in Mercurial, and 40 + the message in Git. WTF?

Repository Diff

In Mercurial, I type hg diff to see all of the outstanding changes that will be committed if I call commit. I did the same in Git and ended up stuck in some crazy mode that let me page up/page down, but apparently not exit. I tried Ctrl+C, Break, Escape, Enter and tons of other keys. I had no idea how to quit. After some Googling, I discovered it was :q. Classy. Just like all those other Windows applications.

Suggestion: Spit the diff out directly to the console like Mercurial (especially if it's so short it wouldn't fill the buffer). We already have the ability to scroll!

Suggestion: Don't use shortcut keys that aren't familiar to Windows users on Windows.

Suggestion: If you put the user into a mode that they need to "exit" to continue doing anything, tell them. Show something on screen that says "Press :q to exit"!

Commit

Ok, so I've seen my change. It all looks good. I need to commit it. Diff has already shown me the changes, so it knows what I want. git commit, right? Wrong! This command told me I hadn't added any changes to the staging area. What? Diff just showed me them! Turns out, I have to do "git add" first, so it knows what I want to commit.

Suggestion: Either don't show unstaged(?) changes in diff, just show a message saying there are some, or highlight the unstaged changes in some way.

(I'd almost go as far as ditching this staging crap, but I don't know enough Git to really understand the implications of that)

Commit (part 2)

With my changes staged, I can finally commit (hurray! so far this has taken longer than the 10-line-change I actually made!). So I type git commit. With Mercurial, this would fire up Notepad and let me type my commit message...

With Git, this launched VIM. That's right, VIM. You know, that standard Windows editor that everybody is familiar with? No, exactly. I started typing my commit message and my cursor starting moving all over the place and doing crazy things; I'd clearly mashed my way into executing commands or something... With that fixed, it was time to save and quit. I probably don't need to tell you how this works in Notepad! I tried Ctrl+S, Escape, Enter, Ctrl+C, and all sorts of other stuff. Again, I had to resort to Google. I wanted <ESCAPE>qw. Of course. Just like Microsoft Word; I should've known that! :-/

Suggestion: Use Notepad by default on Windows.

Suggestion: Don't use shortcut keys that aren't familiar to Windows users on Windows.

Suggestion: If you put the user into a mode that they need to "exit" to continue doing anything, tell them. Show something on screen that says "Press <ESCAPE>qw to exit"!

Pushing

With my change (finally) committed, it was time to push to Codeplex. This one isn't really Git's fault, but I spent 5 minutes trying to figure out why I got Authentication Failed messages when I entered my Microsoft Account details. Turns out, I have a Codeplex username/password from years ago which is "linked" to my Microsoft Account, and despite logging in to Codeplex using my Microsoft Account, this doesn't work with Git.

Suggestion: Let users push to Git using the same details they login to the site with! Or at a minimum, change the text that says "same as your website password" to make it more clear this is a Codeplex password, and not the one you probably used to login to the website!

Conclusion

My conclusion after all of this, is that Git is a fuckup on Windows. It's not friendly to Windows users, and it makes things way more complicated than they should be. If Mercurial had been half as complicated as this, I'd have never moved to (and advocated) DVCS.

I don't buy the "it's more complicated because it's more powerful" bullshit. What I was doing today should've been incredibly simple; and in Mercurial, it would have been. Mercurial is also cross-platform, so it's not like this terrible Windows support can be blamed on that.

I'm genuinely surprised that Git has become so popular on Windows (and at Microsoft) when it's such a mess. I can only assume this is down to GitHub doing a significantly better job than sites like BitBucket!

Luckily, it looks like GitHub for Windows might fill the gap between the totally-ridiculously-complicated-CLI and the complicated-and-badly-performing-explorer-humping Tortoise applications. No doubt I'll be tweeting more about that soon ;-)

I'm sure the Git fanboys/Linux Zealots will disagree with all of this and tell me I'm wrong. And that is why Git fails so badly on Windows. The zealots care more about trying to force their way on users rather than trying to build something that is easy to use and fits in with what different people are familiar with.

Git devs: When in Rome, do as the Romans do.

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: