Over the past few days, this blog has seen very little activity, mainly because we’re trying to connect our server to our user interface for the very first time. As a result, everybody is hacking at a feverish pace so that we could implement an end-to-end scenario before the end of the week. The scenario consists in developing a first version of the Object Grid widget that we could use to power the stoic.com and poetry.io websites. For this purpose, I just finished the compilation of all the meta-data for the objects we need to bootstrap our platform:
I did all this work directly from Google Spreadsheet. In the meantime, François built a simple JSON serializer that exports all this meta-data in multiple files stored in a folder on Google Drive. While we did this, Pascal built a not-so-simple bootstrap library that parses our JSON files and generates all the tables on our PostgreSQL database automatically. It’s starting to work, and it allowed us to fix a few bugs in the meta-data. We should be done with all this tonight, and we should be able to start building our first widget tomorrow.
For some reason, we have yet to introduce our Chief Technology Officer. He’s been busy working on our server and a few other things, but his days in the shadows are now being numbered. As I’m writing these lines, he is putting the final touches to the website he built for promoting one of the few open source projects that we’re planning to release this year. So stay tuned for some announcements to be made soon…
This past week-end was quite productive. Over 2,500 lines of code were either migrated to the new architecture, or written from scratch (roughy half and half). I focused on integrating the new embedded NoSQL database that is now part of our user interface framework. It allows us to cleanly separate data and meta-data from the user interface, which was not possible before without using our upcoming server.
With the new architecture, we have two operating modes: embedded database and remote database. The former is fast but limited in scale (200MB), while the latter will introduce a bit more latency, but will scale with practically no limits. The code we’re developing for this new architecture is written in such a way that we can plug virtually any database for the remote option, either SQL or NoSQL.
Following this productive week-end, here is what we have:
- All meta-data migrated to new architecture
- All data migrated to new architecture
- Code libraries migrated to new architecture
- Code loader migrated to new architecture
- Data caching migrated to new architecture
- Data CRUD API partially migrated (roughly 25%)
Tomorrow, we will try to plug our query builder in order to get a first prototype of object view. We will also re-implement our record view, taking advantage of the fact that our upgraded user interface framework now supports HTML 5. We will integrate the jQuery, jQuery UI, and LESS libraries. We will also package a few icons into a web font to make things look good.
Let the fun begin…
Our CTO gave us a first presentation of our upcoming Server API today. Like everything else we do at Sutoiku, it’s deceptively simple, yet amazingly powerful. We’re still a week away from being able to connect it to our user interface in any meaningful fashion, but it’s starting to look pretty good. Right now, we’re using our applications in a standalone manner, without any back-end. They work great that way, but we’re missing about half of the features that are made possible with the client/server combo, so I’m starting to get pretty impatient. Schedule-wise, we’re still planning to release the client to our early adopters on Just 1st, and the server in the summertime.
One of the trickiest challenges that we have to solve is to synchronize data across a single server and multiple clients, in a bi-directional fashion. The problem is made even harder by the fact that we would like to support scenarios where modifications are made from offline clients. Last week, our COO and myself teamed up against our CTO, trying to convince him that we could not solve such a problem. This morning, our CTO came back to the office with what looks like a brilliant solution. It’s so simple that we’re having a hard time understanding why nobody came up with such a solution before. Either we’re totally missing something, or we stumbled upon something quite significant. We’re giving ourselves a few days to decide which one it is.
We have decided to develop our product using node.js. And we’re hiring!