carterbryden.com
Dad, founder of approximated.app, developer (usually #elixirlang). Friendly and sincere.
I mostly post about dev, things I'm working on, and stray thoughts about business/work/entrepreneurship.
142 posts
2,472 followers
296 following
Regular Contributor
Active Commenter
comment in response to
post
You can fit so many spinners in this bad boy 🚗
comment in response to
post
comment in response to
post
Bold of you to assume I have anything to do on any night
comment in response to
post
Thanks, and exactly!
A nice side effect is that it tends to result in features that people are more likely to intuitively understand. And in the code base, something other developers can understand more easily.
comment in response to
post
That's a good question! I just assumed they are because that would make the most sense, but I haven't actually used this method to grab events themselves before so I'm not sure.
comment in response to
post
For your use case where you want the events themselves, I'd call the events API and grab those instead, triggered by receiving a webhook.
comment in response to
post
A frustrating but (I've found) more reliable option is to trigger an API call to get the latest data when webhooks come in. Depending on frequency and the situation you can debounce/deduplicate so you're not slamming API calls more than some rate, too.
comment in response to
post
That's probably true, but no, I think I don't think I'd feel right doing that. At the end of the day it's a US corp, with all of the unfortunate things that entails, and I wouldn't want to mislead people about that even by accident.
comment in response to
post
Being Canadian while having a US corporation has been a uniquely tense experience lately, I'll say that.
comment in response to
post
This is in addition to the inbound load balancing we already have, which balances based on region, connection count, etc.
That inbound handles which part of your Approximated cluster a request should go through, and the upstream load balancing decides which upstream to send it to.
comment in response to
post
This is extra handy if you want to have your app running on multiple hosting/infra providers and load balance between them for redundancy, costs, etc.
Or if you just don't want to manage a global load balancer on your own infrastructure (or your provider makes it hard to do).
comment in response to
post
Also, is there anything with liveview that could work similarly? Wondering about ways to have frontend stuff coexist with liveview easier. Maybe the same thing but for event handlers?
comment in response to
post
I can also 100% see even the most experienced people letting their guard down and letting through some real doozie bugs as AIs keep getting better. It's just too tempting to get lax when it can help you do 5x-50x more work. Often work that would have been a brutal grind, too.
comment in response to
post
People should totally mess around with it for fun projects.
But more than that and it's a bit like deciding you don't need an architect or engineer to sign off on a building. It might be standing. It might even look good. But you have no idea if it's safe or what's going wrong underneath.
comment in response to
post
On the flip side, I can't really imagine how sketchy it would be to strictly vibe code something serious with where AIs are at currently. Especially with junior-or-less dev experience.
comment in response to
post
Which is to say that it's a massive boost to productivity for me personally. It's more helpful than time-wasting ~100% of the time now, which I wasn't expecting this soon. I think the larger context window is at least as much a part of it as the model itself.
comment in response to
post
3. Code organization for frontend and components. I'm not sure I have a good solution for this, but when contexts came around for the backend logic it was nice to have some conventional way to organize code, even if minimally. I can still do whatever I want but it gives me some guidance.
comment in response to
post
2. Things like :noreply surfacing in liveviews is not a big deal, but the abstraction should probably remove a few things like that for us. Unless there's some good reason to keep it that I don't know about.
comment in response to
post
Okay I read over the article again once I had some more time and I strongly agree with:
1. JS Interop - hooks are okay, but I try to avoid them as much as possible. The basic alpine-ish JS commands were a nice addition too. What could it look like to have a liveview centric frontend system?
comment in response to
post
That's not to say there isn't a lot that can improve in liveview. It's more that I've seen libraries and frameworks slowly become the thing they were a counter-alternative to, for the sake of adoption. At that point it's easy to become just a worse version of the original thing.
comment in response to
post
The article makes some good points but one pushback:
I get why the framework creators would want more adoption amongst JS devs, but I'm not sure that I do as a user of it, if it means it becomes more like JS frameworks. A lot of the reasons why I like liveview are because of those differences.
comment in response to
post
So you're right, not a pointer in the classic sense ( I don't think?), just clever use of the way elixir processes use memory.
comment in response to
post
I was thinking that too, but apparently because they share the same process they can use the same data structure in memory.
comment in response to
post
My understanding is that it's more efficient than that. Any assigns you pass in from the parent use a reference, so no duplication there, but new assigns that you create in the component itself will use new memory.
comment in response to
post
That's so interesting!
My gut reaction for that would be to use function components for the search bar and table, and have a parent liveview like, say, UserSearchLive that would be responsible for fullfilling the event handlers.
Mostly because then I can avoid managing the message passing.
comment in response to
post
Thanks! What are the criteria you use to decide if a component needs it's own state or event handlers?
comment in response to
post
I'm asking around in a few places, and consistently getting back "Use a live component when it needs it's own state or event handlers", so I think maybe my original question should have been:
What are the criteria you use to decide if a component needs it's own state or event handlers?
comment in response to
post
Okay, that makes sense, but I need to drill down more on this to answer what probably should have been my original question:
What are the things that make you decide a component needs to be stateful (an LC) vs just pulling that state from the parent?
comment in response to
post
My limited understanding of how it works is because screens already have their own polarization layer. By putting another in front of your camera, oriented in opposition, it cancels out specifically the polarized light from the screen, but not all of the other natural or studio lighting.
comment in response to
post
You might need to adjust the color and lighting a tiny bit but it's way less than you'd think. Super worth it to not worry about screen light reflections on glasses, background objects, etc. ever again.
comment in response to
post
The video of them screaming at Zelenski might literally be the most blatantly shameful behavior I've ever seen.
comment in response to
post
Me by the end:
comment in response to
post
Thank you! It took a lot of effort (and tailwind UI) because I have the natural design aptitude of a backend engineer.
comment in response to
post
Age two was *really* hard for us, and I always second guessed everything when sleep/food/anything wasn't going as expected.
Am I doing too much? Too little? Too early? Too late? Is this normal? Is something really wrong? Am I causing it? Comparing against infinite opinions on how it "should" be.