Somos un equipo de desarrollo que estos días tuvo el desafío de aprender bootstrap en 5 días. Qué resultó? Acá va nuestra experiencia:

El primer día

1. Entendimos que nuestro cliente nos pedía que las pantallas web empiecen a ser responsive y hoy no lo son. Así que el desafío fue tomar la maqueta del cliente (maqueta.png) y hacer la pantalla desde cero y responsive!
2. Aprendimos que responsive significa que la página se adapta al ancho del dispositivo (monitor, ipad, iphone, etc).
3. Y que Bootstrap es un framework que con HTML y CSS, facilita la definición de un layout de páginas web, y además, te da la posibilidad de que tus páginas sean responsive.
4. Empezamos a armar la estructura de la página con el concepto que, por defecto, Bootstrap usa 12 columnas imaginarias en un ancho de 940 pixeles.
5. Usamos Collorzilla para obtener los colores de la maqueta y MeasureIt para obtener las medidas.
6. Conseguimos un html con un montón de div porque la maqueta tiene unas cuantas divisiones!

El segundo día

1. La página que tenemos ya es responsive.
2. Discutimos un poco acerca de las nomenclaturas para los nombres de las clases de estilo y acordamos que tengan el prefijo del proyecto cuando son clases propias (p.e. pnt-home).
3. Nos organizamos para trabajar en 2 parejas de trabajo.
4. Una pareja decidió avanzar de a bloques y otra decidió armar primero la página y luego estilarla.
5. Bootstrap no nos ayudó en el diseño y si nos facilitó para que sea responsive.
6. Fundamental que cada bloque que usamos para el layout de la página tiene que tener row y/o span, y los estilos se aplican al contenido, no antes!

El tercer día

1. Bootstrap significa autosuficiente, nada, para saber de dónde el nombre.
2. Empezamos a paralelizar el laburo de diseño.
3. Y a usar componentes propios de Bootstrap como dropdown, tabs, pills.
4. Vemos que Bootstrap va bien para páginas con pocas secciones y con muchas subdivisiones se complican los márgenes predefinidos de la página.

El cuarto día

1. Bootstrap nos ayuda a utilizar los elementos HTML para lo que fueron creados.
2. Se nos complica imitar formatos de la maqueta inicial.

El quinto día

1. Incorporamos Font Awesome para que los íconos y letras sean escalables y de calidad, altamente recomendable!
2. Usamos responsive navbar para que la página convierta una fila de títulos en opciones de menú cuando achicas la pantalla.
3. Terminamos el desafío haciendo una demo de lo logrado.

Una forma simpática de aprender en equipo.

Comprar un VPS, instalar una distribución de linux y configurar Node es bastante sencillo, luego bajar nuestro proyecto y ponerlo en funcionamiento tampoco tiene muchas vueltas, es lo mismo que en local en nuestras maquinas (todo por terminal/ consola). Pero la idea de un VPS es que no vamos a tener un solo proceso node, tenemos un servidor para nosotros, vamos a meter muchos procesos, varias bases de datos, la idea es que vamos más allá de una app en nodejs.

El puerto 80

Nos levantamos un servidor node en el puerto 80, y ahora?, no podemos usar el mismo puerto para otro servidor, pero queremos que la IP de nuestro VPS sirva ambos servidores.
Por ejemplo tener ejemplo.com y ejemplo2.com en el mismo servidor pero en 2 procesos distintos, es decir, cada proceso con un puerto diferente, pero para el usuario es el 80.

Virtual Hosts

Básicamente un virtual host nos va a permitir realizar un reverse proxy, es decir, cada request que nos ingresa al servidor por el puerto 80, manejamos que proceso de node sirve fijándonos el dominio por le que ingresó.

Bueno, hay algunas opciones para hacer esto en forma visual (que dependen de la distribución linux que hayamos elegido).
Para mi caso voy a ir con CentOS 6, para complicarla bien, ni siquiera podemos usar Kloxo (en la ver. 6 de CentOS), también tenemos otras opciones como puede ser WebMin, pero investigando un poco más me encontré con un punto interesante: si tenemos un VPS, donde lo importante (y limitante al bolsillo) es la transferencia mensual (entre otras cosas), no nos conviene utilizar estas herramientas web que simplemente al configurar vamos a estar consumiendo los recursos. No digo que es un limitante, pero es un punto importante aunque también es mas divertido meter mano lo máximo que se pueda. Así que descartemos estas herramientas.

Apache vs NGINX

Los que hayan usado Apache (por ejemplo para PHP) conocerán que es bastante simple configurar Virtual Hosts, pero yo tenia NodeJS, no PHP, y casualmente con Apache no vamos a estar utilizando el potencial de NodeJS así que seguí investigando y me encontré con NGINX, el cual es orientado a eventos, por lo que sería ideal para nuestro caso donde tenemos varios procesos NodeJS.

Instalando NGINX

La instalación va a depender de la Distribución de Linux / el SO que elijamos, para el caso de CentOS va por yum

wget http://nginx.org/packages/centos/6/noarch/RPMS/nginx-release-centos-6-0.el6.ngx.noarch.rpm
rpm -ivh nginx-release-centos-6-0.el6.ngx.noarch.rpm
yum install nginx

Configurando NGINX

Como conté al inicio del post, es la primera vez que me meto en todo esto, así que la configuración que les voy a mostrar es lo básico para poner en funcionamiento nuestros servidores NodeJS, no mas que eso.

nginx (se pronuncia enyinex, como Engine X en inglés ), a diferencia de Apache, actual como un ReverseProxy antes que un HTTP Server. Y su configuración es parecida a un JSON con una suerte de herencia jerárquica, es decir, las configuraciones de abajo reemplazan a las de arriba (dependiendo el caso)

