Skip to content

Instantly share code, notes, and snippets.

Avatar

Marty Zalega evilmarty

View GitHub Profile
@evilmarty
evilmarty / dabblet.css
Created Jun 29, 2012
styling the calendar indicator for webkit
View dabblet.css
html {
background: #f06;
background: linear-gradient(90deg, #cceecc,#eeeeee);
min-height: 100%;
}
input[type=date] {
background: #ccc;
background: linear-gradient(90deg, #ddd, #ccc);
border: 3px solid #eee;
border-radius: 20px;
View keybase.md

Keybase proof

I hereby claim:

  • I am evilmarty on github.
  • I am evilmarty (https://keybase.io/evilmarty) on keybase.
  • I have a public key ASC4aCr6fEhHPwob7iVjuPPwFKDitQCjhY3Z4-5SuamHlQo

To claim this, I am signing this object:

@evilmarty
evilmarty / state_machine.js
Created Jan 5, 2014
A small and simple state machine in Javascript.
View state_machine.js
function StateMachine(options) {
options = options || {};
if (!(this instanceof StateMachine)) {
return new StateMachine(options);
}
var states = this.states = (options.states || this.states),
initialState = this.initialState = (options.initialState || this.initialState || Object.keys(states).shift());
@evilmarty
evilmarty / userscript.js
Last active Dec 21, 2015
Campfire avatar userscript
View userscript.js
// ==UserScript==
// @name Campfire Avatar
// @namespace http://firefromthefly.com
// @version 0.1
// @description Adds peoples avatars to the chatroom.
// @match https://*.campfirenow.com/room/*
// @copyright 2012+, You
// ==/UserScript==
var insertMessages = Campfire.Transcript.prototype.insertMessages;
View dabblet.css
/* Fancy textfield */
.fancy-textfield {
display: inline-block;
position: relative;
}
.fancy-textfield > .fancy-textfield-input, .fancy-textfield > .fancy-textfield-placeholder {
color: #fff;
font: 16px/120% Helvetica,Arial,sans-serif;
padding: 10px 0;
}
View dabblet.css
html {
background: #f06;
background: linear-gradient(90deg, #cceecc,#eeeeee);
min-height: 100%;
}
input[type=date] {
background: #ccc;
background: linear-gradient(90deg, #ddd, #ccc);
border: 3px solid #eee;
border-radius: 20px;
@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.

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