yarn test --maxWorkers=50% 2>&1 | grep FAIL | sort -u
yarn test --testTimeout=400 2>&1 | grep FAIL
Some of these tests may take some time as they have user interaction.
Build a game inspired by the movie Monsters, Inc. and loosely based on the old PC game Minesweeper.
Create a three-by-four grid of 12 doors. When the user clicks a door, they'll find one of their monster friends. But behind one door is a human sock. These are dangerous and should be avoided at all costs. Finding it means you lose the game.
If the user finds all 11 monster friends without stumbling onto the sock, they win!
Note: SVG files for the monsters, sock, and door have been included for you.
Strongly opinionated set of guides to quickly setup OS X Mavericks for web development. By default OS X hides stuff that normal people don't need to see. These settings are better defaults for developers.
I don't want: any sounds, annoying confirmation dialogs, hidden extensions, superflous animations, unnecessary things running like Dashboard, Notification center or Dock(Alfred/spotlight works better for me).
These are my opinions. Read this document through and pick up the good parts to your preferences.
According to this gist, the modules break-out session at TC39 (a subset of the larger committee) decided to remove the
module x from "y";
This tutorial uses the "Sample hapi.js REST API" project.
Take a look at: https://github.com/agendor/sample-hapi-rest-api/
##Topics
There are a lot of ways to serve a Go HTTP application. The best choices depend on each use case. Currently nginx looks to be the standard web server for every new project even though there are other great web servers as well. However, how much is the overhead of serving a Go application behind an nginx server? Do we need some nginx features (vhosts, load balancing, cache, etc) or can you serve directly from Go? If you need nginx, what is the fastest connection mechanism? This are the kind of questions I'm intended to answer here. The purpose of this benchmark is not to tell that Go is faster or slower than nginx. That would be stupid.
So, these are the different settings we are going to compare:
var _missing= function(data){ return React.DOM.pre(null, "Route not found: "+ data.route) }, | |
_router= null, | |
_started= false, | |
_nextId= 1; | |
function handleRouteChange(container, component) { | |
var routeParams= Array.prototype.slice.call( arguments, 1 ) | |
React.renderComponent( | |
component({ routeParams:routeParams }, null), | |
container |
# Installing graphite dependencies | |
apt-get install -y python2.6 python-pip python-cairo python-django python-django-tagging | |
apt-get install -y libapache2-mod-wsgi python-twisted python-memcache python-pysqlite2 python-simplejson | |
pip install whisper | |
pip install carbon | |
pip install graphite-web | |
# Setup a vhost by grabbing the example the graphite team released on their repo. | |
# In this file, you'll provide the url used to access to your Graphite dashboard | |
wget https://raw.github.com/tmm1/graphite/master/examples/example-graphite-vhost.conf -O /etc/apache2/sites-available/graphite |
This article has been given a more permanent home on my blog. Also, since it was first written, the development of the Promises/A+ specification has made the original emphasis on Promises/A seem somewhat outdated.
Promises are a software abstraction that makes working with asynchronous operations much more pleasant. In the most basic definition, your code will move from continuation-passing style:
getTweetsFor("domenic", function (err, results) {
// the rest of your code goes here.