No hay evento que se precie que no cuente con una charla presentada por algún miembro de Karumi. Entre ellos suman más de 50 charlas durante todo el 2016. Más de cuatro años de andadura de este pequeño "Rock Solid Studio" cuyo objetivo es hacer el mejor software posible y ayudar a numerosos ingenieros a mejorar su trabajo. En definitiva: hacer software del que sentirse orgullosos.

Son extremadamente exigentes con su trabajo y con ellos mismos, algo que transmiten a cualquiera que haya trabajado con ellos. Lo cual se demuestran en los productos que han ayudado a crear y a mejorar.

Repasamos en esta entrevista cómo surgió Karumi a partir de su vivencias en otras startups, cuál es su filosofía de trabajo que les sigue haciéndo sentir orgullosos, cómo ayudan a las empresas con las que han trabajado a construir mejor software, cómo ven el panorama de desarrollo y, hablamos también sobre sus numerosos proyectos software. Sin olvidarnos de su reciente lanzamiento, Flowup una plataforma de monitorización de aplicaciones móviles.

¿De dónde surgió Karumi? ¿Qué os llevó a cambiar de trabajo y fundar Karumi?

Hace casi 4 años que 5 amigos nos sentamos en la cafetería de La Central en Callao, allí tomándonos un café conocimos a Irene, los 6 teníamos una idea en común, creíamos que era el momento de lanzarnos a la piscina, el momento de dar un paso hacía la incertidumbre de trabajar en nuestra propia empresa. Así nació lo que durante meses nos referíamos como “La Central Project”.

En aquellas primeras conversaciones entre divagaciones sobre el estado del software y aplicaciones en común hablábamos de que queríamos hacer y dónde queríamos ir, todos teníamos claro que queríamos trabajar bien, hacer software del que nos sintiéramos orgullosos y evitar todos los problemas que habíamos vivido en el pasado, en las empresas por las cuales pasamos.

Los 5 veníamos de Tuenti e Irene formaba por aquel entonces parte de Wayra. A todos nos gustaba la idea de montar la empresa en la línea de BlackPixel o 37 signals, creíamos que podíamos encajar muy bien en esa línea, una empresa que hiciera software de calidad y que pudiera resolver problemas difíciles que tienen las empresas, además si por el camino encontrábamos un producto interesante que pudiéramos hacer, ir a por ello. Con estas premisas nace "Rock Solid Studio".

De ese grupo de 6 iniciales por devenires de la vida, nos quedamos al final Alberto Gragera, Davide Mendolia, Jorge Juan Barroso e Irene Herranz.

¿Cuantos desarrolladores sois actualmente y qué tecnología usáis?

Pues el equipo de Karumi está compuesto por siete personas. Siete de las mejores personas que hemos podido reunir para formar un equipo excelente: Davide Mendolia, Alberto Gragera, Jorge Barroso, Irene Herranz, Sergio Gutierrez, Fran Fernández y Pedro Gómez.

Trabajamos sobretodo en Android, iOS y backend. Y no nos da miedo tocar cualquier cosa, aunque nuestra mayor experiencia es Java, Swift y Python, también tocamos cosas con Scala, Clojure o Javascript nos encanta hacer cosas nuevas y movernos fuera de nuestra zona de confort.

¿Cómo es un día cualquiera en la oficina de Karumi?

Pues es un poco locura, porque no hay un día arquetipo, porque a veces estamos en casa, otra veces en Londres u otras en el nuestras ciudades natales. Es raro el día que estamos todos en la oficina. Pero puede ser llegar por la mañana, charlar un poco con los compis de cualquier chorrada, coger un café o un maxibon, programar mientras que alguien pone música (a Pedro le encanta ponernos M Clan) comer en el salón y luego echarnos un FIFA o una partida a la arcade. Y vuelta al currar. Intentamos que el ambiente sea distendido y podamos trabajar lo más cómodamente posible.

¿Tenéis algún manifesto Karumi? ¿Cuáles son vuestros principios fundamentales en vuestra cultura de trabajo?

En Karumi no creemos en colgar un manifesto en la pared para poder señalarlo cuando queramos, creemos que la cultura y la filosofía de la empresa es lo que hacemos todos los días y no lo que decimos que hacemos. Cuando montamos la empresa pensamos en cinco pilares sobre los cuales apoyar el trabajo de Karumi y que nos sirvieran como guía para el devenir de la empresa.

• El primero que decidimos fue que somos una empresa que trabaja en remoto, cuando hablamos sobre esto, no quería decir que no tuviéramos oficina, la tenemos y nos encanta, si no que confiamos en el trabajo de cada uno de nosotros y lo mismo con nuestros empleados. La idea es que cada uno gestiona su tiempo, para lo cual si alguien quiere trabajar desde su casa, su pueblo o de madrugada, él decide, lo importante es que el trabajo esté bien hecho y que se trabaje respetando las necesidades del cliente. Nos parece importantísimo dar esa libertad a los trabajadores, creemos que tratar a los trabajadores como personas responsables debe ser principal para una empresa. Además todo sabemos quien trabaja y quien no, solo hace falta mirar sus contribuciones a los repositorios de código.

• Apostar por la comunidad y el open source. Todos creemos que es bueno demostrar que podemos ayudar a hacer mejor software y aprender a hacer mejor software, para ello debemos ser activos en las comunidades e intentar ayudar en la medida de lo posible.

• Ser honestos. Esto es innegociable, somos honestos, hay clientes que se asombran porque les decimos que no, que no a trabajar con ellos, no a los tiempos de desarrollo, o no porque no tenemos la experiencia suficiente para hacer un proyecto. Creemos que debemos decir siempre la verdad, que preferimos perder un cliente antes de tener un cliente descontento, no mentir en los tiempos de desarrollo, el software se tarda en hacer lo que se tarda en hacer, y tardar menos tiempo o es imposible o se resentirá la calidad. Una de las decisiones que tomamos era no tener comerciales, son los ingenieros los que hablan directamente con las empresas, ellos saben estimar, saben lo que se puede o no puede hacer, además ni su salario depende de lo que vendan, ni tiene que quedar bien con nadie.

• Ser un equipo pequeño. Esta es la decisión con la que estamos más contentos. Cuando le decimos a la gente esto, nos dicen que no escala, que ese modelo no nos hará nunca millonarios, pero a día de hoy creemos que cuidar al cliente y ofrecer calidad está muy asociado al tamaño del equipo y es lo que queremos seguir haciendo. El equipo crecerá, pero todo a su debido tiempo. Vendemos calidad, software bien hecho, hace falta ser bueno y tener experiencia para hacer buen software y contratar buena gente no es ya que sea caro sino que además es difícil. Si eres una consultora que trabaja para terceros es más difícil aún. Pero estamos convencidos de ello, todos los trabajadores de Karumi hablan con la misma voz, el mismo mensaje y eso necesita tiempo para asimilar los conceptos que ofrecemos y no podemos transmitir el mensaje a mucha gente a la vez.

• Escribir buen software. Intentamos escribir el mejor software que somos capaces, aplicar las reglas del buen diseño de software, escribir test, aplicar los principios SOLID, y sobre todo ser pragmáticos. Esto para nosotros es muy importante que las cosas funcionen bien pero que el código sea robusto, legible y mantenible.

Hablando de cuando estáis negociando si aceptar un nuevo proyecto ¿Qué es lo que más valoráis del cliente que os quiere contratar?

Mucha gente tiene la percepción de que somos un grupo elitista que elige con quién trabaja y que solo lo hacemos con quien nos gusta. Y nada más lejos de la realidad, intentamos trabajar con gente que quiera trabajar con nosotros y que valore nuestro trabajo.

Es cierto que tenemos cierta líneas rojas que no queremos cruzar y compañías con las que no estaríamos de acuerdo de forma ética. Valoramos muchos a los miembros de Karumi y siempre queremos que estén contentos en el trabajo del día a día. Nuestros empleados, nuestro equipo son nuestro principal valor, donde radica el valor de la compañía.

¿Qué proyectos y trabajos habéis realizado hasta la fecha?

Hemos tenido la suerte de trabajar con grandes y pequeños equipos. Uno de los primeros proyectos que recordamos con mucho cariño es cuando ayudamos a desarrollar parte de software de Blackphone un teléfono basado en la privacidad, el reto técnico fue mayúsculo y nos dio la oportunidad de trabajar codo con codo con gente muy top del mundo de la seguridad.

También hemos tenido la oportunidad de trabajar como parte de los equipos de Schibsted (dueños de la mayoría de empresas relacionadas con anuncios clasificados en Europa), Jobandtalent (uno de los mayores portales de empleo en España), Wallapop o Trinity Mirror. Intentando mejorar su día a día, donde además de aportar nuestro grano de arena al desarrollo del producto y evolución de los equipos intentamos mejorar su código. Hemos aprendido mucho en estos proyectos colaborando con algunos de los mejores ingenieros del sector.

Habéis colaborado con algunas startups española ¿Cómo es la experiencia de trabajar con equipos de trabajo ya formados?

Intentamos mejorar los equipos desde dentro, somos un miembro más del equipo, un compañero que viene a echarte una mano e intenta mejorar y aportar. Analizamos los problemas de los equipos, sus necesidades, sus miedos y sus manías, también vemos sus bondades, sus fuertes y conocer a las personas. Una vez que tenemos una fotografía general del equipo trabajamos en reforzar los puntos donde los vemos más flojos y explotar sus fortalezas. Cada equipo es un mundo e intentamos dar lo mejor de nosotros mismos y aportar el máximo de valor, para que cuando nos vayamos el mensaje que ofrecemos haya calado. Para otros proyectos no existe un equipo con el que colaborar por lo que nos centramos en desarrollar el mejor producto posible.

¿Cómo les ayudáis a construir mejor software?

De distintas maneras, por un lado de la forma más tradicional, a través de charlas o katas que hacemos con ellos. Pero también lo hacemos de una forma más cercana y enfocada a sus problemas a través pair programing o otras técnicas de extreme programming, revisando pull request, o predicando con el ejemplo. Creemos que predicar con el ejemplo es uno de los pilares fundamentales en nuestras colaboraciones. Solemos coger tareas de los equipos y desarrollarlas a la vez que hacemos pequeños refactors para mejorar el código y vamos metiendo cultura de tests si no existiera.

¿Cuáles son los principales errores que os soléis encontrar en las empresas donde habéis estado colaborando?

El miedo a escribir tests por desconocimiento y tener bases de código que no son testables. Tener mucho código duplicado, esto además afecta a la velocidad de los equipos ya que cualquier cambios influye a tocar mucho código.

También nos encontramos mucho con clases grandes que tienen mucha funcionalidad y hace que sea difícil de leer ya que hace más de lo que dicen que hacen. Le damos mucho valor a la semántica del código.

Si una startup os contratará ahora mismo para montar el andamiaje de su primera app, ¿Por donde empezarías a construirlo? ¿Cuáles son los pilares fundamentales?

Pues lo primero es responder a sus necesidades de negocio, hacer bien el core de lo que va a ser la aplicación, ser pragmáticos, no hacer optimizaciones prematuras o programar cosas por los “por si acaso...”, y los “en un futuro...”. Y lo que hagamos que esté bien hecho y las partes importantes bien probadas y cubiertas de tests.

¿Cómo veis el panorama de desarrollo en España?

A nivel de comunidad cada vez está más maduro, hay un montón de buenos desarrolladores que son también buenas personas. La comunidad está centrada en compartir conocimiento y esto puede observarse en todos y cada uno de los eventos que se organizan en España.

A nivel de empresas aunque está lejos de ser Berlín, Londres o París, la cosa no está mal y creo que va mejorando, hay startups que están haciendo un buen trabajo y que van en muy buena dirección como la gente de Carto que están que se salen y nos encanta que sea un equipo de aquí formado por amigos. Y la llegada de empresas grandes como Amazon también harán que se cree un mejor clima, o eso esperamos.

En casi cualquier evento de referencia os vemos dando alguna charla ¿Cuáles son las principales motivaciones para estar presentes en la comunidad?

Creemos que compartir conocimiento y conocer gente nueva es algo que enriquece a todo el equipo y a la empresa en general. Es algo que nos gusta y nos motiva. Participar en eventos nacionales e internacionales como speakers o sponsors también nos abre muchas puertas. Este año hemos esponsorizado eventos muy interesantes como el ExFest y el Freakend y participado como speakers en eventos internacionales como NSSpain, Droidcon, Devfest o MobiConf. En total hemos dado más de cincuenta charlas en un año si contamos todas las conferencias de los miembros del equipo.

Poca gente no ha usado algunas de vuestras librerías, Rosie Framework o Dexter son buena prueba de ello.¿Cómo creáis y manteneis todo el open source que generais?

Pues intentamos sacar tiempo debajo de las piedras o entre proyectos para poder darle caña al open source. Entender que estos proyectos forman parte de los desarrollos que hacemos casi cada día es fundamental. También cada unos cuantos meses no cogemos proyectos para poder dedicar ese tiempo a nosotros mismos y hacer o mejorar el código que hacemos.

¿Cuál ha sido el proyecto Open Source que más alegrías os dado? ¿Cuál ha sido el más duro técnicamente? ¿De cuál os sentís más orgullosos? Creo que la respuesta a todo es Dexter, la verdad es que es un proyecto que nos encanta, que fue un reto técnico muy alto y que Sergio Gutierrez hizo un trabajo espectacular. Aunque también estamos muy orgullosos de otros proyectos como BothamUI, Rosie, AndroidAudit y todos los repos asociados a las katas que hemos diseñado y usamos en nuestras formaciones para mobile.

Dashboard de métricas de flowup, el producto interno en el que está trabajando Karumi actualmente.

¿Nos podés avanzar algunos de vuestros proyectos internos más próximos

FlowUp es ahora mismo dónde estamos enfocados a nivel interno. Durante dos meses hemos estado trabajando en el proyecto más ambicioso de la compañía y justo la primera semana de diciembre salió la primera beta pública del proyecto. FlowUp es una plataforma de monitorización de aplicaciones para mobile que esperemos ayude muchos ingenieros a poder crear las mejores aplicaciones posibles.

Sitio web | Karumi

También te recomendamos

“Space Apps Challengue acerca el conocimiento que trae la Nasa a la tierra a la gente que participa del hackathon” Entrevista a Pau Contreras

"La enseñanza del pensamiento algorítmico debe empezar en Primaria" Entrevista a Juan Julián Merelo

Cómo conseguir que a tu bebé le gusten las verduras (y más cosas)

-
La noticia Entrevistamos a los desarrolladores detrás de Karumi: "Lo que más nos motiva es hacer software del que nos sintamos orgullosos" fue publicada originalmente en Genbeta Dev por Txema Rodríguez .

La clave para aprender de nuestros errores es documentar nuestros fallos. Escribir un post mortem de cada proyecto finalizado debería ser una costumbre habitual en la industria del software. Tanto de los proyectos que salen horribles como los que a primera vista parecen exitosos. Lamentablemente para muchos desarrolladores y jefes de equipo es una autentica perdida de tiempo. Una lástima ya que debería ser tomado como uno de los pilares en la cultura de la mejora continua.

A pesar de los frenéticos avances tecnológicos en la industria del software aun seguimos intentamos construir catedrales que se desmoronan constantemente. Necesitamos aprender de nuestros errores y entender que detrás de todo esto hay humanos, más allá de lenguajes o tecnologías.

Vamos a repasar las principales características de un post mortem, cómo deberíamos hacerlo y cuál es el objetivo.

¿Qué es un documento de postmortem en un proyecto software?

Como comentábamos al principio: la clave para aprender de los errores es documentarlos. Forma parte de la mejora continua que debemos practicar como equipo de trabajo.

En mi opinión, los principales objetivos para dedicar tiempo a escribir un postmortem de un proyecto (totalmente o parcialmente fallido) es reflejar qué hemos aprendido durante el proceso y qué vamos a cambiar para mejorarlo. Dejarlo todo por escrito y en un lugar accesible nos asegura que podremos consultarlo en el futuro y cualquier nuevo miembro del equipo podrá aprender de la experiencia vivida y narrada fielmente.

Podemos hacer un postmortem desde el proyecto más minuscolo, un error en producción o de todo lo que ha salido mal en un trimestre completo dentro de la organización.

A la hora de escribir un post mortem debemos ser honestos con nosotros mismo y con el equipo, no se trata de encontrar la persona que falló, sino ver cuáles son los procesos que no aseguraron en su día el éxito del proyecto. Debemos encontrar cosas concretas y escribirlos sin censuras. Evitar las excusas. No sirven de nada, necesitamos encontrar soluciones no vale de nada seguir justificando decisiones erróneas.

Estructurando un postmortem

Justo después de acabar un proyecto o de apagar un fuego en producción sería el momento adecuado para recopilar toda la información del suceso y hacer un informe del drama para compartirlo con el equipo. La mente humana es muy frágil y olvida rápido.

La estructura básica sería la siguiente:

• Una breve introducción del proyecto o del error. Es importante remarcar el contexto, la finalidad o el asunto por el que se escribe este postmortem. Ya sea, un proyecto, un trimestre de trabajo o un error detectado en producción.

• Una línea temporal desde que se originó el problema, incluso remontándonos si lo sabemos a su puesta en producción o arranque del proyecto. Debemos describir cada detalle, problema detectado y la persona que lo ha reportado para obtener más información si fuera necesario.

• Análisis de la causa del problema. Después de mostrar la línea en el tiempo, debemos analizar con detalle la causa del problema dando datos sobre cómo implementamos el problema y dónde estuvo el error. Hay que ser critico con los errores que hubo: mala comunicación, falta de prototipado, uso de tecnologías poco maduras, falta de analisis para escalar el volumen de peticiones, etc..

• Impacto y daños causados. Análisis del impacto desde que se originó hasta su resolución. Deberíamos hablar de datos concretos, aunque aquí se pueden mezclar sentimiento contrapuesto de búsqueda de culpables debemos asumir los errores de la forma más constructiva posible. El postmortem puede ser requerido para analizar y comprender ciertas caídas en métricas, es importante ser honesto con lo sucedido.

• Acciones para solucionar el error inmediatamente. Aquí explicaremos algunas de las acciones que ya habremos puesto secuencialmente en el timeline de los hechos. Explicaremos como hemos podido parar la hemorragia del problema y cuáles han sido las soluciones temporales al error.

• Action point para llevar a cabo para que no vuelva a ocurrir. Aqui es dónde más analiticos debemos ser y construir acciones que aporten valor para superar el error. Estas acciones pueden ser a corto como a largo plazo, es decir, podemos hablar de proyecto futuros y refactor que facilitarán que el error no vuelva a llegar a producción.

• Lecciones aprendidas. Para mi uno de los puntos más importantes junto con los action point. De aquí extraemos las conclusiones que todo el equipo ha aprendido del error. Será uno de los puntos que compartamos con mayor intereses con toda la organización para posibilitar la mejora continua y el conocimiento colectivo.

Tanto para la elaboración parcial como completa del postmortem deberías tener en cuenta al máximo número de personas del equipo implicadas. Piensa que lo que para ti pueda ser obvio o ser un sentimiento claro de fracaso para otras puede que no lo sean. Probablemente porque no son conscientes.

Recuerda que documentar adecuadamente nuestros errores hace más fácil que otras personas (presentes y futuras) puedan conocer lo sucedidos y evitar que la historia se repita.

Un buen postmortem ayudará a que todo el equipo trabaje mejor y no cometa de nuevo los mismos errores. En definitiva, aprendizaje continuo.

Foto | Flickr

También te recomendamos

¿Te acuerdas de ... Turbo C?

¿No paras ni un segundo? Estos trucos te ahorrarán tiempo y dinero para estar perfecta en Navidad (y todo el año)

Los 14 podcasts de desarrollo en español que merece la pena seguir

-
La noticia¿Por qué debería ser obligatorio escribir un post mortem por cada proyecto de software fallido? fue publicada originalmente en Genbeta Dev por Txema Rodríguez .

El desarrollo en Cloud implica una serie de diferencias que debo de tener en cuenta cuando voy a desarrollar aplicaciones para ser publicadas en este entorno.

Si bien voy a obtener acceso a capacidades de crecimiento horizontal y vertical en mi infraestructura y servicios, con niveles de disponibilidad y seguridad difícilmente obtenibles en mis instalaciones locales; también es cierto que un despliegue a la Nube significa mucho más que correr mi código en este nuevo entorno.

Y más si estoy realizando un desarrollo desde cero, o realizando sufriendo en mis carnes una migración/transformación. En donde tengo que tener muy presente, como poco, estos 3 básicos patrones de diseño.

Retry Pattern

Tengo mis servicios en Cloud, y me comunico con ellos o a través de una aplicación local (sea de escritorio o nativa de mi dispositivo móvil), o por medio de un cliente Web que está publicado en un Web App.

Todo funciona de manera correcta hasta que me encuentro con lo que se llama una “Transient Fault”, o fallo temporal del servicio, y mi aplicación no debe romperse ni quedarse congelada.

Lo primero es saber que puedo tener tres tipos de sucesos que hagan inaccesible al servicio:

• Que el propio servicio Cloud se haya caído o roto. En teoría esto no debería de ser posible que ocurriera, pero todas las grandes plataformas han sufrido incidencias graves en donde han ofrecido un rendimiento muy limitado o, directamente, han quedado inaccesibles.
• Que el problema esté en las comunicaciones. Ya sea porque tenga interrupciones, caídas, una latencia demasiado alta o un ancho de banda demasiado pequeño. Pudiendo, además, estar situado el cuello de botella en cualquiera de los nodos por donde pasa la comunicación, este bajo mi control o no.
• Que el problema esté en mi servicio. Porque esté bajo una demanda que sobrepase las capacidades del mismo, porque esté bajo un ataque, o por errores que degraden el rendimiento hasta un nivel que produzca fallos.

Sea cual sea el fallo temporal, en mi aplicación debería implementar un patrón de “Reintento”, para que esta incidencia sea soportada por el sistema. Y así, dependiendo de la importancia de la interrupción, actúe de una forma u otra.

Mi aplicación lanza una petición contra un servicio remoto en Cloud, y se encuentra con que el servicio no responde, por lo cual hago que espere un tiempo y que lo vuelva a intentar otra vez en un lapso temporal determinado.

Para evitar que los propios reintentos puedan saturar el sistema cuando vuelva a estar funcionando, configuro que el tiempo entre reintento y reintento sea cada vez más largo, hasta que supere un límite en donde (finalmente) me devuelve un mensaje de error o excepción que alerte de un fallo que no es temporal.

Otra forma, si tengo muchos clientes accediendo de forma simultánea, es que el tiempo entre reintentos sea aleatorio (dentro de unos límites), huyendo también de poder tumbar el sistema al volverse a levantar.

Es decir, hay que tener cuidado en la configuración de los tiempos de reintento definidos en la implantación del patrón, ya que son muy dependientes de las exigencias del negocio; y posiblemente sea necesario un trabajo de optimización y ajuste regular, basado en métricas.

Por otra parte, aunque no sea parte del patrón, pero si resultado, tengo que escoger entre varias posibilidades de notificación al usuario del fallo:

• Ofrecerle un sustituto. Por ejemplo, si está buscando en el catálogo de series le muestro el catálogo de películas. Esto implica una lógica de redirección basada en las preferencias de los usuarios y puede ser un tema tan complejo como efectivo y de agradecer. La principal ventaja, es que el usuario sigue utilizando la plataforma mientras se recupera el servicio.
• No decir nada. El usuario se queda esperando a que el servicio se recupere, manteniéndose en la última pantalla de interacción. Transmitiendo la sensación de que no ha ocurrido nada.
• Avisar lo antes posible. Es la estrategia adecuada si el número de usuarios es muy elevado, ya que evita una saturación por reintentos. En este caso se muestra una notificación que indique que no se puede cumplir la petición y se ofrece enlaces para salir de la petición al servicio caído.

Sin embargo, hay consideraciones a tener en cuenta al decidir implementar este patrón.

Una política demasiado agresiva de reintentos puede llevar al servicio a sus límites operativos. Además, es crítico que las peticiones puedan ser aceptadas y procesadas de forma unitaria, sin tener dependencias que requieren un momento u orden específico de llegada.

Este patrón debe ser evitado en el caso de que la realidad o las pruebas indiquen que el tipo de fallo con el que me puedo encontrar es generalmente permanente, o las operaciones del servicio al que lanzo la petición consumen mucho tiempo.

Valet Key

Cuando estamos hablando de una aplicación “normal” web o de escritorio, sin duda debo aplicar la programación asíncrona como estándar de los procesos pesados que limitan la experiencia de usuario.

Pero debo ir un paso más allá y adoptar uno de los patrones más conocidos y utilizados tanto en plataformas Cloud, como en todas aquellas en donde se realiza la autenticación y validación de un usuario para, por ejemplo, pueda acceder a una librería de fotos y descargarlas en su máquina local.

Si estuviera realizando un desarrollo acoplado, aun siendo asíncrono, llamaría primero al servicio para identificarme como usuario; dicho servicio comprobaría que tengo autorización y permisos adecuados e invocaría al servicio de almacenamiento para devolver las fotos solicitadas.

Sin embargo hay una forma un poco más indirecta, pero mucho más potente para desacoplar ambas operaciones y que cada servicio sea responsable solamente de su ámbito.

Como se observa en la figura, el cliente primero hace una llamada de identificación y autenticación al worker de la aplicación dedicado a ello. Este, el servicio de validación de usuarios, aplica la lógica que sea necesaria para comprobar que el usuario puede acceder a los recursos que está solicitando, y construye un token que le es devuelto al cliente.

A continuación, el cliente envía la petición de los recursos al servicio de almacenamiento junto con el token recibido; en el cual se incluye el periodo de validez del mismo – para dificultar que pueda ser utilizado de forma maliciosa- y los privilegios que se le han otorgado.

Fíjate que con este patrón reparto la necesidad de procesamiento entre dos servicios, consiguiendo una optimización de los recursos que va a tener un impacto favorable en el coste de operación y desacoplando entre sí los servicios, con todas las ventajas de mantenimiento, despliegue y escalado que conlleva.

Otra ventaja es el poder almacenar una traza detallada de cada solicitud de requisitos recibida en cada uno de los módulos por separado.

Pero, por el lado negativo, tengo el aumento de la complejidad del código y que el worker de autorización no tiene constancia ni seguimiento de las operaciones realizadas en el servicio de almacenamiento con los token que ha entregado.

Y por ello no se puede aplicar el Valet Key si tenemos que realizar alguna operación o validación antes de que los datos sean almacenados o enviados al cliente.

Sharding Pattern

Las bases de datos, en su concepción clásica, tienen una capacidad limitada de escalado. Es decir, si quiero que mi instancia tenga más capacidad de cálculo primero le incremento la memoria y optimizo el sistema de almacenamiento (escalado vertical), y luego empiezo a replicar la arquitectura física (escalado horizontal).

Eso sí, a un coste de infraestructura, puesta en producción y mantenimiento especialmente altos.

También me enfrento con las posibles limitaciones de ancho de banda - aún más si estoy en un sistema Cloud con comunicaciones no dedicadas – y con desafíos ante las latencias que puedo sufrir si tengo a mis clientes situados en localizaciones geográficas distantes entre sí.

Para solventar estos inconvenientes, el patrón Sharding define la forma de optimizar la explotación de la base de datos por medio de la división horizontal del conjunto de datos en nodos diferenciados.

En un ejemplo muy simplificado, podría separar los datos de la tabla de usuarios de forma que los primeros 5 millones estuvieran en el shard 1, los siguientes 5 en el shard 2 y así a continuación.

Cada shard tendrá su propia instancia, obteniendo mejores prestaciones en las operaciones al ser el número de registros menor que si tuviera una gigantesca BD con cientos de millones de registros.

Siendo, además, más simple escalar - de forma vertical-, y mucho más si estamos utilizando una base de datos en SaaS, ya que todas incluyen este patrón por defecto de forma interna.

El mayor problema, sin duda, es la complejidad añadida al codificar el patrón desde de cero, obviando que los ORM más modernos y los servicios de bases de datos en Cloud ya incluyen este modo de dividir y explotar los datos. A lo que hay que sumar la decisión de cuando ha llegado el momento de aplicarlo. Ya que está orientado a la optimización de grandes volúmenes de datos, y obtener una sustancial mejora en las IOPS del repositorio de datos.

Por último, Sharding es un patrón que se conjunta y complementa con otras técnicas de división del conjunto de datos, ya sea de forma vertical, por dominio, por funcionalidad, etc.

Y mucho más

Estos tres patrones específicos para desarrollo en Cloud, deben ser conocidos y reconocidos por los desarrolladores. Pero no por ello son los únicos.

De hecho, Microsoft, en su libro Cloud Design Patterns, describe 24 patrones (incluyendo los descritos en este artículo) que todo arquitecto de Cloud debe incluir en su toolbox de soluciones.

Event Sourcing, CQRS, Circuit Breaker, GateKeeper, Piper & filters, Throttling o cualquier otro de ellos son, esencialmente, capsulas de conocimiento que encierran soluciones estándar para los retos consustanciales al desarrollo sobre este paradigma.

Más información | Cloud Design Patterns: Prescriptive Architecture Guidance for Cloud Applications

En Genbeta Dev | Migraciones al cloud en primera persona

También te recomendamos

La que se avecina en 2012: El futuro en la Nube, borreguitos o tormentas

Google lanza PerfKit ¿Cómo evaluar el rendimiento real de las plataformas en la nube?

El día que fabricamos portátiles casi tan finos como los últimos móviles de moda

-
La noticia 3 patrones de diseño imprescindibles que deberías conocer para tu sistema en cloud: Retry, Valet Key y Sharding fue publicada originalmente en Genbeta Dev por Juan Quijano .

Es innegable que Mockito se ha convertido en una librería de referencia para crear Mocks en los tests unitarios escritos en Java y algunos otros lenguajes de la JVM.

Su simplicidad de uso unida a su potencia la han hecho una de las preferidas entre aquellos que quieren escribir tests para validar su software.

Hace algunos meses, el equipo que desarrolla Mockito lanzó por fin la versión final de Mockito 2. Una actualización que ha añadido un buen número de novedades muy interesantes, y que hoy quiero presentarte.

Novedades en Mockito 2

Mockito 2 ha añadido varias funcionalidades realmente útiles, que facilitarán la tarea de escribir tests más sencillos y útiles.

Además, ahora permite crear mocks de algunas cosas que antes eran imposibles.

Aquí te cuento cuáles son las novedades:

Ahora detecta qué mocks no son necesarios

Así es. Cuando un test contenga un mock que no está siendo utilizado, la ejecución fallará. De esta forma nos evitamos crear mocks innecesarios, y los tests se vuelven más legibles.

Si quieres, puedes evitar que esto ocurra utilizando el runner MockitoJUnitRunner.Silent.class, pero la verdad que es algo bastante útil.

Muchas mejoras en los matchers

Con el objetivo de ser más preciso, algunos de los matchers han cambiado su comportamiento.

Por ejemplo, ahora any() no incluye valores nulos. Es una buena forma de detectar dónde estamos siendo demasiado flexibles con nuestras condiciones del test.

Si queremos especificar que queremos un valor nulo para el parámetro, podemos usar el matcher isNull(). Y si queremos un comportamiento similar al antigo, entonces podemos utilizar nullable().

Otro ejemplo es que anyInt() ahora no acepta valores de tipo long. A partir de ahora tendrás que usar anyLong() en esos casos.

Por fin puedes mockear lo "inmockeable"

Mockito 2 permite mockear clases y métodos finales. Esto es una muy buena noticia, ya que podremos evitar que nuestras clases o métodos sean extendidos, y no comprometer nuestro código por el hecho de necesitar testearlo. En el caso de que no se quiera que se use herencia, se debería prohibir, como se indica en el item 17 de Effective Java.

Además, esta feature se vuelve casi imprescindible para otros lenguajes como Kotlin, donde todas sus clases y funciones son cerradas (finales) por defecto.

Esta característica es relativamente experimental, así que para activarla hay que hacer algunos ajustes. Si quieres utilizarlo, en este artículo explico cómo.

Cómo migrar de Mockito a Mockito 2

En muchos casos, esta migración será casi inmediata. Pero es posible que te encuentres problemas, y que algunos de los tests que funcionaban empiecen a fallarte.

Estos son los puntos con los que yo me he encontrado, pero seguro que hay alguno más:

Necesitas modificar el paquete del runner

Si utilizas el runner de Mockito, verás que a partir de ahora te aparecerá como deprecado.

Esto es porque han movido el runner a otro paquete, así que una simple sustitución debería funcionarte:

Este era el antiguo paquete:

import org.mockito.runners.MockitoJUnitRunner;

Y este el nuevo:

import org.mockito.junit.MockitoJUnitRunner;

Actualizar algunos matchers

Como comentaba arriba, los matchers any() ya no validan parámetros null. Yo me encontré con varios de estos, y suelen ser un pequeño olor en los tests, pues indican que están validando cualquier cosa.

El paso de null como parámetro suele ser casi siempre un caso que necesita un tratamiento especial, así que puede ser interesante desdoblar ese tests en dos: uno que use any(), y otro que use isNull().

La alternativa más rápida, sin embargo, es sustituir los any() que fallen por nullable().

Eliminar los stubs innecesarios

Aquí no tendrás mucho problema, porque los errores en los tests te marcarán exactamente qué líneas te sobran.

En alguna ocasión me he encontrado con algún stub que no hacía nada, pero mejoraba la legibilidad. Por ejemplo, mockear un método que devuelve un boolean e indicarle que retorne false.

Aquí ya va en cuestión de gustos. Yo prefiero mantener esta feature activa y evitarme otros que sí que sean innecesarios.

Conclusión

Como ves, Mockito 2 trae muchas novedades que harán tus tests más robustos y sencillos.

Han puesto mucho esfuerzo en solventar todas las carencias de la primera versión, y el resultado es realmente interesante.

Y tú, ¿estás ya usando Mockito 2? ¿Cuáles son las nuevas características que más te están ayudando? La sección de comentarios es tuya.

• En Genbeta Dev | Desmitificando los dobles de test: Mocks, stubs and friends
• Sitio oficial de Mockito

También te recomendamos

Cómo organizar un road trip y no morir en el intento

Test automáticos con QuickCheck ¿Cómo analizar nuestro código en busca de bugs?

Testeando tus aplicaciones Java con Spock: tests más expresivos, fáciles de leer y mantener

-
La noticia Mockito 2: la librería de mocks por excelencia en Java adquiere nuevos poderes fue publicada originalmente en Genbeta Dev por Antonio Leiva .

Kotlin sigue creciendo, y gracias al lanzamiento de la beta de Kotlin 1.1 ya tenemos toda la potencia de la que ya disponíamos para la JVM ahora también en nuestros navegadores.

Con Kotlin, disfrutarás de la experiencia de utilizar un lenguaje fuertemente tipado y de gran potencia como sustituto del convencional Javascript.

Hoy te quiero enseñar cómo puedes utilizarlo para crear tu primer proyecto Web de forma muy sencilla.

¿Qué necesitas para empezar?

Para poder desarrollar con Kotlin, necesitas un entorno de desarrollo muy específico: IntelliJ con la última versión EAP del plugin de Kotlin.

Para ello, descarga IntelliJ desde la página oficial de Jetbrains, y desde Tools -> Kotlin -> Configure Plugin Updates, selecciona Early Access Preview 1.1:

Puede ser que para el momento en que leas este artículo Kotlin 1.1 ya se haya liberado y puedas saltarte este segundo paso.

Creando tu proyecto KotlinJS

Ahora que ya tienes el IDE a punto, sólo necesitas crear un nuevo proyecto que utilice KotlinJS:

Crea un archivo main.kt en la carpeta src, y añade este código:

fun main(args: Array) {
    println("Hello GenbetaDev!")
}

Y ahora un index.html sencillo como este. Como ves, lo importante es que estamos añadiendo la librería estándar de Kotlin, y otro Javascript con el nombre del proyecto, que incluirá nuestro código Kotlin transpilado a Javascript:

<!DOCTYPE html><html lang="en"><head><meta charset="UTF-8"><title>Genbeta Dev</title></head><body><script src="out/production/genbetadev/lib/kotlin.js"></script><script src="out/production/genbetadev/genbetadev.js"></script></body></html>

Ejecuta el main.html (botón derecho sobre el archivo, y click sobre run), y podrás ver en la consola del navegador que se imprime el mensaje:

Añadiendo algo de código extra

Por supuesto, ahora con Kotlin podemos desarrollar el código que necesitemos usando clases, seguridad frente a nulos, lambdas... en fin, todas las funcionalidades que ya soportaba para la máquina virtual de Java.

En ejemplo muy sencillo para renderizar un H1:

import kotlin.browser.document

fun main(args: Array) {
    val h1 = document.createElement("h1")
    h1.textContent = "Hello Genbeta Dev!"
    document.body?.append(h1)
}

Gracias a la generación de DSLs sencilla que nos permite Kotlin, podrías generar cualquier HTML de forma explícita. Aquí te muestro un pequeño ejemplo donde renderizo varias etiquetas HTML:

fun main(args: Array) {

    val items = (1..10).map { "Item$it" }

    document.body?.apply {
        h1("Hello Genbeta Dev!")

        div {
            p("This is a test to generate HTML from Kotlin")

            ul {
                items.forEach { li(it) }
            }
        }
    }
}

Y este es el resultado:

¿Cómo a partir de esa estructura puedo generar el HTML resultante? Muy sencillo. Primero he creado un enumerado que identifica las etiquetas que voy a utilizar:

enum class HtmlTag(val text: String) {
    H1("h1"),
    DIV("div"),
    P("p"),
    UL("ul"),
    LI("li")
}

Y a partir de aquí, una serie de funciones que aplican sobre objetos de tipo Element. Hay dos tipos muy diferenciados: los elementos estructurales y los de texto:

fun Element.h1(text: String): Element = textElement(HtmlTag.H1, text)
fun Element.div(f: Element.() -> Unit) = structuralElement(HtmlTag.DIV, f)
fun Element.p(text: String): Element = textElement(HtmlTag.P, text)
fun Element.ul(f: Element.() -> Unit) = structuralElement(HtmlTag.UL, f)
fun Element.li(text: String) = textElement(HtmlTag.LI, text)

Y estas son las funciones base:

private fun Element.textElement(tag: HtmlTag, text: String) = createTag(tag) { textContent = text }
private fun Element.structuralElement(tag: HtmlTag, f: Element.() -> Unit) = createTag(tag) { f() }

private fun Element.createTag(tag: HtmlTag, f: Element.() -> Unit): Element {
    val element = document.createElement(tag.text)
    element.f()
    append(element)
    return element
}

Gracias a las funciones de extensión y la característica de Kotlin de permitir extraer la última función de los argumentos como un bloque de código, nos queda todo muy sencillo.

Conclusión

Si quieres ver el código completo, puedes echar un ojo al repositorio.

Como ves, Kotlin ya no es exclusivo de la JVM, sino que gracias al plugin de Kotlin podemos transpilar a Javascript y utilizar toda la potencia de un lenguaje fuertemente tipado y de un compilador que nos ayuda a evitar errores.

Si quieres aprender más sobre Kotlin, te animo a que le eches un vistazo al artículo que escribí hace un tiempo sobre Kotlin.

• En Genbeta Dev | Kotlin llega a Gradle: Escribe tus scripts de Gradle usando Kotlin script
• Tutoriales de KotlinJS en Kotlinlang

También te recomendamos

Analizamos 10 anuncios de coches: ¿fomentan la seguridad vial?

Karma.js, el concepto de Test Runner

Angular y Batarang

-
La noticia Cómo usar KotlinJS como sustituto de Javascript para desarrollo Web fue publicada originalmente en Genbeta Dev por Antonio Leiva .

Quedan pocos días para el inicio de la quinta edición del T3chFest, un evento que sigue creciendo año tras año. Esta del 2017 parece la consagración definitiva para graduarse entre los grandes eventos que todo developer debería tener marcado en su calendario, como el Codemotion o nuestro querido ExFest. Tanto por la calidad y cantidad de charlas como por una organización que cuida hasta el más mínimo detalle.

La organización la componen un grupo de estudiantes de los últimos cursos y de doctorado de la UC3M, sin ningún ánimo de lucro. Solo persiguiendo compartir conocimiento entre la comunidad de desarrolladores.

Hemos tenido la oportunidad de charlar con ellos y que nos cuenten de primera mano cómo es la preparación del evento y conocer qué nos espera este año.

Quedan muy pocos días para el inicio de la edición del 2017 ¿Podéis explicar qué es T3chFest?

T3chFest es una feria de informática y nuevas tecnologías que se celebra en la Universidad Carlos III. Es un punto de inflexión entre el mundo académico y profesional ya que nuestros asistentes son 50% estudiantes de informática y teleco, generalmente de últimos cursos; y 50% profesionales del sector. Son dos días llenos de charlas en cuatro tracks simultáneos con una zona de stands donde habrá 13 empresas haciendo reclutamiento y mostrando las nuevas tecnologías. Tenemos un Hackathon y un Concurso de Programación con más de 5.000 € en premios. Ah, y todo totalmente gratis.

También hacemos el día previo al evento una jornada privada de charlas y talleres con institutos de secundaria y bachillerato de la Comunidad de Madrid para ir metiéndoles el gusanillo de la informática. Se lo pasan en grande.

En el 2013 fue la primera edición ¿De dónde surgió organizar un evento de estas caracteristicas?

La idea surgió hace 5 años por unos estudiantes del máster de Ciencia y Tecnología que pensaron que sería una buena idea mostrar los proyectos del Departamento de Informática a los estudiantes. En un primer momento se iba a hacer en un pasillo del campus. Empezaron a moverlo y en unas semanas consiguieron tener a Peter Norvig por videoconferencia y pasaron del pasillo al Auditorio de la Universidad.

Desde entonces T3chFest no ha parado de crecer con ponentes de las grandes empresas españolas e internacionales y con un creciente número de asistentes.

¿Cuales son las principales razones para asistir? ¿Qué podrán aprender los asistentes? ¿Cómo está configurada la agenda del evento?

El principal motivo para venir a T3chFest es el programa. Tenemos tres tracks de charlas y uno de talleres. Algunas de las charlas destacadas de esta edición pueden ser la mesa redonda sobre mujeres en la tecnología donde estará la directora de Campus Madrid, Sofía Benjumea; la charla de computación cuántica por parte de IBM, los talleres sobre Hololens, las dos charlas sobre ingeniería biomédica o la charla de clausura a cargo del manager de operaciones de Uber España Manel Pujol sobre el futuro de la movilidad en las ciudades. Tendremos ingenieros de las grandes como Amazon, Microsoft, HP pero también tendremos a grandes de las empresas españolas como Atresmedia, gmv, Jobandtalent, Intelygenz, etc.

También disfrutarán probando lo que las empresas traigan en sus stands. Tendremos las Hololens, cámaras de 360º, proyección con hologramas, sets de realidad virtual, etc. Ambos días están invitados a desayunar en nuestros coffee-breaks y el viernes tras la clausura tendremos un afterparty con la actuación en directo del grupo Airlocksound.

¿Cuáles son las tecnologías de las que más se hablará?

Cada año nos fijamos en las temáticas y tecnologías que abundan en el programa. Las de esta edición son: microservicios, APIs, blockchain/bitcoin, JavaScript (en todas sus formas), chatbots, deep learning, machine learning, programación funcional y Internet of Things.

¿Quiénes son los responsables de la organización del evento?

Ahora mismo somos 9 organizadores. Los que llevamos menos ediciones organizando estamos en los últimos años del grado y los fundadores están ya a punto de doctorarse. Lo hacemos en nuestro tiempo libre.

El evento es gratuito y sin beneficios, todos los ingresos los destinamos a premios, cartelería y coffee-breaks.

A nivel de organización ¿Cómo ha sido el proceso de organización de T3chFest? ¿Qué apoyos habéis recibido? ¿Desde cuando lleváis preparando esta quinta edición?

Comenzamos siempre a organizar en septiembre. Este año fue volver de vacaciones de verano y al día siguiente ya estábamos decidiendo fechas para el Call for Talks y el reparto de tareas. Desde septiembre hasta diciembre nos dedicamos a promocionar el Call for Talks y hablar con empresas para negociar patrocinios. A partir de diciembre nos ponemos a confeccionar el programa y lo lanzamos el día 6 de enero como regalo de reyes. Entonces nos ponemos con la logística y comunicación: espacios, carteles, etc.

Por una parte la Universidad nos apoya cediéndonos todos los espacios que usamos: las salas para los tracks, grabación y streaming, zona de stands; y también con el tema de comunicación. Recibimos mucho apoyo de toda la comunidad tecnológica a la que le debemos gran parte del éxito, siempre están dispuestos a proponer charlas y a promocionar el evento en sus círculos y meetups.

Este 2017 representa la quinta edición de T3chFest ¿Cómo ha sido la evolución del evento? ¿Cómo ha crecido en número de asistentes, calls for papers y charlas/talleres?

El evento ha crecido en los dos últimos años de una forma increíble. Este año hemos recibido más de 240 propuestas en el Call for Talks, frente a las 170 del año pasado o las 80 de hace dos. También contamos con 20 patrocinadores. De momento llevamos registradas unas 2.000 entradas, el doble que el año pasado y aún queda más de una semana... Está siendo una locura. Aún hay tiempo para conseguir una entrada gratuita.

¿Cuáles son los principales retos para crear un evento de esta envergadura para un grupo de estudiantes sin una empresa detrás? ¿Quiénes son vuestros principales apoyos para que cada año vaya a más?

El principal reto es llegar a una empresa a negociar un patrocinio y que te tomen en serio, o tratar de promocionar el evento y que la gente muestre interés. En cuanto ven lo que hay detrás montado o el programa que tenemos, todos se sorprenden y nos apoyan. Está siendo ‘el año del sí’ y no dejamos de recibir felicitaciones. Tenemos muchos momentos de estrés porque nos enfrentamos a todo nosotros solos: desde programar la web para recibir las propuestas hasta hablar con las reprografías para imprimir las acreditaciones y carteles pasando por contactar con decenas de empresas para negociar patrocinios.

¿Cómo véis el futuro de T3chFest? ¿Cuáles son los eventos nacionales e internacionales que os inspiran?

Nosotros queremos seguir creciendo, ya lo estamos haciendo este año pero aspiramos y tenemos la energía para llegar mucho más lejos. Nuestra fuente de inspiración, y de ayuda en muchas ocasiones, es Codemotion y muchos eventos de Campus Madrid. Por una parte nos fijamos en los grandes eventos a nivel mundial pero no queremos alejarnos de los meetups y de las comunidades locales que tanto nos aportan.

Más información | T3chFest 2017

También te recomendamos

ExFest 2016, situándose entre los grandes eventos a nivel nacional. Hablamos con los ponentes

Analizamos 10 anuncios de coches: ¿fomentan la seguridad vial?

"La enseñanza del pensamiento algorítmico debe empezar en Primaria" Entrevista a Juan Julián Merelo

-
La noticia T3chFest 2017: "El evento ha crecido en los dos últimos años de una forma increíble, pero queremos llegar aún más lejos" fue publicada originalmente en Genbeta Dev por Txema Rodríguez .

Los desarrolladores, los programadores, aquellos que picamos o hemos picado código y construido software vemos el mundo desde otra perspectiva, con otra mirada distinta a la del resto de los mortales. Sabemos cosas que los muggles no pueden ni imaginar.

En este artículo (inspirados por este mítico hilo de Quora) hemos recopilado algunas de estas perlas de sabiduría. A ti seguramente no te descubra nada nuevo ni te sirva de mucho (bueno, espero que por lo menos te saque unas cuantas carcajadas y/o sonrisas) pero harías bien en enseñárselo a tus padres, hermanos, novio/novia, amigas/amigos, abuela, panadero... ¡a todo el mundo no developer que conozcas! Seguro que te miran con otros ojos.

Que se empieza a contar desde el 0, no desde el 1

Para que sirve la barra del 1 (|) en el teclado

Que un punto y coma (;) perdido puede ser un verdadero quebradero de cabeza

Que el código puede ser tan bello como una obra de teatro de Shakespeare.

Bueno, vale, por lo menos más bello que una novela de Dan Brown o de la señora de las '50 sombras de Grey', ¿ok?.

Que hackear no es aporrear el teclado muy rápido y poner cara de intenso

¡Cuánto daño ha hecho Hollywood!

Que Stackoverflow es la mejor web del mundo. Y que la amamos más que a nuestras madres y parejas

Que el "libre" de software libre no significa gratis

Que Python es un lenguaje de programación además de un tipo de serpiente

Que Java y Javascript son dos lenguajes diferentes que no están "emparentados" de ninguna manera

Que HTML y CSS NO son lenguajes de programación

El HTML es un lenguaje de marcado. Y CSS es un lenguaje de hojas de estilo. Haced que lo escriban 100 veces en la pizarra.

Que se puede programar a base de mugidos... o de frases de chiquito... o de lo que se te ocurra

Los lenguajes esotéricos, esas benditas locuras.

Lo que significan las camisetas de Erlich Bachman de 'Silicon Valley'

Venga, otro ejemplo:

Que pair programming no es un spinoff de 'First Dates'

Que los ordenadores sólo entienden dos valores: 0 y 1

Por lo menos los ordenadores "normales". Los cuánticos ya son otra cosa pero mejor que yo que lo explique Trudeau.

Que el primer programador fue una mujer

La gran Ada Lovelace. A sus pies.

Que "La Nube" no es más que otro ordenador. Bueno, muchos ordenadores, vale

Que todo funcione a la primera no suele ser lo habitual

Que no existe el software libre de fallos

Y terminamos con una cosa que los developers no sabemos:

Un programador no sabe reparar la televisión. Ni el frigorífico. Ni el GPS del coche. Ni la Thermomix. Ni siquiera el portátil

¿Queda clarinete? Pues eso.

También te recomendamos

Los tuits developers más divertidos. Edición Noviembre 2014

Con ustedes, 20 empresas disruptivas made in Spain

Los tuits developers más divertidos. Edición Mayo 2014

-
La noticia 18 cosas que sólo los programadores saben (y una que no saben) fue publicada originalmente en Genbeta Dev por Fernando Siles .

En poco más de un mes tendremos en Madrid la 6ª edición de Greach, la conferencia de Groovy y todo su ecosistema de España. A pesar de su bajo coste comparado con otras conferencias similares, Greach ha conseguido afianzarse año tras año y entre los ponentes cuenta con los nombres más destacados del ecosistema Groovy.

Hablamos con los organizadores que nos cuentan en más detalle qué es Greach y las principales novedades de este año.

¿Qué es exactamente Greach?

Greach es una conferencia sin ánimo de lucro que organizamos entre Alberto Vilches y un servidor en nuestro tiempo libre porque nos apasiona Groovy y queremos traer a los ponentes más importantes del ecosistema a España.

Intentamos mantener los precios lo más bajos posibles y aunque es cierto que en las últimas ediciones los hemos incrementado un poco respecto a las primeras, también siguen siendo muy bajos respecto a conferencias similares. Por ejemplo, la otra conferencia de Groovy en Europa (GR8Conf) es en Copenhague y aún teniendo una agenda muy similar a Greach, el precio es unas 4 veces más caro (y eso sin contar el vuelo, hotel y transporte en Copenhague que no es precisamente barato).

¿Cual es el público objetivo de Greach y el tipo de asistentes?

El público que esperamos y que lleva asistiendo estos últimos años son principalmente desarrolladores que trabajan con Groovy y en particular con Grails puesto que es uno de los frameworks más conocidos dentro del ecosistema.
Aún así cada vez hay más gente que se anima a venir aunque no trabajan con Groovy. Han oido hablar de Grails, Gradle, Ratpack, Spock,... y tienen curiosidad. También tenemos asistentes que repiten año tras año y que su trabajo principal es sistemas. Utilizan mucho Groovy para hacer scripts que de otra forma tendrían que hacer, por ejemplo, con bash y siempre hay alguna charla en ese aspecto que les sirve para mejorar.

Esta es la sexta edición. ¿Qué cosas han cambiado respecto a la anterior?

La principal novedad es que hemos pasado de dos a tres días. El primero de ellos, Jueves 30 de Marzo, será un día completo en el se podrá asistir a tres talleres de entre seis disponibles. Los temas son variados y van desde cómo hacer tests unitarios, de integración y funcionales de aplicaciones Grails 3, escribir plugins de Gradle, o generar archivos Excel con un DSL escrito en Groovy hasta temas tan complejos como escribir macros en Groovy.

Después los siguientes días Viernes 31 de Marzo y sábado 1 de Abril serán días de conferencia con dos tracks en paralelo con más de 20 charlas a elegir y más de 25 ponentes.

¿Cuales son los principales ponentes?

Estamos muy orgullosos de contar con los líderes de los principales proyectos y poder traerlos a Madrid un año más. Entre los ponentes más destacados de este año tenemos:

• Graeme Rocher: Project Lead de Grails. Además de la tradicional Keynote de Grails también dará una charla sobre las novedades de GORM 6.1.
• Jeff Brown: Co-fundador de Grails. Jeff dará dos charlas, una sobre cómo monitorizar y obtener métricas en aplicaciones Grails y una segunda sobre cómo desarrollador aplicaciones Grails con otros lenguajes de la JVM.
• Jochen Theodorou: Comitter de Groovy que contará las últimas novedades de la siguiente versión de Groovy 2.5 así cómo del trabajo que se ha estado haciendo en el nuevo parser.
• Andres Almiray: Además de Java Champion, Andres también es comitter de Groovy y el lider del proyecto Griffon. En esta ocasión nos hablará de cómo aprovechar más Gradle presentando una gran cantidad de plugins existentes que mejorarán nuestras builds.
• Marcin Erdmann: Marcin es el Project Lead de Geb y en su charla nos contará su experiencia al frente del proyecto tanto desde el punto de vista de un usuario como contribuyendo a él.
• Danny Hyun: Danny es committer de Ratpack y de otros proyectos opensource. En su charla explicará cómo funciona la asincronía de Ratpack, cómo usar sus Promesas y cómo poder testear todo el código.

¿Qué charlas destacaríais por ser curiosas, distintas o diferentes?

Hay muchas charlas que pueden ser distintas de las habituales, aunque obviamente sin haberlas visto todavía no podemos saber cómo serán. En cualquier caso destacamos:

• Alexa, Tell Me I’m Groovy de Ryan Vanderwerf en la que explicará cómo podemos interactuar con el Amazon Echo utilizando Groovy desde aplicaciones Grails unido además a AWS Lambda.
• Grails Interview Questions de Sergio del Amo: Sergio explicará distintas partes de Grails con preguntas que podrían hacerse en una entrevista de trabajo. ¡Una forma muy distinta de dar una charla!

¿Dónde se celebra Greach y hasta cuándo podemos comprar las entradas?

Este año tenemos dos localizaciones distintas. Los talleres serán en una academia en Nuevos Ministerios y la conferencia será, al igual que el año pasado, en los Teatros Luchana. Contamos con las dos salas de la planta de arriba, projectores HD y las ventajas de estar en un teatro.

Las entradas early bird se pueden comprar hasta el 6 de Marzo. A partir de ese momento empezará la venta de las entradas a precio normal que se mantendrán hasta unos días antes de la conferencia.

¿Y si quiero aprender en más profundidad?

Además de asistir a los talleres otra opción este año es mejorar tus conocimientos de Grails. Hemos llegado a un acuerdo con Object Computing (la empresa que esponsoriza el desarrollo de Grails) y los dos días anteriores a Greach (28 y 29 de Marzo) habrá formación de Grails a cargo de Jeff Brown a un increíble precio. Además los asistentes a Greach contarán con un descuento del 50%. Toda la información está disponible en esta web.

¿Por qué debería asistir a Greach?

Si trabajas con Groovy, Grails, Ratpack, Spock,... No deberías ni pensártelo. Tres días de talleres, charlas, networking, los ponentes más importantes del ecosistema,... imprescindible. Si no trabajas con Groovy pero trabajas dentro de la JVM también es una muy buena oportunidad de conocer otras herramientas, bibliotecas y frameworks que podrás utilizar en mayor o menor medida en tu día a día. Hay charlas de arquitectura, Jenkins, clientes HTTP, GraphQL,...

Además si estás buscando trabajo algunos de nuestros sponsors está contratando y estarán encantados de charlar contigo sobre ello.

Mas información | Greach

También te recomendamos

Las 5 novedades para desarrolladores más llamativas de la F8 2015

Con ustedes, 20 empresas disruptivas made in Spain

F8: ya puedes registrarte para asistir a la Facebook Developer Conference 2015

-
La noticia Greach 2017: La conferencia de Groovy en España llega a su 6ª edición fue publicada originalmente en Genbeta Dev por Iván López .

En la creación de aplicaciones corporativas al más puro estilo ERP, la evolución de las distintas capas del framework utilizado deben mantenerse siempre actualizadas y consistentes (lease framework como conjunto de tecnologías y arquitectura empleada).

El problema principal es que las aplicaciones desarrolladas en este entorno tienen un ciclo de vida muy largo y deben permanecer lo más agnósticas posible a los cambios tecnológicos y la obsolescencia de muchas de las tecnologías actuales.

Cuando hablamos de desarrollo frontend, este propósito no es tan simple, ya que el ecosistema crece y cambia a una velocidad vertiginosa. Es por esto que la elección de una tecnología de frontend que resulte más o menos estable y que siga una evolución sana es fundamental. En mi opinión, si hacemos aplicaciones ricas siguiendo los principios de las Single Page Applications, la decisión a día de hoy no es para nada sencilla.

Quizá en el transcurso de estos últimos años hayas evaluado para estos entornos distintas soluciones con más o menos suerte, así que muchas de las opciones seguro te sonarán :)

El estado del arte

Para entender los motivantes a la hora de elegir, podemos valorar distintos escenarios (soy consciente de que en estos escenarios voy a nombrar sólo una parte muy pequeña de los frameworks que hay disponibles, así que no te ofendas si tu favorito no se encuentra entre ellos ya que simplemente enumero algunos para dar contexto):

• HTML ligero. Basado principalmente en un maquetado HTML con o sin framework CSS responsive que nos ayude en el proceso (en esta parte hemos mejorado bastante gracias a flexbox y un principio de grid css). Como ventaja tenemos la simplicidad y la dependencia de estándares de facto y no de frameworks o implementaciones específicas. Por otra parte, en esta opción partimos de un binding bastante limitado con el DOM, ya que necesitamos alguna "capa" que nos abstraiga de este acceso, haciéndolo menos explícito y más declarativo. Para la integración con componentes ricos y casi para cualquier cosa, debemos utilizar librerías auxiliares.

• Single Page Application "ligero". Muy en la linea de la primera opción, pero con una mejor integración con el DOM, del que ya no debemos preocuparnos. Perdemos el contacto directo con los estándares y pasamos a basarnos en algún tipo de framework. Un ejemplos de esta estructura podrían ser librerías especializadas en el manejo de la vista ("V" en MVC) como son React o Vue.js. En cualquier de estos estos casos, la integración con componentes ricos, el routing en la aplicación, la carga de de módulos y otras muchas funcionalidades quedan fuera de la ecuación.

• Single Page Application "completo". Además de la integración con el DOM, en este escenario disponemos de otros aspectos necesarios en aplicaciones complejas como es el routing. Si hablamos de frameworks como Angular 1.X o 2.X, la parte de contar con componentes ricos también quedaría fuera del alcance del framework.

• Single Page Application "completo" con componentes ricos. Recuerdo inicialmente opciones muy viejunas como qooxdoo, Dojo, SmartGWT o YUI. Ya a día de hoy, estaríamos hablando de opciones como Sencha ExtJS.

En su momento y analizando las opciones disponibles para nuestro entorno corporativo que estaba más orientado a datos que otra cosa, apostamos por ExtJS 3.X allá por el 2009. Este framework venía de la evolución de YUI y aunaba los componentes básicos que necesitábamos en nuestro entorno con una visión de uniformidad y soporte que hacía pensar en que su estabilidad y frecuencia de cambio iba a ser más sencilla de gestionar. Que crédulos éramos entonces ...

La realidad

Incluso eligiendo una solución muy enfocada al desarrollo de aplicaciones corporativas con todos los aspectos que esto conlleva respecto a estabilidad en el tiempo y demás, Sencha ExJS ha sufrido una evolución dramática en los últimos tiempos, motivando cambios de gran calado en el paso a su versión 4, 5 y ahora 6, cosa que no ha sido nada fácil de llevar ante multitud de aplicaciones desarrolladas en distintas versiones y mucho trabajo de actualización entre las mismas.

Esta experiencia nos ha llevado a seguir en la parte del frontend uno de los mantras que tenemos bien aprendidos en la parte del backend: Defendámonos de los frameworks!!!

¿Qué estrategias hemos venido siguiendo para conseguir defendernos de los cambios arbitrarios en los frameworks?

La primera de todas y en mi opinión la más importante, ha sido hacer que el desarrollo de nuestras aplicaciones sea más sencillo y productivo, desarrollando con el tiempo un set de componentes comunes que utilizar en los distintos proyectos. Cuanto más rico sea este set y menos usemos los componentes provistos por el framework de forma directa, más sencillo será añadir funcionalidad nueva y actualizar las aplicaciones ante cambios de versiones.

Esta práctica va un poco en la linea del principio de diseño que nos dice "reduce your API surface", y es que cuanto más nos protegemos de los cambios de una librería de terceros con abstracciones y/o wrappers, más estables son los aplicativos que desarrollamos sobre esta y más controlada está su evolución. Podéis ver una charla interesante sobre el tema aquí:

Después de la reutilización, la segunda linea de defensa debe pasar por intentar evitar que la propia arquitectura del framework fagocite tu aplicación. Si esto sucede, no podrás cambiar ya nunca ni evolucionar su diseño, estando siempre a expensas de las decisiones que se tomen en el contexto del framework de elección. Este caso es especialmente sangrante con ExtJS, el cual pasó de no tener nada de arquitectura, a implementar MVC en la versión 4 y luego posteriormente MVVM en la 5. Una locura en los evolutivos de los distintos aplicativos!!

Por último, conseguir mantenibilidad pasa por controlar el set de tecnologías y herramientas utilizadas por tu frameworks. Si son bastante estándares y el ecosistema evoluciona, no habrá problema, pero si como en el caso de ExtJS en lugar de usar NPM o Webpack o Grunt o Gulp se utiliza un builder propio basado en Apache Ant como es Sencha Cmd, entonces estás claramente en la senda del dolor.

Como veis, no siempre es posible preveer los derroteros por los que te llevará tu framework, así que siguiendo con el principio anterior, no dejes nada en sus manos y sigue siempre la linea de la reusabilidad y de la flexibilidad de cambio.

Siguientes pasos

En nuestra situación actual y siguiendo los principios expuestos, estamos evaluando como conseguir que ExtJS pueda ser utilizado únicamente como un toolkit de componentes ricos, sin necesidad de comprometer la arquitectura completa de nuestra aplicación.

Con la versión 6 y posteriores, ya contaremos con soporte para transpilado de ES6, diseño responsivo y separación de la parte de componentes ricos respecto al resto del framework. No os perdáis la SenchaCon de este año donde se anunció el proyecto Sencha Reactor que permite el uso de los componentes ricos de ExtJS en otros frameworks a través de un bridge especial (en este caso facilitando la integración con React):

De esta manera conseguimos separar los componentes del binding con el DOM, el routing en la aplicación o la propia definición de la arquitectura cliente en general. Esta solución ya comienza a ir un poco más en la linea deseada.

Conclusiones

No creo que nuestro escenario sea especialmente desafortunado, ya que por desgracia los cambios que rompen compatibilidad son más habituales de lo que nos gustaría viendos casos como el de Angular2. No es fácil. Lo que está claro es que estos frameworks de componentes deberían sufrir una transformación en el futuro después de la aparición disruptiva de los Web Components, de forma que la manera de definirlos, reutilizarlos, integrarlos y poder usarlos en distintos dispositivos fuese siempre predecible y estándar, independientemente de su aspecto final y funcionalidad.

Desgraciadamente aun nos queda mucho camino que andar hasta que los navegadores integren de base tecnologías como HTML imports o Shadow DOM, conformándonos mientras con sets de polyfills que nos sirven como punto de partida. Quizá en un futuro podamos ver una integración más clara en frameworks como Angular o ExtJS que trabajan con directivas y componentes, de forma que puedan abandonar sus sistemas de definición propietarios en pro de la estandarización.

Como siempre, el mundo frontend nos depara interesantes movimientos. Deberemos estar atentos y no perder nunca el control de nuestros desarrollos.

También te recomendamos

17 imágenes espectaculares hechas con un móvil con las que aprender los mejores trucos fotográficos

Bootstrap 3 RC1 ya está aquí

Los 10 Frameworks/Librerías más populares de Javascript

-
La noticia Experiencias en el desarrollo de aplicaciones SPA corporativas fue publicada originalmente en Genbeta Dev por Ricardo Borillo .

Kotlin es un lenguaje creado por la compañía Jetbrains, del que ya hemos hablado varias veces en este blog, y con tan solo un año de vida, parece estar causando un gran revuelo en los últimos tiempos.

¿A qué se debe? En este artículo te cuento un poco la historia del lenguaje, y cuáles creo que son los factores que están haciendo que su acogimiento esté siendo tan rápido.

Los orígenes de Kotlin

Por si no has oído hablar anteriormente de este lenguaje, Kotlin se empezó a gestar hace unos 6 años, con la idea inicial de sustituir a Java como lenguaje de programación para los proyectos desarrollados por Jetbrains, compañía conocida por sus diferentes IDEs, entre el que destaca IntelliJ.

Se plantearon la necesidad de un lenguaje que les permitiera escribir un código más mantenible y adecuado a las condiciones actuales del desarrollo. Java se estaba quedando atrás debido al requisito de conservar su retrocompatibilidad, y esto les suponía un problema en su día a día.

Buscaban un lenguaje que corriera sobre la JVM, y que fuera extremadamente interoperable con Java en ambas direcciones, ya que no podían rehacer toda su base de código.

Tras valorar las distintas opciones, llegaron a la conclusión de que no había ninguna alternativa que les cubriese todas sus necesidades, por lo que se lanzaron a crear el suyo propio.

Las bases de Kotlin

El lenguaje no podía seguir la estela sin más de otros lenguajes de la JVM. Decidieron marcarse los siguientes objetivos:

• Que fuera sencillo y pragmático: No querían hacer un lenguaje extremadamente complicado como miles de opciones, sino algo que les permitiera expresar mucho con la menor cantidad de código posible, y que a la vez que redujera lo máximo posible la curva de aprendizaje de desarrolladores Java.
• Totalmente interoperable con Java: esto era una máxima. El resto de lenguajes desarrollados sobre la JVM, de un modo u otro, dificultaban el poder escribir código donde se mezclaran ambos lenguajes. Kotlin fue pensado para que cualquier código escrito en Java se pudiera usar directamente desde Kotlin, y viceversa.
• Ligero: no querían que el lenguaje fuera muy pesado, con el fin de que pudiera crearse código que corriera en cualquier dispositivo. Desde el principio vieron el potencial que podría aportar sobre Android, así que a ello se unió la premisa de que tenía que ser compatible con Java 6.

Con estas ideas comenzaron a crear su lenguaje, que 5-6 años después vería la luz.

2015: la primera gran explosión

El lenguaje fue evolucionando, y es allá por 2015 cuando, movido en parte por Jake Wharton y su documento donde comparaba las distintas opciones a la hora de desarrollar Apps en Android, Kotlin comienza a ganar popularidad.

Por aquel entonces Kotlin aún se encontraba en una Early Access Preview, pero en el documento ya se exponían motivos por los que este lenguaje era una gran alternativa para desarrollar en Android.

La comunidad Android, una de las más activas en el mundo Java, lo recibió con gran curiosidad, lo que supuso un gran empujón para el lenguaje. El equipo de Jetbrains supo entonces que necesitaban dar todas las facilidades a desarrolladores Android para utilizar su lenguaje.

A finales de 2015 se publicó la beta de la versión 1.0 de Kotlin, dejando claro que aquello iba en serio, y animó a mucha más gente a dar el salto.

2016: Kotlin lanza su versión 1.0 final

Hace aproximadamente un año, Kotlin anuncia el lanzamiento de la versión final de Kotlin, que hará que la adopción del lenguaje se haga algo exponencial.

Muchas personas comienzan a utilizarlo en producción y a compartir su experiencia, animando a muchos otros a seguir sus pasos.

Pero esta no es la única razón por la que la aceptación de Kotlin se convierte en algo tan espectacular. Estos son algunos de los hitos más relevantes.

Gradle anuncia que soportará oficialmente Kotlin

Una de las mayores sorpresas que nos trajo 2016 fue la presentación de que Kotlin sería oficialmente acogido por Gradle, como alternativa a Groovy, para escribir sus scripts.

Las características de lenguaje fuertemente tipado unidas a su capacidad de inferencia de tipos, lo convierten en un lenguaje con las ventajas de Groovy, pero que permite al IDE ayudarnos con autocompletado y chequeos en tiempo de compilación.

Kotlin desvela sus novedades: 1.1 e independencia de la JVM

Si algo se le podía achacar a Kotlin, era su dependencia con la Máquina Virtual de Java. Aunque ya existía Kotlin JS, para la versión 1.0 del lenguaje se había quedado como una feature experimental.

El equipo de Kotlin anuncia que la versión 1.1 incluirá Kotlin JS al completo, y que además están trabajando en un compilador nativo que les permitiría ejecutar código Kotlin sobre cualquier plataforma.

Además, anuncia novedades muy interesantes sobre el lenguaje como las co-rutinas, o los type aliases entre otros.

2017: El año de Kotlin

Si bien es cierto que durante el 2016 el crecimiento ha sido imparable, parece que es este 2017 cuando su uso se va a hacer más y más extendido.

Sobre todo en la comunidad Android, que es donde más me muevo, prácticamente todo el mundo ha oído hablar de él, y cada vez más personas se lanzan a utilizarlo en sus propios proyectos y en producción.

Pero esto no se queda sólo aquí, ya que uno de los pesos pesados en backend también da un paso adelante.

Spring anuncia soporte oficial para Kotlin

Uno de los frameworks más utilizados para servidores en Java publica su soporte para Kotlin. La compañía detrás de Spring trabajó mano a mano con el equipo de Kotlin para solventar algunos de los problemas que tenían para soportar Kotlin (principalmente que todas las clases fueran cerradas por defecto).

Ahora Spring incluye un set de utilidades que aprovecha el potencial de Kotlin para hacer que el desarrollo sea aún más sencillo.

Se publica Kotlin 1.1

Casi un año después del lanzamiento de Kotlin, el 1 de marzo se publica la mayor revisión del lenguaje hasta la fecha.

Sus dos principales novedades: Kotlin JS y las co-rutinas.

El primer punto implica que todas las features del lenguaje llegan a la web, y su interoperabilidad con Javascript vuelve a ser nuevamente una de sus mayores bazas. No necesitas crear todo tu código desde cero en Kotlin.

Además, las co-rutinas, un mecanismo para escribir y coordinar código asíncrono de forma síncrona, abre un mundo de posibilidades sobre el lenguaje. Al ser simplemente un pequeño framework, cualquiera puede crear librerías sobre el mismo para ajustar su funcionamiento a situaciones concretas.

Todas estas novedades han hecho que su aceptación no haya parado de crecer y que este haya sido exponencial. Una prueba de ello es que ya hay más de 10 millones de líneas de código repartidas en más de 8000 proyectos en Github, y que empresas como Netflix, Pinterest, Basecamp o Square ya lo están utilizando en producción.

¿Qué podemos esperar de Kotlin en el futuro?

A pesar de todo este movimiento, aún hay gente rehacia a lanzarse a la piscina, con un lenguaje relativamente joven y que las grandes compañías aún están empezando a utilizar.

Hay un par de cosas que creo que servirán de impulso para que más personas y empresas empiecen a utilizarlo:

• Más casos de éxito en producción: si bien es cierto que cada vez hay más, aún no son muchas las compañías que utilizan el lenguaje y cuentan su experiencia públicamente. Ser capaces de explicar las ventajas y de eliminar las trabas ayudarán a que este lenguaje siga evolucionando. Estoy seguro de que este 2017 vamos a tener ejemplos más que de sobra.
• Un posicionamiento por parte de Google: si bien es cierto que Google ya mencionó que no tenían ningún problema con que la gente usase Kotlin y que no iban a poner trabas para su uso, una buena parte de la comunidad Android sigue esperando un soporte oficial por parte de la compañía que desarrolla Android.

Sinceramente me parece difícil que Google se posicione, por lo que eso hace aún más necesario que se disipen todas las dudas que genera su uso en el desarrollo de aplicaciones Android. Es el sector en el que está habiendo una mayor aceptación, debido a las limitaciones inherentes de trabajar sobre una máquina virtual que sólo soporta Java 6.

Por ello, tiene el potencial de convertirse en el lenguaje de referencia para el desarrollo de Apps en Android.

Kotlin es un lenguaje muy joven, pero maduro en cuanto a sus funcionalidades y estabilidad, por lo que es un buen momento para empezar a utilizarlo y descubrir todas sus ventajas.

Ya hablamos en su momento en GenbetaDev de las características del lenguaje, y si quieres ahondar en su uso en Android, puedes echar un ojo a esta guía para iniciarte.

• En GenbetaDev | Kotlin: la Máquina Virtual de Java tiene un nuevo aliado
• Libro Kotlin for Android Developers

También te recomendamos

El nivel de juego a evitar en los eSports: ¿Qué es el tilt y cómo salir de él?

Kotlin: La Máquina Virtual de Java tiene un nuevo aliado

Kotlin desde el punto de vista de un desarrollador Groovy

-
La noticia¿Será 2017 el año de Kotlin? Repasamos su evolución y por qué deberías darle una oportunidad fue publicada originalmente en Genbeta Dev por Antonio Leiva .

Probablemente muchos de vosotros leéis Genbeta Dev a través del feed/RSS, algo bastante normal entre los desarrolladores, ávidos de consumir contenido de distintas fuentes. Pues bien, hoy os traemos una novedad importante en cuanto al nuevo diseño web de Genbeta Dev: una mejor forma de consultar todo el contenido publicado. Quizás esta vez toque echarle un ojo desde la web (guiño) (guiño).

En noviembre del año pasado, Xataka presentaba su nuevo diseño al mundo, una propuesta que destacaba por esa nueva portada que destaca por las 'top stories' o historias destacadas y esta idea empieza a propagarse a otros medios de WSL.

Os presentamos las top stories

La idea básica de este nuevo diseño se basa en las top stories. Una forma de destacar los artículos más importantes, tanto por su relevancia o por su carácter de análisis más profundo.

El concepto tradicional de blogs siempre nos ha llevado a ir navegando por un listado vertical para ir descubriendo el contenido, a veces enterrado por otros artículos. De esta forma tenemos un medio más directo de destacar ese reportaje, entrevista o análisis que será más interesante para vosotros.

En este bloque habrá una historia principal y tres noticias destacadas inmediatamente después. Si bajamos un poco más seguimos teniendo el listado habitual de artículos, sección bautizada como "Lo último", donde se pueden ver todas las publicaciones en orden cronológico igual que siempre, aunque con algunos cambios como imágenes más grandes para destacar que artículos son más relevantes.

Otro aspecto clave de este cambio ha sido crear un lenguaje visual reconocible y sobre todo coherente entre todos los medios de la casa. Por este motivo, además de la estructura de la portada, también cambiamos nuestras tipografías y logotipos para seguir la misma línea que estrenó Xataka hace varios meses.

Al igual que decíamos al principio que muchos de vosotros nos leéis por el RSS, hay tantos otros que consultáis desde el móvil o vuestra tablet. Así pues, la versión móvil también se actualiza para reflejar estos últimos cambios. Además, la web es responsive para que se adapte a todo tipo de pantallas.

Esperamos que estos cambios os resulten interesantes y mejoren la experiencia de lectura de Genbeta Dev.

Gracias por seguir confiando en nosotros y nuestros análisis. Intentaremos cumplir, tanto con estos cambios con nuestros futuros artículos, siendo vuestro medio para desarrolladores favorito.

También te recomendamos

Nube Microsoft, el espacio de Microsoft en Genbeta Dev

Bienvenidos a Genbeta Dev

El centro de alto rendimiento que convierte a jugadores buenos en estrellas de los eSports

-
La noticia Las top stories llegan a Genbeta Dev: descubre nuestro nuevo diseño web fue publicada originalmente en Genbeta Dev por Txema Rodríguez .

Hace unos meses tuve la suerte de asistir a la JS CraftCamp de Munich, una interesantísima conferencia centrada en JavaScript desde el punto de vista del Craftsmanship. En ella, una de las sesiones que propuse en este Open Space y que resultó realmente enriquecedora, fue la de revisión de Libros. La idea era simple, 45 minutos para hablar de libros que habíamos leído y porque nos habían resultado de gran interés. Amazing!! :)

No cabe decir que la lista que salió como resultado fue muuuuuuy larga, pero nunca os agobiéis por lo grande o titánica que pueda resultar una tarea inicialmente, simplemente elegid una de las referencias propuestas y comenzad a leer.

Durante este tipo de sesiones, al margen de recolectar valiosas referencias, lo más importante es ver que motivaciones tienen otros a la hora de mejorar sus skills. En este artículo os presentaré cuales son mis libros favoritos, porque han sido fundamentales para mi carrera como desarrollador y en qué orden me hubiera gustado consumirlos.

Empezando por el principio

Hay contenido que puede considerarse más "de fondo de armario", de forma que siempre nos viene bien haberlo adquirido y nos da mucha flexibilidad y perspectiva en nuestro trabajo. Quizá si tuviese que destacar uno, me quedaría con el Extremme programming explained: Embrance the change de Kent Beck. Su visión del proceso ágil y de las técnicas que componen XP han marcado mi forma de aprender y de trabajar los últimos años.

Por otra parte, existen muchas lecturas recomendables para tener una clara visión de lo que puede llegar a representar nuestra profesión y donde nos dejan movimientos como el Software Crafmanship, tan extendidos a día de hoy. Una con la que me siento más identificado últimamente es el The software Craftsman: Professionalism, Pragmatism, Pride de Sandro Mancuso.

Por último, creo que además de centrarnos en mejorar nuestros skills como desarrolladores, es igualmente importante o más desarrollar nuestra capacidad de aprender, entendiendo mejor en que consiste el proceso de aprendizaje y cómo sacarle el máximo partido posible. Para conocer más detalles sobre todo esto, échale un vistazo a este artículo que publiqué hace un tiempo y no te pierdas referencias como Apprenticeship Patterns, Thinking and learning o Thinking fast and slow.

Dando una vuelta de tuerca

Ya con una buena base y con las baterías cargadas de sabios consejos sobre cómo aprender y cual es la visión más agile de lo que debería de ser un desarrollador, un buen punto para continuar es entender de forma más profunda en qué consisten las prácticas ágiles y porque son tan importantes a la hora de desarrollar software y gestionar proyectos y equipos.

Quizá un buen punto de partida es entender Lean y porqué sus principios impregnan todo lo que hacemos dentro del mundo ágil. Para ello, el Lean from the trenches de Henrik Kniberg nos da una perspectiva práctica y aplicada de cómo acercar un ciclo ágil a las organizaciones.

Para continuar, podemos comenzar con un enfoque más práctico y más cercano al código, de forma que podamos aprender a diferenciar el buen código o código limpio del código que tiene un mal diseño, no escala y no es flexible ni extensible. Algunas buenas referencia aquí pueden ser clásicos como el Clean Code de Robert C. Martin o las Four rules of simple design de Corey Haines.

Avanzando en el diseño de software y sobretodo en el mundo orientado a objetos en el que muchos vivimos, los principios de OOP y los patrones de diseño son herramientas que debemos incorporar cuanto antes a nuestro toolbox. Lejos del Design Patterns de Erich Gamma, el cual es más una referencia para consultar que un libro a leer de principio a fin, podemos optar por el práctico e ilustrado Head First Design Patterns o simplemente centrarnos en las técnicas de diseño orientado a objetos descritas en Practical Object-Oriented Design in Ruby.El objetivo en todo caso es el mismo, aprender a reconocer en el código que escribimos los principales patrones de diseño de software orientado a objetos para poder aplicarlos posteriormente.

Por último y centrado en el concepto de mejora continua y calidad del código, no debemos olvidar referencias como Refactoring Ruby Edition, que nos introducen al mundo del refactoring como técnica utilizada para conseguir la mejora de nuestro código sin alterar su comportamiento observable. Esta guía contiene la definición del catálogo de olores que nos permitirán detectar y mejorar las áreas problemáticas de nuestro código, así como una descripción detallada de las transformaciones que podemos ir haciendo sobre nuestro código de forma segura.

No debemos olvidar además que, unido al concepto de refactoring va siempre el de testing, ya que utilizamos este último como herramienta de diseño que nos guía en el proceso de razonar sobre el código, teniendo además el beneficioso efecto colateral de la reducción de errores y de proporcionarnos una red de seguridad, tal y como nos cuenta Agile Testing o Effective Unit Testing.

Materiales avanzados

Aunque los materiales propuestos en el apartado anterior ya comienzan a ser "relativamente" avanzados, es necesario que nuestros superpoderes se sigan desarrollando con más materiales interesantes. Así pues, es el momento de pasar al siguiente nivel.

Quizá, antes de nada comenzaría por el no demasiado tratado Implementation Patterns de Kent Beck. Esta joya nos permite profundizar en los mecanismos más allá de los formalismos de definición del diseño de un sistema, como por ejemplo las cláusulas de guarda, la propagación de excepciones, la definición del estado intrínseco o extrínseco de las entidades o de cómo mantener nuestras interfaces públicas para garantizar su extensibilidad.

Siguiendo con la parte de patrones, es casi obligatoria la referencia de Refactoring to Patterns de Joshua Kerievsky, ya que va un paso más en la identificación de los patrones ya aprendidos, mostrándonos como se detectan los equilibrios de fuerzas en un proceso de refactoring y qué decisiones tomar cuando se decide actuar sobre ellas.

De vuelta al mundo del testing, GOOS o Growing Object-Oriented Software Guided by Tests de Steve Freeman, nos muestra como partiendo del concepto de Waling Skeleton podemos crear un sistema desde 0 a producción aprovechando las ventajas de cada tipo de test en cada uno de los estratos de nuestro diseño. En ciertas fases, puede ser muy conveniente reforzar nuestros conocimientos sobre Mocks, Fakes and Stubs, sobretodo teniendo en cuenta que el GOOS nos introduce a un flujo de trabajo con TDD muy outside-in y cercano sobre todo a su vertiente más mockist o de la London School.

Por último DDD Distilled de Vaughn Vernon es la versión sintética de su Implementing Domain-Driven Design, el cual nos guía a través de una serie de formalismos que definen cómo un dominio rico puede ser definido desde sus repositorios, pasando por los agregados, eventos de dominios o la definición de un lenguaje ubicuo en nuestros sistemas/negocio.

A problemas concretos soluciones concretas

Y es que en muchas ocasiones, no todo de depende de los fundamentos generales que hemos ido cultivando con esmero en los anteriores apartados. En mi opinión más personal, creo que aunque nuestra actividad laboral se centre en un entorno o conjunto de lenguajes con unas características concretas, no debemos dejar de la lado el resto de paradigmas, estudiándolos en profundidad con la misma constancia (como por ejemplo el paradigma funcional con referencias como Professor Frisby’s Mostly adequate guide to functional programming). En este sentido, quizá no vayamos a programar directamente en ningún lenguaje funcional como Haskell, pero si estudiamos sus motivaciones y uso aprenderemos multitud de lecciones importantes que aplicar a nuestra manera de desarrollar software, como pueden ser la importancia de las funciones pequeñas, con pocos parámetros, sin efectos colaterales, la inmutabilidad o la memoización.

Además de el análisis del paradigma funcional, otros muchos paradigmas pueden resultar de interés como el de la programación reactiva, el trabajo con código legado o cómo hacer presentaciones en público. En este cajón desastre que intenta ser esta apartado me gustaría destacar algunas de las referencias más notables que me he encontrado y que no tienen un lugar concreto en el mapa trazado en apartados anteriores.

Análisis del código actual y cómo identificar sus problemas, hot spots o áreas de mejora: Your Code As A Crime Scene.

Cómo afrontar proyectos de trabajo sobre código legado y qué técnicas podemos utilizar para sistematizar el proceso y ser efectivos: Working Effectively with legacy code y The Mikado Method.

Mejora de nuestro proceso de despliegue con el fin de que sea lo más flexible posible y esté ajustado a nuestros procesos internos ágiles de trabajo: Continuous delivery y Ship it.

Comunicar es una necesidad que todos tenemos. Seamos efectivos en cómo mostramos al mundo nuestras ideas: Presentation Zen y Slide:ology: The Art and Science of Creating Great Presentations.

Conclusiones

Nuestra carrera profesional como desarrollador va a estar marcada por el cambio constante en la tecnología, la cual se transforma a una velocidad vertiginosa. En este sentido, nuestro esfuerzo no puede estar enfocado al 100% en desarrollar nuestros conocimientos en torno a una tecnología o framework que puede estar muerto en un año o dos.

Debemos evolucionar y dejar de ser "Android Developer" o "PHP Developer". Debemos aspirar a ser un "Software Developer" que sea capaz de optar por el paradigma más adecuado, implementado con el mejor lenguaje y en el entornos más conveniente para el problema que tengamos que resolver. Este tipo de aspiración requiere un background mucho más cultivado que la simple devoción a una tecnología, así que enfoquemos nuestro trabajo e invirtamos tiempo en conocimientos que no van a ser perecederos y que nos acompañaran en nuestra carrera profesional más allá del próximo lenguaje o framework de moda.

¿Qué referencias añadirías y qué te han aportado como profesional?

También te recomendamos

Extendiendo la funcionalidad de las librerías básicas de Ruby con Facets

Las Usain Bolt de los teclados. Así es la mecanografía como ciencia de culto

Los 12 canales de Youtube de desarrollo en Español que merece la pena seguir

-
La noticia Los libros que como "software developer" no deberían faltar en tu estantería fue publicada originalmente en Genbeta Dev por Ricardo Borillo .

Este artículo fue publicado originalmente en el blog oficial de Kotlin.

Estamos muy emocionados con el lanzamiento de Kotlin 1.1. Las nuevas características incluidas en esta versión son extremadamente útiles para los desarrolladores de Java y para llevar el desarrollo JVM a un nuevo mundo de posibilidades.

Pero estas nuevas características, como las coroutines, o los type aliases (por poner un par de ejemplos), parecen ciencia ficción para desarrolladores de Android.

Todavía estamos atrapados en el antiguo Java 6 con pequeñas mejoras que nos obligan a desarrollar de formas casi olvidadas para la mayoría de los desarrolladores de cualquier otra plataforma.

Por lo tanto, sería normal preguntarse: ¿el equipo de Kotlin ha sido capaz de mantener la compatibilidad con Java 6 mientras saca todas estas nuevas características? La respuesta es: ¡por supuesto!

Todas estas nuevas características están disponibles para Java 6 y, por extensión, para desarrolladores de Android. Y hoy, quiero mostrarte algunas de ellos, y cómo pueden hacer tu vida aún más fácil al desarrollar aplicaciones de Android.

Type aliases: puedes hacer que tu listener sea mucho más legible

Por supuesto, los type aliases tienen muchas aplicaciones diferentes. Pero lo primero en lo que pensé fue la capacidad de hacer que los listeners sean más legibles, sin dejar de usar lambdas.

Si no has oído hablar antes de los type aliases, son básicamente una forma de cambiar el nombre de los tipos complejos a otros más legibles.

Por ejemplo, podrías tener un RecyclerViewadapter que recibiera un listener. Como sabrás, RecyclerView no tiene una forma estándar de tratar los clicks en los items, como pasa en un ListView, por lo que tenemos que salir al paso usando los que hayamos creado.

Vamos a imaginar que queremos un listener que tenga acceso a la vista. Nuestra clase adapter podría ser parecida a esta:

class MyAdapter(val items: List, val listener: (View) -> Unit) : RecyclerView.Adapter() {
    ...
}

Y tu ViewHolder probablemente también tendría que recibir ese listener, para asignarlo a la vista:

class ViewHolder(itemView: View) : RecyclerView.ViewHolder(itemView) {
    fun bind(item: Item, listener: (View) -> Unit) {
        itemView.setOnClickListener(listener)
    }
}

Este no es un caso muy complicado, pero como puedes ver, necesitamos repetir la definición de la lambda y eso, fuera de contexto, puede dificultar la lectura.

Pero podemos crear un type alias que represente un click listener:

typealias ClickListener = (View) -> Unit

Y luego utilizarlo en todos los lugares que necesitamos el listener:

class MyAdapter(val items: List, val listener: ClickListener)

o

fun bind(item: Item, listener: ClickListener) { ... }

Las data classes ahora son más potentes

Las data classes son geniales porque evitan una gran cantidad de código boilerplate. Pero carecían de cierta potencia, que las hacía inútiles en algunos casos.

Una de las nuevas características de Kotlin 1.1 es la herencia: las data classes ahora pueden heredar de otras clases. Esto permite que las data classes sean parte de las clases sealed:

sealed class UiOp {
    object Show : UiOp()
    object Hide : UiOp()
    data class Translate(val axis: Axis, val amount: Int): UiOp()
}

Y ahora, como las clases sealed pueden ser definidas fuera de la clase padre, esto también podría escribirse así:

sealed class UiOp
object Show : UiOp()
object Hide : UiOp()
data class Translate(val axis: Axis, val amount: Int): UiOp()

Desestructuración en lambdas

Las data classes pueden ser desestructuradas desde la primera versión gracias a los métodos componentX() que generan. Podrías distribuir el contenido de una data class en varias variables de esta manera:

data class Item(val text: String, val url: String)

val (text, url) = item

Pero faltaba una característica realmente potente: Poder hacer esto en lambdas. ¡La espera ha terminado! Ahora puedes hacer algo como esto:

fun bind(item: Item) = item.let { (text, url) ->
    textView.text = text
    imageView.loadUrl(url)
}

También es muy útil para usarlo en pares o conjuntos de clave/valor en un mapa de datos, por ejemplo.

Delegación de propiedades locales

La delegación de propiedades ha demostrado ser realmente útil para proporcionar habilidades extra a las propiedades de nuestras clases.

Por ejemplo, uno de los casos más útiles es la delegación perezosa (lazy delegation), que retrasa la asignación hasta que la propiedad se utiliza por primera vez.

Pero lazy también podría ser muy útil también en las variables, y Kotlin carecía de esta característica.

Ahora, con la delegación de propiedades locales, podemos hacerlo:

fun testLocalDelegation() {
    val database by lazy { createDatabase() }
    val cache by lazy { createMemoryCache() }

    if (mustUseDatabase()) {
        database.use { ... }
    } else {
        cache.use { ... }
    }
}

Aunque este ejemplo puede resolverse sin usar la delegación lazy, ayuda a entender el concepto.

Tenemos un par de objetos pesados que pueden usarse o no. Mediante el uso de lazy, podemos retrasar la instancia hasta que estamos seguros de que vamos a utilizarlo.

La primera vez que se utilice, el código dentro de las llaves se ejecutará, y se almacenará en caché en caso de que se necesite de nuevo más tarde.

Olvídate de declarar las variables no utilizadas en lambdas

Era muy común tener que declarar variables para argumentos de lambdas que al final no se usaban en ninguna parte.

Se debía a que en Kotlin 1.0 no teníamos una forma de descartar parámetros que no utilizáramos.

Como ejemplo, en el artículo donde expliqué cómo actualizar el adapter de RecyclerView usando delegación, terminé con este código:

var items: List by Delegates.observable(emptyList()) {
    prop, old, new ->
    autoNotify(old, new) { o, n -> o.id == n.id }
}

El atributo prop se utilizaba pero, hasta ahora, era necesario declararlo. Ahora puedes evitar incluirlo utilizando un guión bajo:

var items: List by Delegates.observable(emptyList()) {
    _, old, new ->
    autoNotify(old, new) { o, n -> o.id == n.id }
}

Pero era peor el caso en el que no se usaba ninguno de ellos. Si tienes más de un argumento para una lambda, debes escribirlos todos aunque no los uses.

Ahora podemos ignorarlos:

var items: List by Delegates.observable(emptyList()) {
    _, _, _ ->
    notifyDataSetChanged()
}

No sólo se están definiendo menos variables, sino que también el código se vuelve más legible. No es necesario detectar si esos argumentos se utilizan o no. Queda mucho más claro.

Coroutines

Las coroutines son las mejores noticias que hay en Kotlin 1.1. Aunque finalmente se dejaron como experimentales en este lanzamiento, son completamente funcionales y puedes comenzar a utilizarlas en tus proyectos desde hoy.

Las coroutines te permitirán escribir código asíncrono de manera síncrona, lo que permite suspender su ejecución en algún momento y esperar a un resultado, todo mientras se escribe código secuencial.

Una cosa que sabrás sobre las coroutines en Kotlin es que no son una biblioteca o una implementación específica, son una característica del lenguaje que permite crear las bibliotecas sobre ella.

Por lo tanto, aunque el código resultante puede parecer similar, es importante saber cuál es el "engranaje" que están creando esos hilos secundarios y volver al hilo principal, lo que es muy importante en Android.

Afortunadamente, la comunidad de Kotlin se mueve rápido y ya hay varias bibliotecas que traen la potencia de las coroutines a Android. Aquí tienes algunos ejemplos:

Los primeros que te pueden interesar son los oficiales que ofrece Jetbrains:

• Kotlinx-coroutines-android, que proporciona una implementación de las coroutines lista para ser usada en Android.
• Anko, que en su última versión beta incluye compatibilidad con coroutines para muchos listeners del framework.

Pero también hay muchas otras bibliotecas de terceros que implementan sus propias versiones de las coroutines:

• AsyncAwait-Android de Niek Haarman
• Async / Await de Metalab
• Si sólo quieres soporte para Retrofit, puedes echar un ojo a kotlin-coroutines-retrofit por Andrey Mischenko

Te animo no sólo a usarlas, sino también a comprobar cómo se implementan. Es la magia del open source.

Algunas otras cosas interesantes para desarrolladores Android

Hay muchas otras mejoras en esta versión, pero quiero resaltar algunas que están más centradas en el desarrollo de Android.

La primera de ellas es que ahora puede habilitar el soporte con el compilador Jack usando: jackOptions {true}. Google ha anunciado que está deprecando las herramientas de Jack, pero si las utilizas para Java 8, esto puede serte útil hasta que se publique la versión final de Android Studio 2.4.

Además, existe una nueva intention que utilizará @JvmOverloads para implementar los constructores de vistas personalizadas, que permite, literalmente, implementar constructores para vistas personalizadas en una línea (bueno, una línea muy larga) utilizando un constructor y valores predeterminados para los argumentos:

class CustomView @JvmOverloads constructor(
        context: Context, attrs: AttributeSet? = null, defStyleAttr: Int = 0
) : View(context, attrs, defStyleAttr) {
    ...
}

Conclusión

Kotlin 1.1 ha venido con un buen montón de nuevas características impresionantes que hacen que dejar de seguir utilizando Java sea aún más inevitable.

La potencia que Kotlin trae a los desarrolladores de Android está fuera de toda duda, y puedes comenzar a escribir sus aplicaciones de Android en Kotlin a partir de ahora.

Y si quieres aprender Kotlin para Android desde cero mientras desarrollas una aplicación, puedes apuntarte a este vídeo-training gratuito sobre Kotlin para desarrolladores Android que lancé hace unos días.

• Artículo original | Kotlin 1.1 is also for Android Developers
• En Genbeta Dev | ¿Será 2017 el año de Kotlin? Repasamos su evolución y por qué deberías darle una oportunidad

También te recomendamos

¿Será 2017 el año de Kotlin? Repasamos su evolución y por qué deberías darle una oportunidad

¿Vamos a volver a aprender a escribir a mano gracias a la tecnología?

Kotlin: La Máquina Virtual de Java tiene un nuevo aliado

-
La noticia Kotlin 1.1 también es para desarrolladores Android fue publicada originalmente en Genbeta Dev por Antonio Leiva .

Cuando escribimos código es importante seguir ciertas normas, buenas prácticas, reglas de estilo, coherencia en el mismo,... pero en ocasiones esto no es tan fácil, y más cuando trabajamos en un equipo en el que, al final, cada miembro tiene ciertas manías. Una forma de mejorar todo esto es utilizando un analizador estático de código.

Para Java tenemos ciertas herramientas como FindBugs, PMD y Checkstyle que llevamos utilizando durante mucho tiempo, pero tienen el problema de que con Groovy no funcionan correctamente. Para suplir esta necesidad aparece CodeNarc.

CodeNarc es un analizador estático de código Groovy que permite detectar defectos, malas prácticas, inconsistencias, problemas con el estilo del código,... y mucho más. Se trata de un framework muy flexible que por medio de reglas fácilmente configurables analiza nuestro código para mostrarnos un detallado informe a fin de que podamos mejorarlo.

Añadiendo CodeNarc a nuestro proyecto

Ok, nos hemos decidido a mejorar nuestro código Groovy, ¿cómo añadimos CodeNarc al proyecto? Tenemos diversas formas de añadirlo según nuestras necesidades y tipo de proyecto:

• Desde línea de comandos: Una forma muy sencilla de ejecutar CodeNarc aunque probablemente no la más útil.
• Tarea Ant: Probablemente se trata de una de las formas más antiguas de ejecutar CodeNarc. Si tu proyecto todavía se basa en Ant y no has pensado en cambiar a Gradle 3.x, esta es tu solución.
• Desde un test JUnit: Forma muy curiosa de ejecutar el análisis de CodeNarc aunque probablemente poco útil.
• Plugin de Maven: Si usas Maven como herramienta de construcción de tu proyecto esta será la mejor opción puesto que el plugin se encarga de configurar todo y la integración es muy sencilla.
• Plugin de Gradle: Al igual que en el caso anterior, si Gradle es tu herramienta de build, entonces este es el plugin a utilizar.
• Adicionalmente también existen plugins para distintos IDEs como IntelliJ y Eclipse, frameworks como Grails y Griffon o incluso para Sonar y Jenkins.

Tipos de reglas

La última versión de CodeNarc, la 0.27.0, incluye 348 reglas agrupadas en 22 categorías:

• Básicas: Por ejemplo para comprobar que no hay bloques else or finally vacíos.
• "Llaves": ¿Cuántas veces habéis visto if o else de una sola línea sin las llaves? Yo personalmente los odio porque son una fuente de bugs a futuro. Podemos activar reglas en esta categoría para que realicen este tipo de comprobaciones.
• Concurrencia: En esta categoría hay reglas que comprueban la coherencia de nuestro código concurrente cuando utilizamos synchronized o volatile principalmente.
• Convención: Por ejemplo cuando escribimos un if invertido, un if que puede ser convertido a un operador elvis,...
• Excepciones: Contiene reglas que fallarán si por ejemplo hacemos un throw de un NullPointerException.

Y existen muchas más como algunas que comprueban imports duplicados, variables sin utilizar, if innecesarios,...

Veamos un ejemplo

Configuración mínima

He creado un pequeño proyecto de ejemplo basado en Gradle con la configuración necesaria y unas cuantas clases con distintas infracciones para poder comprender mejor cómo funciona CodeNarc. Podeis ir revisando los commits de manera individual para comprender mejors los cambios.

Lo primero que hacemos es añadir el plugin al archivo build.gradle y configurarlo:

apply plugin: 'codenarc'
...

codenarc {
    toolVersion = '0.27.0'
    configFile = new File(projectDir, 'config/codenarc/rules.groovy')
    reportFormat = 'html'
}

Ahora añadimos el archivo de las reglas. Como veis he habilitado unas cuantas.

ruleset {
    description 'Example Project RuleSet'

    ruleset('rulesets/basic.xml')
    ruleset('rulesets/braces.xml')
    ruleset('rulesets/convention.xml')
    ruleset('rulesets/design.xml')
    ruleset('rulesets/dry.xml')
    ruleset('rulesets/exceptions.xml')
    ruleset('rulesets/formatting.xml')
    ruleset('rulesets/generic.xml')
    ruleset('rulesets/imports.xml')
    ruleset('rulesets/naming.xml')
    ruleset('rulesets/unnecessary.xml')
    ruleset('rulesets/unused.xml')
}

Con esto ya podemos empezar con el análisis del código. Sólo tenemos que ejecutar la tarea check para comprobar (en las primeras dos tareas) que se está ejecutando CodeNarc (codenarcMain) tanto para nuestro código como para los tests (codenarcTest). Eso sí, como no tenemos nada en el proyecto el informe no se ha generado.

$ ./gradlew check
:codenarcMain NO-SOURCE
:codenarcTest NO-SOURCE
:compileJava NO-SOURCE
:compileGroovy NO-SOURCE
:processResources NO-SOURCE
:classes UP-TO-DATE
:compileTestJava NO-SOURCE
:compileTestGroovy NO-SOURCE
:processTestResources NO-SOURCE
:testClasses UP-TO-DATE
:test NO-SOURCE
:check UP-TO-DATE

BUILD SUCCESSFUL

Total time: 0.67 secs

Añadiendo código de dudosa calidad

Vamos a empezar con algo muy sencillo, simplemente creamos la clase src/main/groovy/demo/Example1.groovy con lo siguiente:

package demo

class Ejemplo1 {

}

Si ahora ejecutamos de nuevo la tarea check podemos comprobar que se genera el informe con las infracciones y que además la build falla.

Primer encontramos un bloque con la fecha de ejecución y la versión de CodeNarc con la que se ha generado el informe. A continuación tenemos un bloque de resumen por paquete con el total de archivos con infracciones y también el total de infracciones de prioridad 1, 2 y 3. Después tendremos un bloque por cada archivo en el que vemos todas las infracciones del archivo con la línea de código en donde están y un pequeño fragmento del mismo. Además el nombre de la regla es un enlace a una descripción un poco más detallada de lo que significa.

Añadiendo más código

Creamos a continuación otro archivo en src/main/groovy/demo/Example2.groovy:

package demo

class Example2 {

    boolean isEvenNumber(Integer number) {
        if (number % 2 == 0)
            println "The number $number is even"
        else
            println "The number $number is odd"
    }

    void lorem() {
        println 'Lorem ipsum dolor sit amet, consectetur adipiscing elit. Duis volutpat fermentum enim. enean in viverra arcu.'
    }
}

Y si ejecutamos de nuevo CodeNarc vemos que tenemos nuevas infracciones: Sentencia if sin llaves, sentencia else sin llaves y longitud máxima de una línea.

Configurando y deshabilitando reglas

Lo primero que queremos evitar es que CodeNarc haga que falle la build cuando tenemos alguna infracción. Para ello, añadimos a la configuración en build.gradle:

codenarc {
    ...

    ignoreFailures = true
}

Ahora ejecutándolo de nuevo veremos que la build no falla. Aún así seguimos teniendo infracciones con las que puede que no estemos de acuerdo o que queramos personalizar de cierta forma.

Vamos a deshabilitar la regla ClassJavadoc porque aunque sea una buena práctica escribir el Javadoc de todas nuestras clases públicas, para este proyecto de ejemplo no nos interesa.
Para ello, primero tenemos que buscar en qué categoría está incluída la regla. Esto podemos hacerlo directamente en el índice de reglas. Después, editamos el archivo de reglas rules.groovy para deshabilitarla:

ruleset {
    ...
    ruleset('rulesets/formatting.xml') {
        'ClassJavadoc' {
            enabled = false
        }
    }
    ...
}

Si ahora generamos de nuevo el informe vemos que hemos "arreglado" esas infracciones.

Adicionalmente, también podemos excluir una regla en una clase concreta. Imaginad que necesitamos la clase vacía creada anteriormente pero no queremos ni desactivar la regla (porque entonces no detectaría más clases vacías) ni queremos tener de manera perpetua esa infracción en el informe. Para ello podemos hacer uso de la anotación @SuppressWarnings de Java:

package demo

@SuppressWarnings('EmptyClass')
class Example1 {

}

Y entonces, sólo para ese archivo esa regla concreta es ignorada:

Otra opción que tenemos disponible es configurar algunas reglas para adaptarlas a nuestras necesidades. Así, anteriormente vimos en el ejemplo 2 que teníamos una infracción de tipo LineLength porque una línea era mayor de 120 caracteres. Imaginemos que hemos decidido que queremos permitir líneas de hasta 130 caracteres:

ruleset {
    ...
    ruleset('rulesets/formatting.xml') {
        ...
        'LineLength' {
            length = 130
        }
        ...
    }
    ...
}

Haciendo esto "arreglaríamos" de nuevo esta nueva infracción.

¿Y como configuro esto para empezar?

Si no sois muy cuidadosos con el código que escribís y vuestro proyecto tiene cierto tamaño, lo más probable que ocurra nada más instalar CodeNarc es que tengais cientos o incluso miles de infracciones.
Incluso siendo muy escrupulosos es probable que haya algunas reglas que no os gusten o que su configuración por defecto no se adapte a las necesidades del equipo. Mi consejo es que vayais revisando una por una las infracciones, leyendo la documentación de las mismas y decidais si las desactivais, las configurais para que se adapten a vuestro estilo y finalmente, las respetais y corregís.

Una vez decididas las reglas y configuración con las que el equipo se siente cómodo, el paso final será decidir los umbrales para hacer que la build falle. Esto permite tener builds válidas con ciertos niveles de infracciones según la severidad de las mismas pero que, superados esos niveles, la build finalmente falle y os obligue a corregirlas.
Para hacer esto, editamos una vez más el archivo build.gradle:

codenarc {
    // Es necesario eliminar esta opción
    //ignoreFailures = true

    maxPriority1Violations = 0
    maxPriority2Violations = 5
    maxPriority3Violations = 9
}

Así, la build no fallará a menos que superemos alguno de esos umbrales.

Conclusiones

Hemos visto por qué es importante asegurar el estilo y la calidad del código en nuestro proyecto y cómo una herramienta de análisis estático de código como CodeNarc nos puede ayudar a conseguirlo. Además también hemos comprobado que es muy fácil de añadir a un proyecto y de configurar y personalizar para adaptarlo a nuestras necesidades.

Porque en ocasiones no basta sólo con creer que escribimos buen código y además también testearlo, sino que hay que tener herramientas que nos aseguren su calidad, homogeneidad y estilo. Para todo esto cuando se trata de código Groovy, sin duda CodeNarc es el mejor.

Más información | CodeNarc En Genbeta Dev | Testeando tus aplicaciones Java con Spock: tests más expresivos, fáciles de leer y mantener

También te recomendamos

Venus.js, herramienta open source para ejecutar tests unitarios en Javascript

Verdades y mentiras sobre el autismo y las pruebas de software

¿Vamos a volver a aprender a escribir a mano gracias a la tecnología?

-
La noticia CodeNarc: Análisis estático de código Groovy fue publicada originalmente en Genbeta Dev por Iván López .

Cuando alguien piensa en una empresa amante de la programación funcional en general, y de Scala en particular, es muy fácil que se nos cruce por la mente 47 Degrees.

Una compañía que nació a mitad de camino entre Cádiz y Seattle, y que a día de hoy se ha convertido por méritos propios en uno de los mayores exponentes del software libre y de la evangelización del paradigma funcional sobre la JVM.

47 Degrees ha participado en eventos tan importantes como el Typelevel Summit en Philadelphia pero, si algo les caracteriza, es la organización de eventos de talla mundial en la maravillosa ciudad de Cádiz.

Tras dos ediciones del Lambda World, ya están calentando motores para la de este año 2017, que podremos disfrutar el 26 y 27 de octubre.

Pero en esta ocasión les hemos pedido que nos hablen de cómo aprender Scala gracias a una herramienta de e-learning libre que han desarrollado: los Scala Exercises.

¿Por qué 47 Degrees ha apostado por Scala?

Es una serie de factores que se alinearon en un momento en concreto.

A nivel empresarial, siempre nos hemos considerado como una empresa enfocada a nichos de mercado. Empezamos a desarrollar para móvil cuando Android sólo era una beta y vimos como poco a poco el sector del desarrollo móvil se empezaba a colapsar, así que buscamos otro nicho en el que situarnos.

Scala es un lenguaje utilizado por empresas que tienen necesidades muy especificas (sobre todo orientadas a dar salida al tratamiento de grandes cantidades de datos), por lo que, nuestro nicho y target de clientes esta muy centrado.

A nivel tecnológico, llevábamos mucho tiempo desarrollando en Java y nos dimos cuenta que el mismo lenguaje (y nosotros mismos) necesitábamos una evolución. Es por eso que buscamos un cambio de paradigma, algo que se adaptara tanto a nuestra forma de pensar como a nuestro entendimiento de como deberían de ser los lenguajes de programación.

Es por eso, que apostamos por la programación funcional y con el lenguaje Scala, que te permite una transición amigable desde Java, ya que funciona en la JVM y permite cohabitar con ese lenguaje.

¿Qué ventajas le veis sobre el resto de lenguajes?

Trabajamos en el mundo del software desde hace tiempo y hemos aprendido lo suficiente para saber que no hay mejores lenguajes, si no, lenguajes que se adaptan mejor que otros a tus necesidades o las necesidades de tu proyecto.

Nosotros utilizamos y evangelizamos sobre Scala porque creemos que tanto la comunidad como esa tecnología esta alineada con nuestros intereses.

¿Cuál es la mejor forma de aprender Scala desde cero?

Una de las partes de la empresa en donde invertimos más tiempo y esfuerzo es en el desarrollo de Open Source y en la evangelización del lenguaje.

En nuestra página de proyectos Open Sourcepuedes acceder a más de 100 repositorios de distinta tipología y puedes utilizar para ver cómo aplicamos ese lenguaje a distintos proyectos, librerías o plataformas.

Uno de esos proyectos, de hecho, es una plataforma de e-learning basada en ejercicios, llamada Scala Exercises, donde puedes aprender como desarrollar en Scala y sobre librerías del ecosistema.

¿Cómo surgió la idea de los Scala Exercises?

Como muchos de los proyectos Open Source, parte inicialmente de una necesidad. Debido al carácter joven del lenguaje (sobre todo en los inicios, ya que llevamos en Scala cuatro años), dentro de 47 Degrees realizamos formación y trainings a nuestro equipo.

Parte de esa formación que hacíamos en el principio, era trabajar en los Scala Koans (una recopilación de lecciones y ejercicios que empiezan en un nivel básico y poco a poco van incrementando de dificultad).

Uno de los integrantes del equipo, Rafa Paradela, se dio cuenta de que el potencial de estos ejercicios era automatizarlo, gamificarlo y darle un componente social. De esa manera, la misma comunidad podría retroalimentarse y crear un proyecto vivo y en evolución.

¿Cómo lo hicisteis realidad? ¿Quién participó en su desarrollo?

Nuestra política con proyectos Open Source de este tipo es que, si quieres plantear tu idea conjuntamente con 47 Degrees, nosotros apoyamos, financiamos y hacemos todo lo posible para hacerla realidad.

Vimos que lo que nos planteaba Rafa, no sólo era algo que necesitábamos, era algo con potencial que podía ayudar a mucha gente de la comunidad, por eso, decidimos invertir muchos esfuerzos en ello.

En los años de evolución del proyecto, ha participado en Scala Exercises casi la totalidad del equipo de las tres oficinas.

¿Cuál ha sido vuestra experiencia, qué habéis aprendido de todo esto?

Scala Exercises nos ha dado muchísimo más de lo que esperábamos. Por un lado, lo seguimos utilizando activamente para nuestras formaciones, pero por otro, la comunidad lo ha convertido en una pieza clave dentro del ecosistema Scala.

Es un caso práctico de cómo una idea, si la planteas Open Source y la desarrollas por y para la comunidad, puede hacerte crecer como empresa en muchos aspectos.

¿Cómo ha sido la aceptación de la comunidad?

La primera versión de Scala Exercises era una plataforma web que validaba los ejercicios basados en los Koans mediante Javascript.

En cambio, con la segunda versión, nosotros intentamos resolver uno de los muros más difíciles que se encontraban las personas que querían aprender el lenguaje por primera vez. Instalar el entorno necesario para poder compilar por primera vez (IDE, SBT, Scala, etc.).

Trabajamos duro para hacer una plataforma que permitiera embeber un compilador real dentro de Scala Exercises, de esa manera, los ejercicios que vas realizando, no sólo se validan, si no que se compilan.

La comunidad reaccionó muy bien en la primera versión, pero fue en la segunda cuando la comunidad valoró todo el trabajo invertido. Actualmente Scala Exercises forma parte de las guías oficiales de Scala, en GitHub tenemos más de 900 estrellas y 218 forks y cada vez hay más librerías que usan Scala Exercises como forma de evangelización y aprendizaje.

¿Cualquiera puede colaborar añadiendo ejercicios?

Si. La plataforma esta viva y cualquiera puede mandar un Pull Request al repositorio para añadir o modificar ejercicios de los packs actuales.

Es más, una de las posibilidades que añadimos a la V2 de Scala Exercises, es que cualquiera puede añadir un pack de ejercicios. De esa forma, si tienes una librería basada en Scala, puedes utilizar Scala Exercises para añadir una serie de ejercicios que sirvan a los desarrolladores para entender como implementarla.

¿Recomendáis la experiencia a otras personas para que hagan lo mismo con otros lenguajes?

Sin duda. Los mismos lenguajes deberían de tener como prioridad, trabajar para que la curva de aprendizaje sea lo menos compleja posible. Por eso, Scala Exercises es una gran herramienta, permite empezar desde cero y tener una valoración previa antes de lanzarte a la piscina con el desarrollo del lenguaje.

• Scala Exercises | scala-exercises.org
• Sitio Web de 47 Degrees | 47deg.com
• Proyectos open-source | 47deg.github.io

También te recomendamos

¿Vamos a volver a aprender a escribir a mano gracias a la tecnología?

Festival Umbraco España 2014. Entrevista a sus organizadores

Droidcon Spain 2014: conociendo a los ponentes y sus charlas ¿Cuál es su visión sobre Android?(I)

-
La noticia Cómo aprender Scala con Scala Exercises. Entrevistamos a 47 Degrees fue publicada originalmente en Genbeta Dev por Antonio Leiva .

Las grandes empresas tecnológicas estadounidenses, las compañías totémicas de Silicon Valley (o de Seattle o de Austin o de Nueva York o de donde sea), son un caramelo muy goloso para cualquier desarrollador que se precie, provenga del lugar de donde provenga. Vamos, son el Barça o el Madrid de esta profesión nuestra, todos soñamos con jugar en esos campos de Mountain View o la 5ª Avenida.

Hasta ahora, conseguir un permiso de trabajo temporal para acceder a estos puestos era tedioso pero accesible (teniendo en cuenta que hay un importante grado de azar en el proceso, claro). ¿Ha cambiado esto con la llegada de la administración Trump y sus políticas proteccionistas? Si nuestro sueño es trabajar en los Estados Unidos, ¿lo tenemos ahora más complicado que hace tan sólo unos meses? Vamos a intentar arrojar algo de luz sobre este tema en las siguientes líneas.

Los distintos tipos de temporary visas

Vamos a empezar repasando los distintos tipos de permisos o visados con los que se puede acceder a los Estados Unidos siendo ciudadano español. Estos permisos, divididos en visados de inmigrante (la famosa green card) y visados de no inmigrante (las temporary visas), están expedidos por el Servicio de Ciudadanía e Inmigración, la USCIS.

• B. Visitantes con propósitos de turismo, negocios o tratamientos médicos. Los españoles realmente no necesitamos este visado para estancias menores de 90 días, tan sólo rellenar adecuadamente el famoso formulario ESTA (Electronic System for Travel Authorization) y pagar la tasa. Sí, es ese formulario en el que te preguntan si tienes pensamiento de atentar contra el presidente y si no quieres que te pase como a los Medina Azahara, rellénalo con cuidado.
• C. Tránsito a través de los Estados Unidos. Tripulación o pasaje de barcos o aviones que hagan escala en el país.
• F / M. Estudiantes académicos, técnicos o de idiomas.
• J. Visitantes de intercambio.
• D. Tripulantes de barcos o aviones.
• I. Periodistas y demás trabajadores de medios de comunicación (fotógrafos, columnistas, técnicos, colaboradores...).
• E1 / E2. Comerciante o inversor por tratado.
• H1-B. Profesionales especializados con estudios superiores o experiencia laboral equivalente. Este sería el visado al que deberíamos optar la mayoría de los desarrolladores. Luego hablaremos de ella en mayor profundidad.
• H2-A. Trabajadores estacionales agrícolas.
• H2-B. Trabajadores estacionales no agrícolas.
• H3. Aprendices (salvo médicos y académicos).
• L. Transferidos entre empresas filiales. Vamos, si estabas trabajando para alguna empresa estadounidense fuera de los Estados Unidos.
• O. Personas con habilidades extraordinarias. Artistas, actores, científicos...
• P. Deportistas de alto nivel reconocidos a nivel internacional.
• Q. Visitantes de intercambio cultural internacional.
• R. Trabajadores religiosos.

Pasos a seguir para conseguir una H1-B

Como hemos visto en el listado anterior, el visado para trabajar en los Estados Unidos que más se ajusta a nuestra experiencia como desarrolladores es el H1-B para trabajadores especializados.

Este visado, instaurado en 1990 por la administración de Bush padre, también es al que aplican (perdón por el anglicismo) profesionales de otras ramas de la ingeniería, médicos, investigadores científicos o, en una de las excepciones a la necesidad de estudios superiores, las modelos profesionales. Sí, la Primera Dama Melania Trumpentró en los Estados Unidos con una visa H1-B.

El H1-B tiene una validez de 60 meses (5 años, hablando en plata), no tiene limitación de entradas en el país ni tiene ninguna tasa extra para los ciudadanos españoles (aunque si hay que pagar los 190 dólares de tasa general del visado).

Pasos para conseguir este H1-B:

• La empresa empleadora debe solicitar en tu nombre un certificado de trabajo al Departamento de Trabajo.
• Una vez en poder del certificado, la empresa debe cumplimentar el formulario I-129 de la USCIS y que este sea aprobado por la misma.

Aquí es donde entra el factor suerte en el proceso: el gobierno norteamericano sólo concede 65.000 visados H1-B al año y las solicitudes aprobadas por la USCIS suelen ser mucho mayores: este 2017 han sido más de 199.000, en 2016 fueron más de 236.000 y en 2015 más de 233.000.

Es el momento de La Lotería. Un proceso aleatorio informatizado que este 2017 para los visados del año fiscal 2018 se celebró el 11 de abril después de muchos rumores sobre si este año se celebraría o la administración Trump apostaría por otros métodos... pero mejor no adelantemos acontecimientos.

• Si has tenido suerte y te ha tocado La Lotería, ya puedes aplicar por la visa mediante la cumplimentación formulario DS-60.
• El siguiente paso es solicitar una entrevista en la embajada de los Estados Unidos o en cualquiera de sus consulados en España. En la embajada de Madrid el tiempo de espera es de 4 días naturales.

• A la entrevista debes llevar: el pasaporte, la confirmación del DS-60, la confirmación del pago de las tasas, la confirmación del I-129 y una foto. Además de cualquier otra documentación que te sea requerida. En la entrevista te tomarán las huellas dactilares.
• Después de la entrevista tu solicitud será procesada. El tiempo de espera para este proceso en la embajada madrileña es de 3 días.

Si después de estos tres días, la respuesta es afirmativa, puedes empezar a hacer el petate: tu aventura americana esta a punto de empezar.

¿Y ahora con Trump qué?

El visado H1-B es polémico en ciertos círculos prácticamente desde su implantación. Las razones que esgrimen sus detractores son básicamente dos:

1) Que, debido a la permisividad de las instituciones, las empresas lo solicitan para otro tipo de trabajos para los que hay mano de obra nacional más que de sobra como pueden ser entrenadores deportivos, trabajadores agrícolas, profesores de preescolar o las mencionadas modelos internacionales como Melania Trump.

2) Que, gracias a la poca experiencia que se necesita para conseguirlo, sirve para formar talento de economías emergentes como India o China que luego vuelve a sus países y ayudan a disminuir la ventaja competitiva estadounidense en los sectores de IT.

Por lo tanto, con la llegada de Donald Trump a la Casa Blanca y sus prometidas políticas proteccionistas (¡Compra americano! ¡Contrata americano!) había cierta expectativa por ver si iba a tocar este permiso H1-B, gracias al cual su esposa llegó legalmente al país, y en que manera.

Durante la interminable campaña electoral Trump había llegado a decir que había que suspender la concesión de estos permisos durante uno o dos años. También habló de cambiar el método de La Lotería por la confección de un ranking meritocrático (el trabajo para conseguir esto con la gran cantidad de solicitudes que hay se antoja brutal) o un ranking por salario en orden descendente (mucho más sencillo de implementar). Sin embargo, estando ya aposentado en el despacho oval, los rumores hablaban de que se podía ampliar el cupo de 65.000 hasta los 110.000 visados, algo que ya se especuló durante la segunda legislatura de Obama, como una medida para congraciarse con las belicosas grandes compañías de Silicon Valley, que tiran mucho de talento de allende los mares.

De momento ni una cosa ni la otra: de las más 199.000 peticiones de visado se darán 65.000 para el año fiscal 2018 por medio de La Lotería celebrada a principios de este mes.

Sin embargo a finales de marzo saltaban las alarmas con respecto a los desarrolladoresen diversos foros: circulaba un memorando gubernamental que parecía indicar que el trabajo de programador podía quedarse fuera de los trabajos cualificados con derecho a H1-B o por lo menos ser escrutado de manera mucho más estricta.

En declaraciones a Bloomberg, una portavoz de la Agencia de Inmigración, la USCIS, indicaba que "esto no es un cambio en la política de elegibilidad del H1-B in campos relacionados con la informática" si no tan sólo la actualización de unas guidelines que databan del año 2000 y que estaban obsoletas.

En 2016 más de 13.000 puestos de programador en empresas de tecnología fueron cubiertos por trabajadores con visado H1-B. Veremos a ver como evoluciona esto en los próximos años bajo el mando de Trump y si las declaraciones de la USCIS son reales o una mera cortina de humo.

Imagen Melania Trump | Wkimedia Commons
Imagen Visado | Wikimedia Commons

También te recomendamos

Trabajar en el extranjero como desarrollador II: la vida de un programador en Irlanda

Alta demanda de Ingenieros de Software en Irlanda

La mano impresa en 3D en España que cambia una vida en África

-
La noticia Conseguir un visado de trabajo para los Estados Unidos de Trump si eres desarrollador fue publicada originalmente en Genbeta Dev por Fernando Siles .

Github nos permite liberar cualquier proyecto en el que hayamos estado trabajado en privado. En ocasiones, nuestra intención es simplemente compartirlo sin más pretensiones como un pet project o como ejemplo de alguna kata que hemos estado preparado. Pero cuando queremos comenzar un proyecto Open Source un poco más serio, como una librería que queramos compartir con el resto de desarrolladores, quizás debamos pararnos a pensar un poco más antes de publicar nuestro código en Github si cumple una serie de pasos previos.

Vamos a repasar una serie de puntos interesantes para cualquier proyecto Open Source. Un pequeño checklist de recomendaciones, desde la visión tanto de un maintainer de proyectos de software Open Source como de un desarrollador que se encuentra un proyecto en Github y quiere usarlo.

Razones por las que liberar tu código como Open Source

Hay muchas razones por qué un desarrollador u organización querría hacer Open Source un proyecto. Algunos ejemplos para ilustrar la situación sería:

• Pura colaboración. Quizás estemos desarrollando un proyecto por nuestra cuenta, lo hayamos mencionado en algún grupo de slack o meetup de desarrolladores, y nos lancemos a hacerlo abierto para que el resto de desarrolladores sean contributors ayudándonos a avanzar.
• De forma individual simplemente buscar hacer público alguno de tus pet project. De esta forma la gente verá cómo programas y encuentres futuras colaboraciones.
• Transparencia: Existen muchas instituciones que ven el Open Source como la forma de hacer público en lo que están trabajando para que cualquiera pueda revisarlo sin problema.

Deja claro el objetivo, las expectativas y cómo utilizar/colaborar

“Release early, release often” es una de las frases más repetidas cuando pensamos en liberar un proyecto software. Hacer público un proyecto open source es sólo el principio. Por ello, lo primero que debemos hacer es dejar claras las expectativas a cualquier desarrollador que se encuentre con él.

Fundamentalmente necesitamos clarificar lo máximo posible los siguientes puntos:

• El objetivo del proyecto. ¿Qué es? Por ejemplo: una kata, una librería, un framework en construcción, etc..
• Las instrucciones y dependencias que necesita para ser ejecutado
• Un changelog accesible sobre los cambios de versiones y las versiones disponibles.

Checklist de tareas antes de liberar un proyecto Open Source

El clásico README

Es el lugar principal y donde cualquier desarrollador irá a buscar información. Debe estar localizado como un fichero de texto markdown en la raíz del proyecto. Github hace especial énfasis de que cada proyecto cuente con su correspondiente README.

Revisa el nombre Quizás el nombre sea lo primero que creaste, al menos, cuando le dedicaste horas de trabajo en privado, pero ahora que va a ser público debes asegurate que antes de lanzarlo no entra en conflicto con ninguno ya existente y ni mucho menos con alguna marca registrada.

Añade una descripción al proyecto Debemos explicar el objetivo, las motivaciones por las que existe este proyecto. También debemos enumerar las características del proyecto, incluyendo sus funcionalidades.

Cómo debo usarlo o integrarlo Si nos encontramos con un nuevo proyecto, lo más razonables es poder ser capaces de instalarlo, hacerlo arrancar o integrar en nuestra aplicación. Así que es fundamental que buena parte del README se trate de explicar las dependencias y las instrucciones para poder usarlo/integrarlo. Y no te olvides de explicar los test de los que cuenta, seguro que alguien que quiera probar su integridad o colaborar le será de ayuda lanzar los tests antes de crear una build desde el código.

Facilita la forma de descargar el artifact o la build Lo más habitual es que hayamos usado algun gestor de dependencias o un sistema de construcción del proyecto, ya sea con node, maven, gradle, makefile, etc… así como que el binario del proyecto se pueda descargar de algún lugar como maven central o con un sencillo npm.

Automatiza todo lo que puedas Es fundamental que a parte de que lo expliques en el README cuentes con un sencillo script que facilite la vida a los desarrolladores que quieran construir por ellos mismos la build. Usa bash, gradle, ant, maven, npm, etc.. para tu proyecto.

No te olvides del marketing Aprovecha para incluir algun logo o imagen que represente tu proyecto, nunca se sabe cuando alguien quiere hablar de él quizás, algún blog. Incluir un imagen representativa de tu librerías nunca es mala idea. Y si no lo tienes claro, piensa en los animales de la portadas de los libros de O’Really.

Añade una licencia

Liberar algo al público se debe hacer con cuidado. Revisa los componentes que utilizas y decide una libería acorde a tus intenciones y que cumpla los requisitos de tu proyecto. Entre las más populares se encuentran la Apache 2, MIT o GPL. Si te lías con los derechos y obligaciones que implican puedes consultar alguna recomendaciones de Github o alguna de estas webs: Choose a License o TLDR Legal.

¿Cómo contribuir?

Esta sección va indicada especialmente para tus futuros colaboradores, así que se claro indicando una serie de issues abiertas para ir empezando, así como un pequeño roadmap con las tareas a futuro del proyecto.

Y es fundamental que dejes a disposición de los contributors un checkstyle del código del proyecto y una serie de reglas para incorporar contribuciones como un codestyle o algun hook preparado. Así como los pasos a realizar una Pull Request, ahora que Github permite los template eso debería ser obligatorio para que no se les escape ningún apartado que explica en la PR. Es recomendable que lo expliques en un fichero CONTRIBUTING.

Changelog

Añade un listado con los cambios de cada versión. Es fundamental para tus usuarios conocer que se va incorporando progresivamente en cada “salto de versión”. Respeta el versionado estándar utilizando adecuadamente la numeración de MAJOR.MINOR.PATCH.

Intenta separar cada cambio del siguiente modo:

• Nuevos componentes que has introducido, ya sean componentes, APIs nuevas, funcionalidades, etc..
• Elementos deprecated, es decir, lo que en próximas versiones será eliminado y remplazado por otros elementos. No olvides indicar el que se debería usar o la estrategia de migración.
• Elementos que han sido eliminados. Recuerda la retrocompatilidad. No borres nada en un cambio de versión que no haya sido anteriormente marcado como deprecated.
• Y por fin, los bugs que se han ido resolviendo en cada nueva versión. Añade si es posible la issue correspondiente para poder hacer un mejor seguimiento del problema que originaba. Seguro que alguien que se haya dado cabezazos con él se sentirá reconfortado al ver que ya está solucionado.

También te recomendamos

Celebremos la llegada del hombre a la Luna con el código fuente del Apollo XI

¿Por qué las pymes españolas no quieren ser grandes empresas?

CoreCLR, el núcleo de ejecución de .NET Core se publica Open Source

-
La noticia Checklist para liberar un proyecto Open Source en Github fue publicada originalmente en Genbeta Dev por Txema Rodríguez .

El término artesanía del software o software craftsmanship ha ido calando en nuestra industria desde que, en 1999 se publicara el archiconocido The Pragmatic Programmer: From Journeyman to Master. En este interesantísimo libro, se profundiza en la metáfora del programador como artesano a la hora de estudiar su evolución como profesional, de manera muy similar a como se realizaba en los gremios medievales.

Movimientos posteriores como la publicación del Manifesto por la artesanía del sotware o referencias como Software Craftsmanship: The new imperative o The Software Craftsman: Professionalism, Pragmatism, Pride, han hecho que este movimiento crezca y evolucione de forma continua, aumentando en gran medida el número de profesionales que se identifican con sus principios.

La metáfora del artesano

Para empezar, debo decir que la metáfora puede resultar un poco confusa, ya que cuando hablamos de artesanía no nos estamos refiriendo a que no sea importante automatizar y sistematizar los procesos que hacemos manualmente. De hecho, esta metáfora ha sido adoptada sobretodo por algunos paralelismos muy claros que existen entre principios de calidad y excelencia que rigen el trabajo artesanal y su equivalente en el desarrollo de software. Podéis guardar vuestro formones de momento!! Todo esto va simplemente de hacer las cosas bien y de cómo hacerlas aún mejor :)

¿Ciencia o arte?

Antes de entender los principios de la artesanía del software, creo que es de vital importancia dar respuesta a esta pregunta. Para los artesanos del software la respuesta está clara, el desarrollo de software es un arte que hay que cultivar (aunque nuestra industria se empeña en lo contrario). En este sentido, cualquier producto software creado para aportar valor a un cliente con unas necesidades específicas, debe ser diseñado a tal efecto y siguiendo estos principios. Un producto que no se adapta al problema, no aporta realmente valor a los que lo acaban utilizando.

Como desarrolladores, ¿Es este el tipo de producto que queremos producir? Entiendo que en muchos casos la respuesta es un rotundo NO, pero para conseguirlo debemos disponer de las armas adecuadas para no caer de nuevo en ese modelo a las primeras de cambio. En este sentido, en los principios de la artesanía del software están las claves de como conseguirlo. Veamos pues en los siguientes apartados, qué principios se pueden derivar de la búsqueda del profesionalismo.

Principios básicos

Para examinar estos principios, vamos a valernos del manifiesto de la artesanía del software que os comentaba anteriormente y, repasando cada uno de sus enunciados, examinaremos qué prácticas podemos comenzar a interiorizar para convertirnos en verdades artesanos.

No sólo software que funciona, sino también software bien diseñado

Uno de los conceptos que primero vienen a mi mente leyendo este primer punto, es el de economía del software. Y es que nuestro buen diseño, sobretodo en las partes de nuestro software que más impacto o más cambio reciben, es lo que nos permite seguir mejorando su estructura sin cambiar su comportamiento observable. Esto quiere decir seguir evolucionando nuestra base de código a través del refactoring, manteniendo la linearidad del coste de cambio.

No debemos olvidar que aunque el software funcione, en cada pequeño cambio tomamos decisiones a corto plazo que pueden condicionar la evolución del mismo a largo plazo. Muchas de ellas son una consecuencia de los tiempos de entrega o de la falta de información, por lo que no siempre son las más adecuadas. En esta situación, estas pequeñas decisiones que funcionan se convierten rápidamente en deuda técnica.

Hay mucha gente que opina que legacy code o código legado es el que escribimos ayer, ya que a partir de ahora debemos mantenerlo, evolucionarlo y liberarlo de la deuda técnica adquirida con técnicas como testing, refactoring o cambio en paralelo. En este ciclo continuo de evolución y mantenimiento, siempre podemos atender a una constante simple y clara, y es que las necesidades de negocio marcan el ritmo. Es por esto que invertir en estas partes de nuestro sistema nos va a reportar un valor claro en el largo plazo, permitiéndonos evolucionar hacia un sistema bien diseñado que absorba mejor el cambio y que nos aporte flexibilidad y respuesta al cambio.

No sólo responder al cambio, sino también agregar valor constantemente

Por supuesto, y siguiendo con lo que comentábamos en el apartado anterior, podemos conseguir estar dando respuesta al cambio de una forma efectiva mediante un buen diseño de nuestro software y no estar aportando valor a nuestro cliente. Pero ... ¿Cómo puede ser esto?

Imaginemos que en el producto que estamos desarrollando, queremos poder conocer el flujo de pedidos de un cliente. En muchos sistemas, esto puede ser ofrecido a través de un formulario para la ejecución de informes en el que puedo filtrar por casi todo lo que se almacena en la base de datos y acabo sacando un PDF con la lista de los últimos pedidos de un cliente concreto. No parece un escenario muy raro para cualquier software de gestión, ¿no? Pero en realidad, ¿estamos aportando todo el valor posible a nuestro usuario con esta solución? Muy probablemente no ...

Quizá en estos casos, el planteamiento debería pasar preguntarnos qué tipo de perfil en la aplicación necesita explotar esta información con el fin de proveerle de un interfaz más reducido pero adaptado a sus necesidades, de forma que como resultado pueda obtener una gráfica de evolución del flujo de pedidos del cliente junto a otros productos relacionados que otros clientes han adquirido cuando compraban el mismo producto que ha adquirido nuestro cliente (quizá le resulte de interés si se lo ofrezco la próxima vez que compre ese producto). El enfoque es un poco distinto y pasa siempre por diseñar soluciones para flujos concretos y perfiles concretos dentro de nuestro sistema y no para administrativos que sólo insertan y consultan datos sin ningún valor adicional que la propia persistencia de los mismos.

¿Nuestro producto resuelve un problema concreto o se asemeja más a un Microsoft Access?

No os dejéis engañar por la apariencia de los formularios de esta captura. Este modelo no es exclusivo de los ERP ni de las aplicaciones viejunas cliente/servidor. En las aplicaciones más hipster y molonas desarrolladas con Angular 4 y GraphQL podemos encontrar en muchas ocasiones estos mismos patrones cuando no razonamos sobre la solución en términos de simplicidad o de facilidad de uso para los distintos perfiles de usuario.

No sólo individuos e interacciones, sino también una comunidad de profesionales

Vale vale, ya identifico la necesidad de evolucionar mi producto en base a un buen diseño del software y quiero aportar valor con cada nueva funcionalidad que desarrollo, Pero entonces, ¿Cómo aprendo todo lo necesario para conseguirlo? ¿Cómo me convierto en un verdadero profesional del desarrollo del software?

Una gran pregunta sin duda y un camino largo que recorrer. En mi opinión, el primer paso debería ser aprender a aprender, de esta forma podré conseguir sacar el máximo partido al tiempo que dedique a mi aprendizaje.

El segundo sin duda es descubrir la potencialidad del aprendizaje colaborativo o en grupo. Tenemos el privilegio de ser una de las pocas profesiones que ha interiorizado el concepto de comunidad de desarrollo en la manera de relacionarnos y aprender en nuestro entorno. Ahora mismo, independientemente de en la provincia en que residas, hay decenas de comunidades locales que realizan actividades que nos llevan a seguir evolucionando y ser mejores profesionales: Coding Dojos, Charlas, Code Retreats, Hackatones, proyectos open source y mucho mucho más. En cualquier caso, si cerca de ti no suceden todas estas iniciativas, siempre tienes dos opciones: Abrir tu propio grupo local de lo que quieras o seguir aprendiendo online con el material infinito de que disponemos. La única premisa es compartir para aprender.

El ejemplo más paradigmático que conozco de aprendizaje en grupo es el de la DevScola, la escuela gratuita de programación que tenemos en Valencia y en la que cada año se amplía más y más la comunidad de nuevos desarrolladores que han crecido en un ambiente donde hacer bien las cosas es la única razón de ser.

No sólo colaboración de clientes, sino también asociaciones productivas

Aunque jueguen en otra liga, siempre podemos ver cómo los grandes se siguen asociando para hacer cosas increíbles (FaceBook & Instagram = React). A nuestra escala, cada vez que vamos a una conferencia y haciendo networking hablamos con otros profesionales del sector, estamos aprendiendo y mejorando como profesionales. Si no levantas la cabeza del teclado y sólo piensas en tu producto y en tu entorno, quizá es el momento de abrir miras y ver cómo otros están solucionando los mismos desafíos técnicos a los que tú te enfrentas. Conviertete en speaker, da una charla de cómo hacéis las cosas en tu equipo, recibe feedback y mejora tu proceso/producto. Vete de Desk Surfing a trabajar con otros durante dos semanas y aprende y aporta todo lo que puedas.

Simplemente, no dejes de moverte :)

Conclusión

Ante todo, la artesanía del software es una actitud. Es una manera de plantear tu carrera profesional y de vivirla en el día a día. Es una nueva forma de trabajar en la que a partir de ahora reflexionaremos más sobre el cómo, sobre las ceremonias, sobre la cultura que cultivamos en nuestra profesión y de nuestras relaciones con el resto de profesionales.

Yo llevo intentando caminar esta senda desde que un buen día aparecí por primera vez en una reunión de Agile Levante en la que éramos cuatro personas. Mucho ha llovido desde entonces y mucho he aprendido. En definitiva, lo que más me motiva cada día de esta profesión es lo mucho que me queda por aprender y la suerte que tengo por pertenecer a una comunidad de desarrollo tan sana y que comparte unos valores tan potentes.

También te recomendamos

Por qué prefiero trabajar en una factoría de software en vez de en una Startup

Cómo es la labor de un jungla en la Superliga Orange: Carbono nos guía

Desarrolladores metidos a emprendedores: ésta es su historia

-
La noticia Software Craftsmanship y profesionalismo fue publicada originalmente en Genbeta Dev por Ricardo Borillo .

El pasado 25 de marzo se realizó la segunda edición de Women Techmakers en Barcelona, donde cerca de 80 personas se unieron para dar visibilidad al sector femenino en el mundo de las tecnologías de la información.

Con motivo de este evento, hemos hablado con sus organizadoras, las Tech&Ladies Barcelona, sobre la situación actual de las mujeres en este sector, y también para que nos cuenten en qué consistió la organización del evento y su desarrollo.

Sin más, os dejo con la entrevista:

¿Quiénes sois Tech&Ladies Barcelona?

Las Tech&Ladies Barcelona somos 8 chicas que compartimos las ganas de motivar y dar visibilidad a las mujeres que tienen relación con el sector tecnológico. Nosotras somos: Adela Tort, Cristina Palomares, Davinia García, Elisa De Gregorio, Judit Nieto, Laia Chorro, Sara Di Zio y Vero LoGu.

¿Con qué objetivo surgió vuestra comunidad?

Nuestra comunidad surgió un poco con la idea de celebrar el primer Women Techmakers en Barcelona el año pasado. A raíz de ahí, el objetivo de las Tech&Ladies en general es ayudar a las mujeres a que se animen a dar charlas en eventos tecnológicos donde normalmente los ponentes suelen ser hombres, para reducir así la brecha de desigualdad de género en el sector. Esto se hace organizando meetups en los que se crea un ambiente de confort para dar los primeros pasos como ponentes y ganar así experiencia dando charlas.

¿Qué tipo de acciones lleváis a cabo para cumplir vuestros objetivos?

Organizamos eventos de carácter tecnológico en el que las ponentes son mujeres. Pueden ser temas de cualquier tecnología. Lo importante es que la ponente sea una mujer. La idea es crear un ambiente en el que se sientan cómodas para que empiecen a ganar confianza para hablar en público.

¿Por qué son tan necesarios grupos como el vuestro en nuestro sector?

Para dar visibilidad del papel de las mujeres en el mundo tecnológico y para animar a las mujeres a participar en eventos tecnológicos, tanto como ponentes, organizadoras y asistentes. Nuestro grupo facilita que las mujeres entren en la organización de un grupo tecnológico y sean ponentes, de esta manera ganan confianza y colaboran con otros grupos. La idea es también conseguir paridad de género en grupos tecnológicos que no sean centrados en mujeres.

¿Sigue habiendo desigualdad entre géneros en el mundo desarrollo software?

Sigue habiendo diferencias y desigualdad, pero mucho menos que en otros mundos. Hoy en día el mundo del desarrollo de software tiene más oferta que demanda, con lo que la gente, en general, está bastante cuidada y a la vez hay menos desigualdad, sobretodo en el tema salarial.

Un punto donde sí que hay desigualdad es en las posiciones de responsabilidad, en estos cargos vemos muy pocas mujeres. Hay que conseguir cambiar estas dinámicas y que las mujeres puedan y ocupen cargos de responsabilidad. Además, en las empresas de desarrollo sigue habiendo una clara diferencia entre el número de mujeres y el de hombres en el equipo.

¿Cómo ayudan eventos como los WTM a reducir esa brecha?

Creémos que eventos como los WTM crean un ambiente familiar y distendido que permite reunir a las chicas que están relacionadas con el mundo tecnológico y así darnos cuenta de que somos más de las que aparentemente vemos. Además ayudan a hacer networking y establecer contacto con otras chicas y la posibilidad de crear grupos de trabajo. Y como también acuden hombres a estos eventos se consigue que animen a las chicas a ir a otras comunidades y así se favorece la paridad de género en las comunidades desarrollo y reduce las desigualdades.

El 25 de marzo fue el segundo WTM organizado en Barcelona. ¿Qué novedades ha traído con respecto al anterior?

Este año hemos decidido cambiar el día del evento a sábado, facilitando así la asistencia a aquellos y aquellas que trabajan entre semana. Cerca de unas 80 personas nos han acompañado durante esta segunda edición. Otra novedad es el incremento de la duración del evento: de 9:00h a 17:00h, dando tiempo a muchas más charlas. Este año nuestro lugar de encuentro ha sido en la Soko Tech, un espacio de creación para emprendedores en el que se realizan talleres de distintas temáticas y en el que se celebran eventos de carácter tecnológico.

En esta segunda edición hemos querido impactar ofreciendo charlas bastante variadas con algunas ponentes de fuera de Barcelona, y talleres para motivar a los asistentes.

¿Cuál fue la agenda?

El programa del evento fue el siguiente:

Adela abrió la sesión dando la bienvenida a los asistentes presentando algunas cifras de las mujeres involucradas en el mundo tecnológico y dando a conocer el grupo de Tech&Ladies, para animar a más chicas a unirse. También incentivó a los asistentes a participar activamente en el evento tuiteando con el hashtag #wtmbcn17 y así entrar en el sorteo que se realizó al acabar la jornada.

Le siguió Anne Marie Neatham, COO de Ocado, que nos explicó la importancia de la educación en edades tempranas para acabar con el género asociado a determinadas profesiones.

Después Gema Parreño, nos hizo una introducción al diseño de redes neuronales con TensorFlow.

Antes del coffee break, Silvia Romera enseñó algunas de las aplicaciones que utiliza en las clases extraescolares de robótica que imparte y mostró cómo montar un robot y cómo programarlo utilizando Arduino.

Durante el coffee break los asistentes pudieron hacer networking con más mujeres del sector y con las ponentes además de con las organizadoras.

Clara Grima, doctora en matemáticas y profesora titular del Departamento de Matemática Aplicada I de la Universidad de Sevilla, abrió la segunda parte del evento explicando qué parte de las matemáticas hacen posible avances de la tecnología en ordenadores y móviles.

A continuación Ana Carmona, con 10 años de experiencia en .NET y experta en refactoring, enseñó algunos trucos para poder dar una segunda oportunidad al código legado.

Por último, antes del lunch break, Katerina Zalamova doctora en ciencia de materiales y emprendedora desde el 2005, presentó algunos conceptos sobre ioT y cómo gracias a esto podemos hacer nuestra casa inteligente y realizar tareas automáticamente.

En el lunch break se disfrutó de un tiempo de networking con las asistentes y las ponentes.

Después del lunch break los asistentes al evento pudieron elegir entre:

Participar en un workshop para aprender sobre design thinking a cargo de Melisa Galvao, Alexandra Negrut y Silvia Mulet UX designers en Netsuite. El taller tuvo una duración de 2h aproximadamente y los participantes pudieron aprender a solucionar una necesidad de un usuario final, empatizando con su frustración ante el problema siguiendo un proceso iterativo, que enfatizaba la importancia de llegar a una solución a través de la diversidad de opiniones de cada uno de los integrantes del equipo.

O, asistir a una charla impartida por Eva Martín, fundadora y CEO de Tiendeo.com sobre las nuevas tendencias mobile que están incurriendo en un sector, hasta el momento, tan tradicional como es el retail.

Una vez acabada la sesión de la tarde, se realizó el sorteo anunciado al empezar el evento en el que se repartieron libros de autoras del sector, camisetas y una entrada para la JBCNConf.

¿Quiénes han hecho posible este evento?

En este año hemos tenido colaboración de más patrocinadores a los que queremos dar las gracias, ya que hemos podido mejorar y celebrar el Women Techmakers de este año. Aparte de su apoyo y su presencia en la conferencia, hemos podido ofrecer un welcome pack a los asistentes, mejorar el catering y contar con la presencia de grandes ponentes. Queremos dar las gracias a GDG Barcelona, GDG Spain, Schibsted, New Relic, Erni, OpenTrends, Ironhack, Ocado y Tiendeo. Y también agradecer la ayuda con la difusión del evento a Gadwoman.

Además hemos contado con la participación de César Córcoles para la grabación de los videos y con Sandra Torras para las fotos del evento.

¿Cuáles han sido las sensaciones sobre el curso de este último WTM?

Estamos muy satisfechas con el resultado. Hemos obtenido muy buen feedback tanto por la parte de los asistentes como por la parte de las speakers y no podemos estar más contentas. Además hemos sido trending topic en Twitter!

Y para terminar, ¿qué recomendaríais a las mujeres del sector que se sienten infravaloradas simplemente por el hecho de ser mujer?

Que se unan a las comunidades que hay en sus ciudades para hacer piña. A veces un problema se ve grande por la perspectiva que uno mismo tiene frente a él. Y al compartirlo con otras personas el problema se hace más pequeño. Este tipo de comunidades ayuda a ver que no estamos solas y que si algo se nos da bien es apoyarnos las unas a las otras.

También te recomendamos

Cómo es la labor de un jungla en la Superliga Orange: Carbono nos guía

Droidcon Spain 2014: conociendo a los ponentes y sus charlas ¿Cuál es su visión sobre Android?(I)

Entrevista a BetRocket, "aplicamos la potencia de la base de datos Velneo V7 a las apuestas deportivas"

-
La noticia Women Techmakers: Entrevistamos a Tech&Ladies Barcelona fue publicada originalmente en Genbeta Dev por Antonio Leiva .

Si trabajamos en sistemas es muy común que tengamos que hacer pequeños (y no tan pequeños) scripts para automatizar ciertas tareas, conectarnos por ssh a servidores, copiar archivos, ejecutar comandos remotos,... Existen algunas herramientas para realizar estas tareas, pero ¿qué os parecería aprovecharnos de todas las ventajas que nos proporciona Groovy para hacer esto?

Sshoogr, pronunciado como sugar, es una biblioteca escrita en Groovy que proporciona un DSL para trabajar con servidores remotos por SSH. Proporciona una gran flexibilidad y numerosas opciones a la vez que tenemos acceso a todo el lenguaje Groovy y a cualquier biblioteca Java que queremos utilizar.

Primeros pasos

Tenemos dos formas de empezar a utilizar sshoorg a cual más sencilla.

Instalación

La forma más fácil y sencilla de instalar sshoorg es utilizando SDKMAN!, del que ya hemos hablado con anterioridad, así que después de instalarlo, simplemente ejecutamos:

$ sdk install sshoogr

A continuación escribimos este pequeño script Groovy:

remoteSession('ivan:password@localhost') {
  exec 'ls -l'
}

Y lo ejecutamos:

$ sshoogr test1.groovy>>> Connecting to localhost> ls -l
total 124328
drwxr-xr-x  2 ivan ivan      4096 May 19 15:32 bin
...
...<<< Disconnected from localhost

Si obteneis el error reject HostKey: localhost lo único que teneis que hacer es añadir al script anterior trustUnknownHosts = true justo antes de la closure remoteSession.

La ventaja de esa forma de instalar y utilizar sshoorg es que tenemos acceso completo al DSL sin necesidad de saber cómo funciona y realmente.

¿Y sin instalarlo?: Uso como biblioteca

La otra alternativa posible es utilizarlo directamente como biblioteca Groovy. Con esta opción no podremos aprovechar completamente el DSL pero no tendremos que instalar absolutamente nada, simplemente añadir la dependencia:

@Grab('com.aestasit.infrastructure.sshoogr:sshoogr:0.9.25')
@Grab('commons-codec:commons-codec:1.10')
import static com.aestasit.infrastructure.ssh.DefaultSsh.*

trustUnknownHosts = true
remoteSession('ivan:password@localhost') {
  exec 'ls -l'
}

En este caso vemos que el código es muy similar al anterior pero tenemos que añadir manualmente las dependencias y el import.

Sacando partido a sshoogr

Como hemos visto en ambas opciones es muy fácil y rápido empezar a utilizar sshoorg. Ahora vamos a ver algunas otras cosas que podemos hacer:

• Crear archivos remotos: Una opción muy útil, por ejemplo para crear archivos de propiedades con la configuración específica de un entorno concreto:

remoteFile('/tmp/file.properties').text = "enabled=true"

• Subir un archivo: Si en lugar de crearlo en remoto simplemente queremos subir un archivo ya existente:

  scp {
    from { localFile '/home/ivan/mi-archivo.txt' }
    into { remoteFile '/tmp/test.txt' }
  }

• Hacer un tunel ssh: En algunas ocasiones no podemos acceder directamente a la máquina destino sino que debemos hacer un salto intermedio en otra máquina. Con sshoogr tenemos distintas opciones para realizar tunnelling ssh.

• Opciones avanzadas: Por si todo lo anterior no fuera suficiente también tenemos la posibilidad de configurar muchas opciones: usuario, password y puertos por defecto, activar el modo verboso para ver más información de debug, activar o desactivar el comando que se ejecuta, la salida del comando, tiempos de espera,...

Entrevista a Andrey Adamovich, creador de sshoogr

Hemos aprovechado la ocasión para hacer una pequeña entrevista a Andrey Adamovich, creador de sshoogr:

¿De dónde viene el extraño nombre?

El nombre sshoogr viene de una combinación de SSH y GROOvy. Estaba jugando con las letras y encontré la combinación SSH-OO-GR la más interesante de todas. SSH primero, GRoovy segundo :)

¿Por qué creaste sshoogr?

sshoogr fue creado de la frustación de utilizar tareas Ant ssh y scp en scripts de Gradle. Teníamos automatizada la administración remota y el deployment a través de tareas con SSH. La opción de Ant y Gradle no parecía la mejor solución a largo plazo por la cantidad de código de script a mantener.

¿Probaste alguna otra herramienta alternativa??

Cuando cree sshoogr no había muchas alternativas para ejecutar comandos shell remotos que se integrasen adecuadamente con las herramientas y los conocimientos que tenía el equipo: principalmente Java, Groovy y Gradle. Existían alternativas en Python como Fabric y también estaba Capistrano en el mundo de Ruby. Pero aprender esas herramientas era pedir demasiado a nuestro equipo que principalmente conocía Java. Actualmente existen algunas herramientas como gradle-ssh y overthere (licenciado como GPL). También Ansible es bastante popular como herramienta de ejecución remota de scripts, pero no es muy Windows-friendly (yo tengo una máquina con Windows).

¿Tienes planes para el futuro: añadir nuevas características,...?

Tengo muchas ideas sobre como mejorar sshoorg pero el tiempo libre siempre es la mayor limitación :). Con suerte podré empezar a añadir nuevas opciones como local-protocol y controlar la introducción del password de sudo durante el verano.

Bonus: Charla sobre sshoogr de Andrey

Y para finalizar, si quereis conocer de primera mano sshoogr y verlo en acción, os recomiendo esta charla que dio Andrey en Greach 2016:

Más información | Sshoogr

También te recomendamos

Mejora tu código Java usando Groovy

Nueve anotaciones de Groovy que te harán la vida más fácil al desarrollar

¿Ya estás listo para convivir con tu vecino robot?

-
La noticia sshoogr: DSL Groovy para trabajar con servidores remotos a través de SSH fue publicada originalmente en Genbeta Dev por Iván López .