using mocha/chai/sinon for node.js unit-tests? check out my utility: mocha-stirrer to easily reuse test components and mock require dependencies
http://www.bredemeyer.com/links.htm
http://perfwork.wordpress.com/
http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html
http://en.wikipedia.org/wiki/4%2B1_architectural_view_model
http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/examples/four_plus_one_view_of_arch_9A93ACE5.html
export const GoogleApi = function(opts) { | |
opts = opts || {} | |
const apiKey = opts.apiKey; | |
const libraries = opts.libraries || []; | |
const client = opts.client; | |
const URL = 'https://maps.googleapis.com/maps/api/js'; | |
const googleVersion = '3.22'; | |
let script = null; |
Whenever we're dealing with web pages, we say that our browser (i.e. Chrome) is the "client" and the process running on the computer connected to the internet that sends a web page in response to the browser's request is the "server".
Remember that a server is just a process that sends data in response to certain requests. It knows how to respond to requests because the request is formatted using the HTTP protocol (and likewise, the client knows how to receive it because the response also adheres to the HTTP protocol). The computer running the "server process" exposes that process to the internet so that people can make requests to it.
At Fullstack, we like to say that the server is somewhere far away, like "Norway". This is because when you write your own server programs, they'll be running on the same machine as your browser, but this won't be the case in real life!
pragma solidity ^0.4.10; | |
// Enables event logging of the format `console.log('descriptive string', variable)`, | |
// without having to worry about the variable type (as long as an event has been declared for that type in the | |
// Console contract. | |
contract Console { | |
event LogUint(string, uint); | |
function log(string s , uint x) { | |
LogUint(s, x); |
// Cartesian product of arrays | |
// @takes N arrays -- arguments *must* be arrays | |
// @returns an array of X arrays of N elements, X being the product of the input arrays' lengths. | |
function cartesianProduct(...arrays) { | |
function _inner(...args) { | |
if (arguments.length > 1) { | |
let arr2 = args.pop(); // arr of arrs of elems | |
let arr1 = args.pop(); // arr of elems | |
return _inner(...args, |
If you work across many computers (and even otherwise!), it's a good idea to keep a copy of your setup on the cloud, preferably in a git repository, and clone it on another machine when you need.
Thus, you should keep the .vim
directory along with your .vimrc
version-controlled.
But when you have plugins installed inside .vim/bundle
(if you use pathogen), or inside .vim/pack
(if you use Vim 8's packages), keeping a copy where you want to be able to update the plugins (individual git repositories), as well as your vim-configuration as a whole, requires you to use git submodules.
Initialize a git repository inside your .vim
directory, add everything (including the vimrc), commit and push to a GitHub/BitBucket/GitLab repository:
cd ~/.vim