This gist is updated daily via cron job and lists stats for npm packages:
- Top 1,000 most depended-upon packages
- Top 1,000 packages with largest number of dependencies
- Top 1,000 packages with highest PageRank score
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).
(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.
[ | |
{name: 'Afghanistan', code: 'AF'}, | |
{name: 'Åland Islands', code: 'AX'}, | |
{name: 'Albania', code: 'AL'}, | |
{name: 'Algeria', code: 'DZ'}, | |
{name: 'American Samoa', code: 'AS'}, | |
{name: 'AndorrA', code: 'AD'}, | |
{name: 'Angola', code: 'AO'}, | |
{name: 'Anguilla', code: 'AI'}, | |
{name: 'Antarctica', code: 'AQ'}, |
⇐ back to the gist-blog at jrw.fi
Or, 16 cool things you may not have known your stylesheets could do. I'd rather have kept it to a nice round number like 10, but they just kept coming. Sorry.
I've been using SCSS/SASS for most of my styling work since 2009, and I'm a huge fan of Compass (by the great @chriseppstein). It really helped many of us through the darkest cross-browser crap. Even though browsers are increasingly playing nice with CSS, another problem has become very topical: managing the complexity in stylesheets as our in-browser apps get larger and larger. SCSS is an indispensable tool for dealing with this.
This isn't an introduction to the language by a long shot; many things probably won't make sense unless you have some SCSS under your belt already. That said, if you're not yet comfy with the basics, check out the aweso
Ideas are cheap. Make a prototype, sketch a CLI session, draw a wireframe. Discuss around concrete examples, not hand-waving abstractions. Don't say you did something, provide a URL that proves it.
Nothing is real until it's being used by a real user. This doesn't mean you make a prototype in the morning and blog about it in the evening. It means you find one person you believe your product will help and try to get them to use it.