With more than 20 years of activity, not mentioning the previous 10 years of its founders as researchers in the Artificial Intelligence Laboratory of the ENI Spa Group, Sinapsi had the opportunity to get skilled on many technologies and product life-cycle management tools and methodologies.
GNU/Linux and Java
The choosed technologies of Sinapsi at its foundation have been the GNU/Linux operating system and the Java programming language. These two choices, which many judged nefarious, because at those times MS Windows NT was the market leader, while GNU/Linux OS and Java programming language were barely knew, have been found very successful in the aftermath. Below is the excerpt from the 2011 interview to Mimmo Cosenza by Flavia Marzano on Wired magazine.
You have been always connected with the free software, right? What made you do it?
… in 1996 I founded Sinapsi together with some colleagues. We bought a couple of very cheap PCs with the MS Windows operating system pre-installed, but we did not know their development environment and the UNIX operating systems, used by our very first customers, cost a fortune. One of my associates told me about Linux. Said and done. With very cheap x86 machines and Linux we were immediately able to develop applications targeted at very expensive UNIX systems …
This explicitly explains the choice of GNU / Linux, but only implicitly the choice of Java. Java was the first virtual machine solution for developing enterprise applications, whose motto was: Write Once, Run Everywhere. An application could be developed in Java on the GNU/Linux operating system and be released in production on MS Windows NT operating system, despite our detractors at the time.
Since its foundation, Sinapsi has never positioned itself in the market of website development. Quite the contrary. When we were asked about our services we answered as follows:
We do everything that it’s invisible
The above image shows the Sinapsi website of the early 2000s, as recorded by Archive Org. A corner of the cover unveils the source code of Java’s Socket class, just to emphasize our market positioning.
When it comes to invisible software, it is inevitable to talk about middleware as well. In 2007 La Feltrinelli commisioned us its e-commerce initiative. Its UI was created by Frog Desing, while we chose Magnolia CMS, as Content Management System, and Mule ESB as the Enterprise Service Bus to integrate the legacy applications for order, warehouse, and shipment management.
Since then, the SOA (Service Oriented Architecture) architecture has become our daily bread. Few years ago we begun to push ourselves further, returning once again to our origins.
Clojure is the new LISP
In the interview on Wired already mentioned, Mimmo Cosenza said:
… In the second half of the 80s I entered the AI research center of ENI (formerly Agip Spa) and I had a wonderful LISP machine for myself only …
The discovery of Clojure, though once again coming from a distant and glorious past, was nevertheless a breath of fresh air. We remembered when, while teaching Design Patterns, we were used to say to participants:
The best line of code is the one you do not write
This statement, rather cryptic for non-professionals, today seems paradoxical, if applied to Object-Oriented and Design Patterns.
A language that needs Design Patterns to solve problems that it produces itself, resembles the geocentric model of the universe that needs Ptolemaic epicycles to calculate the movements of the planets.
On the contrary, a programming language that favors abstraction will allow the modeling of the world with a limited number of general laws composing each other, such as the laws of physics.
And it was precisely to the graduates of Mathematics and Physics, accustomed more than others to the abstraction for modeling the world, that Sinapsi proposed in 2012 a seminar of a few months on Functional Programming in Clojure.
The above is one of the slides that Sinapsi shows with greater pride to its customers, also because it has allowed us, who were invisible, to make ourselves visible.
On the left the variety of applications:
- desktop, for any operating system;
- browser-based, for any browser;
- app, for any device, iOS, Android and even Windows Phone.
On the right the servers, in all possible deployments, regardless of operating system:
- at your data-center
- in cloud
And above, to control everything, Clojure and ClojureScript, the latter using some of the most renowned and performing client-side technologies:
- React and React Native: the most advanced and performing component technology for web and for mobile applications in native mode;
- Electron: to build portable desktop applications on any operating system.
How often, on average, do companies bring into production the corrections and evolutions of applications developed by programmers? And how many quarrels between the “development” and “operations” divisions are taken over when, bringing the new developments into production, is there anything that did not work as expected? How long does the marketing division wait for seeing in production new applications or features to be served to its customers in order to continue to stay competitive on the market?
Since the beginning of 2017, Sinapsi has created an internal project called Fast Track, with the aim of significantly reducing the time it takes to put new applications and new features into production.
This is a project of progressive automation of the software life cycle, starting from the acquisition of functional specifications to the monitoring of the operations.
The final goal of the project is to arrive at the point where the time between the commit of a new feature (or the fix of a bug) and its deployment in production is close minutes. All this by automatically passing through the execution of the various types of tests, UAT (User Acceptance Test) included.
The metaphor we use internally to characterize the Fast Track project is that of the dishwasher:
As long as there are only two people eating, you can also wash dishes by hand without problems, but as soon as there are more, everyone would like to have a dishwasher.
Of course we are aware that one of the most common statement of programmers when something does not work in production is punctually:
It works on my computer
Docker does not allow to use this excuse again, but inevitably introduces new issues. The challenge of 2018 will be to extend our “dishwasher”, which as a whole goes by the name of Continuous Delivery, to microservice architectures by allowing to deliver new releases in production several times a day, potentially for each source code commit, even if the extreme dynamism of such an architecure poses not so easy problems to be solved.
But the biggest challenge will be for our customers. If they really want to adopt scalable and dynamic architectures, they will inevitably have to rethink their organizations, which in turn will have to be designed to be scalable, because time and the markets do not wait.