All posts by onlyconnect

Visual Studio 2012 hits and misses

A few quick reflections after writing a rather large review of Visual Studio 2012, Microsoft’s development tool for everything Windows.

Several things impressed me. The Graphics Diagnostics Tools for Direct3D, for example, is amazing; you can capture a frame, select a pixel, and drill down into why it is the colour it is. See Amit Mohindra’s blog post here. Though admittedly I got “Unable to start the experiment session” on my first go with this; make sure the Debugger Type is set to Native Only.

image

Graphics is not really my area; but web development is more like it, and I continue to be impressed by what Microsoft has done with Windows Azure. You can go from hitting New Project in Visual Studio to an ASP.NET MVC 4.0 web site up and running on Windows Azure in moments. Even if you add an Azure SQL database into the mix it is not much harder. The experience is slightly spoiled by the fact that the new Azure portal for web sites etc is still in preview and seems to be a bit unreliable; I sometimes get an error when logging in and have to refresh before it works. That is a minor detail though; the actual deployed web sites and applications seem to work fine.

That said, it was also apparent to me that Microsoft’s Azure story has become a little confusing. Want an ASP.NET web app on Azure? Choose between a Web Role, a stateful VM, or a web site. Both web roles and web sites can be scaled quite effectively, thanks to the built in load balancer for web sites. Still, choice is good, as long as the differences are understood. It appears that Microsoft is still backing the web role approach as the most architecturally sound; but web sites are so easy to use and understand that it would not surprise me if they are more successful.

Another hit with me is the SQL Server Data Tools (SSDT), once I understood the difference between DACPACs and BACPACs – a DACPAC encapsulates the schema and logins etc for a database in a single file that you can import elsewhere, whereas a BACPAC also stores the data. The approach in SSDT is that a database schema is just a bunch of SQL scripts, and that if you manage it that way it makes a lot of sense in terms of version control, schema comparisons, deployment and maintenance.

On the ALM side I am impressed with Team Foundation Server Express, which is genuinely easy to install and lights up most of the key features of Microsoft’s ALM platform, though it does not handle the full SharePoint team portal or all the reporting features. Cloud hosting is also an option for TFS and that also worked OK for me, though with occasional delays as my code crossed the internet.

I hesitate slightly with TFS though. It feels like a heavyweight solution, whereas most developers like lightweight solutions. I know that open source tools like git and subversion only do a fraction of what you can do with TFS; but they also never keep me waiting.

I also wonder whether TFS simply creates too many artefacts. Work items seem to multiply rapidly as you use the system, which is good for traceability but could also become a bit of a bureaucratic nightmare if you have team members who make every action into a thing that needs comments and deadlines and links to source code and so on.

I guess it is like any other tool; it will work well for a team that already works well, but will not solve problems for a team that is already a bit dysfunctional.

I had not looked at Microsoft’s modelling featurs for a while; I was interested to discover new code generation features in the UML diagramming tools.

I am slowly beginning to understand what Microsoft is doing with apps for SharePoint. Get this: Microsoft is moving SharePoint 2013 towards being more of a service than a platform; you do not build apps on SharePoint; you build apps that use SharePoint services. This means you can at last develop SharePoint apps without having SharePoint installed on the same box as Visual Studio (thank goodness). And you can build SharePoint apps with PHP or Java as well as ASP.NET, because they are calling SharePoint, not running on it. Makes sense.

So what is not to like? There are a few puzzles, like the way Visual C++ has fallen behind in standards compliance despite the presence of Herb Sutter at Microsoft.

I also still find the whole XAML/Visual Studio/Blend thing a bit of a struggle. One day I will open up Blend, Microsoft’s XAML designer, and it will all fall into place as a natural and quick way to build a user interface, but it has not happened yet. I have also heard that developers should find the designer in Visual Studio enough; but at best it is rather slow and a little unpredictable.

Otherwise the tools for Windows Store apps seem decent to me, though I have heard that advanced developers are finding some issues; not surprising considering how new a platform it is. It is a distinctive platform, and my sense it that while there is a lot to like, developers need time to get the best from it, and there is also scope for Microsoft to improve it, maybe a few refinements in Windows 8 SP1?

Considering its scope, Visual Studio was relatively stable in my tests, though I did once get it into a state where it froze every time I tried to debug an application; fixed by a reboot (sigh).

I do not mind the monochrome user interface; I do not like it especially but it is something you get used to and do not notice after a short time.

Overall? Few people will use everything that is in Visual Studio and of course I have missed out most of it in the above, but it is a mighty achievement and still an asset to Microsoft’s platform.

Windows 8 discoverability: users searching for search

I have been poking around in the Windows Store as the public launch of Windows 8 approaches, and was intrigued by the reviews for the Wikipedia app, which is nicely done. Several users complain about the lack of a search function:

image

In fact the Wikipedia app has excellent fast search, on the Charms bar:

image

The problem: when you open the Wikipedia app there is no visual clue of where to find Search. Even if you have figured out that you need to right-click, or swipe up, to show the menu bar, it does not show a Search option.

image

The Wikipedia app developers have done the design correctly, in terms of Microsoft’s guidelines. This is the “Immersive user interface” which shows content rather than distracting UI furniture.

Another advantage of having Search on the Charms bar is that you are just a tap away from performing the same search in other apps, such as Internet Explorer.

The concept fails though if users simply do not discover key functions. What is the use of an encyclopaedia without search?

It does not help that the Charms bar, which is where Search lives, is hard to summon with the mouse. It is OK on a tablet (swipe from the right) or with the keyboard (Windows Key + Q). With the mouse, you have to position the pointer vaguely in the top or bottom corner and wait for Charms to fade into view if you have done it correctly. It is a vague movement with no feedback that you have initiated an action, like a button that does not click.

I presume though that as users live with Windows 8, Windows Key + Q will become natural when looking for a Search function (hah!). It is fair to say though that the UI does not score highly for discoverability.

How Adobe turned on a pin to embrace the web (and Google)

Adobe’s Create the Web world tour – which came to London yesterday – is in the public unveiling of of Adobe’s new wave of tools, the first since it turned away from Flash and towards open web standard, hardly a year ago.

image 

Michael Chaize is a developer evangelist at Adobe. I asked him when it became clear to him personally that Adobe was no longer a Flash platform company.

“The main shift happened November last year [2011]” he told me. “It happened when we, for the Flash part, decided to just focus on video games and premium video, and invest in HTML tooling and specifications with a team of engineers. It was synced with the decision to stop developing Flash in mobile just to focus on apps with Adobe AIR.

“Now we are almost a year later, and Create the Web is an opportunity to showcase the work that has been done. All the product that have been launched, the Edge tools and service, just started in November of last year.”

The timing was confirmed by Adam Lehman, product manager for Edge Code, a tool built on Bracket, which is an open source project created by Adobe to provide a lightweight, code-centric editor for HTML 5 technologies. I asked him when work on Brackets started. Research started in mid-2011, he said, but “we got the team together in December 2011 and started coding.”

image
Adam Lehman

The Edge tools are intended as focused, lightweight product each targeting a specific small part of web design, in contrast to typical Creative Suite products such as Dreamweaver which encompass a large area of functionality; a valid approach but one which inevitably leads to huge tools that take an age to load and a lifetime to learn. Edge is also being used as a not-to-subtle way to promote Adobe’s subscription-based Creative Cloud, since the tools are only available by that route. As a further sweetener, you can get some of the tools as part of the free subscription tier.

It is remarkable that Adobe has navigated the difficult transition from Flash to HTML, and the difficult transition from shrink-wrap to subscription, with so little pain.

That said, perhaps the transition from Flash to HTML is not as profound as it first appears. The Flash runtime was always free, while Adobe made its money from design tools, and as the web become more capable, designing for the Web looks increasingly similar to designing for Flash.

Even the community is the same. “When it deals with expressive web, motion design, we feel that the Flash community can reuse their skills,” said Chaize.  “Being a Flash developer is not just about the language, it’s a knowledge, it’s a culture. Agencies tell me, ‘When I need to hire a motion designer for HTML, I hire a Flash guy.’

That said, HTML 5 is still inferior to Flash in some respects. I watched a slightly jerky animation showing off HTML 5 capabilities and could not help thinking that it would run more smoothly in Flash (of course it was all preview software). It will get there though. This is why Adobe is working to bring specifications like CSS shaders and CSS regions to the official standards.

