A story of Moldable Development: styling an error from the build log
We recently got a new error in the build of Glamorous Toolkit. It read like
Error: Expected version v0.8.1839 does not match the actual v0.8.1838.
So, before we addressed the problem, we first took a moment to add a highlighter for this error. Below we see how it looks like in the environment. On the left we have a Lepiter page with the build status. The middle pane shows the stages graph. Selecting a stage shows the steps to the right. Expanding a step shows the highligted console output, with our error properly highlighted in red.
This highlighting helps uncovering the problem faster in future situations. And it took only six lines of code to make it happen. But more interesting is how we got to create the extension.
Take a look at the screenshot below.
On the left we see a view with the console log. On the right, we see the source of the view obtained by Alt+Clicking on the view name. The view defines a text editor with a dedicated styler. Expanding the styler class shows the implementation right in place. And there we see the
privateStyle: method that calls the implementation of our rule.
This is literally the path we took to create the six lines. We saw the problem and we acted right there with minimal friction. The whole exercise lasted minutes.
This is a typical Moldable Development scenario. But I'd like to emphasize another thing. Please take another look at the last screenshot. We see there multiple levels of asbtraction all merged in a single window. There is the concrete log that appears in a projection related to a Jenkins pipeline step. There is the implementation of the view. Then there is the whole styler class embedded in the editor of the view implementation.
Most interesting problems in software engineering require bringing together multiple levels of abstraction. It is the job of the environment to make that seamlessly possible.