Azure Web Apps #3 - Asociando dominios a tu Web App

16/02/2018
Artículo original

En las dos entregas anteriores hemos estudiado qué son las Plataformas como Servicio o PaaS, en qué consiste el PaaS de Azure y sus ventajas e inconvenientes, y hemos creado nuestra primera Web App real en Azure, la hemos configurado y la hemos puesto en marcha.

En la entrega de hoy vamos a ver cómo poner a andar el servicio con su propio dominio asignado.

Allá vamos.

Asignación de dominios

Una vez que tenemos nuestra aplicación funcionando sin problemas en el dominio por defecto que nos otorga Azure Web Apps, es hora de pasarlo a producción y empezar a utilizar el dominio definitivo. Ya veremos que es un proceso que, aunque sencillo, no está exento de problemas.

Para conseguirlo debemos acudir al apartado Custom Domains de las herramientas de la Web App, en el lateral. Al acceder a este apartado se nos mostrará la dirección IP que nos han asignado para que la aplicación se vea desde el exterior, y una lista con los dominios actualmente asociados a la misma (en este momento solo el predeterminado). Tenemos la opción de añadirlo usando el botón con un + que tenemos encima de la lista:

Añadir dominio propio en Azure Web App

Por regla general vamos a querer que nuestra aplicación o sitio web responda al menos a dos dominios: el de nivel superior y el subdominio www, ya que casi todo el mundo utiliza este último por tradición.

Nota: de cara a mejorar el posicionamiento SEO (Search Engine Optimization) y que el dominio se posicione bien, es importante que los rastreadores de los buscadores vean un único dominio y no estos dos. Existen otros modos de conseguirlo (por ejemplo con cabeceras de URL canónica), pero lo habitual es que uno de ellas prevalezca sobre el otro y pongamos una redirección permanente. Esto se puede conseguir mediante configuración del servidor web o que lo haga la propia aplicación. En el caso de mi blog, la propia aplicación tiene un ajuste para ello como vimos en el artículo anterior, y siempre te lleva al subdominio con la www.

Al pulsar en el + debemos introducir el nombre del dominio o subdominio que queremos añadir, como se ve en la captura anterior, y acto seguido pulsamos el botón de validar.

La validación se debe hacer de una de dos maneras, indicadas en la propia pantalla, pero ambas pasan por tocar el servidor DNS del dominio.

Opción 1: Entradas DNS de tipo "A" y "TXT"

La primera de ellas es mediante el uso de una entrada de tipo "A", de las que apuntan a una IP directamente, en el servidor DNS:

Opción 1 de validación del dominio

Es decir, se trata de ir a la configuración del servidor DNS para tu dominio y cambiar la entrada de tipo "A" para que pase a apuntar a la nueva IP que te asigna Azure. Además es necesario introducir una entrada de tipo "TXT" con el nombre de dominio por defecto que tengas asociado en la Web App (en mi caso jasoft.azurewebsites.net como ya hemos visto anteriormente).

Opción 2: Entrada DNS de tipo "CNAME"

La otra opción, más sencilla, consiste en añadir una entrada de tipo "CNAME" que apunte al dominio por defecto que tienes asignado:

Opción 2 de validación del dominio

Cambiando las entradas DNS

Sea cual sea la opción que elijas, la modificación de estas entradas DNS se hará de manera similar, aunque dependerá de las facilidades que proporcione tu proveedor de dominios.

Lo más habitual es que el que te vendió el dominio (GoDaddy, Arsys, One2One...) te ofrezca una sencilla interfaz para crear entradas, editarlas y eliminarlas.

Nota: la propia Microsoft te vende directamente el dominio en Azure si no tienes uno, desde el mismo apartado (abajo) y aun precio bastante competitivo:

Comprar dominio en Azure

Por ejemplo, en Arsys (que es donde los suelo comprar yo) puedes ir al panel de control desde el área de cliente y en la opción de Web > Entradas DNS tienes un listado de lo más sencillo en el que puedes añadir, eliminar y editar las entradas (aquí estoy editando):

editando entrada DNS en Arsys

En el caso del ejemplo que estoy utilizando, mi blog en JASoft.org, el servidor de DNS lo gestiona CloudFlare. En el caso de CloudFlare es incluso más fácil pues puedes editar el listado directamente con solo pulsar.

MUY IMPORTANTE: Si utilizas CloudFlare para gestionar las DNS de tu dominio, debes deshabilitar durante un rato la función de proxy de este servicio. Es decir, debes evitar que CloudFlare esté situado entre Internet y tu servidor. El motivo es que si está actuando de proxy (la manera normal), la entrada DNS se resuelve a una IP de Cloudflare (que es el que a su vez se conecta a tu servidor), pero no devuelve la IP real del servidor (de Azure en este caso). Debido a ello, cuando Azure intente hacer la comprobación no lo conseguirá.

Por lo tanto lo que tienes que hacer es, aparte de cambiar la IP, deshabilitar el proxy pulsando el botón de la nube naranja que tienes a la derecha en el listado:

Editar entrada DNS en Cloudflare y deshabilitar el proxy

En la figura anterior vemos como he configurado con la opción 1, o sea, la entrada "TXT" apuntando al dominio por defecto y la "A" apuntando a la IP que me ha dado Azure. Podría haber hecho como ejemplo la segunda opción, que implicaría una única entrada DNS. Si lo haces así y ya tenías una entrada "A" para el mismo dominio o subdominio, no te olvides de eliminarla antes

Una vez hechos los cambios hay que volver a la pantalla de Azure y pulsar en el botón de Validar en la parte superior.

Ten en cuenta que aunque el cambio de DNS es instantáneo, su replicación a lo largo de Internet puede llevar varias horas. Es posible que en ese ínterin la web deje de funcionar par algunos usuarios si ya la tenías albergada en otro lado. De todos modos, en mi experiencia el proceso es rapidísmo y si tu Web App y tu servidor de DNS están más o menos próximos geográficamente, el cambio es casi inmediato. Un buen consejo (sacado más de mi intuición que de una constatación real) sería que no le des a Validar ninguna vez, hasta que haya creado/editado las entradas en el servidor DNS. Así evitas que se cacheen y que tenga que pasar un rato antes de que Azure invalide esa caché.

Otra cosa importante a tener en cuenta es que el listado de dominios asociados a tu Web App en Azure puede tardar bastante rato en reflejar que el nuevo dominio ya está añadido, incluso aunque ya lo este y esté funcionando perfectamente. Yo creo que es un fallo. Mi recomendación es que, si pulsas en Validar y te dice que está todo bien, refresques la página del portal de Azure con F5 para ver si se actualiza el listado "a las bravas". Si aún sí sigue sin aparecer, no te preocupes: una vez validado ya estará funcionando y no tendrás problema. ya te aparecerá un poco más tarde.

Si usas Cloudflare no te olvides de volver a activar el proxy de nuevo en cuanto hayas validado el dominio en Azure. Si no lo haces dejarás de sacarle partido a los servicios de caché, protección, etc.. que te proporciona CloudFlare.

Con esto tu aplicación ya está totalmente integrada en Azure y funcionando en real.

Puede ser interesante que para distinguir la app que funciona en Azure de la que tenías en otro servidor anterior, le pusieses algo en el código diferente al servidor original (por ejemplo un comentario adicional en el HTML, visible solo en el código fuente de la página principal). Así podrás comprobar que realmente las peticiones están llegando desde Azure.

Espera un par de días para asegurarte de que las DNS se han propagado a todo el mundo y si quieres elimina la app del anterior servidor en el que la tuvieses (si usas Cloudflare, en cuanto lo actives de nuevo para el dominio ya puedes tener la seguridad de que está funcionando contra Azure, ya que el DNS resolverá a Cloudflare y las peticiones a Azure las hará Cloudflare).

En resumen

Hemos visto cómo poner a andar el servicio con uno o más dominios propios. Para dejarlo totalmente listo, lo único que nos queda es asociarle certificados digitales para poder habilitar las comunicaciones seguras, lo cual es algo casi indispensable en la actualidad.

Como esto es un tema que tiene bastante que desarrollar, lo dejamos para el siguiente post, que publicaré mañana o pasado.

¡Hasta pronto!

DotNet2018: El evento del año para la comunidad de desarrolladores .NET

15/02/2018
Artículo original

Apúntate la fecha en el calendario y márcala en rojo: 29 de Mayo de 2018. Ese día se celebrará en el Teatro Goya Multiespacio de Madrid, el DotNet2018, el evento más importante del año para la comunidad de desarrolladores de software con .NET.

Durante el evento se desarrollarán 24 sesiones a lo largo de 4 tracks, con mención especial para la keynote inicial a cargo de nada menos que Scott Hunter (Director de Program Management en Microsoft) y James Montemagno (Especialista en herramientas de desarrollo móvil y Principal Program Manager en Microsoft).

Este año, de la organización se encargan nada menos que los chicos de Plain Concepts, quienes, poco a poco, nos han ido desvelando los nombres de los ponentes, todos ellos de un gran nivel y muy bien valorados por la comunidad. Aparte de Scott Hunter, te encontrarás nombres como el de Diego Vega, Rodrigo Corral, César de la Torre o Chema Alonso.

Pero no solo lo decimos por las caras más conocidas. Si asistes, seguro que te llevas más de una grata sorpresa con lo que aprenderás de los ponentes menos mediáticos.

Por nuestra parte, no solo somos orgullosos patrocinadores de este magno evento (y nos verás por allí) sino que te encontrarás a unos cuantos de nuestros tutores entre los ponentes del evento, como son:

  • Javier Suárez (VS & Development Technologies y Windows MVP,
    Xamarin MVP y, por supuesto, nuestro especialista en Xamarin)
  • el gran Eduard Tomás (Web Development Technologies MVP y co-autor del curso de JavaScript avanzado)
  • José Manuel Alarcón (Más de 11 años como MVP en tecnologías web y director de campusMVP).

Nuestra estelar alineación titular para el DotNet2018

Si te interesa el mundo del desarrollo, y especialmente .NET, hazte ya con tu entrada a través de Eventbrite. No pierdas tiempo porque van a volar y esta es una ocasión única para aprender muchísimo a la vez que haces terapia y te relacionas con otros desarrolladores como tú.

Aparte de aprender toneladas de cosas interesantes, es una magnífica ocasión de desvirtualizar gente o reencontrarse con viejos conocidos. Y si no sueles participar y te da vergüenza asistir a este tipo de eventos, anímate, de verdad. Aprenderás muchísimo.

Además, en pocos sitios encontrarás gente tan afín a ti y todos estamos deseando conocerte.

Solo faltas tú. ;-)

"Nuestro objetivo es ofrecer el mejor curso de programación web front-end a mujeres", entrevista a Adalab

15/02/2018
Artículo original

Adalab

Mediodía de una mañana tan brillante como fría en Madrid. Estoy aterrizando en el espacio de coworking en donde tiene situadas sus oficinas y aulas Adalab. Y me reciben sonrientes los tres socios: Inés, Rosario e Israel.

Se nota que no les va nada mal. La oficina es espaciosa, conformada como un dúplex. Y el aula que se vislumbra al final del pasillo en el piso superior, es amplia como para impartir clases a más de 30 personas a la vez.

Durante la entrevista, lo que más ha habido son sonrisas, y un derroche de inteligencia y sentido común. Aunque aparentan juventud, sin duda estas tres personas saben lo que hacen y transmiten muy bien sus pensamientos.

Y así, en unos chillones sillones naranja, empezamos un intenso diálogo que superaría la hora y media de duración.

Veo que en la web que vuestra formación está dirigida a féminas ¿Cómo surgió la idea de una formación solo para mujeres?

La idea de Adalab viene de que trabajamos en cooperación internacional, en proyectos de formación e inserción laboral principalmente en América latina y Asia. Y volvimos a España a finales del 2015.

Nosotras siempre habíamos hablado de la posibilidad de montar una empresa social, y nos pusimos a buscar ideas que pudiesen funcionar; que se centrasen en facilitar posibilidades de inserción a personas que no tienen una inserción laboral de calidad pero de una forma sostenible.

Empezamos a ver cosas que funcionan en otros países, como los bootcamps de programación e intentamos ver si en España funcionarían. Y efectivamente, la realidad era que hay muchísimo desempleo, y al mismo tiempo a las empresas les cuesta cubrir ciertos perfiles digitales y tecnológicos.

Tener una comunidad cada vez más grande de mujeres líderes del sector tecnológico.

Entonces dijimos que tiene todo el sentido del mundo hacer este tipo de proyecto en España. Ya que estábamos buscando una formación de la que hubiese una demanda creciente de puestos de trabajo y que, en relativamente poco tiempo, las estudiantes pudiesen empezar a trabajar y generar ingresos mientras se siguen formando.

Nuestra motivación inicial fue buscar un proyecto que ayudase a reducir el desempleo. Cuando nos enteramos y vimos que en este sector existe un porcentaje muy pequeño de representación de mujeres - aparte que de aquí al futuro van a crecer muchísimo todos estos puestos - y las mujeres se están quedando fuera, nos pareció mucho mejor incorporar que solo fuesen mujeres para conseguir una representación mejor.

¿Cuáles serían los objetivos que perseguís con este programa de formación?

Tenemos un triple objetivo: Reducir el desempleo apostando por una formación intensiva de calidad, que permite una inserción laboral de calidad en un sector con futuro. A la vez, contribuir a reducir la brecha de género en este sector. Y por último conseguir que nuestro programa sea accesible para cualquier mujer, independientemente de su poder adquisitivo.

Por eso nos centramos en formación en front end porque hay mucha demanda, y nos centramos en mujeres para atraer a más mujeres a una profesión con buenas oportunidades de crecimiento. Y encima orientado a mujeres desempleadas o con trabajos precarios, porque queremos reducir el desempleo.

¿Por qué escoger el sector informático para vuestros cursos, y por qué el desarrollo “front end” específicamente?

Hemos utilizado una metodología Lean Startup para poner en marcha la iniciativa, y lo primero que hicimos fue hablar con empresas, preguntarles que perfiles estaban demandando, y entre ellos estaba el de programador front end; que, además veíamos que era más fácil de asimilar para perfiles no técnicos.

Vimos un nicho que está creciendo mucho, que es un perfil especializado y que podía tener demanda. Adalab

Para alguien que ya peina canas, es un poco frustrante el ver que tenéis una limitación de acceso, hasta los 39 años.

En el primer piloto no teníamos edad y en el segundo tampoco. Lo hicieron mujeres mayores de 39 y no hicimos distinción. Pero hemos detectado que, a partir de 35 años, está el mayor porcentaje de mujeres que no acaban el curso con éxito. Y las que terminaban tenían más dificultades para insertarse laboralmente en el modelo de inserción que nosotras barajamos, que es un perfil junior con un contrato laboral en prácticas.

Si que nos hemos planteado, porque existe esa necesidad, llegar a mujeres desempleadas de más edad, ya que suele ser más difícil para ellas encontrar un empleo de calidad. Tenemos en mente diseñar un programa adaptado a sus necesidades

Partiendo de la base que para vosotros lo importante es conocer JavaScript. ¿Cuáles son las razones que os han llevado a impartir React y no Angular?

En el primer curso de “front end” no veíamos ningún framework, o librería. En el segundo lo metimos justo después de la formación como un complemento. Y decidimos que fuese React porque, al final, creemos que no es tan importante el uno o el otro, sino que se enfrenten a esa manera de estructurar las cosas.

De hecho, en las alumnas de la segunda promoción que están ya trabajando, hay algunas que están haciendo React, otras Angular y otras están haciendo otra cosa diferente. Entonces creemos que es un poco lo de menos.

Inés, Rosario e Israel son los socios, pero con Álex y Carlos, conforman el "core" de Adalab

El caso de React, pues también detectamos, sobre todo viendo ofertas de trabajo de empresas, que hay una demanda creciente en ese framework. En cuanto a Angular, vimos que cambia el lenguaje, cambian muchas cosas y, ya que estábamos enseñando JavaScript, tendríamos que enseñar otro lenguaje distinto para el framework. Entonces Angular no era el mejor encaje para un curso tan corto como el que tenemos.

Nosotros siempre nos enfocamos a las necesidades que tiene el mercado laboral, para garantizar la inserción laboral de las alumnas. Que salgan con un perfil que sean empleables, y en puestos de calidad.

Por eso nuestro temario es abierto y va evolucionando con el mercado. Cuando las alumnas empiezan a trabajar, se hace seguimiento de las empresas y les preguntamos que saben, que necesitan reformar, que les gustaría que supiesen, y en base a todas las contestaciones vamos adaptando el temario.

Sin duda el proyecto está teniendo muy buena acogida porque estáis multiplicando el número de mujeres en cada promoción. ¿Hay tantas candidatas como para tener que escoger a la gente? ¿Cómo lo hacéis?

Adalaber

Si, escogemos. Por ejemplo, en la última promoción se apuntaron 150 candidatas y aceptamos a 32. Y de hecho queremos que crezca este ratio. Necesitamos que se apunten más gente para poder elegir mejor.

Lo más importante para nosotras no es nada técnico, sino la motivación de las personas. El proceso de selección es largo, requiere invertir horas y eso, ya de por sí, significa que las personas que lo completan están muy interesadas en hacer este curso.

Primero, hacen unos tutoriales como si fuesen las primeras lecciones de programación. Que les permite, por un lado, saber si les interesa la programación -porque muchas no han tenido contacto con la programación- y, por otro lado, hacemos unas preguntas al final de los tutoriales para ver si están entendiendo lo que se supone que deben entender.

También se les hace una prueba de inglés medio, para ver que pueden leer y entender un texto técnico, y que pueden contestar preguntas sobre ese texto. Y después, en esta promoción, hemos incorporado unos psicotécnicos sobre razonamiento lógico, matemático, lingüístico y concentración.

Finalmente hay una entrevista personal de una hora, en la que lo que interesa básicamente, es su nivel de compromiso, de responsabilidad, qué cosas han hecho en el pasado que demuestre corresponsabilidad, iniciativa y demás, y entender porqué quieren hacer este curso.

Porque el curso es super demandante, y queremos garantizar que las personas que entran están dispuestas a hacer el esfuerzo que requiere conseguir un trabajo como programadora en tan solo 4 meses.

¿La formación la habéis diseñado entre los tres?

Si, a ver, la formación ahora son seis horas presenciales, de las cuales cuatro horas son formación técnica y en las otras dos horas están las otras actividades, en las cuales está el desarrollo profesional. Que damos desde comunicación en público, trabajo en equipo, herramientas para la empleabilidad o inglés.

Sin las mentores y voluntarios, no haríamos ni el 50% de las actividades.

Y luego, también cuidamos mucho en Adalab la metodología docente. No queríamos hacer un programa de: me siento cuatro horas con un señor soltándome una chapa de clase magistral, porque así no se consigue, en cuatro meses, la capacidad para trabajar. Nuestra metodología está orientada 100% a la realidad laboral.

Ahora mismo son cuatro meses, que están divididos en cinco sprint de tres semanas, trabajando en objetivos de aprendizaje individuales y proyectos grupales distintos en cada uno. Utilizamos algunos artefactos de Scrum, pero no con un fin de desarrollar un proyecto en esa metodología, sino con el de aprender.

Son cuatro bloques en el que en el primero vemos temas de maquetación en general, html, css, less, y todo lo que tiene que ver con la parte de maquetación. En el segundo empezamos con JavaScript. Las bases de un lenguaje de programación, el DOM y cómo utilizarlo en una Web. En el tercero, aspectos avanzados de maquetación como SASS, automatización de tareas con Gulp, Css Grid, y temas más avanzados de JavaScript. Y en el último vemos React.

Luego queda un quinto en el que ellas desarrollan un proyecto en colaboración con una empresa.

¿Cuántas mujeres de vuestras formaciones consigue incorporarse, finalmente, al mercado laboral?

Ahora mismo, de todas las personas que terminan el curso de AdaLab, el 81% está trabajando.

Adalaber High

¿Hay alguien más haciendo algo similar?

En España, que nosotros conozcamos, no. Si que hay muchos meetup, grupos de mujeres, asociaciones que fomentan el reducir la brecha de género o hay algunas asociaciones que hacen charlas en colegios.

Pero centradas en formación e inserción laboral en programación para mujeres, no; que nosotros conozcamos. Fuera de España sí. En los Estado Unidos, por ejemplo, sí que hay bastantes organizaciones similares, y también en Latinoamérica.

Está claro que vuestro proyecto proviene y está empapado en una perspectiva solidaría, pero ¿cuál es vuestro modelo de viabilidad?

Legalmente, somos una asociación sin ánimo de lucro. Pero nosotros, cuando creamos Adalab, teníamos vocación de emprendimiento social. Lo que pasa es que en España las empresas sociales no existen como tal y tuvimos que buscar la forma jurídica que más se adaptaba a lo que queríamos hacer.

No tenemos ánimo de lucro, pero tampoco ánimo de pérdida.

Nosotros damos formación, y queremos que esta sea accesible a todo el mundo. Son cuatro meses intensivos, durante los cuales las alumnas pagan una cuota de compromiso de 50 euros al mes. Y solo las que consiguen trabajo, cuando lo consiguen, pagan cuotas retroactivas durante seis meses.

Por otra parte, las empresas que contratan a la alumna también pagan una cuota. Y el porcentaje más alto, a día de hoy, viene de donaciones de fundaciones que quieran apoyar nuestra misión.

¿Habéis recibido alguna ayuda estatal para la creación o sostén de Adalab?

Si, la difusión la hemos hecho a través del Instituto de la Juventud y del Instituto de la Mujer. Pero ahora tenemos dificultades para seguir haciéndola porque solo quieren hacer difusión de cursos que son gratuitos. Entonces, al tener un modelo que es al 50% subvencionado y las alumnas solo pagan otra parte cuando empiezan a generar ingresos, pues claro, estos modelos más innovadores y que buscan cierta sostenibilidad, a la administración le cuesta más entenderlo. Adalaber

No hemos solicitado ayuda estatal. Empezamos con premios de emprendimiento, luego con fundaciones, y hemos ido encontrando los caminos para seguir creciendo. Nos gustaría encontrar financiadores que se adapten un poco a nuestra visión y enteindan nuestro modelo de sostenibilidad.

El problema de los fondos públicos es que vienen con requisitos. Y tienes que adaptar tus proyectos a los requisitos de los financiadores. Y no necesariamente es lo que más le conviene al proyecto. Por eso nosotros queremos ser independientes y decidir en cada momento lo que creemos que es mejor para nuestras alumnas. No estar pendiente de, si no hago esto no me van a dar esta financiación.

¿Tenéis pensado hacer actuaciones mixtas para hacer visible a los hombres los problemas de las mujeres en entornos laborales y educativos tecnológicos, que han hecho que abandonen la industria desde los años 80 del siglo pasado?

Ahora mismo Adalab está muy centrado en formación. Nosotros, a día de hoy, no nos consideramos expertos en esta materia, o sea no tenemos desarrollado unos conocimientos para ilustrar a otros sobre cómo atraer a más mujeres, o como hacerlo mejor. Nosotros, creo que estamos aprendiendo muchas cosas en nuestro desarrollo pero, a día de hoy, en lo que estamos centrados en formación e inserción, de manera inclusiva, para que todas las mujeres se puedan apuntar, involucrando a toda la comunidad de programación. Y eso sí que lo sabemos hacer.

