Category Archives: javascript

Single sign-on from Active Directory to Windows Azure: big feature, still challenging

Microsoft has posted a white paper setting out what you need to do in order to have users who are signed on to a local Windows domain seamlessly use an Azure-hosted application, without having to sign in again.

I think this is a huge feature. Maintaining a single user directory is more secure and more robust than efforts to synchronise a local directory with a cloud-hosted directory, and this is a point of friction when it comes to adopting services such as Google Apps or Salesforce.com. Single sign-on with federated directory services takes that away. As an application developer, you can write code that looks the same as it would for a locally deployed application, but host it on Azure.

There is also a usability issue. Users hate having to sign in multiple times, and hate it even more if they have to maintain separate username/password combinations for different applications (though we all do).

The white paper explains how to use Active Directory Federation Services (ADFS) and Windows Identity Foundation (WIF, part of the .NET Framework) to achieve both single sign-on and access to user data across local network and cloud.

image

The snag? It is a complex process. The white paper has a walk-through, though to complete it you also need this guide on setting up ADFS and WIF. There are numerous steps, some of which are not obvious. Did you know that “.NET 4.0 has new behavior that, by default, will cause an error condition on a page request that contains a WS-Federation authentication token”?

Of course dealing with complexity is part of the job of a developer or system administrator. Then again, complexity also means more to remember and more to troubleshoot, and less incentive to try it out.

One of the reasons I am enthusiastic about Windows Small Business Server Essentials (codename Aurora) is that it promises to do single sign-on to the cloud in a truly user-friendly manner. According to a briefing I had from SBS technical product manager Michael Leworthy, cloud application vendors will supply “cloud integration modules,” connectors that you install into your SBS to get instant single sign-on integration.

SBS Essentials does run ADFS under the covers, but you will not need a 35-page guide to get it working, or so we are promised. I admit, I have not been able to test this feature yet, and aside from Microsoft’s BPOS/Office 365 I do not know how many online applications will support it.

Still, this is the kind of thing that will get single sign-on with Active Directory widely adopted.

Consider FaceBook Connect. Register your app with Facebook; write a few lines of JavaScript and PHP; and you can achieve the same results: single sign-on and access to user account information. Facebook knows that to get wide adoption for its identity platform it has to be easy to implement.

On Microsoft’s platform, another option is to join your Azure instance to the local domain. This is a feature of Azure Connect, currently in beta.

Are you using ADFS, with Azure or another platform? I would be interested to hear how it is going.

Don’t miss Ryan Dahl on Node.js

I’m just back from Dreamforce in San Francisco, where one of the sessions I enjoyed most was from Ryan Dahl in the Cloudstock pre-conference event.

He is the author of node.js, a binding for the V8 Javascript engine, not for running in the browser but for creating server apps. However, it is interesting even if you don’t want to use V8, because of the approach he takes to concurrency and I/O. I wrote up the session here, under the title Nginx the new Apache, node.js the new PHP?

What was Dahl doing at a Dreamforce conference? That was a question that puzzled me, until later in the week when it was announced that Salesforce.com is acquiring Heroku. Heroku has been experimenting with running node.js on its hosted infrastructure for Ruby applications, and may come up with a Ruby wrapper.

Speeding page load with dynamic JavaScript

I’m delighted that ITWriting.com is sufficiently popular to sustain some advertising. I’m not pleased though with the impact on performance. The problem is that ads such as those from Google Adsense or Blogads are delivered by remote scripts. It usually looks something like this in the HTML:

<script type="text/javascript"
  src="http://some/remote/script.js">
</script>

When the browser encounters this script, it stops and waits until the script returns. This means that your site’s performance depends on the performance of the site serving the script. At times I’ve noticed significant slowdown – though to be fair, Google is normally faster than most others in my experience.

So how can this be fixed? I’ve spent some time on the problem, but with limited success. Ideally I’d like an Ajax-y solution where the ads flow in after the rest of the page had loaded and rendered, because the content is more important than the ads. The first step though is to place the scripts at the end of the page, so that the rest of the content is downloaded first. However, the ads have to appear towards the top of the page, otherwise the advertisers will not be happy. I tried inserting the script dynamically like so:

var addiv = document.getElementById("addiv"); //where the ad is  to appear
var theScript = document.createElement("script");
theScript.type="text/javascript";
theScript.src = "http://some/remote/script.js"; 
addiv.appendChild(theScript);

While this works after a fashion, it does not do the job. The problem is that the script typically calls document.write. If you are lucky, the ad will appear at the bottom of the page. If you are unlucky, the ad will replace the entire page.

