sgrytoyr

Joined 17 years ago

Karma
561
Submissions
53
Member since
Mar 23
[ my public key: https://keybase.io/stiang; my proof: https://keybase.io/stiang/sigs/3KdtyDrN1CFbdooN7Wt6enBEiuFk2LMjlUz8MdBR9Xk ]
View on Hacker News

Recent submissions

Comment · 1 year ago
If they could add support for remote development (meaning the claude code instance runs on the remote server in the same folder that you have already opened as a remote/ssh project in Zed) and add a way to paste images in Zed and have them interpreted by CC on the server, this would really be a killer feature.

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.

Comment · 4 years ago
Heh, I do know that to some extent, but I feel like it’s a different issue. We are all submitting sensitive data all the time, and trusting that whatever service we are using (and the services they in turn are using) will handle our secrets responsibly.

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.

Comment · 4 years ago
Appreciate the perspective. I do realise that HAR files are very useful, if for nothing else than being able to rule out any client-side issues. However, I don’t agree with their decision to make it impossible to get something looked at without HAR files - especially when there is a legitimate consern that they may contain highly sensitive data (even after their tool’s automated cleaning) and for something that is almost certainly a backend issue.

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?

Comment · 5 years ago
Thanks for the pointers and insights. I’ve been reading up on this tonight (local time), and this whole issue seems to be mostly a misconception.

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.

Comment · 5 years ago
Almost every time I see a discussion about LiveView there’s someone complaining about the issue of latency/lag, and how it makes LiveView unsuitable for real-world applications.

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!

Comment · 5 years ago
Totally agree.

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.

Comment · 5 years ago
Comment · 8 years ago
Since the benefits seem to be linked to ketosis, I believe we’re talking about fasts longer than 1-3 days, since that’s typically how long it takes to reach ketosis. So anywhere from 1-14 days, I would think.
Comment · 8 years ago
Hi HN! Creator here. Happy to answer any questions you might have. All kinds of feedback is much appreciated!

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.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton