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!
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.
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.
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.
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.
I am sure you have heard about the javascript Promises Pattern, but if you haven’t, here is a quick and simple definition: a promise or future is an object that represents a future result, not yet obtained or calculated (here you have a more complete definition). In fact, what is really nice about it is that allows you to define callbacks for async code in and more elegant and readable way.
Coursera Functional Programming has not been my first experience in an online course, but it has been the most satisfying by far. Many people were interested in it, and I think it created a great hype, not only in the course forums but in social networks like twitter. People all around the world were interacting in the same course, creating really interesting conversations and discussions about the subject. Really nice.
Are you already in love with Git? I’m pretty sure of that, that’s the reason why you are reading this, huh?
These are the steps you should follow to migrate an existing SVN repository to a Git one:
1 – Create a file where you will map SVN users to Git users, following this pattern:
svn_user = git_user
This is the one I created to migrate some SVN repositories from Google Code:
In a previous post, we have seen what Git is and its main characteristics. Now, we’ll go more into detail about its functionality and we’ll see what a usual day working with Git looks like.
But before, some initial concepts:
Repository: A working tree of files and directories which can be versioned, keeping track of every single modification made over the working tree, been able to move forward and backward in its history.
