En la investigacion de node.js, obviamente busque algunas comparaciones con el viejo y poco querido PHP.

Obviamente intuia que el server de node.js era mucho mas rapido que apache, pero no tenia tiempo de hacer las pruebas, es por eso que busque en internet que se habia hecho al respecto, y aca dejo los datos.

Primero una comparativa de las tecnologias

	Apache, PHP	node.js
syntax	Additional language to web standard ECMA script try to use common structures	One language to rule them all = reuse parts of your framework on the client side
strings	‘line line’	‘line\nline’ or “line\n\ line”
templates	<code><?php // code ?></code>	var s = ‘<code>’; // code s += ‘</code>’; // send response http://github.com/creationix/microtemplates
database interface	PDO + prepared Statements (includes class instance support)	Still no prepared statements, 1.5 – 3x slower Driver update
performance		faster
unicode	PCRE	no Unicode Character Properties / Scripts / Blocks in RegExp (only \w, \W consider Unicode whitespace) add chars manually to regexp
order	no namespaces up to 5.3	simple modules / namespaces
serving files	Apache serves static files	Overhead to serve static files Use additional webserver (nginx) or included in web framework
access	Only synchronous access … but easier code	Asynchronous access via closures … highly nested code http://github.com/creationix/step
OOP	implicit memoization via __get() and reuse of requested key	getters (/setters) must access key with other name, bad for iteration or JSON notation
platform	many reliable extensions	many extensions still experimental … but the community is dynamic

	PostGIS/Postgres	MongoDB	CouchDB
GIS functionality	rich	just stuff based on points	few
stable	yes	yes	probably
GIS standards	full OpenGIS support (except for GeomColl in relational functions, workaround functions)	no OpenGIS at all, just points	full excepting for GeomColl
GIS indexing	no GeomColl index single geoms	yes	yes
GIS performance	fast

Fuente: https://docs.google.com/View?id=dfzvhszt_30drxqrvhk

Comparativa de rendimiento

Number of requests performed: 2000
Number of multiple requests made: 50

Number of requests performed: 2000Number of multiple requests made: 100

Number of requests performed: 2000
Number of multiple requests made: 150

Fuente: http://ricallinson.com/nodejs-ash-vs-php-symfony-vs-php-codeigniter

Seguire mi investigacon, cada vez me convenso mas de que node.js tiene un gran futuro.

nodejs javascript server side

Evaluando Node.js

Node.js es una aplicacion que permite correr JS desde el lado del servidor.

Si bien es un proyecto muy nuevo, segun se ha podido apreciar cuenta con mucho potecial, y lo mas interesante, podemos meter frameworks en JS como modulos, y programar en forma mas “comoda” en javascript.

Para los que andan en la busqueda de un nuevo lenguaje (en especial los programadores PHP que siempre andan buscando cambiar, pero no encuentran un lenguaje comodo) es quizas la mejor opcion.

JavaScript es un lenguaje muy simple de comprender, orientado a objetos, y con infinitas posibilidades. Sin lugar a dudas, hay que poner mucho trabajo para node.js siga creciendo.

Bueno, manos a la obra, vamos por parte.

Estas pruebas las hice en Ubuntu, pero mas adelante veremos lo mismo sobre FreeBSD.

Instalacion.

Primero que nada bajamos node.js http://nodejs.org/#download

Despues tenemos que instalar algunos paquetes para poder compilar

#apt-get install build-essential libssl-dev

Ahora si, vamos a compilar.

Descomprimimos:

#tar -zxvf node-v0.2.3.tar.gz

vamos al directorio:

#cd node-v0.2.3

Configuramos:

#./configure

Compilamos:

#make

Instalamos:

#make install

Primeras pruebas

Bueno, ya con node.js instalado, solamente tenemos que ejecutar “node” y veremos la consola.

#node

Para salir de la consola, solamente tenemos que precionar ctrl+D

La consola en si no va  a ser tema de estudio, pero si queremos hacer una prueba, podemos ejecutar

var a="hola mundo";
a;

Como siempre, lo ideal es leer la documentacio, pero vamos a hacer algunas pruebas mas.

Creamos un archivo llamado server.js con nuestro editor preferido para programar y ponemos este codigo

var http = require('http');

http.createServer(function (request, response) {
  response.writeHead(200, {'Content-Type': 'text/plain'});
  response.end('Hello World\n');
}).listen(8124);

console.log('Server running at http://127.0.0.1:8124/');

Guardamos y ejecutamos escribiendo

#node server.js

Ahora comprobamos si efectivamente funciona abriendo nuestro navegador favorito y poniendo como url

http://127.0.0.1:8124

Bueno, por el momento ha sido todo, pero seguire escribiendo articulos sobre node.js ya que me parece un proyecto apacionado.

