Original post blogged on b2evolution.

The purchase of Instagram is no less than an attempt to redefine the landscape of our industry, today, you are either an app, a service or a platform. For instance, RIM will become an "app". No disrespect, it can be a formidable app, opening the doors to the Enterprise to an Apple or a Google, but the window of opportunity for RIM to be a platform is gone. In this new world, search is an app, actually the feature of an app which sets the search context (yelp, UrbanSpoon...), ads is a service and the old WWW amounts to the Yellow Pages (paper HTML edition). Content is now produced, delivered and accessed in a completely different way, e.g. Instagram: we have entered the social:// era and left http:// behind. The circle is the new DNS.

... and maybe (always smiling) Amazon. The problem with Amazon is that they'll have to chose between being a commerce platform (and compete with WalMart) or an industry platform and play with the big boyz. I don't think these two things work well together and eventually Amazon will return to its commerce roots mainly because of the lack of social capability. Amazon is a formidable company, but they are too late to the  game, with no money in the bank to acquire what they need to compete. As (Microsoft), Google and Apple know, there are only so many social networks that can fuel a healthy platform. Most likely Amazon will become a substrate to support services with AWS, and of course, an "app", the kindle, assuming the platform guys leave these holes open (far from a given).

Yet, Amazon was a decisive factor in establishing the architecture of the platform. It reinforced the power of the vertical integration pioneered by Apple. If you come with a great device or set of devices, and an app store, customers will come. Something that Google is still struggling to emulate with an open ecosystem, and I am not even talking about Microsoft.

If the social integration is pretty much a given, the game gets really interesting when it comes to the vertical integration. As we have seen with Apple, customers don't see "choice" (or price) as a competitive advantage. Customers want simple product lines, that offer great consumer oriented products, with clear and real innovation at each cycle, built by thoughtful product teams: selling incremental junk is no longer an option. And yes, TV or Game consoles will be engulfed in the platform. How could the platform guys leave them on the table? Any consumer device that can run an app will be vertically integrated in the platform (or replaced by one).

My best guess is that:

- MS/FB will partner strongly with or even purchase Nokia and HP.
- Google/Motorola will swallow HTC and/or LG, possibly bring Dell in its ecosystem
- Apple ... huh ... will buy Twitter, and RIM for its Enterprise App

Samsung could team up with Amazon, but most likely it will become the component provider of the platform guys. SONY's or Nintendo's trouble simply show that there is no more room for independent Hardware Vendors: you are either a (vertically integrated) platform or you supply the platform with components, not even devices. It is essential to understand that the touch points to consumers is going to be completely locked down by the platform.

Even Telco providers will be suppliers to the platform guys, with the Skype/Hangout/Facetime apps being the new face of telephony.

The interesting thing here is that unless social networks are just a fad, MS/FB is the most likely winner of that game. Even Ballmer could pull that off and retire on a -real - visionary success. There is a large probability that MS/FB/NOK/HP will take on 80% of a vertically integrated, consumer oriented market. Google will lose that game (this is not an engineers game, let alone using corny "Web" paradigms and UX, in any case they will take the decision to move to a vertically integrated model too late without any muscle behind it). Apple will take on a 20% "think different" crowd. Apple is not aggressive enough to win that game, they'll look back to their $100 B in the bank and ask themselves, if they could have used it more "wisely".

Facebook spent a billion, not to buy Instagram but to hold our industry by the balls. With its IPO behind, it will call the shots for years. And yes ... Zuckerberg is next CEO of "The Platform".

Fascinating times ... it's a shame that Steve is no longer with us.

Original post blogged on b2evolution.

Interface Builder is one of the most amazing software ever written. After 25 years (and hardly anything added to it), it is still relevant and still a GUI designer far ahead of the competion. Just let me know if you know any other piece of software that was designed 25 years ago and is still relevant today, pretty much unchanged.

When I discovered IB in 1990, I was in owe. Not only could you build incredible GUIs effortlessly (at least for the time), but IB was also an Injection Dependency Framework more than a decade ahead of Spring. It forever set the tone of my career, anchoring it in the model-driven world, building software that builts software.

That being said, I built Canappi to address a number of shortcomings which would be expected since IB was never designed to build mobile solutions and to a large extend it shows.

1. Canappi's mdsl describes the entire application in a single file: XIB files have all kinds of granularity and are generally loaded individually at different locations, directly from the code. It makes it quite dificult to have a comprehensive view of the application.

2. Canappi introduces the concept of Layout, as a set of controls, which can be reused across different views: IB does not allow you to reuse groups of controls easily, this has to be dealt in code, not at the view definition time.

3. Canappi offers standard actions (call a number, send an email, navigate to a view, present/dismiss a view...): IB doesn't have any notion of standard actions, in particular navigation actions, so you have to go back in code to implement things that could be easily dealt with at the model level, in the GUI definition

4. Canappi has introduced the concept of stylesheets: IB does not have a simple way to reuse a set of properties across the definition of several controls (TextField, Label, Button...)

5. Canappi's programming model include Web API definitions which can be bound to layout and actions: How many mobile apps need to talk to some kind of Web API? Unfortunately IB, which was build 25 years ago, knows nothing about them. With Canappi you can create a client view of a Web API (Connection), and bind operations to individual layouts, including tables and actions. Canappi generates the code to assemble the Web API request, parse the response (XML or JSON) and bind it to the controls of a View.

6. Canappi's can easily specify the layout of a table: When you drag and drop a table in a XIB file, you get, a table. You have no way to declaratively define what the table row is made of.

7. Canappi defines the whole wiring of an application, from Splash screen to Menu to every aspect of Navigation (navigation bar, navigation actions, dialogs...): Apple recently added Storyboards, but that mechanism doesn't scale very well if you application is more than a few views.

8. Canappi makes the process of designing Universal Binary easy, you can define both the iPhone and iPad layouts. Each layout is independent of each other which allows you to define different navigation schemes as well (of course the remainder of the definitions are shared between the two: connections, styles, ...): IB knows nothing about different form factors running the same application. Again, 25 years ago, this was not a common usage pattern.

