And for me, one mediocre tool that works everywhere for everything beats a better tool that requires me to context switch too often, so I mostly retired Plantuml. Not happy about, but alas.
687 karma · joined April 29, 2022
And for me, one mediocre tool that works everywhere for everything beats a better tool that requires me to context switch too often, so I mostly retired Plantuml. Not happy about, but alas.
I like that you're going for one generic syntax instead of many specific ones, like mermaid and Plantuml, but it's as much as a pro as it is a con, it's one reason why these languages evolved in the first place, instead of everyone just using DOT. One possible mitigation would be some sort of reuse mechanism? Some way that generic nodes could be defined once and instantiated many times, so if I wanted to draw something like a sequence diagram, I could define/change my participant lanes just once.
Another issue the "No multi-line statements, no line continuations, no blocks." philosophy. I get *why* you chose it, and has its advantages, but it's a pretty annoying constraint, specially if one wants to have longer node names, or have more detailed description of the node in its label, like listing the responsibilities of a class, for instance. "No blocks" is something that can probably won't make much difference, but line continuations (i.e., some distinction between physical and logical lines) can make or break the user experience, IMHO
The syntax for line breaks is another thing I urge you to reconsider, '/' is waaay to common of a character, and being forced to write long strings in a single line can get *really* annoying. Some sort of multiline string support would really make your existing syntax shine.
The last two suggestions/complaints would complicate your parser a lot, specially since you're writing it manually, so, they are trade offs, but as a user who'd love to have something like this on my toolbelt, not having these features would make me hesitate a lot on investing time in this tool.
That said, it's a nice idea, I'll keep an eye on it =)
I like the "moonshot research" framing, in particular, because it highlights that even negative results will be valuable, either as improvements for ground technology or as published data to inform other initiatives of what has already been tried and failed.
I think that's plenty evidence, I'm not waiting for him to tatoo "I am a fascist" on his forehead.
Also, a minimum awareness of the politics of the people producing the stuff you use is actually pretty necessary when fascism is on the rise all around the world. Might be exhausting, sure, but it's better than the alternative
The only way to stop an oppressive government from abusing the emergency notification system for propaganda is to fight against the oppressive government until it stops existing, then keep fighting to prevent it from existing again.
A vaccine is an objectively better solution than PrEP, just because of the time scale, PrEP needs discipline on a daily or x-monthly basis. A vaccine could last for years. Although, realistically, it's more likely to end up requiring yearly updates like COVID, because HIV is also a mutating son of a bitch.
I 100% agree that waiting for a vaccine is stupid beyond measure. The world should do both: make PrEP widely available AND keep funding vaccine research.
Come on, two levels ain't enough for anything serious. Also, the notes feature is not rendering any differently.
Ah, yes, finally gitlab will have the same uptime leves as GitHub.
Side note, Jesus Christ on a bicycle, this site has a ridiculous amount of ads. Literally could not read the article at the first try, had to reload and enable reader mode before the 1937391 popups started jumping on my face.
For instance:
> "The caching layer is causing a 400ms overhead on cold requests. Here's the trace."
Cool, but how do you know that? Are you sure you're interpreting the trace correctly? How many measurements have you done? Sure that there isn't a historic reason why the caching layer behaves in this way, or a conflicting requirement that lead to choosing this latency over some other, worse consequence?
In the same way:
> "The current error handling swallows exceptions silently, which is making debugging hell. We should propagate errors to the caller"
Agree in principle, but did you check git blame to see if there was a rationale? Or asked someone else? How much change would this require? Could it break consumers of our code?
Granted, the "polite" messages didn't care any of this information either, but at least they didn't almost preemptively shut down the conversation by laying down what is at best an well informed guess and at worse purely personal opinion as if it's irrefutable truth.
Perhaps instead of debating whether to be (too?) polite or direct, it's better to focus on providing as much information as you can, anticipate follow up questions, and close with clear actionable next steps, something which is also missing from both versions of the messages.
"Well, those are hypothetical examples" cool, another evidence that we're all talking out of our asses about the sex of the angels, here. Maybe if the author didn't try so much to characterize themselves as perfectly infallible information delivery machine, then I wouldn't have nit-picked so much their half-assed hypotheticals.
One (I think?) bug report and one suggestion:
- bug: can't get past the 5th project on mobile, whole screen just go black and I have to reload the page. - suggestion: maybe make cd ~ or something like that bring the user back to the actual initial state, with the login banner and stuff. Just running clear results in an empty shell, and the user has to remember to run help again.
P.S.: I ran the secret command. You son of a gun XD
P.P.S.: Two suggestions, actually: display your CV with pdfjs or something, or make an HTML version. It's annoying to have to download files.
I'm not sure I can trust the author's characterization of Roy, though. I got the impression that they don't like any of the people they interviewed (which, you know, fair), but that doesn't get even close to the depths of hatred towards Roy that they sub-textually exude throughout the article.
If their portrayal is even half accurate, though, that's a perfectly reasonable amount of hate.
Maybe if you read past these paragraph it would have been clearer?