¿Por qué me llegan por correo tantas actualizaciones en Políticas de Privacidad?

¿Has notado que todos los servicios, apps o suscripciones a las que te has registrado alguna, vez te están enviando correos referentes a actualizaciones de Políticas de Privacidad? Esto se debe al Reglamento General de Protección de Datos (o GDPR por sus siglas en inglés), un nuevo y amplio reglamento europeo que entra en vigor el día viernes 25 de mayo del 2018, es decir, ¡mañana mismo!

En Webtraining nos preocupamos por mantenerte actualizado, así que aquí te dejo 12 cosas que debes saber acerca del GDPR.

1. La Unión Europea (UE) tiene el poder de castigar.

El GDPR le brinda a la UE la facultad de responsabilizar a las empresas y organizaciones por la manera en que obtienen y tratan los datos personales de sus usuarios, entre ellos tú. Todas las empresas y organizaciones han tenido dos años para prepararse. La promulgación del GDPR no fue un movimiento espontáneo por parte de las instituciones europeas. El GDPR se hizo oficial en mayo del 2016, otorgando suficiente tiempo para prepararse a todos los que recolectan información de sus clientes.

2. Aunque todo esto fue orquestrado por en Europa, el GDPR impacta a todo el mundo.

Si vives fuera de Europa, probablemente te estarás preguntando qué tiene que ver una nueva ley europea contigo. Gracias a algo llamado Alcance Territorial (tercer artículo del GDPR), cualquier organización que trate con datos de residentes europeos deben acatar el GDPR para dichos individuos, lo cual impacta a organizaciones globales como Apple y Facebook (¡Ha!). A pesar de no ser estrictamente requerido, algunas organizaciones están brindando el mismo control y protección a los que viven fuera de Europa.

3. Está saturando tu buzón de entrada

Todos hemos sido bombardeados con emails sobre políticas de privacidad actualizados y con términos y condiciones de uso del servicio. Esto NO es (mayormente) una repercusión del escándalo “Cambridge Analytica-Facebook”,  sino porque las organizaciones están ajustando sus prácticas y políticas para acatar el GDRP. Considera que todos estos emails son un recordatorio para que te desconectes de servicios que ya no usas y hasta olvidaste. No tiene caso que sigan teniendo datos tuyos, ¿o sí?

4. La privacidad de información es por diseño y por defecto.

Aclaro, “por defecto” me refiero no a errónea sino a “dado por hecho”.

Las organizaciones que recolecten o usen datos personales deberán considerar la privacidad a lo largo de todo el ciclo de vida de sus productos y servicios.

Esto significa que desde el día en que los equipos inician a diseñar un producto, servicio o funcionalidad, la privacidad debe permanecer en sus mentes en todo momento.

Esto también significa que los ajustes iniciales de una app o servicio estarán configurados por defecto para beneficiar la privacidad, y será elección del usuario ajustar o remover dicha privacidad.

5. Las políticas y los términos y condiciones deben ser fáciles de entender.

El GDPR exige que las políticas sean escritas en lenguaje simple para que el usuario pueda entender claramente a qué está dando su consentimiento. Ahora es un buen momento para revisar las políticas de privacidad y términos y condiciones de los servicios que usas y actualizar tus ajustes.

Puedes comenzar con estas (algunos enlaces son a las políticas en inglés, pero puedes navegar un poco y buscar la versión en español):

6. Tienes el derecho de llevarte tus información hacia otro servicio.

Este principio se llama “Portabilidad de datos” y significa que tú:

  1. Tienes visibilidad sobre la información que una organización tiene recolectada sobre tí.
  2. Puedes mover esa información a un proveedor de servicios diferente (como un competidor) sin perder el historial de datos que has producido.
  3. Estás más cerca de ser el guardián y beneficiario de tu propia información.

¿Cómo sucederá todo esto? Aún no hay certeza, pero ya lo veremos.

7. Tienes el derecho de ser olvidado.

