Strangely enough, the talk was not about AJAX calls per se, but about various controls, that were explored in alphabetical order, starting from Accordion and going down to calendars, combo boxes, etc. Truth be told, I left somewhere around the letter F.

It also looks like you still want to use good old AJAX toolkit for AJAX calls to ASMX and WCF web services. jQuery also supports that, but with less options or whatever. I am not a real web developer. This presentation should have been called ‘moving from AJAX Control Toolkit controls to jQuery controls’. Anyhow, some jQuery controls are really cool and give your application very slick appearance if you use them right.

The double jeopardy of current situation is that Metro run-time is ideologically closer to Silverlight then to WPF. It is lightweight and will therefore leave out many of the features that WPF has, but Sliverlight does not, like data triggers or multi-bindings. Anyone using a data trigegr or a multi-binding today is using a XAML construct that has no future. From the other hand, Metro apps require async APIs and async/await paradigm, which will make it into WPF 4.5, but not into any upcoming version of Silverlight. So, basically, trying to develop an application that would be then easily ported to WinRT is a futile exercise. It is even more futile in light of was said during the UI guidelines session: even if we could make the code technically compatible, it would be ideologically wrong.

The solution is (surprise-surprise) to keep the actual UI layer thin and put as much logic as much logic as possible into headless business and presentation objects, i.e. models and view-models. Give me an M, give me a V, give me a V, give me an M. What does it spell? Well, don’t sweat it, Model-View-Presenter would also do just fine.

Another, not really related note on Metro. Unlike Android and browsers, Metro lacks global definition of “back” button. Each app can implement its own version of “Back” but it does not work between apps. This is especially problematic if your app launches a browser. You can browse the web, but hitting Back won’t lead you back to the original application, as might be expected, and as indeed happens on Android.

Use simple apps that do one thing well (sounds familiar eh? I wish they found a holy grail and came up with graphical equivalent of UNIX pipes, but alas). E.g. there is no Outlook Metro, there are three different (albeit somehow connected) apps for mail, contacts, and calendar instead.

BTW, contrary to popular belief context menus are allowed in Metro (so that myself), and there is even a gesture for them, but the presenter did not remember what it was

Again, we got a not-so-subtle push to publish cool apps to Windows Store. Also, this was the only demo so far that used VB.NET. All others used either C# or JavaScript.

I am starting to think Metro platform would not be to bad if it were positioned as a stand-alone mobile OS. It would be even better if metro apps could be run in a window on the desktop environment. In fact, Visual Studio has this capability: they shy away from calling it an emulator, saying it uses a combination of RDP and something, etc. etc. So, there is a technical ability to run multiple Metro apps in regular, not full-sceren windows. Instead, for whatever reason we, the desktop users are led into a medieval darkness of Windows 1.0 where windows could not overlap, and they are trying to tell us this is for our own good.

One should listen to the users, but don’t let that obscure your own vision. “I had asked people what they wanted, they would have said faster horses” (c) Henry Ford. One should be clear about one’s goals. Time to market is important: wait too long and you will lose. And so on, and so forth.

There was a not-so-subtle push towards publishing metro apps in Windows store: iPhone and Android market are saturated with apps, Windows apps are a green field. Metro apps are good, because they are “immersive”, i.e. can integrate all features of the device such as GPS, camera, etc. ‘Compatible applications are typically not immersive’. BTW, Firefox spell checker does not know what ‘immersive’ is and underlines it with red

Discussed specialization in the field of programming. Their take is that one must become a generalist, it is impossible to live off a single technology these days. While this might be true, I see deeper and deeper rifts between various technological “continents”. Technology stacks become more and more advanced and extensive, and you just can’t learn them all. It may be relatively easy to switch from B6 to Windows Forms and from Windows Forms to WPF, etc., but jumping from WPF to, say, to enterprise Java programming is damn hard, and it gets harder and harder every day.

Windows Azure came a long way since I last time looked at it. Deploying things became easier. You can RDP into the virtual machine. You can even supply your own bits for the virtual machine, just like on Amazon, and it turns out there is quite extensive support for creating such virtual machines in Windows 7, including a tool called sysprep.exe that will rid the copy of OS from all identity/license information. When you are in Vegas Azure, licensing is on Microsoft. And, on top of all that, you get 750 free minutes a month with your MSDN subscription. This is good, because debugging stuff in the cloud can get expensive quickly.

Pete Brown, Rich Dudley and Vishwas Lele gave excellent presentations on WPF 4.5 and various aspects of WinRT. There was certain overlap (async keyword was mentioned, like, 50 times total ), but not too much to make it boring.