What I needed to do is to capture the output sent to document.write and then insert the HTML dynamically. It turns out that JavaScript makes this easy. We can simply override document.write with our own function. Like so:

var addiv = document.getElementById("addiv"); //where the ad is  to appear
var adHtml = ”;
var oldWrite = document.write;
document.write = function(str)
{
    adHtml += str;
}
<script type="text/javascript"
  src="http://some/remote/script.js">
</script>
document.write = oldWrite;
addiv.innerHTML = adHtml;

This is brilliant, and in fact works perfectly for some of my ad scripts. Unfortunately it does not work for the slowest performer. The problem is that I have no control over the content of the remote script. In the non-working case, the remote script does not return HTML. It returns another script, which references another remote script. Now I have to figure out how to handle all the possible cases where scripts return scripts, which might or might not call document.write.

I’d be interested if anyone has a generic solution. There is a library here that looks like it might be helpful.

Another reflection is that it is in the interests both of advertisers and publishers to have scripts that execute fast and/or behave in a predictable manner that is friendly towards deferred loading techniques. It is no use writing convoluted code to deal with a particular script, when it might change at any time and break the site.

Why programmers should study Microsoft’s random failure and not trust Google search

The bizarre story of the EU-mandated Windows browser choice screen took an unexpected twist recently when it was noticed that the order of the browsers was not truly random.

image

IBM’s Rob Weir was not the first to spot the problem, but did a great job in writing it up, both when initially observed and after it was fixed by Microsoft.

It was an algorithm error, a piece of code that did not return the results the programmer intended.

Unless Microsoft chooses to tell us, there is no way to tell how the error happened. However, as Weir and others observe, it may be significant that a Google search for something like Javascript random sort immediately gets you sample code that has the same error. Further, the error is not immediately obvious, making it particularly dangerous.

I am sure I am not the only person to turn to Google when confronted with some programming task that requires some research. In general, it is a great resource; and Google’s own algorithms help a little with filtering the results so that sites with better reputation or more inbound links come higher in the results.

Still, what this case illustrates – though accepting again that we do not know how the error occurred in this instance – is that pasting code from a Google search into your project without fully understanding and testing it does not always work. Subtle bugs like this one, which may go unnoticed for a long time, can have severe consequences. Randomisation is used in security code, for example.

As an aside, there also seems to be some randomness in the appearance of the browser choice screen. It turned up on my laptop, but not on my desktop, although both have IE as the default.

And who would have guessed that the EU would arrange for so many of us to get an ad for something like the GreenBrowser popping up on our desktop? Apparently it is the “best choice of flexible and powerful green web browser”, though since it is based on IE it is less radical a choice than it first seems.

image

Palm Ares: an online IDE for WebOS development

I spent a few minutes trying out Ares, Palm’s web-based IDE for WebOS, the OS used in the Palm Pre smartphone.

Ares is in public beta and I’m not going to pretend I found it smooth going. No doubt it will be fine after a little patient learning. It is amazing, with drag-and-drop visual interface builder, code editor, source code management, debugger, and logging.  Microsoft’s Internet Explorer is not supported in any version; you need Mozilla Firefox 3.5 or higher, Apple Safari 4.0 or higher, or Google Chrome 3 or higher.

image

The online IDE uses a bit of Java but seems to be mostly HTML and Javascript. If you try to launch the application, you need a Palm emulator running locally, but you can preview in a browser without any local dependencies.

In order to try Ares, you have to sign up for Palm Developer Center. As part of the process, it appears that you have to give Palm permission to charge fees to your PayPal account, which I disliked, though membership is free for the time being. Of course you hope that any fees will be more than offset by the steady chink-chink of income from your app sales.

Is this the future? My immediate reaction was to be very impressed; a little further in and I was greatly missing the comfort of Eclipse.

Still, this stuff will get better; and the idea of just browsing to an URL to continue development is compelling.

Technology trends: Silverlight, Flex little use says Thoughtworks as it Goes Google

Today Martin Fowler at Thoughtworks tweeted a link to the just-published Thoughtworks Technology Radar [pdf] paper, which aims to “help decision makers understand emerging technologies and trends that affect the market today”.

It is a good read, as you would expect from Thoughtworks, a software development company with a bias towards Agile methodology and a formidable reputation.

The authors divide technology into four segments, from Hold – which means steer clear for the time being – to Adopt, ready for prime time. In between are Assess and Trial.

I was interested to see that Thoughtworks is ready to stop supporting IE6 and that ASP.NET MVC is regarded as ready to use now. So is Apple iPhone as a client platform, with Android not far behind (Trial).

Thoughtworks is also now contemplating Java language end of life (Assess), but remains enthusiastic about the JVM as a platform (Adopt), and about Javascript as a first class language (also Adopt). C# 4.0 wins praise for its new dynamic features and pace of development in general.

Losers? I was struck by how cool Thoughtworks is towards Rich Internet Applications (Adobe Flash and Microsoft Silverlight):

Our position on Rich Internet Applications has changed over the past year. Experience has shown that platforms such as Silverlight, Flex and JavaFX may be useful for rich visualizations of data but provide few benefits over simpler web applications.

The team has even less interest in Microsoft’s Internet Explorer – even IE8 is a concern with regard to web standards – whereas Firefox lies at the heart of the Adopt bullet.

In the tools area, Thoughtworks is moving away from Subversion and towards distributed version control systems (Git, Mercurial).

Finally, Thoughtworks is Going Google:

At the start of October, ThoughtWorks became a customer of Google Apps. Although we have heard a wide range of opinions about the user experience offered by Google Mail, Calendar and Documents, the general consensus is that our largely consultant workforce is happy with the move. The next step that we as a company are looking to embrace is Google as a corporate platform beyond the standard Google Apps; in particular we are evaluating the use of Google App Engine for a number of internal systems initiatives.

A thought-provoking paper which makes more sense to me than the innumerable Gartner Magic Quadrants; I’d encourage you to read the whole paper (only 8 pages) and not to be content with my highlights.

Future of Web Apps cheers the independent Web

The Future of Web Applications conference in London is always a thought-provoking event, thanks to its diversity, independence and character. That said, it is a frustrating creature at times. The frustration on day 1 was the barely functional wi-fi, which ruined a promising interactive application called HelloApp, built with ASP.NET MVC. HelloApp would have told us who we were sitting next to, what their interests were, their twitter ID and so on. Microsoft must be disappointed since the developers, some of them more used to technologies like PHP and Ruby, said how impressed they were with the framework and Visual Studio. The poor connectivity was a shame, and a bad slip-up for a web application conference. Even the speakers had to work mostly offline – cloud devotees beware.

Ryan Carson at the Future of Web Apps London, 2009

FOWA has been at London Excel recently, but this event was back to its earlier venue of Kensington Town Hall, more crowded but a better atmosphere and easier to get to. I suspect a little downsizing, but much prefer it. Organizer Ryan Carson has his heart set on enabling start-ups, proffering business advice and uniting developers, designers and money folk, though many attendees are not in the start-up category at all. When revealing the results of a survey showing that many web app hopefuls had less then 1000 site visitors a month he shook his head despairingly “you’re never gonna build a business on that kind of traffic”.

Carson has excellent contacts and the day kicked off with Digg’s Kevin Rose on how to get those visitor numbers up – he should know if anyone does. Rose exceeded my expectations with tips on massaging your visitor egos, avoiding analysis paralysis, hanging round event parties to meet influencers even when you can’t afford to attend the event, and even how to hack the press.

After that the day was disappointingly low-key, at least until midday. Then we got Francisco Tolmasky from 280 North and it all changed. Tolmasky’s line is that we should use pure web technology but with the richness of desktop applications, and to enable this he’s put forward cappuccino, a JavaScript framework inspired by Apple’s Objective C and Cocoa – Cappuccino uses Objective-J. This now has a visual development tool (web-based of course) called Atlas, and in Tolmasky’s demo it looked superb. See here for more details.

The surprising twist is that after developers told Tolmasky that they (or their companies) were not willing to trust code to the web, 280 North came up with a desktop version of Atlas with the added ability to create desktop applications as well. I am not clear about all the runtime details, though it no doubt involves webkit, but Tolmasky’s differentiator versus alternatives like Java or Adobe AIR is that Atlas uses only web APIs.

We heard a lot at FOWA about social media, how to use it for marketing, and how to integrate it into applications. Cat Lee from Facebook gave us a breathless presentation on how simple it is to hook into Facebook Connect. It was OK but it was a sales pitch, and that never goes down well at FOWA. 

The later afternoon sessions were excellent. Bruce Lawson of Opera gave us an entertaining overview of how HTML 5 would make life easier for developers. There was nothing new here, but nevertheless a revealing moment. He showed some rich media working in HTML 5 and made the comment, jabbing at Adobe Flash and Microsoft Silverlight, that the web was too important to place control in the hands of any one vendor. A loud and spontaneous cheer went up.

This was echoed later when Aza Raskin of Mozilla gave us a browser-centric view of social media, suggesting that the browser could broker our “social graph” by integrating with multiple identity providers. Raskin’s line: social media is too important to be in the hands of any one vendor.