Estoy en un experimento con webcams y java, y bueno, obviamente al no haber laburado nunca con este tema sobre linux se me vinieron todos los problemas juntos.

Para ir resumiendo, el jar de V4L4J (Video for linux for Java) anda perfecto, pero el ejemplo tiene algunos temillas que hay que correjir, es por eso que les dejo el codigo fixeado, asi los que quieran programar algo en Java con webcam sobre linux ya tienen que con empezar.

En breve escribiré un post sobre como dejar funcionando la webcam en ubuntu (va, kernel 2.6.x) que no ha sido nada facil, ya que hay que tocar algunas cosas (mas que nada por gspca).

Algunos datos que les pueden servir.

Normalmente para trabajar con la webcam en Java solo basta con la libreria JMF (Java Media Framework) que nos da soporte a todo el mundo multimedia. El tema es que para poder implementar video, audio o lo que sea se requiere el source. Este source puede ser un archivo o un streaming, en el caso de windows solemos usar v4W (Video for windows), pero en linux es necesario v4l (o similares) y por defecto no hay soporte para ese source.

Lamentablemente hay mas documentación al respecto sobre C++ que Java, pero es 100% aplicable, así que si saben C++ no habrá problemas con leer el source y entender como hacer las cosas o incluso extender las funcionalidades de package.

import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
import java.io.IOException;
import java.nio.ByteBuffer;

import javax.swing.ImageIcon;
import javax.swing.JFrame;
import javax.swing.JLabel;

import au.edu.jcu.v4l4j.FrameGrabber;
import au.edu.jcu.v4l4j.exceptions.V4L4JException;
import au.edu.jcu.v4l4j.VideoDevice;
import au.edu.jcu.v4l4j.V4L4JConstants;
import au.edu.jcu.v4l4j.ImageFormat;
import au.edu.jcu.v4l4j.ImageFormatList;

public class Exa5 implements Runnable {
	private Thread thisThread;
	private VideoDevice vd;
	 private JLabel l;
     private JFrame f;
     private long start = 0;
     private int n;
     private FrameGrabber fg;
     private Thread captureThread;
     private boolean stop;

	public static void main(String[] argv){

		try{
        String dev = "/dev/video0";
        //int w=640, h=480, std=FrameGrabber.STANDARD_WEBCAM, channel = 0, qty = 60;

        int w=640, h=480, std=V4L4JConstants.STANDARD_WEBCAM, channel = 0, qty = 60;
        new Exa5(dev,w,h,std,channel,qty);
		}catch(Exception e){ System.out.println("Buuu: "+e.toString()); }

	}

	 public Exa5(String dev, int w, int h, int std, int channel, int qty) throws V4L4JException{
		 initFrameGrabber(dev, w, h, std, channel, qty);
        initGUI();
        stop = false;

		thisThread = new Thread(this, "JMotion");
		thisThread.start();
	}

	 private void initGUI(){
	        f = new JFrame();
	        l = new JLabel();
	        f.getContentPane().add(l);
	        f.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
	        //f.addWindowListener(this);
	        f.setVisible(true);
	        f.setSize(fg.getWidth(), fg.getHeight());
	    }

	 private void initFrameGrabber(String dev, int w, int h, int std, int channel, int qty) throws V4L4JException{
	        vd = new VideoDevice(dev);
	        ImageFormatList l = vd.getDeviceInfo().getFormatList();
	        for(ImageFormat f : l.getNativeFormats()) {
	        	  System.out.println("\t"+f.getName()+" - "+f.getIndex());
	        	  System.out.println("\t\tResolutions: "+f.getResolutionInfo());
	        	}

	        fg = vd.getJPEGFrameGrabber(w, h, channel, std, qty);
	        fg.startCapture();
	        System.out.println("Starting capture at "+fg.getWidth()+"x"+fg.getHeight());
	    }

	 public void setImage(byte[] b) {
	        l.setIcon(new ImageIcon(b));
	    }

	public void run(){
		  ByteBuffer bb;
	        byte[] b;
	        try {
	                while(!stop){
	                        bb = fg.getFrame();
	                        b = new byte[bb.limit()];
	                        bb.get(b);
	                        setImage(b);
	                        System.out.println(bb.toString());
	                }
	        } catch (V4L4JException e) {
	                e.printStackTrace();
	                System.out.println("Failed to capture image");
	        }
	}

	   public void windowClosing(WindowEvent e) {
           if(captureThread.isAlive()){
                   stop = true;
                   try {
                           captureThread.join();
                   } catch (InterruptedException e1) {}
           }

           fg.stopCapture();
           vd.releaseFrameGrabber();

           f.dispose();
   }

}

