Skip to content

Instantly share code, notes, and snippets.

Avatar

Marty Zalega evilmarty

View GitHub Profile
@evilmarty
evilmarty / run.sh
Created Feb 16, 2015
Run a process defined in a Procfile
View run.sh
#!/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 Jul 22, 2015
git pull request workflow
View git-pr
!/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 Oct 19, 2011
EDH javascript [old] api
View edh.js
/*
** 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 Nov 4, 2011
Mobile Safari form label to input focusing
View gist:1338499
// 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 Feb 14, 2012
The first commented line is your dabblet’s title
View dabblet.css
/**
* 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 Oct 25, 2012
Sass vendor helper mixins
View README.md

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 Nov 21, 2012
My idea on policy objects
View gist:4124589

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 Oct 25, 2012
Sass vendor helper mixins
View README.md

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 Dec 12, 2015
Periodically update homebrew once a week.
View README.md

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 Dec 14, 2015
Ember-backed autocomplete
View README.md

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.