evilmarty

#!/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

!/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

/*
** 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

// 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

/**
 * 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

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

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

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

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

evilmarty

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.