cyakimov

//npm install b64url
//A signed_request for testing:
//WGvK-mUKB_Utg0l8gSPvf6smzacp46977pTtcRx0puE.eyJhbGdvcml0aG0iOiJITUFDLVNIQTI1NiIsImV4cGlyZXMiOjEyOTI4MjEyMDAsImlzc3VlZF9hdCI6MTI5MjgxNDgyMCwib2F1dGhfdG9rZW4iOiIxNTI1NDk2ODQ3NzczMDJ8Mi5ZV2NxV2k2T0k0U0h4Y2JwTWJRaDdBX18uMzYwMC4xMjkyODIxMjAwLTcyMTU5OTQ3NnxQaDRmb2t6S1IyamozQWlxVldqNXp2cTBmeFEiLCJ1c2VyIjp7ImxvY2FsZSI6ImVuX0dCIiwiY291bnRyeSI6ImF1In0sInVzZXJfaWQiOiI3MjE1OTk0NzYifQ

function parse_signed_request(signed_request, secret) {
    encoded_data = signed_request.split('.',2);
    // decode the data
    sig = encoded_data[0];
    json = base64url.decode(encoded_data[1]);
    data = JSON.parse(json); // ERROR Occurs Here!

bergie

config.json
reading-image.png

sindresorhus

{
	"ad": [
		"42.5000",
		"1.5000"
	],
	"ae": [
		"24.0000",
		"54.0000"
	],
	"af": [

mschoch

#!/bin/sh

# fix permissions (wrong if docker mounted volume)
chown -R elasticsearch:elasticsearch /var/lib/elasticsearch

# now switch to elasticsearch user and run in foreground
echo Starting: /usr/share/elasticsearch/bin/elasticsearch -Des.default.config=$CONF_FILE -Des.default.path.home=/usr/share/elasticsearch -Des.default.path.logs=$LOG_DIR -Des.default.path.data=/var/lib/elasticsearch -Des.default.path.work=/tmp/elasticsearch -Des.default.path.conf=$CONF_DIR $@
su elasticsearch -s /bin/sh -c "/usr/share/elasticsearch/bin/elasticsearch -Des.default.config=$CONF_FILE -Des.default.path.home=/usr/share/elasticsearch -Des.default.path.logs=$LOG_DIR -Des.default.path.data=/var/lib/elasticsearch -Des.default.path.work=/tmp/elasticsearch -Des.default.path.conf=$CONF_DIR $@"

zsup

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
• Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
• Once documentation has been written, development should commence, and test-driven development is preferred.
• Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
• When a feature is being modified, it should be modified documentation-first.
• When documentation is modified, so should be the tests.

dwchiang

# The next line updates PATH for the Google Cloud SDK.
source /Users/dwchiang/google-cloud-sdk/path.zsh.inc

# The next line enables zsh completion for gcloud.
source /Users/dwchiang/google-cloud-sdk/completion.zsh.inc

karmi

nginx/
!nginx/.gitkeep
!nginx/logs/.gitkeep

src/

tmp/

richardfeliciano

#!/bin/bash
#your db settings
USER="db_root"
PASS="db_pass"
PATH="/path/to/backup/folder"
HOST="mysql_host"
DATE=`date +%d%m%y%H%M`

#get databases list
databases=`mysql --host=$HOST --user=$USER --password=$PASS -e "SHOW DATABASES;" | tr -d "| " | grep -v Database`

remojansen

function logClass(target: any) {
 
  // save a reference to the original constructor
  var original = target;
 
  // a utility function to generate instances of a class
  function construct(constructor, args) {
    var c : any = function () {
      return constructor.apply(this, args);
    }

bgromov

#!/bin/sh

# Credits: http://stackoverflow.com/a/750191

git filter-branch -f --env-filter "
    GIT_AUTHOR_NAME='Newname'
    GIT_AUTHOR_EMAIL='new@email'
    GIT_COMMITTER_NAME='Newname'
    GIT_COMMITTER_EMAIL='new@email'
  " HEAD