This gist shows how to create a GIF screencast using only free OS X tools: QuickTime, ffmpeg, and gifsicle.
To capture the video (filesize: 19MB), using the free "QuickTime Player" application:
#!/usr/bin/env ruby | |
# Remove all gems EXCEPT defaults :) | |
`gem list -d`.split(/\n\n^(?=\w)/).each do |data| | |
match = data.match(/(?<name>([^\s]+)) \((?<versions>.*)\)/) | |
name = match[:name] | |
versions = match[:versions].split(', ') | |
if match = data.match(/^.*\(([\d\.]*),? ?default\): .*$/) | |
next if match[1].empty? # it's the only version if this match is empty |
type T struct { | |
A int | |
B string | |
} | |
t := T{23, "skidoo"} | |
s := reflect.ValueOf(&t).Elem() | |
typeOfT := s.Type() | |
for i := 0; i < s.NumField(); i++ { |
#######BEGIN SCRIPT############ | |
#!/bin/bash | |
# This checks that the specified file is less than 28 hours old. | |
# returns 0 if younger than 28 hours. | |
# returns 1 if older than 28 hours. | |
#funtion arguments -> filename to comapre against curr time | |
function comparedate() { | |
if [ ! -f $1 ]; then | |
echo "file $1 does not exist" |
# | |
# Working with branches | |
# | |
# Get the current branch name (not so useful in itself, but used in | |
# other aliases) | |
branch-name = "!git rev-parse --abbrev-ref HEAD" | |
# Push the current branch to the remote "origin", and set it to track | |
# the upstream branch | |
publish = "!git push -u origin $(git branch-name)" |
package main | |
import ( | |
"database/sql" | |
"github.com/mattn/go-sqlite3" | |
"log" | |
"os" | |
) | |
func runQuery(db *sql.DB, query string) { |
This can reduce files to ~15% of their size (2.3M to 345K, in one case) with no obvious degradation of quality.
ghostscript -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/printer -dNOPAUSE -dQUIET -dBATCH -sOutputFile=output.pdf input.pdf
Other options for PDFSETTINGS:
package main | |
import ( | |
"bytes" | |
"compress/gzip" | |
"database/sql/driver" | |
"errors" | |
"fmt" | |
"github.com/jmoiron/sqlx" | |
_ "github.com/mattn/go-sqlite3" |
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
This configuration is not maintained anymore. You should think twice before using it, Breaking change and security issue will likely eventually happens as any abandonned project.