Desde hace aproximadamente unos dos años he estado flirteando con alternativas a PHP, en especial NodeJS.  El motivo principal ha sido conocer otras soluciones con una aproximación diferente a los problemas que plantea el entorno web en general, y la potencial mejora que supone compartir el mismo lenguaje de programación en el entorno cliente y el servidor. Python también está en la lista de flirteos, aunque debo decir que a cierta distancia.

El atractivo por NodeJS es (y en parte seguirá siendo) un enfoque diferente para la operativa en los cuellos de botella de las aplicaciones web. Al poder tratar las operaciones I/O de una forma asíncrona (eventos y callbacks), es un valor añadido en ciertos casos.  El enfoque asíncrono de NodeJS permite una ejecución más fluida, que a su vez permite combinar consultas exigentes con el trabajo paralelo mientras se espera a la finalización de estas tareas.  Además, una orientación a eventos, soluciones PubSub y otras características derivadas hacen pensar en NodeJS como una opción más que interesante para ciertas soluciones del entorno cloud.

Velocidad del código, velocidad del desarrollo

PHP tiene y tendrá infinidad de defectos, pero por alguna razón es el lenguaje más utilizado para aplicaciones web.  La razón es sencilla: es fácil empezar el desarrollo con PHP, no requiere una curva de aprendizaje como Java. En una palabra, funciona.

Pero la propia evolución de PHP no ha sido nada sencilla. El paso de la versión 4 a la 5 supuso un salto bastante difícil de seguir, y la introducción gradual de los Frameworks primero (empujado probablemente por actores como Ruby on Rails),  y en especial de los PSR, parece haber dividido una comunidad que debate entre la necesidad de estructurar y madurar el lenguaje, o mantenerlo en ese nivel de libertad que ha tenido desde sus inicios. Probablemente la aparición de lenguajes como Ruby (y RoR) como Python ha dado más empuje a la primera alternativa. Sinceramente lo desconozco.

Por último, la aparición de HipHop primero, y de HHVM después, han dado un empuje a la velocidad de carga de las aplicaciones PHP, con una integración completa (o casi) en muchas aplicaciones del ecosistema PHP,entre las cuales destacaría algunos casos clave, como Drupal, MediaWiki y Magento 2.

Es posible que las próximas versiones de PHP incorporen más mejoras en el rendimiento. ¿El mismo que Java? Probablemente no, pero seguro que a la par con NodeJS y mejor que otros lenguajes interpretados. Dependerá del uso que se le dé. En realidad, se puede descartar a PHP por varios motivos, pero en pocos casos ése será el de su rendimiento.

Los nuevos entornos

No pienso en Javascript como algo que deba convertirse en un lenguaje de programación para todos los usos, pero sí para cualquiera. Si un lenguaje permite moverme en varios entornos a la vez (navegador, servidor, aplicación móvil o de escritorio con node-webkit), eso es algo de valorar si por un lado se quiere prototipar y producir un resultado sin detenerse en los detalles del tipado de datos, o en un requerimiento de un extremo rendimiento o de extrema fiabilidad en algunos procesos.

Cada proyecto es diferente, pero PHP, como afirma el artículo comentado más arriba, es lo suficientemente rápido y maduro para ser un gran candidato.

• Dos bibliotecas de código para convertir a HTML las fórmulas de LaTeX, ya sea con latex2html5, o con texlive.
• Un artículo interesante sobre la gestión de errores en NodeJS.
• Testeo unitario en AngularJS.
• Octane, la propuesta de Google para el benchmarking de motores Javascript.
• Una bastante completa introducción a EmberJS.
• TableclothJS, un plugin de jQuery para tablas.
• Un tutorial de School of Data para Tabula, la herramienta que permite extraer tablas de datos de los archivos PDF.

</ul>
Un video de Code For America, en concreto de Catherine Bracy, hablando del por qué los buenos hackers (que no son piratas) hace buenos ciudadanos:</p>

[ted id=1933]

Feliz verbena!

Read more »

 
El humilde border-radius y lo que podemos dar de sí. Una presentación de de Lea Verou en la Fluent Conf 2014:

• Apache Spark para Machine Learning.
• Del Cybercrafting a la Industria 4.0, 2005-2014, en Consultor Artesano.
• Un proyecto para aprender a programar diseñando juegos: Invent with Python.
• Una galería de ejemplos de visualizaciones, bastante diferente y sofisticada.
• Las cuentas de los partidos en ocho puntos, ahora que se acercan otra vez las Elecciones Europeas y la decisión del tipo de voto.
• Un artículo en El País sobre los Games for Change.
• Aplicar PageRank a los pases entre jugadores de un equipo de fútbol para entender sus estrategias. Ale, qué tranquilo me he quedado :-).

