Agility for differentiation



An interesting white paper from Bloomberg Businessweek Research highlights the importance of agility in , in order to achieve  competitive differentiation.

In fact, approaching cloud-based development with the same process used for desktop based development (i.e. the traditional “code – compile – test – debug – deploy” cycle) does not really fit the need for speed and agility that cloud-computing is supposed to deliver.

Organizations are finding that a cloud-based platform for agile software development provides the speed and  flexibility they need to respond to opportunities and market changes. But this will not happen overnight. To support cloud adoption, enterprise cloud development (ECD) platforms can provide a secure path for managing development and deployment in a hybrid cloud environment.

Livebase unique “pure model-driven” approach, combined with the flexibility to deploy virtually anywhere in the cloud (or at the customer’s premises) brings agility to the next level, allowing developers to create, deliver and maintain complex database solutions up to 10 times faster than coding, and to reuse/integrate them across the enterprise.

Do you have a background in data-modeling or database design? Try the Livebase platform today, and experience the power of conceptual data modeling in the cloud.


Antonio Leonforte, CEO di Fhoster, è relatore al convegno organizzato da Business International “Best Practice nel Cloud 2013”

Antonio Leonforte presenta gli innovativi servizi cloud basati sulla piattaforma realizzata da Fhoster e denominata Livebase – Business Agility Platform per consolidare centralmente, gestire in sicurezza e condividere facilmente tutti i dati aziendali che sono normalmente dispersi su documenti e fogli elettronici, scorrelati, e fuori dal controllo dei responsabili IT.
La flessibilità dei fogli elettronici induce infatti i dipendenti delle aziende a usare questi programmi come soluzione pratica e veloce per gestire in modo autonomo (senza il coinvolgimento dell’IT) alcune attività che non rientrano nei processi standard o legati al core-business.
Con il tempo, tutto ciò si traduce quasi sempre in un’evoluzione senza controllo di questi database, che possono diventare costosi da manutenere, rischiosi sul fronte dell’integrità e della riservatezza dei dati, e difficili da mettere in relazione tra loro per estrarre informazioni aggregate realmente utili all’azienda.
Livebase risolve efficacemente questo problema consentendo di soddisfare in modo rapido e coordinato le esigenze di consolidamento e gestione dei dati e, al tempo stesso, di assicurare un allineamento con i sistemi centrali, una estrema agilità nella manutenzione evolutiva e un costante rispetto della governance IT.
Livebase è disponibile a servizio e consente di configurare in pochi giorni soluzioni complete e “chiavi in mano” (con eventuale censimento, pulizia, consolidamento e migrazione dati dispersi in azienda) già pronte per la produzione, anche su infrastruttura dell’azienda o di terze parti, senza alcun investimento iniziale e con la garanzia di un supporto continuo.

InformationWeek on PaaS…

The Information Week on PaaS:  “We believe that platform-as-a-service providers will eventually host the vast majority of Web applications. The value proposition for PaaS is so strong, and so aligned with both business and developer interests, that it’s a matter of when, not if, PaaS becomes the standard. The shift will be gradual—significantly slower than the adoption of IaaS—because of the tight integrations required and the significant loss of control over hardware and software by IT departments. But it’s time to evaluate the landscape of PaaS options and start planning your migration strategy.”

DNS problems

We’re experiencing problems with our DNS server. At the time of writing the problem should be fixed but the new settings will take some time in order to propagate though the internet. In the meantime our site might not be reachable and emails sent to our staff might bounce.