Adicionalmente al derecho de poseer tu información, también tienes el derecho de solicitar su eliminación.

8. Las violaciones de datos serán reportadas a los reguladores mucho más rápido.

El GDPR tiene una “Regla de las 72 horas” que significa que los manejadores de tu información deben reportar una violación de datos a su autoridad supervisora en un lapso menor a tres días después de haberse percatado de ella.

9. Violaciones serán caras.

Realmente caras. En el pasado, las multas por un manejo y recolección irresponsable de datos eran tan bajas que, quizás, era más rentable para las grandes organizaciones pagarlas y seguir con lo suyo.

Sin embargo, ahora las organizaciones que violen el GDPR pueden ser multados por hasta el 4% de su facturación global anual o 20 millones de euros (lo que resulte mayor).

Aún no está claro cuál sería una violación significante, pero podemos tomar a Alphabet (la compañía que posee a Google) para un ejemplo hipotético de una violación al GDPR. Alphabet se hizo de 110 billones de dólares en 2017, así que una multa a una organización así vendría siendo de 4.4 billones de dólares.

10. Lo que es bueno para el usuario también es bueno para los negocios.

Almacenar información personal siempre tendrá riesgos. Mejores prácticas de seguridad disminuye los riesgos asociados con la recolección y procesamiento de datos personales para ambos, usuarios y organizaciones.

Esto no es algo insignificante: en 2015 las violaciones de datos costaron en promedio 3.79 millones de dólares por compañía afectada, sin mencionar la confianza de los clientes perdida y repercusiones en relaciones públicas.

11. Menos información, más confianza.

Es triste pero cierto que algunas organizaciones ni siquiera saben qué información tienen o dónde está almacenada, y el GDPR exhorta a las organizaciones a pensar dos veces sobre la cantidad de información que recolectan.Además, estas necesitan justificar el propósito de dicha recolección.

El GDPR representa una oportunidad para más negocios de ser líderes en términos de recolección de datos al inclinarse por recolectar sólo lo que es necesario para proveer su producto o servicio, en lugar de acaparar datos de todo tipo.

12. El GDPR es un piso, no un techo.

El GDPR provee un conjunto inicial de reglas, las cuales sirven de base para fomentar enfoques más éticos en la recolección y procesamiento de datos. Esto es un paso en la dirección correcta, pero el lado oscuro aparecerá en los detalles para la mayoría de las organizaciones.

Nuevos controles de privacidad, incluso si llegan a cumplir técnicamente con el GDPR, no ayudarán si resultan difíciles de usar y si las organizaciones no están comprometidas con los principios de los cuales nació este reglamento. Aún así, nos gusta que esto fomente una cultura de privacidad responsable, empoderando al usuario con control y elección sobre su experiencia online.

Así que ya sabes, a revisar en dónde estamos metidos y qué andan haciendo con nuestra información.

Espero que este post sea de utilidad, incluso si no eres del mundo de la computación. Déjame un comentario o un saludo. Nos leemos en la próxima.

¿Y en Webtraining dónde puedo ver las políticas de privacidad?

Puedes darle un vistazo a nuestra política actualizada en el siguiente enlace: Políticas de Privacidad de Webtraining.

– Enrique D.

Truco de Vue.js #2: Quiero usar Vue.js en un proyecto grande y viejo.

Tenemos el siguiente escenario: Eres el nuevo miembro de un equipo de desarrollo que lleva unos años perfeccionando una aplicación Web. Dicha app está hecha con tecnologías como .NET y usa jQuery a todo lo que da. Tu primera tarea es “arreglar” el sistema de comentarios pero al analizarlo por un rato descubres cosas como esta:

$('#comment-' + commentId2)
  .toggleClass('comment-state-02')
  .css('display', displayFlag);

Intentas sacarle explicación a cada variable, clase y ID para medio comprender qué están tratando de lograr. Te ves en 2 meses arreglando el parche que arregló el parche que arregló el parche, te deprimes y luego te armas de valor y propones rehacer el módulo.

