28 March 2017
Pomisos is a desktop productivity app that helps users with elements of the Pomodoro Technique, specifically automating distraction removal (e.g. e-mail clients). There’s more info on the project page, what I’m going to concentrate on here are several thoughts that came up during the app’s development.
While the previous "official" Java desktop GUI framework, Swing, was based on the Publisher-Observer pattern, JavaFX is instead oriented around Properties.
Although superficially similar (they also allow listeners to be added), the crucial difference is the concept of "binding" properties to one another, essentially synchronizing them automatically. This allows for essentially writing GUI logic like a set of logic rules, e.g. (pseudocode) :
selected are both of type
BooleanProperty. What’s more, you can bind multiple properties into complex statements, which essentially allows you to
create dataflows that are updated automatically.
Essentially, the logic starts to look like a declarative stream specification, much more maintainable and convenient than the "Listener Hell" of Swing. It’s a shame JavaFX arrived only when classic desktop apps have already started to go out of fashion.
If you do want to start developing JavaFX applications, however, there’s several libraries that allow to comfortably code using Scala.
The first one, of course, is scalafx, which simply "Scalifies" the API, and adds a convenient DSL for property bindings. The previous example would now look like:
managePane.visible <== option.selected
Even more rule-like!
Another thing is FXML development. FXML works pretty much like e.g. Android’s UI XML files - it allows you to separate
general UI specification (the XML) from your business-logic code (a
Over the last year or so, I’ve been evaluating Gremlin/TinkerPop, specifically the Scala implementation, in a variety of projects. Out of curiosity, I went with it as the DB layer for pomisos, using an embedded OrientDB instance as the storage implementation.
Unfortunately, while the API Gremlin API is almost amazingly intuitive (and the Scala implementation doubly so, big kudos to Michael Pollmeier for his work here), I found the "constant" cost of introducing this kind of abstraction seems to be an overkill for projects with only several, unconected, entity types.
Specifically, the biggest problem was creating generalized DAOs, and attempting to use edges as an Ersatz for trivial relations.
To be clear though: in this case, the aforementioned cost of introduction is comparable to an RDBMs. It’s just that, for projects of scale comparable to pomisos, simple object stores are more than sufficient.
From my observations, it appears there’s a persistent myth that experienced developers somehow create perfect code instantly - like some sort of rainbow-excreting unicorns. I find that exceedingly harmful, since it effectively reduces the amount of code that gets out to the public, due to lowered self-esteem of aspiring devs.
By the way, one of the best things in Clean Code is the part where Uncle Bob shows the continuous process of implementing a simple example, starting from a very messy prototype.
This is exactly why I haven’t squashed the ongoing commits. I think it’s a good idea for there to be more transparency in development of similar-scale projects, exactly because of the learning potential in demonstrating the actual coding process.
That’s all regarding the development of pomisos. Check out the project if you’re interested.
Next time, we’ll go back to streaming and game development!
flatMapcombinators would be a much better fit here, instead of a tailor-made DSL.