modisposition

It's time to summarize at least few mistakes or epic fails of the year, hoping the next one will try to follow a better direction. I won't mention anything related to war, politic, Berlusconi, or fashion related stuff, other more prepared than me will do via pictures or posts, all I gonna talk about is the field I am concerned about: web and mobile web oriented technologies and facts. The order is completely random, so grab a mug of coffee, take few minutes, and read 'till the end, forgetting for once tl;dr philosophy ;) The Partially (Multi)? Touch Device Case This has been the most annoying fact of the year: vendors going out with freaking powerful mobile devices with touch or multi touch capable screen/hardware not exposed through the browser and only available for native apps. We are not talking about potentially "dangerous" technologies as WebGL could be, we are talking about the most basic thing able to break 140% the user experience. If a user plays a nat

Tour dates to the right New album, "Open Your Heart", out March 6th on Sacred Bones

There are cases where JS coercion may be wanted/needed/necessary, at least logically speaking. A classic case is a list of primitives, e.g. strings, or numbers, and a check we would like to perform without creating a new function each time . // recycled function function alreadyThere(value) { // wanted coercion, no cast needed return value == this; // shitty code, logically speaking // one cast per iteration return value === "" + this; } var listOfNames = ["Me", "You", "Others"]; // the pointless check listOfNames.some( // the recycled callback alreadyThere, // the *passed as object* this "You" ); // will be true Now, for above specific case anyone would use an indexOf but this is not the point. The point is that in some case we may want to do more complicated stuff and compare the result with this // know if word was already in the dictionary function alreadyThere(value) { return value.toLowerCase() == this; } // co

and we're going back really soon stay tuned for a whole slew of tour dates

For those who don't know what __noSuchMethod__ is here the quick summary: it was a bloody handy non-standard method able to provide a fallback whenever we invoked an object method that did not exist. var o = {}; o.__noSuchMethod__(function (name, args) { alert(name); // "iDoNotExist" alert([].slice.call(args)); // 1,2,3 }); o.iDoNotExist(1, 2, 3); // will produce above alerts A Bit Of Background Well, if you are patient enough, you may consider to read this never-ending post in Mozilla mailing list. The reason that post is called Proxies: get+fn vs. invoke is because Proxy supposes to be the new way to go able to bring us much more power than we probably ever need ... but hey, this is welcome, while what is not welcome, is that Proxy may not be implemented first, which means browsers vendors should have waited to remove __noSuchMethod__ 'cause right now we may not have a pseudo equivalent, and second, but surely not less important, , Proxy does not provid

A very good and common practice with JS projects bigger than 100 lines of code is to split code in different files. Benefits are clear: smaller pieces of code to maintain swappable portions for experiments and/or improvements or new features, as example including for a build magic2.js and get it, rather than change drastically magic.js and follow the repository logs better organization of the code, and I'll come back on this in this post possibility to distribute bigger closures, as example the jQuery approach create ad hoc builds including or excluding portion of the library, specially suitable for specific version of the code that must be compatible with IE only Solutions All Over The Place There are really tons of solutions able to make the described build process easy to use and easy to go. As example, I have created my own one and I am using it with basically every project I am working with: the JavaScript Builder . However, this builder requires a couple of extra technologi

Another active exchange with @getify about JSON comments and here my take because tweets are cool but sometimes is hard to tell everything you think in 140 bytes ... Kyle Facts JSON is used on daily basis for billion of things and configuration files are one, surely common, way to use JSON ( just think about npm packages for node.js ). His frustration about the fact JSON does not allow comments is comprehensible, and he even created an online petition about allowing comments in JSON specs ... but are comments really what we need? Just A Side Effect JSON is extremely attractive as standard, first of all because it's available and widely adopted by basically any programming language in this world, even those that never had to deal with a single JavaScript interlocutor, secondly because it's both simple to parse, and easy to read for humans. After all, what can be so wrong about comments inside such common serialization standard? Aren't comments just as easy to parse as whi

December 7th - Paris, France - Espace B December 9th - Dijon, France - Consortium December 10th - Belfort, France - Poudiere December 11th - Strasbourg, France - Mudd Club December 12th - Rotterdam, Netherlands - Exit December 13th - London, UK - Madame Jojo's December 14th - London, UK - Shacklewell Arms