Jan 21, 2017 at 8:03 PM
I read an article where someone suggested programmers are more like carpenters than engineers. I'm not sure there are easy analogies here, but programmers are definitely not "Carpenters" implementing a project from plans. There are almost always a bunch of different ways to solve a given problem and while there are guidelines we all try to follow, there are many techniques and coding styles which are frequently debated with no clear and obvious better method. If I were to compare programmers to any other profession, I would suggest programmers are most like writers.
All of this is a long-digression to avoid thinking about or talking about what's been vexing me. In my case, I decided to do something a little weird and use my primary data-store as the primary interface to the app as well which complicates things further.
My thought was to use the primary data store as the primary interface to the app. It's a tidy solution, but makes planning a little more complicated.
I was using a slug as the identifier and file name for the entries, but I think a cleaner solution is to use a simple descending date/ time file identifier. I've considered a genuine UUID for the file name, but UUIDs are big and randome, date based structures are a bit smaller and by encoding the date in the filename, we get a small amount of crude indexing built in. We'll save the files with milisecond level dates, and take some basic precautions to prevent two files from being created with the same date-stamp.
So in Swift the filename generator would look like this Reference :
<span class="hljs-keyword">let</span> generateFileName = DateFormatter() generateFileName.dateFormat = &quot;yyyyMMdd_HHmmssSSS&quot;
My initial thought was to create subfolders for each year/ month combo so data would have a bit of heirarchy, but I think that's an unneeded complication. It's possible for performance reasons we'll need that kind of architecture, but a folder with hundreds or even thousands of entries is manageable. When we export to HTML, we'll add a bit of structure so URLs can be readable, but for storing the json files it's not really needed.