← Înapoi la Urmăritori

Cel mai recent articol

Ultima verificare

Urmăritori 0 urmăritori
Articole: 60
  1. An engineering culture that treats test failures as re-runnable "flakes" rather than errors is an engineering culture that will create an inconsistent test suite.

  2. Without fast feedback loops, backfills and data migrations can be some of the slowest work that a team does.

  3. Not tired of the em dash discourse yet?

  4. It's easy to do post-mortems, but it's hard to do them well.

  5. Getting better at your job is satisfying.

  6. ChatGPT Images 2.0 is able to generate a seven-legged spider, but it's not missing the leg I asked for.

  7. Telling a Computer to Do Things

    If you don't know the shell, it's more difficult to tell a computer to do things.

  8. Unless you actually use `vim`, you'll likely want to set both EDITOR and VISUAL to whatever code editor you actually like to use!

  9. The Post-mortem Spectrum

    If you only ever do 'big' post-mortems for gigantic outages, you'll miss good opportunities to learn and improve your systems.

  10. Small Programming Tricks

    A lot of effective engineering comes from the accumulation of small nuggets of knowledge.

  11. You're already running canary servers – servers that validate new code against production traffic – but they might just be called "prod."

  12. this css proves me human

  13. Script Your Code Migrations

    Writing programs to modify code should be a regular part of every engineer's toolkit.

  14. Query planners aren't perfect.

  15. Slow query logs that include the request that caused them, a name that ties them back to the exact location the query comes from, and basic info about the requesting client make improving database performance easy.

  16. A few quick notes on string parameter expansion (`${file/.md/.html}`), adding colors to `printf`, `/tmp` and `mktemp`, and using `awk` for filtering

  17. Store Every Request

    A record of every request that hits your backend is useful for debugging and analysis.

  18. Nano Banana 2 still can't create a seven-legged spider, but the Gemini model at least realizes that it's failed.

  19. Every table needs audit information.

  20. @view-transitions, ::after pseudo elements, counter(), and a few more small techniques that I was happy to discover when building things for this site.

  21. Avoiding literal and optional parameters leads to more readable code, and you should consider turning inlay hints for literal parameter names on if your editor supports them.

  22. How I Review LLM-generated Code

    Code review is essential for getting value out of AI-generated code, which makes trunk-based development, a good diff viewer, LLM review, and opening code locally crucial

  23. You probably don't need `find`

    Between zsh's globbing, Bash's `shopt -s globstar`, and `fd`, you probably can avoid ever using `find`.

  24. LLMs are great at generating code, but writing code helps me think and understand the system I'm building.

  25. Regular expressions with word boundaries, pasting without formatting, and markdown format can occasionally save non-technical writers a teeny bit of work.

  26. Useless shell commands

    Detailed instructions to fix `echo`, abuse HEREDOCs, and use `say` in pipelines.

  27. I'm surprised that MySQL isn't able to come up with a better query plan for queries like `SELECT * FROM X WHERE Y in (a, b) ORDER BY Z LIMIT 10` when there's an index on `(Y, Z)`.

  28. For a query like `WHERE A = ?

  29. You should lint your TODOs

    TODOs are more useful when they have a consistent format!

  30. A good chunk of the coding I've done has been munging data into appropriate shapes.

  31. I found it striking how incapable every AI model I tried was of drawing a spider silhouette missing one leg.

  32. Brownbags shouldn't be lectures

    The basics of good pedagogy—starting with learning goals and incorporating lots of practice—can improve internal company engineer training.

  33. When I haven't tried something, it ends up being a huge barrier towards adding that tool to my toolbox.

  34. Stubs that mutate objects are hard to maintain and can cause hard-to-debug problems for future engineers.

  35. Git is flexible and powerful, but it takes a lot of commands to do most workflows.

  36. Complex numbers can represent vectors in Python in a way that arrays or tuples can't, and they lead to more natural way of structuring 2D data.

  37. Automating things, even when it doesn't save time, is how you learn the skills to automate the things that will.

  38. When writing backend tests, the database is an integral part of what we'd like to test.

  39. Python is a great fit for Advent of Code style problems.

  40. Thinking of B-trees and B+-trees as sorted arrays can help you reason about indexes and performance.

  41. By auto-generating JSDoc comments on a fixture IDs file, we were able to make our fixture code simpler to work with.

  42. Understanding why `zip(*[iter(s)]*n)` chunks an input `s` into `n` chunks is a good excuse to explore iterators, iterable unpacking, list multiplication, and the zip function.

  43. If you have a process ID, you can look at what files/ports a process has open, see details about how the process was started, trace it to see what work it's doing, or wait for it to complete its work.

  44. Containers serving production traffic can sometimes get into bad states that they can't recover from.

  45. How I set up image previews for some posts on this site using automated screenshots.

  46. MySQL 5.7 makes getting a list of numbers pretty tricky, so solutions to FizzBuzz are a fun chance to explore MySQL techniques like session variables, stored routines, and cross-joined views.

  47. How to start an async storage context early in your middleware stack and set up counters to track down problem routes.

  48. Being comfortable using shell tools to do large code migrations is a superpower.

  49. Large analytics SQL queries can be unmaintainable and hard to debug.