modisposition

Two days ago I've submitted a JavaScript loader to 140byt.es since this loader, once minified, fits into 136 bytes . The reason the entry is 140 in the site is that I've left on purpose /**/ to easily spot where you should put JS files to load. And That's Not It Once we have an Array, we have also .concat() , and once we have concat, we have the ability to decide, inline, what should be in the menu: var menu = [].concat( // starter 'onrefusedbeef' in window ? 'caprese' : 'salami', // main course (function(window){ return !!window.bigAppetite; }(this)) ? [ 'pasta', 'salad', 'bred' ] : 'salad', // dessert ['coockies'].concat( this.extraCalories ? ['chocolate', 'sour cream'] : [] // nothing to add ) ) ; // check the menu, chef alert(menu.join("\n")); You can play with differe

I've created many repositories in my programming history, starting from the good old Google Code , passing through Mercurial HG and svn, ending up using on daily basis the awesome Github . There is something I've spotted every time I've created a new repo, I needed a way to do always the same thing ... but better each time ! The very latest case is the callerOf utility , something that small and already demanding usual/common stuff such: a meaningful and organized structure, instead of files in the wild an easy way to test for browsers and often nodejs too a simple build process per each target, able to combine them all at speed light a linter for those projects that could be widely adopted and linters are so annoying ... where was I ... right ... thanks to the same folder structure, an already prepared .gitignore , together with the .npmignore a LICENSE.txt file, in my personal experiments and libraries always Mit Style a Makefile able to help me combining all these tas

hey hey hey our new record, New Moon, is coming out in a few weeks. Stay posted to the blog - we've got plenty of big things coming up - including muchas tour dates to the right, some with our friends Gun Outfit, CCR Headcleaner and Organs, and more to come. love and mud move over, rover. it's time to shake that ass

... is really that easy to start from the scratch or abandon everything, but that's not, by any meaning, an evolution, is rather a reboot. Unfortunately, written software cannot reboot that easily, and we all know that, except few exceptions where is really needed and we call that refactoring! Refactoring is needed when everything is not under reasonable control or performance anymore, refactoring puts everything on hold until it's completed ... you know that ;) Focus On Reality We really should never loose focus on what we are really trying to do, really trying to improve, and for who, if needed, and beside our own self thoughts. If the rest of the world is doing something in a way, we have really few chances to change that way quickly and easily because we decide that way is wrong, right? We need to be able to propose the best change able to improve that de-facto reality rather than thinking that we are able to improve everything simply imposing our own superior reality ..

So, you might know already, but ES guys are talking these days about modules and things, as usual, went out of control since everyone wants its own best module version, ever! Current Status Synchronous, asynchronous, AMD, require() ... apparently these are all right for some use case, but wrong for some other . It looks like JS cannot do synchronous modules ... wait what? why browsers can't since browser have synchronous require since the very beginning? <script> tag anybody? This was me after reading few times JS cannot do sync. Turned out, sync script is in HTML specs, not JS one , but wasn't this about JS indeed, where JS on browser never had this real problem and is simply envious of node.js module loader simplicity? How About Facing Reality ... where in every language, requiring dependencies has always been synchronous because nobody ever cared about that latency, right? And did anyone even bothered using asynchronous file reading to include modules? Not even n

This is about the W3C EventTarget interface, something standard in the DOM side, but still confusing in the JavaScript one where EventEmitter in node.js, or many other kind of constructors, are simply simulating what has been there for years, and standardized across all browser engines. Now In JavaScript Too Correct, I have implemented, written, and re-writtem this shit so many times that I have decided to " un officialize" the already, well described, interface. So, here the repository , something you can install in node via npm install event-target and checking examples on how to use it. Cool? I hope so :-) Only thing that does not make much sense in a non DOM environment is the capture extra argument, something ignored from 90% of the web, something that can be really useful with the DOM but I could not think about any concrete utility in a pure JS world way. Cool thing is: anyone can extend, wrap, or improve, this EventTarget library: enjoy!

I really do not understand why the Web keeps ignoring this browser which is able to provide the best browsing experience out of old hardware too ! It's not me saying that, there are all test you might want to double check or try by yourself. Opera Mobile VS Chrome mobile, a browser available only in latest hardware, and Safari Mobile for iOS 6, and we all know how good is the hardware here. Here the result , with Opera Mobile scoring more than anything else Hardware Acceleration, something possible on canvas you might want to test in this old prototype of a map , the same I have presented at Front Trends in 2010 multi touches, so that an interaction with more modern UI based on gestures could work without problems. Here the tesla experiment In Android 2.X Too This is the part I love the most about this browser ... I mean, if you assume you have best hardware ever under the hood it's easy to be cool , right? I am looking at you Chrome and Safari Mobile , and I am leaving

One of the coolest and most rumored app of these days looked so fun, and conceptually simple, that I could not resist to challenge myself trying to reproduce it via HTML5 and all possible experimental things I know that are working these days for both desktop and mobile. Wine This is the name I have chosen for this experiment, and this is the very first warning: it does not work as it should, is not the equivalent, it cannot substitute the native App : too bad, but probably the reason vine team didn't even try to propose such broken experience. Well, Something Is Working! Guess who's this idiot with a Koala hat in a leaving room: That's correct, " it's a me " through the wine experimental project and a Chrome browser. But let's talk a little bit about technologies I have used, OK? Client (in order of dependencies) experimental.js and Queue HTML5 getUserMedia({video:true, audio:maybe}) Recorderjs for the maybe and Canary only audio st