Desde el 20 de abril de este año (2016) con la publicación de la versión 50 de Chrome, éste deja de soportar la API de Geolocalización de HTML5 en páginas que se sirvan desde una conexión no segura. Es decir, que la función de geolocalizar la posición del usuario ha dejado de funcionar en todas las páginas que no usan HTTPS. La justificación para este cambio está, según la página de Google Developers, en que al ser la localización un dato personal sensible, requerir una conexión segura es un requisito para poder proteger la privacidad del usuario/a. De momento Chrome está aplicando esta política, pero desde Google recomiendan al resto de navegadores que la apliquen también, en un esfuerzo por defender la privacidad de los datos.

La Geolocalización no es la única afectada por esta política. Varias nuevas características de los navegadores van a requerir conexiones seguras.

Fuente

Google Developers

En este post, que recomiendo leer a quienes aun no han dado el salto al uso de un sistema de control de versiones, Peter Ellis hace una clasificación de los/as analistas (y sus equipos) en cuatro categorías:

  1. Quienes realizan la mayoría de su trabajo con Excel (o con Calc, supongo), principalmente gestión de datos y presentación y visualización de resultados. Herramientas especializadas como SAS, Stata, Matlab, R o E-views se usan sólo para tareas de modelado estadístico/econométrico que no se pueden realizar con Excel.
  2. Quienes realizan la mayoría de su trabajo, incluyendo gestión de datos y visualización, con algún lenguaje de programación que suele ser R, SAS o Python, además de SQL, pero que limitan el control de versiones a copias de los mismos archivos con distintos nombres, siguiendo una convención de nombres basados en la fecha.
  3. Como 2, pero con software de control de versiones, una guía de estilo para el código y con un proceso de revisión por pares.
  4. Como 3, pero con más buenas prácticas tomadas del mundo del desarrollo de software, como el unit testing, código modular, integración contínua, etc.

En su libro Executive Data Science, Brian Caffo, Roger D. Peng y Jeffrey Leek dan la siguiente “regla del pulgar” sobre el grado de sistematización que es necesario darle a un conjunto de procedimientos o análisis en el contexto de un equipo de trabajo de ciencia de datos (data science):

  • Si vas a realizar algo una vez, escribe algo de código y documéntalo bien. Lo importante es que estés seguro de entender lo que hace el código, para lo cual hace falta escribir buen código y documentarlo. Para estar seguro de que podrás reproducirlo si alguna vez te toca volver a ello a tí o otra persona.
  • Si vas a hacerlo dos veces, escribe una función. Te permite abstraer una pequeña pieza de código y te obliga a definir una interfaz, con lo que tendrás bien definidas las entradas y salidas.
  • Si vas a hacer algo tres veces o más, deberías pensar en escribir un pequeño paquete que agrupe el conjunto de operaciones que vas a realizar en un análisis dado. También es importante escribir algo de documentación que permita a la gente entender qué se supone que hace y les permita aplicar el software a una situación diferente si es necesario.