Alexander Beletsky's Development Blog

Github as blogging platform

2013-05-16T18:55:00.000+03:00

No, I'm not going to talk about creation some github-backed blogging system. I would like to talk on some blogging style I tried to apply recently.

The problem is, technical blogging is difficult. I usually have a lot of ideas or know-how's while I create some code. It's just hard to blog about. As you didn't do the blog post during coding, you might forget some details or simply loose the encouragement to blog about it.

As I mentioned in my previous post I recently created some code that contains Backbone.js + Express.js boilerplate code that could be great start for building single page applications. I felt I need to document it somehow, so even myself will remember what's going on there. So, I put some README file there. Usually, I don't write much documentation, but during writing it I realized that it's a kind of blog post or tutorial I'm writing immediately after I created something.

I liked the way how it went. First of all, Markdown is great for technical blogging. I still use HTML and feel a but ashamed by that fact. It's so easy to format and place code examples inside with Markdown (and it looks minimalistic and great on github). Second, the content of resulted readme file, pleased me much.. I felt it's the same as blogging, but a bit.. more interesting, or so? So, I twitted about and great surprise for me, repository got 200 stars and 20 forks, got mention on JavaScript Weekly and raised some questions.

The same as blogging, but instead post you have repo with README + some valuable code. Instead comments, you got issues and pull requests.

That was really motivating experience. I think I would like to repeat it from time to time.

Building Single Pages Applications

2013-04-29T20:26:00.000+03:00

This is transcript of talk I gave on #msswit conference 25 April 2013.

What is SPA?

If you just imagined the pools and saunas and massage rooms, this is, unfortunately, not the thing that I going to talk about. We'll check out new concept of web applications, that are called - Single Page Applications.

From technical perspective SPA means the web application, that being loaded as one HTML page and redraws it's UI without round trip to server. That sounds not so exiting, but we can see that SPA is much more than that.

GMail is canonical example of single page application. It was not the first single page application though, it became very popular and gathered a lot of users. That was probably the first time the masses of people realized new user experience - application that works in browser, behaves similar to application on desktop. So, SPA opened a of new opportunities and abilities for software developers to release and promote their applications in web, which is in common case a much easier task, comparing to desktop applications. And new approach need to be taken to create such applications.

API oriented architecture

Before we jump into SPA details, let's talk about the architecture that would allow to build apps in that way. Popularized by Twitter it's being adopted by many vendors and became kind of default. We are talking about 'API oriented' architecture.

Basically, it's just a deviation of classical 'Server-client', where we have server that provides an open API.. and where client is browser, powered by JavaScript engine.

It's quite typically that server and client are communicating through HTTP, using JSON as payload format and relying on REST principles. I'm saying typically, since it's not always the case. Some apps might takes XML and use RPC instead of REST, but that actually doesn't really matter.

Client is browser, that runs JavaScript code. JavaScript code is requesting the data and updating the DOM. Few years ago, jQuery was the primary tool of making such applications. Nowadays, we see MV* JavaScript frameworks are gaining a lot of traction and simplifying front-end development. It's not only about simplification, but also bringing the architecture principles on front-end, something that we haven't seen earlier.

How to build Single Page applications?

We have a bunch of technologies, server and client that would allow to do that. ASP.NET MVC, Web API, NancyFX, ServiceStack, Express.js, RoR.. etc, on server and Backbone.js, Knockout.js, Angular.js, Marrionette.js, Durandal.js etc. from client.

It gives a lot of options, actually. All of them have their pro/cons. I've used to use ASP.NET MVC as platform to build open API's and was quite happy with that. Nowadays, I'm using Node.js / Express.js and it works really great, as well.

The truth is, with SPA, the front-end technology plays a bit more significant role. Of course, server still performs important role for authorization, data access, business logic.. but in API oriented architecture is turns to be a kind of CRUD exposed through HTTP.

As for front-end, my experience lies in Backbone.js. Preventing the questions, I would say - Backbone.js is not perfect (as there are nothing perfect in this world). Bare Backbone.js app would require a lot of manual coding, but it would also allows to see some important implementation details that could be good for general SPA understanding.

Server architecture

