Getting started with TypeScript

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. It hardly helps with code readability. At the same time TypeScript is a separate consistent language, which is, nonetheless, first and foremost a superset of JavaScript. You can use regular JavaScript within TypeScript and TypeScript is being transformed to JavaScript by TypeScript compiler.

I went through the specification and started writing design pattern examples on TypeScript to get a feel on the language.

10 things you need to know about JavaScript

JavaScript seems so simple that many people dont 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 . Yes, it looks like a language of the C-family and, when starting with JavaScript, programers are just writing in C, Java, PHP or other language style. But JavaScript is no subset of any of these languages. You may find JavaScript even a superior language, but you have to know how to do things in JavaScript way. You cannot learn this from the documentation. References and, even more so, the specs are not meant to cover programming patterns, but the language itself. Of course, there is plenty of books and you may find some (e.g. Secrets of the JavaScript Ninja by John Resig, Learning JavaScript Design Patterns by Addy Osmani ) pretty useful. Besides, you can learn straight from the code, since we are lucky to have tons of substantial JavaScript applications available in open-source (jquery.com, yuilibrary.com/projects/yui3/, backbonejs.org, modernizr.com, raphaeljs.com and so on). In either case you may stumble over programming techniques unknown to you. Ive collected here some commonly used practices which may help you.

Functional testing with qUnit

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. You can see it as an automation of QA-engineer routine where it is possible. For functional testing widely used such frameworks as Selenium, Windmill, Twill, BusterJS. Though, if you use qUnit for front-end unit-testing, you may love the idea to use the same tool on functional testing. jQuery provides an incredible API for DOM manipulation. It can be amazing tool to simulate user behaviors and check DOM reaction.

Thanks to Michel Gottas post I came up with a solution.

Scalable JavaScript Application

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. On the other hand, JavaScript is an incredible impressive language. I wonder if JavaScript was originally designed as a foundation on which you build your own language.

About 2 years ago I had worked out a solution which developed by now into a light-weight library which brings into JavaScript everything I miss in the language as a follower of class-based OOP

Pseudo-classical Inheritance in JavaScript for Modules

The classical design of object in JavaScript may look pretty clumsy. So I prefer the module design propagated so indefatigably by Addy Osmani (addyosmani.com/largescalejavascript/). We keep all the declarations within the function body. Public members placed in the object, which the constructor function returns. It looks much nicer. But, here shows up a problem. Common implementation for inheritance doesnt work on such objects. Lets study how exactly JavaScript instantiates objects and come up with a solution for our requirements.

Dependency Injection via Factory

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_Interface instance. We cannot just create DB adapter instance within model constructor, because it depends on configuration data which don’t belong to the model. We can pass to the model constructor a settings array with DB configuration data.

Design by Contract and JS

Design 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.

Flyweight pattern using Mixins

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. In some cases it is much more efficient to share not the instance itself, but weighty parts among the instances. Imagine, you have user object containing properties and methods relevant for any user. However registered user has extended set of properties and methods. Moderator or admin contain even more.

Design Patterns by PHP and JavaScript examples

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. Or you change one module and whole the application starts to collapse like a house of cards. And, of course, you find out that you can’t reuse already written modules for the new tasks, because the encapsulation of the desired parts would take too much risk and work. Robert C. Martin was very accurate naming those symptoms of rotting design as Viscosity, Rigidity, Fragility and Immobility

Bringing realtime to your web applications

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. You can keep the page untouched, but you will see anyway new status updates appear as your friends submitting. The same for notifications. Whenever a new one arrives, the counter changes and the notification list extends.

That seems to me as a trend worth to follow. I’ve been thinking of a solution to vivify widgets on my sites. Now I’m coming up with the following pattern.

Build Your Own Simple Web Form Testing Tool

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?

Support Request Tool like Google Feedback

Have you ever noticed Google+ has an amazing feature called Google Feedback. You click on feedback highlight an area of the site page and getting screenshot with your marking on it sent to the Google support team. If you wonder of having this tool on your own, just take my code and adapt for your requirements.