// jQuery
$(document).ready(function() {
// code
})
- Arts: | |
- Design | |
- Fashion & Beauty | |
- Food | |
- Literature | |
- Performing Arts | |
- Spoken Word | |
- Visual Arts | |
- Business: | |
- Business News |
#!/usr/bin/clisp | |
(defconstant ticks (list "▁" "▂" "▃" "▄" "▅" "▆" "▇" "█")) | |
(defun spark (data-list) | |
(let ((max-value (apply #'max data-list)) | |
(ticks-length (length ticks))) | |
(let ((ticks-unit (/ max-value (- ticks-length 1)))) | |
(map 'list (lambda (x) (elt ticks (ceiling (/ x ticks-unit)))) data-list)))) |
#!/usr/bin/env bash | |
for i in $(seq -f %02g 0 23); do echo $( echo -e "$i\t"; git shortlog -n --format='%ad %s' | grep " $i:" | wc -l); done |
/* Wooden Wall [CSS] */ | |
/* Made with ♥ by Louis Bullock */ | |
html,body { | |
height: 100%; | |
overflow: hidden; | |
} | |
html { | |
display:block; |
// tinyxhr by Shimon Doodkin - licanse: public doamin - https://gist.github.com/4706967 | |
// | |
// tinyxhr("http://site.com/ajaxaction",function (err,data,xhr){ if (err) console.log("goterr ",err,'status='+xhr.status); console.log(data) }); | |
// tinyxhr("http://site.com/ajaxaction",function (err,data,xhr){ if (err) console.log("goterr ",err,'status='+xhr.status); console.log(data) },'POST','value1=1&value2=2'); | |
// tinyxhr("http://site.com/ajaxaction.json",function (err,data,xhr){ if (err) console.log("goterr ",err,'status='+xhr.status); console.log(data); console.log(JSON.parse(data)) },'POST',JSON.stringify({value:1}),'application/javascript'); | |
// cb - a callback function like: function (err,data,XMLHttpRequestObject){ if (err) throw err; } | |
// | |
function tinyxhr(url,cb,method,post,contenttype) | |
{ |
Originally published in June 2008
When hiring Ruby on Rails programmers, knowing the right questions to ask during an interview was a real challenge for me at first. In 30 minutes or less, it's difficult to get a solid read on a candidate's skill set without looking at code they've previously written. And in the corporate/enterprise world, I often don't have access to their previous work.
To ensure we hired competent ruby developers at my last job, I created a list of 15 ruby questions -- a ruby measuring stick if you will -- to select the cream of the crop that walked through our doors.
Candidates will typically give you a range of responses based on their experience and personality. So it's up to you to decide the correctness of their answer.
Ideas are cheap. Make a prototype, sketch a CLI session, draw a wireframe. Discuss around concrete examples, not hand-waving abstractions. Don't say you did something, provide a URL that proves it.
Nothing is real until it's being used by a real user. This doesn't mean you make a prototype in the morning and blog about it in the evening. It means you find one person you believe your product will help and try to get them to use it.
/* Solarized Dark | |
For use with Jekyll and Pygments | |
http://ethanschoonover.com/solarized | |
SOLARIZED HEX ROLE | |
--------- -------- ------------------------------------------ | |
base03 #002b36 background | |
base01 #586e75 comments / secondary content |