After a few weeks of effort, PixMill 1.0 is now a thing. Why is this important?

Well, thanks to the folks in Cupertino, CA and their Catalina OS upgrade, the house of cards that was my collection of Ruby-language code tools came crumbling down. When I refer to my code in such a manner, I’m not saying that it wasn’t useful or well thought out. Up to the Catalina upgrade, it had served us well for TOCS development as well as other personal outside projects. The issue was that it was not being managed in a formal, standardized way.

The Ruby development ecosystem has defined a code package system called ‘gems’. Each gem contains all of the Ruby and/or C code necessary to implement some sort of functionality. Instead of learning and using this package to manage my tools and libraries, I instead dumped everything into a “special” folder on my (and Paul’s) systems and forced the environment to look there for when needed. For access to other functionality, I used other developer’s gems, some of which were less than well-designed.

The Catalina upgrade broke the Ruby/Pango gem that I had been relying on. I spent about two months of scattered free time trying to debug and fix it to no avail. I had to work on Plan B.

Plan B was the alternative design decision back when I was creating my Canvas code. Plan A was simple: write pure Ruby and use other people’s Ruby-to-C interface gems to access C-based functionality, such as the Cairo and Pango libraries for graphics and text layout. This plan could also be labeled the “lazy” plan. Instead of writing full-fledged gems and writing my own interfaces in C, I opted to rely on 3rd party interface gems, 90% of which I didn’t need. However, it worked, until one of these interface gems died for difficult-to-solve reasons.

PixMill is a full-fledged Ruby gem and replaces the Canvas code in its entirety. Instead of relying on up to six 3rd-party interface gems, the interfaces are written in C and are baked into the PixMill code. By doing the work, we cut down on our vulnerability to poorly-designed interface code. It’s also faster.

Private Gem Server

There is one caveat to all of this: accessibility. Ruby gems can be stored at rubygems.org for public posting and downloading of features and functionality. However, we don’t want PixMill, and other privately-developed gems, to be publicly available. The reasons for this are two-fold: extra support overhead (documentation, etc.) and intellectual property rights. We wrote it; it’s ours.

So, how do we store and download privately developed gems for our own use? We need a private gem server. It turns out that someone created a Ruby gem called “geminabox”. Using this gem on our server, and updating a server access list on our clients, allows us to manage our own set of Ruby gems for design and development. You can see it at rubygems.brickmillgames.com. (Don’t worry. It’s password protected.) While the server code allows for custom configurations, I haven’t gotten around to it yet.

With all this done for the most part, we are able to build TOCS counters on our Macs for the first time since spring.