There is another thing I noticed at Create the Web, which is the extent to which Adobe’s new tools are built on Google’s platform. Many of the Edge tools are made with the Chrome Embedded Framework; the browser used for demonstrations is Chrome Canary, a preview build implementing the newest standards, and if you look at the code you see abundant use of the WebKit prefix which designates features currently specific to the WebKit browser engine used by Apple, Google and others. There is also extensive use of WebGL, popular with designer but contentious because some browser vendors consider it a security risk and it is not an official web standard.

Lehman insists that there is no intention to go down a Google-specific route. “It was more of a technology stack we went with,” he says, explaining that the intent for Brackets is that it will one day run in the browser, in which case it will have to support Mozilla, Opera and Microsoft browsers as well.

The reason for adopting so much Google stuff is partly the excellent fit with what Adobe needed, and partly the low friction. “We didn’t have to go to a meeting, it was just published” said Lehman, referring to the Chromium Embedded Framework which let you run HTML5 applications on the desktop.

Brackets looks great, has real community adoption already, and Adobe has interesting plan for its future. Along with browser hosting, Lehman talks about proper debugging support with breakpoint, JavaScript macros, an embedded node.js engine, and more.

When Apple rejected Flash in iOS it put Adobe in a difficult spot – another reason for the company’s warmth towards Google and Android – but since then the transition has been remarkable.

Appcelerator mobile developer survey shows Windows 8 progress, uncertainty

Cross-platform mobile tools vendor Appcelerator has released its latest mobile developer survey (in conjunction with IDC) representing the views of around 5,500 developers using its tools.

It is worth a read this time around. I was particularly interested to see what Appcelerator developers think of Windows 8, launching later this month. There is a chart showing the percentage of developers who are “very interested” in developing for various mobile platforms, and which shows Apple iOS leading at 85%/83% for iPhone and iPad, Android next, then HTML5, and then Windows 8 Tablets at 33% – already ahead of Windows Phone as well as Amazon and RIM devices (RIM has declined from 40% in January 2011).

image

The report says that potential Windows 8 developers are most interested in the “shared development capabilities between desktop and tablet promised by Microsoft with the launch of Windows 8.” I am not sure exactly what this means, and of course surveys like this are broad-brush and different developers will have meant different things. It could be about code sharing between desktop applications and Windows Runtime (WinRT) apps. It could be about the ability to run WinRT apps on the desktop as well as the tablet. It could be about Visual Studio and its ability to target multiple Windows platforms. However, the the survey goes on to talk about a “single paradigm for both desktop and tablet/smartphone applications” which seems to look forward to a future Windows where desktop applications really are legacy.

There is also a note that there were as many developers convinced that they will not be building apps for Windows 8 or Windows phone, as those who were.

What really counts is in the next paragraph in the report:

A large installed base of devices was the #1 criterion for 53% of developers when asked about why they choose to develop on a platform

This is the simple truth, which is why Microsoft has chosen a strategy which puts WinRT on every Windows 8 box whether or not it is really wanted.

The report also states that developers are dissatisfied with HTML5 for mobile applications, in terms of monetization, security, fragmentation, performance, and more. I suggest not taking too much account of this since Appcelerator’s Titanium tool is an alternative to HTML for mobile apps, so will have attracted those who do not want to use HTML5.

Finally, there is a fun section on what devices developers think they will be targeting in 2015. Televisions head the list, followed by connected cars. Most intriguing though are the final two: foldable screens and Google Glass. Apparently 67.1% believe Google Glass is in their future. Surveys, always entertaining but given the volatility of the results, not something you can rely on as a predictor.

Here comes TypeScript: Microsoft’s superset of JavaScript

Microsoft’s Anders Hejlsberg has introduced TypeScript, a programming language which is a superset of JavaScript and which compiles to JavaScript code.

The thinking behind TypeScript is that JavaScript is unsuitable for large projects.

“JavaScript was never designed to be a programming language for big applications,” says Microsoft’s Anders Hejlsberg, inventor of C#. “It’s a scripting language.”

The ubiquity of JavaScript makes it remarkably useful though, with that now extending to the server thanks to projects like node.js. Microsoft is using node.js for its Azure Mobile Services.

TypeScript therefore lets you use features including type annotations, classes, modules and interfaces to make large projects more robust and maintainable.

Variable names are preserved when TypeScript is compiled. Further, since TypeScript is a superset, any JavaScript code can be pasted into a TypeScript project. The compiler is open source and you can download an early version here.

Microsoft is also trying to stay close to the specification for Ecmascript 6, the proposed next iteration of the official JavaScript standard, where relevant.

There is tooling for Visual Studio including a language service to provide code hinting, syntax highlighting and the like.

TypeScript differs from projects like Google Web Toolkit or Script#, both of which also emit JavaScript, in that it does not compile from one language into another; rather, it compiles into a reduced version of itself.

Why is Microsoft doing this? That is the interesting question. I would conjecture that it is partly self-interest. Microsoft itself has to write increasing amounts of JavaScript, for things like Office Web Apps (apparently written in Script#) and the new Azure portals. Azure Mobile Services uses JavaScript as mentioned above. JavaScript is also one of the options for coding apps for Windows 8. Better tools will help Microsoft itself to be more productive.

That said, the arrival of TypeScript will re-ignite the debate about whether Microsoft, while not anywhere close to abandoning .NET, is nevertheless drifting away from it, towards both native code in Windows and now JavaScript in the managed code space.

More information from Microsoft’s S Somasegar here.

A glimpse into the internal battles that set the future of Windows and .NET

A couple of posts from Hal Berenson give insight into the internal battles at Microsoft as the company worked out its strategy to rescue Windows from irrelevance in the world of mobile and tablets. Berenson is now President of True Mountain Group LLC but was formerly at Microsoft where his roles included SQL Server development and architecture, Mobile Development Tools strategy, and General Manager of Forefront identity and security products.

image

Berenson left Microsoft in October 2010, but by that time the strategy behind Windows 8 and Windows Phone 8 would have been in place.

According to Berenson, there were two core options for evolving Windows. There may have been others, but the heart of it is this: what to do with .NET. One option was to make .NET the app model for Windows, which is what was planned for the original Longhorn, before it was reset and became the less radical update that was Windows Vista. The other was to create a new app model based on native code. Steven Sinofsky, the Windows President, chose the latter, which is why .NET is only one of three options for programming the new tablet personality in Windows 8. This meant going down the opposite path from that of Windows Phone 7, which has an entirely .NET-based programming model.

You may recall from other sources that Steven Sinofsky has never been known to be a .NET fan.  While others within Microsoft, and even senior people in the (pre-Windows 8) Windows organization, wanted to move to an entirely .NET app model for Windows Steven did not.  He (and others fyi) wanted to re-engage the native code C++ developers that Microsoft had been neglecting.  And they wanted to co-opt the huge base of web developers to create apps for the Windows platform.  Well, what had the Windows Phone guys done?  They’d implemented a .NET only app platform.  Could the Windows Phone app platform evolve to address the native and web developers?  Sure.  But with no existing library of apps and a desire not to have .NET-centric platform at the core of Windows Sinofsky apparently felt pretty comfortable ignoring the Windows Phone team’s work.

This goes a long way to explain the puzzlement many of us experienced when it transpired that having created in Windows Phone 7 the basis for a touch-friendly operating system that could easily be extended to larger form factors such as tablets, Microsoft chose instead to do a new thing entirely for its tablet strategy.

One take on this is that Berenson’s account illustrates the chaos at Microsoft. Windows Phone was created in a mad hurry in reaction to the iPhone and the ascendance of touch UIs, reusing pieces of .NET, Silverlight and Zune to bring something to market quickly. Then the company’s next move was not to build on that, but to throw it away, even in the context of a mobile and device revolution that was and is a huge threat to its core business. And where was CEO Steve Ballmer in all of this?

The other take though is how this shows the determination and strategic focus of Windows boss Steven Sinofsky. He did not believe that rebuilding the Windows user interface on .NET would save it, with the Longhorn experiment no doubt a factor in that conviction, so he refused to go down that path again, despite the cost in terms of time and, perhaps more seriously, the impact on the developer ecosystem. Microsoft platform developers were asked first to bet on .NET and Silverlight, and now to bet on this new thing the Windows Runtime, and many are disillusioned or even angry. A hard decision; but putting long term strategy ahead of the immediate demands of your customers may be the right thing, in fact the only right thing.

Berenson also confirms what many of us have always assumed: that the removal of the Start menu on the Windows 8 desktop is all about making the new personality in Windows hard to avoid:

The Start menu, and indeed the entire desktop, are legacies that will have to be removed from Windows over time.  While the desktop itself is probably with us for a couple of additional major Windows releases (though there may be truly desktop-free editions sooner than that) the start menu was something that Steven has bet he could get away with not bringing forward into Windows 8.  By doing so he forces users to start living in the new usage paradigm rather than totally avoiding it.  Yes you can still set up a system to avoid leaving the desktop most of the time.  But you can’t avoid the new world completely.  In doing so he sets people up to eventually accept systems without the desktop at all (or at least Windows RT systems for personal use even if they need the desktop at work, for example).

Personally I no longer miss the Start menu; but its absence is certainly a barrier to adoption for Windows 8, as new users struggle to navigate the operating system.

Note: Berenson has kindly commented below. Note his point that merely working at Microsoft does not give you detailed knowledge of all decisions made there.

AT&T partners with Twilio to offer cloud communication apps

Telecommunications giant AT&T has partnered with Twilio to offer cloud communication apps through a web portal:

Powered by Twilio’s cloud communications services and API platform, ACS offers a Web portal for AT&T business customers to browse from a collection of voice and SMS-enabled apps — such as appointment reminder services, polling & surveying data collection tools, ad-hoc workgroup calling & messaging, business continuity, and geo-smart messaging.

When I read the announcement I was reminded of this talk by Laura Merling at the Redmonk Monki Gras conference last year:

Her final prediction? “Jeff Lawson becomes the CEO of AT&T. Why? Because the model has to change.”

Adobe using Google Chromium Embedded Framework for Edge tools

Adobe has published a mission statement which is worth a read if only to demonstrate how far the company has moved away from Flash, once positioned at the heart of its ecosystem – remember the Flash Platform?

The mission statement essentially declares the web as the new heart of Adobe’s platform and it is working to bring HTML, CSS and JavaScript up to the level of richness and interactivity that is possible in Flash.

This even extends to apps and applications, and I was interested in this statement:

The web platform also lives outside of browsers. It’s used by apps, particularly on mobile devices, where the richness of the web platform makes it possible to deliver great user experiences. Adobe will continue to invest in the Apache Cordova project, and Adobe’s distribution of it, Adobe PhoneGap™. When appropriate, Adobe is using the web platform to build tools and services. For example, Brackets, Edge Code and Edge Reflow are built using HTML, CSS and JavaScript using the CEF open source project, to which Adobe is contributing.

CEF is the Chromium Embedded Framework, which is a web browser control based on the open source version of Google’s Chrome browser. It is a C/C++ project but third parties have created wrappers for .NET, Delphi, Java and Python.

It is not long ago that Adobe would be looked to AIR, based on Flash, for a project like this. Incidentally, AIR is also able to host a WebKit-based browser control so would have been viable. Using CEF means getting to use Google’s V8 JavaScript engine rather than ActionScript.

Adobe Creating the Web, offers Edge animation tool for free

It is less than a year ago that Adobe pivoted wholeheartedly from Flash to HTML, a moment that to mind was marked by the acquisition of Nitobi, the PhoneGap company, announced at MAX in October 2011.

Yesterday Adobe clarified its plans for its new wave of web design tools branded Edge. These are as follows:

Edge Animate

A motion and interactive design tool for animating web content with HTML, JavaScript and CSS.

image

Edge Inspect

Preview HTML content on mobile devices for test and debug.

image

Edge Code

This is a commercial product based on the open source Brackets project – a similar relationship to the one that exists between Adobe PhoneGap and the open source Cordova project.

Edge Code adds Adobe integrations such as with Edge web fonts and Typekit, and with PhoneGap Build.

image

Edge Reflow

image

Design tools for CSS, preview expected by end of 2012.

Edge Web Fonts

Free web font service for open source fonts.

TypeKit

Commercial font library service.

PhoneGap Build

Package web apps as native apps for mobile platforms, without needing to install SDKs on your own machine.

PhoneGap Build is free for open source apps, or costs $9.99 per month for up to 25 private app builds.

The Edge tools are only available through Creative Cloud, Adobe’s subscription service, cementing the company’s move to a subscription model for its products. As a tempter, Edge Animate is currently available even to those with the base, free subscription – though you have to agree to be on a marketing list for email, mail and telephone.

image

Will the Edge tools replace Dreamweaver, the web design tool in Creative Suite? I was told not, and that an update for Dreamweaver is in preparation. Dreamweaver is the “one production tool” as opposed to the Edge tools each of which focus on one narrow area of features. Adobe describes this as task-focused tools.

More information in yesterday’s San Francisco keynote here.

Microsoft’s Azure Mobile Services: node.js and more in beginnings of easy cloud to device development

Microsoft announced Azure Mobile Services last month and it was mentioned by Microsoft Server and Tools boss Satya Nadella at the launch of Visual Studio 2012, as an example of where Microsoft is going with its “Modern app” vision, continuous services and connected devices (but with a Windows 8 or Windows Phone 8 flavour).

Azure Mobile Services is in some ways a reworking of the WCF RIA Services developed to support Silverlight applications, and in fact I swear I saw a reference to RIA Services flash past when I was opening my first Azure Mobile Services project in Visual Studio. It consists of a service type in Microsoft’s Azure cloud combined with a client SDK which is currently for Windows Runtime apps in Windows 8, though the REST protocol used could be called from any client platform.

image

Looking at the dashboard for a Mobile Services project in the Azure portal, you can see what Microsoft is going for here. Mobile Services handles authenticated access to data stored in SQL Server Azure. It is designed to be simple and cost-effective to get started, but can be scaled out by moving from a service on a shared host, to a dedicated VM with multiple instances.

image

It is easy to think of cases where the cloud component of a cloud plus device app need do little more than authenticate users, and retrieve and update data. Azure Mobile Services also provides for server-side scripts which you can modify to handle validation and other tasks.

I was interested to see that the server-side scripts are written in JavaScript and executed by node.js. Node.js is fantastic, and one of the benefits is that if you have an HTML and JavaScript client, you can use JavaScript both on the client and on the server. On the other hand, I wonder if Microsoft’s community would rather work with C# on the server, which is more mature and more familiar. Scott Guthrie’s introductory tutorial does not mention node.js.

I had a quick go at creating my own Azure Mobile Service. I have only been partially successful so far.

Things started well enough. I created a mobile service and the Quick Start opened.

image

Both Guthrie’s blog and the Quick Start wizard in the Azure portal are based on a todo list app. I went slightly off-piste here, deciding instead to create an app to track my articles on the web. I wanted to see how Azure Mobile Services copes with related tables, as opposed to a single table.

I had a frustrating time trying to create the database tables. I had to add my IP address to a firewall rule, enable popups, and deal with connection failures caused by unknown network issues.

Finally I was able to get into the database designers. I created an Articles table joined to a Publications table, with a very few fields.

Next I downloaded an automatically generated Windows 8 app from the portal. I had hoped this would magically work with my data. Unfortunately though, it seems to be hard-coded for the todo list app. If you do not want a todo list, you have to write your own code; and so far I have not had time to figure out from the reference what to do next. I looked at the Get started with data article, and guess what, it is the todo list again.

When you create a database, you can specify simple permissions. The todo list example depends on an application key stored in your app and sent over SSL, to grant permission to read and modify data. I selected authenticated user access instead.

image

There is an article explaining how to add authentication, though note that it presumes use of a Microsoft Live ID (the service formerly known as passport). This is perfect in the context of Windows 8 and Windows Store apps, but businesses will want to use Active Directory instead, whether hosted in Azure or Office 365 or on premise. I presume Microsoft will add this at some point though it is not mentioned currently.

My initial conclusion is that Azure Mobile Services shows lots of promise, but that the introductory documentation could be usefully improved, for example not to assume that you want to make a single table todo list app.

In this context the partnership with Xamarin, which is extending the SDK to Apple iOS and Google Android, is excellent news. This makes Azure Mobile Services useful more broadly, and I have a hunch that Xamarin’s support will soon improve the documentation and tutorials. The client SDK is open source and on github.

Note that according to Microsoft’s Kirill Gavrylyuk, in answer to a question from Roger Jennings, Microsoft plans to “roll out full support for iOS and Android including native SDKs soon”, rather than leaving the non-windows support entirely to Xamarin and C#.