Python and Low-Code Development: Smooth Sailing With Jupyter Notebooks

Editor's Note: The following is an article written for and published in DZone's 2021 Low-Code Development Trend Report.

If you ride on a sailboat in a steady breeze, it glides through the water effortlessly. Few things can compare to crossing a bay without the noise and commotion of a thundering internal combustion engine. 

The dream of no-code and low-code development is to effortlessly glide from problem to solution. Back in the ‘80s, no-code/ low-code development was called “end-user computing.” Since the invention of the spreadsheet, we’ve had a kind of low-code computing. The technologies continue to evolve. 

Let’s take our boat out of the slip and sail around a little. We’ll look at two ways Python is commonly used to create no-code and low-code solutions to problems. 

The first thing we’ll look at is using JupyterLab to create solutions to problems with minimal code. I liken this to using winches to help lift the sails. It’s not an internal combustion engine, but it is a machine that helps us manipulate heavy, bulky items like sails and anchors.

The second thing we’ll sail past is using Python as an integration framework to knit together tools and solutions that aren’t specifically written in Python themselves. In this case, we’re going to be writing integration code, not solution code. This is how sailboats work; given a hull and some masts, you’ll have to select and set the sails that will make the boat move. 

JupyterLab 

As a developer, and as a writer about Python, I rely on JupyterLab a lot. It’s often the tool I start with because I get handy, pleasant spreadsheet-like interaction. The “spreadsheet” feature that I’m talking about is the ability to change the value of one cell, and then recompute the remaining cells after that change. This lets me create elegant, interactive solutions where the bulk of the interaction is handled by the notebook’s internal model: a lattice of inter-dependent cells.

In this picture, we can see the computation of cell 2 depends on prior results in cell 1. I consider this “low code” because there’s a vast amount of code we don’t need to write. The Jupyter Notebook provides us an interactive framework that’s robust and reliable. More important than that, the framework fits the way a lot of people have grown to use computers by putting values into some cells and checking results in other cells. The big difference between Jupyter and a spreadsheet is Jupyter lets us write extensions and expressions in Python.

Recently, I had a boat-related problem crop up that was perfect for this kind of low-code processing. The tank under the pointy part of the boat (the “V-berth”) has a fairly complex shape. The question really is: “How big is it?” The problem is access; I have to make a series of approximations and models. 

I really need a spreadsheet-like calculator, but I need a lot more mathematical processing than is sensible in a spreadsheet. Consequently, let me apologize to any math-phobic readers. This example involves a lot of math. For folks who don’t like math, think of using a spreadsheet where you never looked at the formula in a given column. A notebook can (and often does) hide the details. This specific example doesn’t try to hide the details. 

Here’s an example: https://github.com/slott56/replacing-a-spreadsheet. I want to lift up a few key features of this low-code development approach. I created three notebooks, each of which had a common structure. They all have a collection of measurements as the input. As the output, it reports a computed volume. The rest of the cells provide some background to help me make sure the math is right.

Here’s the input cell’s content in the “prism.ipynb” notebook. This is cell 8. 

measured = { 
   # Forward triangle, in inches 
   "h_f": 8, 
   "w_f": 10 + Rational(1, 2), 

   # Aft triangle, in inches 
   "h_a": 27, 
   "w_a": 48, 

   # Overall length from forward to aft, in inches. 
   "l_fa": 46, 
}

This is a Python dictionary that has a number of input values. This is a bit more complex-looking than spreadsheet cells, making it solidly “low-code” not “no-code.”

The output is computed in cell 10, providing a single numeric result with a format like the following: 

'50 85/88 gallons' 

This shows me that the volume of space, given the measurements, is just shy of 51 gallons. 

The best part about this data is there are two kinds of changes I can make. The most important change is to the measurements, which leads to recomputing the notebook. Anyone who can use a spreadsheet can alter the numbers to the “measured” dictionary to recompute the volume. 

The other change I can make is to adjust some of the underlying assumptions. This is a more nuanced change to the model that is also implemented in the notebook. I find that for a wide variety of problems, a notebook is the place to start. It lets me gather data, formulate alternative approaches to algorithms and data structures, and work out candidate solutions that are richly interactive. 

This is an excerpt from DZone's 2021 Low-Code Development Trend Report.

For more:

Read the Report

The JupyterLab project is like a boat with three masts and dozens upon dozens of sails for all conditions and situations. There are a lot of features that can be used to create interactive solutions to problems. The idea is to write only the code that’s directly related to the problem domain and leverage the notebook’s capabilities to present the solution so that people can make decisions and take actions. 

In addition to the notebook for a low-code interactive user experience, we can look at Python as an engine for integrating disparate applications together. 

Python as Integration Engine

Python’s standard library includes modules to help us work with OS resources, including other applications. Rather than build or modify existing code, we can treat applications as opaque boxes and combine them to create an integrated solution. To a limited extent, integration applications is what shell scripts do. There’s a world of difference, however, between integration with a shell script and integration with Python. Shell scripting involves the almost impossible-to-understand shell programming language. (See this article on replacing shell scripts with Python for more thoughts on this.) 

When we integrate applications with Python, we can easily introduce additional computations and transformations. This can help to smooth over gaps, remove manual operations, and prevent potential errors. 

I’m a fan of code like the following:

command = [
   "markdown_py", "-v", "-e", "utf-8"
]

temp = options.input.with_suffix(".temp")
output = options.input.with_suffix(".html")
params = dict(CSS=str(options.style), TITLE=options.title)

with temp.open('w') as temporary, options.input.open() as source:
   subprocess.run(command, stdout=temporary, stdin=source)

This is part of a larger and more complex script to publish a complex document written in markdown. It has a lot of code examples, which are a lot easier to read in HTML format. I must do some pre-processing of the markdown and some post-processing of the HTML. It seems easiest to execute the markdown_py command from inside a Python script, avoiding a complex python-bash-python kind of process. 

Since I’m not modifying the underlying applications, I find this fits with a low-code approach. I’m using the source application (markdown_py) for the thing it does best — adjusting the inputs and outputs using Python.

Conclusion

We can use Python in a variety of ways. It’s a programming language, so we can build code. More importantly, we can use the vast number of pre-built Python libraries to create low-code solutions. We can use a Jupyter Notebook as a low-code way to create a sophisticated interactive experience for users, and we can use Python to integrate other applications. 

Sailing isn’t effortless. The boat glides only when the sails are set properly, and we keep the rudder in the right position. Just as skill and expertise are required to make a boat move, so too is careful attention needed to write the minimal Python code to solve an information processing problem.