Aprendizaje no Supervisado y Detección de Anomalías: Reglas de Asociación Avanzadas

03/04/2018
Artículo original

Este articulo forma parte de una serie de artículos sobre clustering, detección de anomalías y reglas de asociación. Originalmente forman parte de un trabajo para el Máster Universitario Oficial en Ciencia de Datos e Ingeniería de Computadores de la Universidad de Granada en la asignatura Aprendizaje no supervisado y detección de anomalías. El resto de artículos son:

Uno de los problemas de las reglas de asociación es la interpretabilidad, estos pueden venir derivados de los datos en sí, de los usuarios o de las propias medidas de evaluación.

Los problemas derivados de los datos residen en que hay varias formas de interpretar que si A \(\rightarrow\) B en función de las medidas de calidad usadas. Al ser patrones en los datos, la calidad de la regla dependerá de igual modo de la calidad de los datos. Algunos problemas derivados de los datos son:

  • falta de variabilidad, items muy frecuentes no aportan nada (Todos los clientes compran papel) o al contrario, items poco frecuentes tampoco aportan nada.
  • La representabilidad de los datos, es decir, que no haya suficientes datos.
  • Sesgos muestrales, es necesario escoger los items de forma aleatoria, no sesgarlos seleccionado compras de un periodo determinado, como las compras de enero, por ejemplo.

Por otra parte, los problemas derivados del usuario pueden deberse a que no se dispone de un experto en el dominio del problema para interpretar y valorar las reglas. Aún cuando se dispone de un experto, pueden ocasionarse confusiones semánticas en las que se interpretan mal las reglas o los valores de confianza etc.

Los problemas derivados de las medidas, las reglas con soportes muy altos tienden a ser dudosas, ya que su valor tan elevado puede deberse a una falta de variabilidad en los datos. De igual modo, la confianza no siempre es fiable, una regla con una confianza del 84% puede parece buena, pero aún teniendo una regla con máxima confianza (conf = 1) puede que los items de A \(\rightarrow\) B sean independientes.

Para tratar de resolver estos problemas es necesario poder comparar la confianza de la regla con el soporte de su consecuente, dada A \(\rightarrow\) B, \(p(B|A)\) la confianza, \(p(B)\) el soporte de B, es necesario comprar ambas medidas, ya que \(p(B)\) es la probabilidad a priori, mientras que \(p(B|A)\) es solo la probabilidad de las reglas en las que aparece A. Si la $Conf(A \(\rightarrow\) B) = Sop(B)$ A y B son independientes y la regla no es representativa. Aunque la confianza por sí sola no vale para determinar si una regla es buena, sí que vale para descartar una regla mala.

Medidas de calidad

Existen dos grupos de medidas de Interés, objetivas y subjetivas. Las primeras tienen fundamento estadístico, mientras que las subjetivas solo tienen en cuenta los datos.

Entre las medidas objetivas se encuentran La Confianza Confirmada, establece hasta qué punto es útil A para predecir la presencia de B, la medida se da en un rango [-1, 1], donde 0 significa que son independientes, 1 dependencia total y -1 dependencia inversa (A predice ¬ B). Lift mide el nivel de interés, pero al ser simétrica mide asociaciones, no implicaciones, por lo cual no es buena para realizar comparaciones. Convicción detecta la independencia estadística entre items, al igual que lift no está acotada en su salida, por lo que no es muy fiable. El factor de certeza mide la incertidumbre del conocimiento, tiene su origen en los sitemas expertos, la ventaja frente a las dos medidas anteriores es que está acotada en rangos [-1,1], donde 0 significa independencia estadística. Existen más medidas, estas son solo unas pocas. Por lo general, el análisis de la regla depende de la medida a usar. Es necesario usar medidas en función de la semántica que se quiere medir.

Las medidas subjetivas miden el interés de las reglas, suele ser necesaria la presencia de un experto que valore el interés de las mismas. Una de ellas es la Utilidad, en ella hay que tener en cuenta:

  • Restricciones: ¿Qué condiciones o qué contexto es necesario para que el patrón se cumpla?
  • Tiempo de vida: ¿Durante cuánto tiempo será útil la información dada por el patrón?
  • Esfuerzo: ¿Qué debemos hacer para actuar según nos muestre el patrón?
  • Efectos laterales: ¿Se puede prever algún efecto lateral?
  • Impacto: Desde la obtención del patrón, ¿se han producido cambios en la actualidad?
  • Prontitud: ¿Cuándo podemos actuar y utilizar la información que nos brinda el patrón?

Las reglas inesperadas son otro tipo de medida subjetiva, son aquellas que contradicen las creencias del usuario, pueden ser interesantes o no.

Interpretaciones

Esta sección se corresponde con el marco formal de las reglas de asociación, es decir, la definición teórica de las reglas, de forma abstracta. Para ello hay que asociar dicha abstracción con los datos, crear una asociación entre datos y reglas, es esto lo que genera una interpretación.

La forma más común es tabular los datos en una estructura, por ejemplo (salario, alto) \(\rightarrow\) (estudios, superiores), pero no es la única manera de representación. Se puede, por ejemplo, considerar la ausencia de datos con negaciones (¬ A), esta representación es útil para el análisis de grupos de reglas.

Otra forma de representación son las reglas jerárquicas, en esta representación se consideran grupos de items a distintos niveles. Por ejemplo, si los items son artículos de compra, un análisis a nivel de artículos individuales puede no dar información alguna. Sin embargo, a un nivel más alto se puedan extraer conclusiones útiles, un nivel más alto consiste en agrupar los distintos artículos según algún criterio (por marcas, por tipo de producto, tipos de pan, tipos de leche etc). De esta forma se establece una jerarquía en la que un item está compuesto por los items básicos y todas las categorias a las que pertenece, por ejemplo: $$\text{(zumo, naranja, marca, comida)}$$ donde marca y comida son categorías del zumo. En la figura 1 muestra un ejemplo.

Ejemplo de reglas jerárquicas. *Créd. Apuntes de clase*
Ejemplo de reglas jerárquicas. *Créd. Apuntes de clase*

Las reglas secuenciales se usan cuando existe un orden prefijado en los items de las transacciones. Ejemplos de reglas de este tipo son, si A,B y C aparecen en este orden específico \(\rightarrow\) X. Este tipo de reglas son útiles para analizar textos, ya que se extraen reglas como {Minería}{de} \(\rightarrow\) {Datos}, es decir, si se encuentra la palabra Minería seguida de De es muy probable que la siguiente palabra sea datos.

Otro tipo de reglas son las Cuantitativas, usadas con datos estructurados, con dominios numéricos, el problema de estos dominios es su valor semántico y soporte bajo. Para ello, se comentó que es útil dividir el dominio en intervalos y generar pares (atributo, intervalo) en lugar de (atributo, valor), estos items deben estar ordenados. Los intervalos pueden se definidos por el experto para que puedan ser correctamente interpretados, o generarlos automáticamente.

Las dependencias aproximadas definen patrones en bases de datos relacionales, corresponden a dependencias funcionales con excepciones, es decir, si se sabe que V se encuentra en una fila se sabe que W está en la misma fila. En esta interpretación las reglas extraidas tienen la semántica de la dependencia funcional, es decir, los items son del tipo: Igualdad de variables en un par de tuplas.

La última interpretación son las dependencias graduales, representan asociaciones entre la variación (incrementos o decrementos) en los valores de los atributos, representando así correlaciones positivas o negativas. Se puede comparar con las dependencias aproximadas en cuanto a que esta en lugar de determinar si los valores son iguales, determina si son mayores o menores.

Reglas de Asociación difusas

Se usan para representar conceptos, por ejemplo, ¿cuando es una persona alta?, si consideramos 180cm como alto, ¿una persona que mida 179,99 ya no es alta?, este es el problema que tratan los conjuntos difusos, la pertenencia o no de un elemento a un conjunto viene dada por un grado de certeza. La figura 2 muestra un ejemplo en el que se define el rango en el que aumenta si una persona es alta o no, pero presenta el problema comentado anteriormente. Otra forma de representarlo es mediante una función discontinua, como muestra la figura 3, pero tampoco es ideal, lo mejor es una función gradual, como muestra la figura 4

Rango en la que una persona se considera como alta
Rango en la que una persona se considera como alta
Rango en la que una persona se considera como alta
Rango en la que una persona se considera como alta
Rango en la que una persona se considera como alta. Cuando la línea empieza a subir, aumenta el grado en el que se considera a una persona alta.
Rango en la que una persona se considera como alta. Cuando la línea empieza a subir, aumenta el grado en el que se considera a una persona alta.

Las reglas difusas aparecen solo cuando se consideran conjuntos difusos para definir algún concepto con items, transacciones etc, son conjuntos continuos. En este tipo de reglas el soporte depende mucho de dónde se establecen los cortes que definen los intervalos. Semánticamente los intervalos no corresponden con el concepto (30 años es joven, pero 31 no). Para dar solución a este problema se usan conjuntos difusos con funciones de pertenencia, como muestra la figura 5

Particiones difusas con función de pertenencia. Cabe destacar que pueden existir solapamientos (Región roja)
Particiones difusas con función de pertenencia. Cabe destacar que pueden existir solapamientos (Región roja)

Evaluación de reglas por grupos

El análisis de las reglas de asociación suele realizarse de forma individual, estudiando su novedad y potencial utilidad en base a los itemsets que la componen, las medidas objetivas y subjetivas realizadas sobre ellas, y el conocimiento previo del experto. Sin embargo, el análisis de conjuntos de reglas definidos según ciertos criterios puede proporcionar más información, con ciertas ventajas. Por ejemplo, ¿qué ocurre si aparecen ambas reglas A \(\rightarrow\) C y A \(\rightarrow\) ¬ C? o A \(\rightarrow\) C y ¬ C \(\rightarrow\) ¬ A (contra recíproca), la última es lógicamente equivalente. Sin embargo, la logica formal y el conocimento de datos no son lo mismo, al buscar reglas en un conjunto de datos se puede deducir A \(\rightarrow\) B, pero no se sabe nada sobre ¬ B \(\rightarrow\) A. El motivo es que ¬ B \(\rightarrow\) A no aparece en las transacciones, es decir, las transacciones de A \(\rightarrow\) B son distintas a ¬ B \(\rightarrow\) ¬ A, aunque sean lógicamente equivalentes, por ello es necesario mirarlas por separado. En el caso de que ambas aparezcan se proporciona más soporte empírico de que el patrón se cumple, lo cual ocurre siempre que existen reglas lógicamente equivalentes.

Bibliografía

El ciclo de DevOps, una guía para iniciarse en las fases que lo componen

01/04/2018
Artículo original

Devops Loop Illustrations

Hay términos que están de moda, tienen mucha capacidad de empoderamiento, y producen movimientos innovadores en las empresas. Sobre todo, las dedicadas a negocios relacionados con la economía digital.

Uno de ellos es, junto con microservicios, Agile, o transformación digital, el término DevOps.

Este es un concepto, cuasi una filosofía, del cual en este artículo voy a centrarme en la descripción de las fases del ciclo iterativo que lo componen; con el objetivo de aclarar conceptos básicos que debo tener interiorizados antes de emprender su adopción.

Fases en DevOps

Traffic Lights 2147790 960 720

En la actualidad, DevOps se puede definir como un símbolo de infinito o un circulo que define las diferentes áreas y fases que lo componen:

  • Plan
  • Desarrollo
  • Integración continua
  • Despliegue
  • Operación
  • Monitorización

Es importante comprender que es una de las múltiples representaciones, no el canon definitivo. Habiendo simplificaciones totalmente válidas en forma de cuatro fases principales, o descomposiciones detalladas de cada una de ellas.

Otra idea imprescindible de interiorizar es que se trata de la definición de un flujo iterativo, por lo cual diferentes procesos pueden estar comprendidos en diferentes fases de forma orgánica y superpuesta, siempre ajustándose a los conceptos fundamentales de valor y mejora continua.

Debo evitar caer en la tentación de considerarlo como un ciclo en cascada, en donde las fases están delimitadas rígidamente por una frontera que las separa, o que solamente se puede iniciar una fase cuando la anterior ha finalizado del todo.

Ahora, voy a mirar con más detalle cada fase, permitiéndome una licencia muy habitual en los procesos DevOps, que es utilizar el framework Scrum (y sus arquetipos) como metodología de trabajo para hacer más sencillas las explicaciones.

Gestión y planificación

Stratgia Proceso De Planificacion Estrategica

Todo proyecto necesita una visión que indique a los participantes -sean directos o indirectos- el motivo y fin último del trabajo a realizar; definiendo un conjunto mínimo de funcionalidades que permitan aportar Valor en cada iteración, los criterios de aceptación a cumplir y la definición de acabado; para cada una de las fases y en el conjunto del proyecto.

Esto se constituye como una Pila de Producto viva, que está soportando continuadamente un proceso de “jardinería”, desde un punto de vista de negocio, la cual alimenta a las diferentes fases de desarrollo y operaciones; y que aborda los cambios y evoluciones según un proceso de mejora continua basado en un feedback temprano y continuado.

Para ello utilizare las “liturgias” de Scrum, como son las reuniones de Planificación de la iteración y la Revisión de la iteración; pero sin, por ello, dejar de tener una comunicación e implicación constante entre negocio y el equipo técnico. Siendo imprescindible que Negocio y Gestión se formen en las herramientas y métricas diseñadas para que tengan una visibilidad veraz y suficiente del desarrollo del proyecto.

Desarrollo, construyendo código

Mr Burns Monkeys Typewriters1

Esta fase es en donde se construye. Sea picando código, diseñando infraestructura, automatizando procesos, definiendo las pruebas o implantando la seguridad.

Es en donde, en la actualidad, se está realizando el esfuerzo más importante en la automatización de las acciones repetitivas o complejas; y que debiera ser uno de los primeros peldaños que escalar para implantar DevOps en una organización.

Si tuviera que resumir en una sola palabra el concepto más importante de esta fase, esta sería “pruebas.

Ya sea en una aplicación de gestión, operaciones con datos o el despliegue de infraestructura virtual; siempre voy a trabajar en código – ya sea con un lenguaje de programación o de scripting; el cual debe ser almacenado en un gestor de código que me permita operaciones básicas como históricos, ramas, versionado, etc.

Pero con esto no es suficiente y cada pieza construida debe incluir (obligatoriamente) sus propias pruebas automatizadas. Es decir, los mecanismos con los que el propio sistema pueda asegurarse de que lo que hemos realizado es correcto, no falla, no hace fallar a otras partes, cumple los criterios de aceptación, y señala de forma temprana los errores que surgen en todo desarrollo.

De hecho, este es un camino imperativo para adoptar Devops, desde sus más incipientes estadios.

Primero almaceno el código/script en un gestor para poder tener versionado y poder hacer rollback; luego empezar a incluir las pruebas automatizadas, lo cual va a producir una transformación profunda en las técnicas de codificación (desacoplamiento, segregación, modularización, etc); por último, se llega a la orientación de lo construido hacía las fases siguientes, incluyendo la transformación del propio flujo de trabajo.

Integración continua, o cómo dormir tranquilo

Sleeping Baby 1

Aunque en esta fase y la anterior la mayoría de los autores nos centramos en un punto de vista de desarrollo, realmente la llegada de DevOps y los conceptos de Infraestructura como código, hacen que IT también sea pleno participante de esta fase.

La integración continua es automatizar el mecanismo de revisión, validación, prueba y alertas del valor construido en las iteraciones, desde un punto de vista global.

Es decir, mi singular funcionalidad o característica, que he construido en mi entorno de desarrollo, junto con las pruebas automáticas que aseguran su correcto funcionamiento, son publicadas en un servicio que la integra con el resto de la aplicación.

Así, lanzando todas las pruebas que incluye cada funcionalidad, más las pruebas de integración de toda la aplicación, más las pruebas funcionales, más las pruebas de aceptación, más los análisis de calidad del código, más las pruebas de regresión, podré estar seguro de que mi aplicación sigue funcionando correctamente.

Y si algo falla, saltará la alerta temprana indicando en qué pieza y en qué línea está rompiendo mi sistema.

Así que, cuanto más me acerque al momento de iniciar el camino crítico del despliegue, más tranquilo estaré porque más pruebas incluyen mi trabajo.

Despliegue automatizado

Gns60gr

Desplegar, en las organizaciones clásicas, siempre ha sido un dolor. Dos roles (Dev e IT) con objetivos e intereses divergentes se encuentran en una batalla de incomunicación y recelo mutuo para publicar la aplicación en los diferentes entornos de trabajo: desarrollo, integración, calidad/test, preproducción, producción, etc.

Como en toda cadena, es fácil romper por el eslabón más débil, y cuantos más pasos existan en los procesos de despliegue, más posibilidades de fallo humano se suman.

Así, DevOps promueve la automatización de los despliegues por medio de herramientas y scripts, con el objetivo último de que todo el proceso se resuelva con un botón de aprobación o, idealmente, la activación de una característica.

Entre cada entorno de despliegue, hay que tener muy en cuenta la administración del contexto (crear, configurar y destruir entornos); realizar y superar las pruebas específicas de cada uno (como pueden ser pruebas de rendimiento, resiliencia, funcionales, de seguridad o de UX); y administrar la gestión de la configuración (CMDB) de acuerdo con las complejas necesidades de los diferentes contextos de despliegue.

Lo más crítico y dificultoso en esta fase, más que conocida y adoptada en el entorno IT, es la llegada del concepto Cloud con sus capacidades de Infraestructura como código, que fuerza un cambio en el paradigma de la gestión de la infraestructura. Que pasa de una gestión de recursos finitos a una gestión basada en una optimización permanente de costes.

Operaciones, velando por el buen funcionamiento

Istock 000026445143small 0

Es una minoría las aplicaciones que son puestas en producción y no requieren de un trabajo constante en su optimización, evolución, o soporte. Pero, además, debo tener en cuenta todas las operaciones relacionadas con su funcionamiento que deben realizarse de forma continuada durante toda la vida del software.

Así tendré, el ajuste de los recursos de acuerdo con la demanda o las características de crecimiento de las aplicaciones; la modificación dinámica de la infraestructura por causas de seguridad, rendimiento, disponibilidad, etc.; o la optimización de procesos y procedimientos que requieren cambios en el contexto de ejecución y explotación.

En esta fase, aplicará como anillo al dedo la adopción del concepto de Nube – sea pública, privada o hibrida- en dónde las operaciones puedan explotar las capacidades de escalabilidad, persistencia, disponibilidad, transformación, resiliencia y seguridad que ofrecen este tipo de plataformas.

Debiendo trabajar en la automatización de la optimización de los escenarios de operaciones, de forma que vuelvo a mitigar los fallos a causa de error humano.

Monitorización, o el arte de medir

Measurement

Esta última fase de un proceso DevOps, es una fase permanente y que se aplica a todo el ciclo completo.

Es dónde voy a definir las medidas que estaré monitorizando para controlar el estado de salud de las aplicaciones y su infraestructura, siendo esto el histórico de las mediciones durante un periodo de tiempo, que me muestran la evolución del sistema.

Tiene una vertiente reactiva, en donde de acuerdo con los resultados iré ajustando o modificando la plataforma; y otra proactiva en la cual un proceso de aprendizaje continuo me va a permitir adelantarme a las necesidades y riesgos.

Lo que no se define no se puede medir. Lo que no se mide, no se puede mejorar. Lo que no se mejora, se degrada siempre. William Thomson.

Pero no todo es tecnología, y en esta fase se va a consolidar el feedback continuo de todos los ámbitos y niveles del ciclo Devops para poder incluirlos en la siguiente iteración durante la fase de Plan, o de forma inmediata con correcciones puntuales.

Monitorizaré, analizaré y mediré todo aquello que me pueda aportar una visión general del estado actual del proyecto (en su definición más amplia), incluyendo todas las dependencias que tuviera; pero con capacidades de bajar hasta la singularidad para observar con detenimiento el funcionamiento de una pieza en particular.

Y por medio de la realización de retrospectivas, completaré el proceso de Kaizen (mejora continua) del proyecto, incluyendo todos los orígenes relacionados con el desarrollo positivo de los trabajos.

Sobre las fases del ciclo DevOps

Continuous Delivery Infographic 1x

He mostrado una visión generalizada e idílica de un ciclo DevOps completo, siguiendo una estructura lógica basada en la experiencia y en la profusa literatura que hay publicada.

La realidad es bastante más compleja tanto en la implantación como en la ejecución; pero sin duda el mayor escollo son los problemas de comunicación entre los equipos con objetivos e intereses diferentes, y la desconfianza de salir de mi zona de confort siguiendo una “moda”.

Sin embargo, los beneficios son muy importantes. Y no solo en el ámbito de la productividad, del Time to Market, o de la flexibilidad de la empresa frente a las demandas del negocio y los clientes; si no también en los factores humanos, de mejora de la calidad de vida, que hay que valorar en su justa y positiva medida.

También te recomendamos

Dime cuál es la organización de tu equipo de desarrollo y te diré cómo es la arquitectura de tu software

La importancia de la refrigeración en un portátil

Trabajar con microservicios: evitando la frustración de las (enormes) aplicaciones monolíticas

-
La noticia El ciclo de DevOps, una guía para iniciarse en las fases que lo componen fue publicada originalmente en Genbeta Dev por Juan Quijano .

Cómo son los desarrolladores de 2018 según Stack Overflow

28/03/2018
Artículo original

Imagen ornamental
Fotografía de la cabecera: Eleaf / CC BY

Un año más Stack Overflow ha publicado los resultados de la encuesta que anualmente realizan entre sus usuarios. Este año la participación ha sido más alta que nunca, más de 100.000 personas se han molestado en responder a una encuesta de unos 30 minutos de duración. ¡No está nada mal!

Además de las preguntas habituales que ya conoces por otros años, este año han introducido algunas novedades. Por ejemplo, desde el punto de vista técnico han preguntado por primera vez sobre inteligencia artificial o la ética en programación. En la parte personal han preguntado por tendencias sexuales, hábitos alimenticios o número de hijos (WTF?).

Sin más dilación vamos allá con el resumen de 2018:

1.- Perfil de un programador:

Esta parte hace referencia a los datos demográficos de los programadores, a saber: lugar de residencia, edad, género, estudios, trabajo, experiencia profesional,...El resumen sería:

Varón de 28 años con 5 años de experiencia (no necesariamente laboral), con estudios universitarios de informática y desarrollador back-end.

Respecto al perfil de otros años lo único que ha cambiado es que este año los encuestados parecen tener más claro lo que son y se identifican como desarrolladores back-end en lugar de full-stack.

Distribución de pusto/denominación por número de desarrolladores y género
Imagen propiedad de Stack Overflow

En la página de Stack Overflow dispones de más gráficas y preguntas personales a las que han respondido los usuarios con las que podrás sacar tus propias conclusiones.

2.- Tecnología

Por sexto año consecutivo JavaScript vuelve a ser el número 1 por goleada.

JavaScript es el lenguaje más usado por la comunidad. Python ha subido en el escalafón superando este año a C#, al igual que superó a PHP el año pasado.

Evolución de lenguajes más utilizados en los últimos años
Imagen de elaboración propia basada en datos de Stack Overflow

Node.js y Angular son las tecnologías más utilizadas de su categoría, seguidas por React y .Net Core.

En 2015 Mac desbancó a Linux pasando aquél a ser el segundo sistema operativo más usado. A pesar de que cada año crece en número de usuarios, Windows sigue teniendo el 50% del mercado.

Las tecnologías se agrupan en ecosistemas relacionados que tienden a ser utilizados por los mismos desarrolladores. En parte del gráfico, vemos un gran clúster central para desarrollo web (con JavaScript, HTML y CSS) conectado a través de SQL a otro gran grupo formado por las tecnologías de Microsoft (con C #, Visual Studio y .NET Core). A la izquierda vemos otra agrupación que conecta Java, Android e iOS a través de Linux, bash/shell y Python. Para conocer todas las agrupaciones véase el gráfico original.

Ecosistemas de desarrollo relacionados
Imagen propiedad de Stack Overflow

Este año hay un apartado titulado tecnología y sociedad centrado en la inteligencia artificial. Resulta bastante interesante, te aconsejamos que le eches un vistazo al enlace anterior.

3.- Trabajo:

Los desarrolladores suelen centrarse en la parte técnica de su trabajo. Están satisfechos con su puesto de trabajo, siendo el dinero su prioridad a la hora de elegir el mismo.

La gran mayoría de los programadores están trabajando, concretamente el 90% tiene un trabajo remunerado, siendo el 74% a tiempo completo.

En las preguntas relativas al trabajo se han obtenido una gran variedad de respuestas, por lo que las conclusiones ya no son tan categóricas con en el caso de las tecnologías predilectas. Así por ejemplo es casi imposible categorizar el tipo de industria o el tamaño de empresa en las que trabajan la mayoría de los desarrolladores.

En lo que a su carrera profesional se refiere, los programadores están satisfechos con su trabajo actual y aunque esto prácticamente no varía según la industria en la que trabajen, sí se ha detectado que aquellos que trabajan en el sector financiero están más descontentos.

A la típica pregunta “¿dónde te ves dentro de 5 años?”, más de la mitad responde que quiere estar haciendo lo mismo o en otro puesto técnico. Un cuarto de los encuestados afirma querer montar su propia empresa, aunque es importante aclarar que la gran mayoría que dan esta respuesta son menores de 25 años (¿inconsciencia o emprendimiento verdadero entre las generaciones más jóvenes?).

Este año desde Stack Overflow han decidido incorporar preguntas sobre ética profesional. Según ellas la mitad de los programadores jamás escribirían código para un proyecto cuyo propósito no fuera ético. Sin embargo, curiosamente, la gran mayoría opina que en caso de que existan implicaciones no éticas en el código, el culpable es el jefe. Solo un 19% asume su competencia afirmando que el programador es el responsable último del código escrito.

Aunque solo un 16% de los que trabajan están buscando un nuevo puesto de trabajo, tres cuartas partes de ellos están abiertos a valorar otras propuestas, siendo los CTOs (responsables de tecnología) los más reacios a cambiar de trabajo y los relacionados con el mundo académico los más activos en la búsqueda de empleo.

En general, la prioridad de los desarrolladores para evaluar un trabajo es la remuneración, seguida de las tecnologías específicas con las que trabajarán. Lo que menos les importa es la diversidad de la empresa en la que trabajen, lo cual resulta paradójico teniendo en cuenta el gran esfuerzo que están haciendo ahora todas las empresas de TI para luchar con problemas relacionados con la diversidad.

4.- Comunidad:

La mayoría de los desarrolladores usa Stack Overflow para obtener ayuda para su trabajo.

El 85% de los encuestados visitan Stack Overflow varias veces a la semana, y la mitad de ellos al menos una vez al día.

Algunos desarrolladores acuden a Stack Overflow solo para encontrar respuestas a sus preguntas, mientras que otros participan en la comunidad al preguntar, responder, votar o comentar preguntas. Más del 40% de los desarrolladores participan en Stack Overflow varias veces al mes.

La mayoría de los encuestados de la encuesta se consideran parte de la comunidad de Stack Overflow, pero esto varía según los diferentes grupos de personas. Por ejemplo, los encuestados que se identifican como hombres se ven a sí mismos como parte de la comunidad a tasas más altas que aquellos con otras identidades de género:

¿Eres parte de la comunidad?
Imagen propiedad de Stack Overflow

Aunque es evidente que esta encuesta refleja sobre todo una realidad anglosajona somos muchas las personas que nos vemos reflejadas en la mayoría de las preguntas. ¿Y tú? ¿Te sientes identificado con la descripción que ofrece? Deja tus impresiones en los comentarios.

Funcionalidad "Overrides" en Chrome 65: guardando cambios en tu CSS desde el navegador

26/03/2018
Artículo original

Lo que voy a contar a continuación estaba programado para que saliera en la versión 64 de Chrome, en Enero, pero al final la han sacado este mes con Chrome 65.

¿Cuántas veces has estado toqueteando una página que gestionas desde las herramientas del desarrollador? Seguro que muchas.  Lo típico es que un elemento rebelde no acaba de quedar en donde a ti te gustaría o quieres afinar mucho más un margen, un tamaño o un color. Así que abres las herramientas del desarrollador con F12 o con CTRL+MAYs+J (en Windows) y te pones a seleccionar elementos, ver sus reglas resultantes, cuáles influyen sobre el resultado final, y retocas directamente los estilos en el editor del lateral.

Esta funcionalidad ya la habríamos querido para nosotros los que estábamos en esto hace 20 años, pero aún así es un tanto limitada. Si tus cambios se reducen a un par de propiedades CSS puedes tomar nota en un archivo de texto y luego buscar en la CSS original para hacer los cambios. Pero como sean un poco más extensos e involucren unas cuantas propiedades y selectores o, peor aún, se realicen sobre varias hojas de estilo diferentes, entonces hacerles el seguimiento puede ser una locura.

Por suerte la gente detrás de Chrome siempre está al quite con este tipo de detalles y sacan de vez en cuando funcionalidades que nos hacen la vida más fácil. En Chrome 65 han lanzado lo que se denominan "Overrides" que son versiones locales de los mismos archivos que hay en el servidor en los que se van almacenando todos los cambios que hagamos.

Esto es sensacional, ya que nos permite tocar tanto como queramos los estilos de una página y ver los archivos originales ya modificados en nuestro disco duro. Luego solo hay que subirlos por encima de los del servidor y se incorporarán todos los cambios. Es súper-útil.

En el vídeo que pongo a continuación explico en la práctica cómo conseguir esto. Antes de verlo un par de cosas importantes:

  • Los cambios hechos sobre el DOM no se persisten. Es decir, que si añadimos algún estilo en línea con el atributo style o usando la zona element.styles del editor de propiedades CSS, estos cambios no quedarán guardados en ningún lado.
  • Chrome 65 también introduce una cosa muy interesante para verificar si un texto se lee lo suficientemente bien sobre su fondo (contraste) como para que cumpla con las reglas de accesibilidad. Lo comento, como inciso, en el vídeo.

Ahí lo dejo:

[youtube:zG1MXJJzZ6I]

¡Espero que te sea útil!

Cómo eliminar el último commit de Git en el repositorio de origen (p.ej Github)

26/03/2018
Artículo original

El objetivo principal de trabajar con un sistema de control de código fuente como Git es, por supuesto, mantener un histórico fiel e inalterado de todas las etapas por las que ha ido pasando el código fuente de un proyecto. A medida que vamos modificando el código y haciendo commits, su historia  se va ampliando. En cualquier momento podemos ver el estado exacto que tenía un archivo en cualquier momento del pasado, e incluso ver quién ha hecho un cambio concreto, lo cual es de gran utilidad. Sin embargo, a veces, podemos añadir algo a esta historia que no pretendíamos añadir. Por ejemplo, hacemos un commit sin querer, metemos archivos de más o de menos, o va con un bug vergonzoso que no queremos que nadie vea y que se nos ha colado...

Por regla general no deberíamos modificar la historia salvo que sea estrictamente necesario, pero ¡hey!, estas cosas pasan, así que deberíamos poder arreglarlo.

Git es fácil de usar en el día a día, pero cuando aparece algún problema entran siempre en juego muchas variables y puede complicarse la cosa. ¿Cómo arreglamos esto?

Vamos a ver varios casos que se refieren exclusivamente a cuando se trata del último commit realizado. Si es un commit anterior dependiendo de lo que necesitemos habría que hacer otras cosas, pero este es el caso más habitual, así que es el que vamos a ver por brevedad.

En Git existen muchas maneras de hacer las cosas. Estas que cuento a continuación no tienen por qué ser las únicas, pero son las que a mí me parecen más directas y sencillas.

El commit NO está en Github todavía

Bueno, este es el caso fácil. Si hemos hecho el commit y todavía no se ha enviado al repositorio de origen (en Github, GitLab, Bitbucket o donde sea), podemos solucionarlo de varias maneras.

Volver al último commit empezando de cero

Si lo único que necesitas es eliminar este último commit y empezar de nuevo solo tienes que abrir una línea de comandos  en la carpeta del repositorio y escribir:

git reset HEAD^ --hard

Lo que hace esto es eliminar el último commit de la historia, dejando la carpeta en el punto anterior en el que estaba antes de hacer los cambios correspondientes a dicho commit.

El ^ del final de la cabecera le indica a Git que el punto de la historia en donde deseas  dejarla (resetearla), es el padre del último commit en la rama actual (que se llama siempre HEAD). Es importante indicarlo.

Ahora bien, esto hará que pierdas todos los cambios que había en éste. 

Volver al último commit pero no perder los cambios actuales

Lo anterior será lo que desees hacer en muchos casos, pero en muchos otros no. A lo mejor lo que necesitas corregir está en un solo archivo y los cambios de los demás te parecen bien. En estos casos está bien eliminar el commit pero al mismo tiempo evitar perder los cambios. Conseguirlo es casi idéntico a lo anterior, y solo debes escribir:

git reset HEAD^ --soft

De este modo deja todo tal cual está.

Me he olvidado de uno o varios archivos

Si no te hace falta algo tan radical y simplemente te has olvidado de añadir algún archivo  al último commit, no hace falta que deshagas todo como acabamos de ver.

Puedes escribir tan solo este comando para añadir los que te falten:

git add archivo1.ext archivo2.ext ...

Ten en cuenta que puedes usar patrones para añadir varios archivos con un nombre similar de golpe, o simplemente hacer una lista como se ve en lo anterior.

Cuando hayas añadido los archivos que te faltasen, indicas que quieres modificar el commit anterior en base a esto, escribiendo:

git commit --amend

lo cual añadirá el o los archivos al último commit que todavía está en tu equipo.

Nota: si haces esto así, desde línea de comandos, la opción --amend te abre un editor vi por si quieres modificar el mensaje también. Para salir y terminar con la operación debes pulsar ESC y a continuación :x o :q para que salga y grabe los cambios.

El commit ya se ha enviado al servidor remoto (Github, Gitlab, Bitbucket...)

Esta es una pregunta muy frecuente de la que hay muchas versiones diferentes online para su respuesta, muchas de ellas incorrectas. Se trata de hacer lo mismo que acabamos de ver, pero esta vez teniendo en cuenta que no solo está en nuestro equipo local, sino que dicho commit también se ha enviado al servidor de origen, sea éste Github, Bitbucket, Gitlab o similar.

En este caso en realidad es bastante sencillo de hacer también. Vamos a distinguir dos casos...

El repo local y el remoto están sincronizados

Este es el caso más habitual. Es decir, estamos trabajando en un repositorio, hacemos cambios, realizamos un commit para guardarlos en la historia y lo enviamos al remoto usando push. Acto seguido nos damos cuenta de que va con un error muy gordo y queremos echarnos para atrás. ¿Cómo lo hacemos?

Pues en primer lugar destruyendo el commit localmente como hemos visto en el apartado anterior, con:

git reset HEAD^ --hard

y a continuación forzando los cambios al repositorio remoto de origen con:

git push origin -f

En condiciones normales un push al origen falla si el commit que está "arriba" no es un ancestro del commit que se está intentado hacer. Es decir, si el repo remoto va por delante del repo local. Con el parámetro -f (o --force que es lo mismo) forzamos a que esta comprobación no se haga. Esto puede tener efectos destructivos y que se pierdan los commits que van por delante de nosotros, cosa que es justo lo que queremos en este caso: con la instrucción reset estamos situados en un commit inmediatamente anterior al último y con el push forzado estamos haciendo que éste desaparezca.

¡Espero que te resulte útil!

¿Deberías estudiar un MOOC de programación?

23/03/2018
Artículo original

Nadie puede criticar la ambición de las empresas que crean MOOC (Massive Open Online Course). Uno de los pioneros de estos centros de aprendizaje en línea, el fundador y presidente de Udacity, Sebastian Thrun, resumió recientemente su misión como nada menos que "democratizar la educación".

Pero, ¿cuán efectivos son estos cursos? Concretamente en lo que al aprendizaje de la programación se refiere, ¿es suficiente hacerse MOOC o un asistir a un bootcamp para comenzar una carrera como desarrollador de software?

A continuación se describe el perfil de las personas que habitualmente terminan con éxito estos cursos (basado en una encuesta de la HBR) y la calidad de los mismos (según los estándares de la Quality Master).

Perfil del usuario

En 2015 la Harvard Business Review publicó una encuesta titulada “¿A quién benefician realmente los MOOC y por qué?”, algunas de las conclusiones a las que llegaron fueron:

  • Los críticos tienen razón al decir que la mayoría de las personas que inician un MOOC no terminan: solo el 4% de los usuarios de Coursera que ven al menos una clase del curso continúan hasta completar el curso y recibir una credencial.
  • Los que terminan buscan, o bien beneficios educacionales, o bien beneficios profesionales:
    • El 52% indica que su principal objetivo es mejorar su empleo actual o bien encontrar uno nuevo.
    • El 28% se matricularon principalmente para lograr un objetivo académico, como obtener conocimiento en su campo (88%), o un beneficio tangible como un título académico (18%)
  • En lo que respecta al perfil de usuario, la mayoría de las personas que se inscriben en estos cursos tienen una buena educación y pertenecen a países desarrollados. Además cuando lo que buscan es potenciar su carrera, aquellas personas con mayor poder adquisitivo y mayor nivel educativo tienen una mayor probabilidad de éxito.

Según lo anterior parece que el perfil del estudiante que termina con éxito un MOOC es alguien que ya tiene conocimientos de la materia escogida y que busca profundizar en un aspecto concreto de la misma.

Calidad

Sin duda, la confianza y el reconocimiento, incluida la necesidad de convencer a las empresas de que confíen en la calidad de su acreditación, es algo que toda empresa de formación persigue debería perseguir ¡y las empresas que ofrecen MOOC y los bootcamps no iban a ser menos!

Sin embargo, según un reciente estudio realizado sobre un número limitado de cursos impartidos en las plataformas más populares de USA (Coursera, Udacity y EdX), ninguno de los cursos examinados superaba la revisión Quality Matters la cual evalúa la medida en que los cursos cumplen con un conjunto de estándares para la educación online. Las áreas en las cuales obtuvieron menor puntuación hacían referencia a la falta de apoyo que ofrecía el tutor al alumno (esto nunca te pasará en campusMVP, nuestros tutores responden tus dudas en menos de 24 horas) y al poco compromiso por parte de los estudiantes (con nosotros nunca estarás solo).

Si bien los cursos examinados no cumplieron con los estándares suficientes para aprobar la evaluación, algunos obtuvieron calificaciones relativamente altas, los investigadores dijeron que algunos de los MOOC podrían considerarse "cursos online de alta calidad tras algunas revisiones menores".

En verano de 2017 dos de los más conocidos bootcamps de EE.UU. echaron el cierre, Dev Bootcamp (de la empresa Kaplan), y The Iron Yard (de Apollo Education Group, partner de la universidad de Fénix). Cuando DevBootcamp anunció que estaba cerrando, la empresa admitió que “había sido incapaz de encontrar un modelo sostenible que aunara calidad de enseñanza y a la vez fuese accesible a todo el mundo”. Aquí puedes leer el artículo completo en inglés.

Los MOOC son accesibles, pero a veces diluyen el contenido demasiado, mermando así su calidad, porque lo que buscan es llegar al mayor número de personas.

En resumen

Parece, que en lugar de ayudar a impulsar la carrera de personas sin experiencia relevante o permitirles adquirir conocimientos en una nueva área, algunas evidencias sugieren que los MOOC son quizás más adecuados para ayudar a aquellos que ya son expertos en un área particular a especializarse aún más.

Y tú ¿qué opinas? ¿Has hecho algún MOOC alguna vez? ¿Qué calidad tenía? ¿Lo has terminado? Déjanos tus impresiones en los comentarios.

Azure Web Apps #2 - Creando y configurando la aplicación

21/03/2018
Artículo original

Logo Azure Web Apps En el anterior artículo expliqué qué es una Plataforma como Servicio (PaaS) en la nube y por qué son interesantes. Presenté la PaaS de Microsoft, llamada Azure Web Apps, así como sus ventajas, sus inconvenientes, sus precios y para quién es adecuada.

Ahora vamos a la parte práctica de cómo montar una aplicación real sobre Azure Web Apps, siguiendo el ejemplo de este blog, que migré sin adaptaciones a este servicio.

Parto de la base de que tienes una cuenta válida de Azure o que al menos ya has ido a su web y te has creado una cuenta de prueba. La cuenta de prueba te da 170€ para gastar en 30 días, por lo que dan mucho de sí y al terminar puedes usar muchos productos gratuitos, entre ellos las Azure Web Apps, aunque eso sí, sin dominio propio y compartiendo infraestructura.

Nota: todas las capturas que verás a continuación están en inglés porque ese es el idioma que uso en todo el software que utilizo (incluso en el móvil). El motivo de usarlo siempre es que toda la documentación en este idioma suele estar mejor que en español (salvo honrosas excepciones) y es más abundante. Por lo tanto cuando surge un problema es mucho más fácil encontrar soluciones en el idioma de Shakespeare que en el de Cervantes, así que para mi no hay otra opción lógica. Además, el software lo prueban infinitamente más en inglés que en otros idiomas por lo que es menos probable que haya problemas también.

1.- Crear la Web App - Datos básicos

Lo primero que debemos hacer una vez hayamos accedido al portal de Azure es crear una nueva Web App. Para ello pulsamos en el botón de "Nuevo" con un más, arriba a la izquierda, y elegimos la sección Web + Mobile y dentro de esta Web App:

Diálogo de selección de nueva Web App

Al pulsar el primer enlace (el de debajo nos lleva a un tutorial) se nos muestra información sobre el producto y al continuar se nos piden una serie de datos básicos que debemos rellenar:

Datos básicos de la Web App

Lo primero es darle un nombre único entre todas las Web Apps que alberga Azure, lo cual salvo que sea algo muy específico puede ser complicado. En el ejemplo de mi blog, como vemos en la figura anterior, no hubo problema y se puede acceder a través de https://jasoft.azurewebsites.net. Esa será la dirección por defecto para el servicio, y a través de la cual accederemos mientras lo estemos configurando inicialmente.

Nota: Luego veremos que con un poco de configuración es posible evitar que se acceda a través de ahí y que se utilice tan solo nuestro dominio principal, lo cual además es importante para SEO (optimización de cara a buscadores).

Lo siguiente es la suscripción de Azure que quieres usar, ya que puedes tener más de una activa al mismo tiempo (como es mi caso que tengo una personal y una de empresa).

Los grupos de recursos es simplemente una manera de agrupar los diferentes servicios que tienes activados en Azure, de modo que luego los puedas gestionar en grupo o, al menos, listar todos juntos. Puedes crear uno nuevo o reutilizar uno existente. En mi caso opté por la segunda opción y reutilicé un grupo de recursos que tengo para mis webs personales y algunas otras cosas similares.

Ahora sí, un paso muy importante: el sistema operativo que quieres usar. Tienes dos opciones: Windows y Linux. Dependiendo de la tecnología que utilices para tu aplicación deberás escoger uno u otro, aunque hay tecnológicas (como PHP, Node.js, Python o .NET Core) que funcionarían sin problema en ambos. Si este es el caso puedes escoger Linux. La ventaja de Linux sobre Windows en Azure Web Apps es que, ahora mismo, permiten además desplegar contenedores Docker, cosa que en Windows todavía no es posible en este servicio. En mi caso, dado que mi blog usa Blog Engine (lamentablemente) y es una aplicación escrita en .NET 4.x (o sea, .NET "clásico"), necesito Windows.

La ubicación y el plan de servicio es el parámetro más importante. Con esto le indicamos dos cosas. En primer lugar qué plan de servicio queremos utilizar. El plan de servicio es el tipo y el tamaño de los recursos que queremos dedicar a la Web, lo cual condiciona qué características podemos usar y por supuesto el precio. Mientras no tengamos configurado el funcionamiento básico de la aplicación, y mientras no le asignemos un dominio propio (o a lo mejor ni siquiera quieres hacerlo) podemos elegir la capa gratuita que hemos visto o bien una de las compartidas, que te dan más potencia pero son muy baratas. Para subir de nivel tenemos tiempo luego y así mientras no dejemos la app configurada ahorramos unos céntimos ?

Al crear el plan de servicio debemos elegir también la ubicación, es decir, en qué área geográfica del mundo queremos que esté ubicado nuestro plan de servicio. Esto tiene su importancia, sobre todo si no vamos a usar un servicio de CDN para distribuir nuestros contenidos. Cuánto más cerca estemos de nuestros visitantes mejor. En mi caso la mayor parte del tráfico viene de España (y es donde estoy yo también) por lo que ubicarlo en Europa tiene todo el sentido. Dentro de Europa tenemos la zona Norte (con Data Centers en Irlanda y Reino Unido) o la zona Oeste (con DCs en Alemania, Holanda y otros países de la zona). Aquí tienes información sobre todas las ubicaciones. A efectos prácticos es indiferente escoger la zona norte o la oeste de Europa para este servicio, así que como ya tenía otros servicios en la zona oeste, elegí esa.

Lo de Application Insights de momento lo dejaremos desactivado. Se trata de servicios para monitorizar la aplicación.

Le damos a Crear y empieza el despliegue inicial de la Web App. Al cabo de unos segundos habrá terminado y veremos una notificación parecida a esta:

Notificación de servicio creado y desplegado

¡Listo! Ahora hay que instalar tu aplicación

2.- Configuración técnica

Al acceder a la página principal de nuestra Web App veremos que se nos informa de sus datos básicos (nombre, estado, ubicación, dirección de acceso, sistema operativo que en mi caso es Windows Server 2016 pero que realmente no nos importa pues es una de las ventajas de PaaS). También tenemos unas gráficas debajo que ahora están en blanco pero que nos darán información en el futuro sobre cómo está funcionando la aplicación:

Página inicial de la Azure Web App

Lo primero que deberíamos hacer es configurar las tecnologías que necesitaremos utilizar en nuestra aplicación. Para ello, en el menú lateral tenemos el grupo Settings > Application Settings (recuadrado en rojo en la figura anterior).

Al acceder a este apartado podremos configurar los aspectos técnicos de nuestra aplicación:

Ajustes técnicos de la app

Yo lo primero que hago es desactivar las tecnologías que no voy a utilizar: cuantas menos cosas activadas menor es la superficie de ataque y más seguro será el servicio (y más rendimiento arañaremos). Así que dejo .NET 4.7 y desactivo PHP, Java, etc... Además desactivo los Web Sockets ya que no los voy a necesitar, y tampoco le activo la opción de Always On ya que el sitio tiene tráfico suficiente para mantenerla siempre en marcha.

Aquí hay dos parámetros que merecen mención aparte.

El primero de ellos es el tipo de plataforma, si es de 32 o de 64 bits. La tentación siempre es ir y marcar la de 64 bits, a pesar de que por defecto está seleccionada la de 32 bits. Es natural, al fin y al cabo 64bits se asocia con sistemas operativos modernos, mejor manejo de memoria, más rendimiento... Lo cierto es que no suele haber una buena razón para elegir la opción de 64 bits. Por el mero hecho de seleccionarla lo único que conseguiremos es que nuestra aplicación utilice una cantidad mucho mayor de memoria, lo cual en la mayor parte de los casos es innecesario y aumentará nuestros costes a largo plazo si tenemos que escalar. La diferencia de rendimiento no existe, y si no necesitamos acceder a las cantidades enormes de memoria que nos habilitan los 64 bits, merece la pena dejarlo en 32 bits. Con 32 bits puedes direccionar hasta 4GB de memoria, más que suficiente para la mayor parte de las aplicaciones. De hecho la mayor parte de los planes de servicio no te dan tanta memoria en cualquier caso. Entonces, salvo que tengamos un plan grande (y caro) de Azure Web Apps y necesitemos usar toda esa memoria, es mejor no cambiarlo.

El otro parámetro interesante de la pantalla anterior es el tipo de pipeline que queremos usar. Esto es un ajuste que tenemos en IIS para los pools de aplicaciones y puede tomar dos valores:

  • Integrado: las peticiones que llegan pasan por la arquitectura integrada de IIS y .NET, siguiendo una serie de pasos ordenados de manera que se van llamando todos los módulos necesarios para procesar la petición (nativos del sistema y gestionados por .NET). De este modo además es posible utilizar .NET y cualquier módulo creado con esta tecnología para procesar parte de la petición, pudiendo, por ejemplo, añadir autenticación y autorización para recursos que no son de .NET por defecto (como un archivo de imagen o de CSS). Tiene varias ventajas y normalmente es la que deberíamos utilizar salvo que nuestra aplicación no lo soporte.
  • Clásico: en este modo las peticiones van primero a través de IIS y módulos nativos, y luego se pasan a .NET en caso de que sean recursos propios de esta tecnología, para pasar de nuevo a los pasos finales del pipeline de IIS y poder devolver el resultado. Esto implica pasos duplicados y menos eficientes para recursos .NET aunque , por ejemplo, las peticiones a recursos estáticos como imágenes o archivos CSS no son procesadas por .NET y por lo tanto irán un poco más ágiles. Sin embargo no podremos usar .NET para interceptar las peticiones a esos recursos y hacer cosas con las peticiones, como por ejemplo autenticarlas y autorizarlas, o cambiar lo que devuelven.

Personalmente me encanta el control que te permite obtener el modo integrado y es el valor que utilizo. En tu caso deberías ver si la aplicación que vas a instalar te permite usar el modo integrado. Salvo que sea muy antigua no deberías tener problema. Si quieres profundizar un poco más en el tema, en este documento de Microsoft te lo explican un poco más.

Más tarde volveremos sobre esta sección del portal para ver algunos ajustes adicionales, pero de momento con esto es suficiente.

3.- Despliegue de la aplicación

Una vez que has ajustado las tecnologías que quieres utilizar, lo único que resta para las primeras pruebas es desplegar tu aplicación al servicio. En Azure Web Apps existen muchas formas de hacerlo. De hecho hay toda una sección para esto, en el lateral, dentro de la configuración del servicio:

Sección de despliegue de la Web App

La opción interesante en este caso es la que reza Deployment Options (o, en español, Opciones de Despliegue). Desde aquí tenemos la opción de elegir desde dónde queremos desplegar nuestra aplicación, no solo ahora, sino en el futuro a medida que haya cambios y actualizaciones.

Si pulsamos sobre esa opción se nos abre una nueva "hoja" del portal de azure en la que debemos elegir un origen para el despliegue y se nos ofrecen diversas opciones:

Proceso de selección de método de despliegue

Como vemos podemos elegir desplegar desde OneDrive, Dropbox o desde diversos servicios Git. Incluso desde un repositorio Git que tengamos creado en local en nuestro equipo (basta con añadir la web app como remoto para desplegar).

Personalmente encuentro muy útil desplegar desde Dropbox cuando tocamos el sitio muy poco a menudo y lo hacemos editando directamente los archivos en disco. Lo malo de esta opción es que hay que entrar en el portal de Azure y darle a un botón cada vez que quieres desplegar (o automatizarlo, claro, pero para mi pierde la gracia). En cambio, usando un repositorio Git local o remoto es más fácil, puesto que solo hay que hacer un commit a una rama determinada y listo. En cualquier caso la Web app guardará versiones de los últimos despliegues para poder volver atrás con un clic si nos arrepentimos o si hay algún fallo. Se accede desde el mismo menú. Por ejemplo: esta captura es de un sitio web pequeñito que tengo para un "side project" que lo despliego desde Dropbox. Como vemos hay un histórico de despliegues y pulsando sobre cualquiera de los anteriores podemos ver sus datos y nos ofrecerá un botón de "redesplegar", de modo que volveremos al estado anterior en un momento:

Listado de despliegues desde Dropbox

En el caso de un gestor de contenidos o un software de ese estilo en el que, una vez instalado, lo normal es que gestionemos todo desde la propia aplicación, lo más fácil será utilizar el tradicional FTP para desplegar. En el caso del ejemplo con mi blog es lo que haré.

Una tentación grande que existe (y que en mi opinión es un fallo grande de Microsoft), es utilizar la opción que dice Deployment Credentials o Credenciales de despliegue que está en este mismo grupo y que aparentemente te deja establecer una cuenta de FTP para el servicio. Como ya expliqué en este blog hace una temporada eso es un error ya que estaremos cambiando las credenciales para la cuenta de Azure completa, no solo para este sitio web. La forma correcta de hacerlo es usando el botón de Get Publish Profile que tenemos en la portada del sitio, tal y como explico en el enlace anterior. Esto, Microsoft, debería mejorarlo y hacerlo mucho más claro.

Una vez que tengamos las credenciales accedemos por FTP y vemos los contenidos actuales, que constan de una única página por defecto que la que vemos al acceder al sitio desde el navegador, y que debemos borrar para copiar nuestra aplicación:

La página por defecto del sitio

Fíjate en que la aplicación web se almacena bajo una carpeta llamada wwwroot que a su vez es hija de otra carpeta llamada site. Es importante conocer esta ruta, como veremos a continuación. Copia en wwwroot los archivos de tu aplicación.

En el caso de una aplicación .NET como BlogEngine lo normal es que llegue con simplemente copiar los archivos de la aplicación, cosa que hice.

En el caso de este blog hay un detalle especial que hace que tenga que configurar una cuestión adicional y que me viene bien para explicar otra configuración interesante: la creación de directorios y aplicaciones virtuales bajo Azure Web Apps.

Si te fijas, mi blog no se ejecuta en la raíz de la web sino que está ubicado bajo una carpeta llamada Blog, de ahí que todas las rutas llevan /Blog delante. Esto es así por razones históricas ya que en lo más de 20 años que tiene el dominio ha pasado por varios sistemas y ni siquiera fue un blog en sus inicios (porque no existían). El caso es que para que BlogEngine funcione correctamente en esa subcarpeta, la tengo que convertir en una aplicación web. Esto en IIS se hace desde el administrador de sitios, y en Azure Web Apps tenemos que recurrir nuevamente al apartado Application Settings que hemos visto antes. En la parte de abajo de éste tenemos un apartado de Aplicaciones y carpetas virtuales que es en donde debemos configurarlo.

En el caso concreto de mi blog la configuración es la siguiente:

Definir una carpeta virtual

Fíjate en cómo tenemos dos aplicaciones web configuradas. Una es la raíz de la web, que es configurada automáticamente por Azure. La otra es la aplicación de mi blog que está bajo una carpeta que lleva el mismo nombre que la carpeta física, pero que no tendría por qué ser así. En el lado izquierdo debemos definir la ruta relativa desde la raíz de la web en la que queremos configurar la aplicación. En el cuadro de texto de la derecha es la ruta física relativa a la raíz en donde está el código de la aplicación que vamos a configurar.

Importante: en este apartado de configuración tenemos también la posibilidad de establecer ciertos ajustes propios de la aplicación, como cadena de conexión, parámetros propios o manejadores de peticiones. Esto son equivalentes a los que meteríamos en el web.config de nuestra aplicación, pero con una salvedad: no quedan guardados en el web.config de la app, solo son accesibles desde aquí y además tienen prioridad sobre los que hayas establecido en el web.config de la aplicación. Esto es estupendo puesto que te permite gestionar parámetros privados (como contraseñas o configuraciones sensibles) sin que otros desarrolladores que tengan acceso a la misma aplicación puedan verlo.

Bien, con esto ya está la aplicación configurada ya que en mi caso no necesito cambiar ningún ajuste más, puesto que no utiliza bases de datos y todo lo necesario lo tiene en el sistema de archivos. Toca hacer una primera prueba para comprobar que está empezando a funcionar.

Así que vamos a la dirección por defecto que tiene el sitio web con una navegador. La primera petición tarda un poco mientras se levanta el servicio por primera vez.

En mi caso, la cosa no pinta bien:

Error al intentar acceder por primera vez

El motivo ya nos lo dice el propio navegador y no tiene nada que ver con Azure, sino con el funcionamiento de BlogEngine. Existe un ajuste de este sistema de blogs que sirve para indicar si se debe añadir automáticamente la www delante del nombre de dominio en caso de acceder con un dominio que no lo lleve. Cosas de SEO, y mi blog lo tiene activado. Si intentas acceder sin la www se la añadirá y hará una redirección. Este es el motivo de ver esa dirección tan rara en la barra del navegador. Y no funciona porque el dominio www.jasoft.azurewebsites.net no existe. Pero al mismo tiempo me está indicando que la aplicación ha funcionado, ya que le ha metido ese www delante ?

Para solucionarlo en este caso de BlogEngine edito el archivo settings.xml de la carpeta App_Data y cambio el valor de handlewwwsubdomain a remove desde el add original:

Cambio de parámetro de BlogEngine

Con esto evito que le meta la triple w delante. Para que funcione tengo qeu hacer dos cosas:

  1. Reiniciar el servicio. Lo cual se hace desde la portada con el bot´no "Restar" o "Reiniciar".
  2. Borrar la caché del navegador (o usar otro navegador diferente), ya que BlogEngine hace una redirección permanente y por lo tanto el navegador la tiene cacheada y no vuelve a enviar peticiones a la URL correcta, yendo directamente a la redirigida con la wwww incluso en el modo "privado". En el caso de Chrome llega con eliminar el historial de navegación de la última hora (periodo mínimo que permite) y las imágenes y archivos cacheados:

Borrar la caché en Chrome

Haciendo esto el blog funciona a la perfección y todo está como era de esperar:

El blog ya funcionando

Lo suyo es probarlo bien. Si es una aplicación propia puedes pasarle las pruebas unitarias si las tienes. En cualquier caso conviene navegar por él, autenticarse, y realizar las operaciones más comunes (en mi caso crear un post, editarlo, meter un comentario, etc...).

4.- Cambiar el plan de servicio

Salvo que la Web App la hayas puesto ya dentro de un plan de servicio existente, con más aplicaciones, habrás creado uno gratuito en el segundo paso para poder probar y configurar sin coste.

Ahora que ya tienes la aplicación funcionando es hora de pasarla a un plan decente, de pago, para poder escalarla y, sobre todo, poder asignarle uno o varios dominios propios (podemos meter hasta 500, que es el límite, un poco arbitrario para mi gusto pues limita el tipo de app que puedes meter y compartir).

Para ello debes ir a la sección de ajustes y elegir la opción de Scale Up que ya indica que se refiere al plan de servicio:

Escalando nuestra app

La opción de Scale Out se refiere a crear más instancias de la misma aplicación, mientras que Scale Up, que es la que nos ocupa, se refiere a cambiar las capacidades del hardware subyacente, y por lo tanto la potencia de éste y su capacidad.

OJO: fíjate que esto se refiere siempre al plan de servicio, por lo que el cambio no se aplica tan solo a la aplicación, sino a todas las aplicaciones que tengas albergadas bajo el mismo plan de servicio, que pueden ser muchas. Yo, por ejemplo, tengo todos mis blogs y webs de proyectos secundarios personales metidas dentro del mismo plan de servicio, que las aguanta de sobra a pesar del tráfico.

En mi opinión las capas más interesantes son las dos de la parte superior de la siguiente figura:

Capas de plan de servicio

La gratuita es para jugar o para sitios realmente pequeños. La compartida solo merece la pena para ponerle un nombre de dominio propio. Puede ser suficiente para aplicaciones o sitios web pequeños, y aunque no tiene SSL no es problema si usas un servicio como CloudFlare que ya se encarga de darte SSL sin que tengas que tocar Azure.

En el caso de un proyecto más o menos serio deberías asignar un plan B1 o S1 al menos. Personalmente son los que me parecen más equilibrados. Ambos tienen 1 core y 1.75 GB de RAM. Puede parecer poco si tienes costumbre de administrar una máquina Windows Server, pero ten en cuenta que eso es procesador y memoria asignados en exclusiva a las aplicaciones web que albergues, por lo que dan mucho de sí. Puedes tener varias aplicaciones con un tráfico total elevado sin problema, y llegado el caso puedes escalar, bien usando un plan mayor o, mejor aún, creando nuevas instancias del plan actual sin necesidad de hacer nada: escala de forma transparente para tu aplicación y es una de las grandes ventajas de un servicio PaaS.

Ambos planes te dejan añadir certificados SSL propios y también permiten escalar las aplicaciones añadiendo más instancias (con la opción Scale Out que hemos visto antes). La ventaja del plan S1 es que te permite hacer este escalado de manera automática. Defines unas reglas y escala solo cuando lo necesite, sin que tengas ni que tocarlo. Además el S1 te ofrece también la opción de hacer backups diarios automáticos de todas las aplicaciones y te deja crear "slots" para tener varias versiones de la aplicación funcionando (por ejemplo, un slot de producción que es el que ven los usuarios, otro de pre-producción y otro de pruebas... cosas así, y cambiar entre ellos).

IMPORTANTE: En el caso de las instancias compartidas, las D1, hay que saber que cada sitio web que cuelgues te costará ese precio que te indica (8,16€ or sitio o app web). Sin embargo en los planes reservados normales como el B1 y el S1, el precio indicado es fijo, independientemente del número de sitios o aplicaciones web que cuelgues. Mientras te aguante, puedes meter los que quieras. Por eso, en cuanto tienes 3 o 4 sitios en un plan compartido te merece la pena irte al B1 aunque no tengan mucho tráfico. Eso sí, si escalas añadiendo nuevas instancias, cada instancia se cobra a ese mismo precio. Lo bueno es que si solo necesitas escalar durante unas horas para aguantar un tráfico elevado puntual lo único que se te cobra es ese tiempo, por lo que te puede salir por unos pocos céntimos.

En resumen

Bien, hasta ahora hemos visto qué es PaaS, en qué consiste el PaaS de Azure y sus ventajas e inconvenientes. En esta entrega hemos creado nuestra primera Web App en Azure y la hemos configurado y la hemos puesto en marcha.

En la próxima entrega explicaré cómo poner a andar el servicio con su propio dominio asignado (de hecho con varios), y cómo podemos asignarle un certificado digital para SSL de modo que protejamos las comunicaciones y mejoremos el SEO entre otros beneficios.

¡Espero que te esté resultando útil!

¿Migrar tu Web app a Azure? - Caso práctico con este blog (Parte I) - Qué es PaaS y Azure Web Apps

21/03/2018
Artículo original

La verdad es que esto es algo que llevaba queriendo hacer mucho tiempo, pero que había ido dejando y dejando... Hasta ahora.

Por fin, hace unos días, saqué algo de tiempo y realicé la migración de mi blog (este que estás leyendo) a Azure. Ha sido una migración "tal cual", es decir, la misma aplicación exactamente como la tenía (en un servidor Windows con IIS), movida a una Web App de Azure, sin adaptaciones ni cambios. Además utilizo CloudFlare como DNS, proxy y sistema de seguridad, lo cual me ha facilitado todavía más el cambio, como contaré más adelante.

Nota: si no conoces Cloudflare, ya estás tardando: es un servicio increíble, con cantidad de funcionalidad y con una capa gratuita más que generosa. Desde que lo descubrí hace dos o tres años, lo uso para todos mis dominios en Internet. Y no me pagan por decirlo, que en este blog no acepto publicidad aunque en este artículo hable de dos productos de terceros ? Espero no arrepentirme en el futuro de haberlo recomendado (no creo), pero hoy por hoy soy un enamorado del servicio y de sus posibilidades.

Logo Azure Web Apps Mi intención es contar en una serie de próximos posts, empezando por el de hoy, el proceso de migración, para explicar varias cosas:

  • Qué es Azure Web Apps, ventajas e inconvenientes y si es para ti o no.
  • Cómo migré, paso a paso, este blog a Azure, de modo que te sirva si quieres instalar una aplicación ahí
  • Algunos detalles más, como por ejemplo, cómo configurar certificados SSL, cómo diagnosticar errores de tus aplicaciones, cómo hacer copias de seguridad automáticas en Azure Web Apps...

En este primer post de la serie voy a contar qué es Azure Web Apps, cuánto cuesta (si es gratis o no, vamos) y las ventajas e inconvenientes que tiene migrar tu aplicación web a este servicio.

Allá vamos...

¿Qué son los servicios PaaS? ¿Qué es Azure Web Apps?

Azure, como seguro que ya sabes, es el nombre con el que se conoce al conjunto de los servicios en la nube de Microsoft. Bajo este paraguas la empresa de Redmond ofrece todo tipo de servicios bajo demanda basados en Internet.

Azure Web Apps es un producto de Plataforma como Servicio (PaaS) dentro Azure. ¿Qué quiere decir esto? Pues, dicho de manera simple y directa, implica que va un paso más allá de tener una máquina virtual en la nube (que es lo que se conoce como IaaS, Infraestructura como servicio) para aislarte por completo de lo que hay debajo ejecutando tu aplicación. En una máquina virtual debes instalar el sistema operativo, el servidor web, administrar ambos, instalar tus aplicaciones, establecer permisos, hacer copias de seguridad... Y todo esto para empezar a funcionar. Si luego la aplicación crece y tiene mucho tráfico quizá debas escalarla y para ello debes instalar más máquinas y repetir el proceso, manteniéndolas sincronizadas, etc... Es decir, IaaS simplemente te evita los posibles problemas derivados del hardware, pero todo lo demás "te lo comes" tú.

Un servicio PaaS como Azure Web Apps, te aísla de todo eso. Tú simplemente das de alta el servicio, indicas qué quieres ejecutar en él, y (en este caso) Azure se ocupa de todo lo demás. En lo que a ti respecta, no existe sistema operativo debajo (Windows, Linux...), ni servidor web (IIS, NGinx, Apache...), ni actualizaciones,, ni configuración de red, ni virus, etc... Te tienes que preocupar tan solo de tu aplicación. De lo demás te olvidas. Y esto es una grandísima ventaja.

Aunque mucha gente lo sigue asociando únicamente con Windows y con .NET, en función de tus preferencias, Azure Web Apps puede estar ejecutando por debajo Windows Server o Linux en versiones de 32 o de 64 bits, y también ejecuta aplicaciones con multitud de lenguajes y plataformas de programación (.NET, PHP, Java, ASP Clásico, Node.js, Python...). Olvídate del viejo binomio Microsoft = Solo tecnologías de Microsoft.

También puedes instalar y configurar automáticamente muchas aplicaciones ya hechas, como gestores de contenidos como WordPress, Joomla o Drupal, comercio electrónico, foros, CRMs... Es decir, ni siquiera tiene qu ser una aplicación tuya.

Pero, espera... ¿En que se diferencia esto de un hosting de los de toda la vida? En un hosting te dan un espacio de almacenamiento y tú subes por FTP los archivos de tu aplicación y te olvidas ¿no?

Sí, pero es que una PaaS te da mucho más que eso. Por citar algunas cosas más:

  • Muchas más opciones de despliegue e integración continua. Por ejemplo, puedes desplegar automáticamente a la nube cada vez que hagas un commit en una rama determinada de tu repositorio de código Git, o desplegar desde Dropbox, a través de FTP (obviamente), entre otras muchas opciones.
  • Escalabilidad: si de repente tu aplicación crece mucho en usuarios o tráfico, incluso aunque solo sea durante un par de días por algún acontecimiento concreto, puedes escalarla lo que necesites para atender a la nueva demanda, simplemente dándole a un botón o incluso de manera automática, sin que tengas ni que ocuparte tú. No hay balanceadores de carga que mantener, almacenamiento que sincronizar, etc...
  • Slots de trabajo: puedes tener diversos slots para la aplicación, por ejemplo: uno de producción que es el que está de cara al exterior, uno para pruebas internas y otro para actualizaciones, y utilizarlos todos de manera independiente y cambiar instantáneamente de uno a otro. Incluso puedes crear slots de pruebas que salen a producción solo para una fracción reducida de tu tráfico, de modo que puedas probarlo con usuarios reales sin arriesgarte a cambiar la aplicación entera.
  • Instrumentación: para saber exactamente cómo está funcionando tu aplicación, qué fallos hay, cómo responde, la memoria que usa, etc... Es posible incluso hacer pruebas de carga automatizadas de la aplicación, simulando cientos de usuarios simultáneos desde diferentes partes del mundo para ver cómo responde.
  • CDN: si haces uso de esta funcionalidad tus recursos se distribuyen mundialmente y se sirven a tus usuarios desde la ubicación más cercana que de la forma más rápida posible (que conste que yo, para esto, uso Cloudflare y no Azure).

Por no mencionar que en Azure Web Apps y servicios PaaS similares, tienes reservado para tu uso exclusivo la memoria y CPU que hayas contratado y no la compartes con otros cientos de clientes, como sí suele ocurrir en los hosting (sobre todo si son baratos), por lo que el rendimiento está asegurado. También tienes copias de seguridad automáticas, posibilidad de administrarlo todo desde la línea de comandos.

Me has convencido. ¿Cuánto cuesta esto?

Azure Web Apps te permite crear hasta 10 Web Apps de manera gratuita. Sin embargo con muchas limitaciones y sin poder usar siquiera un dominio propio para las mismas. Están pensadas para que puedas probar el servicio o montes webs personales sin grandes pretensiones. Si quieres hacer algo en serio tiene que contratar una versión de pago.

La más económica, con recursos compartido con otros clientes, 4 horas al mes de uso de CPU (que da para más de lo que parece), pero con dominio propio y con posibilidad de instalar hasta 100 aplicaciones, cuesta unos 8€ al mes.

Si quieres ir a algo serio, con recursos reservados, SSL propio, ilimitadas aplicaciones y que pueda escalar, el precio sube hacia el rango de los 40€ mensuales. Eso sí, obtienes la mayor parte de las ventajas que comentaba en el apartado anterior. De hecho existen algunas capas de precios muchísimo más caras, pero pensadas para servicios muy grandes. Tienes los detalles aquí. Más adelante veremos con más detalle los precios y algunos consejos para ahorrar.

Quiero recalcar algo muy importante que debes tener en cuenta: esos precios no son por aplicación, sino por unos recursos subyacentes determinados. Es decir, que si contratas por ejemplo un plan B1 que cuesta unos 47€ al mes, puedes meter en él tantas aplicaciones y dominios como quieras mientras te aguante el servicio (y aguanta mucho), por lo que el coste se divide entre todas ellas. También ten en cuenta que el servicio se factura por minutos, por lo que puedes ampliarlo o reducirlo según necesitas (por ejemplo, durante picos) y puedes tener una capa súper-potente durante unas horas por unos pocos euros, volviendo a una más barata cuando ya no la necesites.

Es decir, no es caro (al menos no prohibitivo), pero no es para todo el mundo tampoco.

Y entonces ¿qué hago? ¿Qué me recomiendas?

Mi consejo sería:

  • Si tu sitio web es estático (o sea, no es una aplicación realmente sino un conjunto de HTML, CSS y JavaScript) y no tiene una cantidad exagerada de tráfico ni necesidades avanzadas, albérgalo gratuitamente en GitHub Pages o en Firebase y olvídate.
  • Si es una aplicación web estilo Wordpress o algo hecho a medida, pero tiene poco tráfico y no te preocupa en exceso el tiempo de respuesta, un hosting tradicional puede irte bien. Dependiendo de la calidad del proveedor de hosting (y el precio) puedes de hecho conseguir resultados excelentes.
  • Si se trata de una app que ya tiene (o esperas que tenga) bastante tráfico, que puede tener picos puntuales de demanda, que retocas o cambias a menudo, en la que te importa el rendimiento y tiempos de respuesta y sobre la que quieres tener un buen control pero sin tener que administrar sistemas, un servicio PaaS como Azure Web Apps es lo que estás buscando, y amortizarás el coste desde el primer momento aunque solo sea por la tranquilidad que te proporciona.

¿Más pegas que se te ocurran?

Aparte del coste existen otras desventajas, que no todo el monte es orégano...

Por ejemplo, existe un máximo de espacio de almacenamiento disponible a compartir entre todas tus Apps. De hecho el máximo son 250GB (o 1TB en un tier especial, a precios exorbitados). El motivo es que, en realidad, el espacio de almacenamiento debería ser solo para los archivos de tu app, no para los que va generando su uso. Aunque por supuesto puedes hacerlo siempre que no sobrepasen ese espacio disponible. La idea es que utilices la API para los servicios de almacenamiento de Azure y almacenes los archivos generados por tus usuarios en un Blob, de ahí esa cierta limitación de espacio. No obstante muchas aplicaciones ya hechas y no pensadas específicamente para usar el almacenamiento de Azure deben utilizar el almacenamiento disponible en la Web App (lo que ven libre en disco, vamos), y en ciertos tipos de aplicaciones esto puede suponer una limitación. Piensa, por ejemplo, en un servicio de almacenamiento de fotos de tus usuarios: no te serviría si no lo integras con blobs de Azure Storage, que por otra parte sería lo más recomendable.

En mi opinión Microsoft harían felices a muchos usuarios y conseguirían más clientes para el producto si añadiesen la capacidad de agregar un Blob de Azure a la Web App que se viera como una unidad local, de manera transparente para la aplicación. Solo con esto aumentaría de manera brutal la capacidad de trabajar con aplicaciones "legacy". Pero de momento es solo un sueño recurrente que tengo ?

Otro posible problema es que, aunque es posible desplegar aplicaciones .NET, Java, PHP, Node.js, Python, ASP clásico... no vale para todas las aplicaciones ya que, por ejemplo, no puedes instalar componentes COM/ActiveX antiguos que debas utilizar.

Además como se ejecutan en un "Sandbox" para aislar las aplicaciones unas de otras, hay cosas que no se pueden hacer, como por ejemplo escribir en el registro (en el caso de Windows), acceder al log de eventos mediante código, crear links simbólicos en el disco o, por citar algo muy común, generar PDFs con ciertos componentes que hacen uso por debajo de IE y GDI32. Aquí tienes una lista completa de limitaciones.

Por decirlo de manera rápida: funcionarán de maravilla con aplicaciones relativamente modernas que no hagan "cosas raras". Pero si debes usarlos con aplicaciones "legacy" que hagan uso de componentes COM, fuera de proceso o que debas registrar, o que usen APIs de muy bajo nivel que supongan un problema de seguridad, entonces olvídate y vete a máquinas virtuales (porque en un hosting tampoco vas a poder ejecutarlas de todos modos).

En resumen

Azure Web Apps es una excelente elección si quieres una plataforma robusta en la que ejecutar tus aplicaciones Web, sin preocuparte por administrar sistemas, pudiendo escalar automáticamente y con muchas otras ventajas que te he contado más arriba.

Ahora bien, si tu sitio es pequeño, con poco trafico y sin grandes pretensiones, probablemente no te compensará el coste que tienen. Tampoco te valdrán si la aplicación o aplicaciones que quieres usar es muy antigua y depende de componentes de terceros (especialmente COM/ActiveX) que debas instalar.

Pero si la aplicación es relativamente moderna y no hace nada "extraño" y necesitas obtener rendimiento, escalabilidad, facilidad de despliegue, "slots" para pruebas, etc... te encantarán y elevarán el nivel de tus aplicaciones.

Espero que esta introducción a PaaS con Azure Web Apps te haya resultado interesante. En cuanto pueda seguiré con la serie y en el siguiente post contaré, paso a paso, el proceso de migración de mi blog de un servidor Windows con IIS a Azure Web Apps.

¡Hasta pronto!

Java: cómo comprobar si existe o no un archivo o una carpeta en el disco duro

21/03/2018
Artículo original

Hoy un truco rápido y muy sencillo para Java pero que hemos visto que mucha gente necesita.

En cualquier aplicación, en muchas ocasiones, necesitaremos leer o escribir un archivo desde el disco duro. Aunque si intentamos leer un archivo que no existe se producirá una excepción que podemos gestionar, puede ser muy útil comprobar primero su existencia. También al escribirlo, ya que, aunque existen maneras de sobrescribir uno existente, quizá queramos comprobarlo para hacer una copia antes de escribir por encima o cualquier otra casuística similar.

Por suerte, nada más fácil de conseguir en la plataforma Java gracias a la clase File del paquete estándar java.io.

Esta clase dispone de un método exists() que, como su propio nombre indica, nos permite averiguar si un elemento existe o no.

Por ejemplo:

File archivo = new File("configuracion.json");
if (!archivo.exists()) {
    System.out.println("OJO: ¡¡No existe el archivo de configuración!!");
}

Así de sencillo.

Este código funciona exactamente igual con un archivo o con una carpeta ya que, a pesar de su nombre, la clase File sirve para manejar ambos tipos de elementos.

En caso de que exista o no exista un recurso en disco, si queremos distinguir el caso de que sea una carpeta o un archivo podemos utilizar los métodos isFile() o isDirectory() para comprobar de qué se trata. Por ejemplo:

File archivo = new File("configuracion");
if (archivo.exists()) {
    if (archivo.isFile()) System.out.println("Es un archivo");
    if (archivo.isDirectory()) System.out.println("Es una carpeta");
}
else {
    System.out.println("OJO: ¡¡No existe el archivo de configuración!!");
}

Es un código muy tonto, pero sirve para demostrar la idea.

La clase File dispone de multitud de métodos para ayudarnos a gestionar archivos y carpetas en cualquier sistema operativo y para averiguar información sobre ellos.

Lo dicho: lo de hoy ha sido rápido, sencillo y (esperamos que) útil ?

GAMBADAS: Los relojes europeos se han retrasado 6 minutos desde enero debido a Serbia y Kosovo

21/03/2018
Artículo original

Esto parece una broma de conspiranoicos, pero es muy real. ¿Has notado que tu despertador o el reloj del horno han ido atrasando poco a poco últimamente? Pues le ha pasado a mucha más gente.

Los relojes digitales más comunes, de pared o de muñeca, llevan una pila y utilizan un cristal de cuarzo para mantener la hora. El cristal vibra a una determinada frecuencia constante cuando lo atraviesa la corriente y eso es lo que usan los relojes para medir el tiempo.

Sin embargo, los relojes típicos que puedes encontrar en un horno o en los despertadores que van directamente enchufados a la red eléctrica utilizan un método diferente. Como sabrás, la corriente eléctrica que llega a los enchufes es corriente alterna, es decir, cambia de signo varias veces por segundo. Esto ahorra en el transporte de la electricidad a larga distancia y aumenta la eficiencia. En Europa la frecuencia de oscilación es de 50Hz, es decir, la corriente cambia de signo 50 veces cada segundo, y esto se mantiene constante. Los relojes enchufados utilizan este hecho para medir el tiempo, ya que saben que cada 50 cambios de polaridad de la corriente ha pasado un segundo. Esta medida es bastante fiable casi siempre.

Sin embargo hay más factores a tener en cuenta en esta historia. La red eléctrica europea está muy interconectada, de modo que cuando un sitio necesita más energía, esta necesidad puede ser atendida por electricidad generada en un país diferente, a miles de kilómetros de distancia. En la actualidad forman parte de esta red continental 26 países, incluyendo a Turquía o a Suiza, que no forman parte de la comunidad económica (puedes ver un mapa bastante detallado en PDF aquí que podrás ampliar como necesites para ver el detalle):

Bien. Esta red eléctrica "global" actúa como un conjunto de vasos comunicantes: para mantenerla estable el consumo que existe se debe corresponder aproximadamente con la producción. Es decir, si se consume más se debe producir más en toda la red y viceversa. Esto es necesario porque si baja el consumo aumentaría la frecuencia de la corriente, y si sube bajaría dicha frecuencia.

Generalmente esta frecuencia se mantiene dentro de unos límites muy estrictos (el mínimo admitido es de 47,6Hz y el máximo es de 52,5Hz) y de hecho existen dos entidades que se dedican a vigilarlo y ajustarlo en función de los datos, una en Suiza y otra en Alemania. Incluso podemos consultar en tiempo real el estado de la frecuencia de la red eléctrica europea:

Todo esto es muy interesante. Pero luego viene la realidad a fastidiar las cosas, y es que si no hay datos fiables, las cosas se pueden descompensar.

Lo que ha estado ocurriendo es que Serbia y Kosovo han tenido una disputa (otra) sobre el consumo de energía que se ha transferido entre sus dos redes. Debido a esta discrepancia en los datos hay nada menos que 113KWh que han desaparecido. No se han registrado convenientemente y no se sabe qué ha pasado con ellos (yo digo, tú dices y nadie sabe qué ha ocurrido realmente).  Para que te hagas una idea, esto es equivalente a la electricidad que consumen anualmente 10.000 hogares ?

Como se ha contabilizado mal el consumo y la producción, se ha descompensado ligeramente toda la red eléctrica europea, esto ha hecho que, aunque supuestamente la red estaba a 50Hz, en realidad haya estado durante varios meses a 49,996Hz. Algo muy pequeño como para hacer saltar las alarmas pero suficiente para que los relojes que dependen de esta frecuencia hayan atrasado en total unos 6 minutos desde enero hasta finales de la semana pasada.

Aún no se sabe a dónde ha ido esa energía ni quién es el responsable (Serbia y Kosovo siguen discutiendo el tema) pero parece ser que ya se ha solucionado y que van a aumentar ligeramente la frecuencia un tiempo para que los relojes que no son fáciles de ajustar manualmente (y no, no nos referimos a tu despertador). Por lo tanto si ajustas ahora tus relojes, dentro de unos meses van a estar adelantados y tendrás que ajustarlos otra vez  cuando la frecuencia vuelva a ser 50Hz exactamente. Lo mejor, de todos modos, es utilizar un reloj digital que no esté afectado por estas cuestiones.

Una vez más se evidencia cómo la dependencia que tenemos de la tecnología, incluso de tecnologías tan antiguas como la electricidad, nos puede impactar de manera directa.

Esperemos que no vuelva a ocurrir.

Y tú ¿has usado ya este fenómeno para justificar esos minutillos que llegas tarde a una cita? ?

Página Anterior Página Siguiente