Y para tu sorpresa… ¡TE LO ACEPTAN! Es tu momento de meterle tecnología de punta que no solo sea novedosa sino eficiente. ¿Pero qué puedo usar que sea eficiente y al mismo tiempo fácil de integrar? OJO: Fácil de integrar es que al meterlo al proyecto no te rompa todo y tome días ajustarlo. Mi sugerencia es obviamente Vue.js.

¿No te convence? Considera que añadir solamente 32kb al proyecto acelerará tu productividad y mantendrá un buen nivel de escalabilidad si creas una abstracción de componentes decente. ¿Qué piensas ahora?

¡Acepto! ¿Cómo empiezo?

Importar el script de Vue.js, sea por CDN o guardando el archivo en el proyecto, es sumamente fácil. Considero que es algo que podemos saltarnos en este post, pero te dejo el link de la documentación oficial aquí.

Ahora, siendo un curioso de la web que conoce Vue.js, sabrás que trabajar con componentes es lo ideal. Y dividir la lógica de cada uno en un archivo con extensión .vue es la cereza del pastel. Sin embargo, el proyecto al que te enfrentas no usa Webpack y, honestamente, integrar Webpack en un proyecto que no se pensó desde un principio con él es una lata. Y tú, siendo el nuevo que ya convenció al Project Manager de usar Vue.js, debes entregar resultados ASAP.

Dale, no pasa nada. Afortunadamente Vue.js tiene más de una manera para declarar un entorno de componentes. En un escenario como este yo te sugiero estas dos formas:

  1. Declaración con strings inline.
  2. Declaración con X-Templates.

Preparación

Checa el repositorio que preparé para ti: https://github.com/enriqued93/truco-vue-2. La rama master contiene el ejemplo para la declaración con strings inline, y la rama x-templates para el segundo ejemplo.

En este repositorio están los pasos necesarios para integrar Vue.js en cualquier proyecto de manera segura. Hay comentarios suficientes dentro del código para comprender qué está sucediendo, así que te recomiendo fuertemente que le des un vistazo.

En el archivo comments.module.js está la definición e inicialización del widget de comentarios y sus componentes. Mi enfoque se basa en definir funciones descriptoras cuyo único fin es devolver objetos con la estructura especificada para un componente de Vue.js.

¿Por qué usar este tipo de funciones y no escribir el objeto inline? En mi humilde opinión, englobar dichos objetos de esta manera ayuda a tener un código más limpio y estructurado. Si estamos trabajando con una herramienta que promueve el uso de componentes, debemos estar consientes de que tener una estructura mantenible y reusable es primordial. Otra ventaja es que si tienes la necesidad de utilizar un componente en otro lado, puedes copiar y llevarte la función completa y no se romperá absolutamente nada ya que la función descriptora debe ser ajena al contexto donde se define.

Declaración con strings inline

Quizá sea la manera más simple de definir un componente en Vue.js. Primero te dejo algunas ventajas y desventajas de este método.

Ventajas

  • Como desarrollador, es imposible perder referencia visual entre lógica y template del componente, pues se encuentran en el mismo sitio.
  • Al mover la declaración de lugar (posiblemente a otro archivo) el componente no se romperá ya que está todo en el mismo objeto.
  • Los problemas que surgen por ejecutar JavaScript antes de tener listo el DOM no te afectarán por declarar este componente porque el template que necesita viene integrado.

Desventajas

  • Como el template se está definiendo como un string, te será muy dificil escribir un componente muy grande.
  • La mayoría de los IDEs (o tal vez todos) tratarán el template como un vil y plano string, omitiendo cualquier tipo de Syntax Highlighting.
  • Para escribir un string multilinea puedes usar las Templates Literals de EcmaScript2015, pero dado que existen navegadores que no implementan esta especificación es un poco arriesgado usarla (a menos que tus requerimientos no incluyan este tipo de navegadores).

Enfoque

Si has usado el framework sabrás que debemos crear un objeto que funja como “descriptor” de nuestro componente y que tiene una estructura como te muestro acontinuación:

{
  template: ...,
  data: ...,
  methods: ...,
  computed: ...
}

Existen ciertas consideraciones que debemos tener en cuenta respecto a este objeto, pero por ahora solo me estoy enfocando en la propiedad template por el alcance de este post.

En el repositorio que te compartí encontrarás que defino el template de los componentes de manera inline, es decir, el HTML con directivas de Vue.js es un string asignado a la propiedad template del objeto descriptor. Este string lo defino usando sintásis diferentes para que de acuerdo a tus gustos o requerimientos uses la que más te acomode. Recuerda que las Template Literals no son soportadas por todos los navegadores (checa la compatibilidad actualizada aquí).

function getCommentListDescriptor() {
    return {
        data: function () {
            return {}
        },
        props: ['comments'],
        components: {
            'comment': getCommentDescriptor()
        },
        template: `
            <div class="wt-comment-list">
                <comment v-for="c of comments" :key="c.id" :model="c"></comment>
            </div>
        `
    }
}

function getCommentEditorDescriptor() {
    return {
        data: function () {
            return {}
        },
        template: '<div class="wt-comment-editor"><textarea class="wt-comment-editor__input" placeholder="Escribe algo..."></textarea><button class="wt-comment-editor__button" type="button">Enviar</button></div>'
    }
}

Declaración con X-Templates

Bueno, pero entonces ¿debo tener forzosamente mis archivos JavaScript con todos esos strings que tienen una sintáxis más parecida a HTML? La respuesta es NO.

Ventajas

  • Ciertos IDEs pueden ayudarte con Syntax Highlighting ya que el template se encuentra en un archivo HTML.
  • Resuelve el impedimento de los templates multilinea.
  • Si creamos un componente con un template muy extenso, el código se aligera visualmente al quitarlo del descriptor.

Desventajas

  • Si no tenemos cuidado y olvidamos incluir los X-Templates en el contexto, el componente no encontrará su respectivo template y explotará.
  • Si el componente se inicializa antes de tener listo su respectivo X-Template dentro del DOM, también explotará.

Enfoque

Hagámosle unos cambios al ejemplo anterior. En lugar de tener los templates en nuestro JavaScript, lo moveremos al HTML de la siguiente manera.

<script type="text/x-template" id="vue-comment-template">
    <div class="wt-comment">
        <p class="wt-comment__subject">{{model.subject}}</p>
        <p class="wt-comment__body">{{model.body}}</p>
    </div>
</script>

El punto clave es englobar el template en un <script> con la propiedad type=”text/x-template”. El ID del script reemplazará al template inline del ejercicio pasado.

function getCommentDescriptor() {
    return {
        data: function () {
            return {}
        },
        props: ['model'],
        template: '#vue-comment-template'
    }
}

No olvides que para que la inicialización de un componente se lleve a cabo adecuadamente, es necesario que el X-Template en cuestión exista en el DOM en dicho momento. Puedes usar $(document).ready() o la estrategia que prefieras para asegurar que el JavaScript se corra cuando el DOM se haya cargado (en el repositorio encontrarás una estrategia usando solamente JavaScript por si has superado jQuery).

Conclusión

En mi humilde opinión, establecer una buena abstracción y arquitectura de componentes en tu aplicación es primordial. Si lo haces no importará si tu app debe seguir creciendo pues soportará nuevas funcionalidades (escalabilidad); arreglar bugs dejará de ser tarea de andar descifrando código ajeno (mantenibilidad).

Si usas Vue.js o estás considerando en usarlo, aprovecha todas las bondades que ofrece y sácale todo el jugo. Recuerda que puedes tener el mejor framework del mundo pero si no lo usas como se debe no hará ninguna diferencia.

