sb8244

That's pretty new in the grand scheme of things? They started making things under their brand once they became established.

I could see Spotify doing the same thing. Particularly around live ticketing, merch, etc.

This is from 2021. I'd be curious if Elixir is still in use, or has expanded at all.

Side note: Pablo's blog posts are always quite good.

I agree big time with this.

Organizing by clean commits is definitely important.

It's not necessarily about the units of code, it's about the bigger picture.

Let's give a hypothetical situation where you split up a PR by the backend and frontend components, but you have some extra fields and endpoints that are not used in your final product. They accidentally get left in because you miss them.

I believe the chance that it would be caught in review is significantly higher in a unified PR review instead of artificially splitting front and back into separate PRs.

And if you need to have the 2 PRs open side by side, then why split it up in the first place?

It's artificial to break up a PR to satisfy the rule of small PRs.

Often you need the full context when evaluating a new feature end to end.

Or you spend 2 days splitting up a PR into smaller PRs so that a person can review it in 30 minutes instead of 2 hours.

I can't say I've ever seen benefit from it both as a reviewer or as a developer, but it could be an effect of different companies and different teams.

I believe that there's certain things (particularly ambitious net new feature development) that isn't served well by artificially minimizing PR size.

You should absolutely strive to keep smaller PRs, but I've frequently seen this become "you should only have small PRs."

That's my big question here. If I don't claim an r&d tax credit, does the salary still get treated as r&d?

True, I used a vanilla wysiwyg editor integrated via hooks.

To be clear, I heartily endorse LiveView. Not using it now due to pretty heavy chrome extension needs, but it was solid. It's just rough in the "just works JS integrations" department. I'd argue you have to be really good at JS to handle any heavier library integrations.

Mongo appears to have a decent driver for it. I'd lean to that if i were looking for an alternative to SQL.

You shouldn't have any issues integrating it into Absinthe, because it doesn't have any ecto bindings out of the box. (There's a helper library, but even that is fairly small.)

I have heard of people using mnesia, but it's not really that common. I'd personally avoid it unless I had a good reason not to.

What about wysiwyg editors? Something equivalent to react-grid-layout? Date pickers? I want to build a startup, not rebuild complex components for the sake of purity.

Simple components are taken care of, but I think that's not where the discussion is very relevant.

I'm sorry to disagree here, but I think it's disingenuous to act like the problem is solved when there's really quite a large gap.

(Btw, of course I built my components with pure LiveView when it made sense.)

I did heavy LiveView development for a while. The library problem definitely exists. It's very rare to find what you want already implemented, so you have to rebuild it yourself. It takes a lot of time.

What I ended up doing was loading react components using LiveView hooks and syncing state using pushed events. Saved me a ton of time because libraries were all there, and worked seamlessly alongside my LiveView app.

Yup! I lean towards a tenant ID approach. I ALWAYS use a library that enforces these tenant checks on queries. Ruby (https://github.com/citusdata/activerecord-multi-tenant) and Elixir (I wrote https://github.com/sb8244/ecto_tenancy_enforcer) are the ones I have experience with.

I'd say it's probably not the typical implementation. Mainly because it's a pain to implement and manage.

I guess that's why this was created though. It's definitely an intriguing tool.

I did shift in past from single database to sharded via citus. The actual migration was smooth, but 6+ months of work went into ensuring compatibility.

There's ways to nearly guarantee compatibility without actually using a sharded approach, like enforcing all tables have a uniform shard key.

I think it's clear they forgot the 0, given that 5*250=1250

Thanks for your work here!

Maybe going outside of engineering?

I use both loom and cmd opt 5, but my CS and sales team would not be able to effectively use cmd5 (editing, hosting, comments, etc.)

The moat for us is that it just works and is cheap enough that moving off is literally not worth my time.

C'mon Atlassian, have the decency to throw another 25M their way...

Do you dislike the tools or dislike the process that gets created around the tools?

I do all of these things with loom today and love it.

I don't think that would've been a good idea. I guess it's possible, but I'd rather trade known obstacles versus unknown obstacles (that will definitely exist).

I said "torn down and built back up" in an endearing way. Sure it was difficult work at times, but it was super fun and we would spend 2 days at a time fixing it until something popped up 6 months later.

But the amount of stuff I learned from that was (I will wager) exponentially more useful than figuring out how to adapt/run a fairly major FOSS.

I was generic in how I described it because I didn't want to talk about the system (it doesn't matter).

The system was for a very specific use case and the set of rules were all specific to that domain. The domain was not related to workload management or jobs, but you could generalize what it did in those terms.

edit: removed some snark. I did want to rewrite this into an in-memory data structure (Elixir-based). It generally worked but the postgres solution was actually really really good for the domain it was built for.

I wrote a system that used the database as essentially a rules engine for "what work to execute next?" There were constraints about max throughput per key, waiting periods, etc.

That system broke me down and built me back up over time. Really deep explaining, understanding the internals of how the data is actually being processed, then finding ways to improve it. I had 1-2 other people who were really interested in postgres that would help work on debugging.

We would continuously get 100x query improvements every time we dove in. Including after we thought we maxed it out.

I hope everyone gets the chance to work on something like that. It was really fun.

You...understand how you can't have one without the other, right?

I strongly agree with you.

I'm fairly involved in Elixir, so I run a risk of catching some frustration for agreeing with you here.

I get why they are going the direction they are, but I think it comes at increased complexity for beginners (that don't want to use LiveView). For example, Phoenix components (which are usable in static server-rendered controllers) live in phoenix_live_view package.

All of that said, Elixir / Phoenix is the best development experience I've ever had and I have no plans to stop using it.

Bad take when the ToS can change on a dime and companies don't give a hoot about retroactive respect.

Another thing with numeric maps is how insert would work. Swapping elements is trivial, but inserting a new one would require rewriting every subsequent entry.

The only time I've hit this is when implementing algorithms that assume constant time access and modification (a lot of algorithms assume this, and can't be swapped for index based maps easily)

This occurred somewhat recently when implementing stable topological sort. I ended up swapping List out for a Vector (Aja is library I used). I received a 100x performance improvement from it.

That's really the only time I've truly hit a List performance roadblock in 7+ years of Elixir.

I'd say most errors I handle are user facing in some way.

The specific error (going to say in response to API given the article) you gave would likely be returned through the system as API response error tuple.

The parts of call stack higher up could determine if they want to show the error or swallow it. If it's a generic KeyError or MatchError, there's a 0% chance anything outside of the immediate call site could handle the error.

Return the error to my user so they can at least see what went wrong with their request (assuming the errors are built to be user facing).

The idea of hiding information from the user, just for me to get it from bug tracking and support tickets is not something I could jive with.

People often take this paradigm too literally, especially if they have not programmed much in Elixir. It is most common to bubble up errors using error tuples, and exceptions are available.

Fred Hebert's blog post called "it's about the guarantees" makes this more clear: https://ferd.ca/it-s-about-the-guarantees.html