The way you structure your code is a key factor when you define your source code organization. It will make your life easier or miserable, and once this structure is established it will become a really tedious task to redefine it. That’s why you know about the different patterns available and choose the one fits your project best. But, why should I care about modules? Well, is the way Javascript offers to organize and encapsulate your code, and if you don’t think you need to do it, because maybe it’s a small project or you don’t care at all, trust me, you are making a huge mistake!

Javascript is an old well-known friend that is growing rapidly and gaining traction since Node.js, a command line Javascript interpreter based on Chrome V8 Javascript Virtual Machine, was published. Its community is building great stuff, and more and more companies are moving into this stack, with a high success ratio. http://nodegeek.net Luckily for me, for my last two professional years I have been involved in one way or another with it, been able to relearn the language and discover its framework. And since not long ago, I’ve been writing articles for a new site where I could focus about this amazing programming stack:

Code modularization, achieved in one way or another, is a technique a good developer must aim for because it helps keeping things small, well-tested and organized. And of course, it follows the DRY directive. So as a Node.js developer (and maybe contributor to the Open Source), creating and publishing an NPM module is one of those steps you will eventually face. Probably if any Node.js developer would have to pick an indispensable tool of the ecosystem, npm would win by far. Its greatness resides in how much easy is to build applications using on of several modules, each of them providing one certain functionality, as if they were building bricks, picking the right tool for each task.

The Node.js ecosystem is quite young and prolific: new tools appear almost every day or week, changing and turning upside down your current workflow, always trying to squeeze a little more productivity to your time and effort or simply making your work easier. As an example, take a look on the NodeFramework page, where Azat Mardanov (@azat_co) collects lot’s of frameworks and utilities related to Node.js. Or NodeWebModules, more web oriented than the previous one, from Caio Ribeiro Pereira (@crp_underground).

Talking about Node.js history, it’s talking a little bit about V8 history. But let’s start with a one line definition of what it is: Node.js is a platform built around Google Chrome V8 Javascript engine, to create lightweight, fast, scalable, event-driven and non-blocking I/O applications. So lets begin talking about Node.js origins, the V8 javascript engine. V8 is an opensource project by Google and it is in the very core of Google Chrome browser. Its first public release was on September 2, 2008, same date Chrome’s first release was announced. It was a big step forward in browsers’ performance, and it pushed browsers’ technology to a new whole level. It’s written in C++ and its biggest revolution was that it precompiled the Javascript source code to machine code instead of just interpret it and then applied a JIT process again in runtime to improve dynamic code execution.

Wellcome to this new site where you’ll find lots of information about Node.js, Javascript and HTML 5 technologies! This project is a chance for me to share my passion about these new and amazing technologies, trying to make you easier to step into it and to discuss and enjoy technology talks to whomever who wants to. It will be mainly focused on Node.js, but sometimes we will talk about generic Javascript or even frontend Javascript related to HTML5 capabilities.

Javascript Allongé@raganwald is one of the more refreshing coding books I have read in a big while. Usually when I face a programming language book, I skip the beginner chapters (if I already know the language, of course) and go directly for the juicy ones, but with this one I tried to follow it from end to end because I read some comments on twitter telling that the way basics are explained, become a really solid base for the language, so I gave it a chance.

Last Friday I got some spare time (finally!) and, with the help and tools of my friend Alfredo, we placed a button in the RaspberryPi case so, when I push it, a custom command its executed on the RaspberryPi, like for example, a clean system shutdown. First lets start with some pictures of the final result: And now the schematics (pins used in the schematics are 3.3v, GND and GPIO):

Persistencia ha sido el tema tratado en el OpenSpace que se ha realizado en las oficinas de tuenti. Hemos podido hablar sobre temas como NoSQL, ActiveRecord, BD basados en grafos, geoespaciales, … entre otros muchos. Ha habido mucho debate, con muchas opiniones, pero sobre todo muy buen ambiente. Muy interesante la charla que ha dado la gente de tuenti sobre como gestionan la persistencia. Es de agradecer la claridad y transparencia con la que han participado.

In the previous post I gave a glimpse of the Javascript Promises Pattern (JPP). Now we are going to take a more in deep look into it and implement our (simplified) version of this pattern. First of all, let’s sow the code I we defined works: we had three operations (to make the example simpler, they all share the same code, but this is not a requisite), each of them expecting a set of arguments which are processed by an asynchronous operation. The result of this asynchronous operation will be feed to the next operation, and so on until we achieve processResults function that will handle the final result. This is a refactored version of the code exposed in the previous post: