As I am writing this, billions of people are urged to socially distance themselves from others. Temporary hospitals are erected. Medical personnel face deadly situations without proper equipment. Factories change to produce ventilators. As physical places shut down, the economy takes a hard hit, too. Unemployment sky rockets. Production drops. People worry. And rightfully so.
We are all asked to do our part and stay home. But, some of us that are more privileged than others: we can work and produce value while being at home. This article is addressed to them. In particular, to those creating software-based solutions.
A few days ago, the governor of New Jersey called explicitly for COBOL programmers to help with the development of the unemployment system during the COVID-19 crisis:
This is how the software environmentalism crisis looks like.
In the software development industry, we focus almost exclusively on building systems. The conversations are dominated by new languages, new frameworks, new deployment options. And the body of software grows exponentially. At the same time, we are unable to remove old systems.
From this perspective, our software industry behaves not unlike the plastic industry: we focus on building without any regards to recyclability…
Databases are pervasive in software development, but more often than not, exploring databases is perceived to be different than typical development and it happens outside of the development environment. We think that this is not reasonable and that it should change.
A while ago we showed how we can accommodate a database exploration right into the Glamorous Toolkit inspection workflow. This also shows nicely that working with the database is not special in any way.
Let’s take the case we used previously with a database including cities with populations and life expectancies around the world. …
To get to moldable content, the frame must not imply a specific structure for the content.
We got to the current tab-based design of Glamorous Toolkit mostly due to the problem of not being able to close a Spotter in a borderless window. In the meantime, we no longer have the Spotter issue, but we still kept the tabs because we realized that we created a frame that knows almost nothing.
It essentially knows a home tab that we can easily mold, a menu that we can make moldable, and a way to search that is already moldable. This is…
We worked on a way to explain that the need for moldability is pervasive in software development, and we came up with this treemap showing all classes from Glamorous Toolkit grouped in packaged and highlighting in blue the classes that define at least one custom view, and in green those that define examples.
This worked nicely. However, we noticed that the user interface got significantly slower when the treemap was displayed. Indeed, a treemap entails potentially many elements, so we expected it to be slow to show the first time, but we did not expect it to slow the whole…
When one looks at Glamorous Toolkit, it’s the shiny interfaces that capture the attention. It’s less apparent that we chose to build our own graphical stack. Building a graphical stack is not a straightforward decision. It is rather costly, especially for a small team, and it comes with high risks and uncertain payoffs. We went this route by going backwards: we imagined a few interfaces, asked ourselves how we’d implement that and the answer was that we need a new stack. So, we built one. Looking back, it was a good decision.
Given that we only had a rough idea…
Nested data structures are ubiquitous in software. Packages, classes and methods are nested. Folders and files are nested. XML elements are nested. Treemaps are useful to highlight occurrences in such nested structures, and they should not miss from a development environment.
Glamorous Toolkit offers treemaps, too. This is a behind-the-scene story of how we constructed this algorithm. The story both sheds a light on how we approach moldable development when we develop Glamorous Toolkit, and it offers an insight on how and why we split the larger logic into smaller parts that can be used for other purposes as well.
Glamorous Toolkit v.0.6.42 brings with it a new native window backend for Mac, an initial Class Coder, extended parsing support, stability throughout the board and in particular in the debugging department, and a few other things.
The initial native window support we announced two months ago felt great both due to separate windows and due to the retina display support. So, we went further and explored a new solution based on the Glutin library. Beside proving to be more stable, it also brings new abilities such as the possibility of having transparent windows.
It currently works reliably on Mac.
Search is a pervasive need in software development. Yet, the typical IDE rarely goes beyond a regular expression queries. We must do better than that.
One of the design principles behind Glamorous Toolkit is that search must be pervasive. It sounds grandiose, but once you setup to do it, it’s actually pretty straightforward.
Let’s start with an example: a search for all methods that are annotated with
<gtView> and that reference the class
How was this realized? On the left, we actually have a Playground with a code query:
#gtView gtPragmas & GtMethodCoder gtReferences
Executing the query opens an…
Example-driven development is somewhat similar to test-driven development, but it differs both in how examples are expressed and composed, and in how examples are utilized both for testing and for documentation purposes.
Let us start from a concrete scenario of modeling a price to fulfill these requirements:
A price can be something like 100 EUR. Prices can be added or multiplied. A price can also be discounted either by a fix amount of money, or by a percentage. All operations can be…
CEO | Software Environmentalist @feenkcom. Making software systems explainable.