9. Canappi has a much richer palette of controls: Graph (Core-Plot), Gallery, RadioButtons (yes IB doesn't have radio buttons for iOS), Button Triggered Pickers and Date Pickers, Video Player, ...

10. With Canappi you can use Interface Builder to create Android layouts. We convert Interface Builder files into mdsl, which can be used to generate both iOS and Android applications.

Canappi's mdsl is also a textual language which you can easily version, compare and merge, even create libraries of resuable application definition. IB on the other hand is a graphical tool which is ideal to position controls on a view, but far less than ideal to manage an entire application.

In fact, mdsl, Canappi's programming model, is so complete today that you can now write entire applications from it, something that is impossible to do with Interface Builder. This app was built with 700 lines of mdsl and less than 50 lines of custom code.

Original post blogged on b2evolution.

No, I am not going to leave my iPhone or iPad alone for some months or scale down on using them. I am really talking about food diets. A completely different topic. As most people probably guessed by now, I am a gadget junky. I don't buy big toys (like cars), but occasionally, I like to have the latest gadget, just because it's cool. So I invested last June in a Withings scale. This is a beautiful equipment, easy to set up and completely seamless to operate for the whole family. You step on the scale and it wirelessly sends you data to their server. You can diplay graphs and data on your favorite mobile phone or tablet.

Last November I reached 240 pounds (109 Kg). I never weighted as much before and when I saw the video of a talk I gave at l'Ecole des Mines de Nantes, I felt it was time to do something. But What ? yes eat less / better, exercise, ...

I have lost lots of weight twice in my life: by exercising for a whole summer and after I got maried when my wife cooked specials low cal meals. Today with two kids, jobs, and other stuff going on, we tried, but neither were really an option. Sure there are millions of diets out there and nothing I could do really worked.

I even bought a fitbit to understand how much more I would have to exercise.  I would not recommend anyone buying this device, this is the most expensive useless gadget I ever bought ($99). It is basically a glorified pedometer and nothing more.

So since the end of November, in about 3 months, I lost 22 pounds (10 kg), but what's most important is that the withings scale taught me how to eat and ultimately how to control my weight. So basically I dropped calories from my meals until my weight started going south. I lost all this weight without going to the gym or starving. As you can see in the graph below, when I got the scale in June, I somehow eat a bit less, but my weight crawled up until November without really understanding why. I was fighting it, but without much success.

So here is my diet (I am sure you can find yours):

• I eat the same thing at Breakfast and Lunch everyday:
  
  • An 8 grain roll and a coffee at Starbucks and a Honey Oat Veggy sandwich at Subway.
  • When I get home around five I eat a fruit or a yogurt.
  • I eat whatever on the table (but small portions) with the family in the evening.
  • If I can also do a veggy sandwich in the evening I do it (in case we are out running errands).
• Weigh yourself everyday, my weight curve was a huge motivator
• Walk a bit more here and there

I never felt hungry the whole time.

That's it, nothing else, nothing more. No need to buy a book or tapes, cook special meals, kill yourself at the gym, weight anything. Each time I did a "real meal" you can see a step in the curve. This is when we had friends at home or we went out.

Yes, and my blood pressure went down too. I am still heavy (99 Kg) so I expected it will drop more on my way to 80 Kg.

So what I learned?

• Eating out is bad, really bad for your health. We used to eat out at least twice a week, not to mention lunch. I am sorry to say that to the millions of restaurant and fast food owner, but what is convenient and fun is basically a silent killer.
  
  • SCHOOLS MUST ABSOLUTELY OFFER A LOW CAL ALTERNATIVE TO BREAKFAST AND LUNCH
• It is amazing to see how few resources the human body can use to run all day
  • I can't imagine how much food is wasted each day for absolutely no reason
• Salt does bring your blood pressure up
• I know today how to control my weight for life. This is priceless.

Yes, my energy levels are very high, I feel really good and every morning I can't "weight" to jump on the scale.

I hope you'll find that helpful.

Just in case you wonder, I am the biggest loser in the family and I am trying to convince my kids and wife to do the same thing.

Subbu wrote a post earlier this month on the Architect role, here he goes:

• You always talk about the big picture.
• You think you know how the system ought to be built.
• You are unhappy that the team is not executing your ideas the way you want them.
• You don’t have a working build.
• You spend a lot of time on documents that are not code.
• You can prototype – but your code is not production worthy.
• You spend too much time in meetings.
• The best code you wrote is a few years old.
• When asked for opinions you tend to speak in general terms.
• Your team members secretly joke about you.
• You start to take analysts and tech blogs too seriously.
• You are a dinosaur.

It's hard to disagree, though I find the list widely incomplete, specially when it comes to "everyone but your mum has an opinion on what the architecture should be", "vendors tell your boss you suck at archicture (unless you buy their product)"...

I am a bit more at odds with his conclusion: Code. Don’t wiki. Don’t powerpoint.

To code or not to code, that seems to be the question: in our industry these days, you code, therefore you are.

Just take any interview with Microsoft, Amazon, Facebook, Google ... and you'll face insipid Comp Sci 101 questions such as: how do you compare two binary trees? So, you bring 25 years of experience and passion, and the best and first thing these companies can do is to have a 25 year old kid ask you to write 5 lines of code. Everything else you have done is irrelevant. That is Subbu's world.

Allow me to take a real example to illustrate how a "coder" architects. A few years ago I was invited at Microsoft for a pubic event, and in a rare insight, a Microsoft architect was proudly explaining why Windows 2003 (R1 if I recall correctly) did not scale as a web server? The developer in charge of the connection manager had used a  ... linked list to manage the connections. I bet this guy had brilliantly passed all the interview CS 101 questions ... Shall we also speak about the kids at Facebook who code your privacy away? Isn't a primary key a convenient way to fetch your favorite piece of information?

The reality, is that Subbu makes the deeply and totally erroneous assumption that we have reached a level of maturity that gives us the perfect communication tools and hence with that in mind of course, writing code shall be the answer.

If you think that a) communicating, b) how and c) when you communicate is irrelevant, I would strongly suggest you watch this presentation from start to finish. Don't get me wrong, coding is great, I love coding, specially metaprogramming, but the question still remains, is an architect, JUST-A developer, hence Archaic, or is his or her role more essential (as in essence), i.e an Archetype ?

Why not think out of the box slide for once? beyond the trees, and the queues, the arrays and the lists, the maps and the sets? Why not ask how Model Driven Engineering could shape the role of an architect and establish a strong and precise articulation between architecture and coding? and with it, enable architecture refactoring ...

Let's review Subbu's list in the light of MDE:

Shall I also mention that the ultimate beauty of MDE is "No Middleware"?

So, for a RESTafarian, who recently admitted:

Hypertext made a lot of sense when I was looking from the server. A few months spent writing real-world client code changed all that.

I am not really sure that Subbu is in the position to teach us some lessons about what to do, or not to do. Very few "Coders" seek to understand the context in which they code, or poke up to the solution model, and I am not even talking about the problem model. So yes I am disappointed, but not surprised to see someone the caliber of Subbu, thinking that we have to return to the early sources (so to speak) of software engineering. The RESTafarians have already thrown us back 15 years, what's another 15 years on top of that?

It's time to let the Architect surface the Arche (In ancient Greek Philosophy, Aristotle foregrounded the meaning of arche as the element or principle of a thing, which although undemonstrable and intangible in itself, provides the conditions of the possibility of that thing.)

I must admit, MDE is a joy to work with, especially as an architect. MDE allows you to express how a certain class of solutions should be built, far away from the intricacies of general purpose languages, conventional type systems and SDKs. It allows you to solve problems, in ways that simply would never have any room in a GPL world. I may never know if MDE would have changed the face of software engineering, but for an industry that has looked for the holy grail of programming languages for so long, a paradigm shift seems innevitable. If for nothing else, all our software development technologies and processes have been aligned along a "monolithic" assumption, when today solutions are composite and often requires several architecture variants to support to different use cases.

Let me take 3 examples from the Canappi 1.2 release. to show where and how MDE makes a powerful difference.

1) MDE enables solution architecture variants : one of the key features of 1.2 is an enhanced level of support for Universal Binary iPad/iPhone applications. You can now define device specific layouts which will be displayed when the application runs on that type of device. The kitchensink demo has been updated to take advantage of that feature. Here Canappi uses tablet variants, but it would be just as easy to add it for different orientations.

layout sessionDetailLayout_iPad {
    // iPad specific layout

}

layout sessionDetailLayout {
	text  sessionId	'' (-20,-20, 10,20) //hidden parameter
	text  sessionTitle '' (7, 45, 305, 65) { Left ; }
	text  sessionPresenter '' (7, 110,290, 20) { Left ; }
	
	tablet sessionDetailLayout_iPad ;
}

There is simply no other mechanism that allows you to do that so elegantly because you are constrained by the underlying architecture of the  SDK you are building your solution onto. When you look at Apple and Android SDKs, you can clearly see that the support for different form factors simultaneously is an "after-thought", not a key architectural foundation.

Furthermore, any architectural deviation from a given SDK translates into lots of boiler plate code, scattered across the entire solution's code base. MDE completely hides this boiler plate code from the solution model.

2) MDE enables the creation/addition of new logic semantics. Mobile apps often need to call more than one API to get the data you need to populate a user interface. For instance, when you need to display the thumbnails of a Flickr gallery, you would think Yahoo's Web API GET /gallery/{id} would return all you need? wrong, it only returns some gallery information with just the photo ids, you need then to make a second call for each photo_id to get the thumbnail URLs to download the thumbnail image files.

So in this case, not only do you need a solution architecture variant (call 2-N APIs given a call to a single API), but you also need to express the logic of that call. No mystery here, that kind of logic is probably a few thousand of years old, and in modern day computing, this is simply called a join:

	
connection flickr {

	operation init getPhotos GET 'http://api.flickr.com/services/rest/?method=flickr.galleries.getPhotos&api_key=API_KEY&format=rest&gallery_id=GALLERY_ID' {
		resultSet 'photos' ;
		join getSizes on photo_id = id where _label = 'Square';
	}

	operation getSizes  GET 'http://api.flickr.com/services/rest/?method=flickr.photos.getSizes&api_key=API_KEY&format=rest' photo_id {
		resultSet 'sizes' ;
	}
}

Yes, it's that simple ! With just a bit of code written once for Flickr and abstracted a tiny bit, I can implement most mashups.

But that's not all, a "side effect" of MDE, in this case, is the ability to refactor your architecture. I happen to believe that mashups should mostly run on the client, unless there are some reason not to bring the data on the client (e.g. the end user is not allowed to see part of the data, bandwidth constraints...), but this point is irrelevant, there will always be the need to do some mashup both on the server or the client. Subbu's team has come up with a nice way to do that on the server side, ql.io.

So how would I enable such a massive architecture refactoring? a simple keyword and a tiny bit of code in the code generator (that generates ql.io scripts and some code on the client that invokes the mashup). I'll try to illustrate that for the next release.

join getSizes on photo_id = id where _label = 'Square' with qlio ;

3) MDE enables you to create solution oriented type systems. Many would argue that the main purpose of a computer is not to "compute", but to manage state persistently. One essential aspect of managing state is data structures and the building blocks of data structures are described by a type system.

One of the challenges when building apps and mobile apps in general is that the UI is quite varied. Take the example of a Map for instance, it often comes with points of interest. How do you bind a data set to a Map such that it displays push pins? just like you want to display rows of values in a table or pictures and picture information in a gallery?

