Brewing Elixirs in the Galley

Hi there!

It's a new quarter so I'm working on a new project! This one will be a rebuilding of my old cooking site Ari's Garden. The new project is tentatively called "Galley". This post is a bit of a long-winded ramble about what I would like Galley to be, the tech it would use, and how it will be different.

Where am I coming from?

What was Ari's Garden and what will Galley be?

This project will be more advanced than Ari's Garden. First off, I want users to be able to contribute their own recipes. Previously, this was not possible; Ari's Garden compiled statically using a mixture of parsing recipes in a .org file, then parsing that org content into JSON, then moving that data into an Elm application that parsed it and spit out a single page application with all our recipes.

Ari's Garden was a fun project and I spent a lot of time on it; from checking my wiki - about 90 hours. A good chunk of that time involved re-aquainting myself with Elm. Each time I return to Elm I find it a bit easier to use, but it often still takes me a bit of time to ramp up to.. I remember I spent a lot of time working on an in-app parser that parsed a special syntax I devised that enabled a recipe's instruction set to render references to ingredient quantities by hovering over it. It was such a small feature, but I spent so long on it! Frankly, I think I was just excited to learn about parsers and try and implement a bit of syntax.

In retrospect, Ari's Garden was a project that I used to encourage myself to try Elm again and to cook more. In that sense, the project was a resounding success!

Where do I want to go?

It's been a few years since I started Ari's Garden. I don't add many recipes to it these days, which is a bit of shame. Like with Ari's Garden, with Galley, I again want to cook more and improve in that realm, but I also want to make cooking easier, and more fun for others. If I can build Galley as I imagine it, it will be useful for other people, and maybe could have a community-oriented ethos to it. How so? Let me daydream about how Galley might be used:

• Galley is invite only (more on that later).
• People can add their own recipes (rather than be a read-only site like Ari's Garden)
• People can use Galley privately to login, pick the recipes they want to make for the week (maybe even have it generate suggestions for them) and then generate a shopping list for that mealplan
• People can rate each other's meals and save/bookmark ones they like
• People can search and find recipes by ingredients they have, helping reduce food waste or unecessary grocery shopping.
• Galley's database can be queried to see which ingredients are most common in recipes to help people new to cooking learn what staples they might want in their pantry.
• People can choose to broadcast what abundances they might have and do food-swaps.

That is a handful of things I've thought of. I think several of the above are "stretch goals". I think the recipe / left-over sharing is a cool idea, but I would never expect it to work right away. But! I will take a moment to digress on some of these community-oriented ideas.

Take the food-sharing-idea. I don't think it would work unless the network of people using Galley is a "closed network" of folks who all know each other in real-life, or through friends of friends. I imagine people (who have not experienced persistent hunger, at least) might have a hard time accepting left-overs from a stranger on the internet. If Galley were to be an invite-only network of people, then I could see something like this being more likely to succeed. In this regard, I was inspired by the closed-network Merveilles mastadon instance - (nb. The name Galley is stolen from the hashtag #thegalley, which folks use to tag food related topics) as well as run your own social. I like the idea of tools that enable community at a smaller level, and of course, don't monitor you, don't tell you what to buy, and don't sell your data.

How am I going to do it?

I'm using Elixir and Phoenix (and LiveView) for this project. I'm convinced this will be a great set of tools for me for a few reasons. First, I'm building a system with a database and user accounts. I want to work quickly, and I think Phoenix will help me accomplish that. Not having to roll a user authentication system will save me a lot of time. Next, I've used Elixir in the past and enjoyed it, and I prefer working in functional languages. As someone who skews toward more front-end projects, I think working within a system like Phoenix+Ecto will help me move faster than if I had to setup all the model/DB stuff from scratch.

I'll write more in the future on how I feel about using Elixir/Phoenix one I've become a bit more acquainted with it.

What's to do?

There's lots to do. Right now I'm acquainting myself with LiveView, Phoenix forms and ecto. I'm currently building up the "New recipe" form, which is going well, now that I understand how "inputs_for" works. I find it interesting to do server side forms, since I joined the world of programming in the Angular 1 days - so, building forms in this "old fashioned way" has actually been a bit confusing to me. I haven't really done that much in Rails and so I'm losing out on the domain/inspiration that Phoenix has borrowed and improved on, and am having to dig around from time to time to understand the common idioms.

Anyway, here's a just a sliver of what's to be done:

• Build the "New recipe form".
• Build a searchable list of recipes for the home page, starting with searching by title.
• Build the "Recipe Show" page with niceties like "per-instruction timers" (I'm excited about this one).
• Hook up object storage on S3 (or whatever) so user's can upload images.
• Make sure user's can only edit their own recipes etc.

How's it going?

So far, so good! Wrapping my head around LiveView was a bit frustrating at first - but I had to read a fair bit of docs/watch videos and poke at code for a while. Now it is starting to feel a bit like React (there is a concept of mounting, and components etc).

It also took me a while to understand how embedded_schemas in Phoenix work. I really like that I can use this feature. I wasn't sure how I would model a recipe table that had N number of steps and N ingredients using a relational db (relational db's are not my strong suit yet!). So, with embedded_schemas I can store a list of recipes and ingredients as JSON in the recipes table. And on top of that, I think it shouldn't be too hard to figure out how to query this nested data if, say, I wanted to know what are the most common ingredients across the all recipes.

So, I'm off to a good start (so long as I don't get side tracked and start trying to build my own mini-syntax and parser again 🙃).

Doubts & Musings

Part of this project-per-quarter challenge is that I also want to write out doubts. Self-doubt is common, and I want to be transparent and honest about that with myself (and any one reading this!)

I've seen a few other projects where programmers have looked at something like cooking and recipes and devised their own method for wrapping the "problem" of cooking into a program that simplifies it. In some ways, I feel like I'm falling into a trap of using programming to smash "problems" into something I want to work with. In the process of taking on this project, I have wondered to myself if I'm overoptimizing something that maybe I should just enjoy and not document or turn into a project. Maybe I should just keep the world of cooking separate from the world of programming!

On the other hand, making a project like this is likely going to help me get back into cooking, which will inevitably improve my quality of life. Ah well ¯_(ツ)_/¯.

That's it for now! As always, thanks for reading.

o/

WT