Sin meterme mucho en la configuración, ya que desconozco ampliamente (pueden ver mas acá), tenemos 3 componentes importantes:

http > server > location : donde server serían el equivalente al VirtualHost en Apache y location las rutas a los recursos (URIs).

Entonces, para nuestro caso particular donde queremos 2 procesos nodejs utilizando dominios distintos y que ambos sean accesibles desde la misma IP (de nuestro VPS) bajo el puerto 80, deberíamos crear un http, con 2 server y sus respectivas location (URI raíz) apuntando a nuestros procesos.

Así que primero, configuramos nuestros procesos de Node para que corran, por ejemplo, uno en el puerto 3000 y el otro en el 3050 y después armemos el config:

Abrimos el archivo de configuración para Linux:

vim /etc/nginx/nginx.conf

# acá otras configuraciones
http {
  server {
    listen   80;
    server_name ejemplo1.com www.ejemplo1.com *.ejemplo1.com;

    location / {
         proxy_set_header X-Real-IP $remote_addr;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header Host $http_host;
         proxy_set_header X-NginX-Proxy true;
         proxy_pass http://127.0.0.1:3000/;
         proxy_redirect off;
    }
  }

  server {
    listen   80;
    server_name ejemplo2.com www.ejemplo2.com *.ejemplo2.com;

    location / {
         proxy_set_header X-Real-IP $remote_addr;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header Host $http_host;
         proxy_set_header X-NginX-Proxy true;
         proxy_pass http://127.0.0.1:3050/;
         proxy_redirect off;
    }
  }
}

Guardamos el config y arrancamos nginx

sudo service nginx start

Pueden ver un ejemplo de una configuración acá

Y listo!, ahora entramos a http://ejemplo1.com y nos levanta el servidor que tenemos en el puerto 3000 y si entramos a http://ejemplo2.com el del puerto 3050.

Mas info.

NGINX (Inglés)

• Wiki
• Intro
• Entendiendo el Modelo de Herencia
• Diferencias con Apache
• Por qué deberías usarlo?

Se acuerdan cuando hablaba de organizar el código de JS, que ya no es scripting y creación de funciones colgadas por todos lados, que a medida que la web crece y hacemos aplicaciones, en vez de una paginita web con botones ya creamos aplicaciones web. Un inicio por el camino correcto al orden es desacoplar creando módulos y hablaba de como hacerlo en el post Patrones: Module y Namespace.

Bueno, avanzando sobre ese tema, existen definiciones y estandares para crear y utilizar módulos, de eso se trata este post. Vamos a ver de que se trata cada uno de estos enfoques para solucionar el problema.

AMD: Asynchronous Module Definition

La Definición Asíncrona de Módulos fue creada para definir módulos donde este mismo y sus dependencias puedan ser cargadas asincrónicamente. Un ejemplo de esto es el conocido RequireJS (en este post muestro una intro: RequireJS: Módulos y Dependencias).
Se puede decir que fue pensado especialmente para el Navegador donde es importante tener este tipo de asincronismo. También existen herramientas de optimización para el navegador donde es importante cargar lo necesario e indispensable mejorando la experiencia con nuestro sitio.

Demasiado texto, tiremos un poco de código para no dormirnos.

// define( [nombre] , [dependencias] , [definición]);

define('miModulo', ['otroModulo'], function(otroModulo){
  // listo, acá defino el módulo "miModulo", 
  // porque la dependencia a otroModulo ya fue cargada y la tengo disponible.

  return {
    acceso: function(){ }
  };
});

De esta manera puedo definir cada módulo de mi aplicación con sus dependencias a otros módulos y me aseguro que todo existe antes de utilizarlos.

CJS: Common JS

Ahora cambia un poco la idea, en CJS no tenemos “definición de módulos”, es decir, no escribimos un “define”, sino que se asume que sus dependencias ya están cargadas al momento de requerirlas.
Para este caso podemos decir que fue pensado para el Server (por ej. NodeJS), donde realizamos un require([módulo]) y lo tenemos, sin asincronismo:

//no hay ningún define()

var otroModulo = require('./otroModulo');

// acá va el código de nuestro módulo

module.exports.acceso = function() {};

Si bien, estamos de alguna manera definiendo sus dependencias con require(), la diferencia principal es que no lo hacemos antes de ejecutarse, es decir, podemos tener funciones y realizar esos require() desde cualquier parte del módulo, pero eso si, siempre se asume que ya está cargado.

AMD + CJS

Pero que pasa si intentamos utilizar el ejemplo anterior de CommonJS en el navegador?, definitivamente no va a funcionar.
Así como tampoco utilzar un define en NodeJS.
Entonces cual es mejor?, cuando?, donde?. Bueno, a mi parecer no hay uno mejor que el otro, ya explique para que fueron creados, ambos tienen sus pros y contras.

Mi problema, personal, es que me gusta AMD por su asincronismo, pero también me gusta CJS por el hecho de no definir dependencias y de poder utilizar mis módulos en NodeJS también (mientras no utilice DOM jeje), así que opté por utilizar ambos para el navegador.
Como?, bueno ahí esta lo divertido, simplemente envolviendo cada módulo CJS en uno de AMD, pero en tiempo de “compilación” (*) (sino sería medio extraño), es decir, usando GruntJS con la ayuda de WebMake.

(*) con “compilación” me refiero a la tarea en GruntJS, realmente no se esta “compilando” el javascript jaja.

En un futuro post voy a mostrar un poco mas de GruntJS, pero por el momento les dejo un proyecto base en Github sobre esto de AMD + CJS + GruntJS + WebMake (también tiene un poco de Backbone y Backbone Marionette )

https://github.com/pjnovas/base-client-project (les debo el Readme en Español)

Cuál te gustas más? AMD o CJS?

Cuando leí este artículo que habla sobre la performance en objectos String, aparte de pensar “que bueno debe ser tener tiempo para hacer experimentos como esos”, me topé con la teoría detrás de los ‘wrapper objects’. De ahí, llegué a este link que me parece absolutamente recomendable (al igual que el resto del blog). Casi todo lo que escriba de acá en adelante, tal vez sea parafrasear o hablar un poco más de lo mismo que en esos enlaces.

En JavaScript, los strings, los numeros, los booleanos, no son objetos; son tipos primitivos. Por consiguiente, no tienen propiedades. Es decir, ‘un string’ no tiene ni indexOf, toUpperCase, ni length… Nada.

¿Entonces?

Después de leer eso, vale la pena abrir la consola de javascript, ¿ Por qué puedo hacer 'fernet'.concat('js') ???

La respuesta es sencilla: por detrás, lo que ocurre es que el string ‘fernet’ es automáticamente convertido a un objeto String, es decir a new String('fernet'), y ese objeto es el que tiene todas las propiedades y métodos que conocemos; por eso es posible aplicarle el concat.
El método concat devuelve un string primitivo, aunque la misma conversión automática ocurriría si quisieramos utilizar alguna de sus propiedades.

typeof 'fernet' // "string"
typeof 'fernet'.concat('js') // "string"
'fernet'.concat('js').toUpperCase() // "FERNETJS"

Vuelvo a insistir con lo mismo para aquellos que no acostumbren a hacerlo: experimentar con la consola js de las herramientas de desarrollo de su navegador favorito es una de las mejores maneras de aprender, descubrir nuevos conceptos, y reconfirmar las cosas que ya sabemos.

var a = 'ejemplo',
    b = new String('ejemplo');

typeof a //"string"
typeof b //"object"
a == b //true
a === b //false
a + b //"ejemploejemplo"

// puedo consultar propiedades para ambos
a.length //7 (gracias a la conversión implícita a su wrapper obj) 
b.length //7

Por si sigue sonando extraño, esto sería lo que hace el intérprete de javascript “detrás de escena” cuando hacemos ‘FERNETJS’.toLowerCase():

var stringOriginal = 'FERNETJS';
var str = new String(stringOriginal); //str sería el wrapper object 
str.toLowerCase(); // 'fernetjs'

El intérprete no sólo usa este “wrapper object” detrás de escena cuando queremos obtener una propiedad, sino que también cuando la queremos setear; pero esto puede ser contraproducente:

var str = 'mmm';
str.unaPropiedadInventada = 100;
str.unaPropiedadInventada // undefined
var str2 = new String('jeje');
str2.unaPropiedadInventada = 100;
str2.unaPropiedadInventada //100

Sobre la conversión [tipos primitivos]<->[wrappers]

Nosotros podemos trabajar con tipos primitivos o con objetos, y podemos explícitamente hacer conversiones en ambas direcciones.

// con new Number envolvemos al primitivo 1 en un objeto number
var n = new Number(1);
typeof n //"object"
// llamando a Number (sin new) convierte el obj a su primitivo
typeof Number(n) //"number"

De todas maneras, no es recomendable y rara vez o nunca, vamos a escribir en nuestro código var x = new Number(17). La principal razón, es que no nos va a ser de gran utilidad, ya que sea cual sea el valor del objeto, siempre va a ser "verdadero" en el resultado de una evaluación:

var tengoPlata = new Boolean(false);
if (tengoPlata)
    console.log('comprar unos fernecitos');
else 
    console.log('esperar');

En el caso anterior, por ejemplo, quería decir que no tenía plata. De todas maneras, se ejecuta "comprar unos fernecitos", dejándome en bancarrota. Esto ocurre porque tengoPlata es un objeto, en contraste con el false que hubiera sido más natural usar.

Por otra parte, desde objeto hacia tipo primitivo muchas veces se hacen conversiones automáticas, (del mismo modo que 1 podría ser convertido a '1'), más que nada a la hora de operar.
Por ejemplo:

var x = new Number(199),
    y = 1;
x + y // 200

Estas conversiones se basan en lo que devuelve el valueOf() del objeto. Es decir, siempre que se trate de convertir un objeto a un primitivo, el resultado de la conversión va a ser lo que devuelve el valueOf. Este método está en todos los objetos, y si no es sobreescrito, va a devolver el mismo objeto (docs de valueOf).
Lo más loco de este artículo es lo que sigue. Sabiendo esto, uno podría emular un objeto, que al momento de operar sería convertido a su correspondiente valor primitivo.

var a = {
  valueOf: function(){ return 199; }
};
console.log(a + 1); //200

var b = { 
    valueOf: function(){ return navigator.plugins.length; } 
};
console.log(b - 1); //???? jeje

¿De qué me sirve saber esto?¿Ya puedo hacer juegos multiplayer en 4-D con js?

La verdad que al fin y al cabo todo esto no tiene mucho sentido práctico, uno podría vivir sin saberlo, pero ayuda a conocer un poco más el lenguaje y entender por qué las cosas funcionan de la manera que lo hacen.
Sí es importante tener presente los problemas que puede traer manualmente instanciar estos objetos String, Number, etc..

NOTAS: * A lo largo de todo el artículo se utilizó el termino 'wrapper object'. Esto se debe a que no encontré una traducción acorde, 'objeto envolvedor', 'objeto envoltorio' simplemente no sonaban correctos. Sugerencias?
* Cuando se habla de String, Number, Boolean en los ejemplos, la mayoría de las veces se podrían haber aplicado indistintamente.

