Macaroons and Oreos

The Elixir Outlaws now have a Patreon. If you’re enjoying the show then please consider throwing a few bucks our way to help us pay for the costs for the show.

Elixir Outlaws, 01/25/2021

On today’s episode of the Elixir Outlaws, Amos and Sean are going to share their technical knowledge and insight on various topics. Amos has been doing a lot of surface-ui work. The surface is a component library for live view. The surface has some excellent features built-in how they handle CSS. Sean hasn’t looked at the Template: Anchor yet, but he has heard mixed things about many people who feel like the eText templates have improved things.

Episode Highlights
The Troubles with form versus dot form feel like a limitation of the template language should unify those things, says Sean.
JSX - React said you could use HTML moments wherever you want, but we are going to turn them into our DOM construction functions that produce the objects with assigned properties from context, says Sean.
Sean recalls some web framework to underline called nitrogen used when it was called dynamic HTML, a sort of live update type stuff over Websockets.
If you have six elements, six-pointers, and probably at the front of that, you have some metadata, then the thing that follows this block in the OTP case is a tuple, says Sean.
A caveat is a kind of blockchain, because a caveat creates a new macaroon that wraps the old one with a new signature, and then you can add another restriction that wraps that one with a new one, says Amos.
Sean asks, would it make more sense not to put any permissions in macaroons unless you are restricting them to a limited set because the absence of a caveat is access?
Sean inquires, verifying a caveat is just like meeting the signature. If caveat doesn’t apply to an operation being performed, why would that be a problem in application logic?
We are storing passwords in the database, which we don’t need. We can make a macaroon for it and give it a time limit like this macaroon will not be any good after this specific time, says Amos.
Amos is going to store permissions in the macaroons, but he is not going to pull the list of projects out of the macaroon and then pull them out of the database.
The authorization context is not the initial set of facts. It’s the thing you want to unify, especially if there is a caveat for the items.
Sean asks Amos, what are your thoughts about code review, and what do you like or dislike about it? What are you trying to get out of it?
Everybody tends to hit the lowest bar set on a team no matter what. So code review, to me, is a place to try to push that bar up, says Amos.
Sean asks how effective is the code review itself, like the process you implement in your teams? And how often do you catch bugs?
Amos says that he feels like learning happens as long as it’s communication. Typos get caught a lot, especially in the documentation, because if somebody wrote documentation, we can read it in the code review and catch typos.
Reviewing something to understand how our product is put together or how our infrastructure is put together has not been that good for me, says Sean.
As per Amos, if a senior asked the question, a junior will often assume that is how they should go. But once a junior person sees that they know something that you don’t know, it adjusts the power dynamic.
Amos suggests that for a good team, we need vulnerability. And the hardest thing to create remotely is vulnerability because there is a lot of interaction that doesn’t happen.
Amos affirms that if you can’t explain the code in the code review, you probably haven’t done it well enough for consideration. In his opinion, people don’t spend enough time on code reviews.

3 Key Points
A lot of the JSX - React projects Sean had to interact with use Storybook, and Amos creates examples for each of your components, and it is a good thing that helps them with documentation.
Authorization is always contextual. When you want to compare or make an authorization decision, you have to look at the context that Sean is trying to authorize and what rights have been granted.
Code review is for both sides of the reviewer and the person or people whose code is being reviewed as it takes vulnerability on both sides.

Tweetable Quotes
“When you are a property type, and you have a component, you can define properties, and you can say whether they’re required or not.” - Amos
“If I have to debug something, I look at a record. When you are debugging, it is because you don’t know what’s going on.” - Amos
“If someone tried to navigate to the URL without the macaroon, they would just get denied, and that would be a perfect use case for macarons.” - Sean
“With datalog in Prolog, you can declare things that look like functions in datalog, usually called facts or functors, and they have nobody.” – Sean
“Celebrate failures that create learning. You don’t celebrate failures if you keep continuing to have the same one over and over.” - Amos

Resources Mentioned:
Podcast Editing
Elixir Outlaws: Website