rocketraman

You mistake the author's central claim. The central claim is that certain things cannot be taught or even researched if they appear to hurt the feelings of students.

Sex being binary (and the author carefully distinguishes between sex and gender) based on the size of gametes was simply one example. Other examples are discussed in the article:

  - the inability to use the terms male and female
  - fear of mentioning historical figures that are white and male to students
  - teaching the concepts of sexual conflict, kin selection, heritability
  - research about sexual selection and cultural differences
  - NIH is denying scientists access to data if their research appears to be "stigmatizing"

Your focus on one example as the central claim that invalidates the author's thesis seems like a giant evasion of the real issue.

Communication and honest debate about facts and details, such as the ones you bring up yourself, is impossible when the people you are attempting to communicate with don't care about the truth -- they only care about how the words you are using make them feel.

Which is the whole point of the article: when feelings take precedence over truth and knowledge, science is at threat.

There is a no right turn sign on the post to the left of the vehicle just before it begins the turn.

There are always trade-offs though.

1) If you're busy maintaining backward compat, you're not busy building innovative new things -- Microsoft. 'nuf said.

2) You have a built-in excuse to not make your new stuff equal in functionality or greater to the old stuff, because hey, customers can just use the old stuff right? I built some software that talks to O365 Sharepoint. Ok, I have two choices of API: the older Sharepoint API or the newer Graph API. They recommend Graph, ok. Build the product and put it into production. Get a new customer requirement for fine-grained auth, and then find out that Graph doesn't handle fine-grained auth -- only the Sharepoint API does that. Oops. Ask Microsoft when that capability is coming to Graph? No timeline, because the Sharepoint API isn't deprecated.

3) Keeping old stuff working may be easier, but building new stuff is harder because the landscape is muddier -- how many times have you looked at Microsoft docs and found multiple ways to do things with no idea if the docs you're looking at actually apply to the approach you're using now?

I think there are ways to have (mostly) the best of both worlds. Linux does it by bring as much stuff in-tree as they can -- they break compat all the time for out-of-tree stuff. Ever try to keep a proprietary VMWare module building without errors? In-tree KVM never breaks because they're super careful with the ABI. Some languages have explicit mechanisms by which they attempt to keep things current, but make it easier on users -- Kotlin is an example of this [1] but its a young language so time will tell whether they can actually thread this needle. My experience so far is yes, I think they can -- I've updated code from Kotlin 1.2 to 1.3 to 1.4 with relatively little pain.

[1] https://kotlinlang.org/docs/reference/evolution/kotlin-evolu...

Wonderful story. Both the janitor and the CEO epitomize Ayn Rand's "ideal man":

> "The moral issue is: how do you approach the field of work given your intellectual endowment and the existing possibilities? Are you going through the motions of holding a job, without focus or ambition, waiting for weekends, vacations, and retirement? Or are you doing the most and the best that you can with your life? Have you committed yourself to a purpose, i.e., to a productive career? Have you picked a field that makes demands on you, and are you striving to meet them, to do good work, and to build on it -- to expand your knowledge, develop your ability, improve your efficiency?

> If the answers to these last questions are yes, then you are totally virtuous in regard to productiveness, whether you are a surgeon or a steelworker, a house painter or a painter of landscapes, a janitor or a company president."

(HT: http://gusvanhorn.blogspot.com/2019/06/a-janitors-multi-bill...)

Another gotcha with HSTS + includesubdomains is if you have a naked domain e.g. https://example.com redirecting to a www prefix e.g. https://www.example.com, but the server is configured to send the HSTS header for the naked domain.

It's not always obvious because your gut reaction is "oh my web site is on www.", but that misconfigured naked domain redirect might indeed break "randomservice.example.com".

I find the the amount of traffic and comments articles with this message generate quite amusing, given the article can be boiled down to: don't use tools like Cassandra, Kafka, etc. until you've thought through whether they are the right tool for your use case. That last part is often forgotten -- these tools may not always be the right tool for the job, but SOMETIMES they are, regardless of your scale.

Well, duh.

The corollary is: if you're using one of these tools, and you HAVE thought through your use case and reasons, don't get defensive about it. If challenged by those with lesser knowledge after reading an article like this, calmly and rationally explain your reasoning. And like any technology choice, be prepared for someone else to offer another option you weren't aware of, with better reasons.

Again, duh.

Leaving aside the (unconvincing) possibility that Boeing was actively covering up issues (which, if they were, is potentially a criminal issue due to fraud), there is a deeper philosophical point to be made about how people should view industry in the modern world, which includes aviation, but also all other production, ranging from farming and mining, to the manufacturing and use of products, and even to services.

It's easy to point to the various risks and lives at risk, due to the products of industry, such as aviation accidents as well as pollutants and even mundane things like typing on a computer (RSI anyone?).

However, what is often forgotten is all the amazing benefits of this industry -- from being able to fly to anywhere in the world in less than a day at a cost affordable by almost anyone in a developed country to having energy to light and heat our homes and run our medical devices, to the existence of this very forum. It is right and moral for both producers in setting their own safety and emission standards, as well as the state in setting limits on production in the name of "protecting society", to consider these positives as well as the negatives. It is morally right even knowing that not setting these limits higher will result in lives and health lost, because the alternative is, bit-by-bit going back to a pre-industrial society in which humans were lucky to live past 35. The way to achieve setting these limits higher is in fact by becoming richer, such that we can afford the better controls. If the state attempts to too tightly control an industry before it can afford those same controls, it is essentially the same as destroying it, and keeping its benefits from the world forever.

Aviation is an example of this whole process working. It's exactly why aviation has become so incredibly safe, while at the same time becoming ever more economical. Companies like Boeing are to be, overall, praised. When fraud occurs, it needs to be investigated and punished, but that doesn't change the essentially good nature of Boeing.

This comment is profoundly ignorant. You're dismissing her philosophy because of two descriptive words (and not even the best two, which would probably be "rational selfishness"), which you have decided are the "opposite of good" simply because history says they are? That's just an appeal to tradition: plenty of people have been wrong about plenty of things throughout history, especially in the areas of morality and ethics.

You clearly know nothing about Rand's philosophy. You would do yourself a favor to correct that error. Even if you ultimately disagree with her, she has very many intelligent things to say and, if you give her a chance, she will challenge many of your preconceptions about morality, ethics, and their postcursors of economics and politics, and raise the level of your discourse significantly.

Agreed. Microsoft Azure Portal is taking up 934 MB, Gmail is 502 MB, Pocket is 309 Mb. Google Keep takes 180 Mb or so.

You miss the point. I don't think they are acting shitty. They're acting according to what both you and they agreed to in advance. You knew (or should have known) what they were (and were not) going to give you in return for your effort. It's only shitty of them (and illegal) if they don't follow through on that agreement.

Which should have been clear to you when you joined the company and read and signed the employment and stock options agreements (you did read them, didn't you?). If that isn't to your liking, don't work for a startup.

The comparison to kbfs and IPFS seems relatively straightforward based on a cursory reading of the three web sites...

kbfs still stores files, and I still depend on them to keep their service running. kbfs adds key management via keybase, but the file sharing model doesn't seem significantly, or at all, different than Dropbox.

IPFS on the other hand is completely peer-to-peer, meaning I have little control over content I publish. I can publish new versions, but my old content is still on the network, and forever out of my control.

Upspin provides a middle ground by providing a protocol for key management and server lookup. Unlike kbfs, the files live on servers that I maintain control of. Unlike IPFS, I can delete or update content after it is published, as needed.

There was a better story about a printer / print server I remember reading somewhere -- someone here will remember and link it I'm sure. This story is so obviously contrived -- what would happen to the gentleman after his car would not start? By the time he called Triple-A or whomever, the car would start again, so the problem of time would be obvious even to a non-engineer.

Unfortunately, there is indeed a lot of truth to the statement that it is a PR gimmick.

The problem with wind and solar is that they are intermittent. Therefore, Google's consumption at any particular moment in time cannot be supplied solely by these intermittent sources because their energy output never matches current demand (at least until some big honking batteries are built to level this out, for which the tech currently does not exist AFAIK -- no, Tesla's battery tech isn't even close to operating at this scale, though its a small step in that direction).

Therefore, Google must take power from the grid from non-intermittent sources that can ramp up and down based on demand, such as coal, gas, and nuclear. And this fact will remain true, even if Google had purchased wind and solar contracts for total energy many times greater than their total energy use.

So even though they may be purchasing contracts for wind/solar energy that exceed their own total energy use, they still cannot even approach viable operation without access to non-wind and solar sources, so its definitely misleading by Google to suggest they are running entirely on wind/solar.

Furthermore, the excess energy produced that Google purchased, but did not use because of the intermittency issue, actually reduces the efficiency of fossil and nuclear sources. Because the wind/solar energy is loaded onto the grid intermittently, it forces fossil and nuclear to cycle up and down to compensate. Just like city vs. highway driving, this is vastly less efficient.

Every time I hear this, I think "Be a man!" : https://youtu.be/-qtrAMK7_Qk

FYI: GitHub master updated to version 0.1.4, demo (http://demo-ritzy.rhcloud.com/) updated to the same version. New DESIGN (https://github.com/ritzyed/ritzy/blob/master/docs/DESIGN.ado...), INSTALLATION (https://github.com/ritzyed/ritzy/blob/master/docs/INSTALLATI...), and API (https://github.com/ritzyed/ritzy/blob/master/docs/API.adoc) docs. Demo has new controls that use the API. A bunch of bug fixes and improvements esp. around some more complex collaboration stuff e.g. operations that overlap with remote selections and cursors as one example.

Not "hard" as such. Just requires a completely separate code path than the local cursor and selection machinery. That isn't too much of a barrier though... I look forward to its implementation in Prosemirror!

Demo is updated now to fix the newline bug.

> If, on the other hand, you mean showing the cursors from other people working on a collaborative document

This is what I meant. Good that its not very hard. Though I'm curious: how do you know what the "right place" actually is i.e. don't the coordinates of the cursor position depend on the rendering of the text which is under the browser's control?

What about showing multiple selections from other authors like Google Docs (and Ritzy) does?

The primary data structure underneath is a "causal tree" CRDT. However, import/export to a JSON structure representing rich text is the "native" format. Example is the source used to create the text in demo instances of the editor:

https://github.com/ritzyed/ritzy-demo/blob/master/src/create...

Quill is good but not great. I looked at Quill extensively before embarking on writing Ritzy. Its collaboration features are minimal -- as far as I know there is no way to do collaboration across two browsers i.e. there is no working and/or available server-side component to coordinate the OT deltas produced by Quill (both editors have to be on the same page, which is somewhat pointless). I believe the authors were moving towards doing this via compatibility with ShareJS, but never quite got there. Offline support will be a pain to add with OT.

ProseMirror looks cool. I wish @Marijn the best with it! Not sure about ProseMirror's offline capabilities. I hope he adds multiple cursors and selections like Google Docs (and Ritzy).

It does not. See the comments from Marijn above. I don't know anything about RTL/bidi and accessibility, so I'm not sure if these are intractable problems for Ritzy or not.

Yup, I noticed that bug! It's fixed now (https://github.com/ritzyed/ritzy/commit/c42769d27730a11fe0d4...) (demo is not updated yet). It should be easy to add the Mac key bindings -- I need to find a Mac to test on.

Pretty easy! Check out the demo source code: https://github.com/ritzyed/ritzy-demo

Author here. Thanks for posting this. I had posted it earlier as a ShowHN (https://news.ycombinator.com/item?id=10087162), but without much notice, so I'm ecstatic to see lots of comments here. Great feedback.

Some responses to the various comments:

1) This is a very early release. I'm aware of all the missing functionality, and the README is pretty clear about all the missing stuff, including undo/redo, bullets, numbered lists, tables, and more. I don't have access to a Mac, so I wouldn't expect any of the Mac keybindings to work. That should be pretty easy to solve though.

2) Piotrek Koszuliński's article was really eye opening. Being completely new to the field of editors, and even new to Javascript (this is my first major Javascript project -- my background is mostly enterprise Java and some Scala), I defer to experts in this field like Piotrek and Marijn, the author of Codemirror and Prosemirror. I'm honored that Marijn even took the time to comment :-) It's possible that Ritzy could still serve as a useful tool within some narrower contexts that do not require handling the long tail of hard behavior mentioned (accessibility and RTL/bidi). OR, with the appropriate expertise, that some of that functionality could be added. Re. touch interfaces, fair point -- my thought was that could be worked around (e.g. by an alternate native component on touch interfaces that talked the same CRDT language -- I believe that's the approach that Google Docs took with editing Docs on mobile). Currently on mobile, basic cursor navigation by text, keyboard / text input, and viewing others' changes in real-time appears to work pretty well (better than I expected actually!). Selections don't work at all.

@marijn: how difficult would it be to add multiple cursors and selections to Prosemirror? I notice that currently the Prosemirror collaboration demo does not show cursors or selections, which is pretty key to a great user experience.

3) @gritzo (the author of Swarm.js, a key library used in Ritzy) mentions that the implementation uses a JS object for each char. That is true and it's very heavy. My initial goal was correctness and as a POC, with something easy to understand and debug. Optimization can come later, if indeed there is interest in taking this general approach further.

4) Recent changes to Ritzy (not yet pushed to the demo page) make each cursor, line, and selection a separate React component within a hierarchy. This makes navigation, rendering and selections pretty quick. However, the editor has never been tested against documents larger than a few hundred lines. My gut feeling is that the limiting factor right now is not React, but the "fat" CRDT data structure I used. It gets particularly bad when a lot of characters are deleted. There is no tombstone clearing logic yet.

5) It should be pretty easy to strip out the server-side stuff and make it client-side only. You lose the "killer feature" of Docs-style collaborative editing though. The server-side is pretty simple to self-host -- check out the demo source code @ https://github.com/ritzyed/ritzy-demo for an example.

I'll try to get the demo back up and running. Its hosted on the smallest (free) tier of Openshift and I've done zero server-side optimization. I'm sure it didn't take much traffic to kill it. Any other suggestions for (free) hosting for NodeJS projects?

I'll also try to write up a design doc over the next few days for those who requested that / are more interested in those aspects.

Thanks again for all the comments / feedback!

A blog post introducing the project: https://medium.com/@ramangupta/a-new-rich-text-editor-for-th...

I agree completely with your comments about ContentEditable. See https://news.ycombinator.com/item?id=10087162 for my own recent contribution to the rich text editing problem without using ContentEditable.

I would like to introduce the open source Ritzy web-based rich text editor: http://ritzyed.github.io/ritzy/. It is based on React [1] and SwarmJS [2] and primarily intended for embedding into applications to support rich text entry with real-time collaboration. Technically, it works similarly to Google Docs and eschews ContentEditable in favor of a custom javascript-based editor surface and layout engine [3]. As far as I know, this is the first open source implementation of this technique. Please see the project README and source code [4] for more details. Note that this is pretty new and hasn't seen any real-world testing/usage, so there are some known bugs [5] and likely lots of unknown ones as well.

Depending on interest, I am considering offering the editor as a software-as-a-service solution. Because it is intended for real-time collaboration, a server-side component is (currently) required. While a simple implementation is part of the open source project, a more complete commercial service could handle storage, communications, security, availability, and provide a simple but powerful API for developers. The API would allow interaction with client-side editors and the data they contain, including real-time server-side push updates as editor contents change. Please let me know if your company or startup may be interested in such a service.

  [1] https://facebook.github.io/react/
  [2] http://swarmjs.github.io/
  [3] http://googledrive.blogspot.ca/2010/05/whats-different-about-new-google-docs.html
  [4] https://github.com/ritzyed/ritzy
  [5] https://github.com/ritzyed/ritzy/issues