Presently:

• Just reviewed the rough cut of the Code BEAM Stockholm Lite vlog. I really like it.
• Preparing a local meetup again. Actually just setting a date and going "we'll do something with Phoenix". Preparing is too much credit.

Library of the moment

icalendar
github | hex

By Gleam language creator Louis Pilfold. Kudos to fazibear for the recurrence stuff.

Note: The library is in maintenance mode only. Eventually if someone needs it to evolve it should probably be forked but it has worked nicely for me.

The iCalendar format is the successor of vCalendar and it is how we structure calendar data for use in calendar apps and such. This is how we interoperate. And I have used this for my eInk calendar gadget that I showed work on in this livestream. I also use it in my very unfinished Stream Deck Plus automation application. Anytime I want to consume calendar information it is there for me. It doesn't do anything weird or unique. It is just a very useful utility and I think too few people leverage their calendars enough.

A good design is costly

Erlang has a good fundamental design. It makes intentional trade-offs. It gains some super-powers, it pays with some drawbacks. Iterating on it has also made things a bit messy overall. LiveView has a good fundamental design. Getting the details right with forms, components and so on has been kind of a steady but somewhat messy process and it is not quite done there.

It is important to have well-designed abstractions for the things that are infrastructure to the work we are doing. Those designs are almost never entirely formed up front and then implemented. They were developed over time but have been around long enough to become assumptions. TCP, HTTP, WebSockets, sessions, cookies. Some of them aren't actually well-designed and we swear about them and make do. But overall many of these designs fade into the background.

When sitting down to build something out it often makes sense to sketch out a design idea on paper. Schemas, how data flows, verbs operating on the schemas, what UIs we expect to need. I would rarely recommend detailing these up front. Sketch. Then try it.

If you start detailing up front you get into things like which components the UI should have and how those are abstracted. And you get into this way before any assumptions have been poked by the reality of implementation.

I was pairing with a really technical client who is also really backend-focused (hello!) on building out a LiveView UI for an application and he mentioned he had taken a crack at the idea before and tried to figure out what components were needed and all that. He found my approach interesting (he didn't seem horrified either). I took a distinctly worse-is-better approach. I'd describe it as Keathley-esque (as in the other Chris). I did have a module full of verbs from previously so much of the "business logic" was a already "abstracted". Well, it was implemented at least.

I had previously started the UI because there was a lot to decide on. I had brought in Tailwind UI templates in straight HTML, adapted them to our case but everything was hard-coded and fake text data right in the template. And nothing in the template was componentized. It looks a right mess.

But then we fixed and refactored it. Right?

Right?

Well, it isn't fully implemented yet. Also, no. And I don't think we will until we see a second page that has the same needs, which might be never.

The next step was to start loading data into the LiveView as needed and replacing the hard-coded data with the actual data. Bring it to life. Then we started wiring up buttons to actually performing their actions. Make it interactive. And on we went. We found what is probably the trickiest part of the page where depending on user choice we will need a form to change shape and use different validations. We ironed out a reasonable approach to that. That ended up being a bit of a design, to make the complexity of that fade into the background. It was found through iteration.

It was very productive and I think the template would drive some people insane, and some would find it perfectly cromulent.

We didn't know the exact design. We didn't invest time in pinning it down before-hand. We laid the tracks as we needed them and now have something working and know a lot more about the problem. If needed we can iterate this design to be cleaner but that adds cost without necessarily adding value. This is a leaf node of the system. This is something people use and all underlying layers serve it. It might never need to fade into the background by means of a thoughtful design. It rests within good designs. And if anyone needs to change how it works? All the parts are very much localized to this LiveView, there will be very little hunting around for what you are trying to do. It is all right there.

This is not the one approach for everything. There are times where upfront architecture and requirements can be necessary. It was a good session though. It felt productive and enjoyable. I have no concerns about returning to that code to keep working at it.

How do you figure out a new feature? Reply to this email or poke me on the fedi @lawik@fosstodon.org.

Thank your for reading. As always, I appreciate your attention.