nginx

No soy un experto en Apache, pero sí soy un conocedor de mod_rewrite y otras bondades. Lo encontraba muy poderoso y flexible. Antes de usar Apache desarrollaba en una madrola llamada ZBserver. Comparado con eso, Apache era ultra-chido.

Pero ahora por cuestiones de RAM estoy entrándole a nginx. Es tan poderoso como Apache pero más pequeño y en general me ha agradado mucho.

¿Qué ventajas tiene nginx sobre Apache?

Su configuración es muy sencilla y su arquitectura es minimalista. Si necesitas scripting, nginx es un excelente reverse-proxy. Tiene capacidades de detección y reescritura de URLs bastante más accesibles que las de Apache y que te permiten especificar qué directorios tienen acceso a scripting, qué archivos se procesarán y exactamente con qué FastCGI backend se procesarán. Tiene incluso cache para esas funciones.

Además tiene otras piezas mágicas como balance de carga, streaming de flv y mp4, compresión gzip, SSI, WebDAV, configuración de logs bastante amplia, funciona como proxy SMTP, POP3 e IMAP y soporta SSL.

Si Apache hace algo que nginx no haga, nginx se puede conectar a Apache. O sea, hace todo y por menos.

Con Apache, jack se estaba quedando sin RAM todas las tardes. Con nginx el uso es más predecible y junto con PHP-FPM y mySQL no exceden los 120 MB en promedio. En otras palabras: excelente.

La vida fácil con PostgreSQL

Mi trabajo actual está más chingón que el anterior.

Uno de los motivos es que para tener una copia de la base de datos de producción, en mi trabajo anterior era necesario saltar varios aros burocráticos para gestionar que se hiciera la copia del servidor de producción al de desarrollo. Y había que avisarle a todos los desarrolladores pues, dado que estaba basado en Microsoft SQL Server sin Microsoft Visual SourceSafe, era necesario llevar las versiones a mano.

Acá corres un comando y te baja la base de datos de producción automáticamente. PostgreSQL se la rifa infinitamente más que SQL Server.

Tradición

Como desarrollador unix entiendo que una tradición de unix es "no news is good news", es decir, si un programa no da salida quiere decir que todo estuvo bien. También entiendo el uso de los pipes y sus diferentes aplicaciones.

Entonces surge una discusión en svn.haxx.se, titulada Piping copious output to PAGER automatically--Pipear salida copiosa automáticamente a PAGER. Este tema sugiere que cuando svn detecte que se encuentra en una terminal y en cuyo entorno se ha definido un programa de visualización por páginas en la variable PAGER (less, more, view, etc.), se debe pipear a él la salida. Esto es particularmente útil en comandos como svn log o svn diff.

Por cómo plantea la idea, muchos parecen convencidos de que podría ser útil. Yo creo que nel.

¿Por qué?

Bueno, como dicen, si te tomaste la molestia de poner tu $PAGER entonces seguro te agradaría algo así. Pero la filosofía de unix es concordante con la teoría cero-uno-infinito, que dice que una tarea se hace ninguna vez, una sola vez, o una cantidad indeterminada de veces. Si lo vas a meter, lo vas a meter sólo una vez y para siempre.

Entonces esta funcionalidad debería ser parte del shell, no de svn ni de ninguna herramienta. Hacer este paginado parte de una herramienta significa que todas lo querrán tener, y será código duplicado, de calidad y funcionalidad variable.

Mejor hackear tu shell para lograrlo. De paso te ahorras tener que probar si estás a un tty o no.