Server is responsible for two principal things. First, it provides with API. Second, it server the master page (again, it's not always the case, master.html could be places in some static resource server).

Master page, is the one that being rendered in browser should bring basic DOM structure + reference the JavaScript code to initialize and run application. That's it.

As always, it's important to think about scalability. Doesn't matter what technology you pick up, it's able to scale and hanlde more incoming request with given response time is vital.

Client architecture

Scalability is important here, as well. That's a different scalability, though.

I liked the way Derick Bailey stated in one of JavaScript Jabber show:

... scalability in this case is not the number of users running the code at any given time. It’s the number of features in the system, how those features interact, and how you can start up and shut down and do all these things with these different features so that your application can grow in size, grow in features, and grow in capabilities.

That's were there the JavaScript pattern, MV* frameworks are shine. And without simple modularity, it's very hard to build scalable JavaScript applications.

Require.js and AMD

Modularity is important. Each module represents some small piece of application functionality. The problem that JavaScript (ES5, to be precise) doesn't have modules as part of language.

Require.js helps to solve the problem. Instead of referencing hundreds of JavaScript files which expose itself to global namespace, Require.js relies on, so called, Asynchronous Module Definition. The special rules which you code have to follow, to be able to act as module and being loaded by request.

Besides of that, Require.js comes with building/optimization tools, that helps to prepare application to production.

So, the Master html has a reference to Require.js main file, which will be responsible for configuration and initialization of app. This typically includes setup of view state management (ViewManager) and routing (Backbone.Router).

Routing

Router, handles in-browser URL change events and notifies about that changes.

The URL change might appear of 2 things: user clicks some href or submits the form with re-direct. The SPA prevents those things. Instead, all href click are overloaded, so instead of performing GET request on given URL, JavaScript code would let router know that URL is changing. Router receives the message and using some route rules, call corresponding handler.

The handler job is to load the application and execute it.

Applications

Applications in terms of code, are simple objects with run (or execute) function.

The responsibility of application is to fetch all required data and intitialize application Main View. The Main view is then passed to a ViewManager, which is responsible to render it and attach to DOM.

Besides of that, application is also 'logical' group of different modules with one goal. Imagine GMail application again - Contacts, Mails, Tasks are different applications. Each application, could have sub applications (with their own data and views).

The rule of thumb, one route one application.

View Manager

As it's been mentioned about, View Manager is important part of SPA architecture.

It handles the aspects of switching one application (MainView) to another. So, the content of application div is cleared up and than updated with new one. In Backbone.js application, that is particularly important, since besides the DOM update View Manager is responsible to clear up unsubscribe all events that views might be subscribed to, to prevent, so called Zombie View problem.

Main View and Subviews

Not trivial application could contain some complex UI. All complex UI is being divided on many smaller components.

MainView is responsible for whole application UI. It's typical job to instantiate and render all required subviews. It also stores the references for all subviews into some internal data structure, so it's been able to close all them, while main view is closed.

TheMailer - demo application

Here is TheMailer - very simple application that implements all the ideas above. I've created that very quickly and I could not call it completed. At the backend it runs ASP.NET MVC/WebAPI and using Require.js + Backbone.js at front end.

It allows you to view and compose email, as well as some simple management of tasks and contacts.

Under the debugger, it is clear how the application is initialized and starting up, how MainView creates Subviews and how Routing and ViewManager works.

Conclusions

I would call it SPA bare bones. As I mentioned above, using pure Backbone.js is good, since Backbone.js contains all required components which any SPA need (most important it have Backbone.Router).

But I would recommended to check further. If you plan stick to Backbone.js, Backbone.Marionette by Derick Beiley could be really nice option. For Google technologies fans, Angular.JS makes a lot of sense. For ones that liked Caliburn.Micro during WPF programming, could play with new framework Durandal.js by Rob Eisenberg.

SPA is a lot of fun and adventure, welcome in!

Building Single Page Applications with Backbone.js and Express.js

2013-04-24T06:11:00.000+03:00

This Saturday I was doing my first Backbone.js class. It went really fine, except one fact.

I wanted to show the aspects of creating Single Pages Application running on Backbone. Started the application from scratch, we had to spend a lot of time writing some infrastructure code before we even jump to Backbone. So, after the class I decided to create some boilerplate project, so next time we would just clone it from github and start to work.

That's how the backbone-express-spa born.

Backbone.js + Express.js SPA boilerplate

The project is a Express.js application using Backbone.js as front-end framework. The idea is you just simply clone it, remove non needed routes and application and build something on your own.

I won't put to much details in a blog post, since repo neat readme section. Just several facts:

Minimal and simple - pure Backbone code, no plugins. For some real needs plugins are required anyway and you are free to include whatever you want.
AMD modules with RequireJS - modularity is key factor for large-scale apps, RequireJS
Concept of Application - to group all view, models, collection related to one application unit in one place.
Handlebars template - using Handlebars as template engine.

Further work

It's not yet completely done. I want to create more meaningful app, show some layouts principles + prepare readme section of building application for production.

I'm also thinking of putting some examples of unit tests both for Express.js and Backbone.js.

Conclusions

Check the backbone-express-spa out. If you like it, please give some stars or shout in twitter. I would be really happy to see some pull requests for improving applications or infrastructure. So, if you want to join - you are welcome!

.NET Developer in JavaScript World

2013-04-14T14:35:00.000+03:00

This is a subscript of lighting talk I did on #odessajs conference that took place 13 April in Odessa.

The story

Thinking about the things going on inside and around me I realized - I don't do .NET development more than 1.5 years for now. It's not the first time I was thinking about that, but now it has a bit different perspective.

WTH?

I work in E-conomic company and about 2 years ago we decided to build new product.

Till that time we've learned hard few things: plain jQuery applications is mess, building new shinny product on out-dated infrastructure is bad idea.

So, we've started with front-end by choosing Backbone.js as our foundation, later on we've decided to switch our API server from .NET to Node.js.

It appears we got full JavaScript stack on that product and I involved in JavaScript more and more each day.

I thought I know JavaScript

That time I mistakenly thought, I can do JS programming. Sure, I understood jQuery selectors, concept of callback and even why we need 'var me = this;' trick in code.

But the reality was a bit different. Now, listening to podcasts and reading some blogs, I understood that I've been to 'classic' trap on C#/Java developer switching to JavaScript. Languages and frameworks requires time to learn.

Long hard way of learning

I had to spend the time to learn new stuff. I would say the best source of information was the code written by my colleagues. We have great team, so initially I were just reviewing the code following some patterns. I also spent time of peering famous OS projects like underscore and Backbone.js.

JavaScript Good Parts, opened my eyes on few important things as well.

There are 3 aspects that changed my mind on JavaScript.

JavaScript is dynamic language

Let's be clear. If someone in 2003 tell me I'm going to program dynamic language and will be happy about, I would never believe that. I was programming C++ and truly believed in types. Types as I was thinking is only way to tackle complexity of software.

Even though, I still think about some advantages of static vs. dynamic languages, my opinion has changed radically.

Dynamic languages are great. I feel I more solve problems rather than designing types (or usually hierarchy of types). Consider that, instead of thinking about the name for next "ProxyAbstractFactoryManager" I'm writing functions that do stuff.

Frictionless development

I was compiling applications for whole my life. Just to run some simple thing I need to compile and link. It's usually not a problem at all, but depends on project infrastructure it can take a lot of time. Sooner or later you start to hate builds.

With JavaScript application, you simply should run it. It starting fast so the gap between "write the line of code" and "check the results" became very small.

Instead of heavyweight IDE's I became Sublime Text 2 user. After years in VS you simply could not understand how to write code without IntellySense. But practice shows it's really possible.

Node.js

To be honest with you, I was very skeptical regarding Node.js initially. But again, practice showed different results. It's been proved that Node.js is very suitable for our product. We are running API server on Node.js and it performs really nice.

Later I started to learn what Node.js platform offers and I was really surprised with it's abilities.

CommonJS style of writing code started to make sense. Namespacing problem is solved, so you can build big applications there.

I have to add that Node.js is a significant Open Source player. Everything you get by npm is open source, you can check the sources if anything unclear. Most of Node.js modules are hosted in github, so even if you experience issues you can fix it.

Conclusions

JavaScript is awesome. I like the experience of JavaScript programming so far. Whatever you do, front-end or back-end you stay in one "language context". I would not call a huge problem, but usually context switching from one language to another can take something.

Picking up technology for next side-project or quick hack I'm selecting JavaScript.

Baby steps to Backbone.js: Exploring collections. Part 2.

2013-04-10T20:53:00.000+03:00

Backbone.js is event-driven framework. All Backbone entities are extended from Backbone.Event object. That means, they are able to raise events, subscribers are able to listen to that events and act accordingly. Let's take a look what type of event does Backbone.Collection have.

Backbone.Collection events

Will have a test suite for that,

describe('collection events', function () {
    var listener;

    beforeEach(function () {
        collection = new FeedbackCollection();
    });

    beforeEach(function () {
        listener = jasmine.createSpy();
    });

Here we are creating collection for testing and Jasmine spy, special function we going to use as event subscriber.

Adding element to collection

As we saw previously there are several ways of adding new elements to collection. By add and push methods. The important thing, does not matter what API method you use, Backbone.Collection would trigger 'add' event.

By add method,

describe('while adding elements', function () {
    beforeEach(function () {
        collection.on('add', listener);
    });

    beforeEach(function () {
        collection.add({id: 'feedback-1', email: 'a@a.com', website: 'a.com', feedback: 'hello'});
    });

    it ('should raise add event', function () {
        expect(listener).toHaveBeenCalled();
    });
});

By push method,

describe('while pusing elements', function () {
    beforeEach(function () {
        collection.on('add', listener);
    });

    beforeEach(function () {
        collection.push({id: 'feedback-1', email: 'a@a.com', website: 'a.com', feedback: 'hello'});
    });

    it ('should raise add event', function () {
        expect(listener).toHaveBeenCalled();
    });
});

Each event handlers receives model itself and reference to collection.

Removing elements from collection

Similarly, there 2 ways of removing items from collection, by remove and pop methods.

By remove method,

describe('while removing items', function () {
    beforeEach(function () {
        collection.on('remove', listener);
    });

    beforeEach(function () {
        collection.add({id: 'feedback-1', email: 'a@a.com', website: 'a.com', feedback: 'hello'});
        var model = collection.get('feedback-1');
        collection.remove(model);
    });

    it ('should raise remove event', function () {
        expect(listener).toHaveBeenCalled();
    });
});

By pop method,

describe('while poping items', function () {
    beforeEach(function () {
        collection.on('remove', listener);
    });

    beforeEach(function () {
        collection.add({id: 'feedback-1', email: 'a@a.com', website: 'a.com', feedback: 'hello'});
        collection.pop();
    });

    it ('should raise remove event', function () {
        expect(listener).toHaveBeenCalled();
    });
});

Resetting and sorting

Besides just adding and removing stuff from collection, it have few more method which reaction is triggering event. It's reset and sort. Reset is the bulk insert into collection, it works great when we fetch some data from server and want to push everything just by one operation. Sort, is rarely called manually, since if collection provides comparator function, it would sort itself, during add or reset operations. But sometimes sorting could be triggered from UI as user changes the sort column of table, for example.

Resetting collection,

describe('while reseting collection', function () {
    beforeEach(function () {
        collection.on('reset', listener);
    });

    beforeEach(function () {
        collection.reset([
            {id: 'feedback-1', email: 'a@a.com', website: 'a.com', feedback: 'hello'},
            {id: 'feedback-2', email: 'b@b.com', website: 'b.com', feedback: 'good bye'}]);
    });

    it('should raise reset event', function () {
        expect(listener).toHaveBeenCalled();
    });
});

Sorting collection,

describe('while sorting collection', function () {
    beforeEach(function () {
        collection.on('sort', listener);
    });

    beforeEach(function () {
        collection.reset([
            {id: 'feedback-1', email: 'a@a.com', website: 'a.com', feedback: 'hello'},
            {id: 'feedback-2', email: 'b@b.com', website: 'b.com', feedback: 'good bye'}]);
        collection.sort();
    });

    it('should raise sort event', function () {
        expect(listener).toHaveBeenCalled();
    });
});

Why it matters?

Knowing the events of all Backbone.js entities is very important. You should always design you application based on events triggering/subscription, instead of direct function call. That would make your code much de-coupled and UI logic very flexible.

Likeastore, Application Built on Hackathone

2013-03-31T18:52:00.000+03:00

It's my second time I attended hackatone. As last time, it took place in Ciklum, the best office in Kiev, so I had very strong wish to visit it. My previous experience showed several things: hacktone is absolutely unpredicable thing, you can't guess which projects will be popular or not.. and the second, that it's hard to do something valuable alone.

So, this time I decided to build a team of guys I know and trust, so we can do something together. Those two guys appeared to be my colleagues, in @debitoor project @voronianski and @mamant. We gathered together, to build a product which was called - "Likeastore"

Idea behind

All of us having at least those 3 accounts: facebook, twitter and github. And all of those are continuous stream of information. If you have an interesting network, it probably produces interesting content so you do much of likes/favorites/stars (stories, tweets, or interesting gihub repos). The problem, it's very difficult to keep this information ordered - you typically remember you heard something interesting, but could not remember the source of it.

"Likeastore" is aimed to fix this problem. Integrating wish different services it's keeping your "likes" information in good order, with nice search and smart categorizing.

What we did?

We basically allow "Likeastore" to connect all those application by their open API and collect the information from it. We transform the information into something generic and grouping it together. So, the users are having all information up-to-date in nice and clear dashboard.

Originally we had ambition to have a kinda real-time. In the way, I favorited the tweet and "Likeastore" almost immediately got the information. We had to drop it. The reason is API's of popular applications are very quoted. You simply cannot do more request that in quota, otherwise you just banned.

So, nethertheless of similar projects, we don't want to make next social network of bookmarks. Instead, we want to build easy to use and powerful information keeper. Something, that help you to have things in order.

How we did it?

In fact, we've build a "thrown-out" prototype. The code is a shitty inside, so we bit far of nearest production. But, we've created an interesting application. We split on 2 + 1, two backend (me and @voronianski) and one front-end guy (@mamant). Sat closely and worked shoulder-to-shoulder for next 22 hours.

From the very beginning I had very clear vision of stuff we need to do. I could imagine architecture and UI principles. And as soon I shared that the teammates accepted that really fine and provided high quality feedback and collaboration. That helped us to have a strong team in my perspective.

All of us are JS developers, so no doubt we've taken a JavaScript stack as default. Node.js, powered by Express.js at the backend and Backbone.js front end. Sometimes it's tricky, but in fact - it's powerful combination.

A bit of tech info

We are having 2 main architectural units: core and connectors. Core, is Express.js application having both serving static content and providing API. The API itself, consists on public and private parts. Public part is aimed our web client (or potentiall apps), where the private is used to communicated connectors.

Connectors are just very simple HTTP services, which perform the handshake with core and then post back all data they have collected through API's. That means, we have 3 connectors now - twitter, github and facebook. Facebook, became a quite difficult to integrated with, so we currently dropped it.

We are having CouchDB as our storage. We took it, because @voronianski had some good experience with. That appeared to be a very lucky decision. CouchDB is very interesting NoSQL solution. It's storage model has few interesting features. One of them is "merge-update". Means, you can post exactly same set of information many times, but CouchDB would not create new entities. It would merge identical documents into one. That simplied connectors very much, since they no longer need to track only new information, but could post back just a transformed bulk of information from API's.

Initially, we all agreed - our UI will never be default Bootstrap theme. It's overused and impress no more as toilet door. That's where @mamant apply his best skills. He carefully worked all our screens making a it look nice and original.

Presentation and feedback

Without few features we did demo-able version in time. We have concluded few major fixes, just before the deadline.

I did a presentation of app in short way, without anything unimportant (at least I wish to think so) and we had received great feedback. People liked the idea, so we've collected 32 voices that brought us 2nd place.

That gives a much of inspiration for further work! All of us are very enthusiastic to make the stuff done. It's a lot of work, actually.

I just want to say thank you to all organizers of this event, it was nicely handled. And to the team, for making it fun and interesting.

Stay tuned for release of "Likeastore", check out sources in a meanwhile.

Baby steps to Backbone.js: Exploring collections

2013-03-27T17:51:00.000+02:00

After initial introduction to Backbone's views and models, we going to look on next Backbone.js fundamental entity - Collection. Collections represents the ordered set of models and became very handy for any type of applications. Consider that, we almost always operate with set of different models: posts, tweets, news etc. all of that are collections, typically rendered as lists or grids.

In small application we are doing through that series we have collection of feedbacks. But before I show how to integrate collection into the app, I want to make sure you understand all collection properties right. We'll do that by TDD'ing the collection and exploring it's behavior.

Collection construction

So, to create collection we need to extend Backbone.Collection object,

var FeedbackCollection = Backbone.Collection.extend({
    model: Feedback,
    url: '/feedback'
});

Here we just specified the URL for collection persistence and the model, of which the collection would consists of. Let's prepare the test suite for collection stories,

describe('FeedbackCollection.js spec', function () {
    var collection;
});

And create our first specification,

describe('when constructing', function () {
    describe('just empty', function () {
        beforeEach(function () {
            collection = new FeedbackCollection();
        });

        it('should be created', function () {
            expect(collection).toBeDefined();
        });
    });

Just to make sure, our definition is fine and we are able to instantiate new collection object.

FeedbackCollection constructor have few optional arguments - models, options. Models, could be either arrays of objects, or array of Backbone.Models. In case of object, collection constructor would "turn" them to models (taking the type we specified on collection definition) and add those models to collection.

describe('with objects', function () {
    beforeEach(function () {
        var models = [
            {email: 'a@a.com', website: 'a.com', feedback: 'hello'},
            {email: 'b@b.com', website: 'b.com', feedback: 'good bye'}
        ];
        collection = new FeedbackCollection(models);
    });

    it('should be lenght of 2', function () {
        expect(collection.length).toBe(2);
    });

    it('should contain models inside', function () {
        expect(collection.models).toBeDefined();
    });
});

or,

describe('with models', function () {
    beforeEach(function () {
        var models = [
            new Feedback({email: 'a@a.com', website: 'a.com', feedback: 'hello'}),
            new Feedback({email: 'b@b.com', website: 'b.com', feedback: 'good bye'})
        ];
        collection = new FeedbackCollection(models);
    });

    it('should be lenght of 2', function () {
        expect(collection.length).toBe(2);
    });

    it('should contain models inside', function () {
        expect(collection.models).toBeDefined();
    });
});

Both things are equivalent. Moreover, typically it's only unit tests you need to initialize collections that way, so I usually prefer first option.

The options parameter, could contain the type of model that collection contain. So, if collection does not specify model property, Backbone.Model will be created by default.

describe('with options', function () {
    beforeEach(function () {
        var models = [
            {email: 'a@a.com', website: 'a.com', feedback: 'hello'},
            {email: 'b@b.com', website: 'b.com', feedback: 'good bye'}
        ];
        collection = new Backbone.Collection(models);   // not specifying model
    });

    it('should be created', function () {
        expect(collection).toBeDefined();
    });

    it('should have models of Backbone.Model type', function () {
        expect(collection.models[0].constructor).toBe(Backbone.Model);
    });

You can override that by passing {model: MyModel} options object,

describe('while passing model option', function () {
    beforeEach(function () {
        var models = [
            {email: 'a@a.com', website: 'a.com', feedback: 'hello'},
            {email: 'b@b.com', website: 'b.com', feedback: 'good bye'}
        ];
        collection = new Backbone.Collection(models, { model: Feedback });
    });

    it('should have models of Feedback type', function () {
        expect(collection.models[0].constructor).toBe(Feedback);
    });
});

Despite of that possibility I really rare use that in practice. It's better to simply specify model type in collection definition, that makes code easy to understand.

Accessing collection elements

After collection has been constructed, it's possible to access internal models. There are several ways of doing that.

The simplest one is by index,

describe('when accessing collection elements', function () {
    var first, second, models;

    describe('by index', function () {
        beforeEach(function () {
            models = [
                {email: 'a@a.com', website: 'a.com', feedback: 'hello'},
                {email: 'b@b.com', website: 'b.com', feedback: 'good bye'}
            ];
            collection = new FeedbackCollection(models);
        });

        beforeEach(function () {
            first = collection.at(0);
            second = collection.at(1);
        });

        it('should get first model by index', function () {
            expect(first.toJSON()).toEqual(models[0]);
        });

        it('should get second model by index', function () {
            expect(second.toJSON()).toEqual(models[1]);
        });
    });

Even it possible, in real apps you probably don't know the index of model you need to get from collection, since they might come from server in unpredictable order. So, instead of index, getting by id is more appropriate way.

describe('by id', function () {
    beforeEach(function () {
        models = [
            {id: 'feedback-1', email: 'a@a.com', website: 'a.com', feedback: 'hello'},
            {id: 'feedback-2', email: 'b@b.com', website: 'b.com', feedback: 'good bye'}
        ];
        collection = new FeedbackCollection(models);
    });

    beforeEach(function () {
        first = collection.get('feedback-1');
        second = collection.get('feedback-2');
    });

    it('should get first model by id', function () {
        expect(first.toJSON()).toEqual(models[0]);
    });

    it('should get second model by id', function () {
        expect(second.toJSON()).toEqual(models[1]);
    });
});

And finally, something that I being trapped many time while starting up with Backbone - indexers on collection, does not work.

describe('indexer does not work', function () {
    beforeEach(function () {
        models = [
            {id: 'feedback-1', email: 'a@a.com', website: 'a.com', feedback: 'hello'},
            {id: 'feedback-2', email: 'b@b.com', website: 'b.com', feedback: 'good bye'}
        ];
        collection = new FeedbackCollection(models);
    });

    it('should be undefined', function () {
        expect(collection[0]).not.toBeDefined();
    });
});

Adding and removing items

Next, we need to understand to how to add and remove items from collections.

There are 2 ways of adding item into backbone collection: add, push. They are very similar, but there are difference between those. The add method takes a model or array of models and the options you can specify the position there the item should be interred to. Push method, would simply add new item to the end of collection.

describe('by add method', function () {
    beforeEach(function () {
        collection.add({id: 'feedback-1', email: 'a@a.com', website: 'a.com', feedback: 'hello'});
    });

    it('should be added', function () {
        expect(collection.get('feedback-1')).toBeDefined();
    });

    it('should be converted to model', function () {
        expect(collection.get('feedback-1').constructor).toBe(Feedback);
    });

    describe('with index specified', function () {
        beforeEach(function () {
            collection.add({id: 'feedback-2', email: 'b@b.com', website: 'b.com', feedback: 'good bye'}, {at: 0});
        });

        it('should have 2 items in collection', function () {
            expect(collection.length).toBe(2);
        });

        it('should have feedback-2 item at index 0', function () {
            expect(collection.at(0).id).toBe('feedback-2');
        });
    });
});

By push,

describe('by push method', function () {
    beforeEach(function () {
        collection.push({id: 'feedback-1', email: 'a@a.com', website: 'a.com', feedback: 'hello'});
    });

    it('should be added', function () {
        expect(collection.get('feedback-1')).toBeDefined();
    });

    it('should be converted to model', function () {
        expect(collection.get('feedback-1').constructor).toBe(Feedback);
    });

    describe('with next push', function () {
        beforeEach(function () {
            collection.push({id: 'feedback-2', email: 'b@b.com', website: 'b.com', feedback: 'good bye'});
        });

        it('should have 2 items in collection', function () {
            expect(collection.length).toBe(2);
        });

        it('should have feedback-1 item at index 0', function () {
            expect(collection.at(0).id).toBe('feedback-1');
        });
    });
});

Please note, that push recieves the same options as add, but it's just a short-cut for add method (take a look how it's implemented, to make it completely clear)

For removing the items, we also have 2 methods: remove, pop. They are opposite symmetrical to the add, push. Remove, removes specified model from collection, pop removes the last model in collection. This is shown by following specification,

describe('when removing items', function () {
    beforeEach(function () {
        collection = new FeedbackCollection();
    });

    beforeEach(function () {
        collection.push({id: 'feedback-1', email: 'a@a.com', website: 'a.com', feedback: 'hello'});
        collection.push({id: 'feedback-2', email: 'b@b.com', website: 'b.com', feedback: 'good bye'});
    });

    describe('by remove method', function () {
        beforeEach(function () {
            var model = collection.get('feedback-1');
            collection.remove(model);
        });

        it('should be removed', function () {
            expect(collection.get('feedback-1')).not.toBeDefined();
        });
    });

    describe('by pop method', function () {
        beforeEach(function () {
            collection.pop();
        });

        it('should be removed', function () {
            expect(collection.get('feedback-2')).not.toBeDefined();
        });
    });
});

Conclusions

We've just gone for a very basic features of Backbone.Collection type. Next time, we'll explore more about collections as events it produces, fetching and persisting data to server.

Third Year of E-conomic

2013-03-13T20:29:00.001+02:00

That's my traditional post on yet another anniversary in E-conomic company. Even thought, I still work there, this year I've heard a bit less of E-conomic but more about Debitoor instead. Debitoor is very cool product me and my team is working on and I was totally focused on that during this year.

So, what's interesting about? Alright, it begins with E-conomic company, which through about 10 years on market gathered huge experience in online accounting. The primary target audience for all that years were professional accounters and administrators that have pretty solid knowledge what the accounting is. But due influence of internet economy and small-business grow there appeared high demand on simple accounting software, that could be easily understood even for non-professional accounters. That's were we saw the opportunity. That's then the Debitoor born.

Technologically it's been very innovative for us, too. As I wrote last year, the March was the month we tried how good different technologies might work for us. The decision were taking up to full JavaScript stack - node.js and MongoDB as backend, Backbone.js as front end technologies.

So, near the April we have a working product running .NET + MSSQL, that was on production and customers started to use, we decided to switch backend from .NET to Node.js. The HTTP API interfaces were "copied" from ASP.NET MVC implementation to exactly the same but on Express.js. The difference was in the way how ASP.NET MVC and Express.js is serving the HTML responses, so we have to re-desing the way how front-end application is being initialized and started. Since the low coupling of our front end to ASP.NET features, the rest of Backbone.js application remained absolutely the same.

All existing data has been exported to JSON files and been imported to MongoDB through the existing API. That gave us a chance to make some performance measuring and we definitely we happy about. Average HTTP request were handled in ~100ms that was a quite big boost comparing to previous platform.

Front-end is being involved as well. We've been switched to Single Page Application (SPA) architecture client side and there is no way back. With Node.js backend we easily moved application to cloud, all static resources to CloudFront that affected initial load time as a result made application to look and feel incredibly fast.

But the most important is - users love it! We've got plenty of sign-ups during the day, from different countries as Germany, Spain, Great Britain, Columbia etc., recently we've started premium campaign, and the premium users joins us. UI/UX are tweeked all the time, based on future application vision and A/B tests.

All that makes me feel - your work is important and you do something valuable.. and that is exactly what keeps me working on E-conomic. It's interesting and make sense - that's all I need.

Looking back to 2012

2013-01-05T17:25:00.001+02:00

It's the first Saturday of New Year, so it would be good idea to spend some time thinking of year that passed.

Work in e-conomic

That was yet another great year in e-conomic. We have build great app - Debitoor. Along the way, we were trying different approaches, re-writing things from scratch, designing and re-designing again and again. Finally we got very solid application built upon Node.js, MongoDB and Backbone.js. Debitoor has been created with scalability in mind, we started with Heroku cloud service, eventually moved to Amazon EC for back-end and Amazon Cloud Front for front-end. Now, it's working amazingly fast and for 8 month we gathered ~20,000 signups, launched service for many countries.

At the beginning of the year we were a bunch of .NET developers diving into JavaScript. Having a very strong team of responsible professionals we've gathered initial knowledge quite fast. I've been focused almost at front-end this year. You probably noticed that I slowed down my writings about ASP.NET MVC and doing more for Backbone.js. That just reflects the fact of my current specialization. Initially, I was not very serious about Node.js platform. But with time, I became to love it. It speed up our development velocity several times, the API we've built on this platform shows amazing performance indicators.

The team has been expanded a bit. We got new very strong PO and few developers both in Ukraine and Denmark and all of those guys are awesome. I enjoy friendly and cooperative environment we have in team. Besides of that, this year we got 2 QA guys. QA influenced the development really much and helped to improve overall quality of service. I would also mention amazing UX team we have, calling themselves "UX Wizards Team" I have to admit - we are really doing magically things. UI/UX of app is changing all the time and with each iteration it became more intuitive, comprehensive and good looking.

Speaking and blogging

For 2012 and have written 63 blog posts on various topics, primarily on .NET, JavaScript and TDD. Some stats, from Google Analytics:

I don't track GA stats actively and I was really surprised to see the figures. I got 105,490 visits, 79,445 unique visits. That gives 288% more traffic than 2011. That's quite big number and I could only hope that this year the traffic would only grow up.

As for most viewed blog posts:

New in ASP.NET MVC4: Razor changes where I highlighted some new stuff of ASP.NET MVC 4 and it's been tweeted by @scottgu (what explains it's popularity).
New Tools in My TDD Arsenal I posted about stuff I used in .NET development like NCrunch, NSubstitute and FluentAssertions.
Starting Up Node.js Development on Windows as quick introduction to setup Node.js development environment on Windows box.

Something that I personally liked the most:

Convention based IoC configuration convention over configuration principles applied to IoC.
7 Weeks With Python my little journey with Python language during Audacity CS101 course.
Developing Web Applications Faster that shows how to apply LiveReload technique to working faster with front-end tasks.

As I said above my focus moved from .NET to JavaScript a bit. I've started a series of blog posts called Baby steps to Backbone.js, I'm learning JavaScript and other front-end frameworks, so I would say more info about JavaScript to come.

As for speaking, I've prepared 10 presentations during 2012 and had nearly 15 speeches on different events. That's not a lot, but it's much more that 2011 and I feel good about it.

Trainings and Consulting

Our TDD in .NET training became very popular. We did a quite of the through the year. It goes very fine and thanks to XP Injection efforts I could only predict more to come. I also did a training on ASP.NET MVC which went quite fine, but very small demand could be seen on that. I hope that 2013 will bring some more trainings in JavaScript as well.

In 2012 I've tried myself as a consultant. I've been contacted by the guy who listened to my JavaScript talk and asked to help with architectural advices on new service he tries to build. I think that was very good experience for both of us. Of cause, that's just a tiny job but I hope that consulting could work for me in future.

I believe that 2012 was just the beginning of Trainings & Consulting part of my duties and 2013 will be the one to prove it.

Communities

Kyiv Beer'N'Code is something that I personally happy about. Being relauched in September 2012, we haven't missed any meet up. Taking into account it's bi-weekly meetings that's a lot. New guys, who joined the group are open minded and smart, so it's always interesting to spend time there. I would like to have say big thanks to Ciklum company, who provides a support for us.

UA Dev Club is growing and growing. Each meeting gathers more and people and it's great. I did a few talks there I try to attend as more meetings as I can (even if they are talking about Java). UA Dev Club became very active this year and I wish it only improves in 2013.

Kiev ALT.NET in opposite a little slowed down this year. Primarily, because it's leader moved to another city, so it became difficult to manage the stuff. Nevertheless, we've organized very cool meetup at the end of year with Jimmy Bogard and it motivated us to go on. We already have planned few meetings ahead and expecting more interesting foreign guests to come. Besides of that, JetBrains might be the one who can help us this year.

Side projects

The last topic in my list that makes me a bit sad. I have to admit, I haven't produced anything really noticeable through the year. My problem is that I'm starting few projects and none of them could make done. Simply lacking the energy and motivation to accomplish it. I believe that "Less is more" should be my slogan for 2013.

Some new projects appeared in my github profile in 2012:

Wonka - supposed to be a blogging engine based on github with easy integration to ASP.NET MVC applications. I had some designs and ideas of implementing it, but it's still in very early stage.
ASP.NET Mobile - small project that I've completed during preparation to the conference. It launched on AppHabor at http://aspnetmobile.apphb.com/, but the traffic is very low there.
FoundStyles - while my playing with Foundation framework I've decided to build small site to keep gallery of themes there, so http://foundstyles.com/ was born. I've created only 3 and after left it. But, currently it has about 300 visits per day and it make sense to update the project. It would be easier, since Foundation moved to SASS.
Freeze - small utility project to make a snapshots of dynamic web sites. Originally I've created it to make a snapshot of Kyiv Beer && Code site and place it to github. I've spent some time on that and it's not yet done (as well as Kyiv Beer && Code site is not moved).
GithubFS.net - using Github remote repository as local file system project. It's on really early development stage, but has some documentation describing ideas. And, it's not done as well.
Benchmark-js - tiny library for measuring JS execution time and putting that to log. Works both Node.js and browser.
Backbone Computed.Fields - something that I personally happy with. Started as some code I've created for debitoor it moved as stand alone Backbone.js plugin.

If you reading this and those projects looks interesting to you, so you would like to pick that up - please let me know.

Something that I has started in 2011 and feel most shame for is Candidate. Being restarted this year I had big ambitions to actually make it done. I still want to implement some meaningful product for .NET web applications deployment. And Candidate would probably be my focus at the beginning of 2013.

Conclusions

Despite of side-projects failure, 2012 was a good year. 2013 is the year of Python that means it would bring happy coding time for all the developers. Happy New Year!

Introducing Backbone.ComputedFields

2012-12-25T22:28:00.000+02:00

Recently, I've been working on small project which I want to share here. It's called Backbone.ComputedFields and it's small plugin that extends Backbone.Model functionality a bit.

I needed to have a model with 'virtual' fields. Namely, fields that does not belong to model directly, but being computed based on some other fields values.

The easiest solution would be simply introduce some model methods, say model.getComputedField() / model.setComputedField() and store the value inside the model object. But that turns out to be bad idea, for several reasons. First, we are breaking usual Backbone interface for getting and setting values - model.get('computed') / model.set('computed', 100). Also, if model is binded to a view, we are responsible for raising events manually, in case of computed or depended field changing.

So, after few iterations Backbone.ComputedFields was born. The design goals: to be simple, to be declarative, to be friendly to model binding (read, respect the events).

Use cases

Typical use cases for Backbone.ComputedFields are: calculating the prices; concatenating several fields; encapsulating the logic of retrieving object by reference.

It's fairly important, that computed field could change. Based on it's value, dependent fields should be updated.

Examples

Let's take a look on few examples. The models here are very simplified. But, it shows the main application of Backbone.ComputedFields.

Calculating prices

The model represents the product, which contains net price and VAT rate.

var Produc = Backbone.Model.extend({
    initialize: function () {
        this.computedFields = new Backbone.ComputedFields(this);
    },

    computed: {
        grossPrice: {
            depends: ['netPrice', 'vatRate'],
            get: function (fields) {
                return fields.netPrice * (1 + fields.vatRate / 100);
            },
            set: function (value, fields) {
                fields.netPrice = value / (1 + fields.vatRate / 100);
            }
        }
    }
});

So, we have grossPrice as computed field. That field depends on 'netPrice' and 'vatRate' and being calculated by simple formulas.

var product = new Product({ netPrice: 100, vatRate: 20 });
var grossPrice = product.get('grossPrice');

In this case, gross price would be 120.

product.set({grossPrice: 300});
var netPrice = product.get('netPrice');

After gross price is update, netPrice will be recalculated and netPrice will be 250.

Concatenating fields

Let's have a model to represent the person with first name and last name.

var Person = Backbone.Model.extend({
    initialize: function () {
        this.computedFields = new Backbone.ComputedFields(this);
    },

    computed: {
        fullName: {
            depends: ['firstName', 'lastName'],
            get: function (fields) {
                return fields.firstName + ' ' + fields.lastName;
            }
        }
    }
});

I'm skipping the setter cause we don't need to set full name here.

var person = new Person({firstName: 'Alexander', lastName: 'Beletsky'});
var fullName = person.get('fullName');

Full name 'Alexander Beletsky' is returned here.

Referenced objects

Sometimes we have a models that only contains a reference to another model. All the time, we need to get referenced object we have to create some piece of code, which it typically copy-n-pasted thought the code base. Computed field could be a good idea to encapsulate that.

var Invoice = Backbone.Model.extend({
    initialize: function (attrs, options) {
        this.customers = options.customers;
        this.computedFields = new Backbone.ComputedFields(this);
    },

    computed: {
        customer: {
            depends: ['customerId'],
            get: function (fields) {
                return fields.customerId && this.customers.get(fields.customerId);
            },
            set: function(customer, fields) {
                fields.customerId = customer.get('id');
            }
        }
    }
});

Here we have customer field, which is computed.

var invoice = new Invoice({}, { customers: collectionOfCustomers });
var customer = invoice.get('customer');

So, I'm able to get customer model even if invoice is just holding the invoice Id.

invoice.set({customer: anotherCustomer});
var customerId = invoice.get('customerId');

If I'm changing the customer of invoice, the 'customerId' would be initialized with id of 'anotherCustomer'.

Conclusions

Backbone.ComputedFields is still pre-mature, but I already successfully used that in one of projects. The github page contains pretty much documentation, so you should have to problems of adopting it for personal needs.

Baby steps to Backbone.js: Unit testing of views

2012-12-19T21:52:00.001+02:00

Previous time, we've implemented a Backbone model and wrote some meaningful tests for it.

Next very important Backbone's entry to test is View.

Views are central concept in framework. Views are actually ones who do stuff. We don't have Controller in Backbone, but according to Controller initial idea as user input handler, Backbone views following exactly the same architectural goal, so they could be treaded as controllers in some way.

What to test?

You should focus on such things:

Initialization - test that view is provided with all required inputs like: model or collection, localization texts, different options. If view is not able, say, render without some option, you should test that exception is thrown.
Rendering - test that required html appeared in view. I do not create those very strict, since they would be to fragile in case of markup changes, but still I check for major DOM elements are present and have right styles.
Events - test that view is correctly handle DOM events.
Model changes and persistence - test that changes in view are correctly propagated in model. If view is about to persist the model, that could tested as well.

I see tests of views as kind of integration test. You communicate to DOM, listening to events, updating models or changing DOM elements state. It's typically that view tests are catching most regression issues.

How to test?

Fortunately, the Backbone views are designed in very testable way. You don't need any special HTML on test page, since view holding all it's DOM structure inside this.el. By means of jQuery, it's easy to change DOM values or trigger events.

Since view also holds reference to model, it's easy to check model's attributes changes or spying on particular models methods.

First red test,

describe('FeedbackFormView.js spec', function () {
    var view, model;

    beforeEach(function () {
        view = new FeedbackFormView();
    });

    describe('when view is constructing', function () {

        it ('should exist', function () {
            expect(view).toBeDefined();
        });

    });

Here we basically testing, that FeedbackFormView should exist, so as soon as function is in place, test should be green.

FeedbackFormView could not exist without a model as well as default feedback text, that should be used as initial value of textbox. In the language of TDD, that means:

describe('when view is initialized', function () {

    describe('without model', function () {

        it('should throw exception', function () {
            expect(function () {
                new FeedbackFormView();
            }).toThrow(new Error('model is required'));
        });

    });

    describe('without default feedback', function () {
            
        it('should throw exception', function () {
            expect(function () {
                new FeedbackFormView({model: new Backbone.Model() });
            }).toThrow(new Error('feedback is required'));
        });
    });

});

To turn from Red to Green, let's add initialize function to view,

initialize: function (options) {

    if (!this.model) {
        throw new Error('model is required');
    }

    if (!(options && options.feedback)) {
        throw new Error('feedback is required');
    }

    this.feedback = options.feedback;
},

Btw, after that change it's required to fix previous test, since it start to fail.

describe('FeedbackFormView.js spec', function () {
    var view, model;

    beforeEach(function () {
        view = new FeedbackFormView({model: new Feedback(), feedback: 'TDD is awesome..' });
    });

    describe('when view is constructing', function () {

        it ('should exist', function () {
            expect(view).toBeDefined();
        });

    });

Now, let's test how rendering works.

describe('when view is rendered', function () {

    beforeEach(function () {
        view.render();
    });

    it ('should email field be empty', function () {
        expect(view.$el.find('input#email')).toHaveValue('');
    });

    it ('should website field be empty', function () {
        expect(view.$el.find('input#website')).toHaveValue('');
    });

    it ('should feedback field with default feedback', function () {
        expect(view.$el.find('textarea#feedback')).toHaveValue('TDD is awesome..');
    });

});

Here and after I'm using very nice Jasmine plugin, called jasmine-jquery. It adds a number of matchers, very useful for testing jQuery objects.

We've tested initialization and rendering, now let's test last aspect, model changes and persistence.

Suppose a user inputs nothing, erases default feedback and presses submit button. Expected behavior is expressed with this test:

describe('when form is submitted', function () {

    describe('no inputs are filled', function () {

        beforeEach(function () {
            view.$el.find('#email').val('').trigger('change');
            view.$el.find('#feedback').val('').trigger('change');
        });

        beforeEach(function () {
            view.$el.find('#submit').trigger('click');
        });

        it('email field should be invalidated', function () {
            expect(view.$el.find('.control-group.email')).toHaveClass('error');
        });

        it('feedback field should be invalidated', function () {
            expect(view.$el.find('.control-group.feedback')).toHaveClass('error');
        });

        it('website field should be valid', function () {
            expect(view.$el.find('.control-group.website')).not.toHaveClass('error');
        });

    });

That's cool. After those tests are passing, we can test that if only email is filled, but feedback is still empty, we are not able to submit the form. By analogy of previous test,

describe('only email field filled', function () {

    beforeEach(function () {
        view.$el.find('#email').val('a@a.com').trigger('change');
        view.$el.find('#feedback').val('').trigger('change');
    });

    beforeEach(function () {
        view.$el.find('#submit').trigger('click');
    });

    it('email field should be valid', function () {
        expect(view.$el.find('.control-group.email')).not.toHaveClass('error');
    });

    it('feedback field should be invalidated', function () {
        expect(view.$el.find('.control-group.feedback')).toHaveClass('error');
    });

    it('website field should be valid', function () {
        expect(view.$el.find('.control-group.website')).not.toHaveClass('error');
    });

});

And finally, if view is filled correctly,

describe('email and feedback filled', function () {

    beforeEach(function () {
        spyOn(view.model, 'save').andCallThrough();
    });

    beforeEach(function () {
        view.$el.find('#email').val('a@a.com').trigger('change');
        view.$el.find('#feedback').val('some feedback').trigger('change');
    });

    beforeEach(function () {
        view.$el.find('#submit').trigger('click');
    });

    it('should show no errors', function () {
        expect(view.$el.find('.error').length).toBe(0);
    });

    it('should save model', function () {
        expect(view.model.save).toHaveBeenCalled();
    });

});

Here, we test 2 things: first, that no validation errors appeared on form and second that save method of model is called. Jasmine built-in spy framework is used here. You can setup on any function of any object and then verify that function has (or has not) been called.

I'm skipping the implementation of that view, but you can find the code of application in gist.

Conclusions

While you typically start with defining and testing models in your application, view is integration test that helps to test actual behavior of application, depending on model states and events. You should define how "deep" you want to test the view, but my proposal is to focus on initialization, rendering, changes (validation) and persistence.

Retrospective of Trackyt.net or Best Project I Ever Accomplished

2012-12-01T16:11:00.000+02:00

It's been to years ago, I've released my own project - Trackyt.net. Month ago I've cancelled my VPS lease contract, so your would not see it available at http://trackyt.net anymore.

This project is first attempt to release something. I had some pet projects before, but never ever made them done. Trackyt.net started as simple application to learn some JavaScript programming and HTML. It turns out to be much, much, much more. Even it seems to be very simple, but I've spent a lot of energy on it.

The product did not gather any meaningful amount of users neither good amount of traffic. For almost 2 years I was investing money/time on it. So, from the first sight it might appear as failed project.

Any kind of business should be evaluated in terms of assets. It's not necessarily means money. Or more correctly, it does not meant "direct" money. I had no paying customers and I actually never thought to sell the product. But, I can prove it - every hour I spent on the project got back to me as value. And the most valuable asset for developer is skill, of cause.

I'll try to analyze what actually happened:

Web development and design: even my professional involvement into web applications, did not give me a feeling of web development. I blame ASP.NET Web Forms for that, but I realized that I lack that kind of skill. That was my first project were I did everything by myself, all HTML/CSS/JS were handmade, not stupid WebControls. My eyes opened on how many things I did not understand, how difficult the front-end might be. Crafting of UI is a huge pleasure for me, I simply like beautiful things. 2 years after I will never call Trackyt.net beautiful, but it was a great point to start.

Outcome: I overstepped the uncertainty and fears of front-end. During the JavaScript programming. I've seen a lot of value in front-end MVC frameworks, so I had no doubts of moving from jQuery based apps to Backbone.js (or other MV*) frameworks. I did a several speeches of JavaScript applications development and got really cool feedback on it.
Test driven development: practicing TDD for quite long years already, so Trackyt.net was not my first project were I applied the technique. The difference was that usually the we work with some legacy code at work, so TDD could be difficult to apply. Starting that project I had strong opinion on TDD and literally TDD'ed everything. UI, Controllers, Repositories.. JavaScript and C#. That was so great experience, I never felt on any other projects. During Trackyt.net I think I moved from Shu to Ha level of testing. Now, I more clearly see what and when should I test to stay in good shape of application.

Outcome: currently I'm professional TDD trainer at XP Injection and Trackyt.net much influenced that it happened. I share my experience with guys I show some examples of code there. I wrote a bunch of blog posts on TDD and it's Trackyt.net who gave most inputs and insights. I've implemented integration tests for my API based FuncUnit and that blog post became the part of JavaScript Weekly and still remains one of the best reads in my blog. I've learned UI testing and formed my opinion on that.

ASP.NET MVC: Never used ASP.NET MVC before, I armed with great book by Steven Sanderson I've started to learn new framework. And Trackyt.net was main playground. Starting up with MVC2 and lately ported it to MVC3 I had a chance to play different aspects of framework. ASP.NET MVC was my first serious step into web development world.

Outcome: I became a huge fan of this technology, learning it from deep and posting information on it. I had a few speeches about ASP.NET MVC.. and the biggest one on MS SWIT 2012, there ~300 persons were listened to me. Then the company I worked to were deciding about back-end technology for API of new product I helped to integrate ASP.NET MVC into existing web site and we successfully built API on it. I assisted my team mates to understand the framework, it was not difficult at all, since I knew the stuff. Currently I have a training course on ASP.NET MVC as well and already conducted some.

API oriented architecture: popularized by Twitter and GMail, the architecture and having RESTfull JSON based service behind and the JavaScript-driven application on front-end, was my high-level architecture for Trackyt.net.

Outcome: I successfully used the same ideas on other projects and it worked really well. For now I'm consulting few companies that tries to adopt same ideas. The most popular post in my blog is about build REST(like) services with ASP.NET MVC.
Continuous Delivery: being annoyed by manual update of production environment I've built simple continuous delivery pipeline that worked really great for me. During the way I've met such great tools as Jenkins, UppercuT, RoundhousE etc. That was my first try of this approach and I felt huge power and advantages of Continuous Delivery. Slightly it became one of the professional areas of interests for me.

Outcome: Continuous Delivery and Chuck Norris tools was the topic of my first talk on KievALT.NET. Since then I became an active participant of community and I really like it. Also, I'm talking about things like RoundhousE on my other speeches and trainings and I got a lot of pleasure than people stand by saying: "You know, we've tried that and it worked so nice, thanks a lot".

Code base: the code base of application is rather small. There is C#, JavaScript, SQL and some NAnt scripts. A lot of things I used there I still copy and paste (or at least taking a look) from Trackyt.net to my current projects. It became a kind of cook book, from there I could quickly pick up some recipe.

Outcome: I didn't thought above that initially, but Trackyt.net codebase also helping me to see what improvements I've made so far. For instance, I reviewed the API controllers recently and realized that I would never write anything like that. Having some code that you produced year or two ago you peer and compare gives some really interesting insights. Besides of application code itself, I've made an C# API adapter and the most significant outcome is ELMAH.MVC.

Concluding this, I would say - Trackyt.net changed the things radically. I've became a speaker on KievALT.NET and UADevClub communities, my blog received an MVB status, I improved my skills and knowledge and I do trainings and consulting. Basically, I've "rebooted" developer inside me and saw my way of constant learning and improving.

Looking back I definitely say - it was only possible because of Trackyt.net.

Without any doubts, that was the most successful project to me!

Kiev ALT.NET Re-launch with Jimmy Bogard

2012-11-27T10:16:00.000+02:00

Good news, Kiev ALT.NET community! One of the best know ALT.NET developers Jimmy Bogard is visiting us on December 11. It's been awhile since the last meetup we had, so it's just great time to gather again and listen to the presentation Jimmy prepared for us.

There will be a talk with intriguing name "Real World Polyglot Persistence". Here is the short description of it.

It always sounds easy - "use the best tool for the job". With very isolated systems, it's easy to decide RDBMS for one application, Redis for another and Cassandra for somethings else. When it comes time to building systems with multiple persistent stores, we're met with challenges in integration, existing applications, and push back from IT administrators. In this session, we'll look at the multitude of challenges of achieving polyglot persistence nirvana, and strategies for addressing associated risks.

I don't know about you, but for me it sound extremely interesting.

Meetup will take place in Ciklum, the most spectacular place in Kiev - Sky Point at 19-00. As always, Ciklum happily agreed host us.

Participation is completely free, but you have to register before. Registration is available here.

The information support by our good friend at wp7rocks.com.

Pair Programming Takes Double Effort

2012-11-23T19:12:00.001+02:00

Pair programming is very known as efficient technique of writing code. Originally appeared as one of key XP practices, it got a lot of traction. You can find many publication about Pair Programming and seems everybody clearly understands it's value. Being a XP trainer and visiting conferences related to engineering practices I usually see such situation: the question goes to the crowd "How many of you do practice Pair Programming?" and I can give a bet, only few hands will appear.. very few people are actually practicing Pair Programming. Why?

Because Pair Programming is damn hard!

There could be 2 situations with PP: first one, then both guys are completely different levels of skills - it turns to be that one (more experienced) is writing and thinking all the time, another one is almost watcher helping to find a grammar errors in code comments. At the end of the day you got 2 mans powers producing 1 mans power work. Easy journey.

Second one is different, is then 2 guys are same or equally same level. Working in such pair could be compared to wresting. You literally have to fight to move on. All the time you under pressure of another man's opinion, usually strong one. You struggle much to get consensus on different topics. You are talking all the time and arguing all the time. Sure, you got shinny-working-super-cool results much more faster by working such pair.

But there is a problem - after 3-4 hours of working that way you will be completely exhausted. Believe me, you are absolutely useless after 4 hours session of true Pair Programming. Thinking, focusing, arguing, writing, testing, debugging over and over again. It takes a lot of energy. Working a 40 hours week in strong pair will let you feel like 80 hours week. There is also psychological side as well: 2 persons could not match each over, so working in pair would be like hell.

Pair programming takes double effort. You should not plan PP session for a whole day, half day as maximum. In my opinion it's not valuable to do every task in pair, simply it's not productive. Pick up most difficult ones, ones that requires cross-functional expertise or most risky ones. As problem well kick-started, rest of things might go in parallel.

I really like Pair Programming, but I would not use it as day-to-day practice as XP suggests. Most of the time, it's more efficient to work alone.

Baby steps to Backbone.js: Unit testing of models

2012-11-22T11:54:00.000+02:00

Unit testing is important part of development process. If you care about the application state and code quality, sooner or later you start to automate the tests. My experience shows, sooner is better option. There are several approaches to unit testing, `test-first` and `test-after`. There are many holy wars appears on that topic. I would say, both options works - but `test-first` or test driven development, works better for me.

By the end of the day, it's only important that tests exists and helping to catch regression bugs. Still, developing by `test-first` helps to see the problem before ahead and in general provides better code quality (that would conclude the holy war).

Today we going to write some tests, that would cover our existing model class Feedback.js. Since the code is already written, we will go `test-after` approach. Fortunately, the code is quite simple, so it would not make a problem to unit test that. But before, let's setup our testing infrastructure.

Folders and files

We'll have a new folder called `spec`. Inside the spec folder, I'll have `models` and `views` folders that would contain tests for models and views.

Tests runner

I'll be using Jasmine test framework. It's very easy to setup it, what we need is jasmine.js and jasmine.css to be placed on proper folders and setup a test page. Test page is a simple html file, which will be entry point for our testing. If you download jasmine standalone bundle you will see SpecRunner.html inside. It could be easily tailored for custom needs.

In the head part of tests.html we need to reference all required .css and .js files.

<title>Feedback form specs</title>

<link rel="stylesheet" type="text/css" href="content/jasmine.css">

<script type="text/javascript" src="/scripts/libs/jquery-1.7.2.js"></script>
<script type="text/javascript" src="/scripts/libs/underscore.js"></script>
<script type="text/javascript" src="/scripts/libs/backbone.js"></script>
<script type="text/javascript" src="/scripts/libs/jasmine.js"></script>
<script type="text/javascript" src="/scripts/libs/jasmine-html.js"></script>
<script type="text/javascript" src="/scripts/libs/mock-ajax.js"></script>

<!-- Sources -->
<script type="text/javascript" src="/scripts/src/models/Feedback.js"></script>

<!-- Specs -->
<script type="text/javascript" src="/scripts/spec/models/Feedback.spec.js"></script>

Jasmine tests in essence

Testing with Jasmine is fun and easy. Jasmine is BDD-style framework, so if you practiced TDD with another frameworks, the style might confuse initially. Let's review the Jasmine test skeleton.

describe('Jasmine spec', function () {
    var value;

    beforeEach(function () {
        value = 1;
    });

    it ('should fail', function () {
        expect(value).toBe(0);
    });

    describe('when value is changed', function () {
        beforeEach(function () {
            value = 0;
        });

        it ('should pass', function () {
            expect(value).toBe(0);
        })
    });
});

In this example, value is our SUT (System under test). beforeEach() function is `context-establish` function, where SUT is initialized (in TDD it's both arrange/act). it function is assert part. Here, we set our expectations about which state should SUT be in to. Notice, that beforeEach are nested into describe, so you tweek SUT depending on case.

Writing some tests

The only one functionality that Feedback.js model contains currently is validation. Let's test that.

describe('Feedback.js spec', function () {
    var model;

    beforeEach(function () {
        model = new Feedback();
    });

    describe('when model is validating', function () {
        var errors;
    });
});

This is something to start with. It does not do any asserts, so now we'll add some real cases. First case, is than both `email` and `feedback` attributes are absent.

describe('when email and feedback fields are absent', function () {
    beforeEach(function () {
        errors = model.validate({});
    });

    it ('should have 2 errors', function () {
        expect(errors.length).toBe(2);
    });

    it ('should have email fields as invalid', function () {
        expect(errors[0].name).toBe('email');
    });

    it ('should have feedback field as invalid', function () {
        expect(errors[1].name).toBe('feedback');
    });
});

It's is possible that user put email, but forgot about feedback.

describe('when email is set, but feedback is absent', function () {
    beforeEach(function () {
        errors = model.validate({ email: 'a@a.com'});
    });

    it ('should have 1 error', function () {
        expect(errors.length).toBe(1);
    });

    it ('should have feedback field as invalid', function () {
        expect(errors[0].name).toBe('feedback');
    });

    it ('should have error message', function () {
        expect(errors[0].message).toBeDefined();
    });
});

Moving on, user might put feedback but forgot about email.

describe('when feedback is set, but email is absent', function () {
    beforeEach(function () {
        errors = model.validate({ feedback: 'TDD is awesome'});
    });

    it ('should have 1 error', function () {
        expect(errors.length).toBe(1);
    });

    it ('should have email field as invalid', function () {
        expect(errors[0].name).toBe('email');
    });

    it ('should have error message', function () {
        expect(errors[0].message).toBeDefined();
    });
});

Tests report

If you now try to run test.html in browser, you will something like that.

Conclusions

Testing of Backbone.Model's is pretty simple thing. It's nothing more than testing some business logic, that might reside inside. Testing of views is a bit trickier thing, but we will see how to do that next time.

JavaScript Object Creation by New Operator

2012-11-12T15:50:00.000+02:00

There are different approaches of how to create object in JavaScript. C# and Java programmers are commonly starting with creation by new operator, since it very close to same practice they got used to.

function Person (name) {
    this.name = name;
}

var person = new Person('John Smith');
console.log(person.name);

If you try to run this code, you will see 'John Smith' in console. Now, try to delete new operator.

Instead of 'John Smith' you will see undefined. Why?

The difference is that without new operator it is just function call. During the call `this` points global namespace. If you running the code in browser, global namespace is bind to `window`.

It's important to understand how new operator works. Internally, operator new is converted to NEW(Person, 'John Smith');. It does several things.

Creates new native object and initializes the __proto__ of object by function.prototype.
Calls function, applying newly created object as value for this.
Returns newly created object.

It can be expressed in this kind of pseudo-code:

function NEW(f) {
    var obj = { '__proto__': f.prototype };
    f.apply(obj, arguments.slice(1));
    return obj;
}

(It's a bit more complex actually, for details check this great answer on SO).

It means that during function call with `new operator()`, this always points to a new object, created based on function prototype. You can initialize the properties of new object inside the function. It's no longer a simple function, but it is constructing function, or more simply - constructor.

To distinguish between constructors (that are always supposed to be called with `new`) and simple function, there is a convention to name a constructors with capital first letter (not person(), but Person()), just to give you some tips while you writing the code.

Knowing NEW() details of work and following simple conventions for constructors will help you to understand language better and prevent many stupid errors.

ELMAH.MVC 2.0.2 is out

2012-11-09T17:21:00.001+02:00

ELMAH MVC 2.0.2 has been just pushed recently. This is a contribution by James Crowley which adds a special configuration key that prevents ELMAH.MVC to setup a global `HandleErrorAttribute()`. It's in particular useful, than you already setup some configuration inside the app, so you don't want default behavior.

Inside the web.config file you will find a configuration setting for that.

<appSettings>
 <add key="elmah.mvc.disableHandler" value="false" />
 <add key="elmah.mvc.disableHandleErrorFilter" value="false" />
 <add key="elmah.mvc.requiresAuthentication" value="false" />
 <add key="elmah.mvc.allowedRoles" value="*" />
 <add key="elmah.mvc.route" value="elmah" />
</appSettings>

It is elmah.mvc.disableHandleErrorFilter. By default it's `false`, meaning `HandleErrorAttribute()` from ELMAH.MVC is used. To disable it, just set true to this setting.

And btw, it's already 30.000 downloads of NuGet package! Huge number, thanks a lot for all users and contributors.

Baby steps to Backbone.js: Model Validation

2012-11-08T09:42:00.000+02:00

Let's go back for a moment for previous post where we started to bootstrap some basic Backbone.js application. It's very simple now, just gathering all data and posting those data to server.

Any reliable system is almost impossible without validation. If some field is required or must conform to some particular rule, it should be validated as soon as possible and validation information should be displayed to user. User then applies corrections and re-submit data.

In case of `Feedback` model, we are interested that user always input her email and feedback message. Backbone.js provides very straight forward for models validation. If model requires validation, it should implement validate method.

So, let's extend our model with validate method.

var Feedback = Backbone.Model.extend({
    url: '/feedback',

    defaults: {
        'email': '',
        'website': '',
        'feedback': ''
    },

    validate: function (attrs) {
        if (!attrs.email) {
            return 'Please fill email field.';
        }
        if (!attrs.feedback) {
            return 'Please fill feedback field.';
        }
    }
});

As you can see, in case of email or feedback is missing, we just simply return string with error message.

To better understand what's going on, let's look on some piece of the code from Backbone.js framework. Namely, to `_validate` method of `Backbone.Model`, which is actually responsible for validation.

_validate: function(attrs, options) {
    if (options.silent || !this.validate) return true;
    attrs = _.extend({}, this.attributes, attrs);
    var error = this.validate(attrs, options);
    if (!error) return true;
    if (options && options.error) {
       options.error(this, error, options);
    } else {
        this.trigger('error', this, error, options);
    }
    return false;
}

You can see, if `validate` returns either undefined or null or false, `_validate` just returns true - meaning the model is valid. Otherwise, it would check if `options.error` function initialized and call it, if not model event `error` is triggered.

During the model saving, we typically provide both success and error callbacks. It means, that error callback will be called, if model does not pass validation requirements. Inside the callback, we might decided what to do with errors. Right now, let's just do alert.

var options = {
    success: function () {
        alert('Thanks for the feedback!');
    },
    error: function (model, error) {
        alert(error);
    }
};

var feedback = {
    email: this.$('#email').val(),
    website:  this.$('#website').val(),
    feedback: this.$('#feedback').val()
};

this.model.save(feedback, options);

Notice that `error` callback receiving model itself as first argument and error object (one returned from `validate` method) as second argument. Let's try this code: leave email and feedback fields empty and press submit button.

There are several drawback of such implementation, though. First of all, `alert` windows are awful, second if user corrects email, next time she presses the submit button next alert with another message appears. This is terrible UX, so let's fix it.

So, we should basically do 2 things: aggregate all errors during validation and apply some nice styles to errors.

Instead of returning simple strings, we'll return an array of objects, containing name of failed and field and message.

validate: function (attrs) {
    var errors = [];

    if (!attrs.email) {
        errors.push({name: 'email', message: 'Please fill email field.'});
    }
    if (!attrs.feedback) {
        errors.push({name: 'feedback', message: 'Please fill feedback field.'});
    }

    return errors.length > 0 ? errors : false;
}

Change the `save` method options, to show errors if any error appeared and hide errors if save was successful.

var me = this;
var options = {
    success: function () {
        me.hideErrors();
    },
    error: function (model, errors) {
        me.showErrors(errors);
    }
};

And implement 2 simple methods:

showErrors: function(errors) {
    _.each(errors, function (error) {
        var controlGroup = this.$('.' + error.name);
        controlGroup.addClass('error');
        controlGroup.find('.help-inline').text(error.message);
    }, this);
},

hideErrors: function () {
    this.$('.control-group').removeClass('error');
    this.$('.help-inline').text('');
}

Let's test the code. As all fields are left empty, it will look like,

As fields are filled and form submitted, all errors are cleared from form.

Conclusions

That was very simple "baby-step" style of approaching model validation. I would could it, validation "from the box". Even if it's very useful there are a lot of different approaches of making even things better. The source code is availble on github.

Stay tuned for next Backbone.js baby steps soon.

How to run multiple AJAX requests

2012-10-31T21:12:00.000+02:00

Suppose you have a list of resources that you would like to retrieve by means of AJAX. `$.ajax()` (or it's short variants like `$.get()` or `$.post`) is usual way of making AJAX calls, it works great than you need to fetch one.

var url = '/api/resource/1';
$.get(url, function (r) {
    // use response
});

Even in case of several it might be still usable,

var url1 = '/api/resource/1';
var url2 = '/api/resource/2'
$.get(url1, function (r) {
    // use response from url1

    $.get(url1, function (r) {
        // use response from url2
    });
});

You can easily see, if you have more than 3 you are trapping into "callback hell". Furthermore, if you have a list of url's to fetch and the size of that list is dynamic, it's not even possible to build structure like that.

Not long time a ago, I've been exactly into this situation. So, I have a list of resources to fetch, I need to issue them one-by-one and I want to have only one callback, that would pass all fetched resources in one object. Initially I thought it's not even possible, at least with-out creation of some ugly code. But with great help of my colleagues the problem been solved.

jQuery Deferred Object is something I've head about, but never got a change to play with. It turn's out to be very nice and simple idea. Deferred allows you to build chainable constructions. Actually, `$.ajax()` always returns deferred object, so you can apply `.done()`, `.fail()` functions on it.

Here is the code, that you could be re-usable in the same situation;

var pipedAjaxRequests = function (urls, callback) {
 var responses = {};

 var promise = $.Deferred().resolve();
 _.each(urls, function (url) {
  promise = promise.pipe(function () {
   return $.get(url);
  }).done(function (response) {
   responses[url] = response;
  });
 });

 promise.done(function () {
  callback(responses);
 }).fail(function (err) {
  callback(responses, err);
 });
};

It does create the pipe of `$.get()` calls and place the responses in one response object. At the time then all resources are fetched, the callback is called. In case of errors, second parameter of callback will have error info.

Thanks a lot to @antsamar and @alex_gonchar for helping me out.

Baby Steps to Backbone.js: Starting up

2012-10-25T22:40:00.001+03:00

Many times then I speak to people regarding usage of any kind of MV* frameworks on front-end I hear common objection: "but we already have a lot of code written on jQuery/Dojo/Whatever, I think usage of additional framework would be impossible". This is not actually true. Backbone is very lightweight and could fit into any existing application.

Baby steps strategy is the most efficient way of trying the things. You start with something really small, enhance it over the time and expand for other application areas. Now, let's imagine you got an existing application, you wish to start using Backbone.js to improve that. I would like to show you, that it's absolutely possible.

Suppose, you want to add a feedback form for your app. Let's implement that with Backbone.js.

Applications, Models, Views

There are no such thing as `Controller` in Backbone.js. But you have to have some kind of entry point, some place with `main()` function inside. I got used to call this place - Application. Basically, the application is a module, which is responsible for initialization of model, instantiation of view, rendering the view.

The `Model` is object that holds the data. It could be fetched and persisted back to server.

And finally view is object that produces markup, hooking up events and updates View from data in Model and otherwise.

We are going to create all three things. It makes a lot of sense to breakdown the folder structure of to reflect logical meaning of each entity of Backbone application. So, we'll create 3 folders for apps, models and views.

Setup Backbone.js

On a target html page we should place 2 additional script tags.

<script src="/scripts/libs/underscore.js"></script>
<script src="/scripts/libs/backbone.js"></script>

Besides of that, let's add one more div. The one that application will be using for rendering views.

<div id="app" class="container"></div>

Application entry point

Let's create a new file in `apps` folder and call it `FeedbackFormApp.js`. It would be very simple.

$(function () {
    var model = new Feedback();
    var view = new FeedbackFormView ({model: model});
    
    $('#app').html(view.render().el);
});

Then DOM is ready, we instantiate new model object and view and render the form into DOM element with id - app.

Feedback model

Now, let's define a model. Create a new file in models folder and call it `Feedback.js`.

The model refects the data we are collecting/displaying to user and it's typically stored on server (sometimes on localstorage). Feedback model will include 3 attributes: email of user, his web site and the feedback text. In terms of Backbone.js that would mean.

var Feedback = Backbone.Model.extend({

    url: '/feedback',

    defaults: {
        'email': '',
        'website': '',
        'feedback': ''
    }

});

The url property of model object is used by Backbone for persisting object to server. The default are defaults values for model attributes.

Rendering the view

The most interesting things in Backbone.js app is happening in Views. Add new file to `views` folder - FeedbackView.js.

The skeleton of view would look like this:

var FeedbackFormView = Backbone.View.extend({
   className: 'row',

    render: function () {
        return this;
    }
});

This view, does do nothing. So, let make it render the template. The template would be very simple form.

There are different approaches, there to actually place the markup. It's possible to place it in the same .html file where view starts and extract it by jQuery, it's possible to place to separate file and load it asynchronously by $.get(). But, according to baby steps scenario - we'll place it directly to .js file. So, inside the view we'll add property called template.

template: '\
 <form>\
  <legend>Share the feedback</legend>\
  <div class="control-group">\
   <label>Email</label>\
   <input type="text" id="email" placeholder="Your email address...">\
  </div>\
  <div class="control-group">\
   <label>Web site</label>\
   <input type="text" id="website" placeholder="Your website...">\
  </div>\
  <div class="control-group">\
  <label>Feedback</label>\
  <textarea id="feedback" class="input-xxlarge" placeholder="Feedback text..." rows="6"></textarea>\
  </div>\
  <button type="submit" id="submit" class="btn">Submit</button>\
 </form>\
',

And render method, would be:

render: function () {
    this.$el.html(this.template);

    return this;
}

First test

Basically, we are ready to see some results. Modify the target view by adding references to model and view.

<script src="/scripts/src/models/Feedback.js"></script>
<script src="/scripts/src/views/FeedbackFormView.js"></script>
<script src="/scripts/src/apps/FeedbackFormApp.js"></script>

Fire up the application and go to target page. You should be able to see something like this (for styles I use Twitter Bootstrap here).

If you see the form on screen, it means application started properly.

Submitting the form

We enter the data into input fields and as soon as data is in-place we are ready to submit. It means we have to catch an event of `Submit` button click and store the model to server.

To explain to Backbone.js that you interested in particular DOM event, you need to add another property to view. It is called events.

events: {
    'click #submit': 'submitClicked'
},

You can read it as - if click happed to element with id `submit`, call function submitClicked.

submitClicked: function (e) {
    e.preventDefault();

    var options = {
        success: function () {
            alert('Thanks for the feedback!');
        },
        error: function () {
            alert('Opps, your feedback has not been submitted, please try again.');
        }
    };

    var feedback = {
        email: this.$('#email').val(),
        website:  this.$('#website').val(),
        feedback: this.$('#feedback').val()
    };

    this.model.save(feedback, options);
}

What it does, is first of all prevent the default behavior of event. So, the form would not be actually posted to server. Second, it prepares the options object's with success and error handlers. After we initialize all attributes with actual values from corresponding inputs/textbox. And finally we call model.save().

Second test

Fire up application again. Now, if have properly set-up server side to receive the HTTP post call to `/feedback` you actually post first feedback.

From my server trace, I can see that new object is received.

Now, it's the server job to put to storage, allocate the id etc.

Conclusions

In this first baby step, I just showed how it's possible to adopt Backbone.js for existing apps. It does not make a lot of sense to re-write your existing code with Backbone.js, but new widgets/elements/applications could be created with Backbone, having a benefit of it's structural approach.

I'll go on with baby steps, showing other features of Backbone.js.

Looking at TypeScript

2012-10-05T21:24:00.000+03:00

Four days ago my twitter has been nuked. The bomb has exploded after TypeScript site link has reach to top of Hacker News and people watched the video of Anders Hejlsberg who generally described the language features and showed some example. Everybody were talking about TypeScript.

For ones who missed the video (I can't believe you did) I shortly describe - TypeScript in new open source project, by Microsoft. It's leader Anders Hejlsberg is very famous developer (my bad, I always forget his name), creator of C# and one of the persons who most influenced .NET platform. TypeScript compiled down to JavaScript, but it introduce the types checking during compilation, so it could be called 'static typed language'.

First of all, TypeScript is definitely not the first language, that complies to JavaScript. It's not the first one that augments JavaScript with new statements like class, interface or module. So, what's so interesting on it?

I've been using static type languages for about 10 years. I've very much got used to compiler error messages and truly believed that it helps to build applications. Meaning, the complier is first guard towards the 'good' code. To the code that could be called reliable, error free.

But situation much changed after I start programming JavaScript.

I feel myself quite productive with using of using JavaScript. Of cause, there are some best practice & patters are collected nowadays, we have better tools, faster engines and JavaScript has been so much adopted by community. But JavaScript is indeed, so powerful language. I really like the dynamic typing, that bit more forces to unit testing, making code changes more easy in the same time creating some very beautiful code structures.

I know that some people are saying, "we don't need any static typing for JavaScript; please don't change the language". Such developers could be called "purists". And they are absolutely right - if you feel confidence in something you do, you should not change the way you do it.

In another hand, I came to conclusion that it's not dynamic types that makes me productive with JavaScript, but rather the experience I gathered with programming lately. It's always only experience, that allows you to work faster, better quality and had fun of your job.

And it's absolutely not about Static vs. Dynamic languages.

Static types are not useless, though. I think, in average it reduces the chances of bug introduction into the code. That's at least what I've seen so far. And that's why "purists" are running JSLint. Basically, Static Types should provide better application quality. This is of cause not completely true, since we know great software written in Python and poor systems written in C++.

It' about the engineers who build that software.

In my opinion the TypeScript will grow. It would have it's own army of fans, like CoffeeScript have or Ruby have. The code that TypeScript outputs is nice and clean, that make easy of debugging it. TypeScript is designed to be closer to ECMAScript6 (Harmony), so in near future the pure JavaScript would start to look like TypeScript.

TypeScript is interesting project and open minded guys will like one.

The Game of Life

2012-09-27T11:52:00.001+03:00

Last weekend the good friends of mine were organizing great event, CodeRetreat in Odessa. I supposed to be there, but due to bad luck I missed that. Nevertheless, I was very interested in CodeRetreat idea, so I followed up the materials and learned a bit about it.

CodeRetreat is about the software craftsmanship. You focus on 4 principles of Simple Design, work in pairs through the series of time boxed sessions, each time starting from scratch (yes, all code produced on previous sessions is destroyed with no mercy). All of that aim one simple goal, became a better developer. For the implementation they selected famous Game of Life. The cellular automata, with simple rules but given very interesting results and foundation for numerous researches.

To do not stay with my misery of missing event, I decided to "play" game of life at home. Trying to follow the rules of sessions, I started to write some JavaScript code. It's even hard to tell, how much fun I had during this implementation.

Tests, code, tests

TDD is very recommended way of development in CodeRetreats. I love TDD and fortunately the game of life is very TDD friendly. It's all about the logic. Logic seems to be very simple and easy describe with tests. For my JavaScript testing I used to use Jasmine testing framework. Jasmine is BDD tests style, which was a little difficult to me at very beginning, but not I tend to write all my tests with BDD style.

I've spent first two sessions for idea elaboration. At the end third session, I got something working. As I said, the process of writing that code was so fun to me, that I even decided to gist the code I created so far.

My big disappointment after was that code is actually not working.

Understanding the problem

Even if I had good tests suite, that showed my code works as expected the game was broken. And the issue is that I didn't understand the domain good enough. It took me 4 sessions (about 4 hours) to finally understand the game.

I proved it once again for myself, there are no perfect code; the code you created at first time is probably broken (unless you understand the domain perfectly, but it's rarely happen in reality). It's OK to completely remove the code you created before and start from the beginning. And with each iteration you moving faster and faster.

Knowing the requirements I was able to create good test suite.

Algorithms and data structures

During the implementation, you have to recall some basics algorithms and data structures. My initial implementation was based on usage of 2-dimensional arrays. It seems to be very natural fit, since the game is happening on orthogonal grid of square cells. But during the implementation of cell replication logic I suffered that design.

Index arithmetic is very tricky and error-prone stuff. So, after several tries I switched from array into the list of cells, each cell holds it's state and position. The tick method of became very elegant, containing 2-pass procedure - one to calculate next state of each state, second is to switch to new state.

Again, I was so happy with code. It looked very readable as for me, without nested cycles and if-else statements.

Visualisation

You can really understand if something works or not, only if you see it in action. I had to have some UI to see, how game is actually working.

I've created very simple HTML based UI. The number of div's which change it's state, depending on cell state (alive or dead).

The visualization of results is very important part. It's only then I tried to run the game on 64x64 square, I realized that performance of my implementation is so terribly poor. It runs very slowly on Chrome, it makes IE10 die.

It means that, all beautiful code, tests, specs and so on - is almost useless, than it comes to performance. My 2-pass algorithm, with a simple implementation is not "production" ready, if we talk about some real software. Unit tests are usually done on smaller sets of data. Visualisation and trying the things on larger set of data opens up the reality.

Conclusions

As I already said, it's so much fun. It makes you feel like "back to roots", forget about your enterprise stuff and do some real work. Besides it's great TDD exercise. It's probably to big to be called code kata, but it is still great for sharping an axe. Focusing on simple design is important. But making things "visible" and running them in real mode is vital.

The most important conclusion for me is: I'm still newbie developer, with so many areas to improve.

Company Days 2012 in E-conomic

2012-09-20T16:58:00.000+03:00

Company Days is a yearly event in E-conomic, then all employees gather together. It's usually happen in the middle of September, the time than Copenhagen is especially beautiful. It's been great week, primarily because of opportunity to meet guys whom we work very close to. Besides the developers, primarily located in Denmark and Ukraine, business and operational people from UK, Sweden, Norway, Spain, Germany etc. are also coming, so it makes very cool international environment.

This year was a little special, since we had additional fun. Our CTO had organized the hackathon. The whole day event, supposed to create some valuable hacks for E-conomic product. All developers has been spitted on pairs and extended with business representatives. I had a team of 4 people - 2 developers and 2 business guys. Started at early morning near the blackboard, it was so nice to be part of process where the value is born in such extremely short period. We finally selected the idea, which seems to be very cool in terms of business and realistic in terms of one day implementation.

It's been a long day of developing, debugging, demonstration and changes. Our product owners were always near us, giving both valuable feedback and supplying us with coffee and Danish chocolate sweets (that worked so good to me, since I needed sugar all the time). About 22.00 we got something that looks like a demo version of feature we wanted to produce. We've spent near 1 hour more, to show everything to PO's and fix some small bugs. I felt very tired at the end.

Next day at 14.00 was big time of presentations. That was the funnies part. I have to admit, there was several really great hacks. In the same time some our PO's are so cool of selling things that they turned the presentation into real show (kind of TV market, I would say). Everybody had a great joy, especially after words like "I've been asking for this feature for 2 year, and those guys created it in 16 hours". It's a bit of irony, but a bit of true as well. I know the jury that included CEO, CTO, Head of PO's etc., we definitely happy to see the results and some hacks will be turned into the products really soon.

Apart from the hackathon, we had traditional speeches of CEO, Marketing people and guys from other departments. There was also a bit more activities, including jogging in which I took a part and did 8km distance. And of cause, Friday boat trip and party in restaurant. Party was so cool, that I almost missed my flight in the morning (but that's a completely different story).

I would like to say thanks for everybody involved, I was happy to meet you guys once more.

How My Wife Became a TDD Fan

2012-09-10T16:36:00.000+03:00

My wife, Sasha is not (yet) IT person. Living with developer for 5 years, she knows only few details of developers job (like, they do code and sitting late nights to make it work). My bad, I never spent much time to explain what really my job is.

Recently she joined the training courses on software testing, to find the job in IT area in perspective.

After her second lesson she got back home and we had a talk about what she is actually studying there. It appeared they started with a software development processes, understanding how the software is actually created. So, they described waterfall (even if nobody using it any more) and some agile frameworks (scrum of cause), and left with a homework, to read what else practices exists.

- So, did you find anything interesting?
- I read about few, but I think I found the most interesting one..
- What's that?
- Its called Extreme Programming..
- Hm, I never heard about it. Tell me more (trolls face on).
- Alright, so it's a different practices as Code review, Pair programming, Collective code ownership.. But you know, what's the greatest one?
- No, what's that?
- Its called Test Driven Development, or TDD.
- What's the point of this TDD? (troll face is still on).
- Can you imagine that you create the test before you create any application code, make sure it doesn't work and after you fix it, so you always sure that application works fine! That's sound so interesting and so valuable, I can't wait to try it!

I had to put my troll face off, after that. I could not believe what I'm hearing. That was simply amazing!

- Do you know, I'm a big TDD fan and the training courses I do from time to time are "TDD in .NET", so we teach people of using TDD practices in real projects.
- Fantastic, I never thought your job is so interesting!

The big disappointment to her was that testers are not doing TDD (she though it's actually the testers job). Nethertheless, I got one interesting thought.

During the trainings on TDD we try hard to explain people the value of TDD and usually there some guys who just deny the idea, seeing absolutely no value in it. That actually show some human feature called "open mindness".

As less you know, as easy to you to get new ideas.. As much you know, as less agile your brain could be, as hard you can adopt anything new.With more experience you got, it's harder and harder to adopt new things. This is only the matter of discipline and hard working to stay update and actually try things out. It's also a big patience till some tool or technique became beneficial to you.

The point of my story is. Developer have to be open minded person during whole career. Something you did yesterday, may became obsolete tomorrow. There are many things outside your comfort zone you might missing, staying in comfort zone for long time.

Back to Sasha, I always knew she is very bright lady. Now I hope she became bright engineer, good luck to you, honey.

Why Use Backbone.js?

2012-09-07T18:30:00.000+03:00

Even JavaScript language and front-end development has been much matured recent time, I still see a lot of confusion about usage of different frameworks and libraries.

For a half of year I use Backbone.js and feel much satisfied with it. It's very popular library, probably because of personal popularity of the creator of Backbone.js Jeremy Ashkenas, very much known also as author of CoffeScript language.

Frameworks and libraries

There are differences between frameworks and libraries. In one sentence, "library is then you call some code, framework is then your code is called from somewhere". The Backbone.js is clearly library. You usually have a lot of different options with libraries and less with frameworks. It's very minimalistic, actually.

At core it only contains of only 4 components (Model, Collection, View, Router). This minimalism is both power and weak side of Backbone.js. The power is that you can build things whatever you like, Backbone fits the experience really smoothly. In the same time, you are really confused the time you just started, since you simply don't understand how to make everything work together properly.

The essence of Backbone.js

In one of the podcasts with Jeremy, he said "Backbone is something that almost every developer will come to theirselves.. dealing with JavaScript applications for a while". I could not agree more. If you have previous experience in programming and you see the value of architecture and design, you will definitely start to invent something similar to Backbone.

After some time spend of development jQuery based application you will realize many fundamental issues, like: data does not belong to DOM, events are not limited on jQuery and so on. But the main issue is jQuery apps usually violates the "Single Responsibility Principle", mixing and manipulation with data and views in the same time. Experienced developers, tries to eliminate SRP issues as soon as possible, almost naturally coming to MVC pattern.

In essence the Backbone is a way to structure you application better. It makes clear de-coupling between data and views that render that data. It's nothing more than that.

Abstracting things out

Programming is a matter of abstractions. As better abstractions you have as better code you have.

Every application works with data. The data does not appear in browser just like that, it have to fetched from somewhere. It's also have to be persisted somewhere. The data could be changed and you have to validate that change is right. If some part of data is changing, you want to be notified on that change. Notice that, this is a very common functionality you want to keep between all data classes - initialization, validation, persistence. This is where the Backbone.Model comes out. With Backbone.Model all that things are already "in the box" you just need to apply your own strategies of implementation.

You typically don't deal with one instance of model. REST interfaces are usually expose something like /api/tasks or /api/photos and so on. You need to group the models into collections. Collection (similar to model) are able fetch and persist itself, all it needs to know is the actual type of Model and URL. This is where Backbone.Collection shies. You are keeping all models close together, if some model become destroyed the collection will be updated, so it always in consistent state.

With view is basically render your models as DOM structure. So, the Backbone.View is abstraction with primarily method - render. Backbone does not say, how exactly you are going to do that. You can create handcrafted HTML and append it DOM, or use some templating mechanisms. Instead, it provides you convenient methods for listening to view events (like clicks, focusout or any other DOM supported events). Inside the handlers you either could update related model or apply some changes to view parts, whatever.

And finally Backbone.Router is a facility to building, so called Single Page Applications (SPA). SPA's most popular example is GMail. You browsing emails, writing and sending - without and page reloads. What's changing is only hash part of URL (like #inbox, #sent, #all). Router is handling hash change events and triggers registered handler. Inside the handler, you can initialize the corresponding application.

Don't repeat yourself

Now, please let me know. How many times did you create (read copy-n-paste) the code for RESTful data persistence? How many times, you did you create code for validation? How many hours you spend for looking for some event listener provoking the bug in your app and hiding somewhere among 200 .js files?

If your answer, more that 2 - stop doing that. Don't repeat yourself - reuse. And better - reuse from best.

Conclusions

There are great solutions, created by people experienced than me, amplified by huge community behind. Backbone.js is one best representatives of such solutions. Having a something that I could rely on, that works good and there places to get help is very strong reason for me, to keep doing that, instead of re-invent wheel yet another time.