Generatron principle #1: Representing the structure of data and application in a way it can be (re)used to create systems in multiple platforms with reduced effort and time.

Yay!!! we landed a rocket!!… on Earth? and what that’s got to do with Software Engineering

Very recently if you reading this story on or after late 2015 you have might have seen the news about successfully landing space rockets on Earth.

This amazing feat, first by Amazon’s Blue Origin and then by SpaceX’s Falcon 9 rockets has taken [In]numerable hours of planning, design, engineering and and I would guess, [In]numerable amounts of money to accomplish. So what’s the big deal?


This is a big deal because rockets are expensive. The Falcon 9 that SpaceX uses costs around $60 million to build, the company told NBC News. Fuel costs per launch are about $200,000.
Most rockets are designed to burn up during re-entry. That means rebuilding a $60 million rocket for every single space mission — not exactly the most cost-effective system.
Reusable rockets, however, would mean cargo could be sent into space with only the fuel and maintenance costs to consider.

By reusing the rocket you they are not only reusing the physical object, they are also reusing all those (wo)man hours and resources invested to complete the project.

Reuse in Software engineering

For many years in software engineering we have been using practices that allow us to reuse those expensive ‘rockets’ we build every day, in the form of code, designs, etc.

Following the DRY principle , we store algorithms, routines, business knowledge, in libraries, frameworks; ready to use for our next project. Here it is as explained by Wikipedia

In software engineering, don’t repeat yourself (DRY) is a principle of software development, aimed at reducing repetition of information of all kinds, especially useful in multi-tier architectures. The DRY principle is stated as “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”
Besides using methods and subroutines in their code, Thomas and Hunt rely on code generators, automatic build systems, and scripting languages to observe the DRY principle across layers.

Generatron and Reuse

Generatron is a Generative Coding as a Service (GCaaS ?) platform, where you can input a data model in a “black box” and on the other end, receive relevevant source code that can understand and interact with that data.

Ok that’s a mouthful , so lets consider a few example use cases where you will want to reuse something you have to create something new:

  1. You have data stored in a database (Oracle, DB2, MySQL, etc.), lets say in a legacy application and you want to create a web and/or mobile application.
  2. You have built an IOS or Android application that stores data in a local database (CoreData,SQLite), but now you want to interact with and store data in a backend system.
  3. You are starting a new software system and you know you will want to write/build both backend and frontend systems For that you would like to reuse your data design, to minimize effort in building those systems.

Depending on your situation, you would have to hire a number of resources front end /backend developers, architects, DBA’s; to help you transform what you have (bolded) into something you don’t currently have (italicized).

Generatron aims to reduce the time it takes to get everybody in the same page, and then the time it takes to type all that code, and make it production ready.

Becoming model literate

It became evident that to maximize reuse, Generatron needed to be able read and understand different ways we convey data structure to a software system: databases (MySql, DB2, Oracle, Access), domain models (Grails, Rails, Sailsjs domain or model objects), documents (YAML , Excel, JSON files).

We could then import them into Generatron and get them ready for reuse in the form of Code Generation.

It made sense to separate these functions and we ended up building Modelatron, were you provide us with the url to a publicly readable git repository, containing your application’s data structure, we will clone it and then explore it for metadata. Currently we support the following model types, with varying degrees of success as we are still developing/testing:

  1. IOS CoreData models
  2. Grails 2.3.x+ Domain Models
  3. SailsJS Domain Models
  4. YAML documents.

Support for other formats is in the works, late 2016.

Model reuse in action

Let’s start with a small use case:

As a developer I want to create an IOS app with core data model and use Modelatron/Generatron to create a backend to store data. I don’t want to use a BaaS (Backend as a service).

Instead of writing a new app, we will just go to to GitHub and choose a ‘donor’ that uses CoreData. We settled for . For this proof of concept (at this point a fully runnable project is not being created) will create backend code using Swift by leveraging Let’s see the process.

It works!

Once we have the data model imported nothing would stop us from also writing a node express backend or a grails backend, all of this in less than 10 minutes!

We are very excited of the results we have seen so far, the weeks and months to follow we will be doing more development to fine tune the platform to make sure it is producing working code 99% of the time.

Like what you read? Give Mark Johnson a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.