</ul>
El video de hoy trata sobre la aplicación de Javascript para controlar "cacharritos" como Arduino, o para programar un drone:</p>
Read more »

Admito que de primeras este título puede parecer mezclar churras con merinas, pero no lo es en absoluto.  El análisis de datos en el ámbito de los negocios se centra en la optimización de los beneficios. Esa optimización a su vez hace rentable la recopilación de los datos dentro de un proceso, un flujo de actividad de sus clientes potenciales: si recopilando unos datos la empresa gana dinero, los seguirá recopilando.

Así pues, es posible que tu rango de actividades esté fuera de ese flujo de datos de interés para las empresas. Y en ese caso, corres el riesgo de ser excluído. Así lo comentaba Jonas Lerman en su artículo Big Data and Its Exclusions del Stanford Law Review del Septiembre de 2013 (el destacado es mío):

big data has the potential to solidify existing inequalities and stratifications and to create new ones. It could restructure societies so that the only people who matter—quite literally the only ones who count—are those who regularly contribute to the right data flows.

Pero las exclusiones también pueden suceder dentro del flujo de datos. Es lo que expone el artículo Big Data’s Dangerous New Era of Discrimination, en el que comenta:

But the main source of concern won’t be privacy, per se — it will be whether and how companies and organizations like your own use Big Data analytics to justify their segmentation/personalization/discrimination strategies.

The more effective Big Data analytics are in profitably segmenting and serving customers, the more likely those algorithms will be audited by regulators or litigators.

Big Data para el desarrollo

El documento adolece de su relativa antigüedad y deja abiertos muchos puntos que quizá ahora se podrían concretar. Pero en todo caso, presenta una serie de posibilidades para la aplicación del Big Data a este contexto:

• Disponibilidad de dispositivos de bajo coste y fácil mantenimiento para recopilar datos.
• Crowdsourcing como modelo operativo en la recolección.
• Estándares de privacidad para los datos personales.

• Mejora de la capacidad de seguimiento y respuesta de sucesos inesperados (Outbreak).
• Mejora de la comprensión del cambio de comportamiento en las crisis.
• Mapeo más concreto de las necesidades de los servicios.
• Habilidad para predecir los cambios en la la oferta y la demanda.

• Comprendiendo en event loop de NodeJS.
• El equilibrio entre el poder y la responsabilidad, en una historia muy humana.
• La relación entre el presupuesto y las bajas militares, en un cambio de representación gráfica que muestra mejor la información y la historia que hay detrás.
• Stories through data, que intenta aglutinar ejemplos de historias explicadas a través de la representación de datos.
• Las cuatro claves para el 100% de uptime con NodeJS.

</ul></p>
Read more »

• Demostración del Algoritmo Poisson para la detección de comunidades, visualizado con D3.
• Una lista de recomendaciones para quienes se introduzcan en el campo de la visualización de datos por la vía del freelancing.
• Una página con una utilidad para practicar con los streams de NodeJS. Poder entender a fondo la funcionalidad de los streams en NodeJS es clave para sacar ventaja en aspectos como el tiempo de respuesta (tiempo hasta el primer byte).
• Sound Manager 2, reproductor audio open source (BSD) para javascript y los navegadores, con fallback a Flash si fuera necesario.
• El reto de crear una API en NodeJS que responda en 5ms. Aunque se centra en aspectos concretos de la optimización, incluye comentarios interesantes.
• Artistas y científicos, más parecidos de lo que se cree, según este artículo en Scientific American.
• Trucos para obtener una versión simplificada de una base de datos de Magento, y poder trasladarla a nuestro entorno de desarrollo.

</ul></p>
Read more »

• Un documento interesante, Open Data Resource Kit.
• WebRTC black magic, para entender algo más sobre esta especificación.
• OfflineJS, una biblioteca para gestionar el momento en el que los usuarios de nuestra aplicación se quedan sin conexión.
• Mozilla Lightbeam, una herramienta para tomar conciencia de la propia privacidad, y ver (con Firefox) quién sigue tu navegación web.
• Code Combat, para aprender a desarrollar javascript mientras jugamos.
• ¿Qué operadores de comparación en javascript utilizarías para verificar si dos valores valen cero? Una pregunta fácil, hasta que le echas un vistazo a esta tabla comparativa de operadores.
• Last but not least, las directrices para la realización de infografías, PDF de la Office for National Statistics británica, en un enlace al final del artículo. Muy pero que muy interesante.

</ul>
Y el vídeo, para conectar NodeJS con Arduino, mediante el framework JonnyFive:</p>
Read more »

