it's not just mounted iphones. An iphone doesn't fit in the motorcycle mount but an old oneplus does, so that gets mounted and iphone stays in my jacket pocket. Iphone camera is fubar, oneplus is working just fine.
Seems to me like it's ignoring context and indirectly applying literal synonyms in the wrong direction. That is, if screwing->fucking (sorry, it's necessary to make the point) but not the other way around except in one context and screwing can be synonym for tighten something in another context, then bracing->tighten and tighten->screwing, it could have "walked backwards" doing something like brace->tighten->screw->fuck, where the last synonym is not valid in the context where the first synonym could be.
Sorry about language and the poor description; I seem to have an idea of the problem, but it's not my field and have no way of describing it in formal way.
There's a difference between Björn (the name) and björn (the animal).
Capitalization gives additional context in this case, if it were in the beginning of the sentence though, then one would hope it contains other clues as well
Onyx Boox are basically android tablets with e-ink that you can enable Play store on.
I tried a couple of display models in stores and it seems quite responsive. Couldn't justify the price though since I've a backlog of books converted to epub that will take me a decade to get through.
Couldn't we mash something like [flattr](https://flattr.com/) into the package managers ( npm, pip, cpan etc.)?
That would give the companies/users an option of regularly contributing a fixed budget to x FOSS projects without having to track down who/where/how for each dependency. The org collecting the micro payments distributes once a month to project maintainers with commit privileges.
For static libs, the project maintainers recursively use the same mechanism, the money trickles all the way down the dependency tree.
Ha - I find unsubstantiated, parroted mantras like this to be a team lead smell :)
In the same way that Agile development has become a mindless cult of rituals that has little to nothing left of the original manifesto's vision, code reviews peppered with thoughtless "code smell" comments have become the bane of development.
Indeed on a code review that kind of comment is bad. We have sonarcube for that kind of nonsense.
The reviewer should explain why, and ideally show how it could be done better.