| /* | |
| ##Device = Desktops | |
| ##Screen = 1281px to higher resolution desktops | |
| */ | |
| @media (min-width: 1281px) { | |
| /* CSS */ | |
When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:
const Article = require('../../../../app/models/article');Those suck for maintenance and they're ugly.
There are a lot of ways to serve a Go HTTP application. The best choices depend on each use case. Currently nginx looks to be the standard web server for every new project even though there are other great web servers as well. However, how much is the overhead of serving a Go application behind an nginx server? Do we need some nginx features (vhosts, load balancing, cache, etc) or can you serve directly from Go? If you need nginx, what is the fastest connection mechanism? This are the kind of questions I'm intended to answer here. The purpose of this benchmark is not to tell that Go is faster or slower than nginx. That would be stupid.
So, these are the different settings we are going to compare:
| The licenses in the npm-registry from their package.json, from the latest version of each module | |
| 23.11.2013 | |
| [ { key: 'undefined', value: 27785 }, | |
| { key: 'MIT', value: 20811 }, | |
| { key: 'BSD', value: 5240 }, | |
| { key: 'BSD-2-Clause', value: 621 }, | |
| { key: 'Apache 2.0', value: 263 }, | |
| { key: 'GPL', value: 233 }, |
| /*! | |
| * isVis - v0.5.5 Aug 2011 - Page Visibility API Polyfill | |
| * Copyright (c) 2011 Addy Osmani | |
| * Dual licensed under the MIT and GPL licenses. | |
| */ | |
| (function () { | |
| window.visibly = { | |
| b: null, | |
| q: document, |
The web is full of benchmarks showing the supernatural speed of Git even with very big repositories, but unfortunately they use the wrong variable. Size is not important, but the number of files in the repository really is!
Why is that? Well, that's because Git works in a very different way compared to Synergy. You don't have to checkout a file in order to edit it; Git will do that for you automatically. But at what price?
The price is that for every Git operation that requires to know which files changed (git status, git commmit, etc etc) an lstat() call will be executed for every single file
Wow! So how does that perform on a fairly large repository? Let's find out! For this example I will use an example project, which has 19384 files in 1326 folders.
| /** | |
| * performance-timing.js: Polyfill for performance.timing object | |
| * For greatest accuracy, this needs to be run as soon as possible in the page, preferably inline. | |
| * The values returned are necessarily not absolutely accurate, but are close enough for general purposes. | |
| * @author ShirtlessKirk. Copyright (c) 2014. | |
| * @license WTFPL (http://www.wtfpl.net/txt/copying) | |
| */ | |
| (function (window) { | |
| 'use strict'; |
| body#-webkit-web-inspector #main{background-color:#002b36!important}body#-webkit-web-inspector #main .panel.network,body#-webkit-web-inspector #main .panel.timeline,body#-webkit-web-inspector #main .panel.profiles,body#-webkit-web-inspector #main .panel.audits,body#-webkit-web-inspector #main .panel.extension{background-color:#fff!important}body#-webkit-web-inspector #console-messages a:hover,body#-webkit-web-inspector #console-messages .console-formatted-function,body#-webkit-web-inspector #console-messages .console-formatted-object{color:#93a1a1!important}body#-webkit-web-inspector #console-prompt,body#-webkit-web-inspector #console-messages a,body#-webkit-web-inspector #console-messages .console-message,body#-webkit-web-inspector #console-messages .console-group-messages .section .header .title{color:#839496!important}body#-webkit-web-inspector #console-messages .console-formatted-null,body#-webkit-web-inspector #console-messages .console-formatted-undefined{color:#657b83!important}body#-webkit-web-inspect |
| // LZW-compress a string | |
| function lzw_encode(s) { | |
| var dict = {}; | |
| var data = (s + "").split(""); | |
| var out = []; | |
| var currChar; | |
| var phrase = data[0]; | |
| var code = 256; | |
| for (var i=1; i<data.length; i++) { | |
| currChar=data[i]; |
Some of the most important changes in ES6 involve improved support for the patterns we already commonly use to organize JavaScript functionality. This chapter will explore Iterators, Generators, Modules, and Classes.
An iterator is a structured pattern for pulling information from a source in one-at-a-time fashion. This pattern has been around programming for a long time. And to be sure, JS developers have been ad hoc designing and implementing iterators in JS programs since before anyone can remember, so it's not at all a new topic.
What ES6 has done is introduce an implicit standardized interface for iterators. Many of the built in data structures in JavaScript will now expose an iterator implementing this standard. And you can also construct your own iterators adhering to the same standard, for maximal interoperability.
