I used Mnemonix tonight to solve a problem I had with the app I am working on. Mnemonix is a really useful and elegant tool. I put this code

{:ok, store} = Mnemonix.Store.start_link({Mnemonix.Map.Store, initial: %{active_notes: []}}, name: Cache)

in the APP_NAME.exs file and within two hours the job was done. Three cheers for Mnemonix!

Hi Chris, some info about my use case, of which there are two, both in Phoenix – one present and one future.

1. Lookup.

This is an app for storing short snippets of information – from things like the speed of light and Planck’s constant to links to various things I find on the web: political articles, github repositories, articles about code, you name it. Just two fields: title and description. URLs in the description field are rendered as links, e.g, http:foo.bar.io/yada/yada?baz=123 is rendered with link text “foo.ba.io”.

I use Mnemonix at the moment for just one thing: to record a list of IDs of records in the database result from the most recent relevant operation – search, create, edit, etc. In the case of deleting a record, the list is the empty one. This is needed to give the user a pleasant and efficient experience.

I plan to add users and authentication and then put this up on the web for all to enjoy. It will also help me, since I will then have access to my data anywhere there is a connection. I plan to use Mnemonix to hold the user’s JWT authentication token, the id list, and maybe more, e.g, preferences.

The code is at https://github.com/jxxcarlson/lookup_server

2. Rewrite the backend for Manuscripta.io:

http://www.manuscripta.io/

Manuscripta is an app for creating, editing, and distributing lecture notes, although it can be used for other things. For writing techical docmentation (code, math, physics), it uses Asciidoctor-LaTeX (https://github.com/asciidoctor/asciidoctor-latex), of which I am the principal developer.

Here is an example --my course notes – http://www.manuscripta.io/documents/jc.qft?toc

I am a refugee from the Rails world. I used Rails for the first version of Manuscripta, but (a) it was too slow, (b) the code got completely out of control. Partly my fault. It was my first real software development experience. Subsequently I split the app into a REST back end written with Hanami, a Ruby web framework which I really like (http://hanami.org). The current front end is written in Angular1 and I have an Angular2 version in the works. But I love elixir/phoenix and have found the functional programming style to my liking (I used to program in Scheme some time ago). Hence the plan to redo the backend in Phoenix. (1) Above was my starter project to learn Elixir and Phoenix. (I also wrote a command-line version of lookup – https://github.com/jxxcarlson/Lookup)

One challenge (for me) of the backend project is that Phoenix will have to communicate with other processes: ruby for rendering Asciidoc-LaTeX documents into HTML and/or LaTeX, and for converting (when necessary) LaTeX docs to PDF.

I plan to rewrite the front end in Elm, but if you have thoughts on front end technologies, I am interested.

This is probably way too much info, but there you go!

PS – I’ll comment on docs, etc. tomorrow. Late here in Ohio!

I finally found some time to pick this back up again, after a busy few months. v0.9.0 is now released! It’s another small public API change:

• The start_link functions on Mnemonix.Store have migrated to the main Menmonix module.
• The Mnemonix.Store.Supervisor module has been renamed to Mnemonix.Supervisor.

These changes are in service to finally fully hiding the Mnemonix.Store namespace as a private API, making usage of v0.9.0 and above much more resilient to API changes in the future.

Furthermore, the start_link functions in Mnemonix are now furnished by the new Mnemonix.Features.Supervision module, which is also used in the Mnemonix.Builder module. This means if you’re creating your own store modules, you no longer need to implement start_link yourself.

Finally, all functions provided by the Mnemonix.Builder are overridable, meaning if you are fluent in the Mnemonix feature APIs you can redefine them for your custom store modules yourself. This also means if you already implemented start_link yourself you do not need to make any changes.

I know it’s more bookkeeping than exciting features. However:

• It unifies almost all Mnemonix functions and grants them to custom stores. That work should be complete with a final addition of setting a default adapter in the builder, allowing the new functions to move into their own feature and make their way into custom stores. This will be a backwards-compatible change.

• It finalizes the module namespaces for the project’s initial v1.0.0 release, allowing me to make some of the really fun optimization changes with confidence behind Mnemonix.Store.

Also up for the next release is adding warning infrastructure to the private Store API, allowing store implementations to choose to support a feature, even if it is unwise, but emit warnings in the caller when it does so (rather than just having the option to continue or raise). This is in service to allowing stores that you probably shouldn’t enumerate over to be enumerable none-the-less.

For those interested in this project, I’ve just published Mnemonix v0.6.2!

v0.6.1 represents a stabilization of the public interface. Functionally, it’s identical to v0.4.0, aside from adding Mnemonix.put_and_expire/4. However, the internals have been completely re-arranged to use less meta-programming, better module names, and have become much easier to maintain and test.

Consequentially, if you were calling Mnemonix.Store.start_link, you’ll need to update your code to use Mnemonix.Store.Server.start_link with slightly different parameters, and all stores now live under the Mnemonix.Stores namespace, like Mnemonix.Stores.Map. Otherwise everything should function identically.

These breaking changes have enabled a few benefits:

• Navigating the documentation is much easier through better namespaces, and internals have been hidden.
• The functions available on Mnemonix have been split up into different Mnemonix.Features docs for simpler browsing of related functions.
• There are quite a few new ways to manage stores beyond the humble store server:
  • Bring up and manage multiple stores with the new supervisor
  • Describe stores in your application config and have them start alongside your application without writing a line of code
  • Define your own module to interface with stores by using the builder macros

The only reason why this stabilized interface isn’t a v1.0.0 is because I want to co-ordinate an announcement around that release and would prefer having more goodies implemented.

Until then, I’ll just be adding more tests, more features, more stores, and improving performance and error handling around existing ones. Update to v0.6.2 and your upgrade path shouldn’t contain breaking changes until a far-off v2.0.0 release!

v0.7.1 transparently* serializes and deserializes all keys and values in and out of erlang’s external term format for every operation.

This means that you can, true to Elixir’s maps, use any term as a key or value for all Mnemonix operations, including the features beyond Map (currently increment/decrement, expire/persist). Some out-of-memory stores like memcachex threw a fit if your keys or values weren’t strings or atoms; no more.

This also allows you to provide any store type (not just a Mnemonix.Stores.Map) with an :initial map of entries to populate the underlying store with. Each entry of the map is simply serialized and sent to the store before the store becomes available.

This incurs about a 4% performance penalty to common store operations for out-of-memory stores, but that should be mitigated by all the low-hanging out-of-memory-store optimization I keep putting off. In-memory stores skip serialization/deserialization.

* Transparent serialization/deserialization means that:

• Mnemonix users don’t need to know about it, even error messages come out deserialized.
• Mnemonix store developers don’t need to know about it, they don’t have to implement anything or reference the implementation in their store’s callbacks.
  • However, serialization/deserialization logic is an overridable callback so store developers can optimize it if they wish.
  • This is how the in-memory stores avoid the external term format serialization.
  • But no other store callbacks in Mnemonix’s architecture requires knowledge of the serialization/deserialization mechanism.

Really, I’m running out of cool things to implement–I might even get around to those optimizations soon. Although I do have a new programmable mechanical keyboard arriving tomorrow, so all bets are off.