sgrytoyr
Joined 17 years ago
Joined 17 years ago
As someone who’s running a development agency I need to have tens of dev environments for different client projects running at the same time, and being able to switch between them multiple times every day (often from multiple client computers), so a remote server is the only way to go–I don’t want all of that stuff running on my Macs.
Nowadays I also have tens of CCs running on the dev server, switching between them using tmux, which works great, but the lack of support for pasting images through the terminal/ssh/tmux has been a real bummer. It would be great if Zed found a way to bridge that gap.
But that stuff is regulated by laws (GDPR etc.) and, at least to some degree, self-regulated by economic principles (leaking passwords or credit cards should be bad for business). More importantly, though, it isn’t in itself a violation of security best practices. You often have to submit sensitive information to live in the modern world.
What is totally unnecessary, though, is for highly trusted services to teach people to share sensitive files unreservedly, just because they are really nice to have during debugging.
Also, it’s not so much that I don’t trust Google to handle the files responsibly, I just think it’s principally wrong to ask customers to send highly technical files (that most people won’t understand the implications of) in this day and age, when everywhere else we are all trying our best to educate people how NOT to get tricked into sharing security credentials and credit card info.
How easy wouldn’t it be to call someone you know are having a payment card issue, claim you are from Google Support, and then ask them to follow the procedure to record a HAR file while they are trying to add a new card, and then send it to some Google-like email? Even though many now have learned that they shouldn’t give out their password to anyone or click random links in emails, I suspect that a huge percentage of people would have no idea of what they just emailed to some stranger in this scenario.
Do we really want the major players to teach their customers that it’s perfectly fine to share whatever with someone claiming to be a support rep? Shouldn’t we be moving in the other direction instead?
Between things like phx-disable-with and phx-*-loading, and the ability to add any client-side logic using JS, there doesn’t really seem to be any limitations compared to a more traditional SPA using (for example) React and a JSON API.
I hope I haven’t added to the confusion about this by bringing it up, I was just very curious to hear your thoughts on it.
From what I understand, the issue is that every event that happens on the client (say, a click) has to make a roundtrip to the server before the UI can be updated. If latency is high, this can make for a poor user experience, the argument goes.
As the creator of LiveView, what’s your take on this? Is it a real and difficult-to-solve issue, or do people just not see "the LiveView way" of solving it?
I think LiveView looks amazing, but this possible issue (in addition to chronic lack of time) has made me a little unsure of whether it’s ready to use for a real project.
Thanks for creating Phoenix, btw!
I have just a few remaining complaints about the language at this point, and Kernel.tap/2 and Kernel.then/2 will solve two of them.
When Jose mentioned a few years back that Elixir the language was more or less "done" or at least stable, and that they would focus on ergonomics and UX going forward, I remember getting a little worried. But I’ve found myself agreeing more and more - there’s not much I miss in the language itself, and projects like Nx, LiveView and LiveBook have shown that it’s an excellent foundation to build very powerful and modern stuff on top of.
Looks like Elixir 1.12 will take full advantage of EEP 54:
https://github.com/elixir-lang/elixir/releases/tag/v1.12.0-r...
Outkit is my attempt to solve outgoing message delivery once and for all. That’s a lofty goal, to be sure, but I’ve spent way too much time setting up the same type of infrastructure many times over, or unsuccessfully trying to trace lost messages, or having to learn a whole new set of quirks when switching from one provider to another. Not to mention the frustration of recreating the same email templates in project after project.
There are existing products that solve some of these problems, sure, but I wanted them all in one package (in addition to some other useful features) and I hope that’s the case for others too.