create different ssh key according the article Mac Set-Up Git
$ ssh-keygen -t rsa -C "your_email@youremail.com"
<?php | |
$data = (object)array( | |
"html" => "<foo bar=\"baz\"/> &", | |
"arabic" => "العربية al-ʿarabiyyah, IPA: [æl ʕɑrɑˈbijjɐ], or عربي ʿarabī", | |
"hebrew" => "עִבְרִית, Ivrit", | |
"chinese" => "汉语/漢語 Hanyu; 华语/華語 Huáyǔ; 中文 Zhōngwén", | |
"korean" => "한국어/조선말", | |
"japanese" => "日本語 Nihongo", | |
"umlauts" => "äüöãáàß", |
create different ssh key according the article Mac Set-Up Git
$ ssh-keygen -t rsa -C "your_email@youremail.com"
package main | |
import ( | |
"container/list" | |
"flag" | |
"fmt" | |
"io" | |
"io/ioutil" | |
"log" | |
"net/http" |
package main | |
import ( | |
"database/sql" | |
"errors" | |
"fmt" | |
_ "github.com/bmizerany/pq" | |
"os" | |
"regexp" | |
"strings" |
var collectionNames = db.getCollectionNames(), stats = []; | |
collectionNames.forEach(function (n) { stats.push(db[n].stats()); }); | |
stats = stats.sort(function(a, b) { return b['size'] - a['size']; }); | |
for (var c in stats) { print(stats[c]['ns'] + ": " + stats[c]['size'] + " (" + stats[c]['storageSize'] + ")"); } |
Hi there!
The docker cheat sheet has moved to a Github project under https://github.com/wsargent/docker-cheat-sheet.
Please click on the link above to go to the cheat sheet.
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:
This is the follow up to a post I wrote recently called From Require.js to Webpack - Party 1 (the why) which was published in my personal blog.
In that post I talked about 3 main reasons for moving from require.js to webpack:
Here I'll instead talk about some of the technical challenges that we faced during the migration. Despite the clear benefits in developer experience (DX) the setup was fairly difficult and I'd like to cover some of the challanges we faced to make the transition a bit easier.
A running example of the code from:
This gist creates a working example from blog post, and a alternate example using simple worker pool.
TLDR: if you want simple and controlled concurrency use a worker pool.
const {PassThrough} = require('stream')
const fs = require('fs')
const d = new PassThrough()
fs.createReadStream('tt2.js').pipe(d) // can be piped from reaable stream
d.pipe(process.stdout) // can pipe to writable stream
d.on('data', console.log) // also like readable