Rocky Lhotka tried (unsuccessfully) to alienate every web developer in the audience by saying that he does not know JavaScript and does not care, and other things like that. Nonetheless, his presentation was quite good. Everyone seems to agree that “the days of plugin-based browser applications (read: Silverlight) are coming to an end”.

They were other entertaining quotes you would probably not find on the slides, such as “google it with Bing”, and “the first thing we write is ‘Hello World’, the next thing we write is a book”. Life of Microsoft evangelists is not always easy.

Allegedly, all user-facing applications are hosted by an invisible “shell”. There were claims and JavaScript/HTML applications are run by Internet Explorer 10, but technically this is not true: they are hosted by special process wwahost.exe.

One can extend WinRT runtime with custom components (“WinMD components”), which can be written in any supported language and used by any other supported language, just like .NET. Certain limitations apply, e.g. if written in C#, component classes must be sealed. Components are not distributed directly to end users, but are shipped to developers. Each application must package all its dependencies with it, there is no central repository like GAC.

WinRT runtime, including custom components, is exposed to user subsystems via “projections”, which were directly compared to CORBA bindings. An intersting (and, IMO, dangerous) feature of “projections” is that they alter not only names (method named PascalCase() would be seen as pascalCase() in JavaScript), but also semantics of certain components. E.g. PropertySet collection throws when adding a duplicate key from C# and replaces existing value when doing the same from JavaScript. Obviously, this could be a source of interesting bugs.

WinRT/Metro application have a different life cycle compared to classic desktop or classic web apps. Unlike a classic web app, the application is one (ever changing) page, so there is no need to save session state, to a point that the word “view state” got completely different meaning in Metro and means screen orientation and the like. Unlike classic desktop apps, Metro apps are not explicitly closed by the user. So, instead of open and close events they receive open, “checkpoint” (suspension, going to background) and optional “resume” event. After going to the background, an application may be either resumed or killed and then reloaded. Ideally, this should be transparent to the user, so the application should save its state during checkpoint and restore it when it opens

Windows. The schizophrenic operating system with two start screens is here to stay. They openly admit it, talking about “desktop side” and “metro side” or even “green side” and “blue side” following the [in]famous architecture slide. I don’t mind if several visually similar ecosystems talk to different APIs under the hood, like POSIX and Win32 subsystem in Windows NT. Having several distinct visual managers on top of the same API also makes sense, like Gnome and KDE. But when everything is different, from input methods to security model, it can hardly be called a cohesive product, IMHO.

Big Brother Development Model. You probably heard that Metro apps take the whole screen, that there are no right clicks, etc. This is all true, but there is more. You cannot develop Metro apps on your local machine without obtaining a special (free) developer license from Microsoft, and this license is good for 30 days. It works per user, per machine. After 30 days if you do not renew the license, you won’t be able to run your own Metro applications on your own machine unless you renew the license. Nice, eh? And this is not a theory: one of the presenters had their license expired during lunch and was forced to rush to renew it. If he did not happen to have Internet connection at the moment, he would not be able to run his own demos. This rule applies only to applications that target Metro runtime, “traditional” applications are not affected.

WPF 4.5. No major changes in WPF 4.5. “Everyone is focused on Windows 8, so it’s a polishing release”. No type safe bindings either. Event ASP.NET got them (ItemType property), but in WPF DataContext remains untyped.

.NET Framework. async and await keywords are the biggest deal on the block, every single presenter mentioned them. This partially has to do with the fact that Metro/WinRT enforces asynchronous call model for potentially time consuming APIs, such as network or file operations The funny part is, they did not have to add new keywords to Javascript – it already has continuations

There was a profound lack of consensus between presenter on whether .NET Metro “profile” is a proper subset of “big” .NET with exactly the same binaries, or the compatibility exists purely on the source code level. The truth is probably somewhere in between.

HTML and JavaScript on Metro. There is a big fuzz about ability to write native Metro applications using HTML and JavaScript. This is technically true, but the resulting applications are not regular HTML/JavaScript applications. They heavily use Metro-specific library called WinJS, which will not appear anywhere else except Metro. So, while they are HTML, they are not cross-platform. Visually HTML Metro applications do not differ from C# or C++ Metro applications.

More later

The development of Git began on 3 April 2005.[12] The project was announced on 6 April, and became self-hosting as of 7 April. The first merge of multiple branches was done on 18 April. Torvalds achieved his performance goals; on 29 April, the nascent Git was benchmarked recording patches to the Linux kernel tree at the rate of 6.7 per second.

Writing a version control system that can host its own source in 4 days is amazing. BTW, April 3, 2005 was Sunday

It also turned out that “git” means “the two of you” in Old English.