Este post quizas no refleje nada tecnológico, pero creo importante poder dar un punto de vista de un tipo que ha estado en este rubro durante mucho tiempo y ha visto mujeres a lo largo de varias empresas.

En mi opinion, tanto hombres como mujeres pueden programar, solo que quizas los hombres toman las riendas de una vida “anormal” mucho mas en serio que las mujeres.

Aca no hablamos ni de inteligencia ni de capacidades, hablamos de un estilo de vida.

En mi tiempo como programador, me he encontrado con grandes mujeres programadores, por ejemplo Romina DeZan, Laura Schonfeld, o Antonela Carrivale… grandes minas del mundo DEV…. pero porque no encuentro mas???

Creo que para dicha respuesta hace falta analizar el comportamiento y estilo de vida de los actores que intervienen en este problema que algunos piensan que no tiene solucion.

En mi simple y sinsera opinión (que obviamente no le importa a nadie) creo que es por una cuestion de tiempos y vida social. Los hombres de alguna forma encontramos gente que nos entienda a la hora de ser nerds hablando de linux, C++ o PHP, mientras que las mujeres ven ese momento de “entendimiento social” mucho mas dificil haciendo su tarea de comprometerse con el mundo DEV mas dificil. Al ser seres casi en un 100% sociables, es un impedimento complicadisimo.

Sin embargo, las mujeres que encontraron un escenario ideal en sus vidas para ser nerds, demuestran ser igual que los hombres mas capaces e incluso mejores en algunos aspectos.

Vuelvo a insistir,  este post no aporta nada de tecnologia (como estaran acostumbrados en este blog), pero si quiere acercarse a todos aquellos que se dedican a este mundo.

Vamos chicas, ustedes pueden ser mejores que nosotros!

El sabado 11 de septiembre se dictara un taller de extensiones de firefox, donde usaran como nuevo juguete estrella a jetpack (el nuevo framework para el desarrollo de extensiones en firefox).

Aca les dejo literalmente lo que estan en la web del event segun mozilla.

El taller comenzará a las 11 de la mañana y durará aproximadamente 5 horas. El evento se realizará en las oficinas de Globant en el complejo Costa Salguero, Rafael Obligado 1221, frente al pabellon 4, Ciudad Autonoma de Buenos Aires.

El evento requiere registración previa en http://eventioz.com/events/taller-de-extensiones-de-firefox o en el formulario que se encuentra al final de esta página.  El plazo de registación vence el día viernes 10 de Septiembre a las 15 horas.

Si querés participar, deberás traer tu propia computadora con estos programas instalados:

