Conferencia BilboStack 2016

Esta ha sido la quinta BilboStack celebrada de forma anual en Bilbao en la localización de la Universidad de Deusto, este año la edición del 2016. Con más asistentes que en años anteriores y unas aulas dispuestas por la universidad más grandes para dar cabida a todos. Sigue manteniéndose gratuita aunque hay que reservar entrada, todas las entradas se agotaron y ha habido lista de espera para conseguir las de aquellos que finalmente tuvieron la mala suerte de no poder asistir. Si el siguiente año no quieres perdértela no hagas planes desde ya para finales de enero de 2017 cuando esperemos sea la edición del 2017.

Al igual que en anteriores entregas las presentaciones se han dividido en dos tracks con duración de 45 minutos ofrecidas en una única mañana. Este año estando el track 1 orientado a temas de programación o código y el track 2 con una temática más diversa desde equipos a productos y servicios.

No podía faltar la cuota para el popular lenguaje JavaScript este año con las dos primeras presentaciones del track 1 y si el año pasado comentaba que no había habido ninguna de Java en ya cuatro entregas, este finalmente ha tenido presencia. Aún siendo solo dos tracks me ha costado algo decidirme por la presentaciones a las que asistir. En resumen, he preferido ir salvo a la de Java a las presentaciones del track 2. React ya lo conozco al escribir el artículo Ejemplo lista de tareas con Backbone y React, en Angular 2 habrán mejorado las cosas pero se me hace redundante. En general creo que me podría enriquecer más del track 2 que del 1 ya que en mayor o menor medida las del primero ya me iban ser bastante familiares siendo programador.

Dentro de unos días se publicarán las presentaciones y no se si los vídeos con los que absorber las ideas expuestas de forma propia, aquí resumiré las presentaciones a las que asistí con las notas e ideas principales que conseguí retener al igual que hice el año pasado con la BilboStack del 2015.

Los equipos ¿nacen o se hacen? (Y si no nacen, ¿cómo se hacen?) por Teodora Bozheva

Comenzamos viendo el caso de una empresa Armenia, Armsoft, dedicada al desarrollo de software bancario. En una zona recientemente en conflicto se empieza de poco a construir una organización sin estructuras y sin procesos, todo el mundo sabe de todo. Buscan la excelencia programando. Para contratar, hacen un curso gratuito, dan formación y a los que seleccionan los contratan pero aún así si contratado finalmente no encaja se va (o supongo lo echan). Son buenos técnicamente pero le dan más importancia al trabajo en equipo que a los conocimientos técnicos.

Los equipos están autoorganizados tomando sus propias decisiones con un objetivo común claro y compartido, estando las personas que lo forman enganchados a lo que están haciendo que con sus diferencias se complementan. Un equipo autoorganizado no significa caos o falta de dirección. La autoorganización es algo natural para los equipos. Sustituir el controlar por confiar es un desafío en muchas organizaciones. Un despacho y repartir el trabajo no une, el control se ejerce por desconfianza.

¿Como hacer equipos? ¿Cómo se crean donde parece imposible? Hay equipos que emergen pero hay que cuidarlos. La empresas tienen que crear el ambiente adecuado. Los equipos nacen entre personas que confían entre ellas y se crean confiando en las personas. Se hacen uniendo personas con capacidades complementarias. En la presentación se comenta que una forma de crear equipo es realizando actividades como hacer excursiones, karts o paintball.

Cómo ser maestros constructores por Zuriñe Menendez

En el ámbito frontend de una aplicación web existen frameworks para todo pero debemos saber lo que hacen.

A la hora de organizar los archivos frontend basta con tener los directorios fonts, images, javascripts y stylesheets siendo innecesario cosas como home, custom o new para incluir en ellas elementos para ciertas partes de la aplicación. Con los diseños hechos se puede planificar la organización. Es recomendable añadir comentarios en el CSS, no usar importants (no hay !important de !important), tabular e indentar correctamente para mejor legibilidad.

Recomendable usar un reset.css y un animate.css. Se ha de cuidar el rendimiento en el cliente no cargando muchos CSS o JavaScripts (añado yo que con HTTP/2 reducir el número de archivos será menos necesario). Hay que conocer el modelo de cajas CSS. Dependiendo de archivo sobretodo si es sencillo es mejor tener una única hoja de estilos, con Sass se pueden llegar a tener muchos archivos. En el navegador hay elementos que se procesan más rápido: (de mayor a menor) id, clase, etiqueta, selector universal. Los ids tienen mayor rendimiento siendo utilizables para elementos únicos como la barra de navegación, sin embargo, no son reutilizables y para esto se pueden utilizar las clases.

Todavía hay quien usa versiones antiguas de Internet Explorer (como administraciones públicas) y en algunos casos hay que soportar 5.5, 6, 7, 8, 9, 10. Para facilitarlo se pueden usar los condicionales como <!-- [if lt IE7]>. Se debe seguir una nomenclatura prefiriendo usar el idioma inglés para dar nombres, usar el guión - para separar palabras compuestas, no usar mayúsculas ni números para los estilos CSS asignando nombre semánticos (evitando col-left, col-right, blue, dark-blue, more-dark-blue), ordenar las propiedades en el mismo orden.

Se debe usar CSS orientado a objetos (OOCCS) agrupando propiedades comunes a varios estilos y los específicos de forma individual para el estilo en concreto. Se debe validar el CSS con W3C, validar el diseño responsive y hacer minimizado para mejorar el rendimiento. En el diseño adaptable no basta con usar un display: none ya que un vídeo se seguiría cargando y consumiendo datos para evitarlo se necesita ayuda de los backenders, para estos casos se puede empezar por el desktop.

Your code as a crime scene por Vicenç García

Nos quejamos de los jefes pero el código que hacemos nosotros tampoco es perfecto y viéndolo algunas partes apestan. Se puede extraer información analizando el código. La presentación se basa en el libro Your Code as a Crime Scene.

Hay herramietas para analizar el código:

• El tamaño de los ficheros.
• Que archivos se modifican más habitualmente y si son grandes significa mayor probabilidad de problemas.
• Número de commits, ficheros y cuantos cambios se les ha hecho, autores.
• Número de indentaciones al principio de las lineas.
• Número de autores que están modificando un archivo, que solo una persona modifique un archivo tiene riesgos. O obtener el número de adiciones o eliminaciones por autor para saber quien tiene más conocimiento de él.

Estos datos son guías algunos datos pueden tener justificación a pesar de su aparente mal indicador. Otra medida es el acoplamiento temporal (ficheros que se modifican en grupo, cada vez que se cambia uno se cambia otro) que permite descubrir acoplamientos que no deberían existir entre ficheros que no deberían tener relación.

Hay que tener en cuenta:

• Process loss: la suma del equipo no es la suma de los integrantes, la necesaria comunicación resta eficiencia.
• Pluralistic ignorance: todo el mundo sabe que algo está mal pero nadie lo dice.
• Dar por buena una opinión porque se repite mucho.
• Aumentar una opinión porque está con la corriente.

Es importante tener datos para evaluar pero hay que tener cuidado con las métricas ya que son maleables.

Java ha muerto! Larga vida a Java (moderno) por Jerónimo López

Hay gente que considera que Java es una mierda y es el nuevo Cobol. Se alegan algunos motivos como:

• Uso Maven y me baja medio internet.
• Es compilado y esto lleva tiempo.
• ProblemFactory. Clases con nombres de 45 y 90 letras.
• XML largos, EJB, XML en Spring, en Struts, también el los pom de Maven, stack traces largos.
• Hola mundo de 7 líneas, con parámetros y verboso.
• Hay que declarar los beans y DTO, hay inner classes.

Con todo esto si es una mierda, pero si lo usas así tu proyecto es una mierda no Java. A partir de 1990 aparecen nuevos lenguajes, cerca de 1995: Python, Java, PHP, JavaScript, 2001: C#. Anteriormente no había un stack con lógica de negocio no acoplado a la base de datos (existía Oracle, SAP o Access, Visual FoxPro). En 1997 se añade JDBC y servlets, en 1999 Java EE con un montón de especificaciones. Java como lenguaje ha cambiado poco, más en las versiones 5 y 8, mayoritariamente ha cambiado la máquina virtual, en las primeras versiones era lenta, ya no. En Java 8 se añaden varias novedades como propiedades básicas pero muy útiles de programación funcional, lamdas, defaults methods con las que lo que antes eran 5 líneas ahora es 1.

Aparece Gradle como herramienta de construcción alternativa a Maven y Ant, con las ventajas de ambos sin sus defectos. Si la herramienta no sirve cámbiala. Antes un servidor de aplicaciones ejecutaba varias aplicaciones, ahora la aplicación ejecuta de forma embebida su propio servidor de aplicaciones que se inicia como una aplicación tradicional con java -jar app.jar de forma que se ha simplificado el despliegue. Se han puesto de moda los microframeworks Spark, Spring Boot, Vert.x, Play, … que arrancan la aplicación en muy pocos segundos. El ecosistema Java sigue evolucionando adaptándose a las nuevas tendencias (en su momento el XML era una de ellas, ya no).

En el índice Tiobe sigue siendo el más popular y en GitHub ha crecido mucho. Lo usan empresas como Google, LindedIn, Amazon, Netflix. Google incluso ha creado un compilador que traduce código Java a JavaScript. Se usa en proyectos como Casandra, Hadoop, Spark, Minecraft, elasticsearch o Android. Es escalable desde tarjetas inteligentes a granjas de servidores, desde una Raspberry Pi a un mainframe. Si Java como lenguaje no te es suficiente puedes usar Scala, Groovy, Ceylon o Clojure. Tiene buenos IDEs que facilitan la escritura de código como eclipse, IntelliJ IDEA o Netbeans.

Su futuro es bueno Sun en su momento lo hizo de código abierto y se basa en comités. Están planificadas varias mejoras, Jigsaw para modularizarlo, HTTP2, REPL, soporte JSON y finalmente se eliminará el soporte de los applets.

En realidad Java nunca dejó de molar y ha evolucionado, esto me es parecido a las bases de datos relacionales y el potente lenguaje SQL que tampoco nunca dejaron de molar y ahí está jOOQ para demostrar que los ORM no son siempre la mejor solución.

La presentación ha expuesto que Java sigue siendo una de los mejores lenguajes, plataforma y ecosistema con el que desarrollar aplicaciones, han sido todo argumentos. Si alguien lo quiere ver en la práctica puede revisar varios de los artículos que he escrito en esta bitácora:

• 10 razones para seguir usando Java
• Novedades y nuevas características de Java 8
• Nueva visita a Herramientas para un proyecto Java
• Herramienta de construcción Gradle
• Usar Gradle mediante Gradle wrapper
• Ejemplo de multiproyecto con Gradle
• Aplicación Java autocontenida con Spring Boot
• Configuración de una aplicación en diferentes entornos con Spring Cloud Config
• Información y métricas de la aplicación con Spring Boot Actuator
• Alternativa a Hibernate u ORM y ejemplo de jOOQ
• Introducción y ejemplo básico sobre Vert.x
• Aplicación web con Spark framework y Java
• Introducción a JavaFX, aplicaciones de escritorio en Java
• Programación de juegos y 3D en Java con jMonkeyEngine
• Java para tareas de scripting con JBang y Gradle

Cómo pasar de servicio a producto y no perecer en el intento por Carlos Hernández

Grandes empresas como DELL empezaron siendo un servicio de reparar ordenadores a proporcionar ordenadores personalizados o Microsoft pasando a vender licencias de su software.

Empezaron ofreciendo servicios para otros a crear un producto que ahora es quaderno para llevar el control de facturación y control de gastos. No es fácil pasar de servicio a producto y hay que preguntarse ¿por que quieres cambiar?:

• Ser los propietarios reales de tu trabajo. En el trabajo para otros se aprende.
• Tomar el control de tu destino, tener tu trabajo, no que te lo den otros.

¿A que estás dispuesto a renunciar?:

• Si pasas de servicio a producto deberás abandonar a los clientes de tus servicios.
• La expectativa de crecimiento o dinero que proporcionará el producto puede ser mucho menor que la real.

¿Cómo lo hicieron?

• Con muchas horas de trabajo.
• Durante un tiempo trabajando para sus clientes de los servicios.
• Gastando los ahorros.

En 2005 no había muchas herramientas o se debían instalar en Windows. Empezaron con un SaaS en 2006. En 2009 estaban en varias cosas al mismo tiempo, eran 3 y uno se dedicaba por completo al producto otro al 50% y otro a finalizar con los antiguos clientes. En 2010 se desarrolla la segunda versión de endeve con buenos resultados a base de marketing. En 2012 todos trabajan en el proyecto. España es un mercado pequeño en cuanto a internet, se internacionalizan. En 2013 se renombra endeve a quaderno internacionalizándose de una isla de Canarias a nivel mundial. En 2014 se automatizan las facturas integrándolo con sistemas de pago y el producto va funcionando.

Hacer negocios básicos no es sexy pero estos resuelven problemas reales y una buena oportunidad para crear productos. Con su experiencia empezando de nuevo daría al inglés importancia desde el principio, crearía una audiencia para tener clientes desde un inicio, elegiría la solución más sencilla evolucionándola a medida que se conoce a los usuarios escuchándoles y diciendo no o sí a sus sugerencias, tu eres el dueño no tienes por que aceptarlas todas. Mejor externalizar servicios como marketing o publicidad ya que es difícil poder con todo siendo pequeños y otros saben más que tú en sus áreas de conocimiento.

Usan herramientas como Slack, Trello, gmail, pasarela de pago stripe que considera mejor opción que PayPal para integrarse.

Otros ejemplos de productos son:

• Death to the stock photos
• Marvel app

Sigues pudiendo saciar tu curiosidad con algunos vídeos de YouTube de elComite donde están disponibles casi todas las presentaciones de las ediciones 2012, 2013 y 2014, del 2015 no se hicieron aunque si algunos audios y de este 2016 si que he visto en el track 2 al menos una cámara creo que grabando, de ser así supongo que las encontrarás en el canal del YouTube anterior.

De nuevo hay que dar las gracias a sus organizadores, ponentes, Universidad de Deusto, asistentes y a la guerrera minoría de asistentas. Hasta el 2017, no te la pierdas.