Ojalá esto te sea útil y no olvides dejarme tus comentarios diciendo qué cosas te interesarían aprender, cómo te pareció este post o qué opinas de mi escritura. Te mando un saludo, nos leemos en el próximo post.

– Enrique D.

 

 

Truco de Vue.js #1: Esconder tus directivas de Vue antes de que esté listo

¿Tus usuarios tienen conexión lenta? ¿Vue.js no se definió correctamente? ¿Detestas el DOM pre-render?

Así se vería Google antes de cargar Vue.js (si lo usara…)

Pues te tengo la solución a tus problemas: ¡v-cloak!

En la lista de directivas de Vue.js encontramos v-cloak, pero puedo asegurar que muy pocas personas le prestan atención.

Lo único que hace esta directiva es desaparecer. Sí, desaparecer y ya. Cuando Vue.js es invocado se encarga, entre otras cosas, de quitar todos los v-cloak que haya dentro del elemento HTML que inicialices.

Ten en cuenta que v-cloak no se pone por defecto en todos lados, tú debes ponerla y sólo es válido en elementos dentro del que inicializas, no aplica sobre él mismo.

<div id="super-app">
    <div class="results" v-cloak>
        <p>About {{numResults}} results. ({{responseTime}} seconds)</p>
    </div>
    <p class="tip">
        Tip: <span>Search for <em v-cloak>{{language}}</em> results only</span>. You can specify your search language in <a href="">Preferences</a>
    </p>
</div>

<script>
    let superVueApp = new Vue({
        el: '#super-app',
        .
        .
        .
    })
</script>

Si esto lo combinas con una regla de CSS puedes ocultar todos los elementos que no estén listos.

[v-cloak] {
  display: none;
}

 

¡Voilá! Con esta solución super-simple te olvidas de tener HTML que no esté listo sin pegarle al performance de tu app.

Si tienes dudas sobre Vue.js o cosas raras que te gustaría hacer y no sabes cómo, déjame un comentario para tenerlo en cuenta para los próximos Trucos de Vue.

– Enrique D.

Mi primera travesía: Integrando AdSense desde cero (parte 1)

¡Qué tal, Webtrainees! Soy Enrique y esta es la primera vez que escribo en el blog de Webtraining. De hecho, NUNCA antes había escrito una entrada en un blog. Siempre ando leyendo cosas que todos escriben pero nunca había escrito algo propio, no tengo idea de lo que estoy haciendo. Espero Alex Arriaga no se moleste. Haré todo lo posible por aterrizar ideas y volverme un moderadamente buen escritor-o-algo. Ojalá pueda hacerlo un hábito y periódicamente compartir mis travesías.

¿Alguna vez te has preguntado por qué hay anuncios en tantos sitios de nuestra querida Internet? Quizá eres un conocedor y conoces la respuesta pero no tienes idea de cómo implementarlo en tu sitio. También es posible que hayas sentido que esos anuncios te espían porque recién curioseaste sobre esos audífonos inalámbricos en Amazon y ya estás encontrándotelos hasta en la sopa.

Si te identificas con alguna de las premisas anteriores te quiero decir ¡GRACIAS! porque así me haces sentir que no soy el único que quiere indagar sobre AdSense.

Logo de Google AdSense
© Google AdSense

* DISCLAIMER: Enrique Díaz (yo mero) no es un experto en uso de AdSense sino todo lo contrario *

Llevo unas semanas trabajando en un proyecto con Alex durante mis escasos ratos libres. El destino nos llevó a decidirnos por utilizar Nuxt.js (Universal Vue.js o Vue.js Server-side) y conocer más sobre la monetización por medio de anuncios (lo sé, a veces son fastidiosos pero así es esto). Nunca había leído a fondo nada de AdSense, pero desde el principio supe que esa sería una opción.

Citando al sitio de esta tecnología perteneciente al gigante Google:

AdSense es una manera gratis y simple de hacer dinero en Internet usando anuncios en tu sitio web. En 2015, repartimos cerca de USD$ 10B a nuestros editores. Ese es el poder de AdSense.

