diaries from a planet of automation

Review of “RESTful Services with ASP.NET Web API” (Fanie Reynders, Packt Publishing)

There is a saying by Thales from Milet which goes “If I make, I learn”.

It has been a while that at Aliencoding we’ve preferred videos to books, when it comes to education.

We do read books, but the tendency has lately been that of watching “live” courses rather than using manuals.

With videos, you don’t actually make (unless you reproduce everything on your machine) but at least you see what’s being done. This is why the saying by Thales is at least partially respected.

This video by Fanie Reynders is a very good overview of the new generation of web services, that is web API’s, in a .net context.

Our attitude towards Web API has been ambivalent: on the one side, we do see the advantages of the smaller network payload; on the other hand we still think that WCF make everything really simpler.

Fanie Reynders knows his stuff. He has a peculiar and funny (in a good way) South African accent which keeps you always alert.

This video is not very long (a couple of hours) but it is not only an introductory training. It starts simple, then goes into more interesting and complicated stuff as OData Filters.

The only part of the course which we didn’t like pertains the fact that Mr. Reynders uses a lot of console apps to test Web APIs. This is not something we appreciated because:

  • client side: a lot of web developers only have visual studio for web, with no console application possibilities
  • server side: hardly will you ever work with a company which allows you to develop a server as a console application…

Apart from this glitch, a good video which helps you understand this promising technology.

This is a link to the eBook (Aliencoding is not affiliated with Packt: if you buy it, there is no compensation for Aliencoding)

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…


Get every new post delivered to your Inbox.