The other day, I decided to start up a side project to write an app for my Stars Without Number game in Darwino. Like back when I wrote a forum/raiding app for my WoW guild, I like to use this kind of opportunity to try new technologies and flesh out my skills in existing ones.

One such tech I've had my eye on for a bit is JNoSQL, which is a framework for integrating with NoSQL databases in Java. It's along the lines of Hibernate OGM, but intended to avoid the pitfalls of the relational/NoSQL that came with trying to adapt JPA directly to NoSQL databases. JNoSQL promised to be much easier to implement for a new database, so I decided to give it a shot.

JNoSQL

JNoSQL is split into two paired components, cleverly named Diana (the driver side) and Artemis (the model/integration side). The task of writing a driver for a new database is pretty well-contained: pick the database type(s) you want to implement (out of key/value, column, document, and graph) and implement about half a dozen interfaces. This is in stark contrast from when I took a swing at writing a Hibernate OGM driver, where the task was significantly more daunting. The final result is only ten Java files, with a chunk of them being utility classes for code organization.

It's a young project - young enough that the best version to run right now is 0.0.4-SNAPSHOT - but it functions well and it's been taken under the wing of the Eclipse foundation, which builds some confidence.

Implementation

Though the task was small, there were still a couple initial hurdles to getting going.

To begin with, I decided to start with the Couchbase driver - this certainly made the overall task easier, since Couchbase's semantics are very similar to Darwino's, but it also meant that I had to be wary of which parts of the codebase were really about implementing a Diana driver and which were Couchbase-isms. Fortunately, this was much easier than the equivalent work when I adapted the CouchDB Hibernate OGM driver, which was a sprawling codebase by comparison.

More significantly, though, it's always tough coming in to modify a codebase written by a single person or small team and learning as you go. The structure of the code is clean, but not quite my normal style (in part because Domino kept me from diving into Java 8 streams for so long), and I also had to ramp up quickly on the internal concepts of Diana. Fortunately, this was mostly easy, since the document-DB driver scaffolding is purpose-built, the hooks are straightforward and the query semantics were extremely easy to adapt. The largest impediment was getting used to the use of the term "Document", which internally refers to a key/value pair, while "DocumentEntity" is closer to the expected meaning.

Like the core implementation, the test suite I adapted from Couchbase was also pleasantly svelte, covering the bases without being an onerous nightmare to convert. Indeed, most of the code I added to it was the Darwino app scaffolding just for the test runtime.

Putting It Into Practice

Once the driver was written, I was hit by a bit of a personal curveball when I went to implement some actual data models. The model side, Artemis, is heavily wrapped together with CDI, which is a Java EE thing that, as I gather, handles managed beans, separation of implementation, and variable injection. This is a pretty normal thing for Java EE developers, but XPages's "don't call it Java EE" environment didn't introduce me to this aspect. As such, the fact that the documentation just kind of casually tossed around CDI terms and annotations threw me for a bit of a loop trying to determine what was what was required and what was just an idiom.

I eventually determined that I could use the reference implementation, Weld, without necessarily going whole-hog on Java-EE-everything. I'm a bit wary of what this bodes for whether I'll be able to use JNoSQL in Darwino on mobile devices, but I'll cross that bridge when I come to it. Once I got a bit of a handle on what Weld is and how to use it in unit tests (hint: make sure you have beans.xml files!), I was able to start writing my model objects and testing them.

Doing It Again

The fact that the bulk of my implementation work ended up being on the app side with CDI goes to show that the Diana driver model really shines. It got me thinking about how difficult it would be in the future, say to write a driver for Domino. There'd be some hurdles - Domino's lack of nested objects and antiquated querying mechanisms would need replacing - but the core task wouldn't be too bad. I don't know if I'd have a need for it, but it's nice to keep in mind as potential future small project.

All in all, I'm optimistic about the use of this. I'd love for Darwino to integrate as smoothly as possible into whatever standard environments it can, and this is one more step in that direction. I'll know as my side app takes shape how much this ingrains itself into my actual work.

Since the end of the year is a good time for recaps, I figured it could be fun and useful to look back to see how my development workspace and habits changed over the course of the year. One of the recurring pleasant side effects of working on Darwino is that it provides opportunities to dive into a wide array of tools and techniques, though my normal XPages development improved a bit too.