Tómate un minutillo para hacer unos cálculos sobre estas dos muestras de datos:

• 1, 2, 3, 4, 5
• 1, 2, 3, 4, 100

Si lo has calculado, habrás comprobado que la media se adapta al valor extremo (100), por lo que cambia de 3 a 22, pero que en cambio la mediana se mantiene impasible ante el cambio.

Lo primero que pasa por la mente de mucha gente es que han cometido un error al calcular. La segunda fase es que la fórmula o el sistema de cálculo está equivocado: ¿Para qué quiero que la mediana se mantenga inmóvil después de un cambio tan extremo? Y aquí es cuando llegamos al meollo del asunto: la media y la mediana se crearon para fines muy distintos.

Hormas, zapatos, árboles y bosques

Porque eso es lo que sucede cuando representamos los datos en al menos dos dimensiones: lo que nuestro razonamiento sudará para encontrar, nuestro ojo lo procesa en décimas de segundo.

El cuarteto de anscombe: cuando las cifras no lo explican todo

La imagen lateral son cuatro gráficos, conocidos como el cuarteto de Anscombe, y son un ejemplo clave para entender la diferencia entre nuestra capacidad para procesar números y para identificar los gráficos.

En los cuatro gráficos, los valores para los principales indicadores estadísticos (media y varianza de x e y, correlación) y la recta de regresión, son idénticos (hasta el tercer decimal). Si tapáramos los gráficos anteriores y sólo mostráramos los indicadores anteriores, sería muy difícil deducir las grandes diferencias entre ellos.

Es en estas situaciones, especialmente cuando en un proceso de análisis pueden aparecer gráficos tan dispares (lo cierto es que no siempre es así), en el que el análisis exploratorio de datos y la representación gráfica nos ayuda a tener una idea de lo que los datos nos deparan.

Al fin y al cabo, el análisis y la representación gráfica pueden cooperar.

Diez años de MapReduce

Diez años más tarde MapReduce se encuentra en el núcleo del BigData, especialmente a través de Hadoop.  Todas o casi todas las grandes compañías que ofertan bigdata ofrecen algún tipo de implementación de Hadoop a sus clientes.

Pero Hadoop es una implementación que no sólo incluye un algoritmo, sino también un sistema de archivos (Hadoop Filesystem, HDFS, basado a su vez en el Google File System, GFS) y todos los mecanismos de control necesario para llevar a cabo el tratamiento de datos a gran escala.

Entonces, si lo que queremos es entender el cambio de paradigma que supone MapReduce para tratar datos, ¿Necesitamos instalar Hadoop o un similar para entender el funcionamiento de MapReduce? Si lo que quieres probar son tus scripts con un pequeño conjunto de datos, no.

Consola y pipes

cat archivo.csv | ./mapper.php

#!/usr/bin/php


$stdin = fopen( 'php://stdin', 'r' );

while( $line = fgetcsv( $stdin, 10000) ) {

// Procesar/mapear los datos y ejecutar un echo sprintf:

  echo sprintf("%s\n", $line[0]);

}

?>

En el caso del script de reducer (reducer.php), lo que haremos es contar cuántas veces aparece cada cadena en el listado (es decir que ignoraremos el valor numérico).  El script es bastante similar al del mapper, pero ahora mantendremos un contador de las veces que aparece la clave, y cuando ésta cambie, la imprimiremos:

#!/usr/bin/php


$stdin = fopen( 'php://stdin', 'r' );

$currentKey   = null;

$currentCount = 0;

while( $line = fgets( $stdin ) ) {

// Generas el proceso de 'reducción'

  if ($line !== $currentKey) {

    echo sprintf("%s\t%s\n", $currentKey, $currentCount);

    $currentKey = $fields[0];

    $currentCount = 0;

  }

  $currentCount++;

}

if ($currentKey !== null) {

 echo sprintf("%s\t%s", $currentKey, $currentCount);

}

?>

Ejecutando el proceso conjunto

chmod +x mapper.php reducer.php

cat archivo.csv | ./mapper.php | sort | ./reducer.php

El resto de la implementación de MapReduce (replicación de datos, gestión de recursos, partición del dataset, etc.) es imprescindible para operar con un gran conjunto de datos, pero no para entender el concepto de base: procesar datos de forma paralela.

Nota final: Aunque Hadoop requiere el uso de Java para desarrollar trabajos MapReduce, incorpora también una funcionalidad llamada Hadoop Streaming que permite la ejecución de scripts MapReduce en prácticamente cualquier lenguaje de programación. La contrapartida es un mayor uso de recursos y mayor lentitud, pero desde luego ayuda a realizar pruebas sencillas con scripts de PHP, python o similares.