Here's what I do when I publish an NPM package.
I always like to check what's going on in a repo before I do anything:
SPC | |
SPC: find file | |
, switch buffer | |
. browse files | |
: MX | |
; EX | |
< switch buffer | |
` eval | |
u universal arg | |
x pop up scratch |
M[16],X=16,W,k;main(){T(system("stty cbreak") | |
);puts(W&1?"WIN":"LOSE");}K[]={2,3,1};s(f,d,i | |
,j,l,P){for(i=4;i--;)for(j=k=l=0;k<4;)j<4?P=M | |
[w(d,i,j++)],W|=P>>11,l*P&&(f?M[w(d,i,k)]=l<< | |
(l==P):0,k++),l=l?P?l-P?P:0:l:P:(f?M[w(d,i,k) | |
]=l:0,++k,W|=2*!l,l=0);}w(d,i,j){return d?w(d | |
-1,j,3-i):4*i+j;}T(i){for(i=X+rand()%X;M[i%X] | |
*i;i--);i?M[i%X]=2<<rand()%2:0;for(W=i=0;i<4; | |
)s(0,i++);for(i=X,puts("\e[2J\e[H");i--;i%4|| | |
puts(""))printf(M[i]?"%4d|":" |",M[i]);W-2 |
if (!Date.prototype.toISOString) { | |
Date.prototype.toISOString = function () { | |
function pad(n) { return n < 10 ? '0' + n : n; } | |
function ms(n) { return n < 10 ? '00'+ n : n < 100 ? '0' + n : n } | |
return this.getFullYear() + '-' + | |
pad(this.getMonth() + 1) + '-' + | |
pad(this.getDate()) + 'T' + | |
pad(this.getHours()) + ':' + | |
pad(this.getMinutes()) + ':' + | |
pad(this.getSeconds()) + '.' + |
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.
#Mobile Device Detection via User Agent RegEx
Yes, it is nearly 2012 and this exercise has been done to death in every imaginable language. For my own purposes I needed to get the majority of non-desktop devices on to a trimmed down, mobile optimized version of a site. I decided to try and chase down an up-to-date RegEx of the simplest thing that could possibly work.
I arrived at my current solution after analyzing 12 months of traffic over 30+ US based entertainment properties (5.8M+ visitors) from Jan - Dec 2011.
The numbers solidified my thoughts on the irrelevancy of including browsers/OSes such as Nokia, Samsung, Maemo, Symbian, Ipaq, Avant, Zino, Bolt, Iris, etc. The brass tacks of the matter is that you certainly could support these obscure beasts, but are you really going to test your site on them? Heck, could you even find one?! Unless the folks that pay you are die hard Treo users my guess is "No".
Interestingly enough my research shows that /Mobile/ is more efficient than **/iP(