I haven't tried this yet, but I wanted to say I think there's a lot of potential in this space. There's so much friction with the current popular solutions...and yet it's so hard to justify trying some of the newer and less popular ones.
I wish you luck because there are a lot of good ideas in here. Running locally and remote debugger are the most exciting to me.
I'd argue that Tenerife was due to taking off (in bad weather), not landing. But of course, a bunch of planes landing at the same airport without ATC sounds quite dangerous.
This sounds like a very nice compromise actually. I'm surprised it helped with abuse though, since there's a lot of email providers that are easier to create an account with than gmail.
Well, you have to go out of your way to prevent it. The sub-addressing complexity is on the email provider side; ticketmaster doesn't have to do anything for it to work except not reject valid email addresses.
In my experience, most but not all sites will accept "+" email addresses.
I think that's exactly correct. You either do split queries (with more latency) or you do a join (and risk Cartesian explosion). Most ORMs should do this for you.
I would add that, at least for me, planning each day out is beneficial as well. When I don't have a plan for a day, I often will sit there, not really doing anything, and not sure what to start doing. This typically ends when I get distracted by something (maybe a question on Slack), and overall leads to some very unproductive days.
Even a simple high-level plan, like "today I want to get these tickets ready for review and work on this RFC", is incredibly helpful for me. A weekly plan may be even more effective, but I struggle to plan that far in advance.
This is pretty interesting. It's not like HTTP needs an intermediate representation, but since cURL is so ubiquitous, it ends up functioning as one. cURL is popular so people write tools that can export requests as cURL, and it's popular so people write tools that can import it.
I wonder if that could be because MySQL 8's replication is backwards compatible but MySQL 5.7's isn't forwards compatible. If so, it makes sense that you're only able to move forward.
I'm not too familiar with the details here, but probably hit the brakes and stop ASAP? If there could be someone under my car I wouldn't keep driving to "pull over safely".
Huh, can you explain that a bit more for a rust noob like myself?
1. How does it know how to create your Error enum? I guess it's from the #[from]?
2. What happens if your method tries to return something that's not an io::Error or a gz::Error? I guess the compiler catches that?
3. How would you handle doing this for multiple methods in the same file? Would you rename your enum to DecompError or something to avoid conflicts?