There is a chapter called ‘ninja code’, which is full of terrible advice. A small example.
> The ideal name for a variable is data. Use it everywhere you can.
There is one small comment at the top of the chapter, which says ‘Irony detected’. Is there really a whole chapter written Ironically? It would be very easy to read this and think it was real advice.
(And if it is real advice, and I’m completely misunderstanding, then I can’t possibly recommend this book).
I understand that often subtleties of language, particularly when it comes to irony or sarcasm, can be lost in textual content (particularly supposedly-formal content like educational materials), and that generally this is something to be avoided.
However, after reading that chapter, I really can't help thinking that you simply weren't paying any attention.
It's not just written in sarcastic tone (something that yes, could be easy to miss for many), but it's also littered with active dissuasion and explicit explanations of the pitfalls of using this style.
Examples:
> If you write like that, a developer who comes across this line and tries to understand what is the value of i is going to have a merry time. Then come to you, seeking for an answer.
> A quick read of such code becomes impossible. And when there’s a typo… Ummm… We’re stuck for long
> A fellow programmer who wants to work with elem in the second half of the function will be surprised… Only during the debugging, after examining the code they will find out that they’re working with a clone!
> First, the code becomes longer and less readable, and the second, a fellow developer may spend a long time trying to figure out what the underscores mean.
You can argue that the chapter is inappropriate, but I don't think you can reasonably argue that it's misleading.
I think that page would benefit to first more clearly define what a JavaScript Ninja is and why it's good for you to become one. Something along the lines:
"A JavaScript Ninja writes code that is brilliantly mysterious. When people read such code it should induce confusion and if at all possible, fear. Clarity is for the feeble. Obviousness is overrated. Obfuscation and secrecy: that is the way of the Ninja. So, how do you become a Ninja?"
> There is a chapter called ‘ninja code’, which is full of terrible advice.
How someone interprets a tongue-in-cheek chapter could be a good litmus test of their reading comprehension, grasp on the fundamentals, and (last, but not the least) basic sense of humour. I’d hate to see it removed.
If someone takes this section literally, I would be immensely curious how they reconciled in their mind that advice with what they (supposedly) read in preceding sections.
I've been following a local-first methodology without realising it for an app that I've been developing. It's a workout-tracking app called harder better faster fitter. It's designed for mobile use in the gym.
At the moment the app is a local only service and there aren't any backups. Next year I plan to add a backend. I'll be keeping some of the ideas in this article in mind. Currently I'm using the browser's local storage api to store data locally. It mostly works, but will be bolstered significantly with a cloud backup.
You can use chrome dev tools. Right click the window and click 'inspect'. In the 'Audits' tab, you can run an audit for accessibility. It runs your website and checks it against common accessibility criteria, giving you a score out of 100.
On a side note, running this page through the accessibility audit, gives a score of 33. Perhaps HN has some work to do on accessibility.
HN it's very obviously bad for accessibility, small click/touch targets, grey-on-grey text with v. low contrast in some situations (by design), poor indent-level visibility. Using 'shade of grey' to convey information is never going to be great.
Table-based layout can screw up screen-readers, I assume it's still 'tabulated but non-tabular'. Way back screen-readers used to assume the first tr contained th even if it wasn't marked up that way.
It would be interesting to hear from people who use assistive tech for HN how much of a problem it causes them in practice.
> It would be interesting to hear from people who use assistive tech for HN how much of a problem it causes them in practice.
I use a screen reader and am a frequent reader of HN. Obviously, much of the site's content is textual - you can't include images in comments AFAIK and it's extremely rare for people to link to graphical content as people often do on Reddit. So from that point of view, the site is an oasis away from the often visual nature of the modern web. On the other hand, there is absolutely no way for my screen reader to gauge whether a comment is a child of another, quickly jump past a child thread that I'm not interested in, quickly move up to the parent or grandparent of the current comment, etc.
TL;DR: the content is accessible because it's text, but accessible navigation is non-existent.
Inspired by Sublime Text's interpretation of monokai, I created `vim-monokai-tasty`, a colour scheme for VIM. The plugin includes a matching vim-airline theme and matching lightline.vim theme.
> The ideal name for a variable is data. Use it everywhere you can.
There is one small comment at the top of the chapter, which says ‘Irony detected’. Is there really a whole chapter written Ironically? It would be very easy to read this and think it was real advice.
(And if it is real advice, and I’m completely misunderstanding, then I can’t possibly recommend this book).