DEV Community: Robert Wallace

How to Clean CSV Files Before Importing into Excel

Robert Wallace — Sun, 28 Jun 2026 09:41:33 +0000

Every analyst and developer has been here: you open a CSV export and the headers are a mess — extra spaces, inconsistent casing, random line breaks, and half the columns have names that won’t survive a database import.

Before you start cleaning in Excel, fix the source file. Excel will only make it worse.

Headers are the first thing I normalize. Trim whitespace, convert to lowercase or title case consistently, and replace spaces with underscores or hyphens. Consistent headers prevent JOIN failures, ambiguous column references, and broken analytics queries downstream.

Then remove empty rows and summarize rows. Exports from payment processors, ad platforms, and CRMs often sneak in totals or blank spacer rows. They look fine in a spreadsheet but break scripts and ETL pipelines the moment you automate the import.

Duplicate rows are another silent problem. They don’t always show up visually depending on the viewer, but they inflate metrics and corrupt aggregations. A quick deduplication pass on a stable key column — email, transaction ID, or timestamp + user ID — fixes this before it pollutes your dataset.

The last step is checking encoding. UTF-8 with BOM is the safest default. If your file opens with strange characters or column shifts, it’s almost always an encoding mismatch between the export tool and your target system.

If you’re doing this regularly, a browser-based cleaner that doesn’t upload the file is usually enough for one-off prep. It keeps the data local and avoids the friction of installing a preprocessing script for a single cleanup job.

How to Estimate GPT-4 API Costs Before Building

Robert Wallace — Sun, 28 Jun 2026 09:38:30 +0000

If you’re building an AI feature, the first thing to model is tokens — not model choice. Pricing pages show per-1K-token rates, but they don’t multiply the math for your actual prompt and completion patterns.

The mistake I see most often is estimating from a single “hello world” call. That number is almost always wrong because real usage has three cost layers: input tokens from system prompts, output tokens from model responses, and hidden costs from retries, logging, or repeated calls in loops.

Input cost is usually predictable if you count your system prompt and the average user message length. Output cost is where variance hides — it depends on max response length, temperature settings, and whether your app chains multiple model calls per interaction.

A practical approach before writing any production code: estimate prompt, completion, and training tokens separately. Run the pricing math at your expected daily call volume, then add a 2x buffer for traffic spikes and experimental prompts.

The trap nobody budgets for is long-running costs from prompt caching, context window growth, or feature expansion that quietly increases token counts. Modeling the ranges — minimum, expected, and worst case — before launch prevents the “why is my bill so high” moment later.

If you’re comparing providers or models, build the estimate table once and swap rates. The math is the same regardless of whether you’re using GPT-4, Claude, or another provider — only the per-1K-token numbers change.

How to Fix Messy Markdown from Notion or Obsidian

Robert Wallace — Sun, 28 Jun 2026 09:35:34 +0000

If you’ve ever exported from Notion or Obsidian, you know the pain: extra whitespace everywhere, empty links, inconsistent heading styles, and stray HTML that breaks your site or docs build.

The good news is the content is usually fine. It just needs normalization.

Headings are the first thing I fix. Exports often start with H2 or mix H1 and H2 depending on how the document was structured. Pick a single top-level heading style and normalize everything down to it. Tools that rewrite headings automatically save more time than manually editing each file.

Then I remove empty bullets and blank lines. They look harmless in an editor, but they show up as layout problems in static site generators and markdown linters. Stripping them out before import prevents a lot of downstream noise.

Links are the next cleanup step. Exported docs love to include anchors to nowhere — placeholders, internal cross-references, or empty hrefs. Removing those late is worth it because broken links are harder to spot once the content is staged.

Finally, code fences should have language tags. Obsidian usually preserves them; Notion often drops them. Adding them back makes the content readable in GitHub, dev.to, or any docs renderer.

If you’re pasting a doc into a markdown cleaner, the fastest workflow is: normalize headings, remove empty bullets, strip dead links, then verify the result in a renderer before using it in production.

Container Queries vs Media Queries: When to Use Which

Robert Wallace — Sun, 28 Jun 2026 08:24:44 +0000

I’ve been thinking about this lately: media queries handle page-level layout changes fine, but they fall apart when the same component needs to behave differently depending on where it sits in the DOM.

That’s where container queries change the equation.

Media queries respond to the viewport. Container queries respond to the component’s container size. This matters for reusable design systems: a card component might sit in a 200px sidebar in one place and an 800px grid in another. With media queries alone, you’d need extra classes, wrapper changes, or JavaScript to handle that. Container queries let the component adapt based on its own context.

The practical rule I use: keep media queries for the page shell and major layout tiers. Use container queries inside reusable components that appear in multiple contexts. This keeps the CSS predictable without duplicating component variants.

A few real-world constraints worth knowing:
- Browser support is solid in modern browsers, but older versions still need fallbacks
- Container queries can’t replace media queries for user preferences like prefers-color-scheme or prefers-reduced-motion
- The syntax (cqw, cqh, container-type) takes a few minutes to internalize

If you’re experimenting with container query syntax, it helps to generate query blocks and paste them directly into your components instead of hand-writing each one. Testing a few variations is faster than guessing values in the editor.