Posts categorized “DSL”.

Interview on DSLs

Federico Tomassetti is doing a great job spreading the knowledge on Domain Specific Languages and related tooling.

Recently, he interviewed me. We talk about current state of DSLs, models, and related tooling. You can find a version and the transcript in his blog.


Quid. DSL for exploring Web Components

Today at Metadev we have released Quid. A new web-based tool for UI prototyping with a strong focus on Web Components.

Quid uses a textual DSL with minimalistic syntax to define and compose components. With real-time preview, the immediate feedback provides a great editing experience.

After months of works it is a joy to share it and await for your feedback.

Anti-pattern: Semantic Code in Comments

Sematic Code in Comments

Have you ever encounter semantic code in comments? I mean, code in a different language to the main one used (could be a DSL), having impact on the semantics and been part of the final behavior or the program?

It’s not code commented and therefore deactivated. No, this code still influences the behavior of your app.

Yes, it sound weird, I know. But from time to time you can find it hidden in code comments.

This post discuss about this pattern found in some languages and argues about why it should be considered and anti-pattern in most of cases.

So, let’s do some some deep dive in code archaeology and review some examples:

More… »

Code generation with Essential. Back to Basics

One day I had and keep having the feeling that mainstream tools for Code Generation are over-engineered and provides a lack of Separation on Concerns.

This was the motivation for me to build Essential as a MDE tooling for creating and maintain custom code generators. Time has arrived I need to get it back to life, refresh it and adapt to the new needs.

In the meantime, for the people interested in:

Modeling on the Web

Just a quick note to link the session recorded last April 11th at Cambridge (UK) for Code Generation 2014 titled “Modeling on the Web” is now available on InfoQ.

Slides also available on slideshare.

In such presentation, our work at Icinetic on Web Modeling (textual, proyectional and wizard-based) was illustrated detailing how we addressed it. Now you can test it by yourself on the products:

Your feedback and comments is welcomed.

Dissecting an AppNow Specimen

Artisan Spanish Knife
AppNow is a minimalist service that converts simple models in a cloud deployed back-end.
The simplicity of this approach encourages developers to focus on what to build (business needs) instead of how (the technical skills to build it) and where to deploy it (devOps).

In this article, we are going to focus and delve into the technical choices made for the backend: architecture, languages & tools, organization and code practices used.

In particular, this can be a useful read for a developer wanting to introduce her/himself into MEAN development. On the other hand, the text is full of low-level technical details and is not suitable for those unfamiliar with programming.
You have been been warned.

More… »

Publishing OpenData with AppNow


OpenData logo by @fontanon

Open Data is a philosophy to make data public & accessible on the internet. Governmental data, expenditures and investments, economic indicators, resources exploit, anonymous medical information, weather information, genomics, or universe exploration to cite a few. I.e. & are good sources of governmental data from US & UK government respectively.

This movement is a prerequisite for other ones like:

  • Open Government to add transparency to the work of our politicians or
  • Open Science where science facts and research papers are freely shared on the net for anyone to conduct a further research today or in the future on the current knowledge. That what Newton referred as “If I have seen further it is by standing on the shoulders of giants” and it is one of the best way to boost the human knowledge and scientific progress.

In these days we are living, one can argue we are surrounded by tons of data, and more and more our capacity to process it is rapidly saturated and filtering mechanism are more needed than ever to reduce the noise over the signal.

On other hand, not all the relevant data is published. Not all is in digital form, not all is available for others. Providing fast and cheap publication mechanism can help to spread openData with valuable one.

What we can do as Developers?

More… »

Microservices Standardization from Models

Alhambra Tiles by Roberto Verturini

Microservices is emerging as an architectural pattern. They encourage small, autonomous and decoupled services exposing a stable contract implementing a business service with the minimum set of external dependencies.

For further discussions on Microservices, accurate definitions and its use cases read Lewis & Fowler, Richardson, or Crammon.

With no doubt, Microservices are gaining momentum. A lot, and too fast, as usual in the tech industry. So fast, that microservices abuse (just because has its buzz component and coolness factor) is already causing also problems:
More… »

End User Programming for Mobile Apps

Mobile Apps
Jean Bézivin (@jbezivin) (see slide 4 here) has a great slide about how the number of world-wide professional developers grows linearly respect to time, and at the same time, the need for software grows exponentially.

Mobile application is a specific market where the explosion for new software are more demanding than never before.

The obvious conclusion, we as developers are not going to be enough to cope with the demand without improving our productivity in orders of magnitude and/or lowering the entry barrier for non-programmers to create applications.

You know, probably it is me as an MDD/MDE practitioner could be biased, but to my best knowledge, I strongly think that Model Driven Engineering is in an excellent position to play crucial role in both worlds:

  • For professional developers: to provide tools to provide such productivity improvement.
  • For end users: to provide tools as easy as possible to allow non-programmers to solve their common tasks.


Today, let’s talk a bit more about end users: why an end user would like to develop an App?

  • Because is something I want, or I like.
  • Because is cool.
  • Because is easy (should be easy, let’s say doable for the average person).
  • Because is cheaper than asking someone else to develop it for me.


Personal Apps

A Personal App is an application tailored to a specific customer and needs. Maybe it will have only one user (as a RSS and content aggregator for day to day consume like videos, music or posts) or be shared among friends (like a birthday application or a shared travel experience). Company apps, catalog of products, specific content about music, TV or films are high popular on markets.


Windows Phone App Studio

In this context, the tool Windows Phone App Studio released two days ago by Microsoft is a great step forward in this direction enabling final users to create their own apps: Personal Apps.

With-in a three or four step wizard, the user is able to select a template for the application, define, change or refine the contents, and select the layout and colors. No technical questions, no programming skills, just the minimum set of questions required: less is more in this contexts. In 5 minutes the work is done and the application ready to be deployed to the device.

See this 5 minutes video:  Windows Phone App Studio Introduction

Windows Phone App Studio provides the ability to generate, compile and deploy the app directly to the user phone with a download initiated by a QR/BIDI code, or to download the source code for a developer to extend, change and customize the app.


Native code

Many app builders focus on HML5, JavaScript and tools like PhoneGap/Cordova. This approach has advantages in terms that provides a common JS core code to do cross-platform to many devices at the cost of non-taking the advantages of the native development: best performance, take advantage of the device unique features and APIs, and better battery management. For the problems of JS on mobile development see this great article/essay: Why mobile web apps are slow.

If you are a developer, you will be productive with the tools you know, of course. But, definitely if you can afford code generation do it: a native app will excel its JS counterpart.


Quality by Design

Another great key feature of a code generator for end users apps is about hiding a huge pile of technical details. Very huge, trust me. If you want to develop from scratch a new mobile application for a phone and put it in a market, you should consider many, many factors:

  • Compliance with the UX, style guide of the device
  • Margins
  • Colors
  • Behaviors of the application
  • APIs for accessing all the features
  • Things allowed in the market, things that are not allowed
  • Etc.

For our own experience in Radarc, passing the Windows Phone Store Certification to create our first App took us 5 iterations of one week each. Now, a well-fine-tuned code generation can produce the code right on the first run saving a lot of time, and therefore, saving money. Of course, there are other constraints like the content to be adequate and not offensive, this is for sure a human task, but the generator solve the other 95% issues.


To sum up: Very, very happy with the team work so far. Congrats to all the involved in the creation and launching of Windows Phone App Studio.

End user programming is not a new term, but hey! new tools are over the table. Let’s see how people react and what they can build with it. Enjoy!


Rethinking development design choices with MDE

The thinker, Paris. Photo CC by Dano

Decisions in all contexts of life are taken under the best information we can collect and under the assumption of many factors. Changes to the surrounding context could lead to changing assumptions and then, it is time to question and rethink about our overall strategy.

Software architecture and design decisions are taken based on principles as the following ones:

  • Simplicity
  • Ease of use
  • Maintainability
  • Separation of Concerns
  • Understandable
  • Low coupling
  • High cohesion
  • Robustness
  • Performance
  • Speed

These principles lead to methods and low level techniques in the process of software creation. And some of them are based on assumptions about the cost of producing code, debugging and maintaining it by capable humans, also called, developers.

Every language, tools and framework comes with its own boilerplate code, ceremony and plumbing. By plumbing, I mean, the code you need to add to glue the components with the framework and/or infrastructure. Plumbing code uses to be a real pain for developers: provides no added value to the business, uses to be tedious to write, it is boring and it is a source of bugs. Most programmers use to hate repeating such plumbing code pushing them in the background as mere typists.

My hypothesis here is that: many development choices we take rely on the cost of changing code. And many developers take such decisions instantaneously like following a mantra in their “agile” religion without stopping and thinking it twice in many cases.

But, what happens if such cost is reduced in a factor of 10. Could this lead to rethinking our design choices and approach the problem with new eyes?

Now, I need you to consider the possibility that we are doing MDE (Model Driven Engineering) we have a code generator: a good one, capable of improving your productivity as developer in a factor of 1 to 10 in a given domain. Of course if such code generator would ever exists, that would be a disruption technology, isn’t it? May be you don’t believe in code gen or have had already bad experiences in the past with it, but please, open your mind and just consider the possibility before reading:

With these kind of tools under your belt and in your mind, let’s now review how things would change:

Code generators are feed by metadata, or models, or specifications. Choose your preferred name, the semantics remain. At the end: a model or a spec is a piece of information in a certain level of abstraction useful to reason about a system.

Conclusion 1:
In this context, if the generator is going to improve your productivity in a factor of 10, makes sense to dedicate time to carefully build the model (analysis and design) and less time to real coding.

The model will be reflecting more and more the essence of the business. The code can be discarded and regenerated whenever is needed, making it easy to move to a different technology.

Conclusion 2:
Therefore, the value is more and more in the model, the code becomes discardable more and more as you increase the percentage of generated code. In the same way as people started to code in C instead of maintaining assembler code, once people trust in the compiler.

Conclusion 3:
In this context of work, Forward Engineering would be mainstream and the way to go. Building and maintaining models and doing code generation for the 80% of the code and then adding the 20% missing.
It is makes no sense, in terms of cost and feasibility to look for inexistent reverse engineering tools to keep in sync models with code. Code is warranted to be in sync with models if this code is only generated by the generator and never touched by a human developer.

The goal is not to replace or avoid developers, but to relieve them to do the boring things (the 80%) and put their brains focused on the real quest: the non-trivial 20% missing.

Conclusion 4:
Don’t touch generated code. Delimitation of user code and generated code should be strict and the punishment to rewrite and refactor their code must be enforced to those who dare to break this rule.

Design choices:

Designer choices frequently involve taking decision on:

  • Repositories: concrete, generic, no repositories at all?
  • Data Transfer Objects (DTO): one for all, many (one per use case), none
  • POJOs/POCOs vs full entity-logic objects
  • Anemic models?
  • DAO / ORM – mapping headache
  • Fluent APIs or XML configuration files
  • Inversion of Control frameworks

And once again, these choices are resolved in the traditional way, taking in serious consideration maintainability issues and ease of change because more likely the software will change with the business.

But now, with our new eyes, let’s remove the assumption that this code is no more a problem to be changed. Moreover, the cost of changing one of these decisions is near to 0, or at least smaller that changing code in the traditional way: just change a switch in the code generator strategy and regenerate everything again.

I will put you an example: ORM mapping files (a la Hibernate/NHibernate) uses to be real nightmare especially in XML files when facing a medium/big system with 500 tables. Writing XML files is tedious, error prone and a real developer torture. And in this context makes totally sense to use a fluent API approach, convention over configuration approaches and any techniques that helps to alleviate this painful and repetitive task.

However, if you use a code generator, (and I do, no science fiction here) able to allow you select the target ORM, and write the correct mapping files in the 100% of the cases, then, in this new scenario: XML is no more a pain. I can occasionally open an mapping XML file or a fluent API version and check that it is correct as long as I do not have to rewrite it.

And that’s basically what I want to stress: design choices in the software industries are strongly influenced by the way and the tools we use to create the software assets. If we change the tools and the costs of change, we should start rethinking if there is a better way of resolving other principles. For example, preferring ease of change in the model instead of ease of change in the code.

Enabling Evidence based Software Engineering:

Once you take the red pill, there is no way back. When facing each new problem, you can prototype the system, and instead of imagining what would be the best performance architecture for your system. You can build a Proof of Concept in two or three candidate architectures, create a benchmark, test and measure it with realistic stress load test. And then, only after comparing the measurements, take a decision about the best architecture for this system.

This method of doing things changes the quality and the way we create software, turning the artisan process into a more scientific driven by data based decisions.

Some of you are ready to accept and embrace it, others would not. For sure my point of view in the issue could be strongly biased, but after of working in conceptual modeling and code generation for more than 14 years, my feeling is that technology for modeling and code generation has matured a lot in latest years and the disruption point is approaching faster and faster. Will you jump into this fast train?

What do you think?


PD: For the ones that read till here but still do not belief in code gen yet:

Advertising ON:  

Would you like to try a real and modern code generator to see its possibilities?

Take a look to Radarc and share your impressions.

Radarc is done by developers for developers.

Advertising OFF: