// jQuery
$(document).ready(function() {
// code
})
// geo-location shim | |
// currentely only serves lat/long | |
// depends on jQuery | |
// doublecheck the ClientLocation results because it may returning null results | |
;(function(geolocation){ | |
if (geolocation) return; |
DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE | |
Version 2, December 2004 | |
Copyright (C) 2011 Jed Schmidt <http://jed.is> | |
Everyone is permitted to copy and distribute verbatim or modified | |
copies of this license document, and changing it is allowed as long | |
as the name is changed. | |
DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE |
DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE | |
Version 2, December 2004 | |
Copyright (C) 2011 YOUR_NAME_HERE <YOUR_URL_HERE> | |
Everyone is permitted to copy and distribute verbatim or modified | |
copies of this license document, and changing it is allowed as long | |
as the name is changed. | |
DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE |
// Long Polling (Recommened Technique - Creates An Open Connection To Server ∴ Fast) | |
(function poll(){ | |
$.ajax({ url: "server", success: function(data){ | |
//Update your dashboard gauge | |
salesGauge.setValue(data.value); | |
}, dataType: "json", complete: poll, timeout: 30000 }); | |
})(); |
if has("autocmd") | |
" remove trailing white spaces | |
autocmd BufWritePre * :%s/\s\+$//e | |
endif |
<?php | |
namespace Jb\AdminBundle\Http; | |
use Symfony\Component\HttpFoundation\Response; | |
class CsvResponse extends Response | |
{ | |
protected $data; |
Lately I've been doing a lot of thinking around versioning in repositories. For all the convenience and ubiquity of package.json
, it does sometimes misrepresent the code that is contained within a repository. For example, suppose I start out my project at v0.1.0 and that's what's in my package.json
file in my master branch. Then someone submits a pull request that I merge in - the version number hasn't changed even though the repository now no longer represents v0.1.0. The repository is actually now in an intermediate state, in between v0.1.0 and the next official release.
To deal with that, I started changing the package.json
version only long enough to push a new release, and then I would change it to a dev version representing the next scheduled release (such as v0.2.0-dev). That solved the problem of misrepresenting the version number of the repository (provided people realize "dev" means "in flux day to day"). However, it introduced a yucky workflow that I really hate
These are my notes basically. At first i created this gist just as a reminder for myself. But feel free to use this for your project as a starting point. If you have questions you can find me on twitter @thomasf https://twitter.com/thomasf This is how i used it on a Debian Wheezy testing (https://www.debian.org/releases/testing/)
Discuss, ask questions, etc. here https://news.ycombinator.com/item?id=7445545