Para contarles que es Curry me voy a basar en el libro   “JavaScript Patterns – Stoyan Stefanov“. ( Lo pueden comprar en su librería de confianza )

En este link tienen una def un poco más genérica, desatada del mundo JS.

“Curry es una técnica de transformación de funciones que permite obtener a partir de una función A otra B que es la versión parcialmente aplicada de A.” Después de la teoría vienen un par de formas de hacerlo con JavaScript.

Que es una aplicación y una aplicación parcial?

Podemos tomar con fines prácticos hablando en un contexto menos matemático y mas JS que una aplicación es como una llamada a función y que aplicar parcialmente una función es llamarla con no todos los argumentos esperados sino con algunos de los primeros. Como de esta forma no podemos obtener el resultado final que obtendríamos de pasarle todos los parámetros, lo que se obtiene es una función que se puede llamar con los parámetros restantes y devolver el resultado como si hubiese sido llamada con todos los parámetros.

Implementaciones

Curry manual:

function sumar( x, y ) {
    if ( typeof y === 'undefined' ) { //detección de aplicación parcial
        return function ( y ) { //la transformación ( curring )
            return x + y;
        };
    } else {
        return x + y;//aplicación completa
    }
}

var sumaParcial = sumar( 4 );// Obtener suma parcialmente aplicada, memoriza x

var result = sumaParcial( 5 ); // uso de la versión parcialmente aplicada, el 5 se usa para y que al sumarle la x memorizada ( 4 ) dará como resultado 9. 

//También lo podemos usar así:
var result2 = sumar( 4 ) ( 5 );

En esta implementación del curry, la aplicación parcial está en la misma función sumar, si vamos a usar mucho esta técnica, se puede hacer una forma más versátil que pueda aplicar curry a cualquier función que querramos en el libro aparece el ejemplo, la función schonfinkelize de 7 lineas que le pone curry a lo que se le cruce:

Curry pro

function schonfinkelize(fn) {
   var slice = Array.prototype.slice,
     stored_args = slice.call(arguments, 1);
   return function () {
      var new_args = slice.call(arguments),
         args = stored_args.concat(new_args);
      return fn.apply(null, args);
   };
}

//Ejemplo de uso:
// Función a modificar:
function echo( x ) {
  return x;
}

// Función modificada
var elephantFunction = schonfinkelize( echo, 'algo para recordar' );//La Transformación ( curring )

// Aplicación, en un objeto mock, o un objeto que necesita tener un método que devuelva siempre el mismo valor con fines de polimorfimo
var mock = {
   getMessage: elephantFunction
}

Mas info sobre apply en Patrones de Invocación de Funciones: this y en Modificando el contexto: call, apply y bind

Implementación de Underscore.js

Underscore viene con la función partial que permite hacer las partial applications, el ejemplo anterior, hecho con esta funcionalidad de underscore sería :

var mock = {
   getMessage: _.partial( echo, 'algo para recordar' ) //La transformación ( curring )
}

Ejemplos de Uso:

Imagínense que tenemos una función densidad de tres variables de entrada ( x, y , z ) que nos devuelve la concentración de algo ( un compuesto por ejemplo ) en un cuerpo dado. Densidad podría tener información de una tomografía computada o de un examen de resonancia magnética nuclear, x podría representar la dimensión longitudinal de pies a cabeza, y con _.partial( densidad, 3 ), podríamos obtener un corte ( una imagen ) de esa información a 3 centímetros de la planta de los pies.

Ok, que pasa si se nos fué la mano con el fernet y queremos cortes que no sean perpendiculares a ninguno de los ejes xyz? Rta, tendríamos que aplicar un poco (bastante) de matemática, como para obtener una función similar partial, pero que se llame por ejemplo slice que reciba como entrada un vector con un punto por donde debe pasar el corte y otro perpendicular al plano de corte, ejemplo:  corte = _.slice( [3, 0, 0], [0, 0, 1], densidad ) // el corte pasa por x = 3 y el vector normal es el que tiene solo componente z.   La función devuelta tendría dos variables de entrada, que serían coordenadas x y y en el plano de corte ( que no necesariamente son las mismas que las originales).

Bueno, espero que les haya gustado.

Todo comenzó con los callbacks, en el mongodb-native de NodeJS. La verdad es bastante estresante generar muchísimos callbacks, y no se pueden generar relaciones entre una y otra colección. Ese realmente fue el problema que me enfrente. Y buscando encontré MongooseJs, que construye modelos de información, para que todo sea mas asequible, y mas fácil de encontrar. Vamos a echarle un vistazo!

var mongoose = require('mongoose');
var db = mongoose.createConnection( 'mongodb://localhost:27017/prueba' );

Hasta hora no es nada raro! Solo llamamos el modulo y le construimos una conexión a la base de datos. Ahora bien lo interesante! La construcción de la base de datos

var postSchema = mongoose.Schema({
    titulo: { type : String, trim : true, index : true },
    post : string,
    slug : string,
    autor : { type : Schema.Types.ObjectId, ref : 'autores' }  });
var userSchema = mongoose.Schema({
    name : { type : String, trim : true },
    nick : { type : String, trim : true, index : true },
    email: { type : String, trim : true },
});

Listo! voy a dar un ejemplo de blog! Como vemos, construimos Schema (Esquemas). Estos esquemas, es tan dados en Json (Bastante cercano a MongoDB por que utilizan BSON que es el mismo JSON pero en Binario ). Cada propiedad debe tener una definición, al igual se pueden colocar múltiples validaciones de esa propiedad. Y todas los valores van a ser validados, si existe algún error nos mostrara. Es decir a los titulo no le puedo poner un false, únicamente un String.

