My name is Ismael Chang Ghalimi. I build the STOIC platform. I am a stoic, and this blog is my agora.

We’ve updated the meta-data of out Tools with the following fields:

  • Action, a short description of the action enabled by the tool
  • Module, the module to which the tool belongs
  • Pattern, the UI pattern implemented by the tool (Module, Object, or View)
  • Object selector, whether the tool lets the user select an object

Our tool engine will initially support three UI patterns:

  • Module, whereby the asset manager shows the objects of a module (used by STOIC Resources)
  • Object, whereby the asset manager shows the records of an object
  • View, whereby the asset manager shows the views on an object

The Object pattern is the most common pattern to be implemented by our tools, followed by View, while Module will be rarely used. The latter will be used for tools that are constructed around a perspective instead of an editor. For these, the perspective will show the records of an object according to a certain view. As a result, the asset manager needs to show a list of all views defined for the object and for which the tool’s perspective is set as default perspective.

Whenever the View pattern is used, if the Object selector property is set to TRUE, the user will be able to select any object for which the tool’s perspective is available. By default, the tool’s primary model object will be selected.

All this will be a bit clearer with a few screenshots coming soon…

Singapore as proving ground

One of the reasons why I recently moved to Singapore is that I wanted to test our platform on a relatively-small yet potentially-rewarding market. ICT buyers in Singapore are progressive and forward-looking, and the recent focus by the Singaporean government on big data, open data, cloud and security (Cf. article) could not come at a better time. As a result, many of our upcoming marketing activities will be focused on this market, and many of our sample applications will use local data for demonstration purposes. Stay tuned for more…

What’s on Hugues’ roadmap

Hugues has been pretty busy lately with our Docker deployment. Once done, he’ll work on this:

  • Fix application deletion
  • Finish the database time machine
  • Add support for standalone linked datasource re-import
  • Add support for custom Elasticsearch mappings
  • Add support for cross-datasource customization
  • Improve support for advanced relationships
  • Improve support for graphs
  • Improve scalability of imports
  • Improve scalability of exports

Many of these will be described in more details through specific posts.

Latest update on Docker provisioning

Hugues is almost done with our Docker provisioning. Instances in Ireland and Singapore should be deployed for customers and partners by the end of the week. We’re still playing with various packaging options regarding the number of containers assigned to each and every tenant, but most technical problems have been solved at this point.

The display of perspective bindings and parameters has been improved. Instead of showing bindings on an horizontal bar and parameters on a vertical panel, both are shown on the vertical panel. And while we distinguish them by hiding parameters behind a “More parameters…” menu, we do not make this distinction more explicit, so as not to use the word “bindings” because it is considered a bit too technical.
The display of perspective bindings and parameters has been improved. Instead of showing bindings on an horizontal bar and parameters on a vertical panel, both are shown on the vertical panel. And while we distinguish them by hiding parameters behind a “More parameters…” menu, we do not make this distinction more explicit, so as not to use the word “bindings” because it is considered a bit too technical.
The display of perspective bindings and parameters has been improved. Instead of showing bindings on an horizontal bar and parameters on a vertical panel, both are shown on the vertical panel. And while we distinguish them by hiding parameters behind a “More parameters…” menu, we do not make this distinction more explicit, so as not to use the word “bindings” because it is considered a bit too technical.

The display of perspective bindings and parameters has been improved. Instead of showing bindings on an horizontal bar and parameters on a vertical panel, both are shown on the vertical panel. And while we distinguish them by hiding parameters behind a “More parameters…” menu, we do not make this distinction more explicit, so as not to use the word “bindings” because it is considered a bit too technical.

We’ve reafactored the Cases object a little bit in order to rationalize the way its records are shown on our new Map perspective. The object now uses three fields to quantify a case and drive its geographic depiction:
Type categorizing the case (Breakdown, Bug, Downtime, Enhancement, Question)
Impact sizing the case (Small, Medium, Large, Huge)
Severity giving an overall score to the case
On the Map perspective, type is driving the iconography, impact is driving the color of the iconography, and severity is driving its size. We still have a bug regarding the colorization of the marker, but we should be able to fix that pretty soon.
We’ve reafactored the Cases object a little bit in order to rationalize the way its records are shown on our new Map perspective. The object now uses three fields to quantify a case and drive its geographic depiction:
Type categorizing the case (Breakdown, Bug, Downtime, Enhancement, Question)
Impact sizing the case (Small, Medium, Large, Huge)
Severity giving an overall score to the case
On the Map perspective, type is driving the iconography, impact is driving the color of the iconography, and severity is driving its size. We still have a bug regarding the colorization of the marker, but we should be able to fix that pretty soon.

We’ve reafactored the Cases object a little bit in order to rationalize the way its records are shown on our new Map perspective. The object now uses three fields to quantify a case and drive its geographic depiction:

  • Type categorizing the case (Breakdown, Bug, Downtime, Enhancement, Question)
  • Impact sizing the case (Small, Medium, Large, Huge)
  • Severity giving an overall score to the case

On the Map perspective, type is driving the iconography, impact is driving the color of the iconography, and severity is driving its size. We still have a bug regarding the colorization of the marker, but we should be able to fix that pretty soon.

Here is a pretty cool scenario: emergency management for a local utility. The idea is pretty simple: monitor certain keywords such as #sgflood on multiple social networks like Facebook and Twitter. From there, aggregate posts that contain enough information to prioritize remediation work, such as geolocation or pictures. Finally, create cases to monitor the progress of remediation effort through a custom workflow.
PS: Cases are automatically created and scored based on sentiment analysis made on posts.
PPS: On the map, the size of pictures is related to the score computed for a case.
Here is a pretty cool scenario: emergency management for a local utility. The idea is pretty simple: monitor certain keywords such as #sgflood on multiple social networks like Facebook and Twitter. From there, aggregate posts that contain enough information to prioritize remediation work, such as geolocation or pictures. Finally, create cases to monitor the progress of remediation effort through a custom workflow.
PS: Cases are automatically created and scored based on sentiment analysis made on posts.
PPS: On the map, the size of pictures is related to the score computed for a case.
Here is a pretty cool scenario: emergency management for a local utility. The idea is pretty simple: monitor certain keywords such as #sgflood on multiple social networks like Facebook and Twitter. From there, aggregate posts that contain enough information to prioritize remediation work, such as geolocation or pictures. Finally, create cases to monitor the progress of remediation effort through a custom workflow.
PS: Cases are automatically created and scored based on sentiment analysis made on posts.
PPS: On the map, the size of pictures is related to the score computed for a case.
Here is a pretty cool scenario: emergency management for a local utility. The idea is pretty simple: monitor certain keywords such as #sgflood on multiple social networks like Facebook and Twitter. From there, aggregate posts that contain enough information to prioritize remediation work, such as geolocation or pictures. Finally, create cases to monitor the progress of remediation effort through a custom workflow.
PS: Cases are automatically created and scored based on sentiment analysis made on posts.
PPS: On the map, the size of pictures is related to the score computed for a case.

Here is a pretty cool scenario: emergency management for a local utility. The idea is pretty simple: monitor certain keywords such as #sgflood on multiple social networks like Facebook and Twitter. From there, aggregate posts that contain enough information to prioritize remediation work, such as geolocation or pictures. Finally, create cases to monitor the progress of remediation effort through a custom workflow.

PS: Cases are automatically created and scored based on sentiment analysis made on posts.

PPS: On the map, the size of pictures is related to the score computed for a case.