Web dev tips

The fact that all the CPU work in a node.js process is done by a single thread continues to amaze me. But, considering node.js cluster API, it all makes so much sense! Having just one thread per CPU core is the "ideal situation", which barely any piece of software ever achieves. I remember good example on this topic from "CLR via C#" book  —  it's about Windows native File Open dialog, which creates tens (!) of new threads when it opens up. So it's all good, but we pay the price for that in the amount of asynchrony we put into the source code. There are good libraries out there, which help in taming this additional complexity, but they usually don't focus on decreasing perceptual complexity of the source code. This is what I tried to do in the tiny node.js library, called " parellel-io ". It helps in situations, when you have multiple I/O operations, which you want to run in parallel and then conveniently process their results all at once. F...

Recently I was implementing a small workaround solution for angular.js date input control and discovered useful $parsers/$formatters pipeline of NgModelController (controller of ng-model directive). In the following example, ngModel is an instance of ng-model directive controller. We get a single instance of it per DOM element. Many HTML element directives may interact with ngModel, each putting parser handlers to the beginning of parsing pipeline and formatter handlers to the end of formatting pipeline. These pipelines transform values between ngModel.$viewValue (what you see) and ngModel.$modelValue (what you get in your model). Using directive priority setting, one can ensure that $parsers and $formatters are in the correct order. The problem with the control was that it did not support manual date entry. We were using old version of angular.js, without ng-model-options support, so on every keystroke, this control tried to convert input string value to date object. This obv...

I realized how important it is to understand logical SQL query processing logic. One example of how something totally new could be found by looking at this logic is what does actually logically happen, when two tables are joined with an OUTER join. OUTER join is actually just another logical step after "INNER join" logical step. This step adds rows, which do not satisfy ON predicate from left, right or both tables (latter - in case of FULL OUTER join). As a result, in the following example, in the first case you could see rows, where city does not equal "Madrid" if corresponding customers don't have any orders (such customer records will simply be added after ON predicate checking): In the second example, you are guaranteed to get only Madrid customer records.

Imagine you need to build an algorithm to sort certain .NET object collection by any number of expressions. These expressions are provided by the caller as another collection of objects, describing sequence of properties and sorting directions: The key to solving this issue is to build a linked list of Comparison<T> delegate wrappers. Each of these wrappers would compare objects and, if they are equal, call next Comparison<T> until it reaches the end of the chain. This is the comparison liked list: And this is how to use it: