diaries from a planet of automation

ASP .Net forms authentication with an Azure SQL Database

Azure is evolving very rapidly and Visual Studio tries to catch up. Every so often, things that were not-so-automatic in the cloud are being automated by Microsoft.

One nice feature that we’ve discovered makes web form applications in Azure easier if you want to use  authentication features in your site. Visual Studio creates the “User” database tables in Azure SQL without you having to create them yourself with the modified aspnet_regsql file (a technique no longer necessary but shown here:

This our test:

1. We create a SQL Azure instance (click on the image to enlarge it)


2. In Visual Studio for Web, we create a Web Forms Web Site


3. In the web.config file of the new site, we replace the connection string with Azure’s (you can get it from the Azure management portal):
<add name="DefaultConnection" providerName="System.Data.SqlClient" connectionString=",1433;Database=DB-for-users;User ID=yourid@our-euro-server;Password=your-Password;Trusted_Connection=False;Encrypt=True;Connection Timeout=30;"/>

4. We launch the web application

5. We click on “log in”


6. The database tables are created in Azure SQL database, and filled as your users register.


Have fun with Azure!

Adobe Flash Builder 4.7 has no Design View. Is it blasphemy? No, but the software contains some other blasphemous aspects…

At Alien Coding, today we finally upgraded our 4.6 to 4.7.

The new version of the once popular programming tool from Adobe installed easily and works decently.

As most Action Script programmers know, this version of Flash Builder has no “Design View”. This means that you can no more draw your UI by dropping and dragging UI elements on a “canvass”. Everything has to be done programmatically, via MXML code.

Apparently, this choice was mandated. Flash Builder has been donated to the Apache Foundation except for the Design view, which contains Flash Professional elements that remain proprietary. Adobe could not issue FB 4.7 with elements that the open-source version did not have.

As an explanation, however, it is somehow funny, because Flash Professional is suffering as well ever since Apple (and O’Reilly!) banned it from mobile; thus, depriving FlashBuilder of a feature because it’s proprietary of another agonizing technology does not seem very understandable.

This said, we are not sure that the elimination of Design View really changes the game of Flash Builder (IF you want to stick to action script rather than HTML5 and CSS and javascript; in the end: if you don’t want to go to PhoneGap). The idea of designing a completely flexible UI on a non-flexible canvass, all in all, did not work well.

I’ll try to explain what the issue with the Design View (at least for mobile) was.

When @AlienCoding we developed applications for Android and iOS, so that they be ready for all screens, we understood rather fast that, except for an early mock-up, the design view would not help us.

The elements were to be re-sized programmatically to account for the different screens. We designed on an 800×320 canvass, but we had to take into account that that screen could as well be 800×400 at run time. What was the UI to do? Adapt automatically. At that point, the canvass could not help anymore anymore, because the result of run-time re-sizing could only be seen in a simulator.

Yes, the canvas was good to make a first drawing of the interface, but you can still do it better with Illustrator or such programs.

This happens also in other IDEs to build applications where you don’t know what the screen size will be: who really counts on the Design Mode of Visual Studio for designing web applications?

It’s however a pity that, together with the Design View, they have taken away the nice property panel which allowed you to easily set all the different properties of a UI control.

Besides, there is one thing that – if not addressed – will kill Flash Builder. Other platforms (including Phonegap) address Windows 8 phones in addition to BlackBerry. In 4.7, even BlackBerry support has disappeared (some say they’re waiting for BB10… but what about the existing apps?).

This is particularly funny, because last week we were invited to an “AIR IS NOT DEAD Workshop” organized by Adobe Italy, which in the end did not take place (or it took place, and we did not receive any response from Adobe when we enrolled: you were supposed to know if you were in or if you were on a waiting list. We knew nothing).



The “AIR is not dead” workshop required you had a computer with 4.6 and a tablet. At the end of the day, you would participate to a lottery which could reward you with two RIM Playbooks. Now Adobe 4.7 does not support the playbook anymore. Is this why they cancelled the event, or did it but communicated nothing to the registered programmers? Whatever the reason, it easy on the border between very funny… and very sad.


Symbols of automation, worldwide


The people of AlienCoding have traveled a lot lately.

They have been to Southern Holland and to South of Italy. These places have absolutely nothing in common except that people show this wonderful need to automate. Both the Den Hague region and the Basilicata region were full of these fans that supposedly take automatic advantage of the wind to produce electricity.

Alien Coding loves automation. If a thing has to be done twice, we automate it here, as a philosophy.

The beautiful picture up here was taken by artist MyVisionAury, who has been the protagonist of a portfolio application for iOS and Android. You can download it here:

Download MyVisionAury on the App Store

Yep that URL!

Here's the link for Yep That URL is a service to shorten (or make longer) URLs.

It is fun because it is minimal but also ironic as automation can sometimes be.

We have gotten to know the founder of the service personally.

His name is E.P. and he’s as cool as his creature Yep.It.

How to find Yes, you nailed it! Go to is so kind as to offer public APIs for their services.

With the founder’s aid and abet, we’ve created an app for iPhone (3gs, 4, 4g, 5) that uses such APIs to create short URLs and… yes, share them via Facebook, Twitter, SMS, email. You can also copy the short URL in the clipboard and have at it.

A fun feat is the “Analyze” one: when you have your (customizable) Yep URL (as “”) then you can also have the numbers of clicks traced by the app (which calls the API). This is much easier than Google!

This is a screenshot:

This is a screenshot of the app of iPhone called "Yep that URL"

The new Apple badges are separated into Download from (on the web) and “available from” (on paper).

This is your download Yep that URL badge. Have fun!

Download Yep That URL on tha App Store

Pushing buttons on the iPad mini

We are very eager to see the iPad mini and how non-designed-by-Apple apps look like in it. We have had a lot of iPads here and we thought that all of them had a problem… they were too big!

“Every inch an iPad” is a very interesting motto, in view of the fact that all iPad apps will run on the mini. This was of course expected, as the new screen has the same resolution of the non-retina iPad (1024×768).

However, the buttons in the apps will be smaller and more difficult to press if the programmers did not have in mind, when they sized them, the inches, rather than the pixels or the points.

For example?

A 50 pixel fixed-width button will be still 50  pixels in the iPad mini. Except that 50 pixels in the iPad mini will be smaller by about 1/3.

When we size buttons, we @AlienCoding don’t think in pixels or points. We think in inches needed by the UI element divided by the number of pixels per point of the device, even if the device seems so irreplaceable. So: a button is never “49 points” or “one tenth of the screen”. It is: “half an inch, whatever the screen size.”

We hope this pays out as more iPad minis (as well as super iPads!) come out of the oven…

Back to a dark non-standard Javascript future

It’s been a long time since we@AlienCoding have been jumping from Javascript platform to Javascript platform to understand what we can use to develop something that can work:

  1. on mobile browsers
  2. on desktop browsers
  3. as a native app [via tools like PhoneGap]
  4. with a decent IDE

I this asking too much? well, if it weren’t for Apple’s (and Adobe’s) policies on point (1), Flash would fit the bill already, wouldn’t it?

We understood very soon  that JScript technologies don’t come with a predefined IDE,  and one must find and IDE for themselves.

The simplest choice for the technology seemed to be the JQuery mobile library. Compared to Sencha, it seemed to have the following advantages:

  1. lightweight
  2. more standard (leverages HTML more than Sencha does. Sencha relies a lot on Jscript and seems less readable)

We downloaded a couple of IDEs.

  1. Aptana and
  2. Webstorm

seemed the most promising ones. The first is free (but incredibly slow), the second almost free (30 days’ trial and very cheap license) but doesn’t feel bad under your fingers.

We created a first jquery mobile application with Webstorm  to understand that…

JQuery mobile does not work at all on IE7 and – surprise – has a  bug in Chrome (or should I say feature) which prevents local HTML to be loaded via Ajax when you divide your application into different files (which is something you may want to do pretty often).

Here are a couple of links: <— the IE problem <— the Chrome problem

This bad bad start convinced us to try Sencha. But there are a couple of things which stopped us from Sencha as well:

  1. From the very start, Sencha market themselves as “non supporting non-modern web browsers” (they use a grinning IE icon to show what they do not support)
  2. The Sencha Architect IDE costs, for ONE developer, from 399 to almost 1,000 dollars.

We are astonished. We looked into Telerik’s Kendo UI suite, but costs are crazy there too, and there is no example of a native app created with Kendo and PhoneGap.

We think this is a ludicrous situation. We are steering towards HTML5 technology for broader support of what we do… and what do we discover? That these technologies are supported by half of the use cases.

We there is space so that a big player comes in and steals the market. What is needed is:

- an IDE that supports HTML5 and JScript

- creates apps out of the same code, without the need for XCode or the Android SDK

Adobe has good candidates.

Can this be Dreamweaver? Can this be Edge? Can this be Flash with CreateJS support? Or will some-one take advantage of this fragmented situation and shoot the silver bullet?

What is certain is that – as regards AlienCoding – it still isn’t any of the non-compatible technologies that, oddly enough, are becoming famous because they are

- hem -


Let the servers do the talking

Having used computers for a long long time, we at Alien Coding have seen the client going from fat to thin to fat again.

It is very nice that with fat clients can help servers use their full computational power but… Is it worth the extra-development?

Fat client applications have these problems:

There isn’t actually a fat client. There are browsers. There are Operating Systems. And not one will work like the others (this is one of the reasons while the Google Play market is not taking off).

Even in “controlled” environments, you are never sure how the “fat” browser will react. The first issue is, however, who controls the “controlled” environments? Unless you are the system admin and the programmer, you have no particular control (or even knowedge) over:

  1. proxy servers the users are working with, and their configurations
  2. browser type (in large companies, some have IE7, some have IE8, some “privileged” are testing IE9)
  3. security settings of the client machine (can everybody accept self-made certificates? can they all accept JavaScript?

That’s why the “corporate==easier” environment is pretty much a myth and most of the times doesn’t save you from the inconsistent “fat” client.

To be on the safe side, we@Aliencoding think that the client should be thin even in corporate development. Then one can concentrate on how to allow the server to work for everybody who has a minimal HTML interface. (let’s all break a leg with HTML5 then…)

Book Review: Mobile JavaScript Application Development (O’Reilly – Adrian Kosmaczewki)

There was a time in which O’Reilly’s books were Bibles in their fields.

Not because they were particularly influential: because they took 900 pages to convince you of one single statement: do like this and you’ll be saved. We remember our first O’Reilly book: the Javascript definitive guide. We were back in the old millenium. The 1000 pages of Flanagan’s book were already today.

Then came the blogs, and O’Reilly took the worst of blogs and – from Bibles of their fields – some of O’Reilly books became the print-outs of blog aggregators, pardon our bluntness.

Why? We don’t know. We still like O’Reilly, the man. We can’t even say that he’s lost his touch: maybe he’s selling now more than ever. Their videos can be cool. The ones by Luke Wroblewski about “Mobile Design First” are amazing. But some of the laters books we’ve bought…

This book by Kosmaczeski started with good intentions. One was that it cost $24,99, which is a little more than the average blog post collection. So one was expecting a little quality. And quantity.

Second of all, this book has just been published (June 2012). So, it should take advantage of some kind of stability that the world of mobile development is supposed to be reaching. The references to the Jscript library versions are updated! JQuery: jquery-1.7.2.min.js (hurrray). JQuery Mobile: (hurray)

However, this book is totally useless if you know how to read a blog and gives no insight that can’t be had by delving just a little into anybody’s told experience on the web.

It starts showing what HTML5 is. For ten pages or so.  CSS3 is just mentioned. Even Dreamweaver books explain html5 and css3 to a deeper level of detail.

Then you go to JQueryMobile. There is a whole project you can build. It’s a pity the author does not tell you where the snippets of code should go, and why. The reason? You have only twenty pages to fill, come on!

Then 26 pages are dedicated to Sencha Touch. A good 31 to PhoneGap. Last, 16 to debugging.

I understand it was our mistake to think a short book could give good insight into such a big realm.

But then again: why issue it and not ping back some blog entries which have more insightful content?

We know books have a hard time in an era in which everybody is entitled to write their experience, opinions and what-have-you, online. But the solution to the book crisis is not publishing (as an ebook!) something that is too-high-level, seemingly inexperienced, mortifyingly deprived of future referentiality. All in all: similar to the blogs which are de facto killing technical books.

Some Peculiarities of the Sandbox Concept in Web Environments

Some days ago I built a web application to create portal users in
One might wonder: why? SFDC is already a web application.Well, the reason was that I wanted my users to share a “delegated” account which had higher privileges than the average user’s.

I’m not entirely sure this complies with licensing paradigms of SFDC, but I would happily skip these considerations because portal users can self-register, I don’t think I’m stealing license power to anybody. 

Two choices presented to me:

- JQuery

- the Salesforce connector for Flash

I went through the JQuery classes (are they really classes?) for SFDC documentation, but had to discard the idea of using JQuery because the first step was: build a php proxy to connect to SFDC via server. Really? This is how the client authentication problem should be solved? Gosh, if I had a php server I could deploy to, in an enterprise environment, why wouldn’t I use php pages?

Then I looked up the Flash/Flex documentation, Everything was smooth until I had faced the ominous…

Cross-domain sandbox client issue

 What does it mean? When you download a page from server, your client calls (web services, http services, etc.) must all address server

If they address or or even, not to mention (not secure)

then you’re screwed and the player won’t even TRY to call your service. You will get a “URL Security Error”. 

The reason? Flash (since version 10, I’m told) is afraid someone’s driving you to a destination you don’t want to go to. If you’re in, it thinks, all your data connections should be done with (which is why you’re suggested in forums that you build yourself a proxy, as JQuery developers would want you to do.)

Does this security model make sense?

Of course, not.

Of course, you must allow applications to retrieve data from servers that are different from yours. So, developers have a workaround to allow applications to tdo this. To do this, you just develop your.swf with a “Security.loadPolicyFile” instruction which points to a “crossdomain.xml” file on the third-party server. This crossdomain file tells what kind of flash domains can access its APIs. 

So, how would an-ill intentioned guy hack you into retrieving data to a server you don’t know you’re going to?

1. deploy a crossdomain.xml file in a server of their own

2. reference the crossdomain.xml file in the “secure” file you’re using in your browser from

3. done… you’re hacked to

So I wonder: this security model would make sense if these crossdomain.xml files were certificates issues by some companies, not if they are text files created by the next guy!

All in all: the Flash Player sandbox 9 to 10 “securization” is apparently a farce. Crossdomain.xml files are needed in servers to decide who can use their services. But binding client security to a third server’s security policy is – if I’m not missing something HUUUgge here – very very peculiar…

Is it Really Still: the Apps?

Apparently, people are talking a little less about them but…

for the last two years, it appeared that any new project for mobile should be developed like a native app.  I’d say: “Enough!”

We don’t want to sound like those boring pundits who think they know what will happen in five years, but this trend cannot go on forever and mobile content will sooner or later verge to – again – the web, or: mobile sites, with offline capabilities.

Why do we think that?

1. App Markets are not searchable satisfactorily

2. No App Market can  grow indefinitely

More in detail:

App markets do not have infinite capabilites. Both Apple’s and Google’s (I don’t know Amazon’s well enough) are growing nonsensically. If apps could be browsed like web pages, which they can’t by definition, then it would make sense that one could choose among so many of them. Since apps cannot be browsed and the room for them cannot be infinite, how does:

  • one decide what app one’s interested in
  • Apple / Google decide what apps are interesting for users?

As for the second question, Google has solved it in this sense: unless you are violating some copyright, you can publish whatever you want, no “review process” asked. Now, this looks like a very democratic thing. It’s a pity Google Play (formerly: Android Market) is 1/10 profitable for developers as Apple’s Store. Partly, right because of this “democratic” policy.

Apple is solving the “quality versus quantity” issue by rejecting more and more apps on the grounds that they “add little value to the user” or “are a web site disguised as an app”. This latter category of app rejection is particularly dangerous to define, because it might as well encompass – say – Facebook’s app, which cannot be used offline and is a simple variation of the very nice iPhone / iPad – optimized site they have (I am often undecided whether I should use the app or the mobile site).

So, we have a market (Google’s) which accepts everything, but is as scattered as the numerous types of devices it serves, and a market (Apple’s) which is trying to be high-quality in a world where everyone’s a programmer.

Google’s saying: “we’re publishing everything, so you’ll eventually find what you’re looking for and award it”, while Apple’s saying “we’re awarding only good stuff, so you’ll find ONLY what you’re looking for.” The first approach is doomed because it may take too long for someone to find the functionality they’re looking for, and eventually people will stop searching; the second approach is doomed because there will be a moment in which Apple will accept only a few selected new apps because – well – they have everything. Who will develop, then?

On the other hand, a sunny day will come in which web technologies don’t seem like an adolescent’s dream anymore.

The same congregation of people who  invented HTML, some day,  will finally be able to define HTML5, won’t they? And they will be able to store content on every device, won’t they? And they will able to have you access selected pages offline, won’t they?  And the HTML5 + JScript combination will be performing so simple games will work in a browser, won’t it?

When that saint day comes, the number of new apps will decrease. Developers will start proposing their bosses they make a proficient HTML application rather than a native app. Application market owners will start to feel that they don’t need to keep so many apps in their roster… 90% of them are non-profitable, everyone knows.

It might as well be that apps will only be: games which need particular performances… or: enterprise applications… but… for instance… bank apps? why bank apps, if the mobile web can be as good?

…can it?


Get every new post delivered to your Inbox.