A few months ago I bought a new Macbook. I’m really fond of the development environment I set up on it. The more I work with it, the more I love it. However, while building the environment I couldn’t find any decent step-by-step manual. So, it took me for a while to get what I wanted. Here’s my experience. Front-end environment For the beginning we need a package manager.
After Microsoft released TypeScript I took a look at their examples and found the idea pretty promising. I do love JavaScript. However, it has its bad parts. JavaScript doesn’t provide any built-in facilities to declare interfaces or object abstraction. There is no explicit way to have type annotations and type checking. Well, even class-based OOP is not a part of the language. Flexibility of JavaScript is incredible. So, there are tons of libraries meant to work-around these inconveniences.
Back in 1995 Netscape wanted a language with a simple programming model, but flexible enough for building real scalable applications. Curious, that Brendan Eich accomplished the task in a few weeks. So, we have JavaScript which seems so simple that many people don’t even bother to learn the language while using it. And yet it works! However, it turned out to be one of the reasons why JavaScript was dramatically misunderstood .
Automated testing is an essential part of application life-cycle (see Continuous Integration). In web-development we usually test: Back-end (*Unit-tests), Front-end (HTML/CSS validators, JSLint/JSHint, CSSLint, YSlow etc) and UI (functional testing). Unit-testing (Back-end, Front-end) is about checking if all the application components adhere the technical design requirements. Every unit-test simulates the application environment on which runs. Functional tests are to determine if the application as a whole ecosystem has no flaws. They run on a copy of real application environment and show if everything is ok from user prospective.
Make of JavaScript the language you need Any diligent developer is constantly working on improving his or her code. There are plenty of books telling how to make your code better. However most of them use the language of class-based OOP. Reader must have enough of experience to reflect those classical design patterns on JavaScript. Thus, many and many developers give up on the language before mastering its true power. That is one of major reasons JavaScript is referred sometimes as The World’s Most Misunderstood Programming Language.
The classical design of object in JavaScript can be expressed like: var ConstructorFunc = function () { var _privateMember = "private member"; } ConstructorFunc.prototype.publicMember = "private member"; ConstructorFunc.prototype.privilegedMethod = function () { return _privateMember; }; Pretty clumsy, isn’t it? I prefer the module design propagated so indefatigably by Addy Osmani (http://addyosmani.com/largescalejavascript/): var Module = function () { // Constructor's job var _privateMember = "private member"; return { publicMember : "private member", privilegedMethod : function () { return _privateMember; } } } It looks much nicer to me.
You know, when coupling is not loose, components depend too much on each other. It makes your entire architecture fragile and immobile. You can check how loose the coupling is by making a unit test for a component. If you have no problem substituting dependencies by e.g. mock objects then everything is ok. Let take a model class. It depends on DB connection, here \Lib\Db\Adapter\Interfaceinstance. We cannot just create DB adapter instance within model constructor, because it depends on configuration data which doesn’t belong to the model.
Related articles: Prototypal Inheritance in JavaScript for Modulesand Scalable JavaScript Application DesignDesign by contract (DbC) is an approach in application design, which originally came from Eiffel, but now widely used on different languages (particularly in Java). In real world one party (supplier) makes an offer for an agreement (business contract) and another one (client) accepts. The same way can be described relations between objects in software engineering. As a declared agreement is accepted by the client object, the last one is expected to keep its rules.
In my previous article among other patters I was telling about Flyweight. That is about the objects designed so to minimize memory use by sharing as much data as possible with other similar objects. You can find plenty of Flyweight implementation examples in Internet, though it will be mostly variations of Multiton, a collection (map) keeping only instance per every identical object. And I decided to follow that unwritten rule as it seems to be the simplest way to show the idea.
After having your project fully tested, deployed and running, it seems the application architecture is pretty good enough. All the requirements met and everybody is happy. But then as it happens, the requirements change and you, all of sudden, find yourself in the time of troubles. It comes out that some modules easier to hack than to modify. Change of other ones brings endless changes in a cascade of dependent modules.
Few years ago only lazy didn’t say about bringing desktop application experience to the web ones. However in reality, it just meant that user actions didn’t always required page reload, but could change page UI dynamically. As for other application events, as a rule they were not handled dynamically. Well, now you can find more and more web applications acting really like desktop ones. For example, Facebook and G+ have widgets which update automatically.
When testing a web-site, nevermind who you are developer or QA-engineer, it happens to you pretty often to fill-in form fields again and again. Boring, stupid work, but how to make sure the form does still work as intended? Some fields added, CAPTCHA was attached, whatever else done –you have to run the test again. Besides, it will be repeated on different browsers. Browser form auto-completion feature helps a bit, but that is not the same as when you have various sets of test-data always ready to apply on a form, isn’t it?