O seguinte post é un extracto do capítulo 8 de Writing for Developers: Blogs That Get Read de Piotr Sarna e Cynthia Dunlop. Escribir para desenvolvedores: blogs que se poden ler A caza de bugs Reescribímolo en X Como o construímos Leccións aprendidas Reflexións sobre tendencias Perspectivas de produtos non comerciais Benchmarks e resultados das probas que O patrón de publicación do blog "Bug Hunt" é o equivalente do mundo da programación a unha historia detective. Ten un tema, unha trama principal, tramas laterais, un protagonista (vostede), un antagonista (normalmente tamén vostede, tendo introducido o bug hai dúas semanas en primeiro lugar). É cativante, mantén os lectores en suspense e remata cunha torsión de trama satisfactoria, ou un cliffhanger táctico. 8.1 Obxectivos Escribir un artigo de caza de bugs serve a varios propósitos, dependendo do éxito da caza, onde a culpa finalmente caeu, e algúns outros factores. 8.1.1 Depósito de coñecemento O feito de que un bug apareceu e foi corrixido é indubidablemente importante, pero o que é moito máis importante é reducir a posibilidade de que ocorra de novo - e saber que facer se ocorre. Algúns mortos rematan Unha herba vermella moi convincente Unha ferramenta que ao principio parecía útil, pero acabou por non estar relacionada Outra ferramenta que demostrou ser moi útil Algúns artigos do blog de 2014 que te levaron a descubrir a causa raíz Todos estes pasos son incriblemente útiles para o futuro debugger doutro problema similar (probablemente vostede de novo, dúas semanas máis vello). A conciencia dos finais mortos e distraccións pasados é especialmente útil aquí. A identificación rápida dun hering vermello coñecido pode aforrar ao futuro debugger (vostede) algunhas horas de investigación improductiva. Pode tratar as publicacións de blogs de caza de bugs como rolos de coñecemento antigo (dúas semanas ou máis), creados polos seus predecesores (vostede) para transmitilo ás xeracións futuras (tamén vostede). 8.1.2 Concienciación global de bugs É tempo de dar de volta á comunidade! As posibilidades son, o bug que corrixiches non se aplica exclusivamente ao teu proxecto. No canto diso, foi causado por unha trampa enganosa no teu idioma de elección, unha das bibliotecas, ou hardware específico. O teu artigo pode inspirar a outros a pensar "Huh, temos exactamente a mesma configuración - faime preguntar..." Tamén podería motivar ao equipo detrás desa tecnoloxía para considerar formas de impedir que outros cometan o mesmo erro. Como resultado, escribir unha historia sobre como corrixir un bug interesante pode causar algúns outros bugs da mesma categoría para ser corrixido en todo o mundo. É unha superpotencia! Este propósito é especialmente importante se o bug está relacionado con: Descrición do software Bloeding Edge Novas de hardware Unha nova comunidade de código aberto Estes tenden a desenvolverse de forma dinámica e teñen moi pouca cobertura de probas en comparación cos estándares da industria simplemente porque son demasiado novos para seren implementados nunha masa crítica de proxectos. Pode pensar neste propósito como unha versión externa do "dump de coñecemento" descrito anteriormente - é un dump de coñecemento que escribe para todos, non só para si ou para o seu equipo. 8.1 Bragadoiro Set aside the negative connotation of the “bragging” word. Tech world bragging – at the right dosage – is good for you and your peers. Bragging about doing something interesting, like hunting and resolving a bug, helps you as well as your readers: 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 A caza de bugs é un tema técnico, e a audiencia para as publicacións de blog de caza de bugs é inherentemente tan técnica. Persoas con antecedentes similares (o que significa que son potencialmente susceptibles de introducir ou sufrir de erros similares nos seus sistemas) Persoas cuxo traballo é atopar e corrixir bugs de produción As persoas no medio dunha similar caza de bugs Persoas que poidan evitar que esta clase de bugs se repitan (aquelas detrás da tecnoloxía onde ocorreu o bug ou traballando en ferramentas de prevención de fallos) Detective fiction aficionados Os seus colegas Professional Internet critics specialized in unsolicited advice É seguro asumir que o público é alguén que: Xa ten un fondo profesional suficiente para comprender os termos técnicos e idiomas que usa no artigo Se non, está disposto a miralos e aprender Se non, é absolutamente correcto simplemente finxir que o entenden Polo tanto, está ben tratar un post de blog de caza de bugs como un dirixido a "nivel intermedio" (ou superior) lectores e non "novos". Termos técnicos avanzados están ben porque non está intentando facer o artigo accesible para un público máis amplo. 8.3 Exemplos Dado que os bugs poden ocorrer en calquera lugar, tamén poden aparecer as publicacións de blogs de caza de bugs. No medio salvaxe, podes atopar publicacións de caza de bugs publicadas en unha variedade de blogs: Big Tech, unicornio, startup e blogs persoais. En xeral, as publicacións de caza de bugs publicadas por grandes empresas de alto perfil son sorprendentemente menos comúns (e máis gardadas) que as de startups, así como contribuíntes individuais que escriben sobre contribucións de código aberto e proxectos de fin de semana. Aquí están algúns exemplos destacados de publicacións de blog que aplican o patrón de "caza de bugs", xunto co comentario de Piotr sobre cada un deles. 8.3.1 Caza dun bug de rendemento NUMA Micheal Chojnowski Author: Páxina do blog ( ) Source: https://www.scylladb.com/2021/09/28/hunting-a-numa-performance-bug/ Summary O artigo describe unha regresión de rendemento que ocorre no hardware moderno co deseño NUMA (Non-Uniform Memory Access). A regresión pareceu ocorrer aleatoriamente na metade das carreiras, o que o fixo moito máis difícil de identificar. O artigo comparte algúns intentos fallidos (pero aínda así hábiles e impresionantes) para diagnosticar o problema. Entón, unha das observacións leva directamente a un avance e unha corrección sorprendentemente pequena - medida con liñas de código. Commentary Este é o pico de publicacións de blogs de caza de bugs. É profundamente técnico, pero ao mesmo tempo sinxelo de seguir. Os lectores menos experimentados poden saltar algúns dos detalles gritty e aínda aprender moito. A experiencia casual que o autor mostra ao editar binarios executables directamente coma se fosen ficheiros de texto fai que a publicación do blog sexa unha lectura extremadamente agradable.A solución ao problema tamén é moi satisfactoria, especialmente para a mente dun programador: só unha liña de código aparentemente inocente cambiou, e todas as regresións de rendemento elimínanse. 8.3.2 Por que o meu Rust está construíndo tan lento? Amos Wenger Páxina Author: Páxina oficial do blog ( Source: https://fasterthanli.me/articles/why-is-my-rust-build-so-slow) Summary Esta extensa publicación de blog investiga os problemas de tempo de compilación para un proxecto Rust. Mostra varias técnicas para perfilar o propio compilador, descompoñer o proceso de compilación en pezas xestionables e medir canto tempo leva cada peza e por que. Está chea de imaxes, fragmentos de código e descricións de ferramentas de concreto que pode usar. A conclusión do artigo non é realmente un único avance, senón un consello honesto para aplicar todas as técnicas extensas anteriores se non está satisfeito co seu tempo de construción Rust. Commentary Comparado a un post de blog técnico medio, este é un hog - nun sentido puramente positivo! Pode levar facilmente un lector cualificado media hora para ler por el, e probablemente sexa unha boa idea dixerilo en tres ou catro partes, tomando pausas da pantalla para evitar mareos e diplopia. Esta é unha característica positiva porque fai que o artigo se destaque. Moitos artigos de tecnoloxía intentan espremer a maior cantidade de información posible en 4 a 6 minutos de lectura. E iso é xusto, considerando o intervalo medio de atención dun ser humano levantado en teléfonos intelixentes en vez de xogar fóra todo o día con pausas ocasionais de debuxos animados. O artigo ten un estilo único que presenta o alter ego do autor, Cool Bear, que regularmente engade comentarios humorísticos curtos - mantendo o lector comprometido ao longo do proceso de lectura (longo). que Este tipo de publicación de blog de caza de bugs tamén serve como unha enciclopedia de técnicas para descompilar o compilador Rust. Teño marcado, só no caso de que eu teña que refrescar o meu coñecemento de como medir os tempos de ligazón nos meus proxectos. A conclusión tamén é bastante non convencional: en vez de construír tensión e finalmente presentar aos lectores cunha solución sorpresa, é simplemente un resumo honesto con ánimo de alcanzar. 8.3.3 Como unha única liña de código fixo un servidor de 24 núcleos máis lento que un portátil Piotr Kołaczkowski Author: Páxinas do blog de Rianxo ( ) Source: https://pkolaczk.github.io/server-slower-than-a-laptop/ Summary O post do blog describe como os benchmarks locais detectaron unha lacuna de botella en máquinas con moitos núcleos de CPU. O autor comparte unha análise de rendemento, realiza algún perfil e, a continuación, ofrece algunhas explicacións de como funcionan as CPUs modernas baixo o capó e como as caches do procesador xestionan a memoria. Commentary Este é outro exemplo estelar dun post de blog de caza de bugs. O seu título é un pouco clickbaity, pero aínda o suficientemente elegante como para evitar ser rexeitado polo software de bloqueo de anuncios medio. Os detalles técnicos son moito máis universalmente entendidos que os no blog NUMA de Chojnowski (descrito anteriormente nesta sección). O artigo é lixeiramente educativo, digresando sobre cousas como "Cantos nanosegundos leva o acceso á caché L3 en media en Intel Xeon." Esa é unha gran práctica; deixa eses detalles impresos na mente dos lectores sen que eles se decaten. 8.3.4 Leccións de Debugging unha fuga de memoria Tricky Direct Sanchay Javeria Páxina Author: Enxeñaría de Telecomunicacións ( ) Source: https://medium.com/pinterest-engineering/lessons-from-debugging-a-tricky-direct-memory-leak-f638c722d9f2 Summary O equipo de desenvolvemento de Pinterest comparte a súa experiencia cazando unha fuga de memoria de código de procesamento de fluxo que levou a fallos en cascadas no seu sistema distribuído. Commentary Este é un artigo clásico de caza de erros - tanto que podería ser usado como un modelo de publicación de blog para cazar case calquera problema no código Java. Contén os pasos de investigación habituais, xunto con capturas de pantalla de ferramentas de observación. Tamén seguindo o custom, o parágrafo culminante chámase "The Fix." Explica que o culpable era outro problema de fuga de memoria causado indirectamente polos mecanismos de recollida de lixo en Java. Sinal: Sempre é! Neste contexto, a conclusión non é realmente un avance devastador, pero definitivamente cumpre coas expectativas dos lectores. aposto que a maioría dos lectores pensan "Ah, eu sabía desde o principio" xusto despois de aprender a causa raíz. 8.3.5 ZFS está misteriosamente comendo a miña CPU de Brendan Gregg Author: Páxinas do blog de Rianxo ( ) Source: https://www.brendangregg.com/blog/2021-09-06/zfs-is-mysteriously-eating-my-cpu.html Summary A publicación do blog describe unha caza para a causa do misterioso uso de CPU máis alto do esperado. Mostra como estreitar os candidatos ata unha única chamada de función con ferramentas de análise e conclúe cun sorprendente bug de rendemento en ZFS - unha implementación de sistema de ficheiros. Commentary O título en si é cativante, pero entón algo na URL salta a vostede: é por Brendan Gregg, o inventor do gráfico da chama! Este é un gran exemplo de por que a marca persoal importa tanto. Cando vexo "Brendan Gregg", inmediatamente asumo que o artigo é interesante ... e non me equivoco no máis mínimo. Dada a experiencia de Gregg, a análise do problema implicou naturalmente gráficos de chama. A causa raíz é bastante sorprendente, e Gregg describiuno dun xeito moi informal e divertido. O post do blog tamén é moi conciso: unha lectura de tres minutos, aínda que reserve algún tempo de antemán para mirar as capturas de pantalla do gráfico de chama. Demostra claramente que non precisa escribir miles de palabras para espremer en moitos coñecementos, consellos e detalles técnicos interesantes. Ver máis recentes publicacións do blog de "Bug Hunt" en writethat.blog Ver máis recentes “Bug Hunt” blog posts Escribe aquí.blog Escribe aquí.blog 8.4 Characteristics As publicacións do blog de Bug Hunt poden variar tanto como as caza de bugs reais, pero tenden a compartir as seguintes características: Eles contan a historia cronoloxicamente, desde o momento en que o malvado bug se manifestou, ata cando foi declarado morto Concéntranse principalmente na emoción (e dor) da caza Compartirán libremente as evidencias recollidas ao longo da caza para que os lectores poidan poñer os seus sombreiros detectives e xogar xuntos. Están dirixidos principalmente a desenvolvedores expertos que coñecen as tecnoloxías que se discuten (ou están listos para aprender a medida que van) Ofrecen nuggets técnicos que poderían ser interesantes agora, salvando vidas máis tarde Vexamos cada un á súa vez. 8.4.1 Crafted chronologically As publicacións de blog de caza de bugs adoitan seguir unha estrutura específica xa que son o equivalente tecnolóxico das historias detectivas. (Se queres unha introdución ou refresco sobre a estrutura dunha historia detective, a IA xerativa fai un traballo decente aquí). Unha vez que o problema é definido, a caza comeza, xeralmente con algúns intentos fallidos (pero educativos). a tensión constrúe ata que o autor alcanza o seu momento aha, que é seguido pola descrición correcta (e esa sección é habitualmente titulada "The Fix"). 8.4.2 Pesado na caza A parte máis delicada do artigo é o camiño cara a identificar o problema. Pasar ao redor do 80% do post explicando o proceso de investigación é unha boa regra. 85% hunt Chojnowski: 83% hunt Wenger: 83% hunt Kołaczkowski: 82% hunt Javeria: 93% hunt Gregg: 8.3 Evidencias en todas partes As publicacións de blog de caza de bugs adoitan estar cheas de evidencias forenses. Os lectores queren ver gráficos de chamas, números, gráficos, scripts e mostras de código. Isto permítelles entrar nos seus zapatos detectives e tratar de descubrir o enigma antes da gran revelación. For example, here’s some of the evidence shown in the example blog posts: Database monitoring graphs (writes per shard), network and disk performance graphs, CPU stats, flame graphs and instruction-level breakdowns, the CPU’s performance measuring monitoring unit (PMU) events, and a variety of attempted code fixes Chojnowski: Wenger: Tempos de construción de carga, unha liña de tempo de unidades de compilación, gráficos de uso e concorrencia da CPU, información de debug, gráficos de chama, rastrexo a través de Chromium e Perfetto, tentativas de correccións de código, gráficos de dependencia Kołaczkowski: Unha ollada ao deseño da ferramenta de benchmarking, resultados de rendemento (no seu portátil de 4 núcleos vs. un servidor de 24 núcleos), gráficos de chama Javeria: detalles de erro fóra da memoria, probas de presión traseira e múltiples forays no monitor de memoria Gregg: Gráficos de chama (por suposto!), detalles de montaxe de ZFS, arcstats e todo o código fonte, a través dun enlace de GitHub que Os gráficos de chama son particularmente comúns en todas as publicacións de blog de caza de bugs. Ofrecen unha gran forma de visualizar o seu proceso de depuración e perfil de rendemento. E son interactivos - os usuarios poden zoom nas partes interesantes, filtrar só os eventos que coinciden cunha expresión regular particular, e moito máis. Os gráficos de chama poden ser creados a partir da saída de ferramentas populares, como o perfil perfecto de Linux ou o comando gráfico de chama de carga de Rust. 8.4 Expertos amigables Bug hunting articles tend to be expert friendly. The author usually assumes that the audience is proficient (or at least familiar) with the technological stack used in the article. Code samples and scripts shared in the article are typically targeted to readers who are familiar with the programming languages used. These types of posts aren’t conducive to basic explanations of core language concepts; if the reader doesn’t “get it,” they might need to soldier through it or just move on. Isto é claramente diferente que noutros patróns de publicacións de blog, como "Reescribimos en X" (discutido no capítulo 9). publicacións de blog nese patrón son máis axeitadas para aqueles que comezan coa tecnoloxía dada e moitas veces inclúen unha sección "Introdución ao Novo Linguaxe". 8.4 Educación As publicacións de blog seguindo este patrón poden ser bastante educativas para os desenvolvedores máis aló do equipo afectado. A parte carnívora, a identificación de bugs, é abundante en detalles sobre como inspeccionar problemas similares. Máis importante aínda, estas seccións son abundantes en detalles reproducibles: aqueles que son susceptibles de ser útiles para resolver todo tipo de problemas similares que os lectores poderían enfrontarse no futuro. O post de blog serve o seu propósito se deixa ao lector equipado con algúns trucos máis que poden aplicar, só no caso de que atopen un bug similar nalgún momento da súa vida. Por exemplo, aquí está unha visión de alto nivel do que os lectores poderían aprender de cada un dos nosos exemplos de publicacións 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 e 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 Comprobe se alguén (o seu xefe, os avogados do seu xefe) será molestado pola súa transparencia Isto é especialmente importante se perseguiches un bug que tivo un impacto notable nos usuarios - ou se a divulgación deste bug podería afectar negativamente á reputación da túa empresa e / ou ao prezo de accións moi importante. proxectos de código aberto ou de código dispoñible xeralmente non impoñen ningunha consideración legal (agás quizais tentar evitar que o teu código se infecte cunha das licenzas GPL e os seus termos "copyleft"). Antes de publicar fragmentos de código dos seus segredos corporativos moi gardados, asegúrese de que o seu xefe e calquera interesado estean ben con el. Mesmo se salta o código, os seus superiores aínda poden ser aversos a facer certa información pública, especialmente se o bug estaba relacionado coa seguridade, ou rematou cunha infeliz fuga de datos. Use esta regra de polgar: Pregunta primeiro, escriba e publique máis tarde. 8.5.2 Fai un mergullo técnico profundo Os detalles técnicos son unha obriga en calquera, ben, blog post. If your article lacks details like code samples, specs on the exact technology used, step-by-step instructions, etc., many readers will leave unsatisfied. Even worse, they might doubt your integrity. Perhaps the inconvenient bits were deliberately omitted to make the product look better? If you worry that you might be adding too many technical details, err on the side of more. Readers can always skip over them if they don't find them interesting. Técnicas Especialmente se espera que as publicacións de blog de caza de erros estean cargadas con consellos, trucos, código, resultados de referencia, así como ligazóns a repositorios de código aberto e documentación. Se non, roubarás aos lectores a oportunidade divertida de sacar as súas propias conclusións das abundantes evidencias. Como se mencionou anteriormente, é bo ser experto aquí. Pode asumir que o público xa está familiarizado coa tecnoloxía descrita, ou está disposto a capturar (coa axuda da súa publicación no blog). 8.5.3 Sexa brutalmente honesto sobre todos os seus 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. Canto máis dor e sufrimento se describen nos primeiros parágrafos, mellor parece o avance final. Os lectores que loitan con problemas similares van activamente buscar en Internet descricións de problemas similares, polo que todas as palabras clave tristes como "rompido", "culpa" ou "FUBAR" serven a dous propósitos - son unha saída emocional para a frustración do autor, ademais tamén fan que o post do blog sexa máis fácil de atopar en liña. Non trates de transmitir unha caza de bugs perfecta e primitiva. os fins mortos e os intentos fallidos traen toneladas de valor educativo. Os programadores (que é, por suposto, un sinónimo de "grandes mentes") pensan do mesmo xeito. 8.5.4 Inclúe números, índices de referencia, métricas e gráficos de chama Resultados de referencia, métricas e todo tipo de números son o equivalente de pistas e probas do mundo da ficción detective. publicacións de blog de caza de bugs parecen menos lexítimas se usan frases vagas como "o noso sistema agora é moito máis rápido". orgulloso dos resultados, entón terías publicado-los..." As capturas de pantalla das túas métricas (ou aínda mellor, figuras interactivas como gráficos de chama) atraen os ollos dos lectores, facendo o artigo máis credible e máis agradable de ler. Realmente 8.5.5 Non renunciar demasiado, demasiado pronto – manter a tensión construción Para a maioría das publicacións de blog, recomendamos compartir o TL;DR axiña para que os lectores poidan decidir rapidamente se queren continuar. Non aquí! Con publicacións de blog de caza de bugs, evite spoilers a todo custo! A tensión debe ser construída pacientemente ata que ocorra o momento de aha, e a corrección é revelada. Esta é a clave para permitir que os lectores (aqueles que non se apresuran, polo menos) experimenten de forma vicaria a emoción da caza, con todas as súas voltas e voltas. Probablemente xa sospeiten que o artigo remata cun final feliz, porque doutro xeito non sería publicado. 8.5.6 Non faga que os lectores sobrecargados cazen demasiado para a corrección Dito isto, algúns lectores estarán impacientes. Quizais tiñan a súa propia conclusión despois de só uns parágrafos e queren a satisfacción inmediata de confirmar que o conseguiron, inmediatamente, a diferenza do vello estúpido. Quizais este sexa o décimo sexto blog de caza de bugs de Java que atoparon este mes e queren ver se este é outro onde o colector de lixo é finalmente culpable. 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 Engadir puntos de interrupción cando sexa necesario Os artigos de caza de erros poden chegar a ser longos, especialmente se está cubrindo cada pequeno xiro e volta (como debería!) Se acaba escribindo unha publicación de blog que levará máis de 20 minutos ou máis para ler, considere engadir algúns puntos de ruptura claros para os lectores, no caso de que opten por consumir o seu artigo en máis dunha sesión. For example, you could provide a short recap of the progress of the investigation so far. You might add an explicit note that the steps described above led to a dead end, leading to a new thesis. Or you could simply use subheadings like “Phase 3,” subliminally suggesting to the reader that it's fine to take a short coffee break here without losing context. 8.5.8 Non chuches a vida dela Readers aren't here to read an official failure report. The captivating bits are the personal story, the struggle, and the final joy of figuring out what was wrong. The best bug hunting blog posts use an informal conversational tone, and anecdotes are very much welcome. Narra-lo desde o seu punto de vista persoal. Non dubide en compartir o que estaba a pasar pola súa mente como o misterio se desenvolveu. Tamén, rantes son borderline obrigatorios e esperado - en doses razoables, por suposto. En profundidade, a maioría dos humanos gozan de ler sobre as frustracións doutras persoas e sentir o alivio indirecto que non lles pasou a eles (aínda). Os enfoques de "construción de tensión" e "proporcionar acceso completo ás pistas" detallados anteriormente son dúas formas fundamentais de manter os lectores involucrados (si, eles sen vergoña roubado de historias detectives reais).Ademais, pode querer: están 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 Non esqueza agradecer aos que axudaron ao longo da caza The most important reason for publicly acknowledging your collaborators is pure kindness. Bug hunts are among the most infuriating parts of computer programming, and misery loves company. Your collaborators probably made the pain a bit less excruciating; if you appreciate that at all, do thank them here. For the not-so-empathetic folks, there are also pragmatic (read: selfish) reasons for thanking your collaborators. Your acknowledgment could make them more likely to assist in the next bug hunt. Also, if you name someone in a blog post, you can pretty much guarantee that they will read it – and maybe they will even share it. And perhaps someone they know will be the person to start it trending on Hacker News. 8.5 Extensións Sinta-se libre de extrapolar de erros específicos (por exemplo, "O noso código Rust tiña un bug") a cuestións máis xerais (por exemplo, "a biblioteca estándar de Rust fai que sexa fácil de bloquear neste caso de uso particular.") As publicacións de blog de caza de erros tamén son oportunidades para iluminar algúns puntos de dor que ten cunha tecnoloxía particular. Conseguiu atraer un público cativo, interesado no que ten que dicir. Por que non aproveitar iso? Se notou algo particularmente problemático co idioma ou biblioteca que usou, pica a bala e suxire que algo debe ser arranxado. Linguaxe de programación e mantedores de bibliotecas aprecian a crítica construtiva que axuda a mellorar os seus proxectos. 8.6 Resumo Escribir un artigo de caza de bugs serve para compartir coñecementos, aumentar a conciencia sobre os bugs que atopou e mostrar os seus logros Unha publicación de blog de caza de bugs está dirixida a un público técnico, desde expertos a entusiastas, xeralmente asumindo (polo menos) coñecemento intermedio da terminoloxía. As publicacións de blog de caza de bugs adoitan ser pesadas en detalles investigativos, mostrando evidencias técnicas en forma de números, índices de referencia, resultados e 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 *A miña Podes ver máis do libro (Non perdas a túa e Por favor, teña en conta que as palabras se confunden nalgún punto aparentemente arbitrario fóra do noso control. /¯ Páxina web de Manning dirixida por Bryan Cantrill afterword by Scott Hanselman (en galego) que
