Awesome PHP has been relocated permanently to its own Github repository. No further updates will made to this gist.
Please open an issue for any new suggestions.
# These are my notes from the PragProg book on CoffeeScript of things that either | |
# aren't in the main CS language reference or I didn't pick them up there. I wrote | |
# them down before I forgot, and put it here for others but mainly as a reference for | |
# myself. | |
# assign arguments in constructor to properties of the same name: | |
class Thingie | |
constructor: (@name, @url) -> | |
# is the same as: |
Awesome PHP has been relocated permanently to its own Github repository. No further updates will made to this gist.
Please open an issue for any new suggestions.
jQuery does good jobs when you're dealing with browser compatibility. But we're living in an age that fewer and fewer people use old-school browsers such as IE <= 7. With the growing of DOM APIs in modern browsers (including IE 8), most functions that jQuery provides are built-in natively.
When targeting only modern browsers, it is better to avoid using jQuery's backward-compatible features. Instead, use the native DOM API, which will make your web page run much faster than you might think (native C / C++ implementaion v.s. JavaScript).
If you're making a web page for iOS (e.g. UIWebView), you should use native DOM APIs because mobile Safari is not that old-school web browser; it supports lots of native DOM APIs.
If you're making a Chrome Extension, you should always use native APIs, not only because Chrome has almost the latest DOM APIs available, but this can also avoid performance issue and unnecessary memory occupation (each jQuery-driven extension needs a separate
# A class-based template for jQuery plugins in Coffeescript | |
# | |
# $('.target').myPlugin({ paramA: 'not-foo' }); | |
# $('.target').myPlugin('myMethod', 'Hello, world'); | |
# | |
# Check out Alan Hogan's original jQuery plugin template: | |
# https://github.com/alanhogan/Coffeescript-jQuery-Plugin-Template | |
# | |
(($, window) -> |
/* Flatten das boostrap */ | |
.well, .navbar-inner, .popover, .btn, .tooltip, input, select, textarea, pre, .progress, .modal, .add-on, .alert, .table-bordered, .nav>.active>a, .dropdown-menu, .tooltip-inner, .badge, .label, .img-polaroid { | |
-moz-box-shadow: none !important; | |
-webkit-box-shadow: none !important; | |
box-shadow: none !important; | |
-webkit-border-radius: 0px !important; | |
-moz-border-radius: 0px !important; | |
border-radius: 0px !important; | |
border-collapse: collapse !important; | |
background-image: none !important; |
I read the first two chapters of [The Pragmatic Programmer: From Journeyman to Master][pragprog], which are entitled "A Pragmatic Philosophy" and "A Pragmatic Approach," respectively. I'll go through and summarize my thoughts "A Pragmatic Philosophy" first:
The preface of The Pragmatic Programmer begins by explaining the meaning of the word 'pragmatic,' which comes from the greek word pragmaticus, or "skilled in business." I get the feeling that this is the central pivot point around which the rest of the book hinges. Skill and craftsmanship are emphasized from the get-go.
Business needs are also a key element, though I get the feeling that it has less in terms of doing whatever the "business person" says and more to do with contextualizing the job of programming within the context of the greater problem at hand.
The sections in the chapter were broken down as seen below. These are the guiding principles behind the rest of the book.
window.onerror = function(message, url, linenumber) { | |
try{ | |
_gaq.push(['_trackEvent', 'Error', 'JS', JSON.stringify({'refurl': document.location.href, 'url': url.replace(/\?\d+$/, ''), 'line': linenumber, 'message': message})]); | |
} catch (e) {} | |
return true; | |
}; |
All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.
Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.
elem.offsetLeft
, elem.offsetTop
, elem.offsetWidth
, elem.offsetHeight
, elem.offsetParent