• python >= 2.5
• el ultimo nightly build de firefox (disponible en http://nightly.mozilla.org/ )

Sistemas operativos recomendados:

• Debian Linux o derivados
• Mac OSX

Al final de taller se realizara un concurso de extensiones donde se premiaran los mejores desarrollos con merchandising de Firefox.

Esperamos verlos ahi, y que gane el mejor!.

Bueno, he tenido una necesidad que todos en algun momento tenemos, intentar complicar la lectura de nuestro codigo PHP.

En mi caso, arme un script muuuy simple, donde paso por base64 los archivos que me interesan.

$secre=array("a","b","c","d","e","f","g","h","i","j","k");

for($x=0; $x<=5; $x++){
	$body=file_get_contents("/path/to/archivo.php");
	$phra=$secre[rand(0,count($secre)-1)].$secre[rand(0,count($secre)-1)].$secre[rand(0,count($secre)-1)].$secre[rand(0,count($secre)-1)];
	$encode=base64_encode($body."\r\n //".$phra);

	$final="eval(base64_decode('$encode'));";
	file_put_contents("/path/to/archivo.php",$final);
}

Básicamente es tomar el contenido del archivo, hacerle un base64, agregarle un comentario con un rand por que me pareció bonito (hay razones, no vienen al caso) y escribir ese resultante en el mismo archivo. Metemos esos procedimientos en un for (limitado a 5, pero podríamos ponerlo a 10, ojo con el consumo de recursos, no limarla).

Saludos.

Bueno, esto lo pongo porque seguramente en algun momento tendra que obtener las coordenadas de un element con javascript.

function getCoordinates( Element ){
	var coordinates = {left:0,top:0};

	while( Element != null ) {
		console.log(Element, Element.offsetLeft  ,  Element.offsetTop);
		coordinates.left += Element.offsetLeft;
		coordinates.top += Element.offsetTop;
		Element = Element.offsetParent;

	}
return coordinates;
}

La funcion es simple, pasame el element (como objeto, con getElementById) y el script empieza a buscar todos los parents de ese objeto, y calcula su offsetLeft y offsetTop, como resultados obtenemos el total.

Espero que les sea util.

Si les ha pasado lo mismo que a mi, que Reflection en Chrome no esta operativo y muestra 2 veces la misma imagen, es porque deben parchar (yo lo tengo implementado con mootools 1.2.4 y la verdad tube que fixear varias cosas).

El problema es webkit419, que algo anda mal con la implementacion de canvas y objetos 2d… raro.

Solo basta con cambiar estas lineas de JS.

} else {
			var can = new Element('canvas').setProperties({'width':arg.width, 'height':arg.height});
			if(can.getContext && !Browser.Engine.webkit419){
				/*var ctx = can.getContext("2d");
				ctx.save();
				ctx.translate(0,arg.height-1);
				ctx.scale(1,-1);
				ctx.drawImage(i, 0, 0, arg.width, arg.height);
				ctx.restore();
				ctx.globalCompositeOperation = "destination-out";
				ctx.fillStyle = arg.color;
				ctx.fillRect(0, arg.height*0.5, arg.width, arg.height);
				var gra = ctx.createLinearGradient(0, 0, 0, arg.height*arg.ref);
				gra.addColorStop(1, "rgba(255, 255, 255, 1.0)");
				gra.addColorStop(0, "rgba(255, 255, 255, "+(1-arg.ref)+")");
				ctx.fillStyle = gra;
				ctx.rect(0, 0, arg.width, arg.height);
				ctx.fill();
				delete ctx, gra;*/

				 var ctx = can.getContext("2d");
                ctx.save();
                ctx.translate(0,arg.height-1);
                ctx.scale(1,-1);
                ctx.drawImage(i, 0, 0, arg.width, arg.height);
                ctx.restore();
                ctx.globalCompositeOperation = "destination-out";
                ctx.fillStyle = '#000';
                ctx.fillRect(0, arg.height*0.5, arg.width, arg.height);
                var gra = ctx.createLinearGradient(0, 0, 0, arg.height*0.5);
                gra.addColorStop(1, "rgba(255, 255, 255, 1.0)");
                gra.addColorStop(0, "rgba(255, 255, 255, "+(1-0.3)+")");
                ctx.fillStyle = gra;
                ctx.fillRect(0, 0, arg.width, arg.height);

			}
			return can;
		}

Seguramente a varios les habra pasado que quisieron implementar mooflow con una version de mootools bajada por ustedes mismos y se dieron cuenta que no caminaba.

Seguramente su firebug estaba abierto, y vieron el mensaje de error

uncaught exception: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIDOMCanvasRenderingContext2D.drawImage]” nsresult: “0×80040111 (NS_ERROR_NOT_AVAILABLE)”

Bueno, esto no es el fin del mundo, es un simple error conceptual por la gente de mooflow, pero lo solucionamos muy facilmente.

Busquen esta linea y modifiquen segun corresponda.

Element.implement({
reflect: function(arg){
//i = arg.img.clone();
var i = arg.img.clone().set('src', arg.img.src);

En uno de mis sitios mas “visitados” he integrado hace unos 3 meses el api de facebook connect, con la expectativa de aumentar el trafico, viralizar mis contenidos y sobre todo poder probar el api de la gente de facebook (que tan popular es en estos días).

Lo primero que me molesto, fue generar archivos en mi proyecto para la gente de facebook, también el api me parecio muy limitada y lo peor de todo… tardaba horrores en cargar.

Mas allá de que mi sitio era un promedio de 10 veces mas “lento”, y que cada 2 x 3 el api se comportaba de forma muy rara, los resultados fueron realmente muy malos, ya que no me aporto en nada haber creado fanpage, programar el compartir en tu muro lo que veías, etc.

Claro esta que podemos discutir de si los contenidos son interesantes o valen la pena compartir, o si el registro era necesario o no, pero claramente no todo lo que se hace con facebook es bueno y exitoso (claramente siempre depende de varios factores).

Entonces fue cuando tome la decisión de eliminar todo lo relacionado con facebook (a nivel api) de mi sitio (ya que considere que no era targe para facebook), ya que prefería velocidad y comodidad para mis users vs “viralidad”.

Casi decepcionado habia perdido las esperanzas de “viralizar” o “socializar” mi sitio cuando recorde a google friend connect.

Entre, di de alta mi sitio, eleji mi gadget (la toolbar de amigos, comments y demás) y la implemente en todas las pages de mi site.

Realmente google friend connect es otra cosa, cargaba 10 veces mas rápido que facebook connect, no se rompe nunca, no he detectado comportamientos raros, y no es tan “rebuscada” como la api de facebook.

Claro que esta es mi simple apreciación (Cesar Casas) y opinión, pero doy un total apoyo a google friend connect, y le saco todas las fichas a facebook.