| # 0 is too far from ` ;) | |
| set -g base-index 1 | |
| # Automatically set window title | |
| set-window-option -g automatic-rename on | |
| set-option -g set-titles on | |
| #set -g default-terminal screen-256color | |
| set -g status-keys vi | |
| set -g history-limit 10000 |
| # to generate your dhparam.pem file, run in the terminal | |
| openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048 |
| # Building static nginx for teh lulz | |
| # | |
| # basic dependencies | |
| sudo apt-get install libxslt1-dev libxml2-dev zlib1g-dev libpcre3-dev libbz2-dev libssl-dev | |
| # download nginx and openssl | |
| wget http://nginx.org/download/nginx-1.5.6.tar.gz | |
| tar xf nginx-1.5.6.tar.gz; cd nginx-1.5.6 |
RDBMS-based job queues have been criticized recently for being unable to handle heavy loads. And they deserve it, to some extent, because the queries used to safely lock a job have been pretty hairy. SELECT FOR UPDATE followed by an UPDATE works fine at first, but then you add more workers, and each is trying to SELECT FOR UPDATE the same row (and maybe throwing NOWAIT in there, then catching the errors and retrying), and things slow down.
On top of that, they have to actually update the row to mark it as locked, so the rest of your workers are sitting there waiting while one of them propagates its lock to disk (and the disks of however many servers you're replicating to). QueueClassic got some mileage out of the novel idea of randomly picking a row near the front of the queue to lock, but I can't still seem to get more than an an extra few hundred jobs per second out of it under heavy load.
So, many developers have started going straight t
A lot of these are outright stolen from Edward O'Campo-Gooding's list of questions. I really like his list.
I'm having some trouble paring this down to a manageable list of questions -- I realistically want to know all of these things before starting to work at a company, but it's a lot to ask all at once. My current game plan is to pick 6 before an interview and ask those.
I'd love comments and suggestions about any of these.
I've found questions like "do you have smart people? Can I learn a lot at your company?" to be basically totally useless -- everybody will say "yeah, definitely!" and it's hard to learn anything from them. So I'm trying to make all of these questions pretty concrete -- if a team doesn't have an issue tracker, they don't have an issue tracker.
I'm also mostly not asking about principles, but the way things are -- not "do you think code review is important?", but "Does all code get reviewed?".
| // ES6 version using asynchronous iterators, compatible with node v10.0+ | |
| const fs = require("fs"); | |
| const path = require("path"); | |
| async function* walk(dir) { | |
| for await (const d of await fs.promises.opendir(dir)) { | |
| const entry = path.join(dir, d.name); | |
| if (d.isDirectory()) yield* walk(entry); | |
| else if (d.isFile()) yield entry; |
| #crontab -u root -e | |
| # m h dom mon dow command | |
| #*/1 * * * * /bin/sh /opt/code/cron.sh > /dev/null 2>&1 | |
| count=`ps -wef|grep sbin/nginx |grep -v grep |wc -l` | |
| if [ "$count" -eq 1 ]; then | |
| echo "The nginx process already run"; | |
| else | |
| echo "Start the nginx process now:" |
| # Hello, and welcome to makefile basics. | |
| # | |
| # You will learn why `make` is so great, and why, despite its "weird" syntax, | |
| # it is actually a highly expressive, efficient, and powerful way to build | |
| # programs. | |
| # | |
| # Once you're done here, go to | |
| # http://www.gnu.org/software/make/manual/make.html | |
| # to learn SOOOO much more. |