var Post = db.model('posts', postSchema);
var User = db.model('users', userSchema);

Y en lazaremos con la base de datos. El primer parámetro es el nombre de la Colección, y el segundo parámetro es el esquema. Ya con esto podemos subir información a la base de datos. Claro en el momento de subida va hacer validada.

var PrimerUsuario =  new User({
    name : 'Pepito Perez',
    nick : 'pepito',
    email: 'pepito@pepito.com'
});
PrimerUsuario.save(function(err, doc){
   if(err)
      console.log(err);
   var PrimerPost = new Post({
       titulo: 'Este es mi primer Post!',
       post  : 'Publicando mi primer post!! que felicidad!!',
       autor : doc._id,
   });
   PrimerPost.slug = slug( PrimerPost.titulo );
   PrimerPost.save( function(err, doc){
     console.log(err);
     console.log(doc);
   })
});

Como podemos ver, lo primero que llamamos es a la creación de un nuevo usuario, le montamos en las propiedades que queremos, al igual que un prototype. Y claro esta la función llamada save, que nos va a retornar el Error y el Documento. Generando un nuevo post, hacemos lo mismo es decir le pasamos los parámetros que queremos. Yo utilizo Slug para tener urls familiares, al igual es un Object. Y guardamos! Y veremos algo así en consola.

{
    _id : 50903550a04313310c000001,
    titulo : 'Este es mi primer Post!',
    post : 'Publicando mi primer post!! que felicidad!!',
    slug : 'este-es-mi-primer-post',
    autor : 2d2ac97cf59cee65f7a38e596c,
}

Claro yo se que los id no son los mismos, que salen en tu consola. Pero seamos un poco desconfiados, vamos a revisar la base de datos!

