#Introduction
So you have a program that is doing bad things and have isolated that to a test case, this guides you though using one of the tools bundled with node-profiler to read the v8 logs.
npm install profiler --from-git git://github.com/wolfeidau/node-profiler.git#updated_v8_to_3.14.5.8
| My thoughts on writing tiny reusable modules that each do just one | |
| thing. These notes were adapted from an email I recently sent. | |
| *** | |
| If some component is reusable enough to be a module then the | |
| maintenance gains are really worth the overhead of making a new | |
| project with separate tests and docs. Splitting out a reusable | |
| component might take 5 or 10 minutes to set up all the package | |
| overhead but it's much easier to test and document a piece that is |
| var express = require('express'); | |
| var taters = require('taters'); | |
| var enchilada = require('enchilada'); | |
| var makeup = require('makeup'); | |
| var veto = require('veto'); | |
| var browserkthx = require('browserkthx'); | |
| var hbs = require('hbs'); | |
| // we set certain settings based on production or not | |
| var kProduction = process.env.NODE_ENV === 'production'; |
Full version out! http://zachbruggeman.me/github-for-cats/
Because cats just wanna have forks.
If you’re a cat, you probably haven’t heard of GitHub. Maybe your human companion has, but they don’t really know how to explain it to you. (Which, as a cat, is extremely frustrating.) GitHub is a website that allows content creators, whether it be via programming, blogging, or issue-reporting, to collaborate together and to learn from each other. It’s powered by a “distributed version control system” called git. A “distributed version control system” sounds pretty complicated, but it really isn’t. What it really means is that lets you, a cat, manage all of the stuff you have made (like maybe some JavaScript?) in one place, and be able to go back in time to see what you did before. It also lets other cats (or maybe humans) see what you’ve done, and help you out with it. This guide will get you introduced to the world of git and GitHub, and it might even
| // Short module explanation // Something to gather my thoughts | |
| // // I think this looks cool. | |
| // | |
| module.exports = the_exported_function // Modules are a function. Always. | |
| // | |
| module.exports.extra = extra // Additional API entry points if | |
| module.exports.other = other // desired. | |
| // | |
| var util = require('util') // Other packages from npm or core | |
| var assert = require('assert') // No comma-first due to lots of |
| <!DOCTYPE html> | |
| <html> | |
| <head> | |
| <script type="text/javascript" src="http://mbostock.github.com/d3/d3.js?1.27.1"></script> | |
| </head> | |
| <body> | |
| <script type="text/javascript"> | |
| var w = 960, | |
| h = 500; |
Locate the section for your github remote in the .git/config file. It looks like this:
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git@github.com:joyent/node.git
Now add the line fetch = +refs/pull/*/head:refs/remotes/origin/pr/* to this section. Obviously, change the github url to match your project's URL. It ends up looking like this:
| for i in $HOME/local/*; do | |
| [ -d $i/bin ] && PATH="${i}/bin:${PATH}" | |
| [ -d $i/sbin ] && PATH="${i}/sbin:${PATH}" | |
| [ -d $i/include ] && CPATH="${i}/include:${CPATH}" | |
| [ -d $i/lib ] && LD_LIBRARY_PATH="${i}/lib:${LD_LIBRARY_PATH}" | |
| [ -d $i/lib ] && LD_RUN_PATH="${i}/lib:${LD_RUN_PATH}" | |
| # uncomment the following if you use macintosh | |
| # [ -d $i/lib ] && DYLD_LIBRARY_PATH="${i}/lib:${DYLD_LIBRARY_PATH}" | |
| [ -d $i/lib/pkgconfig ] && PKG_CONFIG_PATH="${i}/lib/pkgconfig:${PKG_CONFIG_PATH}" | |
| [ -d $i/share/man ] && MANPATH="${i}/share/man:${MANPATH}" |