Skip to content

Instantly share code, notes, and snippets.

View evilmarty's full-sized avatar

Marty Zalega evilmarty

View GitHub Profile
@evilmarty
evilmarty / run.sh
Created February 16, 2015 05:55
Run a process defined in a Procfile
#!/bin/sh
cwd=$(pwd)
process=$1
procfile="$cwd/Procfile"
if [ ! -r $procfile ] ; then
echo "$procfile does not exist or is not readable"
exit -1
fi
@evilmarty
evilmarty / git-pr
Created July 22, 2015 03:31
git pull request workflow
!/bin/bash
PULL_REQUEST_TEMPLATE="\n# Please enter the message for your pull request. Lines starting\n# with '#' will be ignored, and an empty message aborts the commit.\n# On branch %s"
branch=$(git rev-parse --abbrev-ref HEAD);
if [ "$branch" = "master" ]; then
echo "Cannot create pull request on master branch";
exit 1;
fi
@evilmarty
evilmarty / edh.js
Created October 19, 2011 00:21
EDH javascript [old] api
/*
** Everyday Hero Javascript API (incomplete)
** http://api.everydayhero.com.au
**
** dependencies: jQuery
*/
var EDH = {
baseURI: 'http://api.everydayhero.com.au/widget/',
ordinalize: function(number) {
number = parseInt(number);
@evilmarty
evilmarty / gist:1338499
Created November 4, 2011 01:59
Mobile Safari form label to input focusing
// For use in jQuery
// Some mobile browsers (ie. Mobile Safari) don't focus their associated inputs
// so we force that behavior when possible.
$('label[for]')
// First we check when a label is touched and is associated with a radio or checkbox input,
// if so then we mark it as having focus.
.live('touchstart', function(event) {
var input = event.target.control ? $(event.target.control) : $('#' + event.target.htmlFor);
if (input.is('[type=checkbox], [type=radio]'))
@evilmarty
evilmarty / dabblet.css
Created February 14, 2012 12:39
The first commented line is your dabblet’s title
/**
* The first commented line is your dabblet’s title
*/
@import url(http://fonts.googleapis.com/css?family=Lilita+One|Quicksand:700|Passion+One);
body {
background: #0AF;
background-image: -webkit-repeating-radial-gradient( hsla(200,100%,80%,.8) 0px, hsla(200,100%,80%,.5) 4px, hsla(200,100%,80%,0) 50px), -webkit-repeating-radial-gradient( hsla(260,100%, 0%, 0) 0px, hsla(260,100%,50%,.1) 2px, hsla(260,100%, 0%,0) 10px);
background-size: 40px 40px;
background-position: 50% 50%;
@evilmarty
evilmarty / README.md
Created October 25, 2012 07:38
Sass vendor helper mixins

If like me you find it frustrating to define the same vendor prefixes over and over again. Sure, you might create mixins that help reduce the amount of repetitiveness but when your mixins file becomes a library (or not) you see so many lines of near-identical code and wonder if there is an easier way.

Say you have this (all-too familiar) mixin:

@mixin border-radius($radius) {
  -webkit-border-radius: $radius;
  -moz-border-radius: $radius;
  -ms-border-radius: $radius;
 -o-border-radius: $radius;
@evilmarty
evilmarty / gist:4124589
Created November 21, 2012 12:18
My idea on policy objects

I've been thinking for a while on how to make permission handling more modular while maintaining ease of use. I'm a big fan of CanCan's outer mechanism, in that I ask the question "can I read this post?", or more specifically can? :read, post. The simplicity of that is where I think permission checking needs to be. As for defining abilities, that leads to be something less than desired. An ability becomes a nightmare to maintain relatively quickly. It knows more than one object should about the system and isn't modular. I can't take one permission out and use it elsewhere, instead having to copy and paste it into another ability file and tweak it to make it fit. A policy object seems like the solution, but I haven't seen any implementation that is easy to use on the outside. With that this is what I have been thinking.

A policy can have any number of objects assigned to it but only one context. Most, if not all, cases will suffice with a single responsibility policy but wh

@evilmarty
evilmarty / README.md
Created October 25, 2012 07:39
Sass vendor helper mixins

If like me you find it frustrating to define the same vendor prefixes over and over again. Sure, you might create mixins that help reduce the amount of repetitiveness but when your mixins file becomes a library (or not) you see so many lines of near-identical code and wonder if there is an easier way.

Say you have this (all-too familiar) mixin:

@mixin border-radius($radius) {
  -webkit-border-radius: $radius;
  -moz-border-radius: $radius;
  -ms-border-radius: $radius;
 -o-border-radius: $radius;
@evilmarty
evilmarty / README.md
Last active December 12, 2015 09:08
Periodically update homebrew once a week.

Simply add this to ~/Library/LaunchAgents/homebrew.mxcl.update.plist and run launchctl load ~/Library/LaunchAgents/homebrew.mxcl.update.plist.

@evilmarty
evilmarty / README.md
Last active December 14, 2015 13:39
Ember-backed autocomplete

In my journey in figuring out the Ember pattern, this is my attempt at trying to create an Ember-only autocomplete field. There were a few outcomes I wanted out of this, a part from being the Ember-way:

  • Work with any data source
  • Easily templatable results
  • Use only Ember constructs

All are welcome to use this, I'm just after feedback at this point.