Posts

Sentry Error Tracking: Catch Bugs Before Your Users Do

Image
Quick answer Sentry error tracking collects the exceptions your Python app raises in production and groups them into issues you can triage, with the stack trace and how many users were hit. Install sentry-sdk, call sentry_sdk.init() with your project DSN as early as possible, and every unhandled exception is reported automatically. It is worth it once real users can hit errors you never see in development. Your checkout worked on your laptop. It passed review, the tests were green, and the deploy went out on a Friday afternoon. Then a customer writes on Monday that their order failed, and you have nothing to go on. No log line, no stack trace, just a screenshot and a vague description. You open the logs and find a wall of lines, most harmless, while the one line that matters sits buried in the middle. That gap, between an error happening and your team knowing about it, is the whole problem. Sentry closes it by catching the exception the moment it happens and sending you the details. ...
Post a Comment
Read more

OpenTelemetry Python: Trace a Checkout Flow End to End

Image
Quick answer Yes. OpenTelemetry Python adds distributed tracing to a Python service with a few lines of setup: create a tracer provider, attach an exporter, and wrap each step of a request in a span. Each span records a name, timing, and attributes, and spans from one request share a trace id. Start with the console exporter, then switch to a real backend when the traces look right. A customer writes in: checkout took thirty seconds, then failed, and nobody can say where the time went. The order service says the payment call was slow. The payment service says it never saw the request. The logs from both sides exist, but they disagree about what happened first. That is the gap tracing fills. A trace follows one request across every service it touches, giving you one timeline with a name, a duration, and a few facts per step. OpenTelemetry is the shared vocabulary for that timeline, and the Python SDK is the part you wire into your own code. What I would check before using it My firs...
Post a Comment
Read more

LangChain Tutorial: Build Your First LLM App in Python

Image
Quick answer LangChain is a Python framework for building applications powered by large language models, and in current LangChain 1.x you compose those applications with LCEL, the LangChain Expression Language, written as prompt | model | parser. This post builds a working support-ticket triage chain with that pattern, running offline with a stand-in model so you can learn the shape before spending anything on API calls. Picture a support inbox on a Monday morning. Two hundred messages arrived over the weekend: billing questions, outage reports, one customer who cannot check out. Reading each one by hand takes hours, and the urgent ones hide among the routine ones. A language model can read and sort them in seconds, but wiring that into real code means formatting prompts, calling the API, parsing replies, and handling failures. That wiring is the job LangChain is built for, and this post shows it on a small, honest example. What I would check before using it My first check is wheth...
Post a Comment
Read more

pnpm: One Copy of Every Package, Shared Across Projects

Image
Picture a laptop that has hosted a dozen JavaScript projects. The same version of Express sits in a dozen node_modules folders. It works, and on a fast connection nobody notices, until the disk fills up or a CI runner installs everything from scratch on every push. The waste is not dramatic, it is steady: a few minutes here, a few gigabytes there, and a node_modules folder that becomes the biggest thing on the machine. pnpm goes after that waste. It keeps one copy of each package version in a shared store and links it into every project that asks for it. Is that saving worth changing how installs work? Quick answer Yes, pnpm is worth it when several JavaScript projects share the same packages. It keeps one copy of each package version in a shared store and links it into every project, so installs are faster and use less disk space. Its strict node_modules layout also exposes packages the code uses but never declared, which keeps dependency lists honest. What I would check before u...
Post a Comment
Read more

DuckDB: Analytics Queries on a File, Without a Server

Image
A small shop owner exports twelve orders to a CSV file and wants one answer: which city brought in the most money this week? The file sits on a laptop, the data fits in a spreadsheet, and yet getting the answer takes longer than it should. A spreadsheet means wrestling with filters and formulas, and the totals shift every time a row is added. A database server for a file this small is worse: installing, configuring, creating users, all for twelve rows. DuckDB sits in the middle. It is a small analytical database that runs inside your own program, reads the CSV directly, and answers with plain SQL. No server, no setup, no separate process to keep alive. Quick answer Yes, DuckDB can answer analytics questions straight from a CSV file, with no database server to install or run. It reads the file with SQL, so totals, rankings, and revenue per city come from a few queries in a short Python script. The catch is messy data: prices stored as text with a thousands comma, and blank values, nee...
Post a Comment
Read more

tRPC: Your API and Your Client, Sharing One Type

Image
Every team that builds a TypeScript API hits the same frustration. The server changes a field name, or a procedure starts expecting a different argument, and the client keeps calling the old shape. Nothing complains until a user hits the broken page in production. The usual fix is a shared schema file, a code generator, or an OpenAPI document that someone has to remember to regenerate. tRPC takes a different route. It skips the schema file entirely and lets the client import the server router type, so the editor knows exactly which procedures exist and what each one accepts. The question is what it costs in practice, and whether the trade is worth it for a small team. Quick answer Yes, tRPC is worth it when the client and server are both TypeScript and the API is only for your own frontend. It lets the client import the server router type, so the editor knows exactly which procedures exist and what each one accepts, and a renamed field shows up as a red squiggle the same afternoon. T...
Post a Comment
Read more

esbuild: Bundle JavaScript in Milliseconds, Not Seconds

Image
You change one line in a small project, save, and wait. The bundler thinks, the terminal scrolls, and a few seconds pass before the page refreshes. Do that forty times in an afternoon and you have lost several minutes to staring at a spinner, plus the focus you lose every time the flow breaks. Most bundlers are slow because they are written in JavaScript and parse everything with a JavaScript parser. For the language underneath the bundler, see JavaScript Explained: The Language That Runs the Whole Web . esbuild is written in Go, parses in parallel, and treats bundling as a compile step rather than a scripting task. The question is whether that speed is worth changing tools for, and what you give up in return. Quick answer Yes, esbuild is worth switching to when the build is slow enough to notice, because it bundles the shop calculator in 4 milliseconds instead of seconds. It is written in Go and parses in parallel, so two files become one 1.5kb bundle that prints the same receipt as...
Post a Comment
Read more