Design notes, technical explorations, and work-in-progress documentation for side projects.
List<Long> interface, but internally it uses a tree of variable word-width segments to improve performance and memory usage compared to an ArrayList. Performance tends to be worse for appends than an ArrayList but better for inserts. Memory usage is significantly reduced, even for incompressible random data where it approaches the memory use of an array of primitive longs (which happens to be the internal representation in this case). There are some performance metrics over at the GitHub repository. My aim is to use this for the internal index representation in CSView, which already uses an earlier version of this data structure. Source code at GitHubPost, the document structure could represent anything from a blog, to a product catalog, to a photo gallery. An initial version was started in 2016, built around similar technology to my blog and several other projects at the time: a Java web service implemented on Google App Engine, using the corresponding Google platform stack including Cloud Datastore. This attempt got fairly far, including document versioning, handling for multiple domains, preliminary hosting payment integration with Stripe, and an approval/publishing workflow. In the end it was the front-end elements which made the idea unworkable.and will be replaced by &, while it is will be replaced by it's. Substitutions will be made one at a time until the message reaches a target length (140 characters by default). If SlimTweet still can't make the message fit, it will start tweaking the Unicode characters which make up your message, without changing its appearance too much. For example, the digraph vi will be replaced by the roman numeral character ⅵ. When rendered in a standard font, these substitutions are nearly inⅵsible. (Currently offline)