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.

A la hora de que Jekyll construya el sitio con jekyll build o jekyll serve se pueden establecer distintos “entornos” lo que nos permitirá realizar diferentes acciones en función de que estemos en un entorno de desarrollo (si estamos todavía “trasteando”) o en uno de producción (cuando queremos el producto final que vamos a subir al servidor). Por defecto, Jekyll se ejecuta en un entorno de desarrollo, definido por la variable JEKYLL_ENV=development. A la hora de construir el sitio, se puede establecer otro valor, por ejemplo:

$ JEKYLL_ENV=production bundle exec jekyll build

Esto permite introducir código condicional que sólo se ejecutará en uno de los entornos. Ej:

 
  {% if jekyll.environment == "production" %}
    {% include disqus.html %}
  {% endif %}
 

Además de a través de la variable JEKYLL_ENV, se pueden establecer diferencias entre los dos entornos creando un archivo de configuración específico para uno de ellos. Estos archivos se pueden concatenar, de forma que el último en ser llamado sobreescribe los valores que coinciden con el primero. Por ejemplo, si en el archivo _config.yml tenemos entre otros los siguientes valores:

url: example.com
sass:
  style: :compressed

Se podría tener además un _config_dev.yml al que se llamase en tiempo de ejecución con bundle exec jekyll serve --config _config.yml,_config.dev.yml que contuviera los siguientes valores:

url: localhost:4000
sass:
  style: :expanded

Por último, resulta útil crear un par de alias para agilizar el proceso:

alias jekyll_prod='JEKYLL_ENV=production bundle exec jekyll build'
alias jekyll_des='bundle exec jekyll serve --config _config.yml,_config.dev.yml'

Fuentes:

Los microdatos (Microdata) sirven para que robots como Google entiendan mejor el contenido de una página, indicándoles por ejemplo qué parte de la web son los datos de contacto, cuál es un producto o una oferta o dónde se hace referencia a una persona.

Microdata está incluido dentro de las especificaciones de HTML5 y proporciona una forma estándar de añadir a las páginas web un marcado semántico orientado a los ordenadores.

Aunque la forma de definir estos microdatos es estándar, los vocabularios que se pueden usar no lo son, y hay distintas entidades que proporcionan un conjunto de propiedades que se pueden utilizar para definir las partes de nuestra web. Uno de los vocabularios más usados es el definido por schema.org.

¿Cómo se usan?

Microdata nos proporciona 3 atributos1 que se pueden añadir a cualquier etiqueta HTML5 (y sólo a las etiquetas HTML: no sirve de nada añadirlas, por ejemplo, a una etiqueta de SVG):

  • Itemscope. Indica que el elemento es de tipo microdata.
  • Itemtype. Indica el vocabulario que se va a usar. Su valor es la URL de un vocabulario, que describe de qué clase de elemento se trata, por ejemplo, una organización.
  • Itemprop. Este atributo, siempre debe tener un valor, e indica la información específica de cada elemento, por ejemplo nombre, logo, etc.

Los microdatos consisten en grupos de parejas nombre-valor. Estos grupos se llaman items y se definen con el atributo itemscope y cada pareja nombre-valor se llama propiedad y se define con el atributo itemprop.

Ejemplo

Un ejemplo, mejorando la información de la típica página de contacto:

Código:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<div itemscope itemtype="http:/schema.org/Organization">
  <img itemprop="logo" src="images/logo_terrativa.jpg" alt="logo" />
  <h2 itemprop="name">Terrativa S. Coop. Mad.</h2>
Datos de contacto:
  <div itemprop="address" itemscope itemtype="http://schema.org/PostalAddress">
    <span itemprop="streetAddress">Pza. Mayor, 4. Despacho 11</span>,
    <span itemprop="addressLocality">Cerceda</span>,
  <div itemprop="address" itemscope itemtype="http://schema.org/PostalAddress">
    <span itemprop="latitude"></span>
    <span itemprop="longitude"></span>
  </span>
  Tel: <span itemprop="telephone">636 041 753</span>
  <div>
    <a href="http://terrativa.net" itemprop="url"> http://terrativa.net</a>
  </div>
</div>

Todo el div se define como un item de microdata usando el atributo itemscope y con itemtype se establece el tipo de item que va a ser (Organización, usando el vocabulario de schema.org). Dentro de la organización nos encontramos las distintas propiedades, definidas con itemprop. A su vez una propiedad se puede definir como un item y contener otras propiedades, como sucede con el caso de address.

  • name: Terrativa S. Coop. Mad.
  • adress:
    • street-address: Pza. Mayor, 4. Despacho 11
    • locality: Cerceda
    • region: Madrid
    • postal-code: 28412
  • geo:
    • latitude:
    • longitude:
  • telephone: 636 041 753
  • url: http://terrativa.net

Resultado:

logo

Terrativa S. Coop. Mad.

Datos de contacto:
Pza. Mayor, 4. Despacho 11, Cerceda, Madrid 28412
Tel: 636 041 753

  1. En realidad proporciona 5, pero lo más común es usar sólo los 3 que se explican aquí.