The iPad has just launched in the UK, queues are long, stock is short, and it is yet another successful new product from Apple. The iPad has frustrations, like no Adobe Flash support for web browsing, no Java, no printing, and the general sense that you do things the Apple way or not at all. Still, users love it and are willing to pay for it, and in the end that is what matters.
Does this shiny gadget have any relevance to the more humdrum world of business IT? I think it does, especially when taken together with other factors. Here's a remark from Apple CEO Steve Jobs from an informal email conversation with Ryan Tate:
The times they are a changin', and some traditional PC folks feel like their world is slipping away. It is.
Yes, it's a Bob Dylan reference; read the entire thread to see why. Jobs is marketing his company's stuff, of course, but a few days later the stock market put some solid evidence behind his claim. Apple's market capitalisation surpassed that of Microsoft for the first time since 1989. Microsoft remains more profitable; but the figures reflect the market's judgment that Apple has better prospects for growth.
Another sign of change comes from one of Microsoft's most important partners, HP. At the end of April it acquired Palm, and with it the WebOS operating system for mobile devices. Whether HP can make a success of WebOS is uncertain; it will not be easy going up against Apple and Google Android. What is more significant is the implication that HP has finally lost faith in Microsoft's ability to get it right in mobile.
Despite some positive buzz around Windows Phone 7, Microsoft did not help its case when it announced a major reshuffle in its Entertainment and Devices division on May 25th. This follows the bewildering launch of the Kin phone - bewildering because it seems right out on its own in terms of strategy - complete with typical Microsoft flaws according to this thoughtful review:
But the obtuseness of this user experience doesn't stop with the Spot -- it permeates the entire interface as though decisions about how things should work were made almost arbitrarily, without anyone stopping to test them in the real world. The Twitter implementation is a great example of that. You can add your Twitter account to the phone and see updates from people you follow, and you can update your status from the top of the Loop... but that's all you can do. You can't retweet something, you can't send a direct message, you can't go to single person's feed to see all their updates, and you can't even open a link in a Twitter message from the Loop!
Windows Phone 7 will have to be much, much better if Microsoft is to claw back any ground in mobile.
I digress. All that matters is that the world is changing, and looking less Microsoft-shaped with each passing day.
In saying that, I don't mean to diminish the excellent work which I see coming out of some parts of Microsoft - Visual Studio 2010, for example - or to ignore the continuing dominance of the company in many areas of business IT. Many companies still standardise on Windows, and Microsoft Office remains the only productivity suite I come across in work.
All true, but the two great IT trends of today are not centred on Windows and Office. One is mobile, the other is cloud computing; and of course there is synergy between them. Apple's iPad is a further advance for mobile, and will drive increasing mobile data usage and increasing demand both for iPad/iPhone applications and for web applications that work well on those devices.
Microsoft's Open XML standard for Office documents is controversial. Depending on your point of view, it somewhere between a breakthrough in opening up the standard in which the world's most popular office suite saves documents, or a cynical ploy to counter the momentum behind OpenOffice and its rival Open Document XML standard. Amidst all the arguments, it is easy to lose sight of the simple fact that, whatever its merits, Microsoft Office does now save by default in an XML format.
When Office 2007 came out, it was not really sensible to use the new XML formats, such as .docx for Word and .xlsx for Excel, outside the safety of an intranet. If you sent one as an email attachment, there was a good chance the recipient would not be able to read it. Still, now we have Office 2010 and SharePoint 2010, and Open XML has become both more important and less troublesome. It is the only format fully supported by the new Office Web Apps, for example. Further, most of us have had to come to terms with Open XML, at least to the extent that we can open them. Maybe it is time to see if the new formats might actually be useful.
The most obvious advantage of XML is that you can read and write documents using standard XML libraries. There is no need to have Microsoft Office installed, or to try and run it behind the scenes on a web server in order to parse or generate documents. That said, an Open XML document is not a single file akin to an HTML page. Instead, it is a set of related XML files bundled together as a ZIP archive, using another Microsoft standard called the Open Packaging Convention (OPC) If you are curious, you can rename a .docx to .zip, extract the files, and have a look.
If you have in mind to generate Office documents using an XML library, the bad news is that it is not a trivial thing to get right. The good news, at least for .NET developers, is that Microsoft has an Open XML SDK that wraps this complexity. The further bad news though is that the SDK does not free you from having to understand how an Open XML document is put together.
I discovered this for myself after downloading the latest version of the SDK, newly updated for Office 2010. I wanted to investigate how easy it would be to have a web application generate Word documents for download. It turned out to be frustrating. There is what looks like a nice help document with the SDK, including Getting Started articles and a complete reference. Unfortunately, it does not tell the whole story. I was able to generate a simple document in no time, but was soon troubleshooting issues. For example, I found that whitespace at the end of text snippets was getting truncated, so that words ran together, until I figured out that a text element needs the space="preserve" attribute, wrapped by the .NET library as SpaceProcessingModeValues.Preserve. Using styles was also tricky. I followed the supplied article on applying a style to a paragraph, but although I used a standard Word style it was ignored. Styles are no use without a StylesDefinitionPart that contains definitions for the styles you will use.
In the end, the SDK documentation is little more than the famously lengthy Open XML specification, presented as classes and members instead of plain XML. There are few useful code examples.
Open XML is also verbose, and makes you realise how concise HTML is by comparison. You can embolden a word in HTML with a simple <b> element, but in Open XML you have to add a RunProperties element to the Run element that has your text, and then add the Bold element to RunProperties. Microsoft mitigates this verbosity by using very short element names; it is also one of the reasons for using ZIP compression on the final bundle.
It does get better, once you have done your homework on the OPC and Open XML, and created your own wrapper code for the .NET API. There is also a fantastic Productivity Tool included with the SDK, with which you can open and inspect Open XML documents. Its best feature is called Reflect Code, and generates the C# which creates the document you have opened. This means you can get a working example for any document, which can also be used as a starting point for your own document generation. For example, you can set up a document with some dummy text using the styles you need, generate the code, and then amend it to replace the dummy text with your own dynamic content. The only snag is that an innocent-looking and nearly blank Word document includes a large amount of metadata, themes and other stuff, so the generated code is over 2,000 lines long.
Microsoft could do a better job with the SDK documentation, but this is still a powerful tool for parsing and generating documents, and delivers a means of processing Microsoft Office files on the server without Office or SharePoint installed. If you want to know more, the official resource site is here. Finally, a commercial alternative with a more developer-friendly API for both binary and Open XML Office documents is Syncfusion's Essential DocIO; I've not used it but have heard good reports.
I've been testing Microsoft's new Office 2010, along with its equally important companion SharePoint 2010, and trying to decide where it lies between brilliance and disaster. It's certainly an improvement on Office 2007. I was relieved to find that Outlook 2010 performs much better than Outlook 2007 did on its first release. Still, the perenniel question with Office is whether you will actually notice the difference, other than a slightly changed colour scheme, as you get on with typing documents in Word and calculating spreadsheets in Excel. While there is the usual laundry list of new features, there's nothing here as dramatic as the switch from menus to the Ribbon in Office 2007.
The real difference lies elsewhere, in how Office is entering the realm of cloud computing. The likes of Google and Salesforce.com have a straightforward proposition: ditch your desktop applications, store everything on our servers, and run your applications in the browser. Microsoft cannot afford to take that line, since Office is its biggest source of income after Windows itself. It has come up with something more nuanced, offering what it hopes are the most beneficial aspects of the cloud without displacing desktop Office.
Therefore we have Office Web Apps, with in-browser creation and editing of Office documents, but still tied to the desktop applications if you need to go beyond basic features. Office Web Apps can live on Microsoft's servers, such as SkyDrive and the recently announced Facebook tie-in docs.com, or on your own servers as a feature of SharePoint 2010. You can use them from various browsers on Windows, Mac and Linux. Suddenly, opening and editing that .docx or .xlsx - these being the controversial Open XML formats - on Linux is not such a problem. I was pleased and surprised by how much the Web Apps improve SharePoint and change the way I use it.
At the same time, as I dug into the Office Web Apps, I found more and more frustrations. The Office Web Apps use the very same formats as desktop Office, but not all their features are available. For example, you cannot insert a new sheet into Excel via the Web App. In fact, there are so many things you cannot do that listing them would take many pages. That doesn't mean the web apps are useless, they are fine for the basics. Microsoft's solution if you need an unavailable feature: just open them in desktop Office. But what if I'm on Linux? Tough.
This same issue leads to problems which are close to being bugs. Let's say I'm in an Internet cafe using a machine that does not have Office installed, you are in the Office, and we are happily collaborating on an Excel spreadsheet - Office Web Apps even lets us edit it simultaneously. The spreadsheet is nearly done, you feel it needs a little jazzing up, and you open it in Excel to add some Word Art. Oops. Not only is the Word Art invisible to me, but I can no longer edit the spreadsheet. Sorry, says Excel Web App. Incompatible features.
It's something that cannot happen in Google Docs, or Adobe's Acrobat.com, where the web application is the only one that you use. I can see this kind of thing causing endless frustration. Note too that you get no warning when editing a document in a way that introduces web app incompatibility.
Office Web Apps is something we did not have before, and you can see it as glass half full, or glass half empty. Personally I expect to use the web apps, and if they help bring an end to the terrible practice of collaborating by emailing documents to all and sundry, I will be grateful.
Nevertheless, as a cloud offering the Office Web Apps are somewhat broken. It will be fascinating to see how this evolves. My guess is that the Web Apps will improve over time, to the point where installing desktop Office becomes unnecessary for many of us. Microsoft may not like the sound of that, but it is better for the company than the alternative, which is not using Office at all. Never bet against the cloud.
Microsoft has made a release candidate for Visual Studio 2010 available for download, and the rumour is that the final build should be ready in time for the official launch on April 12th. Should you care?
I'd argue that Microsoft's platform is in decline, despite good financial results recently on the back of the success of Windows 7. Windows-only development is increasingly unattractive in a world where Macs, iPhones and Linux devices such as Android and some netbooks jostle for attention alongside the once all-conquering Windows PC. Microsoft does internet too, of course, and even cross-platform for the desktop if you count what is coming in Silverlight 4.0; but even after the launch of Windows Azure this month, the company is not the first to come to mind when you think cloud.
That said, Visual Studio 2010 is a mighty impressive release. It is not just a new IDE, but also includes .NET Framework 4.0, the first complete update since version 2.0 in 2005. Versions 3.0 and 3.5 used the same underlying runtime as 2.0. The Chief Architect is Rico Mariani, Microsoft's .NET performance expert, which has no doubt helped in the tricky transition to Windows Presentation Foundation for the Visual Studio editor and shell; and much of the product is under the oversight of VP Scott Guthrie, one person who still knows how to communicate with developers, and whose presentation on Silverlight 4.0 rescued last year's Professional Developer's Conference from tedium.
Leaving aside the people involved, there is a ton of interesting stuff to explore, including the new F# language, IntelliTrace debugging that lets you step backwards through code, standard UML diagramming, source code management and issue tracking through Team Foundation no matter how small your team, greatly improved libraries and tools for concurrent programming, and if you have the Ultimate edition and the patience to set it up, an extraordinary thing called Lab Management which integrates virtual machines into the automated build and test cycle so that you can verify clean installs into complex multi-machine environments on every build, and use snapshots to analyse bugs at the moment they occur. This is also the first release to be designed with ASP.NET MVC in mind, and to have a full visual designer for Silverlight. Microsoft has also done some good work with Windows Workflow Foundation, in conjunction with a new runtime for the IIS web server called Windows AppFabric, making it easier to build and deploy applications that depend on long-running state management.
There are some disappointments. One is that Visual Studio is out of synch with Silverlight 4.0, so despite developer attention having largely shifted to the 4.0 release, Visual Studio 2010 will ship with Silverlight 3.0 support. There will be an add-on in due course that will put that right. Another is that Windows Azure development is not as smoothly integrated as I had hoped. SharePoint development, while much improved, remains an arduous process that tends to take over your development machine; and there is not much new in mobile development as yet. I am sure there will be plenty of other problems and frustrations; so much here is new that it is nearly inevitable.
These issue have not stopped me from enjoying my work so far with the beta and now the RC. If you have any interest in Microsoft's platform, I suggest you take a look.
I attended Microsoft's Professional Developers Conference last month, with one of my goals being to learn more about Azure, the company's cloud computing platform. I have been meaning to write a post on the subject for some time, but it did not come together until this week, when I listenened to Marc Benioff expounding the Salesforce.com version of cloud computing.
Benioff is ebullient and outspoken; a contrast to Microsoft's Ray Ozzie who gave the Azure keynote at the PDC and conveyed little excitement. Of course, it's easier to be ebullient when your company is growing at 20% per year; but another factor is that the Saleforce.com vision is easier to articulate. Throw out your servers, says Benioff, and move everything to the cloud, that is, to us.
In reality Salesforce.com has a significant integration story, so you can have your on-premise applications talk to your cloud applications, but it is not something Benioff talks about much. Why should he? His company profits when you migrate stuff to his platform; the integration piece is merely an enabler.
Microsoft by contrast makes its money from on-premise software. Its internet services lose money, according to its own accounts. It also has a vast partner infrastructure that is sustained by installing and maintaining its products.
Still, Microsoft knows that it has to do cloud, because the economic benefits to its customers are unavoidable, and because any IT company without a cloud strategy will be punished by the financial markets. In consequence, there is an array of consumer services under the Live brand, and an emerging platform of enterprise services under the Azure brand.
Azure is Windows server in the cloud. You get SQL Server; you get IIS; you get ASP.NET; and it is all pay-as-you-go. So is Microsoft suggesting that we throw out our servers? Considering the profitability of its server division, that would be madness; and indeed, the PDC presented mixed messages about the company's cloud strategy.
This was brought home to me by a session I attended on Bridging On-Premise and the Cloud, given by Windows Azure Distinguised Engineer Yousef Khalidi. Cloud computing, said Khalidi, is a "style of computing with dynamically scalable and virtualized resources provided as a service through the network ... this definition doesn't even say if it has to be on the internet or not. It's a way to think about how an application is structured to fit in a cloud-like model."
Khalidi went on to describe a "spectrum" of computing platforms, from the traditional server or datacenter to private and then public clouds. The forthcoming AppFabric Server will make it easier to run cloud-like applications (according to the definition above) on your internal network, with the option to move it to Azure later should you so desire. "Our strategy, our basic thesis guys, is that there are benefits across the whole spectrum and we'll continue to support the whole spectrum," he said.
The snag is that co-ordinating cloud and on-premise gets complicated, as a glance at one of his slides illustrates.
Well, computing is a complex business and I can understand the appeal of this model to Microsoft-platform companies that require some specific benefit, like pay-as-you-do scalability. As an overall proposition though, it is less attractive than the kind of thing Benioff talks about; it can feel like adding complexity rather than reducing it.
Another issue with Azure is that while it lifts much of the IT administrator's burden, it does little to speed development. You still have to write the code, test it, debug it, deploy it, maintain it. Saleforce.com on the other hand is not only a multi-tenant platform, it is a multi-tenant application. If you are lucky, a little bit of customisation is all you need.
You might not be lucky. You might end up having to write mountains of non-portable code in Apex, the Force.com language. You might run into limitations of the platform, like its difficulty with long-running data processing operations that can interfere with the responsiveness of the system. Salesforce.com is also an expensive platform, with per-user per-month fees for ever.
Still, at least Benioff has a coherent story. I'm not sure that Microsoft does.
The latest news is that Microsoft has re-organized Azure into a new Server & Cloud Division. So now the internal division that has most to lose if Azure succeeds is running the whole show. Technically that makes sense; but the marketing message is going to be even harder to articulate.
I'm just back from Microsoft's Professional Developers Conference in Los Angeles, where the star of the show was the latest update to the Silverlight browser plug-in that lets you run .NET applications cross-platform and within the browser. The pace of development is remarkable. It is only 9 months ago that we were first shown the beta of Silverlight 3, at the Mix conference in March. Silverlight 3 was fully released in July; and now we have version 4.0 beta, with release promised for the first half of 2010.
It is a big release too. Many of the top Silverlight feature requests are being implemented, including printing, right-click and mouse wheel support, a rich text control with editing, clipboard support (though text-only in the beta), drag-and-drop, interaction with Webcams and microphones, multitouch control, improved just-in-time compilation for faster performance, and improved databinding for business applications.
In addition, the forthcoming Visual Studio 2010 is the first to have the kind of Silverlight development tools you would expect, with a true visual design surface and drag-and-drop data binding. On the server, WCF (Windows Communication Foundation) RIA Services simplify the effort of authentication, talking to data, and integrating with ASP.NET.
Another notable feature is the ability to run a Silverlight application out of the browser, started from a desktop shortcut and displayed in a custom window. New in version 4.0 is an HTML control, which embeds IE on Windows and WebKit (used in Safari) on the Mac. These are desktop/web application hybrids. Silverlight 4 blurs the boundaries, by adding a new trusted mode. Subject to the user passing a security dialog, a trusted out-of-browser application gets local file access to user data, cross-domain network access, and on Windows native code interop through COM automation.
The snag with this last point is that any Silverlight application which uses COM automation will only run on Windows, breaking the cross-platform compatibility which is a key reason to use Silverlight in the first place. Although Microsoft says the feature has been put in simply to meet the requirements of a few Enterprise customers, it seems to me that it goes well beyond that, making Silverlight viable in many scenarios that previously would have required a native solution.
Microsoft's ideal scenario is one where applications run everywhere, but run best on Windows, preserving its desktop lock-in. The company calls this "lighting up the platform"; but Windows is somehow the only platform that gets lit up.
I still think it is time to learn Silverlight. The reason is not only Microsoft's signposting of this as its key technology for future client development, but something else I saw last week: Google's Chrome OS. I'll be writing more about this; but I was impressed by how this forthcoming browser-based operating system promises to solve long-standing problems: cheap, lightweight computers that are secure, that start up instantly, that give us access to all our data, but can be left in the back of a taxi without compromising our secrets.
What if Chrome OS catches on? Does Microsoft become irrelevant? The real world does not move that fast; but considering the continuing popularity of the Mac along with the prospect of Chrome OS, it strikes me as brave to presume a Windows-only client for future development. Silverlight on the other hand should run in Chrome OS, either using Mono's Moonlight, or the Intel port being done for Moblin, or perhaps Microsoft itself will have to dirty its hands with Linux. Google might block Silverlight - it was non-committal on the subject at the Chrome OS press briefing - but I'm guessing that concerns over appearing excessively controlling will trump the desire to shut out a competitor.
The point here is not that Silverlight is the answer for all client development; there are plenty of other strong choices. The point rather is that for Microsoft platform developers Silverlight is the technology that makes it possible to take your C# or VB.Net skills and transition them to a new cross-platform, web-oriented world.
At Microsoft Tech-Ed 2009 in Berlin long-time Windows server expert Mark Minasi gave a session on the .vhd format used by Microsoft for virtual hard drives in Hyper-V, the virtualisation feature built into Windows server 2008.
Minasi's talk was not about Hyper-V, but rather about other things you can do with a .VHD. He even noted that in a Windows environment you can use a .VHD as a superior form of ZIP (though without the compression), if you want a single file that can contain windows files and folders while preserving NTFS security attributes, and that can be mounted - or "attached" in .VHD jargon - rather than having to be extracted elsewhere.
One neat trick is to use .VHDs for multi-boot. Multi-boot is less important now that virtualisation works so well, but can still be useful if want to test an operating system with full performance and access to hardware such as accelerated graphics. The old way to do this is with multiple partitions, but this is somewhat inconvenient. Windows 7 is able to boot from a .VHD, and you can set up mutiple VHDs so that you can choose which one to use at start-up. There are a couple of limitations. The operating system has to be Windows 7 or presumably 2008 R2 (which uses the same kernel); and sleep/hibernate does not work in this configuration.
A VHD is still just a file, so you can back it up by copying it elsewhere, provided it is not the one currently running. Note that in this configuration only the hard drive is virtual, not the computer hardware, so while you could go on to mount the VHD in Hyper-V it would be like moving Windows to a new motherboard and very likely would not boot.
Another clever tip is that Windows 7 setup support a keystroke combination, Shift F10, which gives access to the command line for MinWin, the cut-down version of Windows that runs during setup. Here you can get access to Diskpart, the command-line disk management tool, which among other things lets you create a VHD. So you can take a machine with an untouched hard drive, boot into the Windows 7 setup, shell to the command line and create a VHD, then attach and install Windows onto that new virtual drive. Setup actually states that this does not work; but it does work, and we saw it demonstrated.
There are three kinds of VHDs. A fixed VHD has the same on-disk size as its capacity. An expanding (or dynamic) VHD reports the size that you specify when it is greated, but only occupies the space on its host that is needed by the data written there. This is convenient for backup, and lets you over-commit the host drive if you choose to. The third kind is a differencing VHD - a VHD that is based on a parent and only occupies the space needed by its difference as you write to it. The GUI Windows disk management tool does not support creation of differencing VHDs: one of Minasi's points is that you should learn the command line approach using Diskpart in order to get access to all the available features. That said, differencing VHDs are supported in the Hyper-V GUI management tool.
The bottom line is that VHDs have uses that go beyond virtual machines and if you work on the Windows platform it is well worth becoming familiar with them.
At the Future of Web Applications conference earlier this month I spoke to Microsoft's corporate VP of the .NET Developer Platform, Scott Guthrie about ASP.NET MVC. Guthrie is a co-inventor of ASP.NET along with Mark Anders, now at Adobe. A few months back I wrote a piece entitled ASP.NET MVC rescues Microsoft's web platform, but I wanted to hear from Guthrie how he sees the framework evolving, and to explore whether it is time to abandon the older Web Forms approach. How does he see the future of the platform?
"The amount of buzz and religious fanaticism about [ASP.NET MVC] is amongst the highest I've been involved in, certainly since .NET 1.0 and Silverlight. Some people prefer the Web Forms model and I emphasise that Web Forms is not going away, there's all the new stuff that's coming for Web Forms 4.0.
"MVC is an alternative way to do UI and still leverage ASP.NET. For crowds like the one here at FOWA that wants total control over the markup, and who like test-driven development, it's a dream framework. Those folk tend to be more online, so they communicate better which is part of the reason you hear the buzz. I think we'll have more than a million developers using ASP.NET MVC within the first twelve months."
In your talk you mentioned the stackoverflow site which performs very well but runs on not very much in terms of hardware? Is ASP.NET MVC more efficient than Web Forms?
"ASP.NET itself has always been really fast, we've had a lot of success with large sites. One of the things people like about ASP.NET MVC is that the model fits to what they are expecting, for the large LAMP contingent which is heavily represented at this conference. And when they do the performance testing they say 'Holy cow, this thing is fast.' Stackoverflow is a great example, written I think within three weeks and scaling to that level with two machines. Performance is a feature, and one of the reasons StackOverflow works as well as it does is that it's instantaneous response time.
"Conchango just did a site, implemented in 20 weeks, a giant ecommerce project, it's 100% ASP.NET MVC. The SEO is phenomenal, the YSlow rating is phenomenal, they're just blown away. It was fun talking to them last night - the guy was jokingly saying, 'I can't believe it works so well'. It's like the best marketing literature in the world times ten. More and more when I give talks I'd say half the people are new to ASP.NET MVC, and the other half come upand say, 'by the way we've done five sites on it.' That's great to hear."
On equivalent hardware and leaving aside different coding styles, is ASP.NET MVC going to scale that bit better than Web Forms?
"No. The reality is you can build hugely scalable sites with each. Where it does help a little bit is that there is smaller page size and there's a bit more control. There's less abstractions."
And the page lifecycle is shorter?
"It is shorter. I don't think that's making any measurable perf difference. It's more that it naturally flows to what they're doing. I do think it's fast, in the same way that web forms can be fast too. But it promotes a certain way of working that, if you know what you're doing, you tend to build really fast apps."
What about the open source aspect? Are people contributing code?
"People are not contributing code directly to ASP.NET MVC, but we're shippling JQuery and we're shipping JQuery validation which are open source projects, and we are integrating them into our code. With JQuery in ASP.NET MVC version 1.0 we just shippped it, whereas in version 2.0 we have helper libraries that are making big usage of it.
"I'd say that's a first for Microsoft, we're actually taking open source software that has multiple contributors, and using it in a deep way within our own product.
"We ship the ASP.NET MVC source code under an OSI Licence. You can take the code, you can modify it, you can do builds. I know a few people that have done customer tweaks, but for the most part it's that people like being able to learn the product through the code. There's also the reassurance of knowing that if they ran into something, they could fix it."
Would you consider accepting community contributions to the code?
"We've thought about it. I think a lot of people interpret open source as 'hey, anyone can just submit stuff'. The reality is that pretty much every open source project has a closed set of contributors. They come from multiple organisations or backgrounds, but you don't check anything into the Linux kernel without Linus or Andrew signing off on the fix. That would be true of ASP.NET MVC, in that there would be a core set of contributors. At some point I think we will probably open it up to let people to contribute code, or at least patches."
What's new in the latest ASP.NET MVC 2.0 preview?
"The ability to easily do forms validation for input, server-side and especially client-side in a very declarative, easy way, is a huge productivity win.
"'Areas' provide a way to take a large project and easily structure it into multiple small projects.
"New form helpers and what we call editor and display templates for customising them is an innovative way to get strong typing, intellisense and debugging support, and a lot of flexibility in terms of UI generation.
"Asynchronous controllers allow you to call call services on the web, the Twitter, the Facebooks of the world, and much more efficiently scale your web server. The classic problem if you're calling Twitter is what's the response time of Twitter? What's the response time of Facebook? Most web servers are multi-threaded so they're processing multiple requests, but say they have 10 threads running and 15 requests come in, and each of those requests need to go and access Twitter, you're going to block 5 people while nothing is going on on the server. With the Async support we provide a way that you within your app can say, I'm going to wait for a while, yield back the thread, and when the data comes back reschedule me. It can dramatically improve the scalability of the site.
"We're doing a bunch of work around helpers for caching, paging, and a other things. In general it's a compatible release, we're trying to listen to the community, keep it a very transparent, Agile-based development process and knock off the top asks.
"We ship the source to every preview, take lots of feedback. That's the other thing people have really liked about the project, this open feedback. They don't feel like we're telling them, here's the way it is, take it or leave it. They like the fact that we've been iterating with them."
Guthrie is diplomatic about the question of Web Forms versus ASP.NET MVC, and even though I pressed him, would not quite agree that it performs much better. Clearly Web Forms is not going away. Take a look though at some of the comments from practitioners like Howard van Rooijen of EMC (formerly Conchango):
One of the great aspects of ASP.NET MVC is how lean and clean the architecture is - there is so little background noise compared to WebForms; possibly the best illustration of this is the difference between the MVC Request Pipeline vs. WebForm Page Lifecycle. The number of hoops you are forced to jump through in WebForms, compared to MVC is quite staggering.
Overall I heard nothing to change my general opinion, that if you can use ASP.NET MVC rather than Web Forms, you probably should.
Mobile devices are today's development battleground. Timing is everything: I recall Borland's 2003 conference when it introduced an extensive mobile development strategy based on the ill-fated C++ BuilderX, with SDKs from Nokia and Symbian. The sessions drew sparse attendance and Borland later abandoned the product, returning to the Windows-oriented C++ Builder.
So what changed? In part, devices have become more powerful and mobile internet access faster and more pervasive, making the platform more attractive. A bigger factor though is Apple's iPhone. In hindsight, the mobile vendors and operators made mobile development too difficult, with fragmented platforms and locked-down devices. Microsoft has had some success extending Windows to mobile devices, for enterprise development in either C++ or .NET, but its market share is too small, the devices insufficiently well liked, and the deployment obstacles too great. Java had some success too, but write-once, run anywhere never really worked for mobile.
Enter iPhone, with a single platform and easy deployment through the App Store. The "easy deployment" part has to be qualified, since developers have been confronted with limited access to the device, restrictions on what they can develop, and an opaque approval process; but it has worked, and the potential of the mobile platform - about which we have known for years - is now being unlocked.
Other vendors are belatedly rising to the challenge. I'm just back from Nokia's Qt Developer Days, and saw the energy the company is putting into creating a cross-platform, open source mobile development framework. Windows Mobile, Maemo and Symbian are on the immediate roadmap. On the deployment side, Nokia has the Ovi store. I've also been at Adobe's MAX in Los Angeles, where broad mobile support for the Flash runtime was the big story. The Flash runtime is not coming to iPhone yet, but Adobe has a native compiler for Flash applications which targets iPhone. Adobe also has app store plans. Google Android is another platform where all the pieces are in place, and Palm Web OS a new hopeful on the scene.
This means developers now have numerous choices for mobile development, as well as more pressure to create or extend applications to embrace mobile clients. It is not an easy choice. An AJAX application will work on the iPhone and elsewhere, but there is no offline support or access to device features, and the capabilities of mobile browsers vary greatly - though Webkit is becoming a standard on non-Windows devices. Native iPhone works great on Apple's device, but nowhere else. Flash is becoming interesting, but devices with 10.1 will not be around until next year and it is an unproven platform in a mobile context. Windows Mobile will trudge on, though Microsoft's mobile story seems particularly incoherent at present and I expect declining market share. Java on mobile has not gone away either; and Google Android is pretty much a Java platform. C++ will always be attractive for lean, fast applications.
It is fun to pick winners and losers, but impossible to tell how all this will shake out. Here's two safe bets. The first is that mobile, internet-connected applications are in many ways the future of the client. The second is that focusing on a strong web services API (of whatever flavour) is the right place to start. What's your mobile strategy?
I attended a round table to discuss the use of open source software in government, with Red Hat, Ingres, Alfresco, and on the government side representatives from the Office of National Statistics and Islington Council.
It is a fascinating topic on several levels - and not just for government. The two big questions: first, what is the rationale for prefering open source; and second, if you are convinced of its desirability how on earth do you get a huge, diversified entity like the UK government to increase its adoption?
There is clearly some kind of disconnect. The government already has a policy which stops short of mandating open source, but does say:
Where there is no significant overall cost difference between open and non-open source products, open source will be selected on the basis of its additional inherent flexibility.
In other words, given two otherwise equal proposals, open source is favoured - yet in practice we were told that 95% of software in use in the UK government remains proprietary.
So why is that? There are dozens of reasons. It's the available skills, with armies of experts in Microsoft, Oracle, IBM, and so on, compared with only a few willing to specify open source technologies. It's the culture, with countless existing supplier relationships and a well-trodden procurement path with the usual suspects. It's the existing envirnonment: if you start from a point where the servers are Windows, say, and the desktops all have Microsoft Office, it feels more comfortable to continue down that path. It's the lock-in, especially when it comes to things like proprietay SQL extensions and stored procedure languages, that simply do not port easily to new database managers. And it's canny vendors, who go for site licences with the widest possible scope, so that if a small group decides to break the mould and use something different, it looks more like a cost than a saving - because they are already licenced for the proprietary stuff.
These are tough obstacles to overcome. Put another way, the rationale for adoption has to be exceptionally strong to overcome the inertia; and it was here that I found the round table unconvincing. The open source companies gave diverse reasons for the benefits. Lower cost was mentioned frequently. By contrast, John Powell, President and CEO of Alfresco, talked intensely about how the UK was somehow handing over its soul to silicon valley, by not building up local skills in open source software. Someone else said how nice it was that open source software was free so that everyone in an organization could use it; another gently observed that since most open source companies make their money from support agreements that are per user, this is often not the case.
The most persuasive rationale is that open source software tends to support open standards and therefore avoids lock-in. This lowers long-term costs, by ensuring that the customer always has freedom to switch.
The snag with all these arguments is that the proprietary companies can counter them easily. They will reel off all the open standards they support. They will draw graphs showing how much money you save by using their stuff. They will point out that those with skills in their technology can easily market them worldwide. The outcome is that nothing changes.
I don't doubt that leading vendors make excessive profits on software that should be commoditised and cheap, or that vendors follow strategies designed as much to keep us hooked on their stuff, as to advance technology for our benefit. It's a cycle that needs to change.
At the same time, the open source vendors have to recognize - and to be fair, I reckon they often do - that most of us will not switch for ideological reasons. We want to get our work done. The best open source projects, things like the Apache web server (if there is anything like it) succeed on sheer quality and reliability, not merely through being open source.
The tough question: does the open source ecosystem have sufficient resources to deliver that quality, against proprietary vendors with huge profits to pour into research and development? There are plenty of decent open source products; the number that are truly best of breed is more limited. Currently it is the big proprietary vendors that have the advantage.
I left the table with more questions than answers. Should governments introduce more draconian legislation, to counterbalance the industry bias towards the status quo? Will the move towards cloud computing break the pattern? Should legislation be focused on mandating standards support, or even that applications should be proven to work on two different platforms, rather than the matter of open versus closed source? If today's MySQL is tomorrow's Oracle, is there really any difference? Isn't there too much to worry about already, solving problems and delivering successful projects?
If pressed, I would always incline towards the best technical solution, rather than one which ticks boxes, even open source boxes. That said, we are all susceptible to being bamboozled, not even looking at open source alternatives if we already know a proprietary tool or component or platform that will do the job. Even for individual developers, it makes sense to choose the open source solution in cases where other things are equal; and to think twice before building vendor lock-in into the applications we create.
Tech media pundits talk incessantly about migration to the cloud, but it is always interesting to get reports from the trenches. Two recents ones interested me. The first is from Patrick McKenzie, who sells a niche Java application. He's just posted a detailed and entertaining blog entitled Why I'm Done making Desktop Applications. His application exists in both desktop and online versions, and he says he was a staunch defender of the advantages of desktop apps - "You can keep your Google Docs, Excel is superior in almost every way." Then he made an online version of his app with if anything fewer features, and tracked the statistics. He discovered the following:
His conclusion:
The next major release will almost certainly be its last. The webapp, and my future webapps, seem to be much better investments.
Does any of this apply to corporate development? It's true that life is easier in some ways if you do not have to make a sale; and there are still some things that desktop applications do better, like integrating with Microsoft Office through COM automation, or continuing to work offline on the train or plane - though see Rails creator David Heinemeier Hansson's You're not on a plane for a contrary view.
Still, many of the other factors do apply. Lower support requests, zero installation, accurate usage monitoring - all these things have immediate financial benefit.
It is no longer web application developers who have to justify their case, but rather those who still advocate desktop development.
If you need any further persuading, take a look at this survey of 1400 Microsoft's small business customers by Accredited Supplier. Apparently 62% prefer business applications that work through a browser, and only 18% prefer desktop applications. The more chilling news for Microsoft is that 13% actively intend to switch to Google Apps - with all that implies for sales of Windows server, Exchange, and Office - while only 36% are sure that they are not switching.
All that cloud talk is translating rapidly into business decisions. I'm not sure whether the future of the business application client lies more with AJAX and HTML 5, Microsoft Silverlight, Adobe Flex, or something else; but for sure it is not a desktop technology.
The Apple Mac's OS X is a gorgeous operating system, beloved by its users, but outside the niche world of designers and musicians it is generally not the one used in business. It's an odd situation that puts pressure on system administrators to accommodate Macs into their systems, either from the aforementioned designers, or from eager home Mac users who want to enjoy it at work as well.
Last week Apple released OS X Snow Leopard, also known as OS 10.6. I was at Apple's flagship store in Regent St, London following a press briefing, and watching throngs of people line up to purchase their upgrades left me in no doubt about the Mac's continuing success. Nevertheless, because of its high price and lack of business penetration the Mac remains a minority choice. The figures are slippery, but it may be around 10% of the US market by units, 20% by value (the difference showing how expensive they are), while worldwide it is much smaller.
Now Apple has introduced native support for Exchange as a key feature of Snow Leopard, apparently giving admins one less reason to deny would-be corporate Mac users. Is it enough?
Unfortunately the Exchange support still falls short. I've spent several days working almost exclusively in the new OS, and explored the new Exchange support in Snow Leopard. Although there is a lot to like, such as deep integration with Mail, iCal and tasks, there are snags. For a start, you need Exchange 2007 SP1, and earlier versions remain common. Even if that is in place, Snow Leopard's Exchange support still falls short of Outlook on Windows. The new feature is based on Exchange Web Services (EWS), which do not expose all the features of Exchange.
I found myself missing features like the ability to send on behalf of another user, and access to public folders. Another practical problem is that unless Exchange is configured with EWS in mind, it might not work at all, especially when trying to connect over the public internet. Outlook has its problems, but its ability to use RPC over HTTP, avoiding the need for a VPN connection, is a brilliant feature. It is also strong at seamless online/offline support, stronger than Apple Mail. I'm also not convinced that Mail's new Exchange support is quite done, as evidenced by several crashes like this one:
The real issues are broader than this. Macs still fit awkwardly into Windows-based networks. System administrators like standardisation: standard application deployments, standard operating system builds that can be zapped and re-imaged; standard configurations that can be enforced using Windows group policy. The presence of Macs adds unwelcome complication.
There's also the matter of application compatibility. If your business depends on some little application written in Visual Basic 6 or Microsoft Access, for example, you have to figure out a way for Mac users to run it, by emulation, or terminal services, or some other route.
In the short term then, Snow Leopard will not transform Enterprise Mac adoption. Nevertheless, the Mac is a huge influence, beyond what its market share implies. Further, if a significant number of users are using Windows grudgingly, wishing they were not, that is not good for productivity.
Here's three suggestions. The first is to think cross-platform. The past is the past; but for new applications it is short-sighted to target only Windows. I suspect this lesson has largely been learned, but it still bears repeating. Have a cross-platform client - Silverlight may help for .NET developers, or there is Adobe Flash/Flex, or Java, or pure Web applications, to mention a few solutions.
Second, learn from Apple. Microsoft is doing so, and Windows 7 is the evidence. An interview I did with Bill Buxton last year gives further background.
Third, is it really so hard to accommodate Macs? Yes, there are still issues, and different factors apply in every organization, but few problems are insurmountable.
Incidentally, I am no Mac Zealot. I actually like Windows, and although I'm currently immersed in OS 10.6, I intend to go back to using a PC most of the time. Some things are better on the Mac, some things are not, and most things are more expensive. It does pay though to have users working in the environment they prefer; and where that is possible, it makes sense to allow it.
Recently I have been working with Microsoft Silverlight, looking at how to put together a simple database application. I am no designer; my interest in Silverlight is to do with cross-platform deployment, a consistent runtime, and an alternative to HTML and Javascript. It seems I am not alone in this respect; the Silverlight forums are dominated by programming rather than design queries. Here are the message counts at the time of writing:
The Silverlight 3 wish list is also illuminating. You soon get a feel for what developers are most frustrated about, such as: no printing support, no easy way to save documents to the user's hard drive, ugly fonts, no clipboard support, no access to devices like web cams and microphones, and no support for WSHttpBinding which adds transactions and reliable messaging to web services.
Only a few of these things are fixed in the Silverlight 3.0 beta. There is a file save dialog, and text rendering is improved though Microsoft is a long way behind Adobe Flash in this respect.
That said, Silverlight 3 does offer substantial improvements for business applications. For example, in Silverlight 2.0 you have to handle client-side validation manually, whereas Silverlight 3.0 adds validation support similar to what is in ASP.NET. There is also a new server-side piece called .NET RIA Services, which wraps key areas like authentication and transactions. Although Silverlight cannot do real transactions, .NET RIA Services introduces changesets, which let you bundle a set of database updates into a single web service call. You can also include arbitrary custom operations, such as approving a purchase order. On the server side, where you do have transaction support, this is processed and can succeed or fail as an entire unit.
Despite the snags, there is a lot to like in Silverlight. As a GUI framework it works really well, and it is good to know that special effects and transitions are available are available if you need them. Microsoft appears to have executed well on the challenge of creating a smaller, cross-platform build of the .NET Framework, which is really Silverlight's key advantage.
Another plus is the ability to work in Visual Studio with the server and client projects side by side, integrated for debugging. You can set a breakpoint in the Silverlight client, and another in the ASP.NET web service implementation, and it just works.
Presuming that Microsoft's continues its rapid pace of Silverlight development, my guess it that it will evolve into an excellent client for .NET applications, since this is what the community is demanding. As yet though, Silverlight has made little impact on the wider world of web design, which remains dominated by Flash, and it is hard to see that changing.
Too strong? Maybe, but the ASP.NET Web Forms programming model has run its course. It was hugely impressive when it originally appeared - I remember it being announced as ASP+ in 2000, and how phenomenal it seemed. You can build a web page visually, using a rich set of controls, and have ASP.NET abstract away much of the problem of managing state. It also lets you write code in any .NET language, which is just-in-time compiled at runtime for fast performance.
ASP.NET works the same as ever today; but the web has moved on. The Web Forms model makes programming the web more like programming Windows, which was cool at the time but not any longer.
Fortunately for Microsoft, it has an alternative, called ASP.NET MVC. The first full release was announced at the Mix09 conference last week, and you can download it now. I took the opportunity to ask some of the delegates what they thought of it.
The reactions I got fell into two broad categories. The first group found it difficult to puzzle out what it really was, even those who had attended sessions on the subject. The second group loved it, and never ever wanted to go near Web Forms again. In fact, such was the frustration with Web Forms among some developers, that they had developed their own alternative frameworks but were now moving to the official one.
So what's wrong with Web Forms? Complaints I heard include that it is not testable; that it is not really compatible with AJAX; that it is inflexible; that ViewState, hidden form data which preserves state across page refreshes, is a nuisance; and that it is hard to write REST-style applications or those which properly support the Back button.
Enter ASP.NET MVC, which answers all of these complaints. MVC stands for Model View Controller, though having played with it a little I find the name somewhat misleading, as well as being a mouthful (contrast the delightfully-named MonoRail, which is an interesting alternative). Why misleading? Well, it doesn't have much of a Model, as this post observes. It does have views and controllers; but I think one of the reasons developers find it hard to grok is that starting with a discussion about MVC architecture is not the best way to teach it.
I think the place to start is with URLs and routing. It also helps to know that ASP.NET MVC follows the principle of convention over configuration (though not to the same extent as Ruby on Rails). In a nutshell, ASP.NET MVC breaks the link between the URL in the browser and aspx files on the web server; instead, it processes the URL and returns what you want it to return.
A "View" in ASP.NET MVC is an .aspx page, but in the form of a lightweight template, not a Web Forms with a complex page lifecycle.
I've been playing with ASP.NET MVC recently, and it is a delight. Yes, there is more manual coding than with Web Forms, but it is worth it for the additional control you gain. Even the performance seems better, a consequence of the lightweight approach. As it happens, I'm also a believer in test-driven development. I guess I'm in the second group that I spoke to at Mix09.
Microsoft is not killing off Web Forms; rather, it is very insistent that they remain under full development. I get the impression that the company expects ASP.NET MVC to be a minority choice.
Nevertheless, if you work with ASP.NET do not hesitate to check out the new framework. Personally I think ASP.NET MVC might just rescue its web platform from a slow but inevitable decline.
I'm at Microsoft's Mix09 conference in Las Vegas, where the big news (aside from small matters like the final release of Internet Explorer 8) is the beta release of Silverlight 3.0, Microsoft's browser plug-in that competes with Flash as a platform for rich internet applications.
Silverlight 3.0 is stuffed with new features, one of which is the ability to run outside the browser. Right-click an applet, choose Install onto this computer, and suddenly you have a desktop application complete with a shortcut in the Start menu, or on the Mac desktop. This has triggered a debate over how SLOOB (that's Silverlight Out Of Browser) compares to Adobe's existing AIR (Adobe Integrated Runtime), which supports Flash applications running on the desktop.
Understandably, Adobe folk like Ryan Stewart are emphasising the differences:
"I think AIR and the Silverlight OOB (Out of Browser) are two very different technologies for two very different scenarios...AIR is about letting you take your web application skills to build desktop applications and Silverlight OOB is more about letting you take your Silverlight applications to the desktop. The different models will be different for everyone, but right now AIR gives you a lot more flexibility and more API hooks into the operating system."
The big issue is how much these desktop/web hybrids interact with the local machine. Microsoft makes a point of how SLOOBs run in the same sandbox as they would in the browser, which means the user can install without a security prompt, but also that the application has very access to the user's desktop. The only access to the file system is to a protected area called isolated storage, or via a file dialog that the user controls. Microsoft says there might (or might not) be a way of displaying notifications but that is about it.
AIR applications by contrast run with the same permissions as the user. Installation involves the user consenting to a dialog which usually threatens unrestricted access to the system. Your AIR app can read and write any files that the user can read or write. There is also a notification API, and support for drag-and-drop.
That said, AIR applications are also restricted by design. They cannot be extended with native code, or execute other applications. Adobe has always presented AIR as a way of delivering web applications on the desktop, rather than as an alternative to C++ or .NET for traditional desktop applications. So is it really so different from SLOOB?
Well, some of the AIR features do give it an edge. One is the ability to fire notifications (annoying though this can be). It's something that Microsoft definitely intends to add to SLOOBs, though I get a different answer every time I ask about it; it might not come until Silverlight 4.0. Another difference is that AIR can host HTML as well as Flash content, which is an advantage for applications that depend on both. AIR also includes an embedded relational database engine, SQLite, whereas SLOOB developers will have to roll their own or use XML, though I doubt this is really a big deal. One other thing: Silverlight knows nothing about printing, which is unfortunate when running outside the browser.
Nice features; but I still feel that AIR and SLOOB are close competitors. Both take a cross-platform, rich internet application runtime and make it available from a desktop shortcut and with offline support. That makes a huge difference to users, even if the technical differences between running in or outside the browser are not so great. SLOOBs are going to be attractive to .NET developers because they include the .NET runtime and can be developed in the familiar Visual Studio IDE.
Personally I'd like to see an option to run AIR applications sandboxed, as full file access is more than most of them need. I'd also like an option to run SLOOBs with greater local system access when needed. Why not have the best of both worlds?
In the meantime, I'm expecting both to succeed. For applications that will work as a SLOOB, it makes a great user-friendly, cross-platform alternative to Windows Forms; and we've already seen effective user of AIR for cloud-centric utilities like Twitter clients. Both platforms are also highly effective for visualizing data. Who knows, this approach could become the norm for a wide range of business applications.
Historically, the web development choice between the Microsoft platform and open source has been a fork in the road with many consequences. Choose Microsoft, and you generally use Visual Studio, Internet Information Server, ASP.NET, C# or Visual Basic, and SQL Server for the database manager. Choose open source, and you most likely target LAMP in one of its guises, the most common being Linux, Apache, MySQL and PHP, and work in Eclipse or almost anything other than Visual Studio.
Recently the boundaries have been blurring a little. Apache actually runs nicely on Windows, and I've used it happily to host a Subversion repository, while on the other side Microsoft has been making an effort to support PHP in IIS 7.0. But what about running ASP.NET on Linux, is that a silly idea?
I've been following the efforts of the Mono project in this area for some time, though it's been a while since I've tried it out. Mono was originally focused more on desktop than web applications, and I've used it mostly in that context. When laterooms.com tried Mono in early 2006 it quickly gave up, citing problems with Mono's Boehm garbage collector; see the developer's comments to my blog post at the time.
Still, that was three years ago. I had another look a couple of weeks ago, and I've been impressed. In particular, the ability to develop in Visual Studio and deploy to Linux is interesting. I'm working on a small project, and getting this working is remarkably simple. I used Visual Studio 2008, but set the project to target .NET Framework 2.0, as Mono lags behind Microsoft in implementing the latest .NET APIs, and using MySQL rather than SQL Server, since this is available on my Linux web server. Using MySQL with .NET is straightforward thanks to the official ADO.Net provider, which specifically supports Mono as well as Microsoft .NET.
On the web server, running Debian 5.0 Linux (Lenny), I installed the libapache2-mod-mono and mono-apache-server2 packages using Aptitude. Next, I configured Apache to use Mono on a particular web site, with a few lines of manual configuration, as explained here, and imported the MySQL database from the Windows development machine to the Linux web server.
Back in Visual Studio, I compiled the web site, uploaded it, and it worked first try. Performance is good as well.
I realise that a number of caveats apply. It's worth reading this page, the current Mono todo list, which notes some of the important areas where Mono is lacking and includes the comment:
Mono is known to be not as performant as the .NET Framework.
Note that Mono still uses the Boehm garbage collector, though an alternative is in development. Further, Mono does not implement the entire .NET Framework. Mono is a brave choice; Windows and IIS the sensible option for .NET applications.
It still seems to me significant that you can easily deploy to Linux and Apache using Mono. Not all applications are mission-critical, and not all applications need to scale as well as Laterooms.com. Mono has a number of attractions. First, it is open source, so in the event of problems you can always obtain and amend the source code. Second, running on Apache and Linux is a considerable saving in license costs. Third, you can get official developer support from Novell.
Why would you use C# and ASP.NET rather than PHP or Java? The main reason would be because you know and like the language, the platform, and/or the Visual Studio IDE. In an interesting report on the state of the computer book market, O'Reilly notes that C# is now the largest programming language for all book sales. Thanks to Mono, you can use C# but still deploy to an open source platform.
It also seems to me that Microsoft's official support for Moonlight, the Mono implementation of Silverlight, is important. Microsoft now needs Mono, in order to tick the cross-platform box and compete with Flash, giving more assurance to its long-term future.
Mono's growth over nearly a decade has been slow but steady. Perhaps now is the moment that it creeps into the mainstream.
Are you using Mono, for web or desktop development? I'd be interested in your comments.
Microsoft's Eric Nelson conducted a poll on how many businesses still use Visual Basic 6. It is hard to make sense of the statistics, since there was a built-in bias:
This survey was sent out to individuals we "suspected" had Visual Basic 6.0 heritage but it was also widely advertised through the MSDN Flash to UK developers.
In other words, only Windows developers were consulted, and those more likely to be using VB 6 were specially targetted. Some results:
See the original post for more detail. I'd like to know more about the wider picture - how many companies overall still use VB 6 - but although these figures are skewed I can well believe that there is a lot of VB 6 out there.
Incidentally, the respondents are correct in believing that the VB 6 IDE is no longer supported. Extended support ended in March 2008. However, note that Visual Basic for Applications, which partly shares the same runtime, remains part of Office and therefore is supported. The VB 6.0 runtime is supported at least until 10 years after the release of Windows Server 2008; see this paper for exactly what is and is not included.
I noticed that msvbvm60.dll, along with other VB 6.0 runtime files, is also in my beta copy of Windows 7. I guess that will nudge the support life for the runtime even further into the future.
The bottom line is that Microsoft would be crazy to release a mainstream version of Windows that could not run VB 6 applications. For the most part, laggard VB 6 developers are safe, though there could be third-party components that stop working. Another point is that VB 6 will always be 32-bit.
All this prompts a few observations.
First, if you have skills in VB 6.0, it looks like you will be in demand for a while.
Second, my own views on VB 6.0 are mixed. I recognize that it was a revolutionary and very capable tool; but if anyone is inclined to wax lyrical about its merits, I point them towards Verity Stob's Thirteen Ways to Loathe VB and Bring your Hatchet by Bruce McKinney. At best, it is a flawed platform.
Third, I do see the sense in leaving well alone in many cases. VB 6.0 is lightweight compared to .NET, and runs on a wider range of hardware. Migrating code is perilous unless you have rigorous unit tests; some quirk in VB may catch you out, so that ported code does not work in quite the same way.
It strikes me that there is little value in migrating from, say, a VB 6.0 client application to a .NET Windows Forms application. My instinct would be either to leave it be, or redesign it as a web application. Otherwise the risk is that your new ported application will be just like the old version, but slower.
Microsoft has a summary of the options here, which seems to promote the idea of hybrid applications, perhaps using the Interop Forms Toolkit to embed .NET controls in VB 6 forms. Maybe, but there is a danger of getting the worst of both worlds. That said, every case is different so there is little value in generalizing. The important thing is to have a technical and business rationale for the path you choose.
Hyper-V may not be the best virtualization platform out there, but it does not have to be. Its unique selling point is deep integration with Windows Server 2008, complete with an easy to use management console. I've been using it extensively, though on modest hardware, and overall I'm impressed. Enable the hypervisor in the BIOS, install the Hyper-V role, create a new virtual machine, and go. I've used both Server 2008 and Windows 2003 as guest operating systems, and everything works as advertised. You can assign an .iso image to the virtual DVD drive, which is handy for me as an MSDN subscriber, since I test new Microsoft software by downloading it from there. A great feature is that you can backup both host and guests in one shot, even when the machines are running. Provided that the Hyper-V integration services are installed in the guests, the host backup will talk to the Volume Shadow Copy Service (VSS) in the guests to ensure the integrity of the backup.
Hyper-V is handy for Windows developers since you can run servers like SharePoint and Exchange without the clutter and expense of real boxes. Once the new machine is up and running, I generally connect through remote desktop on another machine, and it looks just like any other remote Windows server.
That said, there are a few snags with Hyper-V. While performance is generally good, I've found that disk I/O can get slow. There are a couple of things you can do to mitigate this. One is to be generous with RAM - more memory means less disk access. Second, Microsoft states that a fixed virtual hard drive is faster (though less convenient) than a dynamic virtual drive, which is the default. It is possible to convert from one to the other, though it is a slow operation.
Another issue is that because of the VSS integration, you should not attempt to back up simultaneously from the guest and from the host. It would be easy to do this by accident through scheduled backups, as Microsoft also recommends that you should do both kinds of backup for critical servers.
Using the supplied Windows Server Backup in a Hyper-V guest is awkward, since drives attached through USB or eSATA are not recognized automatically in the guest. You can backup to a network share or a second mounted virtual hard drive. I've heard that this problem is fixed in Hyper-V R2, which you can currently download as a beta.
The subject of Hyper-V and domain controllers is rather complex. Sandy Berkouwer has two separate posts which are helpful. Actions like pausing or saving state in a domain controller can cause problems, and Berkower suggests that having at least one physical domain controller is wise. Microsoft warns against having the host machine joined to a domain managed solely by a guest.
Another issue is that if you are unlucky, and are using snapshots (giving the ability to roll back to a previous time), Hyper-V can occasionally revert to an earlier time without being asked. If this happens, shut the machine down right away and see if you can recover it, as I did, by restoring a backup and doing a manual merge with the snapshot differencing file.
Microsoft appears to be handling the Linux integration services with all the enthusiasm you would expect. You can find the services here - though you have to sign in with a Live ID. Only Suse Linux Enterprise Server is supported, and the site forum, which is noticably lacking official Microsoft participation, includes telling comments. Why does the code have build dependencies on Xen (an open source alternative to Hyper-V), and only works with version 2.6.18 of the Linux kernel? However, note this comment from a user:
For anyone not aware, doing even light disk IO under a hyper-v linux guest without linux_ic will chew on your cpu the entire time, which makes it very unusable for any server that's not mostly idle.
The good news on the Linux front is that Microsoft has just announced an agreement with Red Hat to support Red Hat Enterprise Linux 5.2 and 5.3 - 32-bit and 64-bit, but apparently uniprocessor only - complete with integration services; we have to hope this works out better than the Suse partnership has, so far. It deserves some effort from Microsoft, since running a LAMP stack on a Windows Server machine via Hyper-V is useful.
Despite some hassles, Hyper-V is invaluable, and there is now little excuse for wasting power and space on numerous lightly-used servers. Virtual servers have many advantages, in cost, in ease of management, in flexibility, and in backup and restore. My guess is that they will become the norm for test as well as for production, hosted either locally or in the cloud.
There is a kind of Windows 7 fever sweeping the Web right now. Some observers are getting carried away:
As a person who performs almost every computing task on a Mac and tells anyone who will listen that at this point, the average consumer should be using a Mac instead of a Windows machine because of security and usability, I'm starting to prep myself for the single moment that I thought would never come: I'll be using a Windows 7 machine as my main computer and telling anyone who will listen that, believe it or not, using the latest Microsoft operating system really is worth it. [Don Reisinger]
I've spent a lot of time in Windows 7 these last few weeks, and in some ways I see what he means. It has a smoothness and elegance that is lacking in Vista, though it is there to some extent in Server 2008. But let's be clear: the popular view that Vista is rubbish and Windows 7 is great does not stand up to close analysis, for one simple reason. It is just not sufficiently different. Microsoft actually makes a positive of this characteristic, explaining how preserving the core architecture of Vista ensures good application and driver compatibility and therefore a smooth upgrade.
What about Windows 7 versus the Mac? I agree that Windows 7 is superficially more Mac-like; and more important, that the factors that made Vista such an unpleasant experience for some (not all) early adopters will not apply. I'm thinking of things like laptops that were underspecified, or had buggy drivers, or barely adequate graphics hardware, or that were weighed down with so much foistware that Windows would hardly run. However, other factors that make users prefer Macs will not have changed. There is the control Apple exerts over both hardware and software; its design excellence; the fact that Apple is less tolerant of legacy software, whereas Microsoft has Windows jump through hoops to keep it running,adding complexity and inconsistency; and there is the absence on the Mac of the culture of chaos that afflicts Windows. I'll leave aside religious arguments about Unix vs Windows, though it is a matter of record that OS X has to date proven far more secure, for whatever reason.
Let's ask some awkward questions. Will a substantial number of Windows 7 machines fall victim to viruses, worms, trojans and botnets? Almost certainly. Will Windows 7 from time to time flummox users with obscure errors like "the system could not find the file specified"? Almost certainly. Will some Windows 7 machines be built down to a price and be sold with obvious design flaws and insufficent attention to quality? Almost certainly. Will some vendors wreck the sweet install experience Microsoft has created by imposing their own clunky utilities and third-party trialware on top? Almost certainly. Will the Windows 7 event log become populated with perplexing entries like "The Workstation service terminated with the following error: The redirector is in use and cannot be unloaded." (plucked from my Windows 7 beta 1 laptop)? Almost certainly.
Let me add that I realise how smooth and reliable a well-managed Windows machine can be. Further, while I have had some frustrations with Vista it has always been stable for me and I have never wanted to go back to XP. Vista, then, is better than its reputation; Windows 7 is better than Vista but will have trouble living up to the proclamations made by its more enthusiastic admirers.
Adobe's MAX conference in San Francisco this week was focused on what it calls the "Flash Platform", a technology stack oriented round the Flash multimedia runtime. The "platform" word highlights the fact that you can code for Flash and have your application run everywhere that Flash runs, including Windows, Mac, Linux, and some mobile devices as long as they are not from Apple. It is not a complete platform, being essentially an Internet client, though there are some server-side pieces such as LiveCycle Data Services, to simplify and optimize communication between Flash clients and Java middleware. You can also blur the distinction between browser and desktop with AIR, which runs Flash outside the browser and adds a local database engine.
So what's new? There was the usual set of announcements. The key ones are as follows:
AIR 1.5: an update to the desktop runtime which adds support for Flash Player 10 features such as Pixel Bender, for runtime graphical effects, and an option to encrypt local databases. There is also the SquirrelFish JavaScript interpreter - though this only comes into play if you are running JavaScript within HTML, rendered by WebKit, rather than ActionScript without the Flash runtime, which has its own just-in-time compiler. AIR 1.5 is available now.
A new version of Flex and the Eclipse-based Flex Builder IDE, code-named Gumbo. This has a new skinning and component architecture, more advanced text rendering, easier two-way data binding and a new Client Data Management (CDM) feature which from early descriptions looks reminiscent of a .NET dataset. You work with data on the client, storing updates locally, then zap the updates back across the wire in a single update operation. One thing that is not yet clear to me is the extent to which CDM requires LiveCycle on the server; I'll be sure to clarify this in a couple of weeks at MAX Europe (I was not present at the US event). The database aspect is significant, because so many enterprise applications boil down to CRUD (Create, Retrieve, Update, Delete) in one form or another.
Catalyst, formerly code-named Thermo, was previewed. This is a fascinating product which converts Photoshop artwork into Flex code; it also allows designers to create and preview a degree of interaction in their designs. Catalyst shares the same project format as Flex Builder. Again, I will be taking a closer look at MAX Europe. Here's a preview screen grab:
Cocomo (yet another codename) is a cloud effort from Adobe, focused on conferencing. Adobe hosts the services and provides Flex components to enable file sharing, text and VOIP (Voice over IP) chat, whiteboards, and data messaging; there is also user management built in.
Alchemy is a tool that converts C/C++ code to ActionScript, for execution within the Flash player. It's intended for re-use of existing libraries, not for general development.
Third-party announcements that caught my eye included Ensemble's Flex add-in for Visual Studio (though I was underwhelmed by the preview), and Zend's addition of AMF (Action Message Format) into its PHP Framework. AMF is a binary format that optimizes data transfer between servers and Flash clients.
Although none of these announcements is spectacular in itself, taken together they show the momentum behind Flash as a client for applications as well as video and multimedia, as I have mentioned here before. A good thing? Designers love Flash because of the freedom it gives them, along with the excellence of Adobe's design tools - Creative Suite 4 really is spectacular. Nevertheless, I have a nagging concern that if we adopt Flash rather than AJAX - interactivity in HTML and Javascript - for our next-generation clients, we are giving away the openness of the Web, because Flash is proprietary technology. I recommend this thoughtful post from Google's Brad Neuberg, which recommends not only open-sourcing the Flash runtime, but also integrating it more deeply with the browser and embracing web standards. There's little chance of Adobe adopting Neuberg's proposals, but he does a good job of spelling out the issues. Flash is compelling, as is Microsoft's Silverlight, but each is controlled by a single vendor. Do you think that matters? I'd be interested to hear your opinions.
Concurrent programming was a major theme at Microsoft's recent Professional Developers Conference. We all know the reasoning: processors are no longer getting faster, but multiple processors are now commonplace. Even my desktop PC is a quad-core. However, having multiple processors is no guarantee that applications will run faster. For that to happen, the application has to be coded with concurrency in mind. Therefore, if we want to write fast applications, we have to learn concurrent programming.
Unfortunately concurrent programming is hard. Think deadlocks, synchronisation, non-determinant, race conditions, and so on. Fortunately, Microsoft is good at making hard things easy. The original Visual Basic transformed the coding of a graphical user interface from something intricate done in C or C++, to something anyone could do with a few clicks of the mouse.
Now Microsoft aims to do something similar for concurrency. The .NET Framework 4.0 incorporates the Parallel FX Library, which does a great job of simplifying multi-threaded development. The new Task Parallel Library is smart about how many processors it finds at runtime, and spins the right number of threads to take advantage of them. PLINQ lets you easily apply parallelism to LINQ queries. Daniel Moth does a great job of demonstrating the benefits in his session at PDC, which you can watch online; and if you work with .NET I highly recommend it.
The worrying aspect is that while Microsoft is making concurrency easy, it is not making it safe. When I was playing around with Visual Studio 2010 and .NET Framework 4.0, one of the first things I did was to look at my code for counting primes and to see how I could optimize it. I found I could do so easily by changing a For loop to use Parallel.For instead, one of the features of the new library. I got a nice speed boost on a two-core machine, not quite double, but nearly so. One snag: the result changed every time I ran it.
I soon figured out what was wrong. My code declares a numprimes variable, then increments it within the loop. Everything is fine when single-threaded, but if you have two threads running the loop in parallel, they might both increment the variable at nearly the same time. That means reading the value, incrementing it, and writing it back. Occasionally this happens:
Result: the value is one less than it should be. The fix is to lock the value first, or to find a better approach; this exact problem is discussed here (scroll down to Aggregation).
Bugs are nothing new in programming, but concurrency bugs are particularly tiresome. The code may work fine on some machines; in my example, the bug would not occur on a single-core PC. If your loop is a little less tight than a prime number calculator, it might be that the odds of the bug occurring at all are rather small. It could even pass all your unit tests. Deploy the application though, and you can bet that wrong results will soon crop up with the usual potential for calamity.
Haven't we already had, and survived, this problem with previous abstractions like BackgroundWorker, a class in .NET Framework 2.0 that makes it easy to push some code into a background thread? True to some extent, but BackgroundWorker is less dangerous because it is typically used more for keeping an application responsive, than to increase performance with parallel threads on a multi-core system.
The bottom line is that while I am full of admiration for the work Microsoft has done with the Parallel FX, I have a nagging worry that as more and less skilled programmers are encouraged to do this, we may be introducing a new wave of buggy code, as argued in detail by Edward Lee in his paper The Problem with Threads [PDF]. The hardware trend is real though, so I suspect greater concurrency in everyday business applications is coming whether we like it or not.
The other conclusion is that before using something even as apparently simple as Parallel.For, developers have a responsibility to learn about the pitfalls as well as the benefits.
I'm at Microsoft's Professional Developer's Conference (PDC) in Los Angeles, where we've heard a ton of stuff about Microsoft's forthcoming technology. A lot of the press has focused on Windows 7, and that's understandable since Windows is what many of us stare all day. I've been running Windows 7 myself since Sunday, in an pre-beta build, and I'm both impressed and unimpressed.
The good bit: Windows 7 is better than Vista in every way I can think of. Even in the pre-beta, it is fast and stable. Even better, Microsoft has worked on making Windows "quieter" - reducing the number of distracting dialogs and notifications, and giving users more control over them.
Too much "toast" popping up in the system tray? Just choose "Customize", and you can turn off notifications from applets that are annoying. Too many prompts from Vista's User Account Control, the thing that flashes the screen and asks, "Did you really want to do that"? Now there's a simple slider that lets you minimize the prompts. Provided that you avoid the lowest level, security is not much compromised.
There are other user interface changes, but the nagging question is whether Windows 7 really merits a full new version number. In fact, Microsoft says there are no core architectural changes, which is great for driver and application compatibility, but reinforces the impression that this is just Vista done right.
The biggest innovation (if you have never seen an iPhone) is the multi-touch control, which lets you use your fingers instead of the mouse. You can scroll windows with a flick of the wrist, and pinch the screen to zoom or rotate what you see. Impressive; but whereas this works well on the iPhone which is designed from scratch with this in mind, there are a couple of problems applying it to Windows. First, most of use don't have touch screens, and while that might change, it's also possible that the technology will go the same way as the current Tablet PC, into a small niche. Second, how many application developers will make the effort to support touch properly? Watch this space; but I guess it is possible that mouse and keyboard will remain by far the most common way to control Windows.
The more interesting themes at PDC are outside Windows itself. There's cloud computing, there's Visual Studio 2010, there's news on the future of C#, which as its architect Anders Hejlsberg pointed out, is now a decade old, and plenty more. I'll post separately on some of these topics.
Nevertheless, Windows 7 will be a welcome upgrade when it comes. Which is when? Microsoft won't tell, but I'm guessing we may have it in our hands by this time next year, probably earlier. OEM vendors will want it for the Autumn. To hit that date, Microsoft will need to be complete the OS by the summer. Given the lack of major changes under the hood, that strikes me as plausible.
