El documento proporciona consejos para que un equipo de desarrollo sea más rápido, enfocándose en seis áreas clave: 1) enfocarse solo en lo necesario, 2) establecer claramente la dirección, 3) mejorar la coordinación entre el equipo, 4) identificar y reducir las cosas que roban tiempo, 5) asegurar que las cosas se hagan de manera efectiva, y 6) formar un equipo comprometido. El documento enfatiza la importancia de la transparencia, automatización, toma de decisiones por consenso,
Slides de la charla del open space de wecode 2019.
Cuento qué reglas seguimos en @plasticscm para crear el código más simple posible. Cosas como que no usamos herencia, ni sobrecarga de métodos y que nuestro mantra es "pasa parámetros y todo irá bien"
Este documento presenta una introducción a Esteve Castells y varios conceptos clave de SEO para desarrolladores, incluyendo cómo los frameworks de renderizado del lado del cliente como React pueden afectar la indexación de motores de búsqueda y recomendaciones para mejorar la velocidad de carga, el enlazado interno, las redirecciones y más.
Android es el gran competidor de Apple cuando se habla de sistemas operativos móviles. Ambos han sabido explotar la pasión por el desarrollo de aplicaciones, aunque el sistema basado en Linux, lleva cierta ventaja en el mercado. En este taller, podrás desarrollar una aplicación partiendo desde cero. En él, se explicarán las principales facilidades de la plataforma para realizar a través del mecanismo de los Intents tareas como escanear códigos de barras, hacer fotografías, grabar vídeo o audio...
Ponente: Jorge Juan Barroso trabaja de Senior Developer en el departamento de Aplicaciones Móviles de Tuenti. Ha participado en los desarrollos de las aplicaciones de J2ME, Blackberry y Android, centrándose en la actualidad en ésta última.
Este documento ofrece consejos y recomendaciones para desarrollar aplicaciones Android. Aborda temas como ejecutar tareas en hilos separados para evitar bloqueos, usar AsyncTask, handlers y ThreadPoolExecutor. También recomienda el uso de parcelables, bundles, listviews, cacheo, providers y pruebas automatizadas.
Cómo volarle la peluca a tus usuarios con la velocidad de tu sitio?Martin Siniawski
Este documento presenta técnicas para optimizar el rendimiento del frontend de sitios web. Propone cinco puntos clave: 1) usar sprites para reducir solicitudes HTTP, 2) comprimir imágenes, 3) unificar y minificar archivos JavaScript y CSS antes de comprimirlos, 4) cargar JavaScript de forma dinámica según la página, y 5) cargar plugins sociales de forma asíncrona. También enfatiza la importancia de medir el rendimiento para identificar áreas de mejora.
Rendimiento y velocidad, acelera tu sitio WordPressLibreCon
Que un sitio web cargue rápido es algo muy importante cuando desarrollamos un sitio web. Tanto de cara ahorrar costes de infraestructura como para mejorar al máximo la experiencia de usuario, debemos optimizar al máximo nuestro sitio web. Explicación cómo de una manera sencilla y rápida podemos optimizar nuestros sitios desarrollados en WordPress para así conseguir un tiempo de carga y peso de las páginas menores. Autor: Dani Reguera (Profesor e investigador en Mondragon Unibertsitatea). Librecon.io
Escalabilidad y alto rendimiento con Symfony2Ricard Clau
En esta charla se pretenden tocar todas las cosas que debemos tener en cuenta para sacar el máximo rendimiento y poder escalar usando Symfony2.
Se toca desde parámetros de configuración de PHP y APC, optimización de Composer, dónde optimizar, quick wins varios, cómo hacer profiling correctamente, BBDD NoSQL vs SQL y por supuesto lecciones aprendidas en mis anteriores trabajos
Slides de la charla del open space de wecode 2019.
Cuento qué reglas seguimos en @plasticscm para crear el código más simple posible. Cosas como que no usamos herencia, ni sobrecarga de métodos y que nuestro mantra es "pasa parámetros y todo irá bien"
Este documento presenta una introducción a Esteve Castells y varios conceptos clave de SEO para desarrolladores, incluyendo cómo los frameworks de renderizado del lado del cliente como React pueden afectar la indexación de motores de búsqueda y recomendaciones para mejorar la velocidad de carga, el enlazado interno, las redirecciones y más.
Android es el gran competidor de Apple cuando se habla de sistemas operativos móviles. Ambos han sabido explotar la pasión por el desarrollo de aplicaciones, aunque el sistema basado en Linux, lleva cierta ventaja en el mercado. En este taller, podrás desarrollar una aplicación partiendo desde cero. En él, se explicarán las principales facilidades de la plataforma para realizar a través del mecanismo de los Intents tareas como escanear códigos de barras, hacer fotografías, grabar vídeo o audio...
Ponente: Jorge Juan Barroso trabaja de Senior Developer en el departamento de Aplicaciones Móviles de Tuenti. Ha participado en los desarrollos de las aplicaciones de J2ME, Blackberry y Android, centrándose en la actualidad en ésta última.
Este documento ofrece consejos y recomendaciones para desarrollar aplicaciones Android. Aborda temas como ejecutar tareas en hilos separados para evitar bloqueos, usar AsyncTask, handlers y ThreadPoolExecutor. También recomienda el uso de parcelables, bundles, listviews, cacheo, providers y pruebas automatizadas.
Cómo volarle la peluca a tus usuarios con la velocidad de tu sitio?Martin Siniawski
Este documento presenta técnicas para optimizar el rendimiento del frontend de sitios web. Propone cinco puntos clave: 1) usar sprites para reducir solicitudes HTTP, 2) comprimir imágenes, 3) unificar y minificar archivos JavaScript y CSS antes de comprimirlos, 4) cargar JavaScript de forma dinámica según la página, y 5) cargar plugins sociales de forma asíncrona. También enfatiza la importancia de medir el rendimiento para identificar áreas de mejora.
Rendimiento y velocidad, acelera tu sitio WordPressLibreCon
Que un sitio web cargue rápido es algo muy importante cuando desarrollamos un sitio web. Tanto de cara ahorrar costes de infraestructura como para mejorar al máximo la experiencia de usuario, debemos optimizar al máximo nuestro sitio web. Explicación cómo de una manera sencilla y rápida podemos optimizar nuestros sitios desarrollados en WordPress para así conseguir un tiempo de carga y peso de las páginas menores. Autor: Dani Reguera (Profesor e investigador en Mondragon Unibertsitatea). Librecon.io
Escalabilidad y alto rendimiento con Symfony2Ricard Clau
En esta charla se pretenden tocar todas las cosas que debemos tener en cuenta para sacar el máximo rendimiento y poder escalar usando Symfony2.
Se toca desde parámetros de configuración de PHP y APC, optimización de Composer, dónde optimizar, quick wins varios, cómo hacer profiling correctamente, BBDD NoSQL vs SQL y por supuesto lecciones aprendidas en mis anteriores trabajos
Casper JS - Asegurando la calidad en front-end DrupalDavid Gil Sánchez
En esta sesión presentaremos como estamos utilizando CasperJS (http://casperjs.org/) para asegurar la calidad de algunos de nuestros desarrollos y evitar los tan temidos (y comunes) bugs de regresión.
Mostraremos el uso básico de CasperJS y veremos un caso real en el que estamos testando la lógica principal de un portal con procesos complejos que involucran submits de formularios multipaso, testeo con multiples roles, etc...
Aplicaciones web altamente escalables con RedisAlberto Gimeno
Este documento resume las características y usos de Redis, una base de datos clave-valor muy rápida que soporta datos estructurados. Redis puede escalar horizontalmente mediante particionamiento de datos en varios nodos y replicación de lecturas. Se recomienda usar Redis como caché, base de datos auxiliar o principal cuando se requiera alta velocidad de consulta. Redis ofrece tipos de datos como hashes, listas y conjuntos que facilitan el modelado y consulta de datos complejos de forma eficiente.
Es decir, que las web que cumplan los estándares se vean bien en todos los navegadores actuales.
Me gustan que sean fáciles de mantener y de actualizar, que tengan una consistencia visual entre navegadores.
Me gusta que sean fácilmente accesibles.
Y por pedir… me gusta que sean rápidas, que se posicionen bien en los motores de búsqueda, buen UX, que consuman poco ancho de banda, que sean eficientes, hacerlas con menos esfuerzo y poder visitarlas desde cualquier dispositivo.
La mayoría de las web a las que accedemos no respetan los estándares de la W3C, pero estamos viviendo un cambio y deberíamos encaminarnos a crear páginas bien hechas.
Veremos cuáles son los estándares actuales, como actualizar un sitio web para que utilice los estándares sobre los que se basan la mayoría de los navegadores modernos y en qué me beneficia que mi web los siga.
En resumen: buenas prácticas, qué funciona y las mejores herramientas para llevar a cabo todo esto.
El documento presenta una introducción al Behavior Driven Development (BDD) y su herramienta Cucumber. Explica que BDD se centra en el comportamiento del software desde la perspectiva del cliente, mientras que el Test Driven Development (TDD) se centra en la implementación. También describe cómo Cucumber permite definir casos de prueba en un lenguaje de dominio específico (Gherkin) que es legible para los negocios. Finalmente, proporciona algunos consejos prácticos para empezar con BDD y Cucumber.
Observabilidad: Todo lo que hay que verSoftware Guru
El código que hacemos vive y tiene razón de ser al momento de llegar a producción… ¿Cómo sabemos que tan efectivo es ? Solo podemos saber midiendolo.
Presentada por Isaac Ruiz Guerra en SG Virtual Conference 2020
Tras muchos años asumiendo problemas ajenos como míos siendo empleado decidí crear una empresa que se dedicara a ello.
A lo largo de mi carrera he visto (y perpetrado) cosas que no creeríais pero, al final, la realidad es que la mayoría de empresas tienen problemas muy similares y se suelen cometen errores muy parecidos en todas partes, independientemente del sector, tamaño o perfiles de los equipos.
En esta charla nos centraremos en los errores más comunes que se cometen al implantar metodologías DevOps y cómo intentar evitarlos. Porque DevOps no es un puesto, ni un equipo, ni un proyecto, ni algo que se pueda comprar e instalar.
Porque no necesitas ser una FAANG para aprovecharte de las muchas cosas positivas de estas filosofías. Y incluso en las FAANG reconocen haber cometido muchos de estos errores.
El documento proporciona 9 claves y una clave adicional para la optimización de rendimiento web (WPO) para proyectos de comercio electrónico basados en Magento. Las claves incluyen mantenerse actualizado con las últimas versiones de Magento, eliminar elementos no utilizados, optimizar el tamaño de los archivos, habilitar varios cachés, optimizar la base de datos MySQL, aprovechar servicios de terceros como CDN y asegurarse de usar hosting adecuado. El documento también discute consideraciones adicionales
Comunicacion en equipos tecnicos, por javier ramirez, teowakijavier ramirez
Cómo tratar con tus compañeros sin que te den ganas de matar explica algunas técnicas para mejorar la comunicación en tu equipo de trabajo y para generar un clima de confianza, respeto, y buen rollo. Además explica cómo algunas empresas de tecnología entienden sus equipos de desarrollo
Comunicacion en equipos tecnicos, teowaki, javier ramirezjavier ramirez
"Comunicacion en equipos técnicos, o cómo tratar con tus colegas sin que te den ganas de matar" is a talk I prepared for the DevOps meetup in Madrid.
I explain the challenges of communications in technical teams, how companies like Netflix, Google, Valve, Basecamp or Auttomatic organise their teams, and I provide tips of the techniques I have been applying in my teams through the years.
Lo que nadie te ha contado del Black Hat SEO - ChuisoBlackHatSpain
Este documento discute las técnicas de Black Hat SEO, incluyendo el uso de programas para generar automáticamente enlaces, la replicación de enlaces de la competencia, y el uso de redirecciones para transferir autoridad de dominio. También sugiere que estas técnicas siguen siendo efectivas a pesar de las penalizaciones de Google, pero recomienda enfocarse en técnicas más sutiles como la detección de huellas digitales en CMS y la automatización de procesos de link building.
Este documento describe la experiencia de crear la plataforma de comercio electrónico más grande de Latinoamérica utilizando Grails. Explica por qué se eligió Grails, incluyendo su productividad, comunidad y similitud con Ruby on Rails. Detalla el negocio, diseño inicial, infraestructura, problemas encontrados y futuro de la plataforma. La plataforma ha crecido a más de 2 millones de usuarios utilizando Grails, Terracotta, RabbitMQ y MySQL para lograr escalabilidad y disponibilidad.
Este documento presenta SymfonyZero, un proyecto de inicio gratuito para proyectos Symfony que incluye bundles configurados y funcionalidades comunes para agilizar el desarrollo. También presenta SymfonyZero-API, orientado a proyectos que usen Symfony como API REST. Ambos incluyen características como gestión de usuarios, panel de administración y documentación para facilitar el desarrollo rápido de proyectos Symfony.
Xamarin permite el desarrollo multiplataforma para Android e iOS usando C# y .NET. Permite la reutilización de código entre plataformas y la reducción de costes de mantenimiento. Es adecuado cuando gran parte de la lógica de la aplicación es independiente de la plataforma. Requiere cambiar la forma de trabajar y coordinar equipos para aprovechar sus ventajas.
Este documento describe la plataforma TIMEREPUBLIK, un servicio en línea que permite a los usuarios ganar y gastar tiempo en lugar de dinero. Explica que la plataforma está programada en Ruby on Rails y opera en más de 100 países con 50,000 servicios. También presenta a los tres desarrolladores principales detrás de la compañía y sus antecedentes técnicos.
Presentación RodrigoPolo.com @ Barcamp Guatemala '09Rodrigo Polo
Este documento ofrece una guía sobre estándares web y optimización de sitios. Explica que los estándares como UTF-8, XHTML y CSS separan el contenido del diseño y hacen que los sitios sean más indexables para los buscadores. Sin embargo, a veces la prioridad debe ser la comunicación sobre la adherencia estricta a los estándares. El documento luego proporciona consejos para optimizar sitios web mediante la reducción de solicitudes de red, minificación de archivos, uso limitado de marcos y compresión de contenido.
Presentación de la charla impartida en el meetup de Python Madrid sobre Asincronía en Python https://www.meetup.com/es-ES/python-madrid/events/268111847/
Extendiendo Django: Cómo Escribir Tu Propio Backend de Base de Datos - ExasolJavier Abadía
Django permite acceder – mediante su ORM – a distintas bases de datos. De serie, Django soporta PostgreSQL, MySQL, SQLite, Oracle y existen “backends” (es decir drivers) no oficiales para IBM DB2, Microsoft SQL Server , Firebird y bases de datos ODBC.
Pero... ¿qué pasa si nuestros datos están en una base de datos para la que no existe – todavía – un backend? ¿cómo de fácil o difícil es escribir nuestro propio backend para esa base de datos?
En esta charla compartiremos nuestra experiencia escribiendo un backend para una base de datos analítica (EXASol DB): ¿cómo lo hemos hecho? ¿qué documentación o referencias hay disponibles? ¿cómo nos aseguramos de que el acceso a los datos es correcto?
Más contenido relacionado
Similar a Las reglas que hay que romper para que tu equipo de desarrollo sea el más RÁPIDO
Casper JS - Asegurando la calidad en front-end DrupalDavid Gil Sánchez
En esta sesión presentaremos como estamos utilizando CasperJS (http://casperjs.org/) para asegurar la calidad de algunos de nuestros desarrollos y evitar los tan temidos (y comunes) bugs de regresión.
Mostraremos el uso básico de CasperJS y veremos un caso real en el que estamos testando la lógica principal de un portal con procesos complejos que involucran submits de formularios multipaso, testeo con multiples roles, etc...
Aplicaciones web altamente escalables con RedisAlberto Gimeno
Este documento resume las características y usos de Redis, una base de datos clave-valor muy rápida que soporta datos estructurados. Redis puede escalar horizontalmente mediante particionamiento de datos en varios nodos y replicación de lecturas. Se recomienda usar Redis como caché, base de datos auxiliar o principal cuando se requiera alta velocidad de consulta. Redis ofrece tipos de datos como hashes, listas y conjuntos que facilitan el modelado y consulta de datos complejos de forma eficiente.
Es decir, que las web que cumplan los estándares se vean bien en todos los navegadores actuales.
Me gustan que sean fáciles de mantener y de actualizar, que tengan una consistencia visual entre navegadores.
Me gusta que sean fácilmente accesibles.
Y por pedir… me gusta que sean rápidas, que se posicionen bien en los motores de búsqueda, buen UX, que consuman poco ancho de banda, que sean eficientes, hacerlas con menos esfuerzo y poder visitarlas desde cualquier dispositivo.
La mayoría de las web a las que accedemos no respetan los estándares de la W3C, pero estamos viviendo un cambio y deberíamos encaminarnos a crear páginas bien hechas.
Veremos cuáles son los estándares actuales, como actualizar un sitio web para que utilice los estándares sobre los que se basan la mayoría de los navegadores modernos y en qué me beneficia que mi web los siga.
En resumen: buenas prácticas, qué funciona y las mejores herramientas para llevar a cabo todo esto.
El documento presenta una introducción al Behavior Driven Development (BDD) y su herramienta Cucumber. Explica que BDD se centra en el comportamiento del software desde la perspectiva del cliente, mientras que el Test Driven Development (TDD) se centra en la implementación. También describe cómo Cucumber permite definir casos de prueba en un lenguaje de dominio específico (Gherkin) que es legible para los negocios. Finalmente, proporciona algunos consejos prácticos para empezar con BDD y Cucumber.
Observabilidad: Todo lo que hay que verSoftware Guru
El código que hacemos vive y tiene razón de ser al momento de llegar a producción… ¿Cómo sabemos que tan efectivo es ? Solo podemos saber midiendolo.
Presentada por Isaac Ruiz Guerra en SG Virtual Conference 2020
Tras muchos años asumiendo problemas ajenos como míos siendo empleado decidí crear una empresa que se dedicara a ello.
A lo largo de mi carrera he visto (y perpetrado) cosas que no creeríais pero, al final, la realidad es que la mayoría de empresas tienen problemas muy similares y se suelen cometen errores muy parecidos en todas partes, independientemente del sector, tamaño o perfiles de los equipos.
En esta charla nos centraremos en los errores más comunes que se cometen al implantar metodologías DevOps y cómo intentar evitarlos. Porque DevOps no es un puesto, ni un equipo, ni un proyecto, ni algo que se pueda comprar e instalar.
Porque no necesitas ser una FAANG para aprovecharte de las muchas cosas positivas de estas filosofías. Y incluso en las FAANG reconocen haber cometido muchos de estos errores.
El documento proporciona 9 claves y una clave adicional para la optimización de rendimiento web (WPO) para proyectos de comercio electrónico basados en Magento. Las claves incluyen mantenerse actualizado con las últimas versiones de Magento, eliminar elementos no utilizados, optimizar el tamaño de los archivos, habilitar varios cachés, optimizar la base de datos MySQL, aprovechar servicios de terceros como CDN y asegurarse de usar hosting adecuado. El documento también discute consideraciones adicionales
Comunicacion en equipos tecnicos, por javier ramirez, teowakijavier ramirez
Cómo tratar con tus compañeros sin que te den ganas de matar explica algunas técnicas para mejorar la comunicación en tu equipo de trabajo y para generar un clima de confianza, respeto, y buen rollo. Además explica cómo algunas empresas de tecnología entienden sus equipos de desarrollo
Comunicacion en equipos tecnicos, teowaki, javier ramirezjavier ramirez
"Comunicacion en equipos técnicos, o cómo tratar con tus colegas sin que te den ganas de matar" is a talk I prepared for the DevOps meetup in Madrid.
I explain the challenges of communications in technical teams, how companies like Netflix, Google, Valve, Basecamp or Auttomatic organise their teams, and I provide tips of the techniques I have been applying in my teams through the years.
Lo que nadie te ha contado del Black Hat SEO - ChuisoBlackHatSpain
Este documento discute las técnicas de Black Hat SEO, incluyendo el uso de programas para generar automáticamente enlaces, la replicación de enlaces de la competencia, y el uso de redirecciones para transferir autoridad de dominio. También sugiere que estas técnicas siguen siendo efectivas a pesar de las penalizaciones de Google, pero recomienda enfocarse en técnicas más sutiles como la detección de huellas digitales en CMS y la automatización de procesos de link building.
Este documento describe la experiencia de crear la plataforma de comercio electrónico más grande de Latinoamérica utilizando Grails. Explica por qué se eligió Grails, incluyendo su productividad, comunidad y similitud con Ruby on Rails. Detalla el negocio, diseño inicial, infraestructura, problemas encontrados y futuro de la plataforma. La plataforma ha crecido a más de 2 millones de usuarios utilizando Grails, Terracotta, RabbitMQ y MySQL para lograr escalabilidad y disponibilidad.
Este documento presenta SymfonyZero, un proyecto de inicio gratuito para proyectos Symfony que incluye bundles configurados y funcionalidades comunes para agilizar el desarrollo. También presenta SymfonyZero-API, orientado a proyectos que usen Symfony como API REST. Ambos incluyen características como gestión de usuarios, panel de administración y documentación para facilitar el desarrollo rápido de proyectos Symfony.
Xamarin permite el desarrollo multiplataforma para Android e iOS usando C# y .NET. Permite la reutilización de código entre plataformas y la reducción de costes de mantenimiento. Es adecuado cuando gran parte de la lógica de la aplicación es independiente de la plataforma. Requiere cambiar la forma de trabajar y coordinar equipos para aprovechar sus ventajas.
Este documento describe la plataforma TIMEREPUBLIK, un servicio en línea que permite a los usuarios ganar y gastar tiempo en lugar de dinero. Explica que la plataforma está programada en Ruby on Rails y opera en más de 100 países con 50,000 servicios. También presenta a los tres desarrolladores principales detrás de la compañía y sus antecedentes técnicos.
Presentación RodrigoPolo.com @ Barcamp Guatemala '09Rodrigo Polo
Este documento ofrece una guía sobre estándares web y optimización de sitios. Explica que los estándares como UTF-8, XHTML y CSS separan el contenido del diseño y hacen que los sitios sean más indexables para los buscadores. Sin embargo, a veces la prioridad debe ser la comunicación sobre la adherencia estricta a los estándares. El documento luego proporciona consejos para optimizar sitios web mediante la reducción de solicitudes de red, minificación de archivos, uso limitado de marcos y compresión de contenido.
Similar a Las reglas que hay que romper para que tu equipo de desarrollo sea el más RÁPIDO (20)
Presentación de la charla impartida en el meetup de Python Madrid sobre Asincronía en Python https://www.meetup.com/es-ES/python-madrid/events/268111847/
Extendiendo Django: Cómo Escribir Tu Propio Backend de Base de Datos - ExasolJavier Abadía
Django permite acceder – mediante su ORM – a distintas bases de datos. De serie, Django soporta PostgreSQL, MySQL, SQLite, Oracle y existen “backends” (es decir drivers) no oficiales para IBM DB2, Microsoft SQL Server , Firebird y bases de datos ODBC.
Pero... ¿qué pasa si nuestros datos están en una base de datos para la que no existe – todavía – un backend? ¿cómo de fácil o difícil es escribir nuestro propio backend para esa base de datos?
En esta charla compartiremos nuestra experiencia escribiendo un backend para una base de datos analítica (EXASol DB): ¿cómo lo hemos hecho? ¿qué documentación o referencias hay disponibles? ¿cómo nos aseguramos de que el acceso a los datos es correcto?
El documento presenta una charla sobre UX/UI para desarrolladores. Explica conceptos clave como affordances, gestalt, grids, colores, tipografía y heurísticas de diseño. También advierte sobre posibles errores como ignorar el modelo mental del usuario, usar vocabulario técnico o hacer interfaces poco amigables.
Slides for my talk in FrontFest 2018 (Madrid, Feb 17). It's a technical comparison of the change detection mechanism as implemented in AngularJS, React, Angular2 and VueJS
See demos at https://github.com/jabadia/frontfest-frameworks-demos
Solución a 4 retos de programación de Advent of Code y Google Code Jam para ilustrar construcciones pythónicas de código y algunas utilidades poco conocidas del lenguaje.
Django + Vue, JavaScript de 3ª generación para modernizar DjangoJavier Abadía
Slides de la charla que di en la PyConEs 2017 en Cáceres, el 24 de Septiembre.
Explicaba cómo montar un entorno de desarrollo ágil con Django en el back, Vue en el front y webpack para empaquetar el front y proporcionar Hot Module Reloading
Vue.js + Django - configuración para desarrollo con webpack y HMRJavier Abadía
Presentación del meetup de Vue.js en Madrid, el 12/Sep/2017 donde explicamos cómo configurar Django y webpack para desarrollar SPAs con Vue.js y backend con Django: incluye configuración de Hot-Module-Reloading, autenticación, API y rutas.
El código de ejemplo se puede encontrar aquí: https://github.com/jabadia/gif_catalog
Anatomía de un Bot para Resultados ElectoralesJavier Abadía
Este documento describe cómo crear un bot de resultados electorales en Node.js. Explica la anatomía de un bot, incluyendo entender el lenguaje natural, procesar la intención del usuario, y responder. Luego discute opciones para la plataforma como Twitter, y desafíos como cuotas de tweets y usuarios impacientes. Finalmente, proporciona recursos para el procesamiento de lenguaje natural, bots, y módulos de Node.js.
La charla que dí en Codemotion 2015 sobre cómo resolver la noche electoral con AWS, Node.js, Angular.js, D3.js y Leaflet.js (http://2015.codemotion.es/agenda.html#5699289732874240/50504006)
Buscador de Eventos y Fiestas en España - Buscafiestaholabuscafiesta
Buscafiesta.es es el buscador líder en España para fiestas y eventos, diseñado para satisfacer las necesidades tanto de organizadores como de asistentes. Este innovador software ofrece una plataforma integral que permite a los organizadores de eventos añadir, gestionar y promocionar sus actividades de manera totalmente autónoma, facilitando la visibilidad y escalabilidad de sus eventos.
Buscafiesta.es no solo conecta a los organizadores con su público objetivo, sino que también ofrece herramientas de marketing y análisis que ayudan a maximizar el impacto de cada evento. Ya sea para una fiesta local, un concierto multitudinario o un evento corporativo, Buscafiesta.es es la solución definitiva para hacer de cada evento un éxito rotundo.
PC-04-DISEÑOS DE PITS Y STOPES DE UNA MINA A TAJO ABIERTO.pdf
Las reglas que hay que romper para que tu equipo de desarrollo sea el más RÁPIDO
1. Las reglas que hay que romper
para que tu equipo de
desarrollo sea el más
RÁPIDO
o cómo se gana el sueldo un CTO*
*si, es Comic Sans MS@javierabadia
2017
2.
3.
4. CORRIENDO,
TE
CANSAS
SOLO NECESITAS
UNAS ZAPATILLAS.
PUNTO.
LAS DEL DECATHLÓN
ESTÁN BIEN
AUNQUE TE
COMPRES LAS
ZAPATILLAS DE 180€
TE VAS A CANSAR
IGUAL
PARA HIDRATARSE,
LO MEJOR ES EL
AGUA
LOS GRANDES
ATLETAS CORREN
MUCHO, PORQUE
ENTRENAN MUCHO
PARA PREPARAR UN
MARATÓN, HAY QUE
SALIR A CORRER.
Y TE VAS A CANSAR
23. DRY - código reusable
• no a la primera
• no a la segunda
• tal vez a la tercera
24. DRY - código reusable
• no a la primera
• no a la segunda
• tal vez a la tercera
• copy & paste de código = bueno
• pero SI: single-concern, loose coupling
• DRY: cada decisión en un solo sitio
26. principios de la deuda técnica
• es necesaria y sana si se hace a sabiendas
• demasiada te puede hundir
• no ponerse en modo hackathón
• el que la hace, la paga
28. testing automático
• ¿100% de cobertura?
• ¿qué tipo de errores se cazan con unit-testing?
• ¿tiene sentido hacer test automáticos para validar el HTML?
29. testing “a secas”
• es necesario PROBAR
• antes de cada despliegue
• es necesario VALIDAR
• muy probablemente no es necesario ni efectivo
AUTOMATIZAR los TEST
• mini-post-portems: cada vez que falle algo, preguntarse:
¿cómo podríamos haberlo evitado? (que sea ‘realizable’)
35. time-suckers
• diferencias entre entornos
• en mi máquina funciona
• “ensalada de settings”
• administración de servidores
• disco lleno en el peor momento
• seguridad
• dependencias
36. más time-suckers
• integraciones fallidas
• merges con ansiedad
• despliegues fallidos
• errores manuales = no automático
• se rompe algo al cambiar el esquema de bbdd
• (no usáis migraciones?)
• se rompe algo al cambiar las dependencias
• la Puesta en Producción vs la puesta en producción
37. time-suckers de otro tipo
• información no compartida
• debates filosóficos interminables
41. no vale con saberse los
comandos
y no es necesario sabérselos
42. entendiendo git
• repo
• colección de commits
(identificados por su SHA1)
• commit
• cada commit sabe quien es su padre
• un commit es un delta NO una foto
• rama
• rama = una etiqueta que apunta a un commit
• un commit puede tener dos (o más) hijos
• merge
• crear un nuevo commit con dos (o más) padres
• combinar los cambios que vienen de 2 ramas
https://marklodato.github.io/visual-git-guide/index-en.html
43. usando git
• las ramas
• usar muchas ramas
(son gratis)
• de vida corta
• sin miedo a los merges
• los commits
• prohibido “git add .”
• ‘manufacturar’ los commits
• recomendable
• pull requests
• code review
• oh shit git
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
¿cuántos de aquí sois responsables de un equipo de desarrollo?
Bueno, pues vosotros ya habéis pasado por el momento "Frodo"... y el resto, algún día os tocará... ¿Qué es el momento "Frodo"? Pues llega alguien, te da un anillo y te dice... hala majete, ves allí el monte del destino? Pues tienes que llegar allí y destruirlo.
Así que con un poco de suerte te buscas un equipo de confianza (o te lo asignan) y te pones a pensar cual es la mejor forma de cumplir tu misión. ¿Qué hago? ¿Busco un mapa? ¿Busco ayuda? ¿Empiezo a andar?... ¿Qué haría Frodo?...
nos han encomendado una misión
y queremos hacerlo bien
para ser más cool, buscamos en inglés
nos han encomendado una misión
y queremos hacerlo bien
para ser más cool, buscamos en inglés
internet es como el quiosco, que hay de todo.
me dedico al mundo de la moda, me fijo más en las revistas del sector...
y siempre hablan de lo mismo... qué se va a llevar el mes que viene, cómo hacer dieta y que hay que hacer para estar mas sexy.
Si nos salimos del sector y vamos a las revistas de running... también acaban hablando de lo mismo, de cómo hacer dieta.
También hay portadas con chicos… hablan de lo mismo.
las revistas de running... también acaban hablando de lo mismo, de cómo hacer dieta.
pero… os imagináis que tuvieran estos titulares?
…
¿Qué pondrían el segundo mes?
La realidad no es glamourosa, y por eso nadie hace revistas ni artículos ni tweets
Pues de eso va esta charla...
de los consejos que se escuchan por ahí para desarrollar software y que en mi opinión no ayudan a ir más deprisa,
y de las cosas que nadie dice, porque no son glamurosas o nos da vergüenza reconocer
porque nos han convencido, y encima nos sentimos culpables
Si resumieramos lo que vemos en internet sobre el desarrollo de software en una portada de revista, sería algo así.
…
¿y no hablamos de hacer dieta? si, es esto de los microservicios!!
Muchas buenas prácticas "de salón" pero que muchas veces están escritas por blogueros profesionales y gente que se dedica a escribir tutoriales... pero que han escrito menos código de producción que el director de desarrollo de una consultora
Y ¿qué pasa con el código de producción? QUE ES FEO. Que nadie tuitea sobre el "if" horrible que ha tenido que poner en una función para controlar un error que aparecía a los usuarios los martes por la tarde, porque no tiene glamour.
¿por qué es importante?
velocidad hackatón
calidad hackathón
si quieres ir rápido ve solo, si quieres llegar lejos, ve con toda la tribu
con recursos suficientes y siguiendo todos los manuales y
cumpliendo todas las normas de seguridad.
buena forma = tienes los recursos suficientes y sabes con exactitud por donde tienes que pasar y a dónde tienes que llegar
En los proyectos interesantes, no sabemos a dónde tenemos que llegar ni por dónde tenemos que pasar...
Nadie ha ido antes.
Llegar ántes de que se acaben los recursos.
Dia a día de startups y proyectos que no son startups.
Nosotros en StyleSage llevamos 2 años y medio en este modo: eramos 4 y ahora somos 19.
¿y como lo hemos conseguido?
Microservicios!
¡¡¡NI DE COÑA!!!
No echarnos más trabajo encima. A la larga puede ser la solución óptima. Al principio ni de coña.
necesitas devops
Entonces... hacemos un monolito infumable?
no, monolito si, porque es lo más simple, pero no infumable:
bien organizado, bien separado código muy cohesivo y con poco acoplamiento para que las partes diferenciadas que vayan emergiendo se puedan ir separando.
nos evitamos la carga de trabajo de DevOps inicial y nos preparamos el terreno para trocearlo cuando sea necesario
[12:28]
entonces, en serio
lo primero es saber a donde quieres ir
por que si no, confundimos movimento con avance...
trabajamos mucho, nunca llegamos a nada.
avance = aportar valor a nuestro usuario a través de nuestro producto.
un mes a refactorizar una aplicación = nos hemos movido mucho pero no hemos avanzado nada.
dice hacia donde vamos
pero dice lo que NO hay que hacer.
se pasa el día apuntando buenas ideas y diciendo que no
su trabajo es hacer un road-map:
documento de word
en project, como las empresas grandes
en trello, como las startups hipsters
con post-its , como las empresas ágiles
hablando de agilidad,
lo fundamental es meter al usuario en el bucle, es la única forma de saber si el movimiento es avance
ENTREGAR la funcionalidad lo antes posible y
VALIDAR que lo que hemos hecho es lo que realmente hacía falta.
agilismo = se centra en toda la ceremonia de los post-its, los sprints, los scrum masters... y se olvida de que al final de cada sprint hay que pasar por el usuario!
¿cuantos proyectos hacen sprints sin entregar nada?
te crees que estás siendo muy ágil y solo te estás engañando a ti mismo
[12:29]
solo podemos ir rápido si vamos en la dirección correcta.
Pero aun así… por el camino nos vamos a encontrar miles de distracciones que nos pueden hacer ir más lentos
es lo que yo llamo el 'meta-trabajo', son tareas que nos inventamos nosotros mismos bajo la excusa de las buenas prácticas de ingeniería y que en el fondo no aportan valor al usuario a través del producto
el efecto ‘ballesta’ por ‘miguel angel ballesta’
los desarrolladores somos expertos en cambiar la definición de nuestro trabajo para hacerlo más molón:
ballesta, nueva vista, generador de código para crear vistas: 30 min -> 3 días y además no ha creado la vista
muy preocupante: foco del usuario a la ingeniería: cambiamos el trabajo de aportar valor al usuario a través del producto a hacer un generador de código
síntoma = product manager y CTO no están haciendo bien su trabajo, no están insertando en el cerebro de los desarrolladores la alergia a las pamplinas.
Los desarrolladores son 'caballos de carreras', y tienen que correr. Si no les pones objetivos claros, se ponen a correr en la dirección equivocada. Cuando alguien no sabe qué hacer, hace lo que sabe... programar. Y nos movemos mucho y avanzamos poco.
otro ejemplo de esto son las capas de abstracción:
capa genérica para acceder a base de datos para poder cambiar el gestor cuando queramos,
un sistema de plugins, y así cualquier cosa que queramos hacer la podemos hacer con un plugin,
un editor de layouts...
y es la versión moderna del código espagetthi que es el código lasaña, con demasiadas capas de abstracción... Roberto Waltman
auténticos astronautas de la abstracción que se niegan a resolver problemas concretos... siempre buscan la generalización, la abstracción... ya llegará el momento de abstraer problemas, pero todavía no
si alguien propone alguna de estas cosas, dadle una colleja y que se quede mirando al roadmap
todos tenemos preferencias: un profesional se tiene que adaptar
tenemos distintos estilos de código - los respetamos - 1 cambio de 1 línea no tiene que generar un diff de 200
te aguantas
trabajo del CTO
sobre la estructura del código...
siempre hay alguien que quiere definirla antes de empezar... lo malo es que demasiadas reglas, limitan la velocidad
esperar a ver por donde crece, y definir a posteriori una estructura
tu pintas los caminos, y luego la realidad te demuestra por dónde pasa la gente
espera a ver por dónde te crece el código y define la estructura a posteriori… las reglas prematuras te limitan la velocidad
Todos hemos leido DRY - Don't Repeat Yourself, y nos han inculcado que hay que evitar duplicidades a toda cosa
así que cuando estamos desarrollando y tenemos la sensación de que este código se va a necesitar en más sitios, aparece “ballesta” y te dice
hazlo reusable
el código reusable es muy difícil de escribir bien,
¿qué es genérico y qué es específico de cada caso?
a la primera no, no merece la pena
a la segunda vez, ya ha pasado el tiempo y lo que necesitas ahora no es exactamente lo que tienes. Peligro de romper algo.
a la tercera, no es que vaya a ser más fácil, pero hay justificación para dedicar el tiempo y esfuerzo necesarios para hacer el código bien y probar exhaustivamente los 3 sitios donde lo usas
así que mientras tanto, el copy & paste es buenísimo...
lo importante es que el código que escribamos esté bien organizado con single-concern y loose coupling,
para que cuando llegue el momento de refactorizarlo (si es que llega) la operación sea sencilla.
Y marcar el código duplicado con referencias cruzadas.
¿Y que hay del DRY? en realidad es otra cosa… lo que me dice es que cada decisión debe reflejarse en un solo sitio del código
esto del copy&paste es un ejemplo de Deuda Técnica
es sana ¿tenéis hipoteca?
mientras sea manejable
no ponerse en modo hackathón, no es sostenible
no puede ser que unos hagan ñapas y otros vengan detrás limpando la mierda... eso no es deuda técnica, eso es 'machismo' de código
sobre la documentación... hay que documentarlo todo, no hay que documentar nada...
yo creo que lo que no está escrito, se olvida, pero por otro lado, no hay que escribir las cosas más de una vez
el peor documento es el que no lee nadie
el peor documento es el que cuando alguien lo lee está desactualizado
mantener las cosas juntas, con referencias
lo de la documentación automática es otro ejemplo perfecto del efecto “ballesta”
los desarrolladores tenemos un autocorrector en el cerebro, que cuando oimos la palabra testing, inmediatamente le añadimos automático después…
no nos cabe en la cabeza que las aplicaciones se pueden probar de otra forma… ¡probándolas!
tiene sentido: si, pero acotado, y es una solución parcial al problema de la calidad
¿cuántas aplicaciones han fallado en producción y tenían 100% de cobertura y todos los tests pasando en verde?
¡porque siempre falla otra cosa!
¿qué tipo de errores se cazan con unit-testing?
¿tiene sentido hacer test automáticos para validar el HTML?
TDD: mola como filosofía, pero no para front-end
es necesario PROBAR
antes de cada despliegue
es necesario VALIDAR
no es necesario AUTOMATIZAR los TEST: puede ser cómodo, divertido, útil… pero no es necesario
con cada cagada, pensar qué test te hubiera evitado cometerla
cada vez que falle algo, preguntarse: ¿cómo podríamos haberlo evitado? (que sea ‘realizable’)
sin tests, puedes sobrevivir durante un tiempo… como estos 3 lumbreras
todas estas cosas tienen en común:
redefinen el trabajo
es hacer algo para nosotros
en lugar de hacer algo para el usuario
MUY peligroso
[12:39]
sabemos a donde vamos
no nos distraemos con pamplinas
y aún así, hay semanas en las que se tuerce todo y nos vamos a casa con la lista de tareas sin tocar: se nos ha caido el servidor, se nos ha llenado el disco duro, nos ha fallado una integración y nos hemos pasado dos/tres días limpiando la mierda…
y eso pasa porque a veces nos afanamos en resolver los síntomas, en lugar de atajar las causas de raíz de los time-suckers
si detectáis alguno de estos problemas, no tenéis nada más prioritario que resolverlo: es como atarse los cordones
por ejemplo
aun así, movidas vas a tener, si no querías movidas, no haberte dedicado a la informática
prepárate para que no sean catastróficas: backups, servidores virtuales, repositorios… lo de siempre
ser estrictos con que los entornos sean lo más parecidos posibles pro/pre/dev
resolverlos solo cuando sean time-suckers, no ponernos a containerizar en docker solo porque es divertido…
a lo mejor la solución es contratar un devops
aquí la solución es mejorar el proceso de integración y despliegue contínuo… cada vez más…
viene ballesta y dice “un jenkins”
no es necesario un jenkins… es necesario
automatizar el despliegue (un simple script de bash)
usar migraciones
gestionar las dependencias
hacer despliegues frecuentes
transparencia
respeto mutuo y autoridad del CTO
[12:43]
supongamos que sabemos a donde vamos
que no nos dejamos distraer con las “buenas prácticas”
y que hemos tapado los agujeros del barco
¿qué más nos podría ralentizar?
nada mas triste que dos personas arreglando lo mismo sin saberlo
o alguien resolviendo algo que no tiene sentido, por no saber de donde viene
código
documentos
todo…
integrar código que está a medias
lastre = código no integrado
simplifica muchísimas cosas
y la puesta en producción es facilísima
[12:47]
acabar
terminar
finalizar
completar
dar carpetazo
cerrar
lastre = código que no está en producción = trabajo que no ha aportado ningún valor
desarrollas una feature super urgente en 2 semanas
y se pasa otras dos semanas en “pre-producción” hasta que alguien da el OK definitivo
NEGARSE a resolver ”issues” con cuentagotas
nada iguala a un google spreadsheet compartido
son sagrados
se negocian con negocio: si fijas el alcance yo pongo la fecha
si pones la fecha, yo decido el alcance
acostumbrar a negocio a que siempre cumplimos con las fechas
relación de confianza
[12:50]
¿cuántos hay que tener de cada?
NINGUNO
todos tienen que ser desarrolladores
y todos tienen que tener al usuario presente todos los días
todos tienen que venir a trabajar con el cerebro de pensar activado
ownership, authority, empowerment
nadie ‘aprueba’ la especificación,
nadie va a revisar tu trabajo… tú eres el responsable de hacerlo bien (anécdota de HP)
ojo, que las ”code reviews” son otra cosa
nadie tiene las respuestas, ni la verdad absoluta
PIENSA
dale toda la información a tu equipo para que puedan pensar
todos deben contribuir
todos deben opinar
todos deben tener toda la información para contribuir positivamente
es obligación del CTO tomar las decisiones
y hacerse responsable
los errores individuales ocurren
el equipo debe mejorar para que no tengan consecuencias
yo te digo a dónde hay que llegar
es cosa tuya buscar la mejor manera de llegar
no hay nada que motive más a un desarrollador que sentirse productivo
trabajar en un equipo así motiva
los desarrolladores son caballos de carreras
si corren están contentos
charlas internas
rienda suelta
caballos de carreras
útil, enfocado, con objetivos tangibles
déjale a ballesta que juegue, pero con algo útil
rienda suelta
caballos de carreras
útil, enfocado, con objetivos tangibles
trabajar menos horas nos hace ir más rápido
[12:55]
esta diapo para acabar, no mola
no son reglas, ni un decálogo
somos personas
para ir rápido las cosas importantes no son las que tienen que ver con el código
son las que tienen que ver con el usuario (para saber hacia donde vamos, qué hacer y qué no hacer)
y las que tienen que ver con el equipo (para, que si sabemos a donde vamos, vayamos todos juntos y bien coordinados)