Best Practices

Here is a set of recommendations for using Olympe in a most effective manner.

One of the defining characteristic of Olympe is that it has been built for reusability and scalability from the ground up. Therefore, software engineering best practices can be applied.

Gartner: "A tool for fusion teams"

Business - IT continuum, for business and IT to work together to solve the need of customers (and they HAVE to work together) It's an Integration Tool: integrate different systems/technologies/features together --> solution to heterogeneity & to multiplication of apps

Catalog / marketplace just a way to support the composition. Added value is the ability to extend the catalog. Applications no longer monoliths, but sets of bricks Adapt by composing / recomposing all the time

Architect the application from the top - down

Design by Contract

Design by Contract is a software design approach that recommends building formal interface specifications for software components.

This is exactly what happens when designing bricks: logic bricks have a name and a set of inputs and outputs, visual components have properties and events. Those define the contract that the brick must follow. That contract is helpful in several ways:

1. Before implementing the brick, one can use it in different situations to make sure that its contract makes sense. Do we have the right inputs/ouputs? Will I be able to use it?
2. The contract allows alignement between different members of the team, which is particularly useful when building fusion teams with both business and IT expertise.
3. While implementing the brick, the contract ensures that behavior of the brick is well defined. This is particularly important if the actual implementation is performed by someone with potentially less functional understanding, e.g. in a nearshore development team.

DRY - Don't Reinvent Yourself

Bricks are meant to be reused. Useful functionalities can therefore be used multiple times within a given project, or even reused for across different projects.

Reuse bricks across multiple projects

POINT TO HOW TO REUSE A BRICK ACROSS MULTIPLE PROJECTS

Encapsulate functionalities

Bricks by essence encapsulate a set of functionalities. It is therefore recommended to have well defined bricks rather than having large components providing a mixed set of functionalities.

Test visual components and logic bricks

POINT TO HOW TO BUILD A SMALL APP TO TEST A BRICK

Refactoring & MVC

Like in traditional programming it is very common to attach logic directly to visual components. For example we may put all the logic directly on the On Click of the button. This can be made more modular, maintainable and reusable by wrapping the logic within a brick, which is then called when clicking on the button.

Extract logic from a component

POINT TO HOW TO USE PROMOTE

Split a visual component into smaller pieces

POINT TO HOW TO USE DUPLICATE, REFINE, REPLACE

Check where a component is used before refactoring

Use Groups for layouting

Vertical, horizontal, mosaic, spacing

Using HTML/CSS

Static formatted text easily provided using some HTML/CSS rather than by concatenating multiple labels and other visual components. Label and Show Alert Dialog are examples of bricks that support raw HTML/CSS content. Other UI bricks also support some degree of customizability via their CSS property.

PUT SOME SCREENSHOTS

Reusable texts

One can build a library of reusable texts using Enums. This can be used to define common JSON strings for use in e.g. API calls, or to be reused in popups, error messages and labels. Wrap it into a brick to provide a nice editor.

Dialogs and popups

Different bricks depending on use case:

• Dialog
• Show Alert Dialog / Confirm / ???

Use Data Types

User multiple applications

Makes it easier to serve different types of users (e.g. main app + Admin App for data loads, reporting, configuration, tweaking stuff without giving access to DRAW)

UI vs. Functional refactoring

promote vs. duplicate & erase