start new:
tmux
start new with session name:
tmux new -s myname
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
There have been several HOWTOs posted regarding streaming the 2012 Olympics using HTTP / SOCKS proxies via SSH and other similar methods. None of these actually work using the latest Flash on Mountain Lion (with Firefox, Chrome or Safari). Additionally, the third-party streaming sites don't provide BBC's amazing interface, which lets you quickly skip to individual competitors and events. However, setting up an OpenVPN server does work, with some tweaks. You'll get the exact same UX that people in England receive.
Get a Linode VM in the UK. The 512MB server for $20 works just fine. (If you want to use my referral link, go for it: http://bit.ly/OuzdVe)
Follow the standard OpenVPN installation documentation. (Basically, 'apt-get install openvpn' or 'yum install openvpn' and then follow these docs: http://openvpn.net/index.php/open-source/documentation/howto.html). For an OS X client, I prefer Viscosity: http://www.thesparklabs
| a=b=c=(1..100).each do |num| | |
| print num, ?\r, | |
| ("Fizz" unless (a = !a) .. (a = !a)), | |
| ("Buzz" unless (b = !b) ... !((c = !c) .. (c = !c))), | |
| ?\n | |
| end |
| function Game(){ | |
| var total_score = 0; | |
| var scoring_map = {ghost: 10, pellet: 1, fruit: 5}; | |
| Object.defineProperties(this, { | |
| score: { get: function(){ return total_score; } } | |
| }); | |
| this.eat = function (edible){ | |
| total_score += scoring_map[edible] ? scoring_map[edible] : 0; |
| /** | |
| * UnderscoreJS inspired `merge` | |
| * UnderscoreJS calls it `extend` (overloaded in JS); `merge` feels more intention revealing | |
| * This is naive as it always overwrites if the target property exists. | |
| * | |
| * @see https://github.com/documentcloud/underscore/blob/master/underscore.js#L727 | |
| * @param {Object} target | |
| * @return {Object} target | |
| */ | |
| function merge(target) { |
| // use with: https://github.com/simogeo/Filemanager/pull/97 | |
| var | |
| culture = 'en', | |
| defaultViewMode = 'grid', | |
| autoload = true, | |
| showFullPath = false, | |
| displayPathDecorator = function(path) { return path.replace(/^\d+\/images/i, ''); }, | |
| browseOnly = false, | |
| lang = 'php', |
| @ChristinGorman gave this talk at JavaZone: https://vimeo.com/49484333 It's quite good, short, energetic, enthusiastic, | |
| intelligent, and completely misses the point. | |
| While it's true that the code she produces is much better than the original, and is quite easy to understand; it fails one | |
| critical test. It's not polite. | |
| Polite code is like a well written newspaper article. It allows you to bail out early. A well written article has a | |
| headline, a synopsis, and a set of paragraphs that begin with the high level concepts and get more and more detailed as you | |
| read through the article. At any point you can decide: "I get it! I don't need to read further." Indeed, this is how most | |
| people read newspapers or magazines. The articles are polite, because they allow you to get out quickly. |
| /** | |
| * How to test: | |
| * | |
| * (1) You provide an expression | |
| * (2) You provide what you "expect" that expression's result/outcome will be | |
| * (3) You express how you'd like to compare "expected" outcome to the actual outcome | |
| * (4) Your test should fail initially because you haven't yet writtne the code to support the positive outcome | |
| * (5) Refactor until the test passes | |
| * (6) Repeat | |
| */ |