Hidden features of Visual Studio, enter watch expressions with format specifiers

Every now and then I find myself getting annoyed at these little refresh squiggles that the Visual Studio watch expression get if they potentially have side-effects. I reckon that's a good thing, however, sometimes I need to express a quick way to drill down some data structure and get at that specific value.

Format Specifiers in C# (see MSDN)

These format specifiers are for C# but some of these are language agnostic and some variations of these work with other languages.

There's more information on MSDN. But these are my favourite ones, the ones I try to remember. Because when I need them, I have know that I can use them.

Specifier	Format	Value	Displays
ac	Force evaluation of an expression. This can be useful when implicit evaluation of properties and implicit function calls is turned off. *
d	Decimal integer	0x0065	101
h	Hexadecimal integer	61541	0x0000F065
nq	String with No Quotes	"My String"	My String

* See Side Effects and Expressions.

And this is how you use them...

Watch

Name	Value
Text,nq	string without quotes
source.Skip(2).First(),ac	The 3rd element of an enumerable source
0xa,d	10
10,h	0x0000000a

The d and h format specifiers are especially nice when you find yourself toggling Hexadecimal Display on and off. And as a bonus, If you'ven figured this out yourself, these expressions also work in the DebuggerDisplayAttribute string. Very handy.

VSX Mercurial

I have a habit of leaving things unfinished if I find my self having solved the nitty gritty details. That last stretch stuff just isn't as fun as the technical challenges. Though that's a topic for another day.

This week I contracted a bad case of the flu. I've spent the last several days in bed trying to regain some strength. Laying there thinking (not really accomplishing much of anything) I thought I'd reboot that source code control plug-in for Visual Studio.

The thing about Mercurial (and this is equally true for git) is that it's super easy to get started. And with it you can distribute, patch and hack away effortlessly in mere minuets. What I felt was missing was a source control package for Visual Studio that embraced the same principles.

For all the SVN tools out there TortoiseSVN always struck me as odd because it attempts to turn every last folder in your computer into a version controlled system by integrating with the Windows Explorer Shell. I never got that and was somewhat surprised that TortoiseHg even existed. Mercurial not being SVN makes it somewhat less of an atrocity but I can't believe that people actually wants to use these GUI tools.

Unhappy with the performance of existing plug-ins for Visual Studio I decided to roll my own and I figured that it be a good opportunity to learn how to build Visual Studio Extensions.

I actually have decent statistics of the number of hours a day I actually spend within Visual Studio actively doing stuff. Learning more about the Visual Studio extensibility model felt like a smart move.

I have a very clear vision of where I wanna go from here, it's also my attempt at an open source project. I don't really have any strong feelings about open source but I've always learned a lot by reading source code. This could be a good opportunity to give something back.

If you're a Visual Studio user looking for a Mercurial SCC plug-in checkout VSX Mercurial on Codeplex.

I abandoned this project sometime ago. Mercurial is still a great tool but I use TFS and git today. I also find that the kind of integration I was planning with VSX Mercurial wasn't really what I needed, git extensions taught me this.

Microsoft PDC 2010

Windows Azure is the big topic of this years Microsoft PDC. I haven't payed much attention to Windows Azure in the past but after the PDC I actually felt the urge to write some code in the cloud (hilarious isn't it?).

The developer experience for Windows Azure is what you'd expect with Visual Studio 2010. The transition is easy to make, and the big difference is primarily on the Windows Azure Storage side of things. That did not sit well with me, and it took me a while to figure out that the out-of-the-box tools don't really support the development storage, which is what you use if you haven't paid for an Windows Azure account.

There's a lot of pesky things about the Windows Azure Development Storage that's not entirely obvious. e.g. there's only one development storage account (which limits you to exactly one database at any given time), it can be completely wiped simply by clicking a button on the storage service client and there is no built-in tool for managing the storage (only querying from within Visual Studio is possible). Given that I might wanna switch between different projects, I thought I'd keep my schema and data primarily in scripts, that made sense until I realized the way to talk to the Windows Azure Storage service is through this REST API. That's fine though, but not if you're expecting to write T-SQL scripts. Windows Azure Storage, is a no-SQL storage and fundamentally different from what you get out-of-the-box with SQL Server. I realize that's a good thing for writing scalable software, but it did catch me off guard. I believe I was expecting something along the lines of what Microsoft is offering with SQL Azure.

I'm interested in learning more about Windows Azure, but this sort of thing doesn't not help with that. Eventually, I would put up the money for it, (truth be told, it's not that expensive). However, it's hard to get an overview of the what you need (in terms of computing power) and the final cost when running in the cloud is pretty guess work. Though, you can scale back to whatever supports your revenue stream as well as scale up, if necessary.

It's likely that my concerns right now, will fade away with time. As I learn more about the platform my ability to make the right decision will certainly increase. Though, as of today, the first-class developer experience I've come to expect from Microsoft with Windows Azure is not quite there.

The hardest problem with computing is people

Gilad Bracha said this during the Programming Languages Panel at Microsoft PDC 2010.

The hardest problem really is this whole issue of compatibility that plagues software, that is so brittle, you can never take things out, you can never fix things early, you can just add stuff, and therefore contribute to bloat and the problem is not so much with the technology as it is with the people. The hardest problem with computing is people, and you know they need to be replaced but we cannot do that. Ultimately we need to find ways for software to evolve and update itself in such a way that it can not only grow but shrink.

Hopefully I'm not misrepresenting Bracha or quoting him out of context when I say this.

I've been looking into software composition and clearly found great use for dependency injection. Inversion of control IoC (IoC) represents a step in the right direction and dependency injection (DI) is the means to achieve both IoC and composition. As a proof of concept of this, I was refactoring some code written by co-worker this Friday, moving things into reusable services, and surprisingly yet satisfyingly so, I'm removing more code than I'm adding. The result is not necessarily a smaller code base, but the complexity is certainly more manageable (on top of being testable). I think this is what Bracha is getting at.

The benefit is that there's no longer a tight coupling between these objects. Which is what's allowing me to actually move this code into a separate assembly altogether. If I can partition my software into isolated compartments then that's a step in the right direction. What you get out of this is a problem which focuses on the management of several smaller instances instead of one very large code base and through experience, I've learned that managing complexity on a smaller scale is preferential to a big ball of twine (intermingled dependencies).

The compositional approach is of course not free. Nothing, is. For one, a loosely coupled software architecture that is compositional requires lots of abstractions and you should be aware that there's a fair amount of work to be done to orchestrate the composition of the software itself. Some work is going to focus on writing auxiliary software to make deployment and configuration easier.

I'm convinced that composition is the way to tackle software aiming at solving a diverse class of problems in some manner which is consistent on a higher level. It enables great flexibility without sacrificing architecture, testability or maintainability at the cost of initial bootstrapping when new requirements surface.

Windows Phone 7

After attended the Windows Phone 7 launch event here in Stockholm, Sweden. I started thinking about the Windows Phone 7 experience in a new way. Having read everything I could find on the Internet actually using the phone didn't really change my opinion. It's still a solid touch device. But one thing that became abundantly clear was that the phone can not be experienced through others.

I say this because so much of the phone experience is tied into social networking, such as Facebook and Twitter. If the phone is hooked up to your contacts it's personal and talks to you in a different way. The problem is that you cannot not buy the phone and get that experience, you basically need to rent it and spend time on it, before you can make a decision.

The Windows Phone 7 experience appeals to me differently than the iPhone and Android and if you have a chance to check it out, you should!

Moving to the cloud

I've more or less relied on my hosting company to advocate my own existence on the web. With the changes done to Blogger over the years I've been using it, it has pretty much come to a point where everything I need is in one place. All in all, it's really convenient.

I can make changes whenever and wherever I like. And there's no longer any source code to compile. Normally I'd have a small back-end that grabbed my Blogger and Twitter feeds. But as I recall I've misplaced that source tree at least three times already. With this change the source code is now up in the cloud. And if you're about to right-click and view source. I want to point out that I'm in no way responsible for the additional markup and scripts being generated by Blogger.

System.HardwareAccelerated

Please support my campaign for adding SIMD extensions (and other hardware accelerated features) to the Microsoft CLR implementation. Follow this link and vote for this feature on the Microsoft Connect website.

The x87 floating-point math extensions have long been one of the ugliest legacy warts on x86. Stack-based and register-starved, x87 is hard to optimize and needs more instructions and memory accesses to accomplish the same task than comparable RISC hardware. Intel finally fixed this issue with the Pentium 4 by introducing a set of SSE scalar, single- and double-precision floating-point instructions that could completely replace x87, giving programmers access to more and larger registers, a flat register file (as opposed x87's stack structure), and, of course, floating-point vector formats.

Intel formally deprecated x87 in 2005, and every x86 processor from both Intel and AMD has long supported SSE. For the past few years, x87 support has been included in x86 processors solely for backwards compatibility, so that you can still run old, deprecated, unoptimized code on them. Why then, in 2010, does the CLR emit x87 instructions, and not scalar SSE or, even better, vector SSE?

I lifted this text from Ars Technica and changed one word "PhysX" for "CLR". It's totally out of context but totally applicable at the same time. The CLR is an abstraction, it has the power to emit any instruction set best suitable for any platform.