Categoría: prácticas
Por John Walk
Si no tienes cuidado, tu entorno de Python puede convertirse rápidamente en un desastre. Recorreremos las herramientas disponibles para ser más (código) respetuosos con el medio ambiente y establecer algunas preferencias (muy opinadas) para la creación de Python.
Por AJ Foster
Una vez que una organización decide introducir una nueva tecnología en su ecosistema, la adopción puede ser tumultuosa. Veamos la introducción del lenguaje de programación Elixir en y observemos los obstáculos potenciales. Podemos hacer una conjetura educada sobre cómo abordar estos temas de frente.
Por Jim Cooper
Valoramos los equipos responsables y autónomos, y diseñamos nuestros sistemas con ese fin. Estas son las prácticas que hemos elegido para hacerlo posible.
Por Levi Thatcher
La solución de MVP para escalar la experimentación de nuestro producto.
Por Parker Johansen
El aprendizaje es algo muy personal. Aprender un idioma lo es aún más. En este post, discuto mi enfoque para aprender nuevos lenguajes de programación, con la esperanza de que usted pueda encontrar su propio camino para aprender nuevos lenguajes.
Por Jim Cooper
En el valor de la creación de nuestro producto en colaboración. Aquí están las prácticas que hemos elegido para apoyar ese principio.
Por Jim Cooper
En que valoramos continuamente la entrega de valor a la producción. Aquí están las prácticas que hemos elegido para apoyar ese principio.
Por Levi Thatcher
Escuchar a los usuarios requiere la recopilación de datos tanto cualitativos como cuantitativos. Veamos cómo pensamos en mezclar lo cualitativo y lo cuantitativo y qué es lo que ha obstaculizado nuestros esfuerzos para reunir datos cuantitativos.
Por Neil Sorensen
Habrás notado que nuestro blog se ha hecho un lifting recientemente. Mientras que rediseñar los sitios de portada es bastante común, en nuestro caso, esto representó un cambio mayor. Nos dimos cuenta de que no tratábamos nuestro blog con los mismos principios que aplicamos al resto de nuestro trabajo. Así que nos embarcamos en un viaje para encontrar un mejor camino, que nos llevó a nuestra actual implementación.
Por Allan Stewart
¿Qué tipo de arquitectura de software debería implementar? Cuando se observan las tendencias de la industria, los blogs, las charlas en conferencias y cosas por el estilo, es fácil pensar que otras empresas lo tienen todo resuelto. Te perdonarían si quisieras copiar el éxito que otros están teniendo. Pero no hay una arquitectura perfecta. Todo es un conjunto de compensaciones; sólo hay buenos y malos ajustes para un contexto.
Por Allan Stewart
La deuda técnica es una metáfora ampliamente conocida que nos ayuda a pensar en cómo los problemas técnicos perjudican nuestra capacidad de ofrecer valor comercial a través de los sistemas de software. Pero conocer el concepto es diferente a manejar realmente la deuda técnica. Desafortunadamente, muchos equipos de software saben que tienen una deuda técnica, pero no saben qué hacer al respecto.
Por Allan Stewart
La retroalimentación es la información que recibimos del mundo en respuesta a hacer algo. Sin retroalimentación, no hay forma de saber si estamos logrando nuestros objetivos.
Por Steve Taggart
En un post anterior, Jon habló de vivir en un mundo sin QA. Si su organización tiene gente en roles dedicados a la QA, una idea es entrenarlos para que se conviertan en desarrolladores. Habiendo comenzado mi carrera de software en QA y haciendo la transición de QA a devenir yo mismo, exploraré algunas ideas sobre cómo hacerlo en este post.
Por Allan Stewart
Una importante lección que he aprendido es que cuando nos dejamos llevar demasiado, creamos trabajo adicional para nosotros mismos. Este trabajo adicional es una forma de meta-trabajo no valioso al que me refiero como trabajo secundario. Se interpone en el camino de hacer el trabajo que realmente tiene valor.
Por Allan Stewart
Una de mis actividades favoritas como profesional del software es borrar el código. Con el tiempo, he aprendido que es una de las mejores cosas que puedo hacer porque la cantidad ideal de código es no tener ningún código.
Por Allan Stewart
Los sistemas distribuidos son difíciles. Tienen muchas partes móviles con interacciones complejas y son inherentemente multi-hilos. Para hacerlos funcionar, a menudo hay alguna forma de consistencia eventual en juego. Aceptar esto puede facilitar el desarrollo de software.
Por Dave Adsit
Para que una organización tecnológica pueda ofrecer productos en apoyo de la misión de una empresa, las decisiones sobre qué tecnología utilizar y cómo utilizarla deben tomarse con regularidad. La creación de una estrategia para tomar estas decisiones es un problema para muchas organizaciones.
Por Allan Stewart
Cuando me uní, sabía que al entrar iba a ser un tipo de empresa diferente. Ya estaban practicando cosas que había estado aprendiendo y luchando por implementar en mi compañía anterior, como TDD y entrega continua. Pero no me di cuenta de lo diferente que sería mi trabajo diario hasta que descubrí que mi equipo estaba haciendo algo llamado programación de la mafia.
Por Allan Stewart
Las revisiones de código son generalmente aceptadas como algo bueno en el desarrollo de software. Algunos de los beneficios incluyen la mejora de la calidad, el intercambio de conocimientos de un sistema y la promoción de la propiedad colectiva del código. Pero la forma en que se realiza una revisión de código es importante…
Por Jonathan Turner
Es difícil que el código proporcione valor a menos que sea accesible para los usuarios. Si nuestro código no proporciona valor, ¿por qué lo escribimos? La forma en que obtenemos el código en nuestros entornos de producción ha cambiado con el tiempo y varía un poco de un equipo a otro, pero obtener…