My name is Ismael Chang Ghalimi. I build the STOIC platform. I am a stoic, and this blog is my agora.
Here is a very cool features that I’ve been waiting for before using STOIC for really sensitive applications: the Cipher datatype! This allows you to encrypt and decrypt the value of a field on the client side, using the AES encryption standard. As a result, the server only sees encrypted data, and so does the network. Of course, when a field is using this datatype, its content cannot be indexed nor searched, because AES is not homomorphic.
Now that we’ve got this one working (the UI still needs polishing), I’ll be able to use STOIC for managing all my bank accounts and various online services, including the storage of their passwords. In fact, I’ll start developing a password management application now.
Here is a very cool features that I’ve been waiting for before using STOIC for really sensitive applications: the Cipher datatype! This allows you to encrypt and decrypt the value of a field on the client side, using the AES encryption standard. As a result, the server only sees encrypted data, and so does the network. Of course, when a field is using this datatype, its content cannot be indexed nor searched, because AES is not homomorphic.
Now that we’ve got this one working (the UI still needs polishing), I’ll be able to use STOIC for managing all my bank accounts and various online services, including the storage of their passwords. In fact, I’ll start developing a password management application now.
Here is a very cool features that I’ve been waiting for before using STOIC for really sensitive applications: the Cipher datatype! This allows you to encrypt and decrypt the value of a field on the client side, using the AES encryption standard. As a result, the server only sees encrypted data, and so does the network. Of course, when a field is using this datatype, its content cannot be indexed nor searched, because AES is not homomorphic.
Now that we’ve got this one working (the UI still needs polishing), I’ll be able to use STOIC for managing all my bank accounts and various online services, including the storage of their passwords. In fact, I’ll start developing a password management application now.

Here is a very cool features that I’ve been waiting for before using STOIC for really sensitive applications: the Cipher datatype! This allows you to encrypt and decrypt the value of a field on the client side, using the AES encryption standard. As a result, the server only sees encrypted data, and so does the network. Of course, when a field is using this datatype, its content cannot be indexed nor searched, because AES is not homomorphic.

Now that we’ve got this one working (the UI still needs polishing), I’ll be able to use STOIC for managing all my bank accounts and various online services, including the storage of their passwords. In fact, I’ll start developing a password management application now.

Victory! After days of epic bug fighting and stuborn resistance against the mere idea of conducting proper functional testing before making critical Git commits, the Tags field of Bootstrap is working again. We can all breathe a huge sigh of relief…
Why is it such a big deal? Because the Tags field is using the Tags datatype, which itself uses the JSON primitive. Up until now, the values of fields which datatype was using this primitive were serialized in plain text within our database (Elasticsearch). It was a quick and easy way of implementing this primitive in the early days, but it created some severe limitations, especially regarding the lookup of values within arrays and collections.
Fortunately, Elasticsearch provides native support for JSON structures, especially those that have a consistent schema across all records of the same object. Such is the case for the Tags datatypes, which is a simple array of strings. It’s also the case for advanced relationships, which are modeled as arrays of two key/value pairs (target object, target record).
Last week, Hugues and I decided that our quick and easy implementation of JSON primitive had run its course, and that native JSON mapping was overdue. Hugues worked on it, and delivered an implementation much faster than he had anticipated. He forgot to perform the minimum functional testing that would have been required to find a couple of trivial bugs though. A few email and Skype exchanges followed, and the bugs were eventually fixed, but without any functional testing to back it up. If I’m not going to do my fair share of unit testing, why should Hugues do any functional testing after all?
Hugues got lucky on this one, and his bravado (and talent) paid off.
Cheers mate!
PS: And as I’m writing all this, François is playing Daft Punk’s Get Lucky in the office…
Victory! After days of epic bug fighting and stuborn resistance against the mere idea of conducting proper functional testing before making critical Git commits, the Tags field of Bootstrap is working again. We can all breathe a huge sigh of relief…
Why is it such a big deal? Because the Tags field is using the Tags datatype, which itself uses the JSON primitive. Up until now, the values of fields which datatype was using this primitive were serialized in plain text within our database (Elasticsearch). It was a quick and easy way of implementing this primitive in the early days, but it created some severe limitations, especially regarding the lookup of values within arrays and collections.
Fortunately, Elasticsearch provides native support for JSON structures, especially those that have a consistent schema across all records of the same object. Such is the case for the Tags datatypes, which is a simple array of strings. It’s also the case for advanced relationships, which are modeled as arrays of two key/value pairs (target object, target record).
Last week, Hugues and I decided that our quick and easy implementation of JSON primitive had run its course, and that native JSON mapping was overdue. Hugues worked on it, and delivered an implementation much faster than he had anticipated. He forgot to perform the minimum functional testing that would have been required to find a couple of trivial bugs though. A few email and Skype exchanges followed, and the bugs were eventually fixed, but without any functional testing to back it up. If I’m not going to do my fair share of unit testing, why should Hugues do any functional testing after all?
Hugues got lucky on this one, and his bravado (and talent) paid off.
Cheers mate!
PS: And as I’m writing all this, François is playing Daft Punk’s Get Lucky in the office…

Victory! After days of epic bug fighting and stuborn resistance against the mere idea of conducting proper functional testing before making critical Git commits, the Tags field of Bootstrap is working again. We can all breathe a huge sigh of relief…

Why is it such a big deal? Because the Tags field is using the Tags datatype, which itself uses the JSON primitive. Up until now, the values of fields which datatype was using this primitive were serialized in plain text within our database (Elasticsearch). It was a quick and easy way of implementing this primitive in the early days, but it created some severe limitations, especially regarding the lookup of values within arrays and collections.

Fortunately, Elasticsearch provides native support for JSON structures, especially those that have a consistent schema across all records of the same object. Such is the case for the Tags datatypes, which is a simple array of strings. It’s also the case for advanced relationships, which are modeled as arrays of two key/value pairs (target object, target record).

Last week, Hugues and I decided that our quick and easy implementation of JSON primitive had run its course, and that native JSON mapping was overdue. Hugues worked on it, and delivered an implementation much faster than he had anticipated. He forgot to perform the minimum functional testing that would have been required to find a couple of trivial bugs though. A few email and Skype exchanges followed, and the bugs were eventually fixed, but without any functional testing to back it up. If I’m not going to do my fair share of unit testing, why should Hugues do any functional testing after all?

Hugues got lucky on this one, and his bravado (and talent) paid off.

Cheers mate!

PS: And as I’m writing all this, François is playing Daft Punk’s Get Lucky in the office…

The list of objects that you see on the Quick Create Shortcuts is now driven by a setting. Unfortunately, the setting is not being displayed properly by the Settings object because we’ve had a regression with the Dynamic datatype. Florian has been working on it for a couple hours trying to fix it. Stay tuned…
The list of objects that you see on the Quick Create Shortcuts is now driven by a setting. Unfortunately, the setting is not being displayed properly by the Settings object because we’ve had a regression with the Dynamic datatype. Florian has been working on it for a couple hours trying to fix it. Stay tuned…

The list of objects that you see on the Quick Create Shortcuts is now driven by a setting. Unfortunately, the setting is not being displayed properly by the Settings object because we’ve had a regression with the Dynamic datatype. Florian has been working on it for a couple hours trying to fix it. Stay tuned…

We just added a Cron datatype to deal with Cron schedules. These are used by the Schedules and Services object, and cron is such an arcane syntax that we really need a solid control for it. The datatype is there, but the control won’t be available before a few weeks.

Our new Dynamic datatype (Cf. earlier post) is starting to work, as you can see on the last two screenshots. One shows an Integer and the other a Boolean, for the exact same Value field. And when the dynamic datatype is undefined, as is the case for a configuration (a group of settings), the field is dynamically hidden.
Our new Dynamic datatype (Cf. earlier post) is starting to work, as you can see on the last two screenshots. One shows an Integer and the other a Boolean, for the exact same Value field. And when the dynamic datatype is undefined, as is the case for a configuration (a group of settings), the field is dynamically hidden.
Our new Dynamic datatype (Cf. earlier post) is starting to work, as you can see on the last two screenshots. One shows an Integer and the other a Boolean, for the exact same Value field. And when the dynamic datatype is undefined, as is the case for a configuration (a group of settings), the field is dynamically hidden.

Our new Dynamic datatype (Cf. earlier post) is starting to work, as you can see on the last two screenshots. One shows an Integer and the other a Boolean, for the exact same Value field. And when the dynamic datatype is undefined, as is the case for a configuration (a group of settings), the field is dynamically hidden.

As you can see on this screenshot, the Result field of the Functions object now supports the Dynamic datatype, which itself was configured with a Formula.js expression for specifying the dynamic datatype. Here is the expression we used for it

=stc_output.datatype

Unfortunately, I cannot show it to you, because our Field Options editor does not yet support Formula Field Options. We should be able to fix that by tomorrow hopefully, at which point the end-to-end scenario will be complete.

Victory! The Dynamic datatype is working, as you can see for the Value field of the Settings object. Next, we’re going to add support for Formula.js expressions within Field Options so that Field Options themselves could be dynamic. This will be used to properly implement the Result field of the Functions object. More on this very soon…
Victory! The Dynamic datatype is working, as you can see for the Value field of the Settings object. Next, we’re going to add support for Formula.js expressions within Field Options so that Field Options themselves could be dynamic. This will be used to properly implement the Result field of the Functions object. More on this very soon…

Victory! The Dynamic datatype is working, as you can see for the Value field of the Settings object. Next, we’re going to add support for Formula.js expressions within Field Options so that Field Options themselves could be dynamic. This will be used to properly implement the Result field of the Functions object. More on this very soon…