Related image¡Suena fantástico, yo quiero una rebanada de ese pastél! ¿Qué debo hacer? ¡Y SABER! Veamos…

Beneficios

  • Anuncios revisados para mantener una alta calidad y de contenido relevante.
  • Anuncios ideales dependiendo el tipo de audiencia.
  • Soportados en medios móviles (smartphones, tablets, etc.).
  • Los que pagan más aparecen más y en mejores lugares.
  • Puedes bloquear ciertos anuncios a tu criterio.
  • Personalizables para adecuarse a tu sitio.
  • Provee herramientas de reportes.

Según AdSense, solo es necesario hacer lo siguiente para generar dinero:

  1. Seleccionar el tipo de anuncio adecuado para tu sitio. Ofrecen ciertos recursos para elegir adecuadamente y aprovechar al máximo AdSense.
  2. Elegir dónde queremos ubicar dichos anuncios.
  3. Ver los anuncios en acción. Esto es importante porque es posible que en tu sitio aparezcan anuncios de tu competencia y, siendo honestos, ¿a quién le apetece promover a la competencia con tus clientes? Debemos estar atentos y mover nuestra configuración para prevenir anucios provenientes de esos oscuros y tenebrosos sitios.
  4. Esperar los cheques. ¡Cool! Pero no olvides que el dinero sigue siendo dinero y hay condiciones. Para poder reclamar ese regordete cheque debes llegar a cierto límite de pago en el mes, el cual depende de tu moneda predeterminada. En mi caso (pesos mexicanos) debo juntar al menos MXN$1,200 para retirarlo. Si no llegas al mínimo, tu acumulado se pasará al siguiente mes y así hasta que en algún mes alcances el límite de pago. ¿Un ejemplo? Supongamos que este mes recaudé MXN$900 y no puedo retirar un centavo. El siguiente mes junto MXN$200 más (van MXN$1,100) y sigo sin retirar nada. El tercer mes me fue excelente, aportando MXN$1,000 al acumulado. En este tercer mes tendría MXN$2,100, permitiéndome y obligándome a retirar dicha cantidad.

Bien, considero que es suficiente información y contexto para comenzar a añadir unos anuncios a este sitio.

Paso uno: Crear una cuenta de AdSense.

Para esto necesito una cuenta de Gmail (listo) y ser el propietario del sitio y contenido donde quiero poner anuncios (listo). Visitamos la página https://www.google.com/adsense/start y buscamos donde diga Sign Up o algo similar. Iniciamos sesión con la cuenta de Gmail que deseemos asociar. Introducimos el dominio de nuestro sitio (sin protocolo, sin path, sin queryParams), por ejemplo enrique-diaz.com, completamos el pequeño formulario y aceptamos términos y condiciones (ten en cuenta que solo un número limitado de cuentas pueden asociarse al mismo sitio, así que no andes poniéndolo en todas tus cuentas).

Ahora nos aparece un formulario más extenso y formal, pidiéndonos información para los pagos. Después, debemos copiar un pequeño bloque de código en nuestro <HEAD> para finalmente… esperar a que Google valide que todo está en orden. Según no debe tardar más de 3 días pero es posible que sí. Supuestamente seré notificado por email cuando todo esté resuelto.

Paso dos: …

Ahora me queda esperar, no puedo hacer mucho más y la verdad no quiero extenderme en esta entrada con cosas irrelevantes como mi vida personal o qué le daré a Nala de comer hoy. ¡Ah! Nala es mi cachorra que adopté/rescaté de un parque donde fue abandonada. Mientras tanto, cerraré esta entrada y espero ser notificado pronto para seguir viendo cómo es esto de AdSense. Déjenme sus comentarios, opiniones, quejas, reflexiones o cualquier cosa. Háganme saber si alguien lee esto.

Nos vemos Webtrainees, nos leemos en la próxima travesía.

~ Enrique