The access control portion is not clear to me: `current_user_organization_id()` where is this reading from? We tried using `set_config` https://www.postgresql.org/docs/current/functions-admin.html and it was incredibly slow, it was not designed for how we were using which was included connection pooling and each query ran a difference "current_user_id" set_config.

After asking myself the same (i guess) it seems like setting a “session” beforehand is the key https://www.postgresql.org/docs/current/sql-set.html

I love tailwind, used in 3 projects in the past 4 years, it’s intuitive, well documented, simple. I don’t miss the days of emotion and styled components where I would have to think of a name for every styled div in the project, with tailwind a container is just a div and a few classes nothing else. Less bike shedding discussion, less brain cycles spent naming things, less time wasted in reviews.

> I don’t miss the days of emotion and styled components where I would have to think of a name for every styled div in the project

I see people mention this issue fairly frequently, and it puzzles me a little. I have never once spent probably more than 1 second thinking about what to name something. Is it actually a blocker for some people? Are you really paralysed by this?

especially since with any decent CSS solution (any css in js, or CSS modules) you can reuse names

Like really, I use Styled Components, just call it a Wrapper or InnerWrapper or Row or whatever and move on

There was a time when BEM ruled (and scarred) the world. But names aren't a problem if you abandon the C in CSS and scope all styles to component.

What I don't understand is why BEM is scarring. If you're talking about the reason or timing something looks different, you must have named it in that conversation. Just use that name.

"When the menu is wide, the items' icons and text should be visible. When it's skinny, only the icons should be visible. This button toggles between them."

    .menu {}
    .menu--skinny {}
    .menu--wide {}
    .menu__icon {}
    .menu__text {}

Or I could just express this in code once - in the spot where I attach the class names to the HTML - instead of attaching class names, just attach styles.

I'd say BEM was a passing fad, but didn't rule the world. I also think tailwind will suffer the same fate, but we'll see how it plays out.

> a few classes

You must be working with very good product owners then. The ones I've worked with love to specify the hell out of every possible detail. Like a web form is their personal HGTV renovation. I tried tailwind once and the classes ended up being an order of magnitude more than the markup. It got hard to read, quickly.

you can use @apply to merge the various utility classes together in to something resembling a name, like

.btn-primary { @apply py-2 px-5 bg-violet-500 text-white font-semibold rounded-full shadow-md hover:bg-violet-700 focus:outline-none focus:ring focus:ring-violet-400 focus:ring-opacity-75; }

But their v3 docs seem to be very against this.

"Whatever you do, don’t use @apply just to make things look “cleaner”. Yes, HTML templates littered with Tailwind classes are kind of ugly. Making changes in a project that has tons of custom CSS is worse."

Reasons:

* You have to think up class names all the time — nothing will slow you down or drain your energy like coming up with a class name for something that doesn’t deserve to be named.

* You have to jump between multiple files to make changes — which is a way bigger workflow killer than you’d think before co-locating everything together.

* Changing styles is scarier — CSS is global, are you sure you can change the min-width value in that class without breaking something in another part of the site?

Yet... my experience using projects that use tailwind is that every button everywhere is styled the same way, but it's repeated in multiple areas. The 'kinda ugly' part, but also... it's repeated in multiple places. Trying to change the universal focus behaviour of buttons in a project like this is hard, because... I can't search focus:outline-none without finding everything that has 'focus:outline-none' on it. I can't just search/replace, because it'll impact other stuff.

So I end up spending way too much time trawling through way too many scattered specific styles all over a codebase, vs having a defined 'btn' style someplace. "well, that's just the project's fault"... possibly, but it seems to be the promoted/preferred/evangelized way of using tailwind, judging by the projects I've had to get involved with the past few years. IME, this approach may have good short term benefits, but poorer longer term maintenance, doubly so when the original people are no longer involved in the project, and outsiders have to come in to deal with it.

I agree with Tailwind's stance on this. You really don't need @apply if you're breaking things down to smaller components. I often see people have things like <ul><li className="long_list_of_classes">text1</li><li className="long_list_of_classes">text2</li>...</ul>. This is where I think we need a linter to warn against things like that. Make those <li>'s a component!

I have bern heavy Tailwind user from before v1. It actually doesnt matter where you make the class grouping. You can make it in your templating language or you can make it in @apply. I prefer @apply because the same grouping can be reused if done correctly. @apply is great.

The reason they are discouraging @appply is because its hard feature to implement and many people dont understand how it works so they get to problems and create issues. It bothers Authors so much they have always been considering taking @apply out but i think they know big chunk of the userbase would leave to different similar project.

Why not just do <ul class="my-class">…</ul> and then apply the styles to ul.my-class > li ?

Wait, what? You want to make every li/dt/etc. component? That's insane.

For buttons, I think the 'blessed' way to do it is to use (react) components and have the tailwind classes encapsulated there. It makes sense; you have a layer of abstraction where the implementation of your theme is in the "lower level building blocks" of your components. (Call it a component library if you want)

I generally only use @apply when there are some heavier external interactive libraries that are hard to style. Like for example if you're embedding markup in your application, and you need to apply a set of styles to the markup it generates, and you can't do that directly in react because you don't control that part.

> I can't search focus:outline-none without finding everything that has 'focus:outline-none'

Would a regex not work? Something like <button[^>]*?focus:outline-none

I generally use tailwind in combination with daisyui, and I don’t think about styling a lot any more beyond choosing the proper theme.

Gave it a go for several projects, but didn't like it... for big projects it gets messy, fast. It also feels like it has become the new bootstrap.

I'm very happy with my current CSS-in-JS workflow. Crafting good old css with LLM help. You just show the LLM a pic, ask for the components.... boom, done (with proper naming, etc)

This is actually one of the main reasons I avoid react when I have the option. Styling in react is terrible, I'll use tailwind with it but only as the least bad option.

If I am using a frontend framework and a build step, svelte and astro are nice depending on the use case. I can style with plain old CSS and rarely have to reach for class names, if you keep components small you can get away with element selectors and let the framework scope styles at build time.

If you are maximizing income, go work for the company that pays you the most. If you consider other things then it's not that simple: * control on which project you work on * choose your cooworkers * choose your office location * return to office policies * choose process and bureaucracies It's about how many degrees of freedom you want.

It’s expensive and it’s good that other options are available, it’s not insanely expensive though, the people that need the upgrade often make 6 figure salaries and can afford the upgrade although they might not like the idea of paying it, I personally hate it but I know when I buy the machine will last me at least 5 years, which is good enough for me.

I took a different route and went with a Framework laptop. I'll be interested to see how long it takes for it to fully ship of Theseus.

my M1 Max cost $7500 three years ago, was looking forward to the M4 Max..... last year. As in, wish the M3 had these specs, specifically 128gb RAM and this memory bandwidth.

This is unfortunately too late, to justify recouping costs and buying a new M4 Max.

Primarily because I would be using it for large language model inference at higher parameters. What's happened in just one year is that LLM's have gotten muuuch smaller. Llama 3.2 3B only takes 3GB of RAM at 8 bit quantizing. And in addition to that, cost per token in the cloud has subsequently plummuted 99.9% too. Its just not economical.

But yes, I could afford it but no longer a justification. My 64GB RAM M1 Max is going to be future proof for a while.

I find the cinebench benchmarks meh, every YouTuber and every publisher uses it, few YouTubers do more of a practical test which is quite more useful. I would like to see a comparison with older models as most people that have an m3 are not considering an upgrade.

Same. For me, I took a program I wrote / am writing that’s extremely CPU and disk intensive, and compared the execution time. It’s 2x faster on an M4 Pro compared to an M1. That’s worth it to me.

It's a fair point, but Apple's also taken a lot of heat for comparing their new models to ancient ones rather than the previous one, so that they can show an even bigger performance jump.

Counterpoint: I see a lot of people in discussion threads talking about if they should upgrade from their M1 purchase. (And I count myself in their number.) It's highly likely Apple knows this, and not too much of a stretch to think they're communicating the number that they think it's important to this customer - how much better it would be if you upgraded today.

It's very predictable at this point that nearly everyone has the same videos, it feels like me trying to not plagiarize Wikipedia in middle school; "I'll change a word here, rephrase a sentence there, done!". Also true in many other content categories, everyone uses the same source material, same review units, same benchmarks, often the same editing style. I'd say it's a negative, but I've been watching less and less of it since noticing the pattern.

I've completed Exercism courses and they are great.

One thing that was obvious to me is that if you want to focus on a specific topic the $15/month subscription is too cheap, you can pay, take the course, cancel because you are done with the course, all within the month.

The other thing that is challenging is that the majority of programmer is either too cheap or "too broke", $15 USD is a meaningful amount of money in other countries with weaker currency, and in countries with strong currency I've met people paying thousands for a university diploma, doing a well paid internship that "could not afford exercism". That's though, I hope I never have to build a business for software developers.

All of that shared experience comes from 3-4 years ago, so prices, models might have changed since that, but if they go under it's sad, their UI and their UX was so clean, fun, interactive, pleasant, etc, it was a joy to study using their material.

Kudos on launching it, I will be trying in a few meetings to see if it goes well, so far I am finding the UI unresponsive, I click and it marks an action item as completed (optimistic update) then it reverts back to unchecked (failed). I asked the assistant what Synergy meant and it just hanged. I liked the use of a fake meeting as an introduction to the product and the action items as an onboarding checklist, I like that you launched with a delete my account as well, most startups take a long time before implementing the exit path.

Thanks! We have some kinks to work out with the intro meeting and its associated action items. Everything associated with the intro meeting is stored client-side hence why action items being marked as complete don't persist. You shouldn't notice any issues like that with real meetings (let me know if you do).

I’ve been playing every day it’s relaxing, quick, fun. I added to my Home Screen so I don’t lose it.

About Fly but not about the GPU announcement, I wish they had a S3 replacement, they suggest a GNU Affero project that is a dealbreaker for any business, needing to leave Fly to store user assets was a dealbreaker for us to use Fly on our next project, sad cause I love the simplicity, the value for money, the built in VPN.

Sounds like you might be interested in the Tigris preview:

- https://www.tigrisdata.com/

- https://benhoyt.com/writings/flyio-and-tigris/ (discussed here: https://news.ycombinator.com/item?id=39360870)

- https://fly.io/docs/reference/tigris/

> I wish they had a S3 replacement, they suggest a GNU Affero project that is a dealbreaker for any business

AGPL does not mean you have to share everything you've built atop a service, just everything you've linked to it and any changes you've made to it. If you're accessing an S3-like service using only an HTTPS API, that isn't going to make your code subject to the AGPL.

Regardless, some companies have a blanket thou-shalt-not-use-AGPL-anything policy.

Some companies Including Google.

I’ve sold Enterprise Saas to Google and we had to attest we have no AGPL code servicing them. This is for a CRM-like app.

Yep, our lawyers say to not use and we have to check components and libs we use too. People are really shooting themselves in the foot with that license.

You assume that people want you to use their project. For MinIO, the AGPL seems to be a way to get people into their ecosystem so they can sell exceptions. Others might want you to contribute code back.

I have no problem with contributing back: we do that all the time on MIT / BSD projects even if we don't have to. AGPL just restricts the use-cases and (apparently) there is limited legal precedence in my region to see if we don't have to give away everything that's not even related but uses it, so the lawyers (I am not a lawyer, so I cannot provide more details) say to avoid it completely. Just to be safe. And I am sure it hurts a lot of projects... There are many modern projects that are the same thing, but they don't share code because the code is agpl.

Sounds more like the license is doing its job as intended, and businesses that can afford lawyers but not bespoke licenses are shooting themselves in the foot with that policy

Exactly. If someone doesn't want to use your software because the copyleft license is stricter than they would prefer, that's an opportunity to sell them a license.

We just won’t use their product. Works as well.

Everyone wins :)

Lawyercats are the worst cats.

> > AGPL does not mean you have to share everything you've built atop a service, just everything you've linked to it and any changes you've made to it. If you're accessing an S3-like service using only an HTTPS API, that isn't going to make your code subject to the AGPL.

Correct, this is a known caveat, that's also covered a bit more in the GNU article about the AGPL when discussing Software as a Service Substitutes, ref: https://www.gnu.org/licenses/why-affero-gpl.html.en

> you could trivially get around the AGPL by using https services to launder your proprietary changes.

This is a very interesting proposition that makes me reconsider my opinion of AGPL.

Anything “clever” in a legal sense is a red flag for me… Computer people tend to think of the law as a black and white set of rules, but it is and it isn’t. It’s interpreted by people and “one clever trick” doesn’t sound like something I’d put a lot of faith in. Intent can matter a lot.

(Regardless of how you see the AGPL)

> Computer people tend to think of the law as a black and white set of rules

I've never seen someone put this into words, but it makes a lot of sense. I mean, idealistically computers are deterministic, whereas the law is not (by design), yet there exists many parallels between the two. For instance, the lawbook has strong parallels to the documentation for software. So it makes sense why programmers might assume the law is also mostly deterministic, even if this is false

I'm an engineer with a passing interest in the law. I've frequently had to explain to otherwise smart and capable people that their one weird trick will just get them a contempt charge.

Even if that wasn't directly targeted at me, I'll elaborate on my concern:

That it's possible to interpret the AGPL both ways (that the prior hack is legal, and that it is not), and that the project author could very well believe either one, suggests to me that the AGPL's terms aren't rigidly binding, but ultimately a kind of "don't do what the author thinks the license says, whatever that is".

On the other hand the AGPL itself is trying to be one clever trick in the first place, so maybe it's appropriate here.

We have an region-aware S3 replacement that's in beta right now: https://community.fly.io/t/global-caching-object-storage-on-...

They're about to get an S3 replacement, called Tigris (it's a separate company but integrated into flyctl and runs on Fly.io infra): https://benhoyt.com/writings/flyio-and-tigris/

Funny you should mention that: https://news.ycombinator.com/item?id=39360870

The dealbreaker should be their uptime and support. They deleted my database and have many uptime issues.

Give us a minute.

This looks promising https://github.com/seaweedfs/seaweedfs

Seaweed requires a separate coordination setup which may simplify the architecture but complicates the deployment.

I would downvote because the person is being reductive, in such a way that you can destroy most joy in life.

Saying software engineering is like woodworking is overly reductive in the same way, point is that humans tend to see too many patterns and similarities even though they aren't really more similar than other things.