In this document I am using Sass's SCSS syntax. You can choose to use the indented syntax in sass, if you prefer it, it has no functional differences from the SCSS syntax.
For Less, I'm using the JavaScript version because this is what they suggest on the website. The ruby version may be different.
| DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE | |
| Version 2, December 2004 | |
| Copyright (C) 2011 YOUR_NAME_HERE <YOUR_URL_HERE> | |
| Everyone is permitted to copy and distribute verbatim or modified | |
| copies of this license document, and changing it is allowed as long | |
| as the name is changed. | |
| DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE |
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.
Sometimes you want to have a subdirectory on the master branch be the root directory of a repository’s gh-pages branch. This is useful for things like sites developed with Yeoman, or if you have a Jekyll site contained in the master branch alongside the rest of your code.
For the sake of this example, let’s pretend the subfolder containing your site is named dist.
Remove the dist directory from the project’s .gitignore file (it’s ignored by default by Yeoman).
| (function() { | |
| // Do not use this library. This is just a fun example to prove a | |
| // point. | |
| var Bloop = window.Bloop = {}; | |
| var mountId = 0; | |
| function newMountId() { | |
| return mountId++; | |
| } |
| /* ******************************************************************************************* | |
| * THE UPDATED VERSION IS AVAILABLE AT | |
| * https://github.com/LeCoupa/awesome-cheatsheets | |
| * ******************************************************************************************* */ | |
| // 0. Synopsis. | |
| // http://nodejs.org/api/synopsis.html |
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
Recommendations of unit types per media type:
| Media | Recommended | Occasional use | Infrequent use | Not recommended |
|---|---|---|---|---|
| Screen | em, rem, % | px | ch, ex, vw, vh, vmin, vmax | cm, mm, in, pt, pc |
| em, rem, % | cm, mm, in, pt, pc | ch, ex | px, vw, vh, vmin, vmax |
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
