Análogamente al curso de Analytics Platform Principles que comentaba hace unos días, Google ha publicado otro curso centrado en el análisis de datos. En este caso la herramienta central es Fusion Tables, a partir de la cual podemos entrar más a fondo en conceptos básicos para extraer conclusiones a partir de datos.

Desde luego recomendable para quien crea que le fallen los conceptos básicos, y quiera ponerse a prueba, siempre desde la práctica y las explicaciones amenas.

Quizá la diferencia más remarcable entre este curso y el de Analytics es que en este caso hay mas ejercicios, más texto y menos videos, por lo que es necesario prestar más atención para marcar el ritmo de progreso del curso.

Más tarde de lo previsto, pero aquí dejo los enlaces de esta semana (pasada).

• Ya puedes descargarte 40GB de la wikipedia en formato ZIM, en Xataka.
• ¿Puede un juego serio aumentar nuestra  conciencia de privacidad en Facebook?
• Amazon y el futuro del e-commerce predictivo, en el SAS blog.
• Las dinámicas de pases en la NBA, vía flowing data.
• Guía de estilo de visualizaciones de Sunlight Foundation vía visualizing data.

Aprender analytics de forma amena

Funcionamiento interno de Analytics según el dispositivo

Al final del curso hay una prueba de capacitación en la que hay que conseguir al menos un 80% de la valoración. Todo gratis, aunque no hay que confundir este curso que el de certificación Google Analytics IQ. Tómatelo como algo para repasar y principalmente entender.

Vale la pena echarle un vistazo a Google Analytics, como lo es ponerse al día sobre cualquier sistema que permita medir el funcionamiento de nuestras apps, tiendas, blogs.

Por cierto, que la prueba de certificación está disponible hasta el 27 de Marzo de 2014 (te queda una semanita).

Programar para NodeJS implica casi por definición utilizar su gestor de paquetes, NPM, y por ello utilizar la instrucción require() para utilizar las funcionalidades de esos paquetes en nuestro código.

Por el grado de madurez en el que está actualmente NodeJS (aunque en principio la versión 0.12 será la staging version para la 1.0), hay ciertos patrones y directrices en la estructura de los módulos que quedan abiertos por ahora. Uno de ellos es el funcionamiento de require() y de lo que retorna esta función.

Retornando valores en nodeJS con require()

var elementoRetornado = require('/ruta/a/archivo.js');

module.exports = ;

En el blog de goodegs han explicado los principales casos de elementos a retornar con require() y algunos ejemplos. Sólo para resumir brevemente, los casos que comenta son los siguientes.

Namespace

Un patrón del require para este caso es:

var ns = require('/ruta/a/namespace.js');

var utilidadDelNamespace = ns.Utilidad;

Función

El patrón para require es:

var proxyFunction = require('modulo.js');

var modulo = proxyFunction();

Función de orden superior

var functor = require('modulo.js'); // Retorna la función

var adaptador = require('modulo2.js');

var item = functor(adaptador);

Constructor

var Blog = require('blog.js');

var miBlog = new Blog('sopadebits.com');

Singleton

var singleton = require('singleton-module.js');

singleton.method(arg);

Como extensión de un objeto Global

Aunque el patrón puede variar sensiblemente, el ejemplo de uso sería:

require('should');

var user = {

  name: 'Juan'

};

user.name.should.equal('Juan');

Monkey Patch

Y hasta aquí los patrones de require que podemos encontrar más habitualmente. No descartes leer el artículo en inglés, que es el que realmente tiene el mérito, y más detalles.

• KimonoLabs, un servicio del estilo webscrapping que genera APIs JSON/CSV en base a las páginas que quieres recuperar.
• PromiseJS, un sitio para introducir y difundir el uso de las promises en javascript.
• El rol de los algoritmos en la visualización de información, en Fell in love with data.
• El Nudge Unit, o la unidad de empujoncitos, para introducir el Behavioral Insights Team, que intenta ayudar a la gente a tomar mejores decisiones
• La escalabilidad de la arquitectura como una de las razones de la compra de WhatsApp, en el High Scalability blog.

</ul>
 </p>

Barcelona Skyline from Marc Subirana on Vimeo.

Read more »

Una entrada en parte off-topic sobre la película Her, de Spike Jonze. Recomiendo la película, además de para pasar un buen rato, también para reflexionar en base a una serie de hipótesis que pueden convertirse en realidad en un futuro más o menos lejano.

Me ha recordado en muchos momentos a las reflexiones de Alone Together (esta es la parte On topic) sobre la cada vez mayor dependencia de los humanos respecto de los sistemas (cada vez más) inteligentes ya sean vía móvil, ordenadores o todo a la vez. Así empezaba el libro Alone Together:

La tecnología se propone a sí misma como el arquitecto de nuestras intimidades.

Y lo dejo aquí, porque seguro que se me acaba escapando algún spoiler ;-).

GraspJS es una utilidad que se posiciona como una mejora respecto al tándem grep/sed para la refactorización de código. Su propuesta de valor es sencilla: no ejecuta un análisis textual, sino estructural del código.

Análisis textual del código javascript y sus limitaciones

La primera solución que nos surge es la de grep/sed: Esto es especialmente útil si ya hay un mínimo criterio en la estructura de código, o bien estamos buscando elementos que por sus características textuales ya son lo suficientemente específicos. El problema es que eso cubre un número determinado de casos, y además tiene limitaciones a la hora de aislarse del ruido que pueda tener el código: desde uso ambiguos de la nomenclatura, hasta código comentado y similares. En otras palabras, esta aproximación no se aprovecha de la sintaxis del código, lo que abriría la opción de la búsqueda estructural.

Búsqueda en Javascript por sintaxis y la refactorización

• Búsqueda con selectores del estilo CSS con el motor squery.
• Búsqueda por ejemplos y wildcards con el motor equery.
• Remplazar las coincidencias con la utilidad de remplazo, que incorpora filtros y opciones para modificar las coincidencias más allá de un remplazo literal.

• No intentes crear un nuevo Red Hat, en Techcrunch.
• Visualizar la probabilidad condicional.
• Tutorial sobre WebRTC, una tecnología HTML5 que creo será familiar en un futuro próximo.
• Por si no te has enterado, Twitter da acceso a sus datos para investigadores, con las Twitter Data Grants.
• WebODF, javascript para mostrar y editar documentos ODF online.
• StrataJS, un streaming HTTP server para nodeJS.
• Data Driven Journalism, el qué el cómo y el dinero para hacerlo.

</ul>
Y un video sobre el uso de streams en NodeJS, acompañado de un artículo en el blog del autor explicando el uso de los streams en Node:</p>

Full Streams Ahead from JSLA on Vimeo.

Read more »

En el desarrollo y evolución de aplicaciones es muy habitual que se mezclen funcionalidades de las últimas versiones del lenguaje con otras más antiguas o incluso arcaicas. Es entonces cuando llega el momento en el que alguien (el cliente, el administrador de sistemas o la oferta de hosting) que nos plantea la duda: ¿Cuál es la versión mínima de PHP que necesita mi aplicación?

En ese momento puedes empezar a repasar todo tu código y experimentar un sudor frío... o quizá puedes pensar que alguien ha pasado por esto y comprobar si ha hecho algo para resolverlo.

PHP Compatibility

Para llevar a cabo la prueba, puedes empezar por clonar el repositorio de PHP_CodeSniffer:

git clone https://github.com/squizlabs/PHP_CodeSniffer.git

cd PHP_Codesniffer/CodeSniffer/Standards

git clone https://github.com/wimg/PHPCompatibility.git

cd ../../scripts

./phpcs -i

The installed coding standards are PSR2, PHPCompatibility, Zend, Squiz, PEAR, PHPCS, MySource and PSR1

./phpcs --standard=PHPCompatibility --runtime-set testVersion 5.2 /ruta/a/codigo/php/que/quiero/analizar

Sólo me queda añadir dos comentarios antes de acabar:

• Como en otros procesos relacionados con CodeSniffer, el análisis de compatibilidad se toma su tiempo. Por eso vale la pena que este tipo de procesos se realicen en background de forma automática (mediante phing o similares), para por ejemplo tener un control a cada commit/push realizado.
• Todo el proceso anterior se puede simplificar en el momento en que CodeSniffer acepte el argumento --runtime-set, que actualmente no acepta. Si estás leyendo este artículo, no estaría de más comprovar que la versión de PEAR incorpora ya este parámetro.

A finales del pasado mes de Noviembre Paypal publicaba un extenso post en su blog de Paypal Engineering, explicando su migración de Java a Javascript y NodeJS (y poco más tarde también Groupon se sumó a la idea), con cierto nivel de detalle sobre la tecnología utilizada, el proceso hasta su paso a producción, las diferencias en la productividad para el desarrollo, y... ahí está el tema clave: el rendimiento.

A nadie se le escapa que el tiempo de respuesta en las aplicaciones web es clave en el presente, ya sea por los rankings en buscadores, o por los propios usuarios. Así que abogar por el rendimiento es cada vez más sinónimo de abogar por los beneficios, algo que alinea rápidamente intereses en una empresa. Pero ¿realmente es así? ¿NodeJS aporta tanta mejora?

Escalabilidad y arquitecturas de NodeJS y Java

This means that Java is bottlenecked less on serialization, and Node.js is bottlenecked less on coherency delays. This is exactly what one should expect from their architectures (multi-threaded versus single-threaded with event loop)

The takeaway, as I'd state it: PayPal was able to get better results from Node.js than Java. I am not doubting either Java's or Node's performance capabilities, or arguing that one system is/ought to be higher performance than another. I'm just saying PayPal's blog post is glossing over a subject with a lot of unanswered questions, and therefore their assertions about Node.js being better are unqualified and unsupported in my opinion.

Todas ellas son lecturas interesantes, y siempre entendiendo que además de un debate sobre arquitecturas y paradigmas, hay también una pugna por atraer la atención y el dinero de los presupuestos de IT. Disfruten de la lectura, creo que valen la pena.