Huh, quick tell one Musk's DOGE l33t h4ck3ers about reverse proxies, and put all government sites behind one, that looks for those words and returns an error... Error 451 would be the most appropriate!
For bonus, the reverse proxy will run on a system infiltrated by Russian (why not Chinese as well) hackers.
Sure it's offered free of charge -- and immediately next to the big "Download" button is a big "Donate" button.
> Maybe they do actually donate to the project, contribute code, or support in other means.
Maybe instead of shaming, the question is a cue for them to mention one of those things.
---
In the US it's Thanskgiving week. It's nice to give thanks. It can also be nice to give other things -- like support to a project that has saved/made your company non-trivial money. Not required, but nice.
To be clear, I think it would be fair if they answer something like: "I am trying to get my company to contribute... but as my original story showed, my company is pretty shitty at making simple decisions." :)
60M cash loss in 2021, with over $100M stock based compensation expense. Maybe with Phabricator shutting down they'll see more growth but the last time I used Gitlab it was not comparable to Phabricator's (and Gerrit's) usefulness for large orgs. It's more like a Github clone in the way it functions.
On the other hand, I've just spent several more-or-less full-time months taking advantage of the drracket/check-syntax library, provided by the core Racket team.
On the third hand, I spent all that time, so wrt "bus factor 1", there will be no pleasing you. :)
Not sure why you're being down-voted. (As usual here, only clicking a down-vote button contributes little value.)
- You are correct that implementing markdown consistently is hard because there is no real spec. CommonMark is a spec, which helps, but a heroically thorough spec, so it's still not exactly trivial to implement.
- You are correct that markdown can escape to HTML. Indeed certain marketing email "features" probably would do this?
If I am missing something maybe someone could make an actual contribution to the discussion and explain.
In any case I think by far the most important point was made elsewhere: Google AMP is awful for the web and for email, both.
p.s. edit: Actually, I think the even more important point is that anything except plain text email is awful. :) So there, sure, use markdown or org-mode formatting conventions. Humans are pretty good at handling messy human protocols.
There are lIsPs like Clojure that argue (> data functions macros). Although I mostly disagree (for example I love Racket macros), I understand and appreciate the sentiment. I have heard it from other people who have worked with a variety of LiSp code bases over the years. TL;DR: Any form of non-trivial DSL needs supporting materials like documentation and a simple, clear design.
Although it is nice to be able to expand macros, fully-expanded macro-generating macros are clear in approximately the same way as assembly language. It is impressive if you can navigate that, but even more impressive if can manage not to need to do so.
Clojure argues that (> data functions macros), but it still has macros and accepts that they are not only useful, but sometimes necessary. Clojure's core.async would have had to be built into the compiler, if it wasn't for macros. Just because it prefers data to functions and functions to macros, doesn't mean that it doesn't recognise the importance or usefulness of all three.
> lIsPs like Clojure that argue (> data functions macros).
That's not really Lisp related. It's more like how the community likes to see code being written.
For example I would regularly make use of macros to provide more declarative syntax various programming concepts.
There are Lisp dialects which are light on macros and some which are using macros a lot more. For example the base language of Common Lisp already makes use of many macros by providing them to the user as part of the language (from DEFUN, DEFCLASS, ... INCF, upto LOOP).
> Now an assistive technology user has an equal (and maybe even better) conceptual map of the content and actions they can take on this website compared to a non-assistive technology user. They can get a quick overview of everything on the site, easily navigate to the section of the page they want, and quickly find what they are looking for.
Often there's substantial overlap between improving accessibility and helping "power users".
Sometimes that overlap can help convince managers to spend more time on these kinds of features.
(Unless maybe your whole model is herding people to ads or "promoted" stuff.)
The keyboard navigation that is required to support the WCAG spec is greatly appreciated by me, even though I am fully sighted and don’t use a screen reader.
This was actually the easiest way to sell a management on some of the time we were spending making our latest project accessible. We had time allotted for power user workflows. If you’re implementing keyboard shortcuts there is likely something about that particular type of action in WCAG.
Of course theirs more to it than that. One of the hardest things was coming up with a good strategy for handling hover/focus/active states that didn’t look gaudy to management. The new :focus-visible selector can help where it’s supported, but getting our designed to think about these additional states when designing components helped a lot.
Writing about biology, finance, or geology? Shrug.
Dumb filtering is bad enough when used by smart people with good intent.