El siguiente post es un extracto del capítulo 8 de Writing for Developers: Blogs That Get Read de Piotr Sarna y Cynthia Dunlop. Escribir para desarrolladores: blogs que se leen The bug hunt Lo reescribimos en X Cómo lo construimos Lessons learned Pensamientos sobre las tendencias Perspectivas de productos no comerciales Benchmarks y resultados de las pruebas y The “Bug Hunt” blog post pattern is the programming world’s equivalent of a detective story. It has a theme, a main plot, side plots, a protagonist (you), an antagonist (usually also you, having introduced the bug two weeks ago in the first place). It’s captivating, keeps readers in suspense, and ends with a satisfying plot twist, or a tactical cliffhanger. And the best part is…it’s even more fun to write than to read! 8.1 Objetivos Escribir un artículo de caza de insectos sirve a varios propósitos, dependiendo del éxito de la caza, donde finalmente cayó la culpa, y algunos otros factores. 8.1.1 Depósito de conocimientos El hecho de que un bug apareciera y fuera corregido es innegablemente importante, pero lo que es mucho más importante es reducir la posibilidad de que vuelva a ocurrir – y saber qué hacer si ocurre. Algunos muertos terminan Un herring rojo muy convincente Una herramienta que al principio parecía útil, pero acabó siendo irrelevante Otra herramienta que resultó extremadamente útil Algunas publicaciones de blog de 2014 que te llevaron a descubrir la causa raíz Todos esos pasos son increíblemente útiles para el futuro debugger de otro problema similar (probablemente usted de nuevo, dos semanas más viejo). La conciencia de los finales muertos pasados y distracciones es especialmente útil aquí. La identificación rápida de un herring rojo conocido puede ahorrar al futuro debugger (Usted) unas pocas horas de investigación poco productiva. Puedes tratar los mensajes de blog de caza de bugs como rollos de conocimiento antiguo (dos semanas o más), creado por tus predecesores (Usted) para transmitirlo a las generaciones futuras (también Usted). 8.1.2 Conocimiento global de los bugs Es un tiempo de devolución a la comunidad! Las posibilidades son, el bug que has corregido no se aplica únicamente a tu proyecto. En cambio, fue causado por una trampa en tu idioma de elección, una de las bibliotecas, o hardware específico. Tu artículo puede inspirar a otros a pensar "Huh, tenemos exactamente la misma configuración - me sorprende..." También podría motivar al equipo detrás de esa tecnología para considerar maneras de impedir que otros cometan el mismo error. Como resultado, escribir una historia sobre cómo has corregido un error interesante puede causar que algunos otros errores de la misma categoría sean corregidos en todo el mundo. ¡Es un superpoder! Este propósito es especialmente importante si el error está relacionado con: Software de sangrado Edge Nuevo hardware Una comunidad joven de código abierto Those tend to develop dynamically and have very little test coverage compared to industry standards simply because they are too young to be implemented in a critical mass of projects. You can think of this purpose as an external version of the previously described "knowledge dump" – it’s a knowledge dump that you write for everyone, not just for yourself or your team. 8.1 Bragging Poner de lado la connotación negativa de la palabra "bragging". el mundo de la tecnología - en la dosis correcta - es bueno para usted y sus compañeros. el orgullo de hacer algo interesante, como cazar y resolver un bug, te ayuda a ti y a tus lectores: It's educational. Your audience can presumably learn something by reading how you achieved your goal. It broadens your professional network. People intrigued by similar technologies and challenges will likely reach out to you as we outlined in Chapter 1. It feels good. There’s no shame in acknowledging that attention is one of the benefits of telling the world that you did something. It yields free criticism – hopefully constructive criticism, but valuable either way. The (often illusory) sense of anonymity on the Internet makes it easy to criticize others, so you can count on lots of comments and nitpicks after your article goes public. But after filtering out the vitriol, you can often learn something new, or even revisit your whole approach to the problem. 8.2 Audiencia La caza de bugs es un tema técnico, y la audiencia para los mensajes de blog de caza de bugs es inherentemente tan técnica. People with a similar background (which means they are potentially susceptible to introducing or suffering from similar bugs in their systems) Personas cuyo trabajo es encontrar y corregir los errores de producción Personas en medio de una similar caza de insectos Personas que podrían ser capaces de evitar que esta clase de errores se repitan (aquellas detrás de la tecnología donde ocurrió el error o trabajando en herramientas de prevención de defectos) Detective Fiction aficionados Sus colegas Profesionales críticos de Internet especializados en asesoramiento no solicitado It's safe to assume that the audience is someone who: Ya tiene suficiente antecedentes profesionales para comprender los términos técnicos e idiomas que utiliza en el artículo Si no, está dispuesto a mirarlos y aprender Si no, es absolutamente bueno pretender que lo entienden. Por lo tanto, es bueno tratar un post de blog de caza de bugs como uno dirigido a los lectores de "nivel intermedio" (o superior) y no a los "novatos".Los términos técnicos avanzados son buenos porque no estás tratando de hacer el artículo accesible a un público más amplio. 8.3 Ejemplos Puesto que los bugs pueden ocurrir en cualquier lugar, también pueden ocurrir los mensajes de blog de la caza de bugs. En el campo salvaje, puede encontrar mensajes de caza de bugs publicados en una variedad de blogs: Big Tech, unicornio, startup y blogs personales. En general, los mensajes de caza de bugs publicados por grandes compañías de alto perfil son sorprendentemente menos comunes (y más guardados) que los de las startups, así como los contribuyentes individuales que escriben sobre contribuciones de código abierto y proyectos de fin de semana. Here are some prime examples of blog posts that apply the “Bug Hunt” pattern, along with Piotr’s commentary on each. 8.3.1 Caza de un bug de rendimiento NUMA Mijaíl Chojnowski Author: En el blog de la Universidad de Oviedo ( ) Source: https://www.scylladb.com/2021/09/28/hunting-a-numa-performance-bug/ Summary The article describes a performance regression happening on modern hardware with NUMA (Non-Uniform Memory Access) design. The regression seemed to occur randomly on half of the runs, which made it much harder to pinpoint. The article shares a few failed (but nonetheless skillful and impressive) attempts to diagnose the problem. Then, one of the observations leads straight to a breakthrough and a surprisingly small fix – measured with lines of code. Commentary Este es el punto culminante de los mensajes de blog de caza de bugs. Es profundamente técnico, pero al mismo tiempo simple de seguir. Los lectores menos experimentados pueden saltar algunos de los detalles nitty-gritty y todavía aprender mucho.Todos los intentos fallidos de diagnosticar el problema son educativos, y seguramente útiles en el futuro debugging. La experiencia casual que el autor muestra al editar binarios ejecutables directamente como si fueran archivos de texto hace que el post del blog sea una lectura extremadamente agradable.La solución al problema también es muy satisfactoria, especialmente para la mente de un programador: sólo una línea aparentemente inocente de código cambió, y todas las regresiones de rendimiento se eliminan. 8.3.2 ¿Por qué mi Rust se construye tan lentamente? Amos Wenger Author: En el blog de la Universidad de Madrid ( Source: https://fasterthanli.me/articles/why-is-my-rust-build-so-slow) Summary Esta extensa publicación de blog investiga los problemas de tiempo de compilación para un proyecto Rust. Muestra múltiples técnicas para perfilar el propio compilador, descomponer el proceso de compilación en piezas manejables y medir cuánto tiempo toma cada pieza y por qué. Está llena de imágenes, fragmentos de código y descripciones de herramientas concretas que puede usar. La conclusión del artículo no es realmente cualquier paso adelante, sino más bien un consejo honesto para aplicar todas las técnicas extensas anteriormente si no está satisfecho con sus tiempos de construcción Rust. Commentary En comparación con un post de blog técnico promedio, este es un hog – en un sentido puramente positivo! puede tomar fácilmente a un lector cualificado media hora para leerlo, y es probablemente una buena idea digerirlo en tres o cuatro partes, tomando pausas de la pantalla para evitar mareos y diplopia. Este es un rasgo positivo porque hace que el artículo se destaque.Muchos artículos de tecnología tratan de comprimir la mayor cantidad de información posible en 4 a 6 minutos de lectura.Y eso es justo, teniendo en cuenta el rango de atención promedio de un ser humano levantado en teléfonos inteligentes en lugar de jugar fuera todo el día con pausas ocasionales de dibujos animados. El artículo tiene un estilo único con el alter ego del autor, Cool Bear, que regularmente agrega comentarios humorísticos cortos - manteniendo al lector involucrado a lo largo del proceso de lectura (largo). y Este tipo de publicación de blog de la caza de bugs también sirve como una enciclopedia de técnicas para deshacer el compilador de Rust. Lo tengo marcado, solo en caso de que necesite refrescar mis conocimientos de cómo medir los tiempos de enlace en mis proyectos.La conclusión también es bastante no convencional: en lugar de construir tensión y finalmente presentar a los lectores con una solución sorpresa, es simplemente un resumen honesto con ánimo de alcanzar. 8.3.3 How a Single Line of Code Made a 24-core Server Slower Than a Laptop Piotr Kołaczkowski Author: Artículo anteriorEl blog de Pedro Pacheco ( ) Source: https://pkolaczk.github.io/server-slower-than-a-laptop/ Summary The blog post describes how local benchmarks detected a bottleneck on machines with lots of CPU cores. The author shares a performance analysis, performs some profiling, then offers a few explanations of how modern CPUs work under the hood and how the processor caches manage memory. The suggested fix is a natural consequence of the conclusions reached earlier in the article: minimizing the amount of state shared between processor units eliminates the bottleneck. Commentary Este es otro ejemplo estelar de un post de blog de caza de bugs. Su título es un poco clickbaity, pero todavía lo suficientemente elegante como para evitar ser rechazado por el software de bloqueo de anuncios promedio. Los detalles técnicos son mucho más universalmente entendidos que los de Chojnowski en el blog NUMA (descrito anteriormente en esta sección). The article is sneakily educational, digressing on things like "How many nanoseconds does L3 cache access take on average on Intel Xeon." That's great practice; it leaves those details imprinted in readers' minds without them realizing it. Who knows – maybe one day that tucked-away tip might help fix a performance bug in another project. Overall, the article leaves readers satisfied with the result, and also a tiny bit smarter in the field of CPU architecture and performance. 8.3.4 Lecciones de Debugging una fuga de memoria Tricky Direct Sanchay Javeria Author: En el blog de la Universidad de Oviedo ( ) Source: https://medium.com/pinterest-engineering/lessons-from-debugging-a-tricky-direct-memory-leak-f638c722d9f2 Summary El equipo de desarrollo de Pinterest comparte su experiencia en la búsqueda de una fuga de memoria de código de procesamiento de flujo que llevó a fallos en cascada en su sistema distribuido. Commentary Este es un artículo clásico de caza de errores – tanto que podría ser usado como un modelo de publicación de blog para cazar casi cualquier problema en el código de Java. Contiene los pasos de investigación habituales, junto con capturas de pantalla de herramientas de observación. También siguiendo las especificaciones, el párrafo culminante se llama "The Fix." Se explica que el culpable era otro problema de fuga de memoria causado indirectamente por los mecanismos de recogida de basura en Java. Sugerencia: Siempre lo es! En este contexto, la conclusión no es realmente un avance devastador, pero definitivamente cumple con las expectativas de los lectores. apuesto que la mayoría de los lectores piensan "Ah, lo sabía desde el principio" justo después de aprender la causa raíz. 8.3.5 ZFS está misteriosamente comiendo mi CPU Brendan Gregg Author: El blog de Gregorio ( ) Source: https://www.brendangregg.com/blog/2021-09-06/zfs-is-mysteriously-eating-my-cpu.html Summary El post del blog describe una búsqueda de la causa del misterioso uso de CPU más alto de lo esperado. muestra cómo reducir los candidatos a una única llamada de función con herramientas de análisis y concluye con un sorprendente error de rendimiento en ZFS - una implementación de sistema de archivos. Commentary El título en sí es captivador, pero luego algo en la URL salta a usted: es por Brendan Gregg, el inventor del gráfico de la llama! Este es un primer ejemplo de por qué la marca personal importa tanto. Cuando veo “Brendan Gregg”, inmediatamente asumo que el artículo es interesante ... y no me equivoco en lo más mínimo. Dada la experiencia de Gregg, el análisis del problema involucró naturalmente los gráficos de la llama. La causa raíz es bastante sorprendente, y Gregg lo describió de una manera muy informal y divertida. El post del blog también es muy conciso: una lectura de tres minutos, incluso si reserva algún tiempo de antemano para ver las capturas de pantalla de los gráficos de la llama. Esto muestra claramente que no necesita escribir miles de palabras para comprimir un montón de conocimientos, consejos y detalles técnicos interesantes. Ver más recientes publicaciones de “Bug Hunt” en writethat.blog Ver más recientes publicaciones en el blog de “Bug Hunt” Escribe en el blog Escribe en el blog 8.4 Características Las publicaciones en el blog de Bug Hunt pueden variar tanto como la caza de bugs real, pero tienden a compartir las siguientes características: Cuentan la historia cronológicamente, desde el momento en que el malvado bug se manifestó, hasta cuando fue declarado muerto. Se centran principalmente en la emoción (y dolor) de la caza Comparten libremente las pruebas recopiladas a lo largo de la caza para que los lectores puedan poner sus sombreros de detective y jugar con ellos. Se dirigen en gran medida a desarrolladores experimentados que conocen las tecnologías que se discuten (o están listos para aprender a medida que van) They offer technical nuggets that could be interesting now, lifesaving later Vamos a examinar cada uno a su vez. 8.1 Cronología de la obra Las publicaciones del blog de la caza de bugs a menudo siguen una estructura específica ya que son el equivalente tecnológico de las historias de detectives. (Si desea una introducción o un refresco sobre la estructura de una historia de detectives, la IA generativa hace un trabajo decente aquí).El párrafo de introducción no revela demasiados detalles y ciertamente no proporciona un spoiler sobre la solución. A menudo, simplemente elaboran el título (propiamente misterioso) con unas pocas palabras más. Una vez que el problema se define, la búsqueda comienza, generalmente con unos pocos intentos fallidos (pero educativos).La tensión se construye hasta que el autor alcanza su momento de aha, que es seguido por la descripción de la corrección (y esa sección se titula habitualmente "La corrección").Después de que se revele la solución, el post del blog concluye describiendo medidas preventivas para evitar que este bug se repita - y a menudo una breve disculpa a cualquier usuario afectado. 8.4.2 Pesado en la caza La parte más delicada del artículo es el camino hacia la identificación del problema.Gastar alrededor del 80% del post explicando el proceso de investigación es una buena regla del pulgar.Por ejemplo, aquí está cuánto tiempo cada uno de los artículos de blog de ejemplo anteriormente se gastó en la investigación (basado en el número de palabras): 85% hunt Chojnowski: 83% hunt Wenger: 83% hunt Kołaczkowski: 82% hunt Javeria: 93% hunt Gregg: 8.3 Evidencia en todas partes Bug hunt blog posts are usually full of forensic evidence. Readers want to see flame graphs, numbers, charts, scripts, and code samples. This lets them step into your detective shoes and try to figure out the riddle before the big reveal. Por ejemplo, aquí están algunas de las pruebas que se muestran en las publicaciones de blog de ejemplo: Chojnowski: gráficos de monitorización de bases de datos (escritos por fracción), gráficos de rendimiento de red y disco, estadísticas de CPU, gráficos de flame y fallos a nivel de instrucciones, eventos de la unidad de monitorización de medición de rendimiento (PMU) de la CPU y una variedad de correcciones de código intentadas Wenger: Tiempos de construcción de cargas, una línea de tiempo de unidades de compilación, gráficos de uso de la CPU y concurrencia, información de debug, gráficos de llama, rastreo a través de Chromium y Perfetto, tentativas de correcciones de código, gráficos de dependencia Kołaczkowski: Una mirada al diseño de la herramienta de benchmarking, resultados de rendimiento (en su portátil de 4 núcleos vs. un servidor de 24 núcleos), gráficos de la llama Javeria: detalles de errores fuera de la memoria, pruebas de presión de retroceso y múltiples introducciones en el monitoreo de la memoria Gregg: Gráficos de la llama (por supuesto!), detalles de montaje de ZFS, arcstats y todo el código fuente, a través de un enlace de GitHub y Los gráficos de la llama son particularmente comunes en los mensajes de blog de la caza de bugs. Ofrecen una gran manera de visualizar su proceso de depuración y el perfil de rendimiento. Y son interactivos - los usuarios pueden zoom en las partes interesantes, filtrar sólo los eventos que coinciden con una expresión regular particular, y mucho más. Los gráficos de la llama se pueden crear a partir de la salida de herramientas populares, como el perfil perfecto de Linux o el comando gráfico de la llama de carga de Rust. 8.4.4 Expert friendly Los artículos de caza de errores tienden a ser amigables con los expertos. El autor suele asumir que el público es experto (o al menos familiarizado) con la pila tecnológica utilizada en el artículo. Las muestras de código y los scripts compartidos en el artículo suelen dirigirse a lectores que están familiarizados con los lenguajes de programación utilizados. Estos tipos de publicaciones no son propicios para las explicaciones básicas de los conceptos de lenguaje básico; si el lector no lo "coge", es posible que necesiten soltarlo o simplemente seguir adelante. This is distinctly different than in other blog post patterns, such as “We Rewrote It in X” (discussed in Chapter 9). Blog posts in that pattern are more appropriate for those just getting started with the given technology and often include an “Introduction to the New Language” section. 8.4 Educación Las publicaciones de blog que siguen este patrón pueden ser bastante educativas para los desarrolladores más allá del equipo afectado. La parte carnosa, la identificación de bugs, es abundante en detalles sobre cómo inspeccionar problemas similares. Más importante aún, estas secciones son abundantes en detalles reproducibles: aquellas que son susceptibles de ser útiles para resolver todo tipo de problemas similares que los lectores podrían enfrentar en el futuro. El post de blog sirve su propósito si deja al lector equipado con unos cuantos trucos más que pueden aplicar, sólo en caso de que alguna vez se encuentren con un bug similar en algún momento de su vida. Por ejemplo, aquí está una visión de alto nivel de lo que los lectores podrían aprender de cada uno de nuestros ejemplos de publicaciones de blog: The kinds of issues you might encounter with complex memory architecture (NUMA), especially with ARM processors Chojnowski: Ways to improve your Rust build times Wenger: How modern CPUs work under the hood and how the processor caches manage memory Kołaczkowski: Java is evil Javeria: How to apply analysis tools like an absolute expert Gregg: 8.5 Dos y Don'ts The best blog posts are born from the most torturous bug hunts. Driven by the glorious feeling of finally solving the mystery, strike while the iron is hot. Write your impressions before the high of the hunt wears off and help your peers solve their next case faster. Here are some tips for writing your own Bug Hunt blog post. 8.5.1 Compruebe si alguien (su jefe, los abogados de su jefe) se molestará por su transparencia Esto es especialmente importante si has buscado un error que tuvo un impacto notable en los usuarios, o si la divulgación de este error podría afectar negativamente la reputación de tu empresa y/o el precio de las acciones.Proyectos de código abierto o disponibles por fuente generalmente no imponen ninguna consideración legal (excepto quizás tratar de evitar que tu código se infecte con una de las licencias de la GPL y sus términos "copyleft"). Antes de publicar fragmentos de código de sus secretos corporativos muy guardados, asegúrese de que su jefe y cualquier parte interesada estén bien con él. Incluso si salta el código, sus superiores todavía pueden ser aversos a hacer pública cierta información, especialmente si el error se relacionó con la seguridad, o terminó con una infeliz fuga de datos. Use esta regla del pulgar: Pregunte primero, escriba y publique después. 8.5.2 Hacer un buceo técnico profundo Los detalles técnicos son un must en cualquier, bueno, Si su artículo carece de detalles como muestras de código, especificaciones sobre la tecnología exacta utilizada, instrucciones paso a paso, etc., muchos lectores se dejarán insatisfechos. Incluso peor, podrían dudar de su integridad. Tal vez los bits incómodos se omitieron deliberadamente para hacer que el producto se vea mejor? Si usted está preocupado de que pueda estar añadiendo demasiados detalles técnicos, error en el lado de más. Los lectores siempre pueden saltar sobre ellos si no los encuentran interesantes. Técnicas Se espera especialmente que los mensajes de blog de la caza de errores estén cargados de consejos, trucos, código, resultados de referencia, así como enlaces a repositorios y documentación de código abierto. De lo contrario, robarás a los lectores la oportunidad divertida de sacar sus propias conclusiones de las abundantes pruebas. Como se señaló anteriormente, es bueno ser amigable con los expertos aquí. Puedes asumir que el público ya está familiarizado con la tecnología descrita o está dispuesto a capturarlo (con la ayuda de tu publicación de blog). 8.5.3 Sea brutalmente honesto acerca de todos sus fracasos Your failures and misery provide readers with the cathartic effect that brought them to your blog post in the first place! They also give rise to the most educational aspect of bug hunting articles. After all, it's great to learn from mistakes, but it's even better to learn from somebody else's mistakes first. Los mensajes de blog de la caza de bugs generalmente se escriben después de que se haya identificado la causa raíz y se haya corregido el bug. Cuanto más dolor y sufrimiento se describen en los primeros párrafos, mejor se ve el avance final. Los lectores que luchan con problemas similares van a buscar activamente en Internet para encontrar descripciones de problemas similares, por lo que todas las palabras clave tristes como "quebrado", "defecto" o "FUBAR" sirven a doble propósito - son una salida emocional para la frustración del autor, además también hacen que el post del blog sea más fácil de encontrar en línea. No trates de transmitir una caza de insectos perfecta y primitiva.Las terminaciones muertas y los intentos fallidos aportan toneladas de valor educativo.Los programadores (que por supuesto es sinónimo de “grandes mentes”) piensan de la misma manera. 8.5.4 Incluir números, índices de referencia, métricas y gráficos de la llama Benchmark results, metrics, and all kinds of numbers are the equivalent of clues and proofs from the detective fiction world. Bug hunting blog posts look less legit if they use vague phrasing like "our system is now much faster." Readers will immediately think "Yeah, but how much faster?" followed by "Dear author, if you were orgullosos de los resultados, entonces los habrías publicado..." Las capturas de pantalla de tus métricas (o mejor aún, las figuras interactivas como los gráficos de la llama) atraen los ojos de los lectores, haciendo el artículo más creíble y más agradable de leer. Realmente 8.5.5 No renuncies demasiado, demasiado pronto – mantenga el edificio de tensión Para la mayoría de los mensajes de blog, recomendamos compartir el TL;DR temprano para que los lectores puedan decidir rápidamente si quieren continuar. No aquí! Con los mensajes de bug hunt, evite spoilers a todo precio! La tensión debe ser construida con paciencia hasta que el momento aha ocurra, y la solución se revela. Esto es clave para permitir que los lectores (aquellos que no tienen prisa, al menos) experimenten vicariamente la emoción de la caza, con todas sus giras y giras. Probablemente ya sospechen que el artículo termina con un final feliz, porque de lo contrario no se publicaría. Pero ¿no son la mayoría de las historias de detectives como eso de todos modos? 8.5.6 Don’t make overeager readers hunt too hard for the fix That being said, some readers will get impatient. Maybe they drew their own conclusion after just a few paragraphs and want the immediate gratification of confirming that they got it right, right away, unlike silly old you. Maybe this is the twelfth Java bug hunting blog post they’ve come across this month and they want to see if this is yet another one where the garbage collector is ultimately to blame. Be kind and mark “the fix” with a nice prominent heading so they can skip ahead to the smoking gun. As a bonus, having a clearly labeled fix is also helpful to those who are returning to your blog post because they’re now suffering a similar problem. Back when they were reading this for fun, they enjoyed following along with the thrill of your hunt. But now that the tables have turned, they want to go straight to your fix and see if it will save them in their own moment of despair. 8.5.7 Añadir puntos de interrupción cuando sea necesario Los artículos de caza de errores pueden llegar a ser largos, especialmente si está cubriendo cada pequeño giro y giro (como absolutamente debería!) Si termina escribiendo un post de blog que tardará más de 20 minutos en leer, considere agregar algunos puntos de interrupción claros para los lectores, en caso de que opten por consumir su artículo en más de una sesión. Por ejemplo, podrías proporcionar un breve resumen del progreso de la investigación hasta ahora. podrías añadir una nota explícita de que los pasos descritos anteriormente llevaron a un final muerto, llevando a una nueva tesis. O podrías simplemente usar subtitulos como “Fase 3”, sugiriendo subliminalmente al lector que es bueno tomar una breve pausa de café aquí sin perder el contexto. 8.5.8 No succiones la vida de ella Los lectores no están aquí para leer un informe oficial de fracaso.Los bits captivantes son la historia personal, la lucha y la alegría final de averiguar qué estaba mal.Los mejores mensajes de blog de caza de bugs usan un tono de conversación informal, y las anécdotas son muy bienvenidas. Cuéntalo desde su punto de vista personal. No dude en compartir lo que estaba pasando a través de su mente a medida que se desarrolló el misterio. Además, los rantes son obligatorios y esperados - en dosis razonables, por supuesto. En el fondo, la mayoría de los humanos disfrutan de leer sobre las frustraciones de otras personas y sentir el alivio indirecto de que no les sucedió (aún). Los enfoques de “creación de tensión” y “proporcionar acceso completo a pistas” detallados anteriormente son dos maneras fundamentales de mantener a los lectores involucrados (sí, ellos sin vergüenza robado de historias de detectives reales). Además, es posible que desee: son Write in an extremely casual tone, sacrificing “proper” grammar as needed to keep it conversational Create a faux dialog with the reader: ask them questions so they’re encouraged to step back and form their own hypotheses (which you will proceed to confirm or disprove) Write as if you’re in the thick of the hunt (e.g., “Let’s see if …” vs. “Then we checked if…’’) Share exactly what popped into your head (no matter how silly it seems in retrospect) as you encountered each new piece of information Explicitly call out critical moments like “plot twist,” “dead end,” and “the aha moment” to ensure readers are in the right mindset at every point 8.5.9 No se olvide de agradecer a los que ayudaron a la caza La razón más importante para reconocer públicamente a sus colaboradores es la pureza de la bondad. La caza de bugs es una de las partes más furiosas de la programación informática, y la miseria ama a la compañía. Sus colaboradores probablemente hicieron el dolor un poco menos excruciante; si aprecia eso en absoluto, dale las gracias aquí. Para las personas no tan empáticas, también hay razones pragmáticas (leer: egoístas) para agradecer a sus colaboradores. Su reconocimiento podría hacer que sean más propensos a ayudar en la próxima caza de bugs. Además, si nombra a alguien en un post de blog, puede garantizar bastante que lo leerán – y tal vez incluso lo compartirán. Y tal vez alguien que conozcan será la persona para comenzar a tendencia en Hacker News. 8.5 Extrapolado Siéntate libre de extrapolar de errores específicos (por ejemplo, "Nuestro código Rust tuvo un error") a cuestiones más generales (por ejemplo, "La biblioteca estándar de Rust hace que sea fácil bloquear en este caso de uso en particular.") Las publicaciones de blog de caza de errores también son oportunidades para iluminar algunos puntos de dolor que tienes con una tecnología en particular. Has logrado atraer a un público cautivo, interesado en lo que tienes que decir. ¿Por qué no aprovechar eso? Si notaste algo particularmente problemático con el idioma o la biblioteca que usaste, pica la bala y sugiere que algo debe ser corregido hacia arriba. 8.6 Resumen Writing a bug hunting article serves to share knowledge, raise awareness about bugs you encountered, and showcase your achievements Un blog de caza de bugs se dirige a un público técnico, desde expertos a entusiastas, usualmente asumiendo (al menos) un conocimiento intermedio de la terminología. Las publicaciones de blog de caza de bugs suelen ser pesadas en detalles investigativos, mostrando evidencia técnica en forma de números, índices de referencia, resultados y gráficos. Top tips: Check for transparency issues Do a technical deep dive Be brutally honest Include numbers and benchmarks Avoid spoilers Clearly mark “the fix” Make it personal Thank your collaborators * El Puedes ver más del libro (don’t miss the y Por favor, tenga en cuenta que las palabras se confunden en algún punto aparentemente arbitrario más allá de nuestro control. / ̄ En el sitio de Manning Películas de Bryan Cantrill Descripción de Scott Hanselman (en el y
