5 principles I learned from Clean Code
This year I got very motivated to improve the code in the project I was working on. The classes were long and methods confusing. I wanted to learn how I could adjust the code so it took me and my…
April 15, 2020
The Bloomreach Experience Manager web application has tonnes and tonnes of configuration which is kept in a series of Yaml files within the project source tree. In addition, content intended specifically for the development environment is also stored in the same way.
When the application starts up locally on your development machine, the configuration and development content is bootstrapped into the local development database. Using the console application to add new configuration, with the auto export function activated, you can save the new nodes back to the Yaml files and check in the changes into your VCS. Neat! The same goes for when you create new content for testing your features during development.
However, after a while this tends to leave you with rather large and unwieldy Yaml files. You can open them in your editor, but having a source file spanning several thousands of lines is of course not a very desirable situation. Ideally, you would like to break them up into smaller units and bring order to chaos by creating a nice structure of subdirectories. I have been there and I have done that, and though the result is pleasing the process of getting there is tedious and timeconsuming.
Wouldn’t it be nice if we had a tool to somehow aid us in this task?
Well, good news everybody!
I have created a utility that does all of the above. It lets you split up large Yaml files up into smaller units and automatically place them in a structure of subdirectories while adjusting the indentation and setting rootnodes as required.
The utility works interactively and presents the structure of your large Yaml input file as a tree. For each node in the tree, you can choose to write out a file at that level in the node structure. The root node for the output file is set automatically and you can choose to keep the suggested output file name or enter a name yourself. Or you can choose to descend into the subnodes and write each of those in its own separate file in an appropriately named subdirectory. In addition, you can globally specify whether to prefix the content of the files with
The effect of the various settings that you change are shown in a preview pane. Here are some screenshots:
You can inspect and set the filepath and checkboxes for further descent for each node individually and then output the whole new structure of Yaml files in one go, or you can tweak the settings for any node and then only write the file for that node.
In addition, you can tweak the syntax of the output with global settings and there is a small wizard for setting the “childnodes in separate files” checkbox in bulk, based on node type or on the depth where the node is.
The directory structure for the output is created in the same directory that holds the input file. Due to the way that the node path is reflected in the output file structure, several additional levels of directories may be created before the actual output files are emitted. For this reason it is probably best to work with a copy of the input you want to split up in a clean and empty directory and then when you are satisfied with the results copy files back to your project directory, starting at the correct point in the directory structure.
The utility is written in Java and uses the Swing library. I looked briefly into going with Java FX but the sheer amount of confusion for the licensing model I encountered and the fact that you need to install additional parts of the Java runtime separately was rather discouraging, to put it mildly.
You can find the source code for this utility together with instructions for building and running here:
The Maven pom is set up to create a “fat jar”, meaning that everything it needs to run (except for the input file) is added to the artifact that is created.
I moved the repository to a new location in compliance with company policy. In the meanwhile, I’ve been working on some issues which were caused by ObjectMapper being too clever for its own good. I replaced jackson with snakeyaml and now the output appears more acceptable to Bloomreach without much need for polishing up after the fact.