Create a Meteor app and put the client_/server_ files in a client/server directories. Also, create a public dir to save the uploaded files.
# Adapted from the javascript implementation at http://sedition.com/perl/javascript-fy.html | |
# Randomizes the order of elements in the passed in array in place. | |
fisherYates = (arr) -> | |
i = arr.length; | |
if i == 0 then return false | |
while --i | |
j = Math.floor(Math.random() * (i+1)) | |
tempi = arr[i] |
// to install the connect framework, go to your applications directory | |
// and type "npm install connect" in your command prompt. | |
// to launch the webserver, place this file in your application | |
// directory and execute it using "node index.js" | |
var connect = require('connect') | |
, app = connect() | |
, webserver = require('http').createServer(app); |
#!/bin/bash | |
# Performs a dump of target database and compresses result. | |
# Outputs to: $DUMPDIR/$DUMPNAME.tar.xz | |
# Note: Absolute paths are required for use in cron jobs | |
DBNAME=meteor | |
ROOTDIR=/Users/alanning/foo | |
DUMPDIR=$ROOTDIR/dumps |
This gist had a far larger impact than I imagined it would, and apparently people are still finding it, so a quick update:
- TC39 is currently moving forward with a slightly different version of TLA, referred to as 'variant B', in which a module with TLA doesn't block sibling execution. This vastly reduces the danger of parallelizable work happening in serial and thereby delaying startup, which was the concern that motivated me to write this gist
- In the wild, we're seeing
(async main(){...}())
as a substitute for TLA. This completely eliminates the blocking problem (yay!) but it's less powerful, and harder to statically analyse (boo). In other words the lack of TLA is causing real problems - Therefore, a version of TLA that solves the original issue is a valuable addition to the language, and I'm in full support of the current proposal, which you can read here.
I'll leave the rest of this document unedited, for archaeological
Recently when refactoring a Vue 1.0 application, I utilized ES6 arrow functions to clean up the code and make things a bit more consistent before updating to Vue 2.0. Along the way I made a few mistakes and wanted to share the lessons I learned as well as offer a few conventions that I will be using in my Vue applications moving forward.
The best way to explain this is with an example so lets start there. I'm going to throw a rather large block of code at you here, but stick with me and we will move through it a piece at a time.
<script>
// require vue-resource...
new Vue({
I’m looking for any tips or tricks for making chrome headless mode less detectable. Here is what I’ve done so far:
Set my args as follows:
const run = (async () => {
const args = [
'--no-sandbox',
'--disable-setuid-sandbox',
'--disable-infobars',
TLP
, a power management utility for Thinkpads and other laptops, uses tpacpi-bat
script for battery calibration and setting charge thresholds (for Thinkpads xx20 and later), which in turn uses acpi_call
Linux kernel module that enables calls to ACPI
methods through /proc/acpi/call
. acpi_call
can also be used for hybrid graphics switching and other power management tasks.
As explained here and here, a kernel upstream commit made seek support for [procfs
](https://en.wikipedia.org/wiki/