echo "c/o/s/a/s/#s/o/b/r/e/#/l/i/n/u/x/,#p/y/t/h/o/n/,#n/o/d/e/./j/s,#a/n/d/r/o/i/d/././.#a/n/d#/a/l/l#/t/h/a/t#j/a/z/z"|sed -e's/\///g;s/#/ /g' cosas sobre linux, python, node.js, android... and all that jazz
Este es un pequeño script en bash, para analizar los mails enviados por determinado usuario a partir del archivo de log del postfix, no es lo optimo pero funciona :D
#!/bin/bash
echo "Buscando mail de: $1"
for i in $(grep sasl_username=$1 /var/log/maillog | awk '{print $6}'| cut -c -12); do grep $i /var/log/maillog| grep -E "from=|to="|awk '{if ($7 ~ "from"){ print "\n" $7 }else if ($7 ~ "to"){print $7}}';done
Explicar como funcionan los closures en javascript no es una tarea de una sola vez, siempre surgen dudas y hay que volverlo a explicar. Por eso les dejo está porción del video de Alex Russell (@slightlylate on Twitter) del google IO 2011, en el que explica de forma simple y muy precisa como funciona está técnica y sobre todo por qué es tan importante manejarla.
Digging about another project that requires sending messages via D-Bus I decided to make this simple app, that shows a notification of my recent tweets (your) timeline , and with this I can be updated about what's going on twitter while you do your daily tasks ...
It was originally madeonly for Linux environments, because in my work I have ubuntu, but then with the help of @dual3nigma decided port to mac and window$ using growl.
The app requires the libnotify library for Linux environments and growl for Mac / Window$, was made with Node.js and the code is available at Github where you will find all the steps to install and use.
Indagando sobre otro proyecto que requiere envio de mensajes a través de D-Bus se me ocurrió hacer esta simple app, que me mustra en un cuadro de notificación los últimos tweets de mi (tu) timeline, y con esto poder estar actualizado de lo que pasa en twitter al mismo tiempo que haces tus tareas diarias...
En un principio fue realizada sólo para entornos linux, ya que en mi trabajo tengo ubuntu, pero luego con la ayuda de @dual3nigma decidí portalo a mac y window$ utilizando growl.
La app require de la librería libnotify en entornos linux y de growl para Mac / Window$, fue realizada con Node.js y el código está disponible en Github en donde encontrará todos los pasos para instalarla y usarla.
Este es el segundo post de la serie sobre node.js (socket.IO y mongoDB), si no lo hicieron lean el primero post #1.
Este capitulo es sobre el manejo de rutas, como ya sabrán cuando creamos nuestro servidor (en nuestro caso usando express) debemos declarar las rutas que manejaremos, y si bien esto a primera vista parece fácil hay algunas cosas a tener en cuenta.
Comencemos con algo simple, establecer la respuesta para la ruta "/"
Con lo anterior establecemos como manejaremos un requerimiento de nuestro index (ej: http://javierviola.blogspot.com) y que para este post en particular responderemos simplemente con el texto handler : /.
Antes de seguir una aclaración, para demostrar el uso de rutas utilice simplemente los métodos res.write y res.end con el fin de imprimir la función que respondió el requerimiento y los parámetros pasados.
Esto nos permitiría responder tanto a un GET de /users como a /users/12 o /users/pedro, y esto es posible porque el primer parámetro de la funci&oacuet;n get express lo utiliza como una expresión regular, por lo cual esta definición puede servir para lista todos los usuarios, algun usuario o los usuarios que matcheen con el valor de :id.
Y esto es posible porque :id define un placeholder lo cual nos permite acceder al valor a través del objeto req.params.
Veamos las diferentes respuestas:
lucaMac:02-Routes pepo$ curl localhost:3000/users
handler: /users/:id?
parametros:
id : undefined
lucaMac:02-Routes pepo$ curl localhost:3000/users/pedro
handler: /users/:id?
parametros:
id : pedro
lucaMac:02-Routes pepo$ curl localhost:3000/users/25
handler: /users/:id?
parametros:
id : 25
También podemos definir varios placeholders simplemente cambiando el primer argumento:
Y como pueden observar, aquí no sólo accedemos a id y action, sino que restringimos el primero a que sea numérico y damos tres opciones para el segundo, gracias a las regex :)
Veamos como funciona:
curl localhost:3000/users/25/edit
handler: /users/:id
parametros:
id : 25
action : edit
lucaMac:02-Routes pepo$ curl localhost:3000/users/25/delete
handler: /users/:id
parametros:
id : 25
action : delete
lucaMac:02-Routes pepo$ curl localhost:3000/users/25/del
Cannot GET /users/25/del
lucaMac:02-Routes pepo$ curl localhost:3000/users/pedro/delete
Cannot GET /users/pedro/delete
Como vemos funciona y si la regex no se cumple 404 no se puede encontrar....
lucaMac:02-Routes pepo$ curl localhost:3000/users/pedro/delete -I
HTTP/1.1 404 Not Found
X-Powered-By: Express
Content-Type: text/plain
Connection: keep-alive
* Ya veremos al final una posibilidad de manejar esto de una forma más pro
Bueno ya manejamos los GETs ahora queremos manejar los POSTs para ello definimos:
app.post('/users',function(req,res){
res.write('handler post: /users/ \n');
res.write('parametros en body: \n');
for(key in req.body){
res.write('\t'+key+' : '+req.body[key]+'\n');
}
res.end();
});
Y en este caso nos valemos del middleware bodyParser que nos permite acceder a los valores pasados a través del objeto req.body.
Una cosa interesante de express es que nos ofrece el middleware methodOverride que nos permite ser más semántico en nustras rutas, ya que no permite que un POST sea transformado en un PUT o y así ser manejado por app.put o app.delete respectivamente...
Para ello veamos la siguiente definición:
/* post */
app.post('/users',function(req,res){
res.write('handler post: /users/ \n');
res.write('parametros en body: \n');
for(key in req.body){
res.write('\t'+key+' : '+req.body[key]+'\n');
}
res.end();
});
/* We can use put to be more semantics, like a RESTful api.
For this be use the middleware methodOverride, this
middleware check for the input _method in the body
(this input could be hidden for don't show to the
end user), and if its present tranform the post in the
_method input value and don't pass this in req.body
*/
app.put('/users',function(req,res){
res.write('handler put: /users/ \n');
res.write('parametros en body: \n');
for(key in req.body){
res.write('\t'+key+' : '+req.body[key]+'\n');
}
res.end();
});
/* delete, as in put we can use methodOverride to be
more semantic
*/
app.delete('/users',function(req,res){
res.write('handler delete: /users/ \n');
res.write('parametros en body: \n');
for(key in req.body){
res.write('\t'+key+' : '+req.body[key]+'\n');
}
res.end();
});
Como vemos definimos la misma ruta para los tres verbos http (POST,PUT,DELETE), y gracias al middleware methodOverride atender cada uno de ellos según el valor del input _method que se pase, y para explicarlo mejor un ejemplo:
Un post común:
lucaMac:02-Routes pepo$ curl -X POST -d "id=32&action=delete" localhost:3000/users/
handler post: /users/
parametros en body:
id : 32
action : delete
Un post, pero que será respondido como put:
lucaMac:02-Routes pepo$ curl -X POST -d "id=32&action=delete&_method=put" localhost:3000/users/
handler put: /users/
parametros en body:
id : 32
action : delete
vean como se pasa el valor de _method para que el middleware sobreescriba el método
Y por último el mismo post, pero respondido como delete
lucaMac:02-Routes pepo$ curl -X POST -d "id=32&action=delete&_method=delete" localhost:3000/users/
handler delete: /users/
parametros en body:
id : 32
action : delete
Y con esto queda explicado el middleware...
Una cosa importante a tener en cuenta es que las rutas se procesan secuencialmente y en la ubicación que fueron declaradas, es por eso que es muy importante hacer una declaración ordenada de nuestras rutas para que cada requerimiento sea atendido por la ruta que queramos y no por otra
Y haciendo uso de esto último, y utilizando un wildcard podemos manejar los errores 404 de una forma simple con esta ruta al final de todo:
app.all('*',function(req,res){
res.write('handler all: *\n');
res.write('ERR, no regex match\n');
res.end();
});
De esta forma atenderemos cualquier ruta (*) y en cualquier verbo http que no haya sido manejada anteriormente, con lo cual es muy útil para servir errores 404
Veamos como funciona:
lucaMac:02-Routes pepo$ curl -X POST -d "id=32&action=delete" localhost:3000/users/dasdsdas
handler all: *
ERR, no regex match
lucaMac:02-Routes pepo$ curl -X GET -d "id=32&action=delete" localhost:3000/usedasd
handler all: *
ERR, no regex match
Espero que haya sido claro en como es el uso de rutas con express y cualquier cosa no duden en contactarme
Les dejo el código utilizado Código en Github
Hasta la próxima (con la explicación de como funcionan los middlewares :) )
This series of posts, are related to the previous post node.js apps with real time which explains how to install the necessary components to develop an application with node.js + socket.IO + MongoDB.
But along the way I thought best to start with some basics, and from them be adding complexity until an application (I have not yet defined, hearing ideas...) which makes use of socket.IO for real-time interactions.
Well, let's start with a very basic introduction to Express frameworks.
This framework is widely used and perfectly combines with socket.IO, is very simple to use and brings many things "out of the box" ready to use.
The first thing we do is create the environment where we will develop this demo, we created the directory for this application and within the structure we create the following subdirectories:
var express = require('express');
var app = module.exports = express.createServer();
In these two lines load the module you need and call the function createServer we return an object with the web server will use to listen to requests and answer them.
Then we go to its configuration, which are the following lines
They first set the directory / views as a repository of templates, for this we use a variable defined globally node.js runtime is __dirname whose value is a string with the absolute path of the directory of your app.
Then we set to "ejs" as our engine for rendering templates, so remember to install the module via npm (npm install ejs).
The final set is to establish that we will not use a layout file for this example, if we wanted we could have a database file for all of our templates or for use only for some pages.
Then we declare the Middlewares we will use the first express.bodyParser () is used for parsing of the post (either json or not) and you return the result parses the variable accessible via req.body , the following is express.methodOverride () that is important to be declared after express.bodyParser () because it performs a check on the variable req.body , this middleware is useful to override the methods of our forms, just an input field with the hidden attribute, like this:
Then we declare the use of app.router which is simply the middleware that contains all the paths defined, and performs route lookup based on the URL of the current request and the HTTP method.
And finally declare the directory from where we provide our static content express.static (__dirname + '/ public') , this allows us to access our resources (in the directory public ) directly referencing it as , note that there is no need to reference the directory public but directly we refer to directories in there
Well, with this we have our first app using node & Express, the code in this first post is on Github Posts
lucaMac:nodeapps pepo$ git clone git@github.com:pepoviola/Socket.IO_rooms.git
Cloning into Socket.IO_rooms...
ERROR: Hi pepoviola, it's GitHub. We're doing an SSH key audit.
Please visit https://github.com/settings/ssh/audit/1767330
to approve this key so we know it's safe.
Fingerprint: 7c:(...):54
fatal: The remote end hung up unexpectedly
Yes, I had read the news that they had exploited a vulnerability that allowed update rails attributes inserting a new SSH key for more detail can read these links [0].
Therefore began an audit GitHub SSH key, for it asks that we enter the link listed above ("Please visit https://github.com/settings/ssh/audit/1767330") to approve or reject our key now ... If you have multiple keys as I uploaded to github, since different machines rub shoulders and this means that you must enter each machine and check if the ssh fingerprint is correct or not. Which brings us to what inspired me to write this post, i dont know if everyone knows how to read your fingerprint to validate the github presented to us, if do not know it I leave here a simple explanation.
The first thing to know is where is our public key, which usually is in the path ~/.ssh/ (/home/[user]/.ssh) with the name id_rsa.pub, when you have found this file must run the following command