Jake Luer logicalparadox
| #!/bin/bash | |
| IFNET="eth0" | |
| IPNET="8.8.8.8" | |
| PORTS="20 21 25 80 8000 8888 12000 12001 12002 12003" | |
| BANLIST="64.205.0.18" | |
| if [ "$1" = "start" ]; then | |
| echo "Starting firewall..." |
| Stability ratings: 0-5 | |
| 0 - Deprecated. This feature is known to be problematic, and changes are | |
| planned. Do not rely on it. Use of the feature may cause warnings. Backwards | |
| compatibility should not be expected. | |
| 1 - Experimental. This feature was introduced recently, and may change | |
| or be removed in future versions. Please try it out and provide feedback. | |
| If it addresses a use-case that is important to you, tell the node core team. |
The dictionary refers to a Mediator as 'a neutral party who assists in negotiations and conflict resolution'.
In software engineering, a Mediator is a behavioural design pattern that allow us to expose a unified interface through which the different parts of a system may communicate. If it appears a system may have too many direct relationships between modules, it may be time to have a central point of control that modules communicate through instead. The Mediator promotes loose coupling by ensuring that instead of modules referring to each other explicitly, their interaction is handled through this central point.
If you would prefer an analogy, consider a typical airport traffic control system. A tower (Mediator) handles what planes (modules) can take off and land because all communications are done from the planes to the control tower, rather than from plane-to-plane. A centralized controller is key to the success of this system and that's really the role a mediator plays in software design.
In real-worl
Installation commands:
$ wget http://redis.googlecode.com/files/redis-2.4.8.tar.gz
$ tar xvfz redis-2.4.8.tar.gz
$ cd redis-2.4.8/
$ mkdir -p /opt/redis
$ make PREFIX=/opt/redis install
$ cp redis.conf /opt/redis/redis.conf
$ chown -R redis:redis /opt/redis
| // `promise` is some operation that may succeed (fulfill) or fail (reject) | |
| var newPromise = promise.then( | |
| function () { | |
| return delay(1000); | |
| }, | |
| writeError | |
| ); | |
| // If `promise` fulfills, `newPromise` will fulfill in 1000 ms. | |
| // If `promise` rejects and writing to the error log succeeds, |
Just some quick notes on how to create a hackathon, super simple really.
- Prepare one page summary of the event (Name, venue, audience numbers)
- Reach out to tech evangelist from various companies, offer 10 minutes to pitch their APIs (skype or in person)
- Reach out to influential hackers to be judges and includes sponsors
Node.js core does its best to treat every platform equally. Even if most Node developers use OS X day to day, some use Windows, and most everyone deploys to Linux or Solaris. So it's important to keep your code portable between platforms, whether you're writing a library or an application.
Predictably, most cross-platform issues come from Windows. Things just work differently there! But if you're careful, and follow some simple best practices, your code can run just as well on Windows systems.
On Windows, paths are constructed with backslashes instead of forward slashes. So if you do your directory manipulation
| L1 cache reference 0.5 ns | |
| Branch mispredict 5 ns | |
| L2 cache reference 7 ns | |
| Mutex lock/unlock 25 ns | |
| Main memory reference 100 ns | |
| Compress 1K bytes with Zippy 3,000 ns | |
| Send 2K bytes over 1 Gbps network 20,000 ns | |
| Read 1 MB sequentially from memory 250,000 ns | |
| Round trip within same datacenter 500,000 ns | |
| Disk seek 10,000,000 ns |
| var plumbdb = require('plumbdb') | |
| var shp2json = require('shp2json') | |
| var tako = require('tako') | |
| var geohash = require('geohash').GeoHash | |
| var JSONStream = require('JSONStream') | |
| var async = require('async') | |
| var gju = require('geostuff') | |
| var t = tako() |