Joel Junström

This is terrifying. 30+ minutes! 😳 The point of a stand-up is, if you’re a team that’s working effectively using scatter/gather, at least you’ll have a few minutes to coordinate before the day starts. If that takes more than a few minutes, you’re in deep deep trouble. Among other things, it tells me you’re not communicating at all over the course of the day.

@_swanson Love the inboxes nomenclature here!

@joeljunstrom I don't understand this sentiment though...instead you will couple to your own home-grown, non-standard lifecycle events?

This! But without the coupling to ActiveRecord lifecycle hooks.

@_swanson But in essence I tend to lean towards something like Events.register that hides the Event.create. End result is usually similar but does not require hooks. I do love the look of the more 37signals style. But haven’t worked in a code base that had the constitution to keep it clean

@_swanson Eh I don’t know how twitter works, reply above 🙃

Yep! Or ish. I’ve been in enough situations where backfilling will be needed, someone does something they shouldn’t in prod console or ship code without thinking about the implicit side effects that I think the extra layer of explicit calls are worth it.

Our entire product is powered by these 30 lines of boring Rails code

Ruby might be faster than you think johnhawthorn.com/2024/ruby-migh…

separation of concerns should be about isolating units of behavior, not technologies. we should focus on what a system does—not what it's made of—and colocate areas of a system that will depend on one another when a change is made. the goal is to be able to understand as much as possible about the behavior of a specific part of a system when looking at a cohesive unit.

My biggest gripe with @TypeScript is that while it should follow API design, it often drives it. The beauty of JS is that it enables highly dynamic, flexible APIs that can provide great ergonomics, but TS tends to do very poorly with them so they’re often ruled out. The priority of constituencies¹ is end-users > authors² > implementors > theoretical purity. When designing development tools (whether that is a JS library, a browser, or a web technology), our convenience is lower priority than our users’ convenience², and their convenience is lower priority than their end-users’ convenience. API design decisions should be driven by user needs, not tooling limitations. ¹ #priority-of-constituencies" target="_blank" rel="nofollow noopener">w3.org/TR/design-prin… ² Users of the tool, called "authors" here to distinguish from their own end-users

Error: Hydration failed because the initial UI does not match what was rendered on the server.

FULL SPECTRUM DOMINANCE

LMAO @ThePrimeagen

we're reaching levels of PHP previously unimaginable

I think I figured out how to create responsive type scales with composable CSS utilities, thet lets you scale linearly between exact pixel values (this is important if you want to align exactly with a type scale, rather than just scale type on a case-by-case basis) 🧵

Don't ever just fix a bug. Fix the root cause. E.g., what architectural issues (e.g. too-tight coupling) forced the bug into existence?

@srbaker Can’t go wrong with skylight + sentry. Both gives actionable and understandable information in their respective category

Alright #lazytwitter: I have a Rails app. What are y'all using for error reporting, tracking, etc? If I can have a pony, I'd love something that has breakdown on memory usage and request time. Suggestions?

With the efforts of many great engineers, Rails head is now compatible with Rack 3. github.com/rails/rails/pu… is closed as completed.

@AntlPop Then you need to learn more about Hammarby. Haven’t seen a match that is more bajen in a long while :)

Of all the Stockholm teams, I feel I should support Hammarby, but they're making it veeerrryyyy difficult 🤣