modisposition

I know it might sound boring but I really want to put everything down and laugh, or cry harder, the day TC39 will realize __proto__ was one of the most terrible mistakes. A Simple Dictionary Attack ES6 says that Object.create(null) should not be affected anyhow from Object.prototype . I've already mentioned this in the 5 Reasons You Should Avoid __proto__ post but I forgot to include an example. You can test all this code with Chrome Canary or Firefox/Nightly and the most basic thing you need to know is this: var n = Object.create(null); n.__proto__ = {}; for (var k in n) console.log(k); // __proto__ !!! Object.keys(n); // ["__proto__"] !!! Got it? So, __proto__ is enumerable in some browser, is not in some other but it will be in all future browsers. Let's go on with examples ... // store values grouped by same key function hanldeList(key, value) { if (!(key in n)) { n[key] = []; } n[key].push(value); } // the Dictionary as it is in ES6 var n = Object.

Symbols , previously known as Names , are a new way to add real private properties to a generic object. // basic Symbol example var BehindTheScene = (function(){ var symbol = new Symbol; function BehindTheScene(){ this[symbol] = {}; } BehindTheScene.prototype.get = function(k) { return this[symbol][k]; }; BehindTheScene.prototype.set = function(k, v) { return this[symbol][k] = v; }; return BehindTheScene; }()); var obj = new BehindTheScene; obj.set('key', 123); obj.key; // undefined obj.get('key'); // 123 In few words symbol makes possible to attach properties directly without passing through a WeakMap. A similar behavior could be obtained indeed via WeakMaps: // similar WeakMap example var BehindTheScene = (function(){ var wm = new WeakMap; function BehindTheScene(){ wm.set(this, {}); } BehindTheScene.prototype.get = function(k) { return wm.get(this)[k]; }; BehindTheScene.prototype.set = function(k, v) { return wm.get

Update : when you've done with this post, there's even more in comments and the newer one: Yet Another Reason To Drop __proto__ Too many discussions without real outcome about __proto__ magic evilness or feature. It's time to understand why using it is, today , a bad idea. __proto__ Is NOT Standard (yet) TC39 refused to standardize this property because of the amount of problems it brings . Apparently will be part of ES6 but is not there yet. __proto__ is a silent, non spec'd, agreement. What's the problem? Keep reading ;) __proto__ Could NOT Be There The silent non standard agreement sees __proto__ as configurable property of the Object.prototype . As example, try this in some environment: (this.alert || console.warn)( delete Object.prototype.__proto__ ); // false or true ? The outcome is migrating from false to true . As example, current Chrome has a non configurable descriptor, while Canary has a configurable one. Same is for latest node.js, Firefox, an

Drawing Class Diagrams preemptive is sometimes nice to optimize your thought of design. But it will still most likely change in the development phase. Since your Class Diagram is part of your documentation it should be up to date all the time. There is no point in having a Class Diagram if the code does not fit it. You could keep adapting the changes to the Class Diagram by hand, but that can get very time-consuming and exhausting. You should rather automate that process, and there are several ways to achieve exactly that. You could for example search for a UML Class Diagram Tool supporting roundtrip engineering. There are some commercial, and even some free ones available. Not all of them work very well and it can be a frustrating task to figure out which way to go. You would probably try out some and throw them away because they are just not what you expected. Thats why i want to show you a different approach: Letting a Javadoc Doclet draw the Class Diagrams in build phase and embed

Well, I don't always post about updates, changes, or new repos here, so here a quick and dirty post on things I've been tweaking, creating, or fixing, recently. DOM4 This 100% test covered polyfill is awesome! Combined with some basic utility makes DOM manipulation life really easy. As example, this is how you can shuffle last to first one a list of li: var li = document.querySelectorAll('ul.shuffle li'); li[0].before(li[li.length - 1]); // or even better! var ul = li[0].parentNode; ul.prepend(ul.lastChild); Pretty cool stuff from W3C! experimental.js The most compact and easy way to retrieve experimental features, or standardized, now supports CSS prefixes too. var JSkey = experimental( window, 'requestAnimationFrame' // optionally explicit, 'js' ); // JSkey is the string // webkitRequestAnimationFrame // mozRequestAnimationFrame // others too or // requestAnimationFrame // forcing JS assignment if (!experimental( window, 'requestAnimati

