I don't think it'd be too hard to make the flip-to-silence feature reliable on the Nokia. It already has a sensor to turn off the screen when you put it up to your face (or if you cover the screen with something).
So if you use that in combination with the accelerometer, then you should know when the phone has been flipped on its face.
Although, to be honest, it's not too hard to silence my Samsung Focus either. Just press down on the volume control.
There's also a strong case to be made for .NET in terms of how well-crafted and well-documented the framework is, and how many of the common tasks are made very easy by the framework.
So this has a couple advantages over most unmanaged languages:
1. It's easier to write correct code.
2. In general it requires less code to pull off most tasks.
And then in a web server environment, more often than not the bottleneck is going to be in the database or data access side of things anyway. So taking a small performance hit from using a managed language is probably not worth worrying about. At least that performance hit is nowhere near that of something like Ruby.
I'm a Blend user myself. I got Blend for free thanks to BizSpark. So for anything design related I'll have Blend open in "split" view, often using the tooling of Blend and writing XAML by hand in equal measure.
But it's good to see the improvements in tooling for VS11 when it comes to XAML. Most of the features I saw were things that past versions of Blend could always do. But it's really going to help those who don't have Blend.
@jimhogg - Thanks for the response. That makes some sense.
So I'm sure you've thought about this. But seeing as how C++ is used heavily in so many tools, libraries, and applications, the performance improvements you're enabling with these techniques are trickling down to power efficiency. So you and your team are doing more to save the planet than Al Gore. That's gotta feel good.
So there was one thing I was thinking about during this whole interview which I don't think was addressed. Basically, from what I've observed in the past, not all CPU instructions are created equal. Some have a higher cost than others.
I don't doubt that vectorizing and fitting multiple operations into a single specialized instruction is faster. But is performing 4 addition operations (for example) in one instruction really4 timesfaster than doing them one at a time?
I actually don't mind the monochrome look. But some of the text areas and lists are a little too gray. It makes them look disabled. For example, the solution explorer and all of the debugging windows should be white since they tend to have a lot of text in them that you'll interact with.
And I do agree about the all caps issue. It's purely an aesthetic thing but the headers of all the windows/tabs being all caps does look funny, especially in that font.
I recently signed up with Azure for a new project of mine. It's a software as a service model where other website owners will install a snippet on their website to gain specialized insights and uncover problems.
So of course its popularity is unpredictable at this point, but it has the potential to see an enormous number of requests every day and may even see drastic bursts of traffic. So scaling has always been at the back of my mind as I'm building it.
Furthermore, it's absolutely true that Azure makes you think about efficiency. Since you're essentially paying for usage, it encourages you to make your application as efficient as possible. I'm always thinking about this as I'm writing the code, designing the database, etc.
I recently incorporated an optimization technique where I'm storing a temporary list of updates in-memory (I'll move this over to Azure Cache soon for better reliability). Then I send these updates to SQL Azure and Azure Table Storage once every minute. Due to my schema design, I'm able to greatly reduce the total number of inserts/updates that have to be performed by using this technique.