In the case of Canappi we built a simple binding framework that lets you express that the result set from a Web API call is bound to a "layout" (a set of controls).  You can optionally use a fromKey / toKey mapping when the attribute names of the result set are different from the names of the control.

layout myMap bindings pointOfInterest with mapping aSimpleDataMapping ; 

In this statement,pointOfInterest points to one (or more) APIs that gather the data that is automatically bound to the map control which supports binding to a single push pin (lat, long, title and subtitle) or an array of pushpins. The reason why we make it that simple, is because we took the decision early to normalize the response before we bind it to the UI, i.e. we built an implicit type to which Web API response formats map to, on one end, and from which UI views (with any control) bind to.

Ok, I understand this is quite basic, but incredibly productive for at least 95% of the data that moves from a server to a client and back: I don't know any programming language that allows this type of consision (e.g. a twitter app in 30 lines of code). Yet, hundreds of thousands of developers, every day, write some code that picks up some data from some kind of back-end API call and puts it in some kind of UI element.

These examples are the bread and butter of MDE, they are very easy to implement and I would argue that they add less than 20-30% overhead to your first implementation of a variant, type of business logic or data binding. That means on your second implementation you already gained overall 20-30% of your time. So next time you look at the architecture of your solution why not ask these questions:

a) Is there any variant in your solution architecture?

b) Does your architecture deviates from the architecture of the underlying SDK / Platfrom on which it is built?

c) Are you using some business logic that is not easy to express with the programming language that you are using?

d) Would you benefit from extending the type system of your underlying programming model?

If you answer yes, to one or more of these questions, I would certainly take a good look at MDE.

Robert Scoble thinks so.

The new Path? The one that won a Crunchie last night for great design? It’s not done in HTML 5.

This morning I saw something new coming soon from Storify. Not done in HTML 5. This morning I visited Foodspotting which just shipped hot new apps on iOS, Android, and Blackberry. Not done in HTML 5.

More and more I’m hearing that designers and developers are ignoring HTML 5, especially for the high end of apps.

After building Canappi, I can only wholeheartedly agree with Bob. HTML5 has certainly a place in the mobile landscape, if for nothing else to "mobilize" your web site, but when it comes to user experience, we don't see how it can compete with Native Frameworks at least in the years to come: For every successful mobile web app, someone will build a superior native experience that users will adopt. There is simply no room to compete.

I am currently building Canappi's jQuery Mobile code generator and from what I can tell, it is extremely limited compared to the native iOS and Android SDKs.

The fundamental reason for Web Apps to emerge in the late 90s and 2000s was the "client update" problem and to a lesser degree the number of platforms on which the app should run. In the 90s, assistants used to roam the buildings with CD-ROM (and Floppy disks) to update every single client.

Today, App Stores have completely solved the update client problem (for mobile and desktop apps), and running on multiple platforms really means running on iOS and Android (although the fragmentation of Android is a bit of a concern).

Web Apps have many fundamental flaws, from flowing layouts which simply don't work in small form factors, to cluncky off line experience, not to mention bandwidth and power consumption.

If you combine a horrible developer experience to a horrible user experience, (Mobile) Web Apps have simply no room to grow from here.

AT&T released last week at CES a new API platform that exposes a number of Network APIs:

• SMS/MMS
• Location
• Device Capability
• In-App Payment
• WAP Push
• ...

The APIs implements OAuth 2.0 and capture user consent wherever applicable. I think the in-app payment (that goes directly to thesubscriber's bill) is a game changer for mobile applications, in particular Web  based mobile apps.

The APIs come with an SDK and some code samples.

In order to use these APIs, you need to join the developer program and create a developer account.

You would then create an "application" which basically gives an application id, a shared secret and a short code (yes ! your own short code). These credentials are used to get an access token (See figure below).

If you use the Java SDK (there are others available: PHP, Ruby...), all you have to do is to insert these values in the conf/att-api.properties file and build the project with Eclipse or Ant directly.

Once it is built, you just start the server by executing run.sh and you deploy the Sencha client application in your web server. The API server aquires access tokens automatically.

Here is how I deployed my server:

SDK -> /var/www/att/server -> sh run.sh

Sample app -> /var/www/client -> open http://www.yourdomain.com/client/examples/sms

If you want to change the location of the application, just update the ResourceBase value in the com.sencha.jetty.EmbeddedServer class. In my case, it was set to  webapp.setResourceBase("../../client");

That's it ! And if you wonder, with your very own shortcode, you can also receive SMS too.

I have a few promo codes from AT&T that give you free access to the platform for one year.