The DotCloud experience

Rocking and Rolling out

The Edge of the Empire Character Generator v0.1 is now out.

As it is not even feature complete, I would not define this as a milestone worth its own post. This post is about the deployment experience on the DotCloud Platform it runs on.

Documentation

While the platform documentation seems comprehensive and well written, it is somewhat outdated. The changes around dcuser did not make their way into the docs.

On the other side the help system around the command line utilities and the deployment tutorial was useful to figure out what is happening and why (not).

Platform requirements

If you are about to start a new project on DotCloud, I would highly recommend cloning the example repositories. The exact requirements does not documented too well, so it is all trial and error for those poor folks who try to bring an existing app (even a simple one) to the platform. Fortunately the things are kept really simple here.

Summary

It has been a bumpy, but short ride so far with dotCloud. It is always confusing to start using a new tool, people rush and overlook things clearly stated in the documentation. The dotCloud docs explains the concepts well but not up to date in all the details. This makes the deployment experience somewhat difficult, but I have seen lot worse than this. The concepts are however relatively simple and this keeps the pain tolerable.

All in all, DotCloud runs my simple web app for free, so I got more than I paid for.

When your programming paradigm breaks, so does your code

/ This is a quasi-translation of an older post. Enjoy! /

Hands full of paradigms

Without actually thinking about it, we are constantly jumping between programming paradigms. A typical "N layer" application can easily grow this complex before the release:

• JavaScript + HTML + CSS client, communicating via JSON (which is almost JavaScript)
• Java or .NET Back end
• Some legacy services we use through XML Web Services
• Relational database, document store, etc.

Lets count the paradigms here:

• Procedural (JavaSript, Back end, Database Stored Procedures)
• Declarative (HTML, XML, CSS, SQL)
• Functional (JavaScript, Back end)
• Prototypical (JavaScript)
• Object Oriented (Back end)

Isn't it interesting we ended up more paradigms than architectural layers? What if we toss some Domain Specific Languages in? Is it a good or bad thing?

It depends. It certainly gives us the flexibility to implement things where they're the most effective. Need to process the accounts overnight? Stored procedures are here to help. MVC style UI? You can do it in JavaScript with less round trips to the back end server.

On the other hand, there are certain concepts traveling across the whole application stack. These are the "things" our application is all about: products and orders in a web shop. Comments and pictures on a social media site. Stocks, gas tanks, shoes, you name it. These things need to have a representation in every paradigm you have. There will be a table to hold your products, a .NET class to represent them in the processing, an XML representation, a JavaScript object, and some HMTL markup to show them. These are the center of your application and all the code you write deals with them.

At certain points of your architecture, you need to convert them from one paradigm to another.

Those are the points where all hell break loose.

When the worlds collide

While most of the paradigm has some sense of data modeling, their vocabularies can be slightly different. Strings does not exists in the database engines (but there is varchar), while JavaScript has no precise numeric representation (like Decimal types in databases). The struggle continues in the functionality area too, with too many discrepancies to count. The following diagram shows how the different features partially overlap:

The "white zone" in the center is the matching point between your paradigms. This is where you can safely implement your "things".

The "gray zone" on the other hand is covered by some of your paradigms but not all. Using these features is dangerous, but sometimes we take the risk: the feature feels so perfect. Sometimes it worth the effort. Other times we regret taking the unbeaten path. A performance issue or an unforeseen twist in requirements points to the lovechild as the bottleneck of future growth.

What can we do?

• Play safe and never leave the "white zone": will be boring after a while. You will copy paste all day along and then fix copy-paste errors. 
• Play hard and code around: Of course you would never do that, would you? If you did this in the past, there is a fair chance you will end up in the "less feature for the same development effort = end of life-cycle is near" state. Try harder (or safer?) next time.
• Let's buy the perfect framework: For every generic problem there is a generic solution, right? Get Hibernate and solve the Object Oriented vs. Structured paradigm gap instantly. You will end up coding against an API, solve performance issues against an API, and generally live and die by the API of your choice. No silver bullet here. Move along.
• Keep it simple: the only smart way out is to keep the paradigms at the bare minimum. The simplest the architecture, the less paradigm collisions you need to overcome. Over time, there will be guys who want to bring their favorite framework, server, programming language because it is so cool and trendy. Resist them. Show them this blog post. Throw them out of the window if they don't listen. Anything but don't add architectural complexity to the design.

Have you found any other way around this? Let me know in the comments!

Angular vs. React - Round I.

Concepts

I've been toying with these frameworks for a while (a year maybe?), trying to implement a basic character generator web app for Fantasy Flight Games's excellent Edge of the Empire RPG. It is not that the world needs such application, it is more about me finding the framework I can easily work with. Let the fight begin!
On a very high conceptual level React is much like PHP: it can be very modular and tries to slip into your pages unobtrusively. Well, considering its Facebook roots it is not a surprise. The template syntax called JSX tries hard to look familiar, and with some minor exceptions (summarized on a this page) it feels like good old html. It is pretty much a facade though: all those familiar looking html elements are pure JavaScript objects, organized into a virtual DOM, eventually reconciled against the actual DOM by React somewhere in the backstage. This has not bothered me so far, it is more like watching a movie and knowing it is not real. Maybe it is the best for all parties involved: who whats to be stabbed in a shower for real?
Angular.JS on the other hand feels more close to the big frameworks like good old JSP and ASP with a markup page and a code-behind class. Don't get me wrong: you will probably end up with the same ratio of generic vs. framework specific tags in your html using both. The difference is more in the approach: React builds bottom up, while Angular is geared toward the do everything type usage: it works really well if you do most of your page in Angular. While React tries to be a very good "V" in the MVC (or MVVM), Angular is a full stack MVVM framework.
I am pretty new to most of these and probably missed some real important concepts on both sides. At the end it is more about your personal preference and project needs: if you like the "build your toolbox, then your stuff" approach, React can serve you very well. On the other hand it has less to offer than Angular. This could be a blessing if your page has some kind of backbone.js like framework deeply integrated.

Watch the language reader!

This time not yours but mine.
I have realized it would be better to continue in English. Someday I might attract some readers!

Translating the old posts is not really a priority but I might do it. As of now I will put some ideas about Angular.JS and React.js down on (virtual) paper.