标签：#RAM

Every so often a post reminds me that the most dangerous line of code in a system is the one that looks like it could not possibly be wrong. This week's version: calling .lower() on a string can be a security vulnerability. If your first reaction is skepticism, mine was too. Lowercasing is the plumbing of programming. We do it to normalize usernames, compare header names, canonicalize domains, and check things against blocklists. It feels like arithmetic. The problem is that case conversion is not a character-by-character mechanical operation. It is a linguistic one, defined by Unicode, and it has behavior that surprises almost everyone who has not been bitten before. Case is not symmetric, and not always local Two examples that break the mental model. Turkish has a dotless i, and correct locale-aware conversion maps between letters differently than English does, which means "the same" string can lowercase into two different results depending on locale settings. And there are characters outside ASCII whose lowercase form is an ASCII character, meaning a string that contains no k at all can become one that does after normalization. Sit with that second one for a moment, because it is the security-relevant shape. If you validate a string, then normalize it, you have validated something that no longer exists. Your check ran against one value and your system acts on another. That is the classic time-of-check versus time-of-use bug, except the mutation is not caused by an attacker racing you. It is caused by your own normalization call, quietly doing what the spec says it should do. I want to be careful not to overstate the specifics here, since the exact behavior depends on language runtime, Unicode version, and locale configuration. The generalizable lesson is what interests me. The pattern to look for in your own code Anywhere a string travels through this sequence, there is potential for trouble: Accept input. Check it against a rule: an allowlist, a blocklist, a com

I read a short argument this week that tooltips need a delay before they appear, and then, once you are obviously working your way along a toolbar, they need to drop that delay entirely. It is a tiny piece of interface behavior. It stayed with me longer than most architecture posts I read this month. Partly because it is correct, and partly because it is not really about tooltips. It is about the fact that timing is something you design, the same way you design spacing or color. Most teams treat it as a leftover. We pick 200ms because it felt fine on a fast laptop. Or we pick zero because zero seems honest. Or we inherit whatever number shipped inside the component library we installed on day one and never revisit it. Then the product feels twitchy or sluggish, and the bug report says "it feels weird," which is the hardest class of bug there is. Two different users living in the same hands What makes the tooltip case interesting is that a single person switches modes mid-interaction. When my cursor is crossing the screen on its way somewhere else, a tooltip that fires instantly is noise. It flashes, it covers content, it makes the interface feel jumpy for no reason. The delay exists to filter accidental passes. But the moment I stop and read one tooltip, I have declared intent. I am now surveying. If the next four icons each make me wait 500ms, the interface is punishing me for exactly the behavior it was trying to encourage. The delay was a filter for accidents, and I stopped having accidents. So the right behavior is stateful: wait at first, then trust me until I leave the neighborhood. That is the whole insight, and it generalizes further than hover states. The same pattern, wearing other clothes Once you see it, this shape is everywhere: Autocomplete that should debounce while you are typing a word, then feel instant once you have paused and are clearly evaluating results. Confirmation dialogs that make sense the first time you delete something and become a wall

A program can produce the right answer and still contain work that does not help it reach that answer. Tests pass, the output looks correct, and unnecessary computations survive because they appear harmless. This becomes easier to miss in AI-generated code. A model can produce a plausible implementation in seconds, but plausible code often includes variables, conversions, or branches that the requirement never asked for. An intent alignment review adds one question to the usual correctness check: Does every instruction help achieve or explain the stated goal? This does not require a formal proof or an exhaustive line-by-line exercise. The useful result can be concise. Correctness and intent Correctness asks whether the observable behavior matches the specification. Intent alignment looks for code that contributes neither behavior nor useful clarity. The goal is not to produce the fewest possible lines. A named constant or helper function can be worthwhile even when the program could run without it. The concern is accidental complexity: code that suggests requirements or design decisions that do not actually exist. AI can help by reading the requirement and implementation together. It can confirm the working behavior, identify unnecessary instructions, and explain whether those instructions are harmful or simply unhelpful. A small Fibonacci example Consider this specification: The function should print to stdout the first hundred elements of the Fibonacci sequence. The phrase "first hundred" does not specify whether the sequence begins with 0, 1 or 1, 1 . For this review, we assume the intended convention begins with 0, 1 and prints one value per line. def print_fibonacci_100 (): a , b = 0 , 1 sequence_limit = 100 display_width = len ( str ( sequence_limit )) for index in range ( sequence_limit ): current_value = int ( a ) print ( current_value ) a , b = b , a + b checkpoint = ( index + 1 ) % 10 == 0 final_pair = ( a , b ) print_fibonacci_100 () Review The implementa

submitted by /u/yui01 [link] [留言]

Follow-up to my post a couple of weeks ago about a 2.5 GB PCAP that took 6-7 hours to process. Streaming tshark's output into Go got it to 70 minutes, but it was still single-threaded. The most common response here was: why not just add goroutines? Turns out you can't, and the reason is that tshark's dissection is linear state. What it reads in one packet determines how it decodes the next — TCP reassembly, connection tracking, anything under tcp.analysis.* reads and updates shared conversation tables as it goes. Strict ordering isn't a design choice, it's what dissection requires. Goroutines on the consuming side don't help because the bottleneck was never there. So the concurrency has to happen before tshark sees the file. Not by splitting on size — a TCP stream cut mid-conversation loses the state the dissector needs — but by session, so each chunk holds complete conversations and nothing crosses a boundary. Then N tshark processes run in parallel. The detour: I was using PcapSplitter from PcapPlusPlus in connection mode, which holds one output file open per flow. At 95-125 flows it started producing corrupted output. Two distinct failure signatures, reproduced on master and v25.05, on both pcapng and legacy pcap. pcapfix said the source was clean. Reimplemented the split in-process with gopacket and it went away. Honest ending: splitting only triggers above 100k packets, and 3 of the 57 files this pipeline actually handles cross that threshold. Full writeup: https://robinhayer.dev/concurrency-without-a-parallel-parser submitted by /u/Hot_Interest_4915 [link] [留言]

submitted by /u/Swimming_History_432 [link] [留言]

Vibecoding: How to Manage an AI Coder and Not Drown in Spaghetti Code Forget fairy tales about AI doing everything for you at the touch of a button. Without strict control, vibecoding quickly turns into a mess of broken, unmaintainable code. Modern vibecoding isn't blind generation — it is strict architectural supervision . To build real products, you must change your approach to context and redefine your role in the process. Forget Persona Prompting: Context is the Only King of Modern Prompting Fables like "Act as a Senior Developer" were left back in 2023. Modern LLMs don't need roleplay — they need the cleanest, deepest context possible . Why "Persona Prompting" is Outdated AI doesn't start coding better just because you called it a senior dev. It needs concrete technical boundaries. Skip the foreplay and provide the AI with technical specifications: Stack and versions: Not just "React", but React 18, Next.js 14 (App Router), Tailwind CSS . Architectural constraints: Show folder structure, naming conventions, and API response formats. Rule files ( .cursorrules / .clauderules ): Load strict rules into the project that the AI must follow at all times (e.g., "Never use any in TypeScript, write functional components only" ). Humans as Strict Regulators, Not Blind Consumers of Code The biggest danger of vibecoding is shipping AI-generated garbage straight to production without looking. If you blindly consume whatever the AI spits out, your project is doomed. 1. Total Quality Control and Code Review You act as the Technical Regulator and Censor . You never take the AI's word for it. Read every diff : Check exactly what the AI changes. Don't let it rewrite working modules from scratch just to add one button. Don't know how to code? Use basic logic: adding a single button shouldn't make 30 lines of code disappear from main.py or app.js . Force it to justify decisions: If the AI suggests a library, ask: "Why this one over a native solution? Will it impact performance?" 2.

The people who know your AI agent best may be the people least able to see all of its flaws. Not because they are bad engineers. Because they built it. Years ago, when I was taking art classes, my teacher told me something I've never forgotten: “Sara, you can't judge your own art.” I remember thinking, of course I can. 😂 Then she explained. After spending hours looking at the same piece, your eyes get filled with it. You stop seeing what is actually there. You see what you expect to see. I've used that lesson everywhere since. And I think AI agents have the same problem. You designed the requirements. You designed the system. You know why every decision was made. Then you design the evaluation and ask: “Does my agent actually work?” That's where the blind spot can appear. Your evaluation may end up testing the system according to the same assumptions that created it. The evaluator can inherit the system's assumptions Consider a simple requirement: “The agent should answer customer questions accurately.” Seems reasonable. So the team creates an evaluation set with questions that have clear intent and well-defined answers. The agent performs beautifully. 94%. Green dashboard. 🎉 But an external evaluator might ask a different question: What happens when the customer's request has two plausible interpretations? Now you have a different test: “Can I change my billing address?” Does the agent answer immediately? Does it ask which account or address the customer means? Does it make an assumption? The original evaluation may have been technically correct. It just never tested the ambiguity. That is the blind spot. Internal evaluation is still essential This isn't an argument that internal teams shouldn't evaluate their own systems. They absolutely should. The people who built the system understand its requirements, architecture, constraints, tools, and intended behavior better than anyone. That knowledge is extremely valuable when designing evaluations. But it can also crea

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

Your backend framework will outlive your current team. Choose one that the next team can still navigate — here's why .NET has been that framework for Netflix, GitHub, and Stack Overflow for over two decades. Summary Twenty-three years. That's how long .NET has been running in production. Most frameworks from that era got abandoned, forked beyond recognition, or replaced entirely — .NET kept showing up. Netflix still uses it. GitHub uses it. Stack Overflow, which has probably saved more developer careers than any single resource on the internet, runs on ASP.NET. None of these teams are using it out of inertia. They're using it because it works under conditions that expose every weakness in a poorly designed system. This article gets into how .NET actually works, what it gives teams day-to-day, and whether it makes sense for what you're building now. Key Takeaways: One codebase, five platforms — Windows, macOS, Linux, Android, iOS. No rewrites, no platform-specific forks. Three languages, one project — C#, F#, and Visual Basic coexist without forcing a rewrite. The performance tooling ships with it — JIT compiler, AOT compiler, CLR memory management, Garbage Collector. All out of the box. Why Is .NET Still Around? Honestly, this question is worth sitting with for a second — because in software, most things don't survive twenty years. They solve the problem of the moment, get widely adopted before anyone finds the sharp edges, and then get quietly replaced when something newer comes along and the migration pain seems worth it. .NET didn't go that way. Some of that is Microsoft backing — resources, long-term support commitments, a developer community that doesn't dissolve when priorities shift. But backing alone doesn't explain it. Plenty of well-resourced frameworks have died. What actually kept .NET alive is that the foundational architecture held up. The cross-platform capability wasn't duct-taped on in 2020 because everyone suddenly cared about Linux. It was in the

Because "we'll be in touch" is not an observable state. I submitted a job application recently. It...

submitted by /u/rahmanism [link] [留言]

This isn't my main piece for the week, it's more of a "contributes nothing to knowledge" kind of post. Last week I took another look at my portfolio and thought, "Hey, why not make this feel a bit more like me?" So I set out to give it a makeover, stuffed as much of my personality into it as I could, and et voilà, done. The old one was kinda too formal. TL;DR: I gave my portfolio a personality transplant. If you'd rather just look than read: a-thedeveloper.vercel.app Vibe / Tone Option By default, the professional option is enabled. But if you're not too sensitive and want to have a little fun, try toggling over to the unfiltered version of me, lol. I don't actually talk like that in real life anymore, but having grown up speaking English, that's pretty much how I sounded back in my teenage years. I was a grumpy teenager like everyone else, the difference is I was extra grumpy compared to most. 😭 I also lost access to my Instagram account, so all of it is still sitting there, public, for anyone to see. Every day I hope that account just quietly gets deleted. And if you're wondering whether that same energy has been erased, nope, it's still very much here. I just keep it contained to appropriate contexts now, lol. I also found these while digging through my old microsoft drive, weird 16 year old me stuff. I actually said this in a debate, by the way. Can't remember if my team won that one or lost. Weather Options Kinda irrelevant to how it actually describes my portfolio, but I initially wanted to make rainy the only option, because I'm a big fan of dark, gloomy, cloudy weather — the kind that makes England look like heaven to me. 😭 Then I thought, why not just have all of them? So now each weather option comes with its own falling elements based on the selection, plus music that I feel fits the atmosphere. Again, it doesn't really serve any practical purpose, but I think it's a nice little touch to have, haha. DEV Writing Views with an API Key When I joined DEV in 2

submitted by /u/cdb_11 [link] [留言]

As of August 26, 2026, GitHub reports that 398 merged pull requests carry my name on the author line. Twenty nine of those live inside repositories that I own myself, so I removed them from this count on purpose. What remains is the number that actually matters to me: 369 pull requests merged into other people's repositories , across 33 external projects , maintained by strangers who had zero reason to trust my code. Every single one of those 369 merges is real, dated, and linked in this post. Nothing here is rounded up and nothing is claimed without proof. If you want to skip my writing entirely, open the search query in section two and run it yourself. That is the whole point of this article. You should never have to take a stranger's word about their own stats. Jump To Any Section How I Verified These Numbers | The Complete Scoreboard | 2024 The Year Of Volume | 2025 Fewer Pull Requests Higher Quality | 2026 The Year Production Code Got Merged | What 369 Merges Taught Me | Frequently Asked Questions | Where To Find Me How I Verified These Numbers I did not count these by hand. I queried the GitHub search API directly, which means the numbers come from GitHub itself, not from my memory or my ego. You can reproduce everything in this post with one click: https://github.com/search?q=is%3Apr+is%3Amerged+author%3Aaniruddhaadak80&type=pullrequests Or if you have the GitHub CLI installed: gh api -X GET search/issues -f q = "is:pr is:merged author:aniruddhaadak80" That query currently returns 398 results. I then filtered out every repository under my own account, which left exactly 369 external merges. The math is boring on purpose: 398 minus 29 own repository merges equals 369. One more honest number before we go further. I have submitted 918 pull requests in my lifetime so far. That means fewer than half of everything I ever sent got merged. Rejection is not the exception in open source, it is the price of admission, and anyone who shows you a 100 percent merge rate is

The strongest candidate I ever voted no on solved the problem in eleven minutes. Clean. Optimal. Caught the edge case I normally have to hint at twice. Then I opened my notes to write the scorecard and found one line: "Solved it. I have no idea how." That is the short version of why strong engineers fail coding interviews. Not because they can't code. Because nothing they did survived the trip from the room to the scorecard. The interview is not the thing being graded. The document I write forty minutes later is the thing being graded, and you are not in the room when it gets read. TL;DR Strong engineers fail coding interviews mostly on signal density , not correctness. A silent correct answer scores lower than a narrated near-miss. Interviewers score 3-4 rubric axes (problem solving, coding, communication, and for senior roles, judgment) and each axis needs quotable evidence , not vibes. The decision happens in the debrief , where ambiguity defaults to no. "Lean hire" across the board is a rejection at most companies. The most common senior failure is solving a senior problem like a junior : no scoping, no tradeoffs, no failure modes, no tests. Fix it by talking in sentences your interviewer can transcribe verbatim: assumption, tradeoff, complexity, test. What do interviewers actually score in a coding interview? Not "did you get the answer." Almost every structured loop I've been part of scores a fixed rubric, and correctness is one box inside one axis. Here is roughly what the form looks like: Axis What it's really asking What lands on the scorecard Problem solving Did you scope before you built? "Asked whether input fits in memory before choosing an approach." Coding Would this survive code review? "Named things well, extracted a helper, no off-by-one." Communication Could I follow you in real time? "Told me the plan first, then coded the plan." Judgment (senior+) Do you know what breaks in prod? "Unprompted, called out the retry storm risk." Notice what every r

Customizing cell backgrounds in Excel is one of the fastest ways to transform a plain data dump into a professional, scannable report. Whether you need to highlight headers, flag key metrics, or add visual polish to dashboards, the Free Spire.XLS for .NET library makes it easy to apply solid fills , texture patterns , and gradient effects programmatically. In this guide, you'll learn how to implement each style with concise C# examples. Prerequisites Install the library via NuGet Package Manager: Install-Package FreeSpire.XLS Then add the required namespaces to your project: using Spire.Xls ; using System.Drawing ; 1. Solid Fill (Flat Background) The solid fill is the most common background type—ideal for headers, totals, or status-based highlighting. using ( Workbook workbook = new Workbook ()) { Worksheet sheet = workbook . Worksheets [ 0 ]; CellRange cell = sheet . Range [ "B2" ]; cell . Text = "Solid Background" ; // Solid fill requires the pattern to be explicitly set to Solid cell . Style . FillPattern = ExcelPatternType . Solid ; cell . Style . Color = Color . LightGreen ; workbook . SaveToFile ( "CellSolidColor.xlsx" , ExcelVersion . Version2016 ); } ⚠️ Crucial : Always set FillPattern to ExcelPatternType.Solid before assigning a color. If omitted, the color change will be ignored. 2. Texture Fill (Pattern Overlay) Texture fills overlay a repeating pattern (e.g., brick, checker, or angle) over a base color. They're perfect for subtly distinguishing data categories without overwhelming the reader. using ( Workbook workbook = new Workbook ()) { Worksheet sheet = workbook . Worksheets [ 0 ]; CellRange cell = sheet . Range [ "B2" ]; cell . Text = "Texture Background" ; // Angle texture pattern cell . Style . FillPattern = ExcelPatternType . Angle ; cell . Style . Color = Color . LightGray ; // Base background color cell . Style . PatternColor = Color . Beige ; // Pattern overlay color workbook . SaveToFile ( "CellPattern.xlsx" , ExcelVersion . Version2016 ); } N

I built Unicode Text Tools , a free site with a bunch of text converters — superscript, subscript, bubble/circled text, upside-down text, small caps, and more. Type something, get it transformed, copy it out. The whole engine is one dependency-free JS file built entirely from character mapping tables . No AI, no server, no libraries. Here's why that's the right architecture for this class of tool, and how the trickier conversions work. The core idea: it's all just lookup tables Every conversion on the site is a function that maps each input character to a Unicode character (or does a small transform). The simplest cases are pure dictionaries: // Superscript (full a-z, 0-9) var SUP = { a : ' ᵃ ' , b : ' ᵇ ' , c : ' ᶜ ' , d : ' ᵈ ' , e : ' ᵉ ' , f : ' ᶠ ' , g : ' ᵍ ' , h : ' ʰ ' , i : ' ⁱ ' , j : ' ʲ ' , k : ' ᵏ ' , l : ' ˡ ' , m : ' ᵐ ' , n : ' ⁿ ' , o : ' ᵒ ' , p : ' ᵖ ' , q : ' ᵠ ' , r : ' ʳ ' , s : ' ˢ ' , t : ' ᵗ ' , u : ' ᵘ ' , v : ' ᵛ ' , w : ' ʷ ' , x : ' ˣ ' , y : ' ʸ ' , z : ' ᶻ ' , ' 0 ' : ' ⁰ ' , ' 1 ' : ' ¹ ' , ' 2 ' : ' ² ' , ' 3 ' : ' ³ ' , ' 4 ' : ' ⁴ ' , ' 5 ' : ' ⁵ ' , ' 6 ' : ' ⁶ ' , ' 7 ' : ' ⁷ ' , ' 8 ' : ' ⁸ ' , ' 9 ' : ' ⁹ ' , ' + ' : ' ⁺ ' , ' - ' : ' ⁻ ' , ' = ' : ' ⁼ ' , ' ( ' : ' ⁽ ' , ' ) ' : ' ⁾ ' }; The transform itself is trivial — walk the string, look up each char, append the mapped value (or the original char if unmapped). The work is in the tables: knowing which Unicode blocks exist, what's 1:1 reversible, and what's incomplete. The Unicode reality check Here's the thing nobody tells you about Unicode text transformation: the blocks are inconsistent. Superscript : complete for a-z and 0-9 — fully reversible. Subscript : incomplete — there's no subscript b , c , d , f , g , q , w , y , z . If you map an input with those letters, you have to decide what to do with them. Small caps : x has no small-cap form ( ꞯ is the closest, but it's a different character and looks wrong). j is a problem too — the Unicode small-cap ᴊ collides visually

A polished UI can make a product feel completely different, but getting there usually takes more than...

The same zsh script could list ~/Documents when I ran it in Terminal. Started as a LaunchAgent, it failed with: ls: /Users/administrator/Documents: Operation not permitted The LaunchAgent had the same user ID, the same $HOME , and the same script. That combination makes this look like a Unix permission problem. In this test it was not. The useful discriminator was the launch context: access succeeded from Terminal, failed from launchd , and still succeeded for a path outside the protected folder. I reproduced this on macOS 15.6.1 (Darwin 24.6.0) with a LaunchAgent in gui/501 . The probe was removed after the test. Why chmod is the wrong first check The obvious suspects were file ownership, a wrong home directory, or a job running as another user. The probe printed those facts before touching the files: #!/bin/zsh print -- "user= $( id -un ) uid= $( id -u ) " print -- "home= $HOME pwd= $PWD " /bin/ls " $HOME /Documents" 2>&1 | /usr/bin/head -5 /bin/cat " $HOME /Documents/vinh/working/CLAUDE.md" 2>&1 | /usr/bin/head -1 # Negative control: outside Documents /bin/ls " $HOME /.pf004" 2>&1 | /usr/bin/head -5 The two runs produced this difference: Check Terminal LaunchAgent in gui/501 User / uid administrator / 501 administrator / 501 $HOME /Users/administrator /Users/administrator ls ~/Documents Listed entries Operation not permitted cat inside ~/Documents Read the file Operation not permitted ls ~/.pf004 Listed entries Listed entries The working directory differed, but the script used absolute paths under $HOME , so PWD=/ did not explain the denial. The negative control mattered more: the LaunchAgent could read another directory owned by the same user. Changing ownership or mode bits would not explain why only the launch context changed the result. The owning layer is the privacy context On this machine, the access decision was attached to how the process was launched, not just to uid 501. Terminal had a privacy context that allowed access to the user's Documents folder.