Nuestros voluntarios son tanto hombres como mujeres y, sin el apoyo de ellos, la mitad de las cosas que hacemos

Impulsamos a mujeres jóvenes con dificultades de empleabilidad, para que se conviertan en profesionales líderes del mundo digital.

en Adalab no serían posibles. Estos voluntarios se acercan a nosotros porque quieren aportar a construir un proyecto que apuesta por la diversidad. Entonces allí es dónde creemos que estamos haciendo ese mix a la hora de involucrar a toda la comunidad.

Pero sí, nos gustaría, en la medida que podamos crecer en equipo, invertir más en esto; sacar más partido de nuestra comunidad de voluntarios; y divulgar la misión de que haya más mujeres.

A día de hoy, no lo podemos hacer porque no lo podemos abarcar todo. Pero si es algo que tenemos en mente el crear, a lo mejor, un evento anual nuestro sobre esta temática para hombres y para mujeres.

Miremos hacia adelante, buscando con la vista un horizonte. ¿Cuál son vuestros planes de futuro?

Siempre que hablamos del crecimiento de AdaLab lo vemos de dos formas. Uno, es llegar a más mujeres. O sea, poder hacer más programas; y que más mujeres se apunten y puedan acceder a nuestra formación; y que se puedan insertar y ofrecer más talento a las empresas. Y por otro lado ofrecer perfiles diferentes, no solamente centrarnos en Front, sino evaluar otros perfiles.

Nosotros queremos un crecimiento que nos permita tener la calidad suficiente en cada una de las cosas que hacemos.

No es una cosa de: quiero estar en el mundo de entero. Si logramos conseguir la calidad en la formación que se necesita, en cada uno de los cursos, pues a seguir creciendo. Pero si crecer significa hacer las cosas con menor calidad o llegar menos a las personas, entonces no vamos a pasar por allí. Por ejemplo, nos ofrecieron irnos a otra ciudad el año pasado, y dijimos que todavía no estábamos listos.

Y también tenemos visión de mejorar nuestra comunidad. Empezar a hacer más eventos para promover que haya más mujeres en programación, y divulgar más nuestra misión.

Tenemos un programa de mentoring, que es solo para mujeres. Cada alumna tiene una mentora programadora con años de experiencia que le ayuda en su desarrollo profesional. Lo que queremos es que después nuestras alumnas sean mentoras de las siguientes y sean un referente para ellas.

Queremos que nuestras alumnas sean como “role models” para otras generaciones, intentando crear esos referentes.

Más información | Adalab

Adalaber 05

También te recomendamos

Plisados, lino, satén: te contamos cómo planchar las prendas más valiosas de tu armario y ahorrarte la tintorería

Así consiguió la Universidad de Carnegie Mellon aumentar el 35% al número de mujeres matriculadas en informática

Nace Adetik, un foro para denunciar la precariedad del sector informático

-
La noticia "Nuestro objetivo es ofrecer el mejor curso de programación web front-end a mujeres", entrevista a Adalab fue publicada originalmente en Genbeta Dev por Juan Quijano .

Por San Valentín, enamórate de nuestros cursos con descuento y sin sorpresas

14/02/2018
Artículo original

A veces las cosas no son lo que parecen. Por eso tanto en el amor como en la formación online suele haber un temor que flota en el ambiente: ¿Y si me sale rana? De entrada parece bueno, pero ¿y si no es lo que aparenta?

Te los venden como cursazos, pero la realidad es que no va más allá de una serie de PDFs y vídeos monolíticos que caducarán en 6 meses y que sabes que dejarás a medias. Eso sí, con acceso ilimitado a material inservible.

¡Eh! ¡Un momento! ¿Y dónde está tu tutor para preguntarle?

En cambio, en campusMVP te enseñamos de verdad. Formación de alta calidad, pensada para tu día a día y con un tutor experto siempre a mano.

Y, al terminar tu curso, te llevas los contenidos en PDF y un diploma certificado por campusMVP.

Si es tu primera vez en campusMVP, te vas a enamorar 

Estás de suerte. Ahora puedes hacer ese-curso-que-te-vendría-tan-bien sin riesgo y con descuento.

Esta es una ocasión magnífica para probar por primera vez nuestros cursos porque, solo hasta el 20/2/2018:

  • Te damos un 20% de descuento. (Más abajo tienes un cupón)
  • Si el curso no te convence, te devolvemos el dinero. (Consulta más abajo las condiciones)

Y por si esto fuera poco, una vez seas antiguo alumno, tienes un 20% de descuento para siempre.

Porque nos gusta cuidar de los nuestros, sea San Valentín o no.

Yo, es que prefiero la formación presencial...

Hay mucha gente que aún cree que la formación presencial es mejor que la formación online sin haberla probado nunca. Pero lo cierto es que, la formación online bien concebida tiene muchísimas ventajas.

En campusMVP nos lo tomamos muy en serio. Nuestro principal objetivo es que aprendas, por eso:

  • Tienes acceso a profesores de primer nivel a los que, de otro modo, no podrías acceder de forma presencial. Todos ellos son expertos profesionales que usan a diario las tecnologías que enseñan y, si no fuese online, jamás podrías acceder a sus conocimientos y experiencia.
  • Durante el curso podrás preguntarle directamente tus dudas sobre los contenidos al creador del curso. Aquí no hay tutores de relleno, solo expertos.
  • Accederás al curso en cualquier momento, lo que te permite organizarte en función de tu disponibilidad. Además, la plataforma te va informando si avanzas a buen ritmo o no. Y te daremos un toque si te despistas o vas más lento de lo esperado. Sin disculpas: ¡para aprender hay que trabajar!
  • El contenido va directo al grano, a lo importante. Y mezcla teoría, vídeo, recursos externos y ejercicios prácticos en función de las necesidades de la materia para que no malgastes tu tiempo. 
  • Al finalizar el curso, no solo te llevas un diploma (si apruebas, claro) y un PDF con todos los contenidos. Dispondrás de un perfil propio en nuestra web donde nos jugamos nuestro prestigio avalando tus conocimientos.

Simplemente queremos que aprendas lo que necesitas en el menor tiempo posible. Nuestro buen nombre va en ello.

La gran ventaja para empresas y trabajadores por cuenta ajena en España

Y por si todo esto fuera poco, si trabajas en España por cuenta ajena, la práctica totalidad de nuestros cursos se pueden bonificar a través de Fundae (la antigua Fundación Tripartita). O sea, que en la práctica os podría salir gratis a ti y a tu empresa. Esto nos convierte en una excelente oportunidad para que las empresas tecnológicas españolas inviertan sin coste en formación de calidad para sus desarrolladores, que es su principal capital.

No es fácil encontrar cursos de programación de este nivel en español, online y además bonificables.

Y todo esto no lo decimos nosotros

La mayoría de nuestros alumnos aprueban con nota nuestros cursos en sus valoraciones finales:

  • «Me gusta el método y es de agradecer la rápida respuesta por parte del tutor que permite un avance rápido.»
  • «. Es muy completo, y tanto la teoría como los vídeos de ejemplo son fáciles de entender. Los profesores son unos cracks y lo demuestran. Cualquier duda te la responden en poco tiempo y bien explicada.»
  • «Este curso me ha sorprendido e incluso ilusionado en algunos momentos, ya que hay cosas que no sabía ni que existían y que han abierto ante mí un mundo de posibilidades, lo recomiendo 100 %.»

Estos son solo unos pocos, pero tenemos más, opiniones de personas reales, con nombres y apellidos.

El cupón y las condiciones de la promoción

Si te has leído todo hasta aquí, enhorabuena. Te has ganado el cupón con creces. Usa este código cuando compres tu curso

BBCPBSZY

Con él obtendrás tu curso con un 20% de descuento y tendrás 10 días para devolverlo si no te convence. Eso sí, siempre que aún no hayas realizado más del 25% del total del curso. En la página principal del curso, dentro de nuestra plataforma, podrás consultar qué porcentaje llevas realizado:

Este cupón no es acumulable a otras ofertas y será válido hasta el martes, 20 de febrero de 2018 a las 23:59 CET (Madrid).

Por cierto, si eres estudiante o desempleado (y puedes acreditarlo), tienes siempre un 30% de descuento con nosotros. En ese caso tienes que contactarnos antes de comprar para que te demos un cupón especial para ti

Y ya sabes, ante la más mínima duda, ponte en contacto con nosotros.

La muerte de la locura de los microservicios en 2018

13/02/2018
Artículo original

Nota: este artículo es una traducción del original "The Death of Microservice Madness in 2018" escrito por Dave Kerr y con el permiso expreso del autor. Algunos enlaces y notas se los hemos añadido nosotros para dar más contexto y que se entiendan mejor algunos conceptos.

En los dos últimos años, sobre todo, los microservicios se han convertido en un tema muy popular. La 'locura de los microservicios' viene a ser algo así:

Los de Netflix son buenísimos en devops. Netflix hace microservicios. Por lo tanto: si yo hago microservicios, seré buenísimo en devops.

Hay muchos casos en los que se ha hecho un gran esfuerzo en adoptar patrones de microservicios sin realmente comprender cómo los costes y los beneficios se aplican a las especificaciones del problema que se tiene entre manos.

Vamos a describir en detalle qué son los microservicios, por qué el patrón es tan atractivo, y también cuáles son los desafíos fundamentales que conllevan.

Terminaremos con un conjunto de preguntas que pueden servir para preguntarte a ti mismo cuando estás valorando si los microservicios son un patrón apropiado para ti. Las preguntas están al final del artículo.

Imagen decorativa - Microservicios

¿Qué son los microservicios y por qué son tan populares?

Empecemos por lo básico. Así es cómo una hipotética plataforma para compartir vídeos puede estar implementada, primero en forma monolítica (una unidad grande única) y luego en forma de microservicios:

Aplicación monolítica frente a microservicios

La diferencia entre los dos sistemas es que el primero es una unidad grande única: un monolito. La segunda es un conjunto de servicios pequeños y específicos. Cada servicio juega un papel concreto.

Cuando se dibuja este diagrama con este nivel de detalle, es fácil entender su atractivo. Hay un montón de ventajas potenciales:

  • Desarrollo Independiente: los componentes al ser pequeños e independientes, se pueden desarrollar por parte de pequeños equipos independientes. Un grupo de trabajo puede cambiar el servicio de 'Subir Vídeo' sin interferir en el servicio 'Transcodificar', o incluso sin saber que se están haciendo dichos cambios. La cantidad de tiempo que se necesita para aprender sobre un componente se reduce muchísimo, y es más fácil desarrollar nuevas funcionalidades.

  • Despliegue independiente: cada componente individual se puede implementar independientemente. Esto permite que las nuevas funciones se liberen con mayor velocidad y menos riesgo. Se pueden implementar correcciones o funciones para el componente 'Streaming' sin requerir que se desplieguen también otros componentes.

  • Escalabilidad independiente: cada componente se puede escalar independientemente el uno del otro. Durante las fechas con mucho tráfico cuando se liberan nuevos episodios, el componente 'Descarga' se puede escalar para manejar el aumento de carga, sin tener que escalar cada componente, lo que hace que el escalamiento elástico sea más factible y reduce los costes.

  • Reusabilidad: los componentes cumplen una función pequeña y específica. Esto significa que se pueden adaptar más fácilmente para su uso en otros sistemas, servicios o productos. El componente 'Transcodificar' podría ser utilizado por otras unidades de negocio, o incluso convertirse en un nuevo negocio, quizás ofreciendo servicios de transcodificación para otras empresas.

En este nivel de detalle, las ventajas de un modelo de microservicios sobre un modelo monolítico parecen obvias. Y si es así -¿por qué razón este patrón sólo se ha vuelto protagonista recientemente? ¿Dónde ha estado metido el resto de mi vida?

Si esto es tan genial, ¿por qué no se ha hecho antes?

Existen dos respuestas a esta pregunta. Una es que sí se ha hecho -dentro nuestras capacidades técnicas- , y la otra es que los avances técnicos más recientes nos han permitido llevarlo a un nuevo nivel.

Cuando comencé a escribir la respuesta a esta pregunta se me fue la mano y se convirtió en una descripción demasiado larga, así que realmente voy a separar parte de la explicación en otro artículo y publicarlo en el futuro. En esta entrada, voy a omitir el viaje de un solo programa a muchos programas, haré caso omiso de los ESBs (Buses de Servicio Empresarial), y de la arquitectura orientada a servicios (SOA), el diseño de componentes y contextos delimitados, y demás...

En cambio voy a decir que en muchos aspectos hemos estado haciendo esto desde hace bastante tiempo, pero con la reciente explosión en popularidad de la tecnología de contenedores (Docker en particular) y en la tecnología de orquestación (como Kubernetes, Mesos, Consul, etc...), este patrón se ha vuelto más viable a la hora de ser implementado desde un punto de vista técnico.

Así que, si damos por hecho que podemos implementar microservicios, tenemos que pensar cuidadosamente si debemos hacerlo. Ya hemos visto las ventajas teóricas, ¿pero cuáles son los retos de hacerlo?

¿Cuál es problema con los microservicios?

Si los microservicios son tan geniales, ¿Qué es lo que pasa con ellos? Aquí van algunos de los problemas que he visto.

Mayor complejidad para los desarrolladores

Las cosas se ponen mucho más difíciles para los desarrolladores. En el caso de que un desarrollador quiera trabajar estando de viaje, o en una funcionalidad que pueda abarcar muchos servicios, ese desarrollador tiene que ejecutarlos todos en su máquina, o conectarse a ellos. Esto es a menudo más complejo que simplemente ejecutar un solo programa.

Este desafío se puede mitigar parcialmente con varias herramientas, pero a medida que aumenta el número de servicios que componen un sistema, mayor es el número de desafíos a los que se enfrentan los desarrolladores cuando se ejecuta el sistema en su conjunto.

Mayor complejidad para los operadores

Para los equipos que no desarrollan servicios, pero que los mantienen, se da una explosión en la complejidad potencial. En lugar de administrar algunos servicios en ejecución, están administrando docenas, cientos o miles de servicios en ejecución. Hay más servicios, más vías de comunicación y más áreas de potencial fracaso.

Mayor complejidad para devops

Leyendo los dos puntos anteriores, puede "chirriar" que las operaciones y el desarrollo sean tratados por separado hoy en día, especialmente dada la popularidad de DevOps como práctica (de la que soy un gran defensor). ¿No puede DevOps mitigar esto?

El desafío es que muchas organizaciones siguen funcionando con equipos de desarrollo y operaciones separados- y, consecuentemente, las organizaciones que lo hacen son mucho más proclives a pasarlo mal con la adopción de microservicios.

Y para las organizaciones que sí han adoptado DevOps, sigue siendo difícil. Ser tanto desarrollador como operador ya es duro de por sí (a la vez que crítico para desarrollar un buen software), pero también lo es tener que entender los matices de los sistemas de orquestación de contenedores, especialmente sistemas que están evolucionando a un ritmo rápido, es muy difícil. Lo que me lleva al siguiente punto.

Requiere un nivel de pericia muy alto

Cuando lo hacen los expertos, los resultados pueden ser maravillosos. Pero imagínate una organización en la que las cosas no están funcionando del todo bien con un único sistema monolítico. ¿Qué razón habría para argumentar que las cosas irían mejor aumentando el número de sistemas, lo que a su vez aumenta la complejidad operativa?

Sí, con una automatización eficaz, monitorización, orquestación y demás, todo esto es posible. Pero la dificultad raramente está en la tecnología -el desafío es encontrar personas que puedan usarla de manera efectiva. Estas habilidades están actualmente muy demandas, y va a ser difícil encontrar personas capacitadas para hacerlo bien.

Los sistemas del mundo real están muy mal delimitados

En todos los ejemplos que se utilizan para describir las ventajas de los microservicios, se habla de componentes independientes. Sin embargo, en muchos casos los componentes simplemente no son independientes. Sobre el papel, ciertos dominios pueden parecer bien delimitados, pero a medida que se rasca en la superficie y se entra en detalle, puedes encontrar que son más difíciles de modelar de lo que se esperaba.

Aquí es donde las cosas pueden llegar a ponerse extremadamente complejas. Si en realidad sus límites no están bien definidos, entonces lo que sucede es que, aunque teóricamente los servicios se pueden implementar de forma aislada, te encuentras que debido a las interdependencias entre ellos, debes implementar conjuntos de servicios como un grupo, y no de forma independiente.

Esto significa que es necesario administrar versiones coherentes de los servicios probados y testados cuando trabajan juntos, y en realidad dispones de un sistema de despliegue independiente, ya que para implementar una nueva función, es necesario orquestar con cuidado el despliegue simultáneo de muchos servicios.

Se obvian con frecuencia las complejidades de estado

En el ejemplo anterior he mencionado que la implementación de funcionalidades puede requerir el despliegue simultáneo de varias versiones de varios servicios en tándem. Es tentador asumir que una estrategia basada en técnicas de despliegue e implementación sensatas puede llegar a mitigar esto: por ejemplo despliegues azules/verdes (que la mayoría de las plataformas de orquestación de servicios gestionan con poco esfuerzo), o múltiples versiones de un servicio ejecutándose en paralelo, con los canales que los consumen decidiendo qué versión utilizar.

Estas técnicas mitigan un gran número de desafíos si los servicios no tienen estado. Pero los servicios sin estado son, francamente, fáciles de gestionar. De hecho, si tienes servicios sin estado, entonces me inclinaría por obviar los microservicios en su conjunto y considerar el uso de un modelo de arquitectura sin servidor.

En realidad, muchos servicios requieren estado. Un ejemplo en nuestra hipotética plataforma para compartir vídeos podría ser el servicio de suscripción. Una nueva versión del servicio de suscripciones podría almacenar datos en la base de datos de suscripciones de forma diferente. Si estás ejecutando ambos servicios en paralelo, estás ejecutando el sistema con dos esquemas a la vez. Si realizas una implementación verde/azul y otros servicios dependen de los datos de la nueva forma, entonces deben actualizarse al mismo tiempo, y si la implementación del servicio de suscripción falla y retrocede (hace un rollback), es posible que necesiten retroceder también los otros servicios, con consecuencias en cascada.

De nuevo, puede ser tentador pensar que con bases de datos NoSQL estos problemas de esquema desaparecen, pero no es así. Las bases de datos que no imponen el esquema no conducen a sistemas de BBDD sin esquema, sólo significa que el esquema tiende a ser administrado en el nivel de la aplicación, en lugar del nivel de la base de datos. La dificultad fundamental de entender la forma de sus datos, y cómo evolucionan, no se puede evitar...

Las complejidades de la comunicación se ignoran a menudo

A medida que se construye una gran red de servicios que dependen unos de otros, es muy probable que haya mucha comunicación entre los servicios. Esto implica nuevos retos. En primer lugar, hay muchos más puntos en los que las cosas pueden fallar. Debemos contar con que las llamadas de red van a fallar, lo que significa que cuando un servicio llama a otro, debe tener en cuenta que va a tener que reintentarlo un número de veces como mínimo. Ahora, cuando un servicio tiene que potencialmente llamar a muchos servicios, terminamos teniendo entre manos una situación muy complicada.

Supón que un usuario sube un vídeo al servicio de compartir vídeos. Quizás tengamos que ejecutar el servicio de subir vídeo, pasar datos al servicio de transcodificar, actualizar las suscripciones, actualizar las recomendaciones y demás. Todas estas llamadas requieren un grado de orquestación, y si las cosas fallan necesitamos reintentarlo.

Esta lógica del reintento se puedo volver complicada de gestionar. Intentar hacer las cosas de manera sincronizada a menudo termina siendo insostenible, ya que hay muchos puntos en los que las cosas pueden ir mal. En estos caso, una solución más fiable es usar patrones asíncronos para gestionar la comunicación. El reto aquí es que los patrones asíncronos inherentemente hacen que el sistema tenga estado. Como hemos dicho en el punto anterior, los sistemas con estados y los sistemas con estados distribuidos son muy difíciles de gestionar.

Cuando un sistema de microservicios usa colas de mensajes para la comunicación dentro del servicio, lo que tienes básicamente es una gran base de datos (lo cola de mensajes o broker) que mantiene la adhesión entre los servicios. Nuevamente, aunque no parezca mucho lío de antemano, el esquema volverá a ti para explotarte en las manos. Un servicio en la versión X quizás escriba un mensaje con un formato determinado, los servicios que dependan de este mensaje también tendrán que ser actualizados cuando el servicio de envío cambie los detalles del mensaje que envía.

Sí, es posible tener servicios que puedan manejar mensajes en muchos formatos diferentes, pero esto es difícil de gestionar. Ahora, cuando se implementan nuevas versiones de servicios, hay momentos en que dos versiones diferentes de un servicio pueden estar intentando procesar mensajes desde la misma cola, quizás incluso mensajes enviados por diferentes versiones de un servicio de envío. Esto puede llevar a casuísticas complicadas incontrolables. Para evitar estas casuísticas raras, quizás sea más fácil permitir que solo existan ciertas versiones de los mensajes, lo que significa que es necesario implementar un conjunto de versiones de un conjunto de servicios como un todo coherente, asegurando que los mensajes de versiones anteriores se drenen correctamente antes.

Esto resalta de nuevo la idea de que los despliegues independientes pueden no tener el resultado esperado cuando entras a ver los detalles.

Versionar se vuelve complicado

Para mitigar las dificultades mencionadas anteriormente, las versiones deben ser gestionadas con mucho cuidado. Una vez más, puedes tender a asumir que siguiendo un estándar como SemVer se resolverá el problema. No es así. SemVer es una convención sensata que puedes usar, pero aún tendrás que hacer un seguimiento de las versiones de los servicios y de las APIs que pueden trabajar junto a ellos.

La gestión de dependencias en sistemas de software es notoriamente difícil, ya sean módulos de Node.js, módulos Java, bibliotecas C o lo que sea. Los problemas que surgen de los conflictos entre componentes independientes cuando son consumidos por una sola entidad son muy difíciles de resolver.

Estos escollos son complicados de gestionar cuando las dependencias son estáticas, y pueden ser parcheadas, actualizadas, editadas y así sucesivamente, pero si las dependencias son ellas mismas servicios en vivo, entonces probablemente no puedas simplemente actualizarlos -es posible que tengas que ejecutar muchas versiones (con la dificultad que ello conlleva y que ya hemos descrito) o tirar abajo el sistema hasta que lo puedas arreglar del todo.

Transacciones distribuidas

En las situaciones en las que necesitas la integridad de la transacción a lo largo de una operación, los microservicios se pueden convertir en un dolor de muelas. Los estados distribuidos son difíciles de manejar, hay muchas pequeñas unidades que pueden fallar y hacen que la orquestación de transacciones sea muy complicada.

Puede ser muy tentador intentar evitar el problema haciendo que las operaciones sean idempotentes (aquellas que el efecto de ejecutarlas más de una vez es el mismo), ofreciendo mecanismos de reintento y demás, y en muchos casos esto puede funcionar. Pero quizás se den escenarios en los que simplemente necesites que una transacción falle o tenga éxito, y nunca quedarse en un estado intermedio. El esfuerzo que implica trabajar para sortear esto o para implementarlo en un modelo de microservicios puede ser demasiado grande.

Los microservicios pueden llegar a ser monolitos disfrazados

Sí, los servicios y componentes individuales pueden implementarse de forma aislada, sin embargo en la mayoría de los casos vas a tener que ejecutar algún tipo de plataforma de orquestación, como Kubernetes. Si estás utilizando un servicio gestionado, como GKE de Google, EKS de Amazon o AKS de Azure, entonces una gran parte de la complejidad de administrar el clúster lo gestionan por ti.

Sin embargo, si estás administrando el clúster por tu cuenta, estás gestionando un sistema grande, complicado, de misión crítica. Aunque los servicios individuales pueden ofrecer todas las ventajas descritas anteriormente, es necesario administrar con mucho cuidado el clúster. Las implementaciones de este sistema pueden ser complejas, las actualizaciones pueden ser difíciles, la puesta en marcha de medidas de failover en caso de error pueden resultar muy complicadas y así sucesivamente...

En muchos casos los beneficios globales están ahí, pero es importante no trivializar o subestimar la complejidad adicional de administrar otro sistema grande y complejo. Los servicios gestionados pueden ayudar, pero en muchos casos estos servicios son recién nacidos y no están aún maduros (Amazon EKS fue anunciado tan sólo a finales de 2017 por ejemplo).

¡El fin de la locura de los microservicios!

Evita caer en la locura tomando decisiones ponderadas cuidadosamente. Para ayudarte en este aspecto he elaborado una serie de preguntas y respuestas para ayudarte a decidir mejor:

Diagrama: preguntas a hacerte cuando consideres usar Microservicios

Puedes descargar una copia en PDF aquí: Consideraciones-Microservicios.pdf

Un último apunte: no confundas microservicios con arquitectura

He evitado esa palabra que empieza por 'a' de forma deliberada. Pero mi amigo Zoltan me hizo un buen apunte al revisar este artículo (al cual también ha contribuido).

No existe la arquitectura de microservicios. Los microservicios son simplemente otro patrón o implementación de componentes, nada más, nada menos. Si están presentes en un sistema o no, no significa que la arquitectura del sistema esté resuelta.

Los microservicios se relacionan de muchas maneras con los procesos técnicos en torno al empaquetado y las operaciones, y no con el diseño intrínseco del sistema. Los límites apropiados de los componentes continúan siendo uno de los retos más importantes a la hora de hacer ingeniería de sistemas.

Independientemente del tamaño de tus servicios, ya estén en contenedores Docker o no, siempre tendrás que pensar cuidadosamente sobre cómo montar un sistema. No hay una respuesta válida, y hay un montón de opciones.

¡Espero que te haya resultado útil este artículo! Como siempre, por favor comenta debajo si tienes cualquiera pregunta o si quieres aportar algo a lo expuesto aquí.

También puedes seguir algunas animadas discusiones sobre el artículo en:

Apéndice: Lecturas adicionales

Los siguientes enlaces puede que te resulten de utilidad (todos en inglés):

Por favor, ¡comparte cualquier otro recurso que creas que sea una buena lectura o visionado sobre el tema!

Por qué elegir VueJS: 5 razones para considerarlo nuestro próximo framework de referencia

11/02/2018
Artículo original

Vue

A lo largo de estos años, he tenido la suerte de poder trabajar con diferentes frameworks JavaScript. Cada uno de ellos ha tenido, para mi, sus puntos fuertes y sus puntos débiles. Nunca he tenido un apego incondicional con ninguno de ellos y eso me ha hecho ver a los frameworks como lo que son: herramientas que pueden ayudarnos tanto como hacernos pasar un buen dolor de cabeza. Esto ha hecho que pueda valorar mucho qué funcionalidades son necesarias y qué argumentos tener en cuenta a la hora de decantarme por uno o por otro dependiendo del contexto en el que me he encontrado.

Viéndolo con perspectiva, en muy poco tiempo, hemos visto como estos frameworks han ido pasando por diferentes generaciones y como han ido madurando. Se podría decir que ha día de hoy, en lo que yo suelo considerar la 3ª Generación, nos encontramos con frameworks bastante maduros que nos ayudan a realizar un gran número de tareas que pueden ser ejecutados en diferentes navegadores a la vez.

ReactJS, Angular y EmberJS son los frameworks que representan un mayor uso en el mercado y que han demostrado ser una garantía de robustez y escalabilidad. A esta terna, se ha unido hace una temporada VueJS. Un framework con el que llevo trabajando durante un buen tiempo y del que he intentado estudiar cada funcionalidad.

En este post, me gustaría exponer cinco razones que han hecho que VueJS se haya convertido en mi framework JavaScript favorito. Espero que estas razones os convenzan para que en vuestra próxima prueba de concepto o proyecto personal, le deis una oportunidad.

1. Un framework para aprender y usar de manera progresiva

VueJS se autodenomina como un framework progresivo. Cuando encaramos un desarrollo con VueJS, podemos indicar qué partes del framework queremos incluir. VueJS está modularizado en diferentes librerías separadas que permiten ir añadiendo funcionalidad en el momento que las vayamos necesitando.

La modularización en librerías de un framework no es algo nuevo en el desarrollo front. Tanto ReactJS como Angular cuentan con una organización parecida de su código base. Lo que diferencia a VueJS de otras alternativas es lo bien desacopladas que se encuentran estas partes, lo fácil que es extender la funcionalidad core y lo bien que trabajan todas sus partes una vez que se decide incluir más módulos.

El core principal de VueJS está formado por una librería encargada de renderizar vistas en el navegador. Su forma de organizar el código es por medio de pequeños componentes que contienen todo el HTML, CSS y JavaScript necesario para funcionar como pieza independiente. Estas piezas se van componiendo en un árbol jerárquico de componentes hasta formar nuestra aplicación. Usar esta librería es tan fácil como importar el script en nuestra página HTML.

Si lo único que necesitamos como desarrolladores es una mejor forma de organizar y renderizar nuestros pequeños componentes visuales, nos quedamos ahí y no incluiríamos nada más. En el momento que nuestra aplicación empezase a crecer, contamos con librerías para gestionar las rutas de nuestra aplicación como vue-router o con librerías para gestionar el estado global de la aplicacion como pueda ser vuex. Si nuestra aplicación tuviese que tener una gran optimización o tener buen SEO, podemos incluir y trabajar con vue-server-rendering.

Plataforma Vue 1

Y así nos pasaría con muchas más funcionalidades. La cantidad de librerías con las que se cuentan (ya sean creadas por los desarrolladores oficiales o por la comunidad) es tan grande y cubre tal espectro de funcionalidades, que será difícil que nos encontremos desamparados y sin esa utilidad que nos es indispensable.

2. Funcionalidades intuitivas, modernas y fáciles de usar

VueJS no ha reinventado la rueda. Nuestro amigo verde fue creado como proyecto personal por Evan You, antiguo desarrollador de Google, en un intento de simplificar el funcionamiento de AngularJS. El framework empezó a ser tan fácil y simple de usar que, una vez que su creador decidió subirlo a los repositorios de Github, la comunidad fue usándolo en cada vez más proyectos.

Empresas como Xiaomi, Alibaba o Gitlab son algunos de sus grandes exponentes. Si miramos las estadísticas de las expectativas de uso en el año 2018 encontramos que muchas personas y empresas están interesadas en conocerlo y usarlo.

Vue Vs React

Pero ¿Por qué este hype? ¿Por qué la comunidad tiene tan buenas palabras de este framework?

Bajo mi punto de vista, se debe a lo bien que Evan You ha sabido trasladar todo lo bueno que tienen otros frameworks como Angular, ReactJS y EmberJS y desechar aquello que al desarrollador no le aportaba o le era complejo de usar.

Si tuviésemos que definir a VueJS por cuatro de sus aspectos conceptuales serían estos:

  1. El dato como centro de todo: En VueJS, los componentes gestionan un modelo de datos interno. Estos componentes están diseñado bajo el patrón MVVM. Esto quiere decir que el desarrollador no tiene que preocuparse tanto por cómo o cuando renderiza un modelo en pantalla y sí más en cómo tiene que ser la lógica que gestiona ese modelo. El renderizado de HTML es delegado a la librería. Nosotros simplemente jugamos con datos, métodos y plantillas HTML donde indicamos cuando se tiene que pintar cada parte del modelo.

  2. El sistema de componentes es reactivo: VueJS sabe comunicarse muy bien por medio de eventos asíncronos. Un componente hijo se puede comunicar con su componente padre por medio de eventos. Dos partes del sistema pueden comunicarse por medio de eventos. Los propios modelos de un componente son capaces de enviar eventos para indicar cuándo renderizarse. El sistema de componentes se convierte en un organismo vivo que reacciona muy bien al cambio y realiza acciones programadas por el desarrollador. Esto se debe a que el módelo de datos del componente es envuelto por getters y setters especiales encargados de gestionar estas reacciones.

  3. Sin fricción con otras librerías o recursos: Cuando me enfrenté a ReactJS sufrí un poco con el concepto de que todo era JS. Tener JSX no me ayudó para su aprendizaje. Angular me medio obligó a incluir TypeScript para escribir componentes. Me gusta TypeScript, lo que no me gusta es que me impongan herramientas. VueJS es el más concienciado con esto: Usa lo que quieras, usa la herramienta con la que te encuentres cómodo, céntrate en escribir HTML, CSS y JavaScript. Si quieres añadir JSX o TypeScript hazlo. Si no lo quieres incluir ahora, hazlo más tarde. Esto hace que desarrollar en VueJS sea más intuitivo. Es casi como trabajar con JavaScript nativo. Particularmente, me parece un paso muy natural si vienes de trabajar con jQuery.

  4. Todo está en el sitio que tiene que estar. Cuando empecé con VueJS, me di cuenta que miraba la documentación menos que en la de otras herramientas. Asimilaba la sintaxis antes. Incluso la propia intuición me permitía usar la librería sin tener que mirar la documentación previamente. Esto se debía a que el naming de la API de VueJS es bastante intuitiva. Con saber lo que significa props, data y methods y qué puedo incluir en estas partes, podía empezar a hacer mucho, con muy pocos conocimientos. De hecho, si no os explico de qué trata cada una de estas partes de la API, lo más seguro es que supieseis de qué estoy hablando. Es una de las virtudes de VueJS. Ser fácil, intuitivo y poco recargado. Cada parte está en el lugar que debería estar. Esto es algo dificil de entender hasta que no se está desarrollando algo en VueJS, pero creedme, que si le dáis una oportunidad, esto lo notareis.

3. Un ecosistema muy variado que cubre todo lo necesario

Cuando me decanto por una herramienta de trabajo u otra, busco que la experiencia de desarrollo sea lo más cómoda posible. VueJS tiene a su alrededor una serie de herramientas que ayudan a conseguir que el desarrollador sepa en todo momento qué está haciendo y cómo lo está haciendo. Hay tres herramientas que me ayudan mucho a la hora de trabajar con VueJS.

Una de ellas es la línea de comandos (CLI) especial que han creado sobre NodeJS. Esta herramienta permite empezar un proyecto con un boilerplate (o plantilla base) configurado a nuestro gusto de una manera fácil y sencilla. Simplemente descargando desde npm la herramienta vue-cli, podremos crear una estructura inicial con la que trabajar que cumple con la guía de estilo pactada por la comunidad. Bajo mi punto de vista, es la mejor manera de empezar a conocer la plataforma.

Además, una vez que estamos desarrollando, lo que más me ayuda a saber qué estoy haciendo y si lo estoy haciendo bien son los procesos de depuración. Es cierto que Firefox y Google Chrome ya cuentan con excepcionales herramientas para depurar código. Pero hay una serie de conceptos internos que VueJS gestiona como el estado, las propiedades o los eventos que las herramientas estándar no suelen conocer.

El equipo de desarrollo de VueJS mantiene una extensión de Chrome que nos permite ver cómo se renderiza nuestro árbol de componentes, cómo se están lanzando y registrando eventos, cómo se guarda el estado interno de cada componente o cómo se está comportando el estado global de la aplicación. Esta es una buena herramienta que nos ayudará mucho en nuestro día a día. Simplemente hay que ir al store de Chrome y descargarla.

Chrome Vejs Extension

Pero esto no queda aquí, y es que además de encontrar facilidades a la hora de empezar y de depurar un proyecto con VueJS, contamos con plugins para los IDEs más usados en la actualidad. Yo en mi caso, uso Visual Studio Code (VSC) para desarrollar aplicaciones front y me gusta mucho tener instalado un plugin para realizar diferentes acciones de VueJS llamado Vetur.

Este plugin, me permite tener intellisense de la sintaxis de Vue en VSC. Me permite escribir componentes más rápido gracias a los snippets por defecto que tiene, me permite tener pintado y estilizado mí codigo para que en todo momento sepa cuales son las palabras reservadas del framework. Por último, me permite usar herramientas como Prettier con solo usar un atajo de teclado. Cómo véis es una herramienta muy útil.

Lo bueno de estas herramientas es que se encuentran en constante evolución. Siempre que sale una nueva versión del framework, la comunidad y el equipo core se encarga de mantenerlas al día y siempre están añadiendo funcionalidad extra para hacer el trabajo a los desarrolladores un poco más fácil.

4. Una comunidad muy activa

Todo lo anterior puede estar muy bien, pero si no hay un buen grupo de personas que esté detrás de un proyecto tan importante como este, poco puede importar ¿Cuántas veces nos ha pasado, que hemos usado una librería y con el paso del tiempo, hemos tenido que ser nosotros quien la hemos tenido que mantener porque su creador no le ha dado soporte? En la época de esplendor de jQuery, me pasó más de lo que me hubiera gustado.

En ese sentido, simplemente tenemos que mirar este repositorio oficial de VueJS llamado ‘Awesome VueJS’. En este repositorio se incluyen todos aquellos recursos relevantes que la comunidad está creando sobre esta herramienta: Libros, charlas, librerías, posts, manuales… todo lo que se nos ocurra está aquí.

VueJS es un proyecto Open Source que cuenta con una comunidad muy viva. Además, es un proyecto Open Source ‘real’. ¿Qué quiero decir con ‘real’? Quiero decir que es un proyecto gestionado, desarrollado, evolucionado y planteado por y para la comunidad. Si miramos a sus competidores más directos, tanto Angular (creado por Google) como ReactJS (creado por Facebook) tienen un sistema Open Source más rígido y menos abierto de lo que nos gustaría.

El roadmap, el versionado, las decisiones, siempre o casi siempre, son tomadas desde los equipos formados por estas dos grandes empresas. En este caso, el modelo de VueJS se asemeja más con el de EmberJS. Proyectos financiados por la comunidad, creados por la comunidad, sin ningún gigante que se preocupe por ellos.

Esto, como en todo, puede ser un arma de doble filo. La esencia del software libre, el espíritu de compartir con la comunidad, está presente en VueJS. No existen intereses de terceros. No existen cambios repentinos por decisiones de negocio. Simplemente se intenta seguir un roadmap que pueda satisfacer a todo el mundo partiendo de unas bases conceptuales. Esto es bueno porque te da independencia y te da sensación de cercanía.

La comunidad en VueJS se siente escuchada. Muchas partes del framework se han quitado o mejorado por las issues que se han abierto en los repositorios del proyecto.

Planes como que VueJS renderice en Web Components nativos han sido gracias a la presión de la comunidad.

Sin embargo, VueJS sufre de un mal que si con el tiempo no se tiene en cuenta, puede ser el final del proyecto: VueJS todavía depende demasiado de su creador. Si se revisan los commits y estadísticas del proyecto, se puede observar que Evan You copa todavía muchos de los rankings de actividad. Empieza a haber gente importante en el proyecto (como Sarah Drasner o Guillaume Chau), pero parece que todavía todo gira alrededor del desarrollador oriental.

Esto, por muy mal que nos parezca su sistema de software libre, no va a pasar en otros frameworks más corporativos. Google, ReactJS van a seguir mantenidos porque se encuentran dentro de la estrategia de desarrollo de sus empresas. ¿Qué esto puede cambiar? Pues sí, tal vez, pero que sepamos que contamos con esto. VueJS tiene pinta de ser un proyecto que a medio-largo plazo va a seguir funcionando muy bien, pero es normal que se vigilen los movimientos de la comunidad.

5. Todo el código de un componente se encuentra en un único fichero

Vale, quizá tampoco sea nada novedoso. Habíamos comentado que en ReactJS todo se transformaba en JavaScript, por tanto, todo el código de un componente, ya sea HTML (JSX en este caso), CSS y JavaScript se va a encontrar en un único fichero con extensión .jsx. Y quizá estos sistemas no lo veas ni como una ventaja ¿Qué pasa con la separación de conceptos? ¿Ya no debemos separar el contenido, de su estilo y su lógica de negocio?

Bueno, pues sí, en VueJS, los componentes también guardan todo lo necesario en ficheros con extensión .vue. Estos ficheros contienen todo el HTML, el CSS y el JavaScript de un componente. Entonces ¿en qué se diferencia de ReactJS? Se diferencia en que en VueJS, los conceptos están juntos en un fichero, pero no revueltos.

Para verlo más claro, veamos el ejemplo de un componente en VueJS:



<template>
    <form class="search-box" @submit.prevent="search">
        <input type="text" placeholder="Ej. Cinema Paradiso" v-model="query" />
        <button>Buscar</button>
        <span>{{ queryLength }}</span>
    </form>
</template>

<script>
export default {
    name: 'search-box',
    props: {
        value: { type: String, default: '' }
    },
    data() {
        return {
            query: this.value
        }
    },
    computed: {
        queryLength: function () {
            return this.query.length;
        }
    },
    methods: {
        search() {
            this.$emit('search', this.query);
        }
    }
}
</script>

<style lang="scss" scoped>
@import '../assets/scss/_colors';

$color-light-darken: darken($color-light, 15%);

.search-box {
    display: flex;
    height: 3rem;
    

    button,
    input {
        &:focus {
            outline: none;
        }
    }

    input {
        width: 100%;
        padding: 0 0.5rem;
        border: 1px solid $color-basic-2;
        border-right: 1px solid $color-light;
    }

    button {
        padding: 0 2rem;
        background: $color-light-darken;
        color: $color-basic;
        font-weight: bold;
        border: 1px solid $color-light-darken;

        &:hover {
            cursor: pointer;
            background: $color-light;
            border: 1px solid $color-light;
        }
    }

    span {
        display: block;
        font-size: 1.5rem;
        padding: 0.5rem 1rem;
    }
}
</style>


En esta ocasión, observamos un componente que representa un típico buscador. Es el componente SearchBox.vue. Este componente se encarga de renderizar un formulario con un elemento <input /> y un elemento <button />. Lo que hace es guardar lo que el usuario inserta en la variable query y emitir un evento al componente padre con esta información cuando el usuario pulsa en el botón.

¿Véis lo que os digo? Todo el HTML, CSS y JS está junto, pero no revuelto. Gracias a las etiquetas template, script y style, tengo los conceptos separados, pero juntos, de esta forma es más fácil reutilizar ficheros en más de un proyecto. Todo el contenido queda más claro. Si el desarrollador está trabajando en un componente en particular, tiene todo a la vista.

Lo bueno de esto, es que cuando construya mi aplicación, vue-loader, una pieza creada por el equipo de VueJS para hacer que mis ficheros .vue funcionen con Webpack, todo mi código JavaScript será empaquetado en un fichero app.min.js y todo el CSS que se encuentre en los componentes, será empaquetado en un fichero app.min.css. Auténtica magia que nos hace la vida más fácil a todos y todas.

Lo bueno de nuevo de VueJS, es que si esto de los Single File Components no te convence, puede seguir guardando los conceptos de cada fichero por separado.

Conclusión

Creo que es bastante importante saber la razón por la cuál se elige una herramienta. Dependiendo del contexto, desarrollar con uno u otro framework puede ayudarnos a trabajar mejor en equipo.

No es lo mismo trabajar solo en un proyecto personal que trabajar con un equipo de veinte desarrolladores. No es lo mismo trabajar en un proyecto grande y complejo que en uno pequeño y con un ámbito bien acotado. No es lo mismo trabajar con compañeras y compañeros que tienen un bagaje en front que con un equipo con perfiles más multidisciplinares.

Estos puntos que yo aquí he expuesto son mis razones. Son las razones por las cuales VueJS me ha convencido para mi contexto y mi marco de trabajo. Puede que a ti, un framework con una comunidad abundante no sea importante. Puede que las funcionalidades que te he dicho y que más valor me aportan a mi, a ti no te aporten nada o que no te aporten lo suficiente como para hacer un cambio drástico a VueJS.

Por tanto, no te dejes llevar por mis palabras y, como se debería hacer, ten cuidado, no te fíes de nadie. Prueba por ti mismo las cosas en un desarrollo lo más acotado posible, o por el contrario, lleva el framework a sus límites si necesitas un contexto muy exigente.

Puede que, como me pasó a mi, cuando hagas esas pruebas, su API te convezca más, su workflow te enganche, que te sientas cómodo en su filosofía, en sus conceptos, que te encuentres tan bien desarrollando con VueJS que quizá ya no solo encuentres válidas (o erróneas) mis razones, si no que encuentres tus propias razones para usar VueJS.

Más información | Vue.js

También te recomendamos

SFML 2: Fuentes y textos

Este San Valentín enamórate del amor, de quien tú quieras y como te dé la gana

SFML 2: Sonidos y música

-
La noticia Por qué elegir VueJS: 5 razones para considerarlo nuestro próximo framework de referencia fue publicada originalmente en Genbeta Dev por José Antonio Dongil Sánchez .

Por qué elegir VueJS: 5 razones para considerarlo nuestro próximo framework de referencia

11/02/2018
Artículo original

Vue

A lo largo de estos años, he tenido la suerte de poder trabajar con diferentes frameworks JavaScript. Cada uno de ellos ha tenido, para mi, sus puntos fuertes y sus puntos débiles. Nunca he tenido un apego incondicional con ninguno de ellos y eso me ha hecho ver a los frameworks como lo que son: herramientas que pueden ayudarnos tanto como hacernos pasar un buen dolor de cabeza. Esto ha hecho que pueda valorar mucho qué funcionalidades son necesarias y qué argumentos tener en cuenta a la hora de decantarme por uno o por otro dependiendo del contexto en el que me he encontrado.

Viéndolo con perspectiva, en muy poco tiempo, hemos visto como estos frameworks han ido pasando por diferentes generaciones y como han ido madurando. Se podría decir que ha día de hoy, en lo que yo suelo considerar la 3ª Generación, nos encontramos con frameworks bastante maduros que nos ayudan a realizar un gran número de tareas que pueden ser ejecutados en diferentes navegadores a la vez.

ReactJS, Angular y EmberJS son los frameworks que representan un mayor uso en el mercado y que han demostrado ser una garantía de robustez y escalabilidad. A esta terna, se ha unido hace una temporada VueJS. Un framework con el que llevo trabajando durante un buen tiempo y del que he intentado estudiar cada funcionalidad.

En este post, me gustaría exponer cinco razones que han hecho que VueJS se haya convertido en mi framework JavaScript favorito. Espero que estas razones os convenzan para que en vuestra próxima prueba de concepto o proyecto personal, le deis una oportunidad.

1. Un framework para aprender y usar de manera progresiva

VueJS se autodenomina como un framework progresivo. Cuando encaramos un desarrollo con VueJS, podemos indicar qué partes del framework queremos incluir. VueJS está modularizado en diferentes librerías separadas que permiten ir añadiendo funcionalidad en el momento que las vayamos necesitando.

La modularización en librerías de un framework no es algo nuevo en el desarrollo front. Tanto ReactJS como Angular cuentan con una organización parecida de su código base. Lo que diferencia a VueJS de otras alternativas es lo bien desacopladas que se encuentran estas partes, lo fácil que es extender la funcionalidad core y lo bien que trabajan todas sus partes una vez que se decide incluir más módulos.

El core principal de VueJS está formado por una librería encargada de renderizar vistas en el navegador. Su forma de organizar el código es por medio de pequeños componentes que contienen todo el HTML, CSS y JavaScript necesario para funcionar como pieza independiente. Estas piezas se van componiendo en un árbol jerárquico de componentes hasta formar nuestra aplicación. Usar esta librería es tan fácil como importar el script en nuestra página HTML.

Si lo único que necesitamos como desarrolladores es una mejor forma de organizar y renderizar nuestros pequeños componentes visuales, nos quedamos ahí y no incluiríamos nada más. En el momento que nuestra aplicación empezase a crecer, contamos con librerías para gestionar las rutas de nuestra aplicación como vue-router o con librerías para gestionar el estado global de la aplicacion como pueda ser vuex. Si nuestra aplicación tuviese que tener una gran optimización o tener buen SEO, podemos incluir y trabajar con vue-server-rendering.

Plataforma Vue 1

Y así nos pasaría con muchas más funcionalidades. La cantidad de librerías con las que se cuentan (ya sean creadas por los desarrolladores oficiales o por la comunidad) es tan grande y cubre tal espectro de funcionalidades, que será difícil que nos encontremos desamparados y sin esa utilidad que nos es indispensable.

2. Funcionalidades intuitivas, modernas y fáciles de usar

VueJS no ha reinventado la rueda. Nuestro amigo verde fue creado como proyecto personal por Evan You, antiguo desarrollador de Google, en un intento de simplificar el funcionamiento de AngularJS. El framework empezó a ser tan fácil y simple de usar que, una vez que su creador decidió subirlo a los repositorios de Github, la comunidad fue usándolo en cada vez más proyectos.

Empresas como Xiaomi, Alibaba o Gitlab son algunos de sus grandes exponentes. Si miramos las estadísticas de las expectativas de uso en el año 2018 encontramos que muchas personas y empresas están interesadas en conocerlo y usarlo.

Vue Vs React

Pero ¿Por qué este hype? ¿Por qué la comunidad tiene tan buenas palabras de este framework?

Bajo mi punto de vista, se debe a lo bien que Evan You ha sabido trasladar todo lo bueno que tienen otros frameworks como Angular, ReactJS y EmberJS y desechar aquello que al desarrollador no le aportaba o le era complejo de usar.

Si tuviésemos que definir a VueJS por cuatro de sus aspectos conceptuales serían estos:

  1. El dato como centro de todo: En VueJS, los componentes gestionan un modelo de datos interno. Estos componentes están diseñado bajo el patrón MVVM. Esto quiere decir que el desarrollador no tiene que preocuparse tanto por cómo o cuando renderiza un modelo en pantalla y sí más en cómo tiene que ser la lógica que gestiona ese modelo. El renderizado de HTML es delegado a la librería. Nosotros simplemente jugamos con datos, métodos y plantillas HTML donde indicamos cuando se tiene que pintar cada parte del modelo.

  2. El sistema de componentes es reactivo: VueJS sabe comunicarse muy bien por medio de eventos asíncronos. Un componente hijo se puede comunicar con su componente padre por medio de eventos. Dos partes del sistema pueden comunicarse por medio de eventos. Los propios modelos de un componente son capaces de enviar eventos para indicar cuándo renderizarse. El sistema de componentes se convierte en un organismo vivo que reacciona muy bien al cambio y realiza acciones programadas por el desarrollador. Esto se debe a que el módelo de datos del componente es envuelto por getters y setters especiales encargados de gestionar estas reacciones.

  3. Sin fricción con otras librerías o recursos: Cuando me enfrenté a ReactJS sufrí un poco con el concepto de que todo era JS. Tener JSX no me ayudó para su aprendizaje. Angular me medio obligó a incluir TypeScript para escribir componentes. Me gusta TypeScript, lo que no me gusta es que me impongan herramientas. VueJS es el más concienciado con esto: Usa lo que quieras, usa la herramienta con la que te encuentres cómodo, céntrate en escribir HTML, CSS y JavaScript. Si quieres añadir JSX o TypeScript hazlo. Si no lo quieres incluir ahora, hazlo más tarde. Esto hace que desarrollar en VueJS sea más intuitivo. Es casi como trabajar con JavaScript nativo. Particularmente, me parece un paso muy natural si vienes de trabajar con jQuery.

  4. Todo está en el sitio que tiene que estar. Cuando empecé con VueJS, me di cuenta que miraba la documentación menos que en la de otras herramientas. Asimilaba la sintaxis antes. Incluso la propia intuición me permitía usar la librería sin tener que mirar la documentación previamente. Esto se debía a que el naming de la API de VueJS es bastante intuitiva. Con saber lo que significa props, data y methods y qué puedo incluir en estas partes, podía empezar a hacer mucho, con muy pocos conocimientos. De hecho, si no os explico de qué trata cada una de estas partes de la API, lo más seguro es que supieseis de qué estoy hablando. Es una de las virtudes de VueJS. Ser fácil, intuitivo y poco recargado. Cada parte está en el lugar que debería estar. Esto es algo dificil de entender hasta que no se está desarrollando algo en VueJS, pero creedme, que si le dáis una oportunidad, esto lo notareis.

3. Un ecosistema muy variado que cubre todo lo necesario

Cuando me decanto por una herramienta de trabajo u otra, busco que la experiencia de desarrollo sea lo más cómoda posible. VueJS tiene a su alrededor una serie de herramientas que ayudan a conseguir que el desarrollador sepa en todo momento qué está haciendo y cómo lo está haciendo. Hay tres herramientas que me ayudan mucho a la hora de trabajar con VueJS.

Una de ellas es la línea de comandos (CLI) especial que han creado sobre NodeJS. Esta herramienta permite empezar un proyecto con un boilerplate (o plantilla base) configurado a nuestro gusto de una manera fácil y sencilla. Simplemente descargando desde npm la herramienta vue-cli, podremos crear una estructura inicial con la que trabajar que cumple con la guía de estilo pactada por la comunidad. Bajo mi punto de vista, es la mejor manera de empezar a conocer la plataforma.

Además, una vez que estamos desarrollando, lo que más me ayuda a saber qué estoy haciendo y si lo estoy haciendo bien son los procesos de depuración. Es cierto que Firefox y Google Chrome ya cuentan con excepcionales herramientas para depurar código. Pero hay una serie de conceptos internos que VueJS gestiona como el estado, las propiedades o los eventos que las herramientas estándar no suelen conocer.

El equipo de desarrollo de VueJS mantiene una extensión de Chrome que nos permite ver cómo se renderiza nuestro árbol de componentes, cómo se están lanzando y registrando eventos, cómo se guarda el estado interno de cada componente o cómo se está comportando el estado global de la aplicación. Esta es una buena herramienta que nos ayudará mucho en nuestro día a día. Simplemente hay que ir al store de Chrome y descargarla.

Chrome Vejs Extension

Pero esto no queda aquí, y es que además de encontrar facilidades a la hora de empezar y de depurar un proyecto con VueJS, contamos con plugins para los IDEs más usados en la actualidad. Yo en mi caso, uso Visual Studio Code (VSC) para desarrollar aplicaciones front y me gusta mucho tener instalado un plugin para realizar diferentes acciones de VueJS llamado Vetur.

Este plugin, me permite tener intellisense de la sintaxis de Vue en VSC. Me permite escribir componentes más rápido gracias a los snippets por defecto que tiene, me permite tener pintado y estilizado mí codigo para que en todo momento sepa cuales son las palabras reservadas del framework. Por último, me permite usar herramientas como Prettier con solo usar un atajo de teclado. Cómo véis es una herramienta muy útil.

Lo bueno de estas herramientas es que se encuentran en constante evolución. Siempre que sale una nueva versión del framework, la comunidad y el equipo core se encarga de mantenerlas al día y siempre están añadiendo funcionalidad extra para hacer el trabajo a los desarrolladores un poco más fácil.

4. Una comunidad muy activa

Todo lo anterior puede estar muy bien, pero si no hay un buen grupo de personas que esté detrás de un proyecto tan importante como este, poco puede importar ¿Cuántas veces nos ha pasado, que hemos usado una librería y con el paso del tiempo, hemos tenido que ser nosotros quien la hemos tenido que mantener porque su creador no le ha dado soporte? En la época de esplendor de jQuery, me pasó más de lo que me hubiera gustado.

En ese sentido, simplemente tenemos que mirar este repositorio oficial de VueJS llamado ‘Awesome VueJS’. En este repositorio se incluyen todos aquellos recursos relevantes que la comunidad está creando sobre esta herramienta: Libros, charlas, librerías, posts, manuales… todo lo que se nos ocurra está aquí.

VueJS es un proyecto Open Source que cuenta con una comunidad muy viva. Además, es un proyecto Open Source ‘real’. ¿Qué quiero decir con ‘real’? Quiero decir que es un proyecto gestionado, desarrollado, evolucionado y planteado por y para la comunidad. Si miramos a sus competidores más directos, tanto Angular (creado por Google) como ReactJS (creado por Facebook) tienen un sistema Open Source más rígido y menos abierto de lo que nos gustaría.

El roadmap, el versionado, las decisiones, siempre o casi siempre, son tomadas desde los equipos formados por estas dos grandes empresas. En este caso, el modelo de VueJS se asemeja más con el de EmberJS. Proyectos financiados por la comunidad, creados por la comunidad, sin ningún gigante que se preocupe por ellos.

Esto, como en todo, puede ser un arma de doble filo. La esencia del software libre, el espíritu de compartir con la comunidad, está presente en VueJS. No existen intereses de terceros. No existen cambios repentinos por decisiones de negocio. Simplemente se intenta seguir un roadmap que pueda satisfacer a todo el mundo partiendo de unas bases conceptuales. Esto es bueno porque te da independencia y te da sensación de cercanía.

La comunidad en VueJS se siente escuchada. Muchas partes del framework se han quitado o mejorado por las issues que se han abierto en los repositorios del proyecto.

Planes como que VueJS renderice en Web Components nativos han sido gracias a la presión de la comunidad.

Sin embargo, VueJS sufre de un mal que si con el tiempo no se tiene en cuenta, puede ser el final del proyecto: VueJS todavía depende demasiado de su creador. Si se revisan los commits y estadísticas del proyecto, se puede observar que Evan You copa todavía muchos de los rankings de actividad. Empieza a haber gente importante en el proyecto (como Sarah Drasner o Guillaume Chau), pero parece que todavía todo gira alrededor del desarrollador oriental.

Esto, por muy mal que nos parezca su sistema de software libre, no va a pasar en otros frameworks más corporativos. Google, ReactJS van a seguir mantenidos porque se encuentran dentro de la estrategia de desarrollo de sus empresas. ¿Qué esto puede cambiar? Pues sí, tal vez, pero que sepamos que contamos con esto. VueJS tiene pinta de ser un proyecto que a medio-largo plazo va a seguir funcionando muy bien, pero es normal que se vigilen los movimientos de la comunidad.

5. Todo el código de un componente se encuentra en un único fichero

Vale, quizá tampoco sea nada novedoso. Habíamos comentado que en ReactJS todo se transformaba en JavaScript, por tanto, todo el código de un componente, ya sea HTML (JSX en este caso), CSS y JavaScript se va a encontrar en un único fichero con extensión .jsx. Y quizá estos sistemas no lo veas ni como una ventaja ¿Qué pasa con la separación de conceptos? ¿Ya no debemos separar el contenido, de su estilo y su lógica de negocio?

Bueno, pues sí, en VueJS, los componentes también guardan todo lo necesario en ficheros con extensión .vue. Estos ficheros contienen todo el HTML, el CSS y el JavaScript de un componente. Entonces ¿en qué se diferencia de ReactJS? Se diferencia en que en VueJS, los conceptos están juntos en un fichero, pero no revueltos.

Para verlo más claro, veamos el ejemplo de un componente en VueJS:



<template>
    <form class="search-box" @submit.prevent="search">
        <input type="text" placeholder="Ej. Cinema Paradiso" v-model="query" />
        <button>Buscar</button>
        <span>{{ queryLength }}</span>
    </form>
</template>

<script>
export default {
    name: 'search-box',
    props: {
        value: { type: String, default: '' }
    },
    data() {
        return {
            query: this.value
        }
    },
    computed: {
        queryLength: function () {
            return this.query.length;
        }
    },
    methods: {
        search() {
            this.$emit('search', this.query);
        }
    }
}
</script>

<style lang="scss" scoped>
@import '../assets/scss/_colors';

$color-light-darken: darken($color-light, 15%);

.search-box {
    display: flex;
    height: 3rem;
    

    button,
    input {
        &:focus {
            outline: none;
        }
    }

    input {
        width: 100%;
        padding: 0 0.5rem;
        border: 1px solid $color-basic-2;
        border-right: 1px solid $color-light;
    }

    button {
        padding: 0 2rem;
        background: $color-light-darken;
        color: $color-basic;
        font-weight: bold;
        border: 1px solid $color-light-darken;

        &:hover {
            cursor: pointer;
            background: $color-light;
            border: 1px solid $color-light;
        }
    }

    span {
        display: block;
        font-size: 1.5rem;
        padding: 0.5rem 1rem;
    }
}
</style>


En esta ocasión, observamos un componente que representa un típico buscador. Es el componente SearchBox.vue. Este componente se encarga de renderizar un formulario con un elemento <input /> y un elemento <button />. Lo que hace es guardar lo que el usuario inserta en la variable query y emitir un evento al componente padre con esta información cuando el usuario pulsa en el botón.

¿Véis lo que os digo? Todo el HTML, CSS y JS está junto, pero no revuelto. Gracias a las etiquetas template, script y style, tengo los conceptos separados, pero juntos, de esta forma es más fácil reutilizar ficheros en más de un proyecto. Todo el contenido queda más claro. Si el desarrollador está trabajando en un componente en particular, tiene todo a la vista.

Lo bueno de esto, es que cuando construya mi aplicación, vue-loader, una pieza creada por el equipo de VueJS para hacer que mis ficheros .vue funcionen con Webpack, todo mi código JavaScript será empaquetado en un fichero app.min.js y todo el CSS que se encuentre en los componentes, será empaquetado en un fichero app.min.css. Auténtica magia que nos hace la vida más fácil a todos y todas.

Lo bueno de nuevo de VueJS, es que si esto de los Single File Components no te convence, puede seguir guardando los conceptos de cada fichero por separado.

Conclusión

Creo que es bastante importante saber la razón por la cuál se elige una herramienta. Dependiendo del contexto, desarrollar con uno u otro framework puede ayudarnos a trabajar mejor en equipo.

No es lo mismo trabajar solo en un proyecto personal que trabajar con un equipo de veinte desarrolladores. No es lo mismo trabajar en un proyecto grande y complejo que en uno pequeño y con un ámbito bien acotado. No es lo mismo trabajar con compañeras y compañeros que tienen un bagaje en front que con un equipo con perfiles más multidisciplinares.

Estos puntos que yo aquí he expuesto son mis razones. Son las razones por las cuales VueJS me ha convencido para mi contexto y mi marco de trabajo. Puede que a ti, un framework con una comunidad abundante no sea importante. Puede que las funcionalidades que te he dicho y que más valor me aportan a mi, a ti no te aporten nada o que no te aporten lo suficiente como para hacer un cambio drástico a VueJS.

Por tanto, no te dejes llevar por mis palabras y, como se debería hacer, ten cuidado, no te fíes de nadie. Prueba por ti mismo las cosas en un desarrollo lo más acotado posible, o por el contrario, lleva el framework a sus límites si necesitas un contexto muy exigente.

Puede que, como me pasó a mi, cuando hagas esas pruebas, su API te convezca más, su workflow te enganche, que te sientas cómodo en su filosofía, en sus conceptos, que te encuentres tan bien desarrollando con VueJS que quizá ya no solo encuentres válidas (o erróneas) mis razones, si no que encuentres tus propias razones para usar VueJS.

Más información | Vue.js

También te recomendamos

Este San Valentín enamórate del amor, de quien tú quieras y como te dé la gana

SFML 2: Sonidos y música

SFML 2: Fuentes y textos

-
La noticia Por qué elegir VueJS: 5 razones para considerarlo nuestro próximo framework de referencia fue publicada originalmente en Genbeta Dev por José Antonio Dongil Sánchez .

GoLang vs PHP

11/02/2018
Artículo original

Si te gusta la programacion, vamos a tratar sobre dos lenguajes que usan mayoritariamente los programadores. Uno de ellos, de los más elegidos, dada su antigüedad, destaca por su reconocimiento a través de los años. El otro, más reciente, pertenece a una de las grandes empresas de Internet, Google.

Te ayudaremos a repasar las características de ambos, con el fin de ayudarte a seleccionar el que mejor se adapte a ti. Haremos que tengas las cosas más claras; te señalaremos lo bueno y lo malo de cada uno de ellos. Así que, vamos allá.

El lenguaje Golang

Golang es el lenguaje para programación creado por Google. Con poco menos de una década de vida, aún sigue siendo un desconocido para algunos, pero ha sabido abrirse camino en el mundo de la computación.

Lo bueno

Golang suele hacerse atractivo al programador por su simplicidad. Es sencillo de comprender y utilizar, añadiendo un plus a todo esto, su confiabilidad. Con estas características, cumple a la perfección lo que promete.

- La concurrencia del también conocido Go permite la ejecución de diferentes procesos de manera simultánea, facilitando la comunicación entre ellos.

- Un lenguaje sencillo, con limitadas opciones, que permite aún más su manejo por parte de los programadores.

- Su código estándar te permite memorizarlo fácilmente, sobre todo cuando repasas ejemplos y temas del lenguaje.

- El rendimiento es muy bueno, muy similar a C pero con la sencillez de un lenguaje moderno.

Lo malo

- A pesar de su simplicidad, quedaron algoritmos complejos por su longitud, lo que les hace, a su vez, difíciles de comprender. El motivo de esto es que dichos algoritmos no terminaron de incluirse en este nuevo lenguaje.

- La dificultad para desarrollar nuevas funciones termina siendo un problema para los programadores. Quizás de lo simple que han querido hacer este lenguaje, frenan el intento por sacarle mayores propiedades al mismo.

El tradicional PHP

Más conocido en el mundo de la programación, dados los años que lleva activo, no deja indiferente a quien lo sigue usando. Pero como todo, tiene sus lados bueno y malo. Echemos un vistazo.

Lo bueno

- Su sencillo lenguaje puede ser memorizado fácilmente, así que resulta muy atractivo.

- Ha demostrado una gran rapidez, de desarrollo

-  Muchos frameworks web disponibles

- Gran comunidad de desarrolladores

- Dados sus años de vida, dispones de mucha información en Internet acerca de él. Del mismo modo, continúa avanzado en sus funciones.

Lo malo

- El rendimiento no es su punto fuerte suele requerir más potencia de computación que otros lenguajes como Go o Java.

Comparativa de rendimiento

La última palabra la tienes tú. La programación es un arte para el que debes elegir bien tus herramientas.

 

Hosting Windows en México

11/02/2018
Artículo original

Espero y este post sea de tu agrado, no olvides compartirlo en su redes sociales y sobre todo.. Gracias por seguirnos!

¿Necesitas un hosting windows en México? No te preocupes! Hoy te hablo sobre una excelente opción de hospedaje web en México con servidores windows para cubrir tus necesidades en tu proyecto actual o futuro, hablamos sobre el proveedor recomendado asi como las especificaciones técnicas de los servidores y costos. Contar con un buen proveedor de hospedaje web es fundamental para cualquier proyecto de TI, un proveedor seguro y de confianza es la piedra angular de cualquier proyecto exitoso. El proveedor que hoy recomiendo para hosting windows en México es uno con bastantes años de experiencia y con precios bastante razonables

Compartir en Facebook

Comparte en Google Plus

Compartir en Twitter

El post Hosting Windows en México aparece en el Blog de Jonathan Melgoza

FRIKADAS: Descarga y monta tus propias máscaras de carnaval

09/02/2018
Artículo original

¿Aún no tienes disfraz pero no quieres renunciar a ser la sensación de la fiesta de carnaval? Bueno, quizá te encaje esta propuesta que te traemos, pero te avisamos, hace falta un buen carro de frikismo, y otro tanto de maña y paciencia. Además, tiene la ventaja de que te obligará a pasar un buen rato lejos de la pantalla del PC.

La solución nos viene de la mano de Steve Wintercroft, un diseñador británico que, junto a su esposa Marianne, lleva desde 2013 elaborando máscaras poligonales hechas de cartulina.

[youtube:-kMHf8WI9io]

Todo nació a raíz de una inesperada invitación a una fiesta de Halloween. Steve tuvo que improvisar un disfraz y tiró de creatividad. Armado con cartulina y cartón, cutter, pegamento y un poco de paciencia, se fabricó la máscara de un animal.

La idea triunfó en la fiesta, así que Steve se dedicó a perfeccionar su máscara y la puso a disposición de todos en formato digital para que se la pudieran descargar y montar sin necesidad de ser expertos en origami o papiroflexia.

A partir de ahí, el siguiente paso ya fue la venta al público general de máscaras resultonas, pero lo más simple posibles. Ellos diseñan las máscaras y luego las venden en formato digital a través de su tienda online. Solo tienes que comprar tu favorita, descargarla, imprimir el esquema y montarla siguiendo las instrucciones.

En este vídeo puedes ver al propio Steve montando una sencilla medio-máscara de zorro, por si te quieres disfrazar de Firefox:

[youtube:EB95TvCLyLA]

Desde su web te animan a usar cartón y cartulina reciclados, en la medida de lo posible. Por ejemplo, cajas de cereales vacías que, probablemente, ya tengas en casa. Claro que, esto quizá choca un poco con la posibilidad de comprar la máscara en formato libro, como esta calavera donde ya viene la máscara impresa además de fotografías y otros materiales artísticos relacionados con la misma.

Lo que no le podemos negar es que parece que su iniciativa está teniendo bastante éxito, pues incluso tienen una serie especial de libros-máscaras dedicada a Juego de Tronos.


Por cierto, hemos rebuscado por toda la web para intentar encontrar la máscara de Stormtrooper que ilustra esta entrada, pero al parecer simplemente fue un proyecto personal y nunca salió a la venta para no meterse en problemas legales. Se ve que resulta más complicado negociar con Lucas/Disney que con HBO. Una pena. Habrá que tirar del espíritu geek e ingeniería inversa. ¯\_(ツ)_/¯

Si te animas a proyectarla, ¡háznoslo saber!.

Página Siguiente