Backbone gives us a very powerful set of tools. It gives us models, views, and routes – all event driven, consistent and beautifully embrace underscore.js functionality. Being a library rather than a framework, Backbone doesn’t give us application structure. That “glue” we need too initialize the app and glue all the pieces together.
Since coding is by far easier than explaining, I programmed a Todos app in order to demonstrate how this can be done with Asynchronous Module Definition (AMD) using RequireJS. Continue reading →
RPN (Reverse Polish Notation) is a mathematical notation wherein every operator follows all of its operands, which was designed to reduce computer memory access and utilize the stack to evaluate expressions.
A typical interview question would be to implement a RPN calculator since it is simple enough to resolve in less than an hour and it tests our ability to notice a problem that cries out for a stack based solution.
It also tests our absence from the “Introduction to Algorithms” course in college.
Obviously there are other algorithms to implement RPN, such as recursion, but using a stack will be more efficient: a stack will take O(n) times rather than O(n2) for recursion.
PubSub (or the observer pattern) is obviously the hottest pattern in client side development, and I would like to take a shot at trying to refine the best practices for using it in a flexible and robust way.
The definition provided in the original Gang of Four book on Design Patterns states:
“Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically”
As in any design pattern, an important part is to keep the application loosely coupled and with high cohesion. Continue reading →
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Special cases aren’t special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one– and preferably only one –obvious way to do it.
Although that way may not be obvious at first unless you’re DutchDoug.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea — let’s do more of those!let’s fake those!
I ran into an old post by Philipp Lenssen on how good programmers are lazy and dumb.
I totally agree with the title and most of the content. However, I believe that the lazy and dumb engineers are the better ones for a different reason:
Because code is liability, and by writing a lot of code, you are taking upon yourself (or your team) liability to test, maintain, document and improve it.
A lazy developer will first look for an existing solution that already has all the above and which is qualified to solve the aimed problem.
Because a dumb developer writes code that is simple enough, for dumb engineers, just as he is, to be able to understand and work with.
“Smart” engineers tend to write sophisticated programs that nobody but them or the like of them can understand. I guess it makes them feel smart.
Dumb engineers look for simple, encapsulated, loosely coupled solutions that anybody can understand.