When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:
const Article = require('../../../../app/models/article');Those suck for maintenance and they're ugly.
At the top of the file there should be a short introduction and/ or overview that explains what the project is. This description should match descriptions added for package managers (Gemspec, package.json, etc.)
Show what the library does as concisely as possible, developers should be able to figure out how your project solves their problem by looking at the code example. Make sure the API you are showing off is obvious, and that your code is short and concise.
I recently had several days of extremely frustrating experiences with service workers. Here are a few things I've since learned which would have made my life much easier but which isn't particularly obvious from most of the blog posts and videos I've seen.
I'll add to this list over time – suggested additions welcome in the comments or via twitter.com/rich_harris.
Chrome 51 has some pretty wild behaviour related to console.log in service workers. Canary doesn't, and it has a load of really good service worker related stuff in devtools.
| Puts on glasses: | |
| (•_•) | |
| ( •_•)>⌐■-■ | |
| (⌐■_■) | |
| Takes off glasses ("mother of god..."): | |
| (⌐■_■) | |
| ( •_•)>⌐■-■ |
| /* | |
| Demo: https://jsfiddle.net/elky/f6khaf2t/ | |
| <div class="element"> | |
| <div class="truncate"> | |
| Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt | |
| ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco | |
| laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in | |
| voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat | |
| non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. |
Hi Nicholas,
I saw you tweet about JSX yesterday. It seemed like the discussion devolved pretty quickly but I wanted to share our experience over the last year. I understand your concerns. I've made similar remarks about JSX. When we started using it Planning Center, I led the charge to write React without it. I don't imagine I'd have much to say that you haven't considered but, if it's helpful, here's a pattern that changed my opinion:
The idea that "React is the V in MVC" is disingenuous. It's a good pitch but, for many of us, it feels like in invitation to repeat our history of coupled views. In practice, React is the V and the C. Dan Abramov describes the division as Smart and Dumb Components. At our office, we call them stateless and container components (view-controllers if we're Flux). The idea is pretty simple: components can't
| // No Security | |
| { | |
| "rules": { | |
| ".read": true, | |
| ".write": true | |
| } | |
| } |
A list of the most common functionalities in Jekyll (Liquid). You can use Jekyll with GitHub Pages, just make sure you are using the proper version.
Running a local server for testing purposes:
According to the MDN reference, it is:
ECMAScript 5's strict mode is a way to opt in to a restricted variant of JavaScript [sic].
It goes on to say:
I am in the Pacific time zone (UTC -8/-7). Typically, I work from 9:00am - 6pm after waking up at about 5:30am, hopefully with a brief walk around the block, and getting the kids started with their day. I try to take a lunch anywhere between 11:30am and 2pm. Sometimes I'll step away for a short sanity break. Other than that, I'm usually at my desk. At the very least, I have my phone with me.
All that being said, I try my best to stay mindful, wherever I am. When I'm at work, my priority is work. When I'm with family, however, work becomes a close second.
I work from my home office in Anaheim Hills, California.