Bookish Development Diary, episode 5.
It’s been quiet around here over Christmas, and I cut myself a bit of slack and didn’t really do a lot last week, but I’m back to it now.
Pretty much the last decision I made before the holidays was that I needed to develop some basic view classes for use with Datastore, and that they should live in a companion module (called DatastoreKit), as another published product of the Datastore package along with the Datastore module itself.
I also decided that this should go hand-in-hand with a test application, which is a separate project and a client of both Datastore and DatastoreKit.
Bookish Development Diary, episode 4.
A tale of how the last version of the Datastore was just right, but it turns out that the latest version is even righter.
As I mentioned in a previous post, I really enjoy the way an API evolves as one slowly figures out what it is supposed to do.
This process is continuing with Datastore, the database backend that I’m using for Bookish.
It’s perpetually humbling to realise just how unfinished that thing that you thought was finished actually is. For instance: it turns out you actually need API to delete records - who knew? 1
Something that I particularly enjoy is the moment where two concepts/classes/algorithms that you thought were separate reveal themselves to be two aspects of the same thing.
This seems to be happening with Datastore…
-
I might have fogotten to add one in earlier versions of the API. :facepalm:. ↩
Bookish Development Diary, episode 3.
In which our intrepid developer disappears down a deep rabbit hole, in search of the cleanest and most idiomatic way to express string constants in Swift1. Because, you know, stuff…
Sometimes it’s the little things that make me happiest.
In an open-ended system like Datastore, where any property can be assigned to any entity, I needed to be able to specify a property using some sort of key.
It turns out that there are a few ways of doing this…
-
If you’re a sophisticated user of Swift, none of what I’m about to say will probably come as a surprise. You may be bored or underwhelmed by this tale. Sorry! In fact, maybe you know a better solution? If so, please let me know. The solution I describe is was one of those things that I had to puzzle out over time when I started writing Swift - mostly by seeing other code that looked cleaner than mine, and figuring out what the difference was. I’ve been meaning to write it down explicitly for a while. ↩
Bookish Development Diary, episode 2.
One of the devevelopment tasks I enjoy most is designing then implementing a new module. The smaller the module, the more self-contained the job it is tasked with, the cleaner and simpler the resulting API, the better.
Perhaps that’s the reason that I allowed myself to be distracted by convinced of the need to develop Datastore, my generic data storage layer for Bookish…