Technical Chapter 12
The OCC Innovation Delivery teams - Fusion, Trilobites, Puffin and the OCC UX Design Studio - hold regular Technical Chapter meetings to help advance cross-team knowledge sharing. The meetings cover a wide range of topics, usually around technologies used in on-going project work, but also on tools and techniques that benefit the development process.
Docker Compose [Fusion]
Compose is a tool for defining and running multi-container Docker applications. Operando has lots of modules, each one being a Docker container and therefore Compose seems like a natural fit. However, there are limitations: Compose yields a subset of the full Docker functionality with limitations on for example networking.
A web framework for Python. Based on Natalie's training time, this is a good technology for prototyping but inferior to our standard tools for long-term development. Natalie explored code first database creation (so probably MySQL). Apparently, it does not play well with React.js (probably in the same way that Razor does not).
We also discussed an alternative: knockout.js. This is quite different to React in that it fits better into MVC Razor, but we were all quick to point out its various flaws. While being less of a deviation from the ASP MVC / jQuery way of working than React is, it does not play well with jQuery at all. There are lots of little problems that you hit when developing (for example, the order of attributes can have an effect!?!?), and they are difficult to debug.
Would you use either technology with a map control, or go the jQuery route?
React Native [UX]
This is similar to but different from React.js. It is for creative native UIs on Android and iOS. While a developer familiar with React.js will find the switch to React Native relatively easy, there are differences in, for example, navigation and of course the tags used are different.
OCC Shared / Vanilla web controls
Trilobites have been trying to set up an OCC library of shared code for some time. There is now an SVN repo but it is very much in its early stages. In coming weeks, Trilobites will be working on how to create web controls quickly in a typical OCC project, that already have the various issues solved: accessibility, validation, etc. This will require input from, for example, the UX team so that the controls are easy to re-style, but will probably come with some vanilla styles out of the box.
This pattern tends to be implemented when you need to "visit" every item in say a directory tree. In this example, there are two types of "item": a directory and a file, but a large number of operations that can be executed on each. Each operation, for example, rename, will need a method for each type and therefore it later a new item type is introduced, then a large number of methods are likely to require writing, even if only of the "not supported" sort. When it is likely that lots of new item types are going to come along, then the acyclic visitor pattern is better, for example, you test if a processor can support an item type via testing for an interface, and only then do you present the item to the processor.