Change In Software Development there is no such thing as stagnancy. Everything you develop now is just another version of a component that will probably change in the future. Change is the most common thing in Software Development, and you're better of accepting it as a fact. Expect future changes to everything you develop, and therefor design your Code more modular. This makes changes more easy and increases the Quality at the same time. Adapt the concepts of DRY and YAGNI . You will often come to the Situation, where you look at your Code and imagine that you could have done that "better". Don't let this thought prevent you from sleeping. Take action immediately and Refactor ! If you don't do it now, you will probably never do it. The longer you wait, the harder and more costly it gets. And you slowly grow up a mess you cant deal with anymore. "Good code is code that is easy to change. Code tends to change until it is no longer easy to change. All code bec

CircularJSON is my next level take on @getify thoughts about recursive-safe JSON.stringify() operation, going further than what @izs proposed with his json-stringify-safe module which aim, and purpose, can be summarized in his reply: This module is useful for the use case I'm using it for. If it's not your cup of tea, well, GOOD NEWS! There are a lot of cups with a lot of different flavors of tea in them. Thanks man, what you probably don't know is that actually, there are no concrete, safe, performant, solutions to that problem ... oh well, now there is one! CircularJSON My fully tested, 650 bytes, portable and cross platform solution, is based on same isaacz logic: the usage of JSON.stringify(data, receiver) In few words, if you consider safe the native JSON , you can consider safe CircularJSON too in both serialization and deserialization . Despite what you might think about recursive serialization, there's no magic behind and all tests can prove that Circ

The Decorator Pattern Class Diagram: Decorator Pattern is one of the most powerful Design Patterns, and its important to understand why. It allows you to add functionality to a Class without changing it. You use delegation instead of inheritance by just wrapping the existing Class in a "Suite" of your choice while the Interface stays the same. This way, you can even wrap a Class into multiple layers of Decorators where every Layer has its own and different purpose, and the Original Class even stays the same. Other than that the Layers are completely interchangeable and removable, because they all have the same Interface. You can use your naked Object in the same manner as a decorated one with multiple Layers, and the rest of the Application wont even notice. Other components dont need to know whether a Class is decorated or not, because the only thing they care about is the Interface. The following Graphic should clear things up: Just follow the Steps: In the first example th

Today i want to show you another way to use the Builder Pattern . From what i ' ve seen there are tons of examples of the Builder Pattern online. But they do all have one thing in common: They are used to create an Instance of an Object and "replace" its constructor. This way you can create a complex Object in a very clean and readable fashion using a Fluent Interface . Other than that, there is also a slightly different way you can benefit of the Builder Pattern. Think of a Method with like 10 Parameters. Thats not quite nice, and should not ever happen. Robert C. Martin recommends a maximum amount of 3 Parameters in his book: Clean Code . You should rather use some kind of a Config Object holding those 10 parameters, to clean it up. But lets say, you have a BookService Class with a find(..) method, that allows to search by 10 different parameters, and every single one of them is optional. You could use the Builder Pattern with some kind of Query Object to solve the pro

Every now and then somebody comes out with this problem: How do I stop an iteration such forEach() ? Well, there are at least a couple of ways to do that ... Dropping The Length The first tacky way to stop executing a function is to drop the length of the array. Every extra receives the initial ArrayLike object as third parameter so a function like this should be safe enough: function forEachAndBreak(value, i, arr) { if (someCondition(value)) { arr.length = 0; } } someArray.forEach(forEachAndBreak); Bear in mind, this will affect the initial array too so if this is not desired, a copy is needed: someArray.slice().forEach(forEachAndBreak); Cons: Still Looping Even if this trick works as expected, there is something we don't see behind the scene: the loop is still going on. If you ever wrote some array polyfill, you might have heard that the for loop should verify that i in arr is true, before invoking the function or handling the value at that index since the Array might

Today i want to help you manage your Automated GUI Tests (Selenium) better. In the past i have seen many different ways people handle this. Some people just write those plain HTML TestCases with Selenium-IDE, store it somewhere on the HDD and run manually when needed. Others dont even use Selenium-IDE. They write pure Java for Example, and automate their execution with JUnit. My todays solution lies inbetween. Precondition I want plain HTML TestCases, created with Selenium-IDE. So that someone with little Programming skills can still create them. I want these GUI Tests to be run automatically in my Build process, so my CI-Tool can notify me on errors. I also want all TestCases under Versioncontrol in my Projects Repository since the Tests grow with the Source. I want the most little effort with the highest outcome. So i dont want to export JUnit Tests out of my HTML TestCases since it would be kind of a Duplication - and i want to stick to the DRY Principle. Solution First of all i cre