And how does that matter? The QR gets read either way.
Less complex QR codes are easier to scan, especially at a distance
Readit Newscbarrick commented on Google shifts goo.gl policy: Inactive links deactivated, active links preserved blog.google/technology/de... · Posted by u/shuuji3
cbarrick commented on Efficiently Generating a Number in a Range (2018) pcg-random.org/posts/boun... · Posted by u/csense
I think the problem with URL shorteners like Google’s that includes the company name is that to the layperson there is possibly an implied level of safety.
Here is a service that basically makes Google $0 and confuses a non-zero amount of non-technical users when it sends them to a scam website.
Also, in the age of OCR on every device they make basically no sense. You can take a picture of a long URL on a piece of paper then just copy and paste the text instantly. The URL shortener no longer serves a discernible purpose.
Shorter URLs mean fewer characters to encode in a QR code.
"Why CI/CD Still Doesn't Include Continuous Documentation?" (current title) is an interesting direct translation mistake, in the question form. I see it often, and it makes sense.
English doesn't have a succinct way to frame the construct. I wonder if this form will eventually become correct.
Alternatives:
"Why (still) doesn't X do Y?"
"Why is it that X still doesn't do Y?"
"Why doesn't X do Y, still?"
All of these are awkward, but more idiomatic. Currently, at least. :)
Nothing about the title seems like an English grammatical mistake to me. In fact, that's how I would say it.
Seems like "still" is an adverb modifying "doesn't". Replacing it with another adverb, like "clearly", in the same position also sounds correct to me.
I am a native American English speaker. I grew up in Georgia/North Carolina, if that is a useful data point.
cbarrick commented on Simon Tatham's Portable Puzzle Collection chiark.greenend.org.uk/~s... · Posted by u/sogen
I discovered these as a child by just combing through the Ubuntu package repositories looking for games.
These days, I play the Android port all the time. It's my go-to to occupy my time on short flights.
Deleted Comment
We have everything as scripts rather than one-liners so they work fine no matter which shell you're using.
In our case, we often have complex decision trees to diagnose issues before we get into the ops. Our playbooks are very thorough with details about all of these debugging techniques.
You can never completely automate the debugging step: it often requires human judgement to direct the investigation in ways that can't really be expressed in a script.
The friction of the shell comes up not in executing the ops, which we do in fact have heavy automation around, but in all the little pieces of debugging has to happen to tell you what ops need to be done.
(If you get paged and the solution is to skip the debugging step and run a script, then why didn't you automate the script so that you don't get paged in the first place?)
SRE running copy pasted commands directly instead of a script or some automation solution? I don't think the problem is the shell...
Insinuating that my playbooks are bad or any other kind of incompetence without actually knowing anything about my service is simply being an asshole.
You should try fish shell. Great user experience out of the box, including history suggestions.
The incompatible syntax of fish makes it a no go for me.
As an SRE, at my day job I often need to copy/paste commands that are generated from a playbook.
Our playbooks use Bash, and in practice Zsh is compatible. But a co-worker using fish often has to manually modify commands before running, and I'm not about that life.
The problem with fish is mostly the different syntax for setting variables and lack of heredocs. Sometimes the string substitution differences come up too.
Deleted Comment