Eclipse Still Reigns

My primary IDE of choice remains Eclipse on the Mac. I've tried to like IntelliJ - I really have - and using Android Studio has given me a bit of appreciation for it, but the combination of inertia, its features, and the fact that IntelliJ feels more alien on the Mac have kept me with Eclipse. I do keep checking every milestone release notes page to see if they've improved the process of working with Tycho-based projects, though.

Text Editor Brawl

I've been a TextMate user since about when it came out, but the slowdown of development has taken its toll, and my eyes have started to wander. Its main replacement so far has been Sublime Text, which essentially feels like a snappier and more-modern TextMate, and it's suited well enough - I'm using it to write this post, for example. In recent weeks, though, I've also finally started giving Visual Studio Code a trial run for a React app I'm writing. Unsurprisingly, I'm finding it quite pleasant, and it's making a good play to take over as my default in the future.

The Markdown Editor Search May Have Reached Its Conclusion

The Darwino user documentation is written with Gitbook, which uses Markdown, and so I've been looking for a while for a comfortable environment for writing it. Each of the programmer text editors has good syntax support, and TextMate did some inline formatting, but the ones I use seem to either lack an inline preview pane or have one that doesn't work quite like I'd like. I used Haroopad for a while, but development petered out, and it was time to find another. I've recently found Typora - I'd thought at first that its semi-WYSIWYG editing in a single pane wasn't what I wanted, but it surprised me: it's outstanding. I have a few minor gripes, but I think I'm sold (or I will be once they release a for-money version).

Issue Trackers Remain Weird

I've gone through many iterations of how to track to-dos and issues for projects, and I've gone all-in on using integrated issue trackers in Git repos when available. The experience is never perfect, though: I don't like using browser tabs for these, but none of the native apps do quite what I want. One of the kickers is that not all of my projects are on GitHub, so either I need to check in two places or use something that bridges the gap.

Eclipse has Mylyn, which integrates with both GitHub and Bitbucket, but it's always a little janky about it. It does the job, though, and for a good while my solution was to have a separate Eclipse installation running geared entirely to issue tracking - no IDE functionality enabled, just a single window with the list of tasks. That worked kind of well, and I may return to it, but it never felt quite right.

For now, I've settled back on splitting up the two - checking Bitbucket via the web and using Ship as a mostly-native client for GitHub. The Ship UI is excellent enough to overcome my retience at the split workflow - the handling of milestones, Up Next, and whatnot make it a joy to use.

Aging Hardware Bristling With Drives

My main development machine remains the Late-2014 iMac 5K, which is nervously eyeing the iMac Pro page, but I've augmented it with a refurbished ThunderBay 4 mini to house my workspaces and VMs. I'll likely eventually convince myself to buy an iMac Pro, but for now this machine is still doing its job nicely.

Similarly, my gaming PC is still chugging along in its crazytown new case, and I've recently had a wild hair to cram it full of hard drives and group them with Storage Spaces. It's proving to have turned into a pretty nice NAS-alike and a capable workhorse for Plex serving, VR, and general gaming.

On the Chopping Block

I have a spate of apps that I use that I would love to trim down or replace if I can do so. Prime among those is Slack; while I like Slack for chat rooms better than the old standby of Skype, I'm hardly the first to notice what a hog it is, considering it's just a couple web pages. I've tried out Franz and Rambox a bit to tame the disaster zone of running Slack, Skype, Discord, and Microsoft Teams simultaneously, but they had some showstopping problems of one stripe or another. Still, I don't think the current setup can last another year.

SourceTree continues to be... kind of there. It's taken to crashing randomly every day or so, which isn't a huge impediment to working, but the notification dialog may as well say "hey, maybe it's time to give Git Tower a shot".

Parallels is still doing its job as my VM environment, but the advertizing for each successive version gets more and more desperate, and it's really been putting me off. Maybe it's time to make the switch to VMWare, especially since it seems like it took the performance crown in recent versions. Ideally, I wouldn't have to keep Windows running all the time at all, but for now it's a necessity.