The Guardian’s Chris Thorpe gave a bold presentation about how the Guardian wants to embed itself in the web through its open platform. Like most print media, the Guardian has many challenges around its future business model (disclaimer: I write for the Guardian from time to time); but Thorpe’s presentation shows that his newspaper is coming up with an intelligent response, promoting interaction and building out into the wider web rather than erecting paywalls. Having said that, maybe the Guardian will try other business models too; it is a journey into the unknown.

Overall a day for social media and the open web, and a good antidote to the more vendor-centric conferences at which I often find myself. Next week, for example, it is the Flash-centric Adobe MAX; and having heard very little about Flash at FOWA that will make an interesting contrast.

Where next for Adobe ActionScript?

The Flash community is disturbing the quiet of August by beating up ActionScript, the language of Flash, Flex and AIR. ActionScript is based on JavaScript, and took huge strides in version 3.0, introduced with Flash Player 9. Just-in-time compilation greatly improved performance, while the core language got optional strong typing, namespaces, sealed classes, and other features that brought the language closer to Java or C#. Adobe was endeavouring to implement ECMAScript 4.0, which at the time was also meant to be the future standard for JavaScript in the browser, though ECMAScript has since gone in a different direction.

Nevertheless, a number of influential Flash developers are saying “not good enough”. Sascha Balkau has a good summary and lists some of the requested features, including method overloading, generics, threading, abstract classes, and enums. Nicolas Cannasse talks about the failure of ActionScript 3. Joa Ebert is unhappy with the community process and observes that Google’s V8 is faster than ActionScript which in his view is ridiculous. Jesse Warden also complains about performance and asks for the performance gains from the amazing Alchemy (which compiles C/C++ to ActionScript) to be available to all ActionScript code. Peter Elst asks for ActionScript to be decoupled from the player and replaced with a dynamic language runtime.

Why all the fuss? This is the pace of development in the industry putting pressure on Adobe. There are undoubtedly Flash developers casting envious glances at Silverlight’s .NET Framework, which meets many of the above requests – though let’s not forget the Silverlight developers casting envious glances at Flash in areas like text handling or simply its wider adoption – and the Google factor is also an interesting one.

Miguel de Icaza tweets mischievously about how Adobe should adopt Mono and get C#; and in many ways he’s right. Not that Adobe should necessarily adopt Mono; but that it should be using a language and virtual machine that is shared with a wider community – which I guess is what was intended for Tamarin, though that has not worked out well so far.

In the meantime, I’m guessing that Adobe will be coming up with improvements to meet at least some of these requests – multi-threading, surely, and the next stage in Alchemy. MAX 2009 in October?

Local SQL support in Safari vs Google Gears: what is happening?

Today I installed Safari 4.0, and one of the features which caught my eye is its local database support. No, it’s not new, but perhaps has not received the attention it deserves. The feature lets you use a local SQLite database from JavaScript, both online and offline, and works on the iPhone 2.0 and higher (2.1 for offline support) and in Safari 3.1 and higher. The API is rather simple. windows.openDatabase returns a database object, and you then work with methods like transaction.executeSql, reading the results in a callback function. Security restrictions mean that access to the database is restricted to pages served by the domain from which it was created. Apple has more information in its Safari Client-Side Storage and Offline Applications Programming Guide. Safari’s local database features implement the HTML 5 W3C Web Storage API.

It’s a great feature, and strengthens Safari on the iPhone as an application runtime that avoids the hassles of the App Store. Does it have wider value? A problem is inconsistent support across other browses. Microsoft’s IE8 supports DOM Storage (key-value pairs), which is also part of the HTML 5 standard, but not SQL. FireFox also supports DOM Storage, but its SQLite support is restricted to components and extensions only.

A possible reason for the lack of wider SQL support is that Google has its own implementation in Gears, which works in Safari and FireFox on the Mac, in IE and Firefox on Windows, and in Firefox on Linux. One place you cannot install Gears though is on the iPhone. A possible solution is to create a wrapper API that uses HTML 5 on Safari and Gears elsewhere; Malte Ubl has done some work on this, for example.

Personally I’d like to see the HTML 5.0 specification more widely supported, since along with the iPhone issue, not everyone wants to install Gears. I would have thought it could be added to both Chrome and FireFox relatively easily; but would be interested to know what is planned.

Technorati Tags: ,,,,

Visual Studio 2008 as a JavaScript editor

I’ve been doing some work on JavaScript editors recently, and was impressed by Microsoft’s Visual Studio in this respect. Here’s my post on the subject. By the way, even the free Express edition works fine for this; and you don’t need to use ASP.NET. You do need to use Internet Explorer of course; that’s another story.