$ mongo
mongo> show dbs
prueba 0.203125GB
test 0.203125GB
mongo> use prueba
mongo> show collections
posts
users
mongo> db.users.find()
{ "_id" : ObjectId("2d2ac97cf59cee65f7a38e596c"), "name" : "Pepito Perez", "nick" : "pepito", "email" : "pepito@pepito.com" }
mongo> db.posts.find()
{ _id : ObjectId("50903550a04313310c000001"), "titulo" : "Este es mi primer Post!", "post" : "Publicando mi primer post!! que felicidad!!", "slug" : "este-es-mi-primer-post", "autor" : ObjectId("2d2ac97cf59cee65f7a38e596c" }

Genial!! Esta toda la información que subimos a la base de datos. Vamos a buscar a nuestro usuario!

User.findOne().where('nick', 'pepito').exec(function(err, doc){
   console.log(err);
   console.log(doc);
});

null
{
    _id : 2d2ac97cf59cee65f7a38e596c,
    name : "Pepito Perez",
    nick : "pepito",
    email : "pepito@pepito.com",
}

Tomamos el modelo, y le mandamos un findOne, find o findById, le podremos pasar querys de Mongodb. Pero todos estos parámetros en una función como aquí, y nos facilitan el trabajo. Nunca olvidemos hacerle exec. Si al igual podemos buscar los Post, pero también podemos saber de que usuario es! Miremos como se hace

Post.find().populate('autor').exec(function(err, doc){
   console.log(err);
   console.log(doc);
});

Bueno en este caso, buscamos todos los Post. Le montamos la función populate, lo que hace, es buscar según el id, en otra colección y lo anida en la propiedad autor. Miremos que nos muestra la consola!

null
[ {
    _id : 50903550a04313310c000001,
    titulo : 'Este es mi primer Post!',
    post : 'Publicando mi primer post!! que felicidad!!',
    slug : 'este-es-mi-primer-post',
    autor : {
        _id : 2d2ac97cf59cee65f7a38e596c,
        name : "Pepito Perez",
        nick : "pepito",
        email : "pepito@pepito.com",
    }
} ]

Como nos damos cuenta, es un Array o mejor una lista de Object, y dentro de cada Object existe el Object Usuario. Así se vuelve mucho mas fácil tanto la búsqueda como la subida de información. Claro teniendo esto podemos modificar el nick de nuestro usuario y con un .save, se sube a la base de datos.

Bueno esta es la primera parte de esta serie de posts. En el próximo les mostrare como guardar elementos anidados, hacer querys avanzados y validaciones.

Antes de arrancar, te recomiendo que leas el post Patrones de Invocación de Funciones que habla sobre el bindeo del contexto en el famoso this, así puedo concentrarme en mostrarte la diferencia entre estos métodos.

Bueno, ahora que sabes esto del this y como se bindea su contexto, algo que es extremadamente útil a la hora de tener el control sobre las funciones o métodos que hacemos y utilizamos.

Como viste en el post mas arriba en el caso del apply lo que estamos haciendo es meterle un nuevo contexto a una función, por ejemplo:

var obj = {
  delta: 2,
  test: function(num1, num2){
     return (num1 + num2) * this.delta;
  }
};

var resultado = obj.test(2,2);
console.log(resultado); // (2 + 2) * 2 = 8

En este caso, simplemente tenemos un objeto con una propiedad y una función, al llamarla con 2 números, los sumamos y le aplicamos el delta de su contexto (en el cual está corriendo la función), que para este caso es el objeto en si mismo.

Pero que pasa si ahora queremos cambiarle ese contexto, un nuevo delta, definido por nosotros pero sin modificar el objeto…

apply()

var cambio = {
  delta: 5
};

var resultado = obj.test.apply(cambio, [2,2]);
console.log(resultado); // (2 + 2) * 5 = 20

Le aplicamos un nuevo contexto en el cual corre la función, por lo que ahora el this de obj va a contenter nuestro objeto cambio, por ende, el delta valdrá 5 al ejecutarse.
Y que es el array que sigue a la llamada?, esos son los argumentos que recibe la función:

  [funcion].apply([contexto], [parámetros como array]);

call()

Otra forma de llamar a una función aplicandole un contexto es con call, siguiendo con el ejemplo del apply:

var cambio = {
  delta: 5
};

var resultado = obj.test.call(cambio, 2, 2);
console.log(resultado); // (2 + 2) * 5 = 20

La única diferencia es la forma de pasar los argumentos, ya que en vez de que sea un array, simplemente toma el primero como el contexto y los siguientes son los argumentos en el orden que los esperamos.

  [funcion].call([contexto], [param1], [param2], [paramN]);

bind()

En este caso hay una vuelta de tuerca mas, que nos puede ser bastante útil.
El bind() no llama a la función con un nuevo contexto, sino que nos devuelve una referencia a la función con ese nuevo contexto:

var cambio = {
  delta: 5
};

var funcionConCambio = obj.test.bind(cambio);
var resultado = functionConCambio(2, 2);
console.log(resultado); // (2 + 2) * 5 = 20

Muy loco!, esto aplicado a callbacks puede ser muy interesante.
Usas el self, me o that?

Supongamos tenemos una llamada ajax y definimos un callback para cuando termina, un ejemplo común sería:

// más código donde utilizamos el this
var that = this;
function callback(datos){
  that.magia(datos);
}

ajax(callback);

Ahora con bind nos quedaría asi:

function callback(datos){
  this.magia(datos);
}

ajax(callback.bind(this));

Mucho más limpio!

Algo a tener en cuenta es que el metodo bind() aparece en el ECMAScript 5ta Edición, por lo que puede que los navegadores ancianitos no lo soporten.

Primero tenemos que tener en cuenta que LocalStorage es el almacenamiento que no expira, y SessionStorage es el que vive sólo en una sesión.
Ambos tienen los mismos métodos:

• getItem ( key )
• setItem ( key , value )
• removeItem ( key )

Van a ver por ahí un globalStorage: es una implementación de Mozilla previa a HTML5, pero desde la versión de Firefox 13 dejó de soportarse, por lo que olvidate de que existe

No hay mucho para explicar sobre los métodos ya que hablan por si solos, veamos un ejemplo:

if (window.localStorage) {

  localStorage.setItem("nombre", "pepe");

  var nombre = localStorage.getItem("nombre");
  
  localStorage.removeItem("nombre");
}
else {
  throw new Error('Tu Browser no soporta LocalStorage!');
}

También se puede utilizar los Items como propiedades del objeto localStorage ó sessionStorage (pero no está recomendado, así que tomalo como título informativo):

localStorage["nombre"] = "pepe";
var nombre = localStorage.nombre;
delete localStorage["nombre"];

El soporte de navegadores es muy amplio:

+----------------+--------+-----------------+----+-------+-----------------+
|    Feature     | Chrome | Firefox (Gecko) | IE | Opera | Safari (WebKit) |
+----------------+--------+-----------------+----+-------+-----------------+
| localStorage   |      4 | 3.5             |  8 | 10.50 |               4 |
| sessionStorage |      5 | 2               |  8 | 10.50 |               4 |
+----------------+--------+-----------------+----+-------+-----------------+

Pueden ver mas info acá

Y cuánto podemos almacenar?: depende mucho del navegador, pero la cantidad oscila entre 2.5 y 5 Mb (2.5 Mb en la mayoría de los navegadores, lo cual es bastante )
Pueden ver la tabla completa y probar cuanto se banca el navegador en el que están en Web Storage Test

Podemos guardar JSON?, Si, pero yo te recomendaria que sea serializado, (en String) y lo que hagas antes de enviarlo.
Por que esto?

1. Por los “fallbacks/ polyfills”, si queremos agregarle un soporte a cookies por si no tiene disponible el web storage, puede que tengamos problemas si no estamos manejando strings.
2. Lo serializa de todas formas, pero la diferencia es que no es automático, por lo que podemos tener comportamientos extraños:

  localStorage.setItem("locura", true);
  var locura = localStorage.getItem("locura");
  console.log(locura); // true
  console.log(typeof locura); // 'string'

Ahora, con JSON?, supongamos que tenemos:

var persona = {
    nombre: "pepe",
    edad: 20,
    locura: true
};

Guardamos directo el JSON al localStorage:

localStorage.setItem("persona", persona);
var personaGuardada = localStorage.getItem("persona");

console.log(typeof persona); //object
console.log(typeof personaGuardada); //string

console.log(personaGuardada.locura); //undefined!
var personaGuardada = JSON.parse(personaGuardada); //Uncaught SyntaxError

Como habría que hacerlo:

var personaAGuardar = JSON.stringify(persona);

localStorage.setItem("persona", personaAGuardar);
var personaGuardada = localStorage.getItem("persona");

console.log(typeof persona); //object
console.log(typeof personaGuardada); //string

var personaGuardada = JSON.parse(personaGuardada); 
console.log(personaGuardada.locura); //true

Por último te dejo un fallback a Cookies, ya que no siempre tenemos soporte para usarlo, está es una implementacion de Mozilla bastante coqueta (no se si funciona en IE 7, por ejemplo), la idea es que en nuestra aplicación usamos directamente window.localStorage y siempre va a existir, si el browser no lo soporta va a ir a cookies automáticamente.
Fuente: MDN – DOM Storage

if (!window.localStorage) {
  Object.defineProperty(window, "localStorage", new (function () {
    var aKeys = [], oStorage = {};
    Object.defineProperty(oStorage, "getItem", {
      value: function (sKey) { return sKey ? this[sKey] : null; },
      writable: false,
      configurable: false,
      enumerable: false
    });
    Object.defineProperty(oStorage, "key", {
      value: function (nKeyId) { return aKeys[nKeyId]; },
      writable: false,
      configurable: false,
      enumerable: false
    });
    Object.defineProperty(oStorage, "setItem", {
      value: function (sKey, sValue) {
        if(!sKey) { return; }
        document.cookie = escape(sKey) + "=" + escape(sValue) + "; expires=Tue, 19 Jan 2038 03:14:07 GMT; path=/";
      },
      writable: false,
      configurable: false,
      enumerable: false
    });
    Object.defineProperty(oStorage, "length", {
      get: function () { return aKeys.length; },
      configurable: false,
      enumerable: false
    });
    Object.defineProperty(oStorage, "removeItem", {
      value: function (sKey) {
        if(!sKey) { return; }
        document.cookie = escape(sKey) + "=; expires=Thu, 01 Jan 1970 00:00:00 GMT; path=/";
      },
      writable: false,
      configurable: false,
      enumerable: false
    });
    this.get = function () {
      var iThisIndx;
      for (var sKey in oStorage) {
        iThisIndx = aKeys.indexOf(sKey);
        if (iThisIndx === -1) { oStorage.setItem(sKey, oStorage[sKey]); }
        else { aKeys.splice(iThisIndx, 1); }
        delete oStorage[sKey];
      }
      for (aKeys; aKeys.length > 0; aKeys.splice(0, 1)) { oStorage.removeItem(aKeys[0]); }
      for (var aCouple, iKey, nIdx = 0, aCouples = document.cookie.split(/\s*;\s*/); nIdx < aCouples.length; nIdx++) {
        aCouple = aCouples[nIdx].split(/\s*=\s*/);
        if (aCouple.length > 1) {
          oStorage[iKey = unescape(aCouple[0])] = unescape(aCouple[1]);
          aKeys.push(iKey);
        }
      }
      return oStorage;
    };
    this.configurable = false;
    this.enumerable = true;
  })());
}

Arrancamos con un ejemplo común:

try {
  //.. venimos haciendo cosas 
  throw "disparo un error!";
}
catch(e){
  console.log(e); // "disparo un error!"
}

Bueno, tiramos un error que es un string, pero podemos hacerlo mejor:

try {
  //.. venimos haciendo cosas 
  throw new Error("disparo un error!");
}
catch(e){
  console.log(e.message); //"disparo un error!"
  console.log(e.stack); //Error: disparo un error! at http://localhost/:3:2 at condition .... 
}

Ahh, ahora se vé mucho mejor, tenemos el stack y el mensaje por separado y si hacemos un throw e; vamos a ver el error completito en la consola (o en el terminal en el caso de NodeJS). O sea, que ahora es un objeto, no mas cadenas voladas en el eter.

Cómo vimos en otro post, el alcance de las variables es a nivel de función, pero para el catch, nuestra variable e tiene alcance SOLO dentro del catch:

console.dir(e); //error: e no está declarada
catch(e){
  console.dir(e); //jeje   
}
console.dir(e); //error: e no está declarada

Manejar errores de esta manera nos trae muchas facilidades, aparte de tener el Stack y de tener realmente una Excepcion y no un string, nos abre las puertas para empezar a manejar errores enserio, ahora podemos:

Crear nuestros Tipos de Errores:

function MiError(mensaje) {
  this.name = "MiError";
  this.message = mensaje || "No Especificado";
}
MiError.prototype = new Error();
MiError.prototype.constructor = MiError;
 
try {
  throw new MiError("explotó!");
} catch (e) {
  console.log(e.name);     // "MiError"
  console.log(e.message);  // "explotó"
  console.log(e.stack);  // Error: explotó! at http://localhost/:9:2 at condition .... 
  console.log(e instanceof MiError); //true
}

Simplemente extendemos la clase Error con nuestro nuevo tipo de error

Al tener tipos propios de errores, es seguro que vamos a necesitar catchear cada tipo, porque para eso los creamos, ya que esto no es un feo string y ahora es una clase, podemos comprobar por instancia para que quede prolijo:

try {
  throw new MiError("explotó!");
} catch (e) {
  if (e instanceof MiError){
    console.log('fue MiError');
  }
  else {
    console.log('fue otra cosa así que disparo un error no manejado');
    throw e;
  }
}

Van a ver por ahí casos donde se utiliza:

catch(e if e instanceof MiError)

Cuidado con eso porque solo lo soporta Mozilla y no es parte del Standard ECMAScript.

Aparte del coqueto Error (piénsenlo como la clase Exception de C# o Java, sería el error más genérico), también tenemos otras Excepciones ya definidas que heredan de Error:

• EvalError
• RangeError
• ReferenceError
• SyntaxError
• TypeError
• URIError

Todo este manejo de errores funciona tanto en el cliente, como en el servidor con NodeJS. Lo que hay que tener en cuenta es que algunos navegadores ancianos no soportan la clase Error, pero hablamos de navegadores muy ancianos.

Para el cliente también hay otros tipos de excepciones ya definidas por ejemplo DOMExceptions (este va a depender de los niveles de DOM y del navegador, pero va para otro post )

Manejando errores en Callbacks

Ahora bien, tenemos otro caso de manejo de errores, los famosos y amados callbacks, como manejaríamos los errores?, tenemos un tema, no deberíamos hacer un throw ya que un callback puede ejecutarse en otro momento (asíncrono) y disparar una excepción dentro de un callback en otro tiempo puede traer graves problemas.

Lo que se utiliza, y no se bien si realmente es un standard (en NodeJS), es tener un argumento más (el primero) en cada callback, el cual va a ser el error:

dao.leerDatos(function(error, datos){
   // en error tengo la excepcion (pero no hay try/ catch)
});

Porque el argumento error en el primer lugar?, yo creo que viene por el lado del opcional, en JavaScript ningún argumento es obligatorio, podemos definirlos o no, y usarlos o no, no estamos obligados a seguir una firma de métodos/ funciones como en otros lenguajes. Entonces de esta manera si queremos agarrar el argumento datos estamos obligados a agregar el argumento error, por su orden

Es por eso que en el caso de un callback que no devuelve nada, simplemente se dispara cuando algo termina, lo ideal sería que igualmente tenga un argumento error:

dao.guardar(entidad, function(error){
  // etc ..
});

Bueno, y como manejo si hubo error o no?, ya que no hay try/ catch?

dao.leerDatos(function(error, datos){
  if (error) {
    // manejo el error.
    return;
  }
  
  console.dir(datos);
});

Simple!, compruebo si error es un valor verdadero y recuerden hacer un return, o salir de ese callback de alguna otra forma, ya que sino la función continuará su ejecución, y no me suena a que queremos que suceda.

Mirando esto mismo de quien llama a ese manejo podemos ver como funciona:

function hacerLlamada(termino) {
  
  dao.leerDatos(function(error, datos){
    if (error) {
      termino(error);
      return;
    }
    
    // algún calculo mágico
    termino(null, datos);
  });
}

hacerLlamada(function(err, datos){
  if (err) throw err;
  else console.dir(datos);
});

El ejemplo no es lo más feliz, pero lo que te quiero mostrar es como sería el que llama a esa función con otro callback. De está manera nos queda el código mucho mas ordenado y con los errores bien manejados, como si hubiera un try y catch (que va subiendo en su ejecución a medida que es disparado y atrapado por el que lo llamó), hacemos lo mismo con callbacks y somos todos felices .

Links útiles y fuentes de info

• String is not an Error por Guille Rauch
• JavaScript Errors – Throw and Try to Catch W3School
• Error en MDN (MOZILLA DEVELOPER NETWORK)

Estos ejemplos que muestro a continuación (solo simplificados para que no sea tan tedioso explicarlos y entenderlos) son piezas de código genuinas que sirven para comprender la utilización de los métodos mencionados en un contexto real.

Se define la clase Usuario que posee la complejidad mínima y necesaria para exhibir los ejemplos.

Usuario es una clase trivial con 3 propiedades: id, nombre y esAdmin y el método validar que devuelve 2 errores.
Se construye el arreglo usuarios con 3 objetos de esa clase.

function Usuario(nombre, esAdmin, id){	
	this.nombre = nombre;
	this.esAdmin = esAdmin;
	this.id = id;
		
	this.validar = function (){
		return ["error1 " + nombre, "error2 " + nombre];
	};
};

var usu1 = new Usuario('Juana', false);
var usu2 = new Usuario('Pedro', false);
var usu3 = new Usuario('Alberta', true);

var usuarios = [usu1, usu2, usu3];

some

Dada una función, some devuelve verdadero si algún elemento del arreglo cumple con la misma.
El objetivo de este ejemplo es escribir el código necesario para saber si alguno de los usuarios es administrador.

Usando for:

var hayAlMenosUnAdministrador = false;
for (var i; i < usuarios.length; i++) {
	var usuario = usuarios[i];
	if (usuario.esAdmin) 
		hayAlMenosUnAdministrador = true;        
}

Usando some:

var hayAlMenosUnAdministrador = usuarios.some(function(usuario){
	return usuario.esAdmin;
})

Usando some pero más prolijo:

var esAdmin = function(usuario){
	return usuario.esAdmin;
};

var hayAlMenosUnAdministrador = usuarios.some(esAdmin);

every

Dada una función, every devuelve verdadero si todos los elementos del arreglo cumplen con la misma.
El objetivo de este ejemplo es practicamente la misma idea anterior, solo que en este caso el objetivo es saber si todos los usuarios son administradores.

var sonTodosAdmin = usuarios.every(esAdmin);

reduce

reduce aplica una función que toma como parámetros el valor acumulado y el elemento actual del arreglo. Esa función devuelve el nuevo valor acumulado. El segundo parámetro de reduce recibe el valor inicial acumulado.
El objetivo de este ejemplo es escribir el código necesario para construir un arreglo con todos los errores de validación de todos los usuarios. Recordemos que cada objeto usuario posee el método validar que devuelve los errores de validación del mismo.

Usando for:

var todosLosErrores = [];
for (var i = 0; i < usuarios.length; i++){
	var usuario = usuarios[i];
	var errores = usuario.validar();
	
	for (var e = 0; e &lt; errores.length; i++)
		todosLosErrores.push(e);
}

Mejorado:

var todosLosErrores = [];
for (var i = 0; i < usuarios.length; i++){
	var usuario = usuarios[i];
	var errores = usuario.validar();	
	todosLosErrores = todosLosErrores.concat(errores);
}

Usando reduce:

var todosLosErrores = usuarios.reduce( function(errores, usuario){
	return errores.concat(usuario.validar());
},[]);

Usando reduce pero más prolijo:

var agregarErrores = function(errores, usuario){
	return errores.concat(usuario.validar());
}
var todosLosErrores = usuarios.reduce(agregarErrores,[]);

En la tercera parte de este artículo se muestran ejemplos de los métodos: forEach, filter y map.