santaklouse

#!/usr/bin/env bash

# checck if pidof exists
PIDOF="$(which pidof)"
# and if not - install it
(test "${PIDOF}" && test -f "${PIDOF}") || brew install pidof

# find app in default paths
CO_PWD=~/Applications/CrossOver.app/Contents/MacOS
test -d "${CO_PWD}" || CO_PWD=/Applications/CrossOver.app/Contents/MacOS

mlebkowski

#!/bin/bash

# remove exited containers:
docker ps --filter status=dead --filter status=exited -aq | xargs -r docker rm -v
    
# remove unused images:
docker images --no-trunc | grep '<none>' | awk '{ print $3 }' | xargs -r docker rmi

# remove unused volumes:
find '/var/lib/docker/volumes/' -mindepth 1 -maxdepth 1 -type d | grep -vFf <(

Sewdn

TL;DR

Meteor is great at sharing code between different builds for different platforms. You can use the same source for your browser builds, server builds, your builds for iOS, Android, ... But how to organize your project to be able to orchestrate your builds for different apps and services from the same source? This post elaborates on the reasons why you need these different builds and how you could accomplish this with Meteor easily.

Use cases: Why would you build different apps?

1. Different apps for different roles

Say you have an app with completely different end user experiences depending on their role. It is common practice to have the user logged in, check her authorization (role) and then setup different routes or load different templates to serve that type of user’s needs. While doing so, all types of users load the same build and the app decides what portions of the build to use and what not to use.

danielgtaylor

Moving to ES6 from CoffeeScript

I fell in love with CoffeeScript a couple of years ago. Javascript has always seemed something of an interesting curiosity to me and I was happy to see the meteoric rise of Node.js, but coming from a background of Python I really preferred a cleaner syntax.

In any fast moving community it is inevitable that things will change, and so today we see a big shift toward ES6, the new version of Javascript. It incorporates a handful of the nicer features from CoffeeScript and is usable today through tools like Babel. Here are some of my thoughts and issues on moving away from CoffeeScript in favor of ES6.

While reading I suggest keeping open a tab to Babel's learning ES6 page. The examples there are great.

Punctuation

Holy punctuation, Batman! Say goodbye to your whitespace and hello to parenthesis, curly braces, and semicolons again. Even with the advanced ES6 syntax you'll find yourself writing a lot more punctuatio

ekristen

#!/bin/bash

# Author: Erik Kristensen
# Email: [email protected]
# License: MIT
# Nagios Usage: check_nrpe!check_docker_container!_container_id_
# Usage: ./check_docker_container.sh _container_id_
#
# Depending on your docker configuration, root might be required. If your nrpe user has rights
# to talk to the docker daemon, then root is not required. This is why root privileges are not

tmaiaroto

# Feel free to change this path of course (and keys_zone value as well, but also change the usage of it below).
proxy_cache_path /var/www/cache/resized levels=1:2 keys_zone=resizedimages:10m max_size=1G;

# Gzip was on in another conf file of mine...You may need to uncomment the next line.
#gzip on;
gzip_disable msie6;
gzip_static on;
gzip_comp_level 4;
gzip_proxied any;
# Again, be careful that you aren't overwriting some other setting from another config's http {} section.

dominicsayers

What I actually did

/etc/security/limits.conf

elasticsearch hard memlock 100000

/etc/default/elasticsearch

phpdude

        location /resize {
                alias /tmp/nginx/resize;
                set $width 150;
                set $height 100;
                set $dimens "";

                if ($uri ~* "^/resize_(\d+)x(\d+)/(.*)" ) {
                        set $width  $1;
                        set $height $2;
                        set $image_path $3;