Cómo abrir archivos .rdlc con Visual Studio 2017

17/10/2018
Artículo original

RDLC es el acrónimo de Report Definition Language Client-side, o Lenguaje de Definición de Informes de lado Cliente. Los archivos con extensión .rdlc son archivos de informes creados por Visual Studio y se trata de archivos de texto que contienen XML con la definición del informe. Gracias a estos archivos y a los visores de informes para Windows Forms y Web Forms era muy sencillo crear y desplegar informes en nuestras aplicaciones.

Antiguamente, a partir de Visual Studio 2005, se incluía de serie con Visual Studio un diseñador para este tipo de informes, pero posteriormente, desde VS2013, se dejó de incluir por defecto este diseñador. En VS2013 y VS2015 llegaba con editar la instalación de Visual Studio y elegir la opción de instalar las herramientas de datos de SQL Server (que no se instalaban por defecto) para volver a tenerlo disponible. Sin embargo en Visual Studio 2017 no viene incluido en el paquete de manera alguna.

Es por esto que si abres con Visual Studio 2017 un proyecto que incluya archivos .rdlc lo único que verás será el contenido XML del archivo, lo cual puede ser suficiente para pequeños retoques (son fáciles de seguir) pero es arriesgado y poco práctico.

Por suerte es muy fácil de solucionar puesto que ahora es posible acceder a esta funcionalidad utilizando una extensión.

Vete al menú de Herramientas·Extensiones y actualizaciones, y una vez allí busca la palabra "RDLC" en el directorio de extensiones online:

Le das a la opción de descargar, la cual te informará de que se ejecutará una vez cierres todas las ventanas de Visual Studio. Así que cierra Visual Studio (en fin...) y deja que te salte el diálogo de instalación:

Pulsa el botón Modificar y empezará la instalación:

Una vez terminada ya puedes arrancar de nuevo Visual Studio e intentar abrir el diseño de informe:

Si el .rdlc original está creado con una versión antigua de Visual Studio (por ejemplo con VS2010), la primera vez que lo abras te dirá que lo va a actualizar a la última versión, y te creará una copia de seguridad del original en el mismo sitio (no la verás en el explorador de archivos, pero está en el disco duro en la misma carpeta, con el mismo nombre y el sufijo "Backup").

Es posible que una vez lo abras y le modifiques algo, cuando lo intentes guardar de nuevo te salga este mensaje de error: "Unknown Report Version: 9.0" o "Versión de informe desconocida: 9.0":

Esto es porque realmente no actualiza el archivo cuando lo abres y lo intenta guardar en una versión incorrecta (porque las referencias que tiene el proyecto son a una versión antigua del ensamblado de informes). En cualquier caso es fácil de solucionar: Cierra el proyecto o abre una nueva instancia de Visual Studio sin ningún proyecto abierto. Ahora arrastra el informe .rdlc que quieras convertir desde el explorador de archivos directamente sobre Visual Studio. Te preguntara si quieres convertirlo, cosa que hará. Graba y ya quedará bien y lo podrás abrir, editar y grabar sin problema desde tu proyecto. Si tienes muchos informes para convertir es un "peñazo" hacerlo así, pero tampoco tardarás tanto.

¡Espero que te resulte útil!

Estilos CSS para imprimir: pautas básicas y ejemplos

17/10/2018
Artículo original

Los estilos específicos para imprimir muchas veces son los grandes olvidados, ya no solo a la hora de maquetar una web, si no incluso por los propios desarrolladores de navegadores.

Si nunca has trabajado con ellos, probablemente las primeras veces te encuentres con algún dolor de cabeza. Realmente no es que sea muy difícil si lo planificamos bien, aprovechando los estilos CSS generales y dándole un poco de cariño a los estilos para impresión con unas pocas reglas, podemos ganar muchos puntos a los ojos de nuestros usuarios.

Tanto si estás dando tus primeros pasos aprendiendo HTML y CSS , como si eres un experto en frontend, te recomiendo que los tengas presentes desde el principio en cada web que desarrolles, ya que es una práctica muy recomendable.

Como siempre, antes de nada es conveniente ponerse en el lugar del usuario (o mejor aún, preguntarle) y pensar: ¿Para qué podría querer yo imprimir esta página? ¿Qué es lo realmente importante dentro del contenido?

Pueden ser muchos casos: Desde un post de un blog que queremos usar como referencia, pasando por una receta que queremos tener a mano, el localizador de una reserva, el recibo de una compra de un electrodoméstico... Hay muchas posibilidades.

Cómo añadir estilos CSS específicos para impresión

Generalmente los añadiremos en una hoja de estilos externa específica con el atributo media="print". Si tenemos una hoja de estilos principal externa, normalmente estos estilos también se aplican en el momento de imprimir, si al enlazarla le hemos aplicado el atributo media="all":

<link rel="stylesheet" type="text/css" href="https://www.campusmvp.es/recursos/estilos.css" media="all" />
<link rel="stylesheet" type="text/css" href="https://www.campusmvp.es/recursos/estilos-impresion.css" media="print" />

Si no hemos especificado un atributo "media" en la hoja de estilos general, también se aplicarán a la hora de imprimir. Por cierto, vigila los tiempos de carga de de la hoja para impresión, puedes llegar a encontrarte sorpresas:

<link rel="stylesheet" type="text/css" href="https://www.campusmvp.es/recursos/estilos.css" />
<link rel="stylesheet" type="text/css" href="https://www.campusmvp.es/recursos/estilos-impresion.css" media="print" />

Bueno, en realidad no se aplican siempre todos los estilos, porque los navegadores suelen encargarse de eliminar algunos detalles accesorios, como colores e imágenes de fondo. Eso sí, suelen dejar elegir esto al usuario en las opciones de impresión, aunque si te interesa mucho, se podría llegar a forzar su impresión.

Si tenemos muy pocas reglas o si, por lo que sea, preferimos tenerlo todo junto en un solo archivo CSS, también podemos usar una media query dentro de nuestra hoja de estilos general en vez de usar una hoja de estilos específica de impresión:

@media print {
    /* Aquí irían tus reglas CSS específicas para imprimir */
}    

O también está la posibilidad de introducirlos como estilos en bloque en el <head> del documento:

<style type="text/css" media="print">
       /* Aquí irían tus reglas CSS específicas para imprimir */
</style>

Eso sí, recuerda, si hay alguna hoja de estilos que la quieras usar solo para dispositivos de pantalla deberás usar media="screen", o dentro de la hoja de estilos, @media screen.

Ejemplos, pautas y buenas prácticas en la CSS para impresión

Eliminar contenido poco importante o accesorio

Columnas laterales, anuncios, formularios auxiliares (como el buscador), menús... Hay muchos elementos que carecen totalmente de sentido al imprimir una web. Aprovéchalo para simplificar al máximo, ya que eso también te facilitará las cosas.

<style media="print">
     #sidebar {
        display:none;
     }          
</style>        

Asegúrate de usar display:none; para sacar el elemento del flujo, si usas visibility:hidden; el elemento no se verá pero seguirá ocupando espacio. También es posible que tengas que forzar un poquito la especificidad de tus reglas, incluso teniendo que recurrir a la directiva !important. Claro que, si esto último puedes evitarlo mucho mejor.

Ajustar el contenido que nos queda

Al eliminar elementos superfluos como el sidebar, es posible que el método que hemos usado para componer nuestra web pierda todo el sentido y sea necesario hacer ajustes. Por ejemplo, un caso habitual son los floats. Si has flotado contenedores, es posible que necesites "desflotarlos".

main {
    float:none;
}        

Revisa también los sitios en los que estés usando Flexbox o CSS Grid. En este caso quizá necesites cambiarlos a display:block;.

Nota: hace poco me encontré un caso particular. Quizá cuando lo leas ya esté solucionado, pero en el momento de redactar este post, cuando el contenido está envuelto en un contenedor con display:flex, Firefox es incapaz de generar más de una página de contenido en la vista de impresión. Para solucionarlo deberás aplicarle un display:block a ese contenedor. Si te sigue ocurriendo este problema, aplícalo sistemáticamente a todos los display:flex; hasta que des con el culpable.

Otro punto a tener en cuenta: los elementos con position:relative; o position:absolute; a veces también son fuente de problemas. Tenlo en cuenta si ves que se te descoloca algo de manera flagrante.

Usa medidas absolutas

El tamaño del papel es fijo, puedes usar medidas absolutas como cm, mm, pt o incluso pulgadas.

Si prefieren seguir usando un layout fluido, aquí también puedes usar media queries, especialmente unas tan útiles como las de orientación, que sirven tanto para el viewport como para elementos paginados:

@media print and (orientation: portrait) {
    /* Reglas para imprimir en formato vertical */
}
    
@media print and (orientation: landscape) {
    /* Reglas para imprimir en formato apaisado */
}                               

Texto, colores e imágenes de fondo

Como el navegador elimina los colores e imágenes de fondo, es posible que el color de tu texto pueda flaquear en su contraste con el fondo. Revisa este punto y valora la posibilidad de cambiar todo el texto a negro. Tendrás mejor contraste y los cartuchos de la impresora de tu usuario te lo agradecerán.

Ya puestos, te puede interesar redefinir el tamaño del texto base a pt ya que es una medida absoluta más habitual para la impresión de documentos y tendrás mayor control.

Revisa también si hay alguna imagen importante en el contenido que hayas introducido como imagen de fondo (¡mal hecho!). Otra potenciales fuentes de problemas pueden ser sombras CSS del tipo box-shadow o text-shadow.

Para empezar con buen pie, te recomiendo echarle un vistazo a HTML5 boilerplate, especialmente al reset específico para estilos de impresión.

Convertir los Enlaces para mostrar la URL usando solo CSS

Obviamente sobre un papel impreso no funcionan los enlaces. Así que, si crees que es importante la URL del enlace para el contenido del documento, puedes elegir mostrarla sin tener que tocar el HTML, solo usando CSS.

Para ello nos podremos valer de contenido generado a través de CSS con la propiedad content y el pseudoelemento ::after:

a[href]:after {
    content: " (" attr(href) ")";
}        

Asimismo, te podría interesar no mostrar los enlaces internos, esto podríamos hacerlo con la pseudoclase :not de esta forma (pon tu dominio en lugar de campusmvp.es):

a[href^="http"]:not([href*="campusmvp.es"]):after {
    content: " (" attr(href) ")";
}        

Debugueando estilos para print: Herramientas para desarrolladores

Si estás acostumbrado a debuguear webs con las herramientas del desarrollador de turno, es posible que al intentar arreglar algún problema grave en la vista de impresión te sientas un poco maniatado.

En Chrome se puede emular la vista de impresión, y, aunque no es del todo exacto, resulta de bastante ayuda para investigar posibles problemas. Búscalo en la pestaña "Rendering" :

En Firefox no parece que haya una forma de emularlo directamente ahora mismo (o yo no he sido capaz de encontrarlo). Para versiones anteriores a Firefox 62, se podía ejecutar en la developers toolbar (May + F2) el comando media emulate print. Pero desde la versión 62 esta posibilidad se ha esfumado y de momento no hay una alternativa directa. A pesar de que se supone que la consola normal sustituye a esta barra, el comando media no está implementado.

Lo que sí podemos hacer es, en la vista previa de Firefox, clic derecho > inspeccionar elemento. La herramientas para desarrolladores de Firefox usadas sobre la vista previa de impresión no va tan fina como en la vista de pantalla. De hecho, a veces no es capaz de aplicar cambios o incluso se bloquea, pero sigue siendo útil para localizar qué elemento es el que te está descolocando todo.

Y si nada de esto te sirve, prueba a cambiar directamente el media de tus estilos de impresión para verlos aplicados en pantalla. No será exactamente lo mismo, pero menos da una piedra.

Otra técnica oldschool que puedes usar es empezar a colocar bordes artificiales de distintos colores a tus elementos para entender cómo se están posicionando. Y es que, no te lo creerás, pero los más talluditos conocimos una época en la web en que no existían las herramientas para desarrolladores y tirábamos de cosas así...

Técnicas avanzadas

Hasta aquí más o menos todo normal ¿no? Pues hay más, solo que, en este post, por cuestiones de espacio, no podremos profundizar todo lo que nos gustaría.

Por ejemplo, puedes controlar la página usando la regla @page. La especificación CSS Paged Media Module aún está en borrador, pero ya se pueden hacer muchas cosas con ella.

Aunque le veas esa "@" delante a @page, se usa como un selector normal:

@media print {
    @page {
        margin:2cm;
    {
}                        

 @page dispone de su propio modelo de caja, pero la particularidad más interesante es que se divide en 16 áreas que funcionan como pseudoelementos que pueden albergar contenido generado por CSS, algo similar a como funcionan ::before y ::after, pero a lo grande:

Modelo de caja de @page

Pseudoelementos de @page

Esto está pensado así para albergar títulos, numeración de páginas y capítulos, notas al pie de página, aclaraciones en los márgenes, etc... Vamos, como si fuese un libro.

Es un tema muy, muy interesante. Si quieres empezar a profundizar, en este post de Kseso se hace una muy buena introducción a la regla @page.

Saltos de página

En una web, una página puede ser todo lo alta que necesitemos, pero las páginas de papel son finitas, lo que puede provocar saltos de página indeseados. Para controlar esto disponemos de 5 propiedades muy útiles, aunque te recomiendo que consultes siempre su implementación en navegadores, ya que puede haber inconsistencias.

Generalmente tienen la estructura page-break-*, pero ojo, que vienen heredadas de CSS2 y, en lo que respecta a la especificación, son más recientes los elementos con la estructuras break-, definidos por el módulo de Fragmentación con CSS, y que están pensados para usar en más sitios que la impresión, como la multicolumna.

Por razones prácticas, en este post veremos los antiguos que, dentro de lo que cabe, tienen mejor soporte:

page-break-before

Con page-break-before podemos forzar (o impedir) que se produzca un salto de página antes de un elemento concreto. ¿Para que querríamos esto? Pues para que este elemento aparezca siempre al principio de una página, por ejemplo:

article {
    page-break-before: always;
}

page-break-after

Con page-break-after podemos forzar (o impedir) que se produzca un salto de página después de un elemento concreto:

h2 {
    page-break-after: always;
}

page-break-inside

page-break-inside es muy útil para evitar que un elemento se parta entre dos páginas.

div {
    page-break-inside: avoid;
}

Líneas huérfanas y viudas: orphans y widows

Las líneas huérfanas y viudas son un concepto tipográfico para referirse a las líneas que quedan descolgadas del párrafo al que pertenecen debido a un cambio de página o columna, ya sea al principio (huérfanas) o al final de este (viudas).

La buena práctica más comúnmente aceptada en estos casos es que no debe quedar una sola línea descolgada, debe haber un mínimo de dos. El software de autoedición (tipo Adobe InDesign®) y los procesadores de texto suelen tener herramientas para gestionar estos casos.

En CSS para impresión también podemos controlar la cantidad de líneas con las propiedades widows y orphans, y de hecho el valor por defecto para ambas propiedades es 2, aunque lo podemos cambiar :

p {
    widows:3;
    orphans:3;
}

En conclusión

Como puedes ver, si nos metemos a fondo, el CSS para impresión tiene más miga de que probablemente te podrías esperar. Pero si lo tienes presente desde el principio y no tienens necesidades especiales, tampoco deberían ser un problema demasiado grande poder presentar el contenido importante de una forma digna y útil para poder imprimirse.

Si crees que me he dejado algo importante, tienes alguna duda o sugerencia, ya sabes, tienes los comentarios a tu disposición.

Análisis y Visualización Básica de una Red Social de Twitter con Gephi

16/10/2018
Artículo original

Este artículo es el resultado de un ejercicio para la asignatura Minería de Medios Sociales en el máster en Ciencia de Datos de la UGR

Análisis de la red

Esta red contiene un subconjunto de los seguidores de la cuenta @elbaulp de Twitter, ya que por limitaciones de la API la descarga de la red de hasta segundo grado de conexión tardaba mucho.

El objetivo de este análisis es identificar a los actores más influyentes, que hacen de puente entre comunidades para poder expandir el número de seguidores de @ElbaulP

Grado medio

  • N = 2132 nodos.
  • L = 6643 enlaces
  • Densidad = 0.001
  • Grado medio = 3.116, lo cual quiere decir que cada nodo de la red está conectado con otros 3 en media.

A continuación se muestran las gráficas de densidades de los grados.

En cuanto a grados totales, hay cuatro nodos que destacan, con un grado de mayor a 120. El nodo con mayor grado es de 161. Estos nodos se corresponden con hubs. La distribución de grados indica que se cumple la propiedad libre de escala. Muy pocos con muchas conexiones, y muchos con pocas conexiones.

Los nodos con mayor grado de entrada (Con mayor número de seguidores) tienen 120 y 160 seguidores, respectivamente.

Pasa absolutamente lo mismo para los grados de entrada y salida, en el caso de Twitter esto indica seguidores y seguidos. El usuario con más amigos tiene unos 99 amigos.

Diámetro

El diámetro de la red es de 13. Este valor representa la máxima distancia existente entre dos nodos en toda la red. La distancia media es de 4.5.

El histograma de distancias es el siguiente:

El diagrama de cercanía nos indica que hay bastantes nodos muy alejados del centro (entorno a unos 90). Otros, por contra, están muy situados en el centro de la red (unos 85). El resto de nodos se situan a los alrededores del centro de la red.

Conectividad

Se tienen 845 componentes conexas, la componente gigante agrupa 1261 nodos. El coeficiente de clustering medio es 0.068. En este caso es bajo, ya que la cuenta de twitter es de un blog, en lugar de una cuenta personal. El histograma CC es el siguiente:

Lo cual indica que en regiones poco pobladas el coeficiente de clustering es muy alto, ya que los nodos están más conectados entre ellos localmente. Por ello destaca un punto muy alto al principio de la gráfica.

Centralidad de los actores

Los cinco primeros actores para las siguientes medidas son:

Centralidad de Grado Intermediación Cercanía Vector propio
nixcraft: 161 rootjaeger: 0.048 programador4web: 1 Makova_: 1
Makova_: 151 podcastlinux: 0.048 KevinhoMorales: 1 psicobyte_: 0.966
cenatic: 132 Linuxneitor: 0.043 elrne: 1 Terceranexus6: 0.908
Terceranexus6: 129 Makova_: 0.039 Mrcoo16: 1 NuriaStatgirl: 0.796
LignuxSocial: 121 Wdesarrollador: 0.038 RodriKing14: 1 Inter_ferencias: 0.780

En cuanto a la centralidad de grado, no se tiene muy en cuenta, aunque refleja el número de conexiones de un actor, no tiene en cuenta la estructura global de la red.

Una medida bastante importante es la intermediación, estos actores hacen de puente entre otras regiones de la red. Por lo cual pueden conectar distintas comunidades entre sí. En el caso que nos ocupa (Twitter), si conseguimos que uno de estos actores nos mencione o nos haga RT, nuestro tweet podrá llegar a otro tipo de usuarios que quizá estén interesados en nuestras ideas.

La cercanía mide cómo de cerca está un actor del centro de la red. En este caso no nos sirve de mucho, ya que todos los nodos tienen la misma medida.

Por último, la centralidad de vector propio es una medida recursiva que asigna importancia a un nodo en función de la importancia de sus vecinos. Es decir, tiene en cuenta la calidad de las conexiones, en lugar de la cantidad. El primer actor tiene un valor de esta medida de 1, lo cual indica que es el nodo más importante y con el mayor número de conexiones importantes. Luego es un actor a tener en cuenta en la red.

Detección de comunidades

Para la detección de comunidades se ha usado un factor de resolución de 1.99 para obtener un total de 5 comunidades. Se ha elegido este valor de resolución debido a que valores inferiores resultaban en un mayor número de comunidades, pero muchas de ellas formadas por dos nodos. El valor para la modularidad es de un 0.436, lo cual es un buen valor.

La proporción de nodos en cada comunidad es la siguiente:

  • 40.85%
  • 21.39%
  • 17.5%
  • 10.98%
  • 9.15%
  • 0.14%

La distribución de modularidad se observa en la siguiente imagen:

Todas tienen un tamaño razonable salvo una, demasiado pequeña.

La siguiente imagen muestra el grafo coloreado en función de a qué comunidad pertenece cada nodo:

Analizando la red, se puede apreciar que la comunidad de arriba (Azul celeste) pertenece a nodos relacionados con la ETSIIT. Algunos miembros de esta comunidad hacen de puente (Son nodos con mucha intermediación) con otras comunidades. Por ejemplo, Makova_ y Linuxneitor hacen de puente con la comunidad morada, esta comunidad está más relacionada con usuarios de Linux y blogs de Linux. NataliaDiazRodrz hace de puente de la comunidad de la ETSIIT con la comunidad verde, más relacionada con la temática de Ciencia de Datos. Esto tiene sentido, ya que NataliaDiazRodrz estudió en la ETSIIT y trabaja en Ciencia de Datos, concretamente en temas de NLP. La comunidad Amarilla está relacionada con programación.

Gráficos adicionales

En la siguiente gráfica se muestra la red dispuesta con los colores en función del valor del vector propio, y el tamaño de los nodos como la intermediación:

En la siguiente figura se muestra a la inversa, color la intermediación, tamaño el vector propio:

Considero que las medidas más importantes son el valor de vector propio y la intermediación, la siguiente gráfica muestra cómo están relacionadas entre ellas. A mayor valor para ambas mejor, más importante es el nodo:

Los beneficios de utilizar Docker y contenedores a la hora de programar

09/10/2018
Artículo original

El desarrollo con instancias de Docker está cada vez más extendido entre los equipos de desarrollo de software porque simplifica el proceso de programación, despliegue y entrega de aplicaciones.

Docker es una de las palabras más de moda en el mundo del software. Si alguna vez te has preguntado por qué, la respuesta principal es por el valor que los contenedores y el desarrollo con instancias de Docker aporta tanto a los programadores como a los administradores de software, y especialmente a aquellos que hayan adoptado un flujo de trabajo centrado en DevOps. Docker permite que estos equipos de desarrollo alcancen una eficiencia muy alta en la entrega y el despliegue de software, al solucionar muchos de los retos que presenta la virtualización tradicional.

En este artículo intentaremos explicar por qué las instancias de Docker han resultado tener un grado de aceptación tan grande entre los equipos de desarrollo de software y como los contenedores aportan ventajas a los desarrolladores que no pueden obtener usando máquinas virtuales de toda la vida.

¿Qué es lo que hace Docker?

Para entender por qué Docker es tan valioso para los desarrolladores de software, primero hay que comprender cómo es que Docker aporta (o no) cambios a la hora de desarrollar y desplegar software.

En la mayoría de las empresas, el desarrollo, despliegue y la entrega de software es un proceso con varios pasos bien diferenciados:

  1. El primer paso es el diseño de la aplicación.
  2. El segundo es el desarrollo de la misma, escribiendo el código.
  3. El tercer paso es montar el código en un entorno de pruebas y probarlo.
  4. El cuarto y último paso consiste en empaquetar la aplicación probada, desplegarla y entregarla a los usuarios.

Desde un punto de vista de desarrollo y despliegue, los contenedores pueden hacer todo lo que hacen las máquinas virtuales, pero mejor.

La única parte del proceso de desarrollo de software con contenedores Docker que realmente supone un gran cambio es en el último paso. Los contenedores no suponen necesariamente un cambio en el diseño o a la hora de programar el código (aunque, en algunos casos, migrar software heredado a contenedores exige algunas modificaciones para que la app se pueda ejecutar como un conjunto de microservicios). Los contenedores tampoco hacen variar en lo fundamental la forma en la que se prueban las aplicaciones, aunque si facilitan el hecho de mantener un entorno de pruebas consistente. De todos modos, las herramientas para hacer pruebas son las mismas.

Pero a la hora de empaquetar y desplegar una aplicación de desarrollo a producción, las instancias de Docker cambian mucho la cosa. Permiten a los desarrolladores colocar la app dentro de un contenedor, que es un entorno definido por software fácilmente portable. Este entorno, además, está abstraído del sistema host.

El valor de desplegar aplicaciones como instancias de Docker

¿Qué beneficios obtienen los equipos de desarrollo desplegando sus aplicaciones como contenedores? La lista puede llegar a ser muy larga, pero las ventajas principales asociadas a los contenedores se pueden resumir así:

  • Solo se tiene que programar la aplicación una sola vez. Dado que una app en Docker se ejecuta dentro de un contenedor, y el contenedor se puede ejecutar en cualquier sistema operativo que tenga Docker instalado, no se tiene que programar y configurar el software para diferentes tipos de plataformas hardware o sistemas operativos en los que tiene que poder ejecutarse. Solo tienes que programarlo una sola vez para Docker.

  • Se obtiene una mayor consistencia entre los entornos de prueba y los entornos de producción. Cuando se desarrolla con Docker, se hacen pruebas de la app dentro de un contenedor, y la despliegas dentro de un contenedor. Eso significa que el entorno de pruebas es idéntico al entorno en el que se va a ejecutar el software. En consecuencia, los desarrolladores ganan en tranquilidad y en confianza pues saben que los usuarios finales no se van a topar con problemas que el equipo que probó el software hubiera pasado por alto.

  • Se obtiene mayor modularidad. El desarrollo con contenedores es ideal para un enfoque basado en microservicios para el diseño de aplicaciones. Bajo este modelo, las aplicaciones complejas se dividen en unidades más discretas y pequeñas. Por ejemplo, y sin llegar a cambiar la arquitectura tradicional de la app, la base de datos quizás se ejecute en un contenedor mientras que el front-end de la misma se ejecuta en otro distinto. Este enfoque hace que la aplicación sea modular, reduciendo la complejidad de tener que mantener y actualizar la aplicación, dado que un error o un cambio relacionado con una parte de la app no requiere que se revise la aplicación completa.

Si un desarrollador se dedica a escribir código, hacer pruebas y desplegar el software, estas funciones de Docker le facilitan la vida y le harán más productivo.

Cómo empezar a desarrollar utilizando Docker

El desarrollo con instancias Docker versus la virtualización tradicional

Revisando la lista anterior, uno se puede preguntar en qué se diferencian los contenedores de las máquinas virtuales. Y es que después de todo, si despliegas tu app en una imagen de una máquina virtual para una plataforma tipo VMware o KVM, también se obtiene la ventaja de programar una vez y desplegar donde sea (o al menos casi donde sea). Los entornos virtuales, además, ofrecen un nivel relativamente alto de consistencia entre el entorno de pruebas y el entorno de producción.

Todo eso es verdad. Sin embargo, los contenedores duplican de varias formas las ventajas de las máquinas virtuales, por ejemplo:

  • Las instancias de Docker son más ligeras. Para desplegar una app como imagen de una máquina virtual, lo más probable es que tengas que incluir un sistema operativo entero en la imagen. Con un contenedor, solo la app y unas cuantas capas de base tienen que ir dentro del contenedor. Esto se traduce en un proceso de montaje más sencillo, y, encima, la capacidad de poder de alojar muchos más contenedores en un servidor físico único. Además, arrancan mucho más rápido (en centésimas de segundo) y te puedes permitir el lujo de lanzarlos y cerrarlos automáticamente según las necesidades.

  • Los contenedores son muy, muy, muy consistentes. La imagen de una máquina virtual ofrece una consistencia bastante razonable entre el entorno de pruebas y el entorno de producción de una aplicación. Aún así, existe una variación mayor que en el caso de los contenedores. Las imágenes de las máquinas virtuales contienen diferentes tipos de sistemas operativos, y esos sistemas operativos tienen muchas más variables de entorno que Docker. Por ejemplo, puedes montar dos máquinas virtuales Linux con dos meses de diferencia, que tienen un nivel de parches o cierto software pre-instalado diferentes, y que pueden variar el resultado final. Con un contenedor Docker hay mucho menos margen para las variaciones: usando la misma versión de las imágenes te aseguras que son idénticos, lo que implica una consistencia mayor que el de las máquinas virtuales.

  • Los contenedores son gratuitos y de código abierto. Algunas plataformas de virtualización, como KVM, son gratis y de código abierto. Pero otras, incluyendo VMware, requieren generalmente una licencia comercial para uso empresarial. Docker es totalmente gratis para que cualquiera lo descargue e instale. Puedes pagar, eso sí, por servicios adicionales y soporte, pero el producto base es gratuito y de código abierto.

Te recomendamos que leas este otro artículo más detallado sobre las diferencias existentes entre contenedores y las máquinas virtuales.

Utilizando algún orquestador de contenedores, sobre todo Kubernetes, puede crear despliegues automáticos todo lo complejos que necesites, con balanceado de carga automático, monitorización de salud y muchas otras características avanzadas, para las cuales tendrías que hacer encaje de bolillos su usases máquinas virtuales.

Desde el punto de vista del desarrollo y despliegue, los contenedores hacen lo mismo que las máquinas virtuales, pero mejor.

El desarrollo con instancias Docker y DevOps

Pero aún no hemos terminado con toda la explicación de por qué Docker está causando tan buena sensación entre los equipos de desarrollo de software. El otro factor en juego es el cambio a DevOps.

DevOps es un enfoque de desarrollo y de despliegue de software que pone el énfasis en la colaboración transparente y fluida entre las personas encargadas de desarrollar el código ("Dev"), las personas que administran las operaciones en producción ("Ops", de operations), y todas las personas que realizan tareas intermedias (como las personas encargadas de probar el software, por ejemplo). El objetivo de DevOps es el de tirar abajo las parcelas que tradicionalmente han separado o dividido cada parte del proceso de desarrollo de software y permitir la entrega constante de actualizaciones en las apps.

Si uno se quiere dedicar a desarrollar apps siguiendo el enfoque de DevOps, Docker es muy útil porque te ofrece consistencia en los entornos de desarrollo que usa todo el equipo (sin andar moviendo máquinas virtuales pesadísimas: con un simple archivo de texto), y la naturaleza tan ligera de los contenedores, que ya hemos descrito arriba. Docker hace posible que los equipos de desarrollo programen y desplieguen software actualizado rápidamente. Por esa razón Docker y DevOps van tan bien de la mano.

Habiendo dicho lo anterior, Docker no es la única herramienta dentro del ecosistema de DevOps. Servidores de integración continua, frameworks de programación flexible y una infraestructura escalable también son componentes importantes de un flujo de trabajo DevOps para la mayoría de las empresas de desarrollo. El movimiento DevOps es anterior a Docker y no hay ninguna norma que diga que tienes que usar contenedores si quieres hacer DevOps. Por lo tanto, Docker y DevOps guardan alguna relación, pero no están ligados de manera congénita.

Aún así, si se quiere modernizar la forma en la que se desarrolla software en la empresa adoptando los principios de DevOps, Docker muy probablemente hará mucho por ayudarte a conseguir tus objetivos.

En este artículo te contamos cómo puedes empezar a desarrollar utilizando Docker.

10 Beneficios de usar Docker y contenedores a la hora de programar desde una óptica empresarial

¿Por qué será que grandes empresas como ING, Paypal, o Spotify usan Docker a día de hoy? ¿Qué otras razones contribuyen al crecimiento exponencial de Docker? Además de las razones explicadas arriba, repasaremos los beneficios de usar Docker teniendo en cuenta un punto de vista empresarial.

1. Retorno de la inversión y ahorro de costes

La primera ventaja empresarial de usar Docker es el ROI (el retorno de la inversión). Uno de los factores más importantes desde el punto de vista empresarial para optar por una u otra tecnología es el retorno de la inversión de cada una de ellas. Cuanto más pueda minimizar una solución los costes a la par que aumenta los beneficios, mejor solución es desde esta perspectiva, y más aún en empresas grandes que necesitan generar una facturación estable a largo plazo.

En este sentido, Docker puede ayudar a facilitar este tipo de ahorro reduciendo costes en recursos de infraestructura. La naturaleza de Docker permite que se necesiten menos recursos para ejecutar la misma aplicación. Dado que Docker tiene unos requisitos de infraestructura tan reducidos, las empresas son capaces de ahorrar en costes de mantenimiento y de servidores. Incluso si los llevas a la nube, ya que todos los principales actores (Azure, AWS, Google Cloud...) ofrecen contenedores Docker y Kubernetes y les sacan partido para sus propios servicios. Docker permite, además, como hemos visto, que los equipos de desarrollo sean más eficientes, lo cual constituye otro ahorro de costes por aumento de productividad y disminución de problemas. Y hablando de eso...

2. Estandarización y productividad

Los contenedores Docker garantizan consistencia a lo largo del proceso de desarrollo y despliegue de una aplicación, estandarizando el entorno en el que se ejecuta. Una de las principales ventajas de una arquitectura basada en Docker es precisamente la estandarización. Docker permite desarrollos, compilaciones, pruebas y entornos de producciones repetibles y replicables y sin necesidad de compartir enormes archivos. Poder hacer que toda la infraestructura de servicios a lo largo de todo el proceso de desarrollo sea estándar, permite a cada miembro del equipo de desarrollo trabajar en un entorno de producción paritario. Así los desarrolladores están más equipados para analizar y corregir errores dentro de la aplicación. Esto reduce la cantidad de tiempo que se pierde encontrando bugs y aumenta el tiempo disponible para programar mejores y más funcionalidades.

Los contenedores Docker permiten hacer cambios a tus imágenes Docker y hacerles un control de versión. Por ejemplo, si se realiza la actualización de un componente que rompe todo el entorno, es muy fácil retroceder a la versión anterior de una imagen Docker ya que la configuración no es más que un pequeño archivo de texto. Todo este proceso se puede probar en cuestión de minutos. Docker es rápido y permite hacer replicaciones y lograr redundancia ágilmente. Además, lanzar imágenes Docker es igual de rápido que ejecutar un proceso cualquiera de la máquina.

3. Eficiencia de imágenes de contenedor

Docker te permite crear una imagen de contenedor y usar esa misma imagen a lo largo de todo el proceso de despliegue. Una gran ventaja de esto es la capacidad de separar pasos no dependientes del proceso y ejecutarlos en paralelo. El tiempo que va desde la compilación a la producción se puede acelerar bastante.

4. Compatibilidad y mantenimiento más fácil

Erradica el problema de "en mi máquina funciona" de una vez por todas. Una de las ventajas de las que se beneficia todo el equipo de desarrollo es del de la paridad. La paridad en Docker significa que las imágenes se ejecutan igual independientemente del servidor de la máquina física en la se ejecutan. Para un equipo de desarrollo esto supone tener que dedicar menos tiempo configurando servidores, depurando errores específicos de problemas del entorno, y una base de código más portable y más fácil de configurar. La paridad también implica que la infraestructura de producción es más fiable y fácil de mantener.

5. Simplicidad y configuraciones más rápidas

Una de las ventajas principales de Docker es la forma en la que simplifica las cosas. Los desarrolladores pueden coger su propia configuración, transformarlo en código y desplegarlo sin problemas. Como Docker se puede usar en una amplia variedad de entornos, los requisitos de la infraestructura ya no quedan vinculados al entorno de la aplicación.

6. Despliegue y escalabilidad rápidos

Docker consigue reducir el despliegue a cuestión de segundos. Esto se debe al hecho de que crea un contenedor para cada proceso y no arranca un sistema operativo. Los datos se pueden crear y eliminar sin temer que el coste de tenerlo que arrancarlo todo otra vez sea mayor de lo que se pueda permitir.

7. Pruebas continuas

Docker garantiza entornos consistentes desde la fase de desarrollo hasta la fase de producción. Los contenedores Docker se configuran para que conserven todas las configuraciones y dependencias internamente. Así, se puede usar el mismo contenedor desde desarrollo a producción con la seguridad de que no hay discrepancias ni intervención manual.

Si se necesita llevar a cabo una mejora durante el ciclo de lanzamiento de un producto, se pueden hacer los cambios necesarios a los contenedores Docker, probarlos, e implementar los mismos cambios a los contenedores que ya existen de antes. Este tipo de flexibilidad es otra ventaja clave de usar Docker. Docker verdaderamente permite compilar, probar y liberar imágenes que se pueden desplegar a través de múltiples servidores. Incluso si está disponible un nuevo parche de seguridad, el proceso es el mismo. Puedes aplicar el parche, probarlo y acto seguido liberarlo a producción.

8. Plataformas multi-cloud

Esta es posiblemente una de las grandes ventajas de Docker. En los últimos años, todos los proveedores principales de computación en la nube incluyendo Amazon Web Services (AWS), Microsoft Azure o Google Compute Platform (GCP), han adoptado la disponibilidad de Docker y Kubernetes, y han añadido soporte individual. Los contenedores Docker se pueden ejecutar dentro de una instancia de Amazon EC2, una instancia de Google Compute Engine, un servidor Rackspace server o VirtualBox, siempre y cuando el sistema operativo host soporte Docker. Si este es el caso, un contenedor que se ejecute en una instancia de Amazon EC2 se puede portar fácilmente a un entorno de la competencia. Además Docker funciona muy bien con otros proveedores como OpenStack, y se puede usar con varios gestores de configuración como Chef, Puppet, y Ansible, etc.

9. Aislamiento

Docker garantiza que las aplicaciones estén aisladas y segregadas. Se asegura de que cada contenedor tenga sus propios recursos y que estén aislados de otros contenedores. Se pueden tener varios contenedores para aplicaciones separadas ejecutando stacks completamente distintos. Docker, además, garantiza que la desinstalación de aplicaciones sea completa ya que cada aplicación se ejecuta en su propio contenedor. Si ya no se necesita una aplicación, lo único que hay que hacer es borrar su contenedor. No dejará atrás ningún fichero temporal o de configuración en el sistema operativo.

A todas estas ventajas habría que añadir que Docker también se encarga de que cada aplicación utilice solo los recursos que le han sido asignados. Una aplicación determinada no tirará de todos los recursos disponibles, que normalmente hace que baje el rendimiento o directamente dejen de funcionar otras aplicaciones.

10. Seguridad

Una última ventaja en este apartado de usar Docker es la de la seguridad. Desde el punto de vista de la seguridad Docker garantiza que las aplicaciones que se están ejecutando en los contenedores estén totalmente segregadas y aisladas las unas de las otras, como ya hemos comentado, otorgando un control total sobre la gestión y el tráfico de flujos. Ningún contenedor Docker puede entrar a ver los procesos que se están ejecutando dentro de otro contenedor. Desde un punto de vista de arquitectura del software, cada contenedor obtiene su propio conjunto de recursos que van desde las pilas de procesamiento hasta las de red.

Conclusión

Para concluir cabe destacar que los contenedores Docker comparten sus sistemas operativos para ser ejecutados como procesos aislados independientemente del sistema operativo de la máquina host. Docker se enorgullece, según sus propias palabras, de que sus contenedores se "pueden ejecutar en cualquier máquina, en cualquier infraestructura y en cualquier nube". La portabilidad, flexibilidad y simplicidad que esto permite son las razones fundamentales que explican por qué Docker ha sido capaz de crear tanta captación en tan poco tiempo.

Nota: créditos de las imágenes: José M. Alarcón, Docker y Manu Camargo en Unsplash.

El developer feliz: qué buscamos y qué necesitamos

08/10/2018
Artículo original

El developer feliz: qué buscamos y qué necesitamos

Cuando preparaba “El Feliz Developer”, la charla para T3chFest que me animó a preparar un estudio sobre motivaciones profesionales en el sector IT, una de las cuestiones fundamentales en la investigación, era definir las necesidades más importantes de los trabajadores. El objetivo era reflexionar sobre qué cosas son las que buscamos, las que necesitamos, en nuestra vida y, sobre todo, también en el trabajo.

Hoy intentaremos analizar precisamente cuáles son nuestras necesidades, y por qué algunas son más importantes que otras dentro del entorno profesional.

¿Qué es lo que de verdad queremos?

Lo ideal antes de empezar a leer este artículo es que te sientes con una hoja de papel al lado. ¿Ya la tienes? Escribe en un lado cuáles son los factores que hacen que te sientas feliz en tu trabajo. Escribe en otro lado cuáles son los factores que podrían hacer que fueras infeliz en tu trabajo

Genial, ahora puede seguir leyendo. Pensar en este tipo de cosas sin conocer las clasificaciones teóricas, te permite ser mucho más sincero contigo mismo.

Los profesionales que respondieron a la encuesta de El Feliz Developer” dijeron que lo más valorado en su trabajo era, en este orden:

  • flexibilidad
  • salario,
  • buen ambiente
  • uso de las tecnologías más actuales.

Por otro lado, lo que más se echaba en falta era:

  • formación
  • salario acorde a las expectativas
  • uso de metodologías ágiles

La teoría de Herzberg: necesario, pero no suficiente para hacernos felices

¿Hasta qué punto piensas que tener una buena silla, la temperatura de la oficina, o una luz que no parpadee sobre ti te hace feliz?

Hay dos teorías, con sus matizaciones, claro, que nos ayudan a explicar muy bien cuáles son las necesidades y motivaciones que tenemos en el ambiente profesional.

Una de estas teorías es la de Herzberg, que analiza qué factores generan satisfacción, y qué factores generan insatisfacción. Lo realmente interesante de esta teoría, es que hay factores que ayudan a aumentar nuestra satisfacción, pero tienen muy poco efecto sobre la insatisfacción, y viceversa punto hay factores que cuando faltan causan insatisfacción, pero que estén presentes no garantiza la satisfacción de los trabajadores: son necesarios, pero no suficientes.

¿Hasta qué punto piensas que tener una buena silla, la temperatura de la oficina, o una luz que no parpadee sobre ti te hace feliz? No es algo que añadiríamos como algo que nos motivaría, pero sin embargo, si hace demasiado frío o calor, hay olor desagradable o ningún ascensor funciona, nos sentiriamos muy insatisfechos. Este tipo de reflexiones nos ayuda a valorar y entender la importancia de las “pequeñas” grandes cosas , y a comprender por qué desde la empresa es importante cuidar estos detalles, que muchas veces damos por supuesto.

¿Eres capaz de definir cuáles son los factores que deberían cumplirse, obligatorios si cambiaras de trabajo?

Maslow y la jerarquía de nuestras necesidades

Ahora, ponte delante de tu hoja de papel. ¿Eres capaz de definir cuáles son los factores que deberían cumplirse, obligatorios si cambiaras de trabajo? ¿Puedes definir por otro lado cuáles supondría un plus, pero son menos importantes para ti?

Muchos ya conoceréis la Pirámide de Maslow. Es nuestra segunda teoría: fue propuesta por Maslow en los años 40 que trata de jerarquizar las necesidades del ser humano: las ordena según su orden de prioridad. Estas necesidades están orientadas a la vida en general, y se han interpretado varias veces por diferentes autores.

Estas necesidades son básicas (las que nos permiten mantenernos vivos), seguridad, afiliación (como nos relacionamos) , reconocimiento (como nos perciben). Pueden trasladarse al entorno profesional, como vemos en la pirámide.

Piramide de Maslow adaptada al trabajo

Desde luego, y como podremos imaginar, este orden de necesidades puede cambiar: dependiendo de nuestra situación, valoramos más unas cosas que otras (después de una mala experiencia en un ambiente conflictivo, primaremos las necesidades de socialización o afiliación, si estamos en un momento en el que es muy necesario el crecimiento profesional por sentirnos encasillados, serán fundamentales las opciones de promoción al buscar un nuevo empleo.

Por ejemplo, a partir de cierta banda salarial. ¿Hay una diferencia real entre cobrar 80 u 85k al año?, el dinero tiene menos importancia en detrimento del tipo de trabajo, el clima laboral…. pero esto solo ocurre cuando ciertas bases están cubiertas

Es importante entender que las necesidades han de cubrirse primero desde la base e ir subiendo: no podemos hablar a alguien de que le vamos a dar entradas para ir al cines si le estamos pagando un salario ínfimo o no le damos herramientas mínimas para trabajar.

Por supuesto, en muchos casos, un problema social de afiliación puede convertirse en un problema de base: machismo, acoso, si afecta a la seguridad...

Cambiamos lo que somos, lo que necesitamos… y cómo influimos

Como curiosidad: fíjate en nuestra pirámide: las bases, en azul (básicas y seguridad) deben ser aseguradas por la empresa, es su responsabilidad. La parte verde es responsabilidad repartida, entre la empresa y nosotros (proceso de selección, relaciones informales) La cúspide depende más de nuestra propia percepción.

Y, una última observación. Vuelve a pensar en esos factores que hacen que te sientas bien en el trabajo. En tu día a día: la limpieza la seguridad… piensa en el trabajo de las personas que se esfuerzan por que tu base de la pirámide sea lo mejor posible. Quienes reparan tu ascensor, vacían tus papeleras, vigilan los accesos y se encargan de que el baño esté limpio. También tienen su propia pirámide, sus necesidades y sus motivaciones.

Éste puede ser también un buen ejercicio autoconocimiento. ¿Cuáles son los factores que has considerado necesarios (imprescindibles para un cambio)? ¿cuáles son los que has considerado motivadores (un plus)? ¿Qué puedes exigir a la organización para que tu pirámide mejore? ¿Cómo puedes afectar tú a la pirámide de los demás? ¿Qué soluciones de la pirámide aporta tu trabajo, y tu actitud?

Este tipo de reflexiones nos ayudan a conocer mejor cómo somos, cuáles son las necesidades que ahora no tenemos cubiertas, y cómo hemos evolucionado a lo largo de los años, tanto nosotros como nuestras motivaciones.

Foto | Raimond Spekking Video | El feliz developer | T3chFest 2018

"OpenAPI, estandarizando los contratos de las API". Entrevista a Pedro J. Molina

08/10/2018
Artículo original

El café humea en la mesa, mientras el tono de llamada del Hangout se repite en mis auriculares, y repaso las preguntas que quiero hacerle a Pedro J. Molina; uno de los mayores expertos en OpenAPI de nuestro país.

Es miembro del ISA – Grupo de investigación de Ingeniería de software aplicada- de la Universidad de Sevilla, liderado por Antonio Ruiz junto a Pablo Fernández, y doctor en informática, especializado en modelado y generación de código.

Recientemente se ha integrado dentro de la Iniciativa OpenAPI, en donde participa de forma activa en la TSC (Technical Steering Committee) y el BGB (Business Governance Board). Y se ha prestado para una larga entrevista donde repasamos esta tecnología.

Una de las cosas que más me llaman la atención de Pedro, es la claridad y sencillez con que contesta las preguntas técnicas de todo nivel que le voy lanzando durante esta hora larga de conversación.

Busca la forma de explicar conceptos muy complejos, para lograr que lleguen a la mayoría de los lectores sin perder, en ningún momento, la rigurosidad de una mente científica.

¿Qué es OpenAPI?

Api Consumers

Es un estándar para definir contratos de Api. Los cuales describen la interfaz de una serie de servicios que vamos a poder consumir por medio de una signatura. Por ejemplo, saber que vamos a tener una operación de sumar que va a recibir dos números y que estos son del tipo “entero”.

Tecnologías previas, como CORBA o SOAP, han intentado estandarizar las operaciones RPC (Llamadas a procedimientos remotos) que satisfagan la necesidad de comunicar dos máquinas que están separadas entre sí; y que requieran conocer como una tiene que invocar a la otra, especificando qué tipo de mensajes se aceptan, y qué es lo que se va a devolver.

¿Qué ventaja tiene el enfoque de OpenApi en comparación con definir un API de modo informal?

Se puede exponer un servicio de manera informal, pero la comunicación de cómo acceder al mismo también lo será. Esta comunicación informal puede inducir o incluir equivocaciones al escribirla, describirla, o ser incompleta; siendo una documentación con muy poco valor para poder consumir el servicio, porque depende de que esté bien expresado y sea bien entendido.

Ese es el contrato en que hay que ponerse de acuerdo.

Si hacemos el esfuerzo de formalizar esa definición (contrato), podemos conseguir que una máquina también la aproveche para poder conectarse al servicio y, consumiendo la especificación OpenAPI, construir un Proxy de integración. Es decir, una clase que automáticamente se conecta al servicio.

¿Pero esto no lo hacía ya los WSDL? ¿Qué falló para que sean tecnologías residuales en la actualidad?

Arquitectura SOA

CORBA y WSDL son tecnologías para comunicar servicios distribuidos. El paradigma SOA (Arquitectura orientada al servicio) es un estilo arquitectónico basado en la comunicación entre servicios distribuidos débilmente acoplados y altamente interoperables. SOA fue abrazado por la industria y los grandes fabricantes como Oracle, Microsoft, IBM, etc., los cuales se lanzaron a construir sus propias pilas de productos SOA que resultaron ser muy complejas y, en ocasiones, incompatibles entre sí.

Al final la complejidad del uso de la pila de productos SOA fue tal, que la industria abandonó la aplicación de los estándares más farragosos. Y con la llegada de los primeros smartphone y sus limitadas capacidades de cálculo y almacenamiento, migraron del XML al JSON (aunque el primero es mucho más extensible que el segundo) y de los Webservices (y sus sobres SOAP) a las comunicaciones REST.

¿Qué relación tiene Swagger con OpenAPI?

OpenAPI viene de Swagger.

A finales de la década pasada empezó a crecer la economía de las API’s, la cual indica que toda aplicación que quiera escalar y triunfar en el mercado debe incluir una Interfaz de Programación de Aplicaciones potente.

En 2011, Tony Tam crea el proyecto Swagger API para automatizar la documentación y la generación del SDK (framework de desarrollo) de clientes de sus API’s. Diseñando un formato muy sencillo para describir el interfaz, en JSON o YAML, pero lo suficientemente formal como para que las máquinas lo puedan utilizar para crear Proxys (para clientes) y Skeletons (para servidores).

El éxito de Swagger fue fulgurante, convirtiéndose en un estándar “de facto”, y siendo adquirido por la empresa SmartBear que ha liberado todo el proyecto añadiéndolo a la Linux Foundation y atrayendo a los actores más importantes en la industria como Microsoft, IBM, PayPal, Adobe, Google, SAP, etc.

Y dentro de la Linux Foundation está la Iniciativa OpenAPI que es un comité dentro de la Fundación Linux que rige la evolución de la especificación.

¿Por qué está siendo tan apoyado por los fabricantes?

Si bien Swagger ya era libre, SamrtBear lo adquirió y liberó para hacerlo realmente neutral y que los diferentes fabricantes pudieran desarrollar sus 'API Middleware' -productos que se colocan entre tu API y el cliente final-, que te dan servicios de autenticación, autorización, seguridad, identificación, gestión de pagos, entre otros.

En una API que soporte 100 endpoints, la complejidad viene al tener que configurar nuestra herramienta para cada uno de ellos. Sin embargo, al tener una definición del contrato OpenAPI, con un sistema de drag & drop podría configurar de modo automático la herramienta de forma muy sencilla.

Los fabricantes de Middelware son los primeros interesados en que haya un estándar abierto para todos. Y, como hay negocio, se han puesto de acuerdo en dicho estándar siendo este el incentivo que ha conseguido que todos estén convergiendo hacía OpenAPI; incluso los usuarios de RAML, otro framework para definir las API, que se ha integrado en el comité de la Fundación Linux.

“El objetivo de OpenAPI es construir un estándar en la definición de las API para humanos, pero haciendo hincapié en el interfaz para máquinas, facilitando que se configuren e integren de forma autónoma”

Pero no se circunscribe a los fabricantes, también actores tan importantes como la Banca o los gobiernos han entendido las ventajas de la estandarización en OpenAPI . Así Holanda se ha convertido en el primer estado que ha adoptado la definición para el desarrollo de sus aplicaciones.

¿Quién compone OpenAPI?

Investigadores de ISA

Hay una representación por cada organización que es miembro de la iniciativa. España está presente por el Grupo de investigación de Ingeniería de software aplicada (ISA) de la Universidad de Sevilla, al igual que por la startup 42 Crunch dedicada a la seguridad y gestión de amenazas a aplicaciones y datos.

El Grupo ISA hace una labor de investigación, más que orientada al negocio, trabajando en métricas de SLA donde se determina la definición de nivel de servicio. El objetivo es proponer extensiones orientadas a la medición y definición de niveles de servicio dentro de los contratos OpenAPI, aplicando la investigación realizada en la implantación industrial.

NdE. Las ramificaciones e implantaciones de estas extensiones al estándar OpenAPI aporta un valor crítico en las capacidades de aplicación de los contratos entre los interfaces de integración. En ningún otro estándar se comprende de manera específica el soporte a la medición de la calidad del servicio.

Dentro de la iniciativa OpenAPI existen tres comités diferenciados:

  • El Comité Técnico, en donde se discute el estándar y se añaden extensiones. Se trabaja con reuniones semanales en donde se revisa el estado de los desarrollos.
  • Comité de Gobierno, en donde se revisa el estado de la iniciativa desde un punto de vista de gestión.
  • Comité de Marketing, donde se diseñan y ponen en marcha acciones de formación, difusión, visibilización, etc. Y que utiliza los fondos aportados por las organizaciones miembros para realizar los eventos o campañas.

Además, de un par de personas a tiempo completo en la Linux Foundation, dedicadas a OpenAPI.

¿Cuáles son los mayores impedimentos que te encuentras en el día a día al trabajar en los comités?

Hay que conciliar los intereses de muchos fabricantes, que cada uno quiere añadir sus propias funcionalidades, las cuales hay que discutir y acordar. Todas las cosas diseñadas por comité son un poquito más lentas que cuando swagger lo construían dos personas y añadían funcionalidad muy rápido, llevando el producto hacia donde querían.

Las cosas en comité van despacio

Lo bueno es que al estar integrado en la Linux Foundation se garantiza que todo lo que se aporta está libre de patentes y que todo el mundo lo va a poder utilizar sin restricciones.

Hay veces que nos gustaría sacar las cosas más rápido, pero es necesario priorizar los temas, y los procesos van un poquito más despacio. Es importante ser cautos con las publicaciones para dar tiempo que la industria implemente estos estándares.

Por ejemplo, aún hay muchos utilizando OpenApi 2.0 mientras esperaban herramientas en desarrollo para la versión 3.0, que lanzamos hace un año.

En resumen, las dificultades de trabajar en un comité no son mayores que las de cualquier proyecto distribuido. Además, la gente que los compone tiene un gran nivel y vienen con las reuniones muy bien preparadas.

¿Puedo trabajar en la versión 3.0 apuntando a un contrato 2.0?

Openapi Versiones

En el cambio de versión ha habido ruptura de compatibilidad porque había que reorganizar el estándar e implicaba una mejora muy importante. Sin embargo, próximamente vamos a publicar la versión 3.1, y en esta no va a haber ningún tipo de ruptura ya que somos especialmente cuidadosos de añadir nuevas definiciones que sean interoperables con las versiones anteriores.

¿Yo, como una persona física puedo aportar a la iniciativa OpenAPI?

Si. La manera más normal es acceder al proyecto en GitHub de la especificación y dar de alta una Issue en donde describir al detalle la petición o la aportación que quieres añadir. El comité técnico semanalmente revisa el proyecto en GitHub y, aquellas que son interesantes de desarrollar, puede solicitarte que hagas una contribución (pull request) en donde definas la implementación técnica de la propuesta o abrir una nueva tarea interna para planificar su debate y construcción.

También en el proyecto en GitHub tenemos los documentos de cada una de las reuniones del comité para poder hacer un seguimiento de alguna propuesta o del trabajo realizado, así como del roadmap de la siguiente versión que se está “cocinando”.

La Fundación Linux garantiza el acceso libre y gratuito a los trabajos de la Iniciativa OpenAPI

Por ejemplo, en la futura versión 3.1 se describen los “Overlays” que permiten extender la descripción de la API, y que podrían valer para publicar la documentación de una misma interfaz en varios idiomas; o sistemas de encriptación y firmas digitales utilizando JWE (JSON Web Encryption).

Estando previsto hacer el anuncio de esta nueva versión el próximo 24 de septiembre en la conferencia “API Strategy & Practice”.

¿Qué aportaciones habéis hecho al estándar?

Pedro Molina 01

Desde la Universidad de Sevilla hemos propuesto un par de herramientas para el prototipado rápido de contratos con OpenAPI. Oas-generator y Oas-tools.

A titulo personal desarrollo una librería en TypeScript (openapi-ts) y otra en .Net CORE para la creación de contratos OpenApi 3.0.x, otra que construye definiciones 3.0 para Baucis (framework de construcción de APIs REST).

Además de publicaciones en el blog de la iniciativa, como el de “Tres escenarios comunes para aprovechar la especificación OpenAPI”, y la participación semanal en el comité técnico.

Más información | Iniciativa OpenAPI de la Fundación Linux, GitHub de OpenAPI, Página de la ISA en la Universidad de Sevilla

GAMBADAS: Troyano bancario en Android con decenas de miles de descargas

05/10/2018
Artículo original

Hay que tener mucho (pero mucho) cuidado con cualquier cosa que instales en tu teléfono móvil, especialmente en el caso de Android, el sistema operativo más extendido, con una cuota de mercado de más del 80% mundial. Parece una obviedad, pero no lo es en absoluto, al menos si nos atenemos a los hechos. Y es que, en muchas ocasiones, solo por el mero hecho de que una aplicación esté disponible en la tienda de Google y tenga muchas descargas es motivo suficiente para fiarnos e instalarla. ¡Error!

Un caso reciente de fraude grave ha sido el protagonizado por una aplicación que, supuestamente, servía para grabar llamadas telefónicas llamada QRecorder, una de las decenas de aplicaciones de este tipo que podemos encontrar en la Play Store. Esta aplicación maliciosa, descubierta por la policía checa, ha robado al menos 78.000€ de sus víctimas atacando sus cuentas bancarias desde el móvil.

Al instalar este tipo de aplicaciones, por regla general requieren muchos permisos, aunque sean legítimas: al fin y al cabo se "embeben" mucho en el sistema para poder hacer su trabajo: gestionar y grabar llamadas. En este caso la aplicación aprovechaba el servicio de accesibilidad del sistema para detectar qué aplicaciones bancarias estaban instaladas en el móvil, descargar y ejecutar código externo malicioso específico para cada banco (albergado en Firebase, el servicio de Google). Además, usaba el permiso para dibujar sobre otras aplicaciones para robar las credenciales. Finalmente, el permiso para gestionar SMS se utilizaba para poder enviar y recibir mensajes y así confirmar las transacciones fraudulentas que realizaban. Toda una obra de arte de código utilizada para el mal.

El troyano se distribuía fundamentalmente en los mercados de Europa del Este ya que estaba traducido (suponemos que de momento) tan solo a checo, polaco y alemán, y atacaba a bancos de esta área geográfica. La policía checa tiene incluso fotografías de alguno de los "crackers" obtenidas en un cajero al que iban a retirar dinero obtenido con el troyano.

En la página de Lukas Stefanko, el analista de seguridad móvil que ha divulgado el caso, se pueden obtener detalles de la aplicación y de su código y funcionamiento. Incluso podemos verlo en funcionamiento en este vídeo que ha publicado:

[youtube:OIYX9TbspW8]

Hay que mirar "muy mucho" qué aplicaciones descargamos, y que los permisos que les otorgamos sean los estrictamente necesarios y no más. Además, por el hecho de que una app esté en Google Play, tenga muchas descargas e incluso muchas valoraciones, no es motivo suficiente para fiarse, en especial en aquellas aplicaciones que acceden mucho al sistema.  El hecho de que Google audite y analice las aplicaciones antes de permitir que aparezcan en la tienda se ha demostrado que no es suficiente en muchas ocasiones, y este solo es un caso más. ¡Precaución amigo conductor!

Noticia vista originalmente en Una al día de Hispasec.

Ruby 2.5.0 Publicado

04/10/2018
Artículo original

Nos complace anunciar la publicación de Ruby 2.5.0.

Ruby 2.5.0 es la primera versión estable de la serie 2.5 de Ruby. Introduce muchas características nuevas y mejoras en desempeño. Los cambios más notables son los siguientes:

Nuevas características

  • El uso de rescue/else/ensure ahora es permitido directamente dentro de bloques do/end. [Característica #12906]
  • Agregada yield_self para ceder al bloque dado su contexto. A diferencia de tap, retorna el resultado del bloque. [Característica #6721]
  • Soporta medición de cobertura de ramas y de cobertura de métodos. La cobertura de ramas indica que ramas se ejecutan y cuales no. La cobertura de métodos indica que métodos son llamados y cuales no. Al ejecutar un conjunto de pruebas con estas nuevas características, sabrá que ramas y que métodos se ejecutan, y evaluará la cobertura total del conjunto de pruebas de manera más rigurosa. [Característica #13901]
  • Hash#slice [Característica #8499] y Hash#transform_keys [Característica #13583]
  • Struct.new puede crear clases que aceptan argumentos con palabra clave. [Característica #11925]
  • Enumerable#any?, all?, none?, y one? aceptan un patrón como argumento. [Característica #11286]
  • Se ha eliminado la búsqueda de constantes en el nivel superior cuando no se encuentran en una clase. [Característica #11547]
  • Una de sus librerías más amadas, pp.rb, ahora se carga automaticamente. Ya no necesita escribir require "pp". [Característica #14123]
  • Impresión de la trazas y del mensaje de error en orden inverso (las llamadas más antiguas primero, las más recientes al final). Cuando aparece una traza larga en su terminal (TTY), puede encontrar facilmente la línea causante al final de la traza. Note que el orden se invierte sólo cuando la traza se imprime directamente en la terminal. [Característica #8661] [experimental]

Mejoras en desempeño

  • Mejora del 5 al 10% en desempeño al eliminar todas las instrucciones trace del bytecode general (secuencias de instrucciones). La instrucción trace se añadió para dar soporte a TracePoint. Sin embargo, en la mayoría de casos, TracePoint no se usa y las instrucciones trace son gasto puro. En cambio, ahora usamos una técnica de instrumentación dinámica. Ver detalles en la [Características #14104].
  • Pasar un bloque por un parámetro de bloque (e.g. def foo(&b); bar(&b); end) es cerca de 3 veces más rápido que en Ruby 2.4 por la técnica de “localización diferida de Proc” [Característica #14045]
  • Se reescribió Mutex para disminuir su tamaño y aumentar su rapidez. [Característica #13517]
  • ERB ahora genera el código de una plantilla dos veces más rápido que en Ruby 2.4.
  • Mejorado el desempeño de algunos métodos incorporados incluyendo Array#concat, Enumerable#sort_by, String#concat, String#index, Time#+ y más.
  • IO.copy_stream usa copy_file_range(2) para copiar con la opción offload en Linux (es decir sin leer ni escribir el contenido sino añadiendo una referencia cuando el sistema de archivos lo permite). [Característica #13867]

Otros cambios notables desde la versión 2.4

  • SecureRandom ahora prefiere fuentes proveidas por el sistema operativo en lugar de OpenSSL. [Falla #9569]
  • Promovidas cmath, csv, date, dbm, etc, fcntl, fiddle, fileutils, gdbm, ipaddr, scanf, sdbm, stringio, strscan, webrick, zlib de la librería estándar a gemas por omisión.
  • Actualización a Onigmo 6.1.3.
  • Actualización a Psych 3.0.2.
  • Actualización a RubyGems 2.7.3.
  • Actualización a RDoc 6.0.1.
  • Actualizada versión soportada de Unicode a 10.0.0.
  • Thread.report_on_exception ahora queda en true por omisión. Este cambio ayuda a depurar programas de multiples hilos. [Característica #14143]
  • IO#write ahora recibe múltiples argumentos. [Característica #9323]

Ver detalles en NEWS o en la bitácora de commits.

Con esos cambios, 6158 archivos cambiaron, 348484 inserciones (+), 82747 eliminaciones(-) desde Ruby 2.4.0!

¡Feliz navidad, felices festividades y disfrute programando con Ruby 2.5!

Descargas

  • https://cache.ruby-lang.org/pub/ruby/2.5/ruby-2.5.0.tar.gz

    SIZE:   15834941 bytes
    SHA1:   58f77301c891c1c4a08f301861c26b1ea46509f6
    SHA256: 46e6f3630f1888eb653b15fa811d77b5b1df6fd7a3af436b343cfe4f4503f2ab
    SHA512: 0712fe68611f5d0cd6dd54b814f825478e64b6a62bdf67bce431f4dca2dc00b1a33f77bebfbcd0a151118a1152554ab457decde435b424aa1f004bc0aa40580d
    
  • https://cache.ruby-lang.org/pub/ruby/2.5/ruby-2.5.0.zip

    SIZE:   19495617 bytes
    SHA1:   700b6f55d689a5c8051c8c292b9e77a1b50bf96e
    SHA256: 94559ea6e3c619423da604e503ce1dc1c465d6e0747a07fbdc5f294acaf14c24
    SHA512: e4324064cee8c65b80192e3eff287e915d2d40464d300744c36fb326ae4b1846911400a99d4332192d8a217009d3a5209b43eb5e8bc0b739035bef89cc493e84
    
  • https://cache.ruby-lang.org/pub/ruby/2.5/ruby-2.5.0.tar.bz2

    SIZE:   13955820 bytes
    SHA1:   827b9a3bcffa86d1fc9ed96d403cb9dc37731688
    SHA256: d87eb3021f71d4f62e5a5329628ac9a6665902173296e551667edd94362325cc
    SHA512: 8f6fdf6708e7470f55bc009db2567cd8d4e633ad0678d83a015441ecf5b5d88bd7da8fb8533a42157ff83b74d00b6dc617d39bbb17fc2c6c12287a1d8eaa0f2c
    
  • https://cache.ruby-lang.org/pub/ruby/2.5/ruby-2.5.0.tar.xz

    SIZE:   11292472 bytes
    SHA1:   9c7babcf9e299be3f197d9091024ae458f1a1273
    SHA256: 1da0afed833a0dab94075221a615c14487b05d0c407f991c8080d576d985b49b
    SHA512: 55714a33d7661fe8b432f73c34fd67b49699f8b79df1cbd680a74899124d31111ab0f444677672aac1ba725820182940d485efb2db0bf2bc96737c5d40c54578
    

Publicado por naruse el 2017-12-25
Traducción de vtamara

Java 11 ya está aquí: te toca pagar a Oracle o cambiarte a otras opciones

03/10/2018
Artículo original

Hace justo un año Oracle lanzaba la esperadísima versión 9 de Java. Era la primera gran versión de la plataforma desde Java 8, aparecido más de cuatro años antes, en marzo de 2014. Lo cierto es que traía bastantes novedades, pero a pesar de ello muchas empresas todavía siguen usando Java 8 en sus desarrollos. Y es que el mundo Java tiende a moverse lento porque se utiliza sobre todo para aplicaciones de gestión y de backend en donde se prima la estabilidad por encima de todo.

El año pasado, con Java 9, Oracle se comprometió a lanzar una nueva versión de Java cada 6 meses, y de momento lo está cumpliendo aún a costa de que las nuevas versiones no traigan grandes novedades. En marzo de este año salió Java 10, sin apenas nada reseñable y que pasó sin pena ni gloria. Ahora lanzan Java 11. En esta ocasión, sin embargo, sí que viene con algo muy importante que deberíamos tener en cuenta si vamos a desarrollar: el cambio de licencia y el soporte a largo plazo asegurado para el JDK.

Cambios radicales: Kits de desarrollo de Java, licencias y precios

Un Kit de desarrollo de software (SDK) de Java es lo que nos permite desarrollar con la plataforma Java. Incluye una implementación concreta del estándar de la plataforma, así como herramientas y compiladores. Oracle ofrece uno oficial llamado JDK. Aparte del de Oracle existen otros, siendo el más conocido el OpenJDK, la versión open source del kit de desarrollo, apoyada principalmente por la propia Oracle.

El JDK 11 inicia una nueva era en la licencia de uso. Hasta ahora podías descargar y programar con el Kit de Desarrollo de Java oficial de Oracle y luego poner tu aplicación en producción o distribuirla sin tener que pagar nada al gigante del software. Sin embargo, a partir de Java 11 y el JDK 11, aunque puedes seguir desarrollando con él, tendrás que pagar una licencia a Oracle si quieres utilizarlo para poner las aplicaciones en producción. El coste es de 2,5 dólares al mes por cada usuario de escritorio, y de 25 dólares por procesador en el caso de aplicaciones de servidor. Aquí tienes la lista de precios oficial.

Esto no afecta a versiones anteriores del JDK, por lo que si usas Java 8, 9 o 10 sigue siendo gratuito.

Además de la nueva licencia y el coste asociado, existe otra novedad: desde Java 9 Oracle se ha comprometido a sacar una nueva versión "mayor" de Java (y del JDK) cada 6 meses, con dos actualizaciones garantizadas entre ellas: una al mes del lanzamiento (la x.0.1) y otra al cabo de tres meses (la x.0.2). Después tendrás que actualizarte a la versión "mayor" siguiente, que sale a los 6 meses. Esto es un problema para muchas organizaciones puesto que un cambio de versión muchas veces supone problemas e inestabilidad. Es por eso que una gran mayoría de empresas sigue todavía con Java 8 a pesar de las nuevas versiones que han aparecido.

Bien, pues Java 11 es la primera versión de Java un JDK denominado LTS o Long Term Support. Esto significa que Oracle garantiza que te dará soporte y actualizaciones para la versión durante 3 años, en lugar de tan solo 6 meses. Eso sí, a cambio de un "módico" precio (¿sabes cómo se lee "Oracle" del revés? Pues eso...).

Esto es muy interesante para las grandes empresas, porque se aseguran que tienen soporte y actualizaciones del JDK oficial durante bastante tiempo (aunque seguramente menos de lo que les gustaría), y no les importa pagar a Oracle por el privilegio del soporte y de las licencias de uso. Pero es un grave problema para los desarrolladores individuales y las empresas pequeñas.

 

¿Qué opciones tenemos?

Que no cunda el pánico. No es necesario que te quedes con el JDK 8 o 9 para no tener que pagar licencia, perdiéndote además las novedades que surjan en la plataforma. Además, es importante seguir avanzando...

Hasta hace poco, el OpenJDK era el patito feo de los SDKs de Java. El JDK oficial tenía más cosas, era más estable y además gratuito, por lo que el JDK siempre ha sido la opción por defecto para programar con Java

Sin embargo, sabiendo los cambios de licencias que estaban preparando, Oracle ha trabajado muy duro para hacer que el OpenJDK se haya equiparado en todos los aspectos al JDK, hasta el punto de que se puede decir que el OpenJDK y el JDK son idénticos desde un punto de vista técnico, desde la versión 11.

Debido a ello, ahora el OpenJDK debería ser tu opción por defecto para programar en Java.

¿Cuál es la pega entonces? Nos pasamos al OpenJDK y punto ¿no?

Dos problemas... y sus soluciones

Fundamentalmente el uso del OpenJDK implica que tienes que lidiar con dos posibles problemas: las actualizaciones y el soporte.

En teoría, el OpenJDK seguirá la cadencia de lanzamientos que describíamos antes: una versión grande cada 6 meses con dos intermedias programadas. Si quieres soporte a más largo plazo, en teoría, no lo obtendrás y tendrás que ir subiendo de versión.

En cuanto al soporte tienes dos opciones:

  1. Tratar de que te ayude, gratis, la comunidad del OpenJDK
  2. Pagarle a alguien para que te dé soporte comercial (aunque Oracle no es la única opción (tienes a IBM o a Redhat que también lo dan), sí es la fuente y la que la mayor parte de las empresas usarán)

Esto puede ser un problema para algunas empresas, sobre todo si buscan estabilidad, y es a lo que juega Oracle con su JDK: ¿quieres soporte y actualizaciones a largo plazo? Pues paga.

Por suerte, siempre suele haber solución para casi todo.

En primer lugar, la comunidad de OpenJDK está hablando de que habrá al menos actualizaciones públicas de cada versión durante 4 años (más incluso que el LTS del JDK). Lo malo es que eso incluye tan solo el código fuente, y si queremos el producto final (clases base, herramientas, compiladores...) tendríamos que compilarlo nosotros mismos, lo cual no siempre es fácil, y mucho menos directo. Por suerte existe una comunidad dentro de OpenJDK llamada AdoptOpenJDK cuyo objetivo es precisamente facilitar el uso de éste proporcionando versiones compiladas del OpenJDK para descarga y usos directos. A través de este proyecto podemos descargar cualquier versión del OpenJDK compilado para su uso en múltiples sistemas operativos. ¡Genial!

En cuanto al soporte... eso es harina de otro costal. O pagamos por él o tendremos que confiar en la comunidad. Por suerte es una comunidad grande y fuerte, y con los cambios de licencia de Java 11 aún lo será más, así que no deberíamos tener problema. Por otro lado, Stackoverflow es tu mejor amigo, ya sabes...

En resumen

Con Java 11 se inaugura una nueva era en la plataforma Java. Ahora el JDK ya no es gratuito y deberás pagar una licencia mensual por usuario o por procesador si quieres usarlo en producción. Además, el soporte técnico también es de pago y si lo quieres a largo plazo (3 años). Java 11 de hecho es la primera versión LTS (soporte a largo plazo) oficial de la plataforma Java.

Esto no significa que Java deje de ser gratuito, ni es una gran tragedia para la plataforma tampoco. Para la mayoría de desarrolladores y empresas no habrá una gran diferencia. El desarrollo se trasladará a OpenJDK (que ahora es equiparable al JDK) en lugar de al tradicional JDK de Oracle, y el soporte se obtendrá de la comunidad. Para ciertas grandes empresas y administraciones, el hecho de pagar no les importará y de hecho será una ventaja porque tendrán garantizada la estabilidad y el soporte directo de Oracle durante unos años.

Aún así Java sigue y seguirá siendo el lenguaje más popular del mundo, y el que más puestos de trabajo genera, así que merece la pena aprenderlo bien.

¡Ya estás tardando en actualizar tus herramientas de desarrollo Java y el SDK subyacente para usar OpenJDK!

¡Ah!, y por cierto, si te preguntas qué novedades hay de verdad en la plataforma... quitando la palabra clave var (copiada descaradamente de C#), el nuevo recolector de basura y el "Flight Recorder" el framework para recopilar datos para diagnosticar aplicaciones, poco hay que contar...

Referencias

Conviértete en un desarrollador con trabajo en menos de un año (no sin esfuerzo)

28/09/2018
Artículo original

¿Alguna vez te has planteado la posibilidad de convertirte en un desarrollador de software? ¿Estás buscando alguna forma de reorientar tu carrera profesional? En este artículo te propondré algunas ideas para que puedas empezar en el desarrollo de software y algunos consejos para que encuentres tu primer empleo en el sector en menos de un año.

¿Por qué dedicarte al desarrollo de software?

Si estás barajando la idea de formarte en el desarrollo de software, pero no estás seguro de si es una buena idea, aquí van unos cuantos datos para que saques tus propias conclusiones:

  1. Hay muchísima demanda de desarrolladores en este momento. En España solo este año 2018 se estima que hay al menos 10.000 puestos de trabajo de programación que no se cubren por falta de personal cualificado, siendo este número de unos 900.000 en toda la Unión Europea. Según el informe publicado por Infojobs sobre las ofertas difundidas en su portal de empleo, por ejemplo, el año pasado se publicaron 9.822 ofertas de empleo de desarrollador Web (Front o Back End), siendo el número de candidatos medio que se postularon a cada oferta de tan solo 6. En el caso de desarrolladores móviles se publicaron 6.253 ofertas con una media de inscritos de tan solo 5. El número de puestos de trabajo que requieren habilidades tecnológicas aumentará en 16 millones para el año 2020, según datos de la Unión Europea recogidos en el Informe IMMUNE sobre el estado del Coding en el mercado laboral actual y futuro. Además, esta demanda de profesionales cualificados en el sector TIC crece un 3% cada año. Una demanda que no se cubre con el número actual de profesionales ni de recién graduados que salen de las universidades españolas.

  2. Las tareas pueden ser muy variadas e interesantes. Como desarrollador puedes dedicarte a trabajar en una amplísima gama de proyectos que van desde el desarrollo de aplicaciones empresariales a aplicaciones móviles, programación de autómatas, vídeo-juegos o inteligencia artificial.

  3. El trabajo puede ser muy flexible. Dado que la mayor parte del tiempo se dedica a leer y escribir código, todo lo que necesitas es un ordenador. Esto conlleva el hecho de que se puede trabajar desde cualquier sitio, y a cualquier hora. Cada año crece el número de desarrolladores que teletrabajan e incluso he conocido alguno que se dedica a trabajar mientras viaja por el mundo.

  4. Te tiene que gustar y generar curiosidad. Esta razón debe ser la más importante. El mercado laboral sufre el dilema vocacional porque las carreras más demandas son las menos elegidas por los estudiantes después del primer año, ya que el abandono es mayor en el área de ingeniería y especialmente en informática. Si no te gusta nunca serás bueno en ello, y si no eres bueno en ello no crecerás profesionalmente. Da igual que haya miles de ofertas laborales, que los sueldos estén por encima de la media y que puedas teletrabajar. Tienes que sentir curiosidad porque es una profesión que exige estar formándose constantemente y en muchas ocasiones tendrás que resolver problemas sin ayuda de nadie. Nadie dijo que convertirse en desarrollador iba a ser fácil.

¿Cómo convertirse en desarrollador?

Ser desarrollador exige tener muchas destrezas. Para mejorar cualquier destreza hay básicamente dos cosas que son determinantes: practicar eficientemente y tener la ayuda de un experto, a modo de tutor o de mentor.

En el desarrollo de software, la mejor forma de aprender a programar es programando, con el apoyo de un desarrollador sénior que te guíe en los momentos de mayor dificultad. Maximizando estos dos factores podrás convertirte en un gran desarrollador. Si quieres empezar rápido y ponerte manos a la obra, hay varias cosas que puedes intentar hacer desde ya para dar comienzo a tu carrera de desarrollador de software:

Consigue un mentor

Esto es lo ideal: empezar a aprender a programar y tener detrás a un desarrollador experto ejerciendo de mentor y tutor. Puede ser un amigo, un familiar, o un desarrollador que conoces y quiere echarte una mano (rara avis porque siempre están ocupados). Tener alguien a quien recurrir cuando llegas a un callejón sin salida es muy útil. Además, tener a alguien que va midiendo tus progresos y con quien adquirir un compromiso personal de dedicarle tiempo y esfuerzo a tus estudios te puede ayudar a ser constante y no perder el ritmo.

Todo esto suena genial. En teoría, claro. Conseguir un mentor es realmente complicado. No todo el mundo conoce a alguien que trabaja como desarrollador y también supone mucho trabajo para el mentor. Y si conoces a un desarrollador, sabrás que siempre están ocupados e igual se niegan a ejercer de tutor, y eso es una decisión comprensible que tienes que acatar y respetar.

Encuentra un puesto de trabajo en una empresa de desarrollo

Esto quizás suene a hacer trampas, ya que lo normal es ser capaz de desarrollar algo antes de obtener un trabajo. No es lo que parece. Las empresas de software necesitan perfiles de todo tipo: administrativos, comerciales, técnicos de marketing, diseñadores, etc... Lo bueno de poder conseguir un puesto de trabajo en una empresa de software es que puede suponer un empujón en una fase temprana de tu formación, de repente se te abre el cielo de par en par ya que tendrás un sueldo (aunque sea modesto, incluso de becario o en prácticas) y puedes optar a formarte en temas de programación mientras trabajas cerca de desarrolladores seniors. ¿Qué más se puede pedir? Puedes pedir formación a la empresa y con el tiempo alguno de tus compañeros puede ejercer de tutor.

Trabajar en una empresa de desarrollo también te pondrá en contacto directo con la realidad del negocio, y con la cultura del trabajo de los programadores de software, que es algo que no se aprende simplemente estudiando un oficio. Esta faceta es importantísima, ya que no tiene sentido invertir recursos en un software que nadie quiere, y tratar con el cliente o el usuario final es una destreza "blanda" que lleva su tiempo adquirir.

Hay que tener un plan

No es fácil conseguir un mentor, ni tampoco un empleo en una empresa de software y reciclarse internamente. Estos consejos solo son factibles para una minoría. Dado que no todo el mundo se puede permitir lo anterior, vamos a idear un plan para poder aprender a programar y poder optar a un puesto de trabajo como desarrollador. Deberá ser un plan realista y asequible para una gran mayoría.

Busca el puesto que te encaje y que te guste

Para poder crear un plan necesitas tener claro cuál es tu objetivo. En este artículo nos hemos creado el objetivo de aprender a programar en un tiempo razonablemente corto (11-12 meses) para poder optar a un puesto de trabajo como desarrollador. Cuanto antes consigas meter la cabeza como programador en una empresa, mejor, ya que una vez que te contratan tu ritmo de aprendizaje se incrementará de manera exponencial puesto que estarás programando cosas todos los días y contarás con el apoyo de tus compañeros más experimentados.

Como decíamos en la introducción, hay muchos campos en la industria del software, desde el BigData hasta la Inteligencia Artificial o el desarrollo de vídeo-juegos... Pero si queremos tener un plan factible de inicio y dentro de un plazo razonablemente corto, lo mejor hoy en día quizás es empezar por el desarrollo web, con la idea de seguir progresando hasta convertirse en un desarrollador full-stack. Si tu idea pasa por llegar a programar otras cosas no pasa nada, empezar en programación web no quiere decir que tengas que dedicarte a ello toda la vida. Aprenderás muchísimas cosas que luego podrás transferir y aplicar en el campo que finalmente elijas.

Como lo que buscamos es aprender a programar y poder estar en el mercado en un tiempo razonablemente corto, cuando buscamos en internet por ofertas de desarrollador web, en el momento de escribir esto, solo en el portal de InfoJobs encontramos casi 1.400 ofertas en España, y en el portal Indeed casi 2.200.

Si filtramos un poco más, y hacemos la búsqueda añadiendo "junior" (desarrollador web junior) todas las ofertas en general piden una serie de habilidades comunes mínimas:

  • Habilidades de maquetación Front-End: HTML, CSS y JavaScript, y bibliotecas jQuery, BootStrap o AJAX.
  • Conocimientos de técnicas Responsive y Adaptative para diferentes sistemas, navegadores y dispositivos
  • Conocimiento de algún framework de JavaScript, normalmente Angular o React.
  • Conocimientos de herramientas de control de versiones, principalmente Git
  • Dominio de algunas de las herramientas específicas para desarrollo Front-End como Webpack o Gulp.

Por lo general, esos son actualmente los requisitos para poder optar a un puesto de desarrollador web junior. Adicionalmente, muchas ofertas también piden conocimientos en PHP, conocimientos de bases de datos SQL, gestión de dominios y DNS, ECMAScript, dominio de algún CMS, con sus themes y desarrollo de plugins, y demás, pero generalmente son ofertas "ornitorrinco", que no tienen mucho sentido, ya que mezclan el Front con el Back, diseñadores web con programadores web, cosas de sistemas con desarrollo, etc...

La lista anterior es una base estupenda, si la dominas, para poder trabajar como desarrollador Web Front-End y poder más adelante "volar" y acaparar otro tipo de puestos (si es que el de Front-End se te queda corto, que no tiene por qué ser así ya que es muy completo).

Ya tenemos una idea de lo que tenemos que aprender, ¿y ahora qué? ¿cuál es el plan?

Crear un plan

A la hora de elaborar un plan para aprender los requisitos enunciados podemos intentar hacerlo online con recursos gratuitos. Es factible. Todos los recursos necesarios para aprender desarrollo web abundan por Internet. Incluso te puede llegar a abrumar.

Los grandes inconvenientes de hacerlo así son varios:

  • La información online está desestructurada y no suelen seguir una metodología pedagógica
  • Se necesita un alto grado de auto-motivación para aprender, sobre todo si partes de cero
  • Estás solo y es muy fácil quedarse atascado y desistir
  • Si partes de cero, es difícil delimitar cuánto se tiene que profundizar en cada materia y qué cosas son las importantes

Decíamos antes que un plan que no se puede llevar a cabo, no es un plan. Por ello, mi recomendación para cumplir nuestro objetivo de convertirnos en un desarrollador web en menos de un año pasa necesariamente por un curso online completo que cubra todos los bloques imprescindibles, estructurado, con método, que te empuje a avanzar y que te de apoyo en los momentos de frustración y duda.

Si estás convencido, tenemos lo que estás buscando.

Máster online Desarrollo Web Front-End

Te presentamos la 8ª edición de nuestro exitoso Máster Online especializado en Programación Web Front-End. En él encontrarás los mejores contenidos en español y los mejores tutores para que, en solo 11 meses, estés en condiciones de ejercer profesionalmente. En serio, pero tienes que trabajar mucho.

Este programa MASTER de campusMVP está diseñado para que puedas estar en condiciones de trabajar profesionalmente en programación web Front-End en 11 meses con una dedicación estimada de entre 7 y 9 horas a la semana (entre 300 y 360 horas de dedicación total estimada). Viene avalado por la reconocida calidad de campusMVP y las 7 exitosas ediciones anteriores. Y siempre lo estamos mejorando con los últimos conceptos y contenidos.

Durante todo el proceso, para resolver todas tus dudas, tendrás contacto directo con nuestros tutores expertos, que son los mismos conocidos profesionales que han creado los contenidos del Máster y que resolverán todas tus dudas.

Además de nuestras tutorías convencionales (contacto directo, respuesta en menos de 1 día laborable), en esta edición del Máster, si el tutor lo considera oportuno, tendrás la oportunidad de recibir tutorías “uno a uno” en directo, con audio, vídeo y la posibilidad de compartir la pantalla. De este modo si se te atraganta algo, el tutor estará más presente que nunca para ayudarte aún mejor.

Los contenidos de este máster cubren los requisitos necesarios indicados anteriormente para encontrar un puesto de trabajo:

  • HTML y CSS para desarrolladores
  • Responsive Web Design
  • Programación con JavaScript
  • jQuery
  • ECMAScript
  • APIS avanzadas de HTML5
  • Control de código fuente con Git
  • Angular
  • Herramientas de desarrollo Front-End

En todos estos bloques se parte de cero para llegar a un nivel profesional de conocimientos y experiencia práctica.

Te advertimos de que hay que trabajar duro, pero con lo aprendido podrás abordar con garantías puestos de trabajo relacionados con esta materia, y sabrás más de estas temáticas que la mayor parte de los programadores que encuentras por ahí en las empresas. En lugar de centrarse tan solo en la última biblioteca de moda, terminas dominando todos los conceptos para poder crecer por tu cuenta a medida que la tecnología cambie en unos años.

Si quieres más información consulta la ficha completa de este curso o ponte directamente en contacto con nosotros.

Página Anterior Página Siguiente