Livebase cloudlets configured with a custom URL have been always reachable, while cloudlets with a standard URL (hs<n> might still be reachable only via their IP address.

I apologize for the inconvience, and please feel free to contact me on skype (a.leonforte) or twitter (leonforte) for any request or need. The situation should be back to normal by tonight. More info in the next ours.

Livebase 2.11 to production

Attach files to database objects

It is now possible to model applications allowing to attach files to database objects. Such applications can be used to upload unstructured content (PDF files, MS Word documents, ZIP archives) and to associate such content with structured data (author, date, topic, etc.) that can help in managing and retrieving it.

Let’s say, for instance, that you are a physician, and that you have modeled a simple database application keeping track of all your patients. Your model will likely contain a “Patient” class with all the attributes required to identify a patient (e.g. first_name, last_name and date_of_birth).

Now you can extend your model by adding to the “Patient” class one or more attributes  of type “File”, e.g. the PDF scan of the result of a genetic test. Just open the model, select the database schema, right-click on the header of the “Patient” class, and select  “New attribute > File” from the contextual menu. Once regenerated, your application will include an upload button in the form to create or edit a patient.

Contextual creation of associated objects

When populating a database, it happens often that while creating an object you need to refer to another object which does not exist yet. For instance, you might want to register a new invoice which has been paid with a check, but you cannot find the “Check” option in the menu containing all the methods of payments.

Until Livebase 2.10, the only way to resolve the problem was to open a new context on the “Payment_method” class (by clicking on the specific command in the application menu), add  the missing “Check” method, go back to the initial context where the invoice form is still open, hit the refresh button and select the new “Check” method you have just created.

With Livebase 2.11 end-users can now take advantage of a button beside each association editor, allowing to create the object to be associated (the new “Check” method of payment, in our example) within a modal dialog box which pops-up in the main context (the invoice form, in our example). Once created in this way, the new object is associated automatically.

The new feature is available only when the class target of the association (i.e. the “Payment_method” class, in our example) does not have any part class (i.e. is not a whole of one or more composition relationships).  In fact, structured classes would be too complex to be managed within a modal dialog box.

Minor improvements

  • Fixed bug in the visualization of real numbers
  • Fixed bug in the wizard morphing the database schema after some specific types of change in the cardinality and/or navigability of associations in the model.

FHOSTER at TechCrunch Italy

After much anticipation, TechCrunch is finally coming to Italy with a showcase of Italy’s 40 hottest startups, and we’re quite happy to have qualified. Come visit us tomorrow (September 27, 2012) at The Globe Theatre, Largo Aqua Felix, Villa Borghese – 00197 Rome Italy.

TechCrunch Italy will gather some of the most recognised leaders and innovators of the technology and media industries in Italy, Europe and the US to give a unique insight into the big changes and trends happening in the world right now.

At stand 35 we’ll show live the latest version 2.10 of the Livebase platform, the only model-driven Application PaaS platform conceived to create Enterprise database applications (and the REST API to access them) on-the fly. More on the event at

Livebase 2.10 released to production

We are very proud to announce that Livebase 2.10 has been released and is now in production, featuring a number of improvements over the last public release 2.8. The major new features include a new on-demand backup system, deferred model validation, dynamic data-type change for class attributes (with no data-loss whenever technically possible)  and a powerful enanchment on unique constraints now applicable also to relation roles.

Backups on demand

Create a snapshot (image backup) of any cloudlet in seconds, with a single click.  Backups are saved on our secure storage area: sort them by date or cloudlet, and restore them with a single click.

Livebase automatically performs disaster-recovery images of every cloudlet  every 4 hours, and these images are stored on physically distinct servers . Livebase also allows developers to download the database of their cloudlets (as a MySQL dump or as a MS Access file) at any time. The good news is that Livebase 2.10 now also features a quick-and-easy, server-side backup option. Just open the command  menu of the cloudlet you need to backup and click on the “Backup” command, which basically takes a snapshot of the cloudlet (members, applications and database) and saves it (as a compressed archive) on a special storage area safely located on a physically distinct server. To list all your backups just click on the “Backups” tab located on the top-right area of the dashboard. Each backup in the list is identified by a timestamp, a short description of its content (whatever was inside the cloudlet when the backup was created) and an optional comment provided by the developer. You can group backups by cloudlet  or by date. To restore a backup, just select it from the list and press the “Restore” button at the bottom of the list: a new cloudlet will be created, identical to the one the backup was taken from. Please note that on order to restore a backup your account must have resources enough for the additional cloudlet created by the restore command.

Deferred model validation

More flexibility in editing complex models. Freely change or delete model elements: any other element depending on the changed/deleted ones is now just marked as invalid.

Until version 2.8, the Livebase designer constantly enforced formal validity in the models, while they were drawn by developers (i.e. not just on save). The rationale was to pro-actively prevent the developer to draw inconsistent models. An important drawback of such a rigid approach, however, was that when developers changed or deleted some model elements, any other element depending-on or referring-to the changed/deleted element were changed/deleted as well, automatically, to keep the model consistent in real-time. On complex models, with complex query/math derived attributes, this behavior turned out to be less than desirable.  In Livebase version 2.10 the designer allows to apply changes on the model that temporarily make it inconsistent. When this happens, the designer shows a warnings and allows the developer to go through a list of the issues and fix them. If you delete an attribute, for instance, the designer in Livebase 2.10 does NOT delete all the derived attributes depending on the deleted one: it just mark them as invalid allowing you do adapt the expression behind each of them. Note, however, that it’s still not allowed to save an inconsistent model: any problem in the model must be fixed in order to save it.

Dynamic (data-preserving) attribute type change

Change the data-type of an attribute in the model of a cloudlet already in production, without losing data (some restrictions apply).

Developers can now change the data-type of an attribute whenever it makes sense (that is, when the semantics of the attribute does not change). This new feature is extremely useful when the cloudlet database already has some data that you want to keep: in this case, in fact, deleting the attribute and recreating it  with the new data-type would delete the existing (populated) column in the cloudlet  database, and would replace it with a new empty column. To change the type of an attribute, in the Livebase 2.10 Designer, just right-click on the attribute (in the Database schema) and select one of the target data-types in the “Change type” submenu. Please note that not all the conversions are allowed.

New “Year” data-type

The new year data-type allows a more semantically correct management of year values into Livebase applications, and a better formatting too.

All the applications generated with Livebase automatically format big numbers using the thousand separator configured for the current user (e.g. a dot for Italian users, a comma for English ones).Unfortunately this happened also with years, because they were normally modeled as integer attributes. With Livebase 2.10 developers can now take advantage of a special “Year” data-type, whose value are not formatted with the thousand-separator. Please note that only a subset of the arithmetic operators are allowed on years (e.g adding an year to another one does not make sense).

Scope of unique constraints can now be restricted

It is now possible to enforce that two offices “of the same company” cannot have the same name. The additional condition between quotes (scope restriction) is the new feature.

In Livebase 2.8, every unique constraint applied on a class had an implicit global scope, in that it was mandatorily applied on all the objects of that class. In order to provide the modeler with more flexibility, the latest version of Livebase allows to restrict the scope of the constraints to a subset of the objects based on their relationships with other objects.

To clarify this concept, let’s consider a simple model with a “Company” class related to an “Office” class via a composition, as in the picture below.

Given such model, end users are able to create companies and, within each company, to create the offices of that company. However, applying a unique constraint on the office name without restricting the constraint’s scope would always prevent the creation of two offices with the same name, even if they belong to different companies.

With Livebase 2.10 it is now possible to include in the unique constraint, along with the office “name” attribute, also the role linking the office to the company it belongs to. By doing so, the resulting applications will prevent the creation of two offices with the same name only when they belong to the same company (in other words, name collisions will not occur between offices of different companies).

More generally, Livebase 2.10 allows unique constraints to include not just class attributes but also any “whole” role (added to the constraint by default) and  any association role whose max cardinality is one (to be added manually when desired.

Redundancy control on association objects

Easily prevent the creation of redundant association objects between the same pair of associated objects (e.g. the result of a match between two basket teams, or the score a student got on a university course).

Livebase does not allow to add attributes to an association (i.e. to create an “association class” in UML terms), but modelers can easily work around this limitation by turning the association into a class with all the desired attributes, and by linking such new class to the two classes that were at the end-points of the original association. This technique is known as “association reification” and is shown in the example below.

Let’s consider, for instance, the problem to track the scores that some students get at the exams they pass: a simple relation between the “Student” class and the “Course” class  (as shown in the picture below) would not allow track how each student scored on each  course.

In fact, “score” cannot be an attribute of the Student class (because each student has one score for each course passed) and it cannot be an attribute of Course class either (because each course is passed by many students with different scores). In essence, score should be an attribute of the association between the Student and the Course classes, but, as noted previously, Livebase does not allow to add attributes to associations.

To solve this modeling problem developers can “reificate” the association by replacing it with a class “Exam” with the score attribute, and by associating this new class to the Student and to the Course classes as shown below.

Objects of classes like Exam are often called “association objects”, in that their main purpose is to associate other objects (a student and a course, in the example) and to hold the attributes of such association (the score).

With Livebase 2.8, however, there was no way to prevent the creation of multiple association objects connecting the same pair of end-point objects. In our example, there was no way to prevent the creation of multiple exams for the same student-course pair.

With Livebase 2.10, instead, developers can now easily create on the “reificated” class a unique constraints containing just the roles linking it to the end-point classes. Back to our example, developers can now add to the Exam class a unique constraints containing just the student and the course roles, which definitely prevents the creation of multiple exams for the same student-course pair.

Automatic layout of models

Drawn a complex model and need help in arranging classes and relation? The new automatic layout algorithm sorts it out minimizing bends, relations crossings and the overall diagram area.

It is always a good practice to draw Livebase models placing semantically-related classes on the same diagram, close one another. Sometimes, however, an automatic layout facility comes handy, especially when models are not originally drawn by the developer but automatically reverse-engineered from MS Excel files.

Livebase 2.10 now features a sophisticated automatic layout facility that can rearrange your diagrams moving classes and re-routing relation lines in order to minimize crossing between relations, the total number of bends along relations and the overall area off the diagram.

Instant cloudlet stop & restart

Stopping and re-starting a cloudlet is now up to ten times faster.

The architecture of the cloudlet stop operation has been redesigned to make it much faster. In Livebase 2.8 all the applications running on the cloudlet were immediately undeployed, which required up to ten seconds. With Livebase 2.10 applications are now just configured as logically inactive, but they stay deployed just in case the cloudlet is restarted without changes in the underlying model. The entire stop and re-start process now takes a few seconds, and it also saves considerable CPU time on the hosting server,

Livetable preferences now preserved during cloudlet rebuild

When you extend a cloudlet already in production, preferences applied by cloudlet members on livetables corresponding to unchanged classes are preserved.

In Livebase 2.8 each time a cloudlet in production was modified and rebuilt, all preferences applied by members on the livetables of the generated application were reset. Such preferences include the set of hidden/visible/grouping columns, the order of the columns and their internal ordering, filters, etc. With Livebase 2.10 such preferences are preserved through the cloudlet rebuild process, with the only exception of the livetables corresponding to classes whose database-schema has changes (attributes added/deleted or attribute type changed).

REST API now supports localization for the HTML data format

Checking the results of a REST API call to a cloudlet using the HTML data format? Enjoy classes, attributes and roles names localized in the language configured for your account.

HTML is one of the data formats available from the REST API of any cloudlet, along with XML and JSON. HTML is format has been provided to support humans reading the results of each call, but in Livebase 2.8 classes, attributes and roles were reported using model identifiers rather than labels localized in the language of the account making the call. This has been fixed in Livebase 2.10. Please note that both the XML and the JSON data formats will still refer to classes, attributes and roles using the identifiers specified in the model, since those data formats are conceived to be machine readable.

REST API now supports calculation of derived attributes before commit

Need to calculate the value of a derived attribute for a given modified object before saving the object? Now you can!

Quite often the form for editing a database object has some read-only fields that are recalculated and updated automatically whenever you change some of the other fields according to some formula. In Livebase you can achieve this by using derived attributes (i.e. attributes whose value is derived – calculated – according to a formula based on other attributes) and the generated applications perform the magic automatically. In Livebase 2.8 however, it was not possible to create a client based on the REST API with a similar behavior, because there was no way to ask the server “what would be the value of this derived attribute given the values of all the other attributes” without actually saving the entire object. Now with Livebase 2.10 you can, so the end-user can see the result of the calculation and decide whether to save the object or not.

Other minor improvements

  • It is now possible to configure more precisely margins for each report and a page-break before each section.
  • Characters from extended carsets are now supported in model localizations
  • The REST API now return localized labels when the “HTML” data format is requested
%d bloggers like this: