标签：#disc

In remote software demos, the biggest problem is not always the product itself. Sometimes the audience simply doesn’t know where to look. A button may be visible. A setting may already be on screen. The presenter may be explaining everything correctly. But if attention isn’t directed clearly, people can still get lost. After doing a lot of screen sharing and software demos, I kept noticing the same small UX problems. 1. The cursor is visible, but not necessarily noticeable When you're presenting your own screen, you always know where your pointer is. The audience doesn’t. On a large monitor, a compressed video call, or a busy application UI, the pointer can easily disappear visually even though it is technically visible. This becomes especially obvious when you say something like: “If you look over here…” You know exactly what “here” means. The audience may need another second or two to find it. That delay sounds minor, but during a demo it can happen again and again. A presenter moves on to the next step while part of the audience is still trying to locate the previous one. 2. Moving the pointer is not the same as directing attention A common workaround is to move the mouse around whatever you want people to notice. I’ve done this many times myself. Circle the button with the cursor. Move back and forth over a chart. Quickly point between two settings. It works, but it also adds visual noise. Eventually I realized there are really two different actions happening: Navigation — using the mouse to operate the software. Attention — telling the audience where to look. During a demo, those aren’t always the same thing. Sometimes I don’t want to click anything or change the interface. I just want to say: Look here. 3. Highlighting something can interrupt the demo There are plenty of powerful screen annotation tools available. They make sense when you want to draw arrows, write notes, add shapes, or explain something in detail. But during a live product demo, switching int

Last post, I said "the book is under review." Now the paperback is live. The Kindle edition is...

Every hackathon has the same 90-second moment of dread: someone hands you a codebase you've never seen, and you have to make sense of it before the clock runs out. File trees don't help. grep doesn't help. You waste the first 30–60 minutes reading the wrong files, missing a hidden dependency, and stepping straight into a production trap nobody warned you about. In other words: before writing code, you spend half your time trying to figure out where the hell the code is. The idea wasn't "AI that writes your code." It was "AI that tells you where to look before you write it." For InnovaHack Chapter-1, my team built Waypoint — a dev onboarding platform. Point it at any GitHub repo or a local folder, describe a task like "Add a new global configuration flag to app.set()", and instead of you reading the whole codebase to figure out where that even goes, it hands you a Mission Brief : exactly which files you'll touch, the traps waiting in them, what to learn first, and the order to do it in. Waypoint made the Top 50 — one of the 50 chosen to advance to Round 2. Here's how it actually works under the hood, what it took to build, what's next for it — and since I don't believe in only posting the highlight reel, what happened after we placed that made us walk away from the next round. The problem: the cold-start tax Every time a developer joins a new codebase, or picks up an unfamiliar task in one they already know, there's a tax paid in wrong files read, missed dependencies, and traps hit blind. For me, that moment came when I wanted to contribute to Forem — the open-source project that actually powers DEV. I didn't know a line of Ruby on Rails, and between learning the language, understanding the framework, and preparing for interviews, I didn't have the time to read an entire unfamiliar codebase just to figure out where one feature belonged. I never ended up making that contribution. But the problem stuck with me. It's also a pattern for our team more broadly: we delibera

Recently, I built a mobile app with Expo; everything worked well with the development build on a simulator and a real device. Yet when I published the app to test the production build on a real device, it crashed without any explanation. With the crash, I had to get the crash report from Apple and download it to read it and try to understand the issue, yet even with that, I did not find any details that could help me, so I did what any normal guy during this age can do, I gave my code base to claude code and the crash report to anaylze them and tell me the issue. Guess what happened here? It hallucinated! Reading Claude's output made me feel I wasn't going in the right direction; for that reason, I had to go the old way: Stack Overflow and Reddit. Going to read the issues there helped me with three main extra things that AI does not provide: Knowing what other people tried: When I go to Stack Overflow or Reddit , I read the question, the thread, and other people's comments, even if it's not the correct one; this helps me get context, grasp the idea, and even learn some historical data about the issue. That might be the one I am facing. Sense of community: When I read other people's struggles and experiences, it gives me the feeling that I am not alone- not just me and a machine trying to prompt it to work- and it makes me feel that I belong to something bigger. It helps me keep up, not get frustrated, and feel that it's me who cannot solve issues with AI. Slow learning: Our brain does not remember the information when you read it once and forget it; we learn when we put effort and push the limits of our brain. With AI, this is getting easier by sending the question directly and getting the answer, so we forget even the issue if we face it again (spoiler alert: I had this exact issue a few months ago and forgot about it). That's why slow reading and similar methods help keep our brains alive and help us improve. With this, I am not saying to fully remove AI and not t

I'm part of an awesome community where senior devs, product managers, founders, and experienced folks from different domains discuss how they use AI and automation tools to boost productivity — without sacrificing real learning. The group is a goldmine . Tool recommendations. Automation workflows. Latest trends. Migration war stories. I've learned more from this group than from most tutorials. Last week, I needed to find something specific about running local LLMs. I searched with keywords. I scrolled. I found a whole lot of messages — but none of them answered my question directly. I still had to manually read through dozens of messages , open the links they shared, and try to piece together the context myself. It took me over an hour, and I wasn't even sure I'd found everything. Someone might say: "Just Google it." Or "Ask an LLM." But that defeats the purpose. The value here isn't just information — it's the context . The "this library is a game changer" comment only makes sense if you know what the person was working on before, and who else agreed or disagreed. That context is lost in scrollback. And I'm tired of trying to keep it all in my head . I've seen people send important links to themselves on WhatsApp. But that becomes a messy pile with no structure. No connections. No way to see how one message relates to another. So I'm curious: How do you deal with this? Have you lost important knowledge in group chats? Do you have a system for recovering it? Or are you also just scrolling endlessly? I have an idea I'm working on. But I'd love to hear your approaches first. Drop your thoughts in the comments — I'll document what I learn .

1. Crypto & Security Tools Crucial for authentication setup, payload verification, and security testing. JWT Parser / Decoder: Decodes JSON Web Tokens ( Header , Payload , and Signature ) without transmitting secret keys over the internet. Token & Password Generator: Generates cryptographically secure random passwords and API tokens with customizable character sets, lengths, and complexity rules. Hash Text Generator: Computes cryptographic hashes (MD5, SHA-1, SHA-256, SHA-512) for strings to verify integrity or check signature matching. Bcrypt Hash / Verifier: Hashes plain-text passwords or checks plain text against an existing hash using the bcrypt algorithm. UUID / ULID Generator: Creates universally unique identifiers (v4 UUIDs) or time-sortable lexicographically sortable unique identifiers (ULIDs). BIP39 Mnemonic Generator: Generates seed phrases and cryptographic keys used in wallet initialization and HD key generation. RSA Key Pair Generator: Generates public and private RSA key pairs directly in the browser for local testing of asymmetric encryption systems. Basic Auth Generator: Quickly constructs Authorization: Basic <base64> HTTP header credentials from a username and password. 2. Formatters & Prettifiers (Development) Saves hours when dealing with messy logs, API responses, or raw system configurations. JSON Prettify & Minify: Formats unformatted API JSON strings with customizable indentation or compresses them into a single line to reduce payload sizes. JSON Diff: Highlights additions, deletions, and structural changes between two JSON payloads. SQL Prettify: Formats raw SQL queries into clean, readable multi-line statements with capitalized keywords. YAML / XML Formatter: Cleans up indentation, validates structure, and formats raw XML and YAML files. Docker Run to Docker Compose: Translates single CLI flags ( docker run -d -p 80:80 ... ) into a structured docker-compose.yml file. Cron Expression Generator & Parser: Provides human-readable schedules from

Last month my WhatsApp stack moved 89,479 messages. I got no invoice for any of them. That is not a brag, it is the setup for an honest accounting. Because "self-hosting is cheaper" is the least interesting sentence in infrastructure, and it is usually said by someone who has never been paged at 7am by a bot that went quiet at 2am. I want to put a real number on both sides of that trade: the money Twilio would have charged, and the money self-hosting quietly takes back. All the numbers below were pulled or fetched on August 27, 2026 . The rate cards move quarterly, so check yours. The traffic, measured rather than estimated Five WhatsApp inboxes, bridged from WAHA into a self-hosted Chatwoot. Thirty days: messages Total 89,479 Inbound (from users) 45,563 Outbound (from us) 43,916 Most benchmarks stop here, multiply by a per-message rate, and publish. That answer is wrong, because Meta does not charge per message. It charges per template sent outside an open customer service window. Multiplying my full 89,479 by a template rate overstates the Meta line by about 3x. Multiplying just the outbound half still overstates it by about 1.5x. Since November 1, 2024 non-template messages are free. Since July 1, 2025 utility templates answering a user inside an open 24-hour window are also free. So the only line that costs money is the outbound message that goes out when nobody has written to you in the last day. Which means the number you actually need is not "how many messages," it is "how many outbound messages had no inbound message from that contact in the preceding 24 hours." The query that produces the real bill Here it is against Chatwoot's schema. It uses a window function rather than a correlated NOT EXISTS , because on a messages table of any size the correlated version will happily eat your connection pool. WITH src AS ( SELECT m . conversation_id , m . created_at , m . message_type FROM messages m WHERE m . inbox_id IN ( 27 , 23 , 46 , 50 , 48 ) -- your WhatsApp in

Keep the beams standing. Replace what they carry. — The 36 Stratagems, Replace the beams with rotten...

I Started Building a Discord Server Directory I’ve spent a lot of time around Discord communities, and one thing has always bothered me. Finding a good Discord server is harder than it should be. There are thousands of communities for gaming, anime, roleplay, technology, social groups and pretty much every niche you can think of. But finding the right one usually means jumping between invite links, old posts, server lists and search results. At some point I thought, why not build a better way to discover them? That’s how I started working on Dizord. The first version was pretty simple. I wanted a place where a server could be listed, people could discover it, and everything could be organized around interests instead of just one giant list of servers. Then the project started getting bigger. More servers meant more categories and tags. More tags meant better search and filtering. Server information changes constantly, so keeping listings updated became another problem to solve. I’m building the backend with Laravel and working with the Discord API to handle server information and synchronization. There are also a lot of small things behind the scenes that aren't obvious when you simply open a server listing page. One of the things I'm currently working on is making discovery better for smaller communities. A server shouldn't need tens of thousands of members just to be discoverable. The goal is pretty simple: Make it easier to find a Discord community you'll actually want to stay in. The project is still evolving, but the current version is live: https://dizord.com I'm still experimenting with search, categorization, server activity and ways to make a large directory useful instead of overwhelming. If you're building a directory, marketplace, or any project with thousands of constantly changing pages, I'd also be interested in hearing how you handle discovery and indexing at scale.

Introducing AI Disclosure on DEV: Tools for Nuance, Clarity, and Better Feeds Author leads by example using the new tag Ben Halpern Ben Halpern Ben Halpern Follow for The DEV Team Aug 26 Introducing AI Disclosure on DEV: Tools for Nuance, Clarity, and Better Feeds # showdev # announcements # ai # community 49 reactions 3 comments 3 min read

Two weeks ago I counted 204 guards in my repos and found that 89 % had never been shown they can...

Claude Code is amazing. It feels like cheating in the best way until it doesn't. The first time I dropped a vague comment and it gave me a fully working component, I was hooked. But somewhere along the way, I realized something weird was happening: I was coding less... and thinking less. Let’s talk about that. The Tools Got Better, But We Got Lazier In 2022, you still had to know stuff . Now? You just prompt your way through half the job. And sure, productivity skyrocketed. Ship faster, write fewer tests, scaffold full APIs in a couple of minutes. But here’s the tradeoff no one likes to talk about: we’re outsourcing thinking . Not tasks. Not code. Thinking. I've seen teammates slowly stop debugging on their own. They just throw the stack trace into Claude. I’ve seen people stop learning the fundamentals of async behavior or memory handling because “Claude will tell me.” Cool. Until Claude gives you a bad answer and you don’t realize it because you stopped building your intuition. The Industry’s Not the Same The layoffs? Brutal. And the worst part isn’t just losing a job it’s realizing you didn’t build portable skills . Because if Claude wrote all your code at your last job, what exactly did you learn? When companies trimmed down, they didn’t just cut bodies. They cut noise. They kept the people who could solve problems , not the ones who could Google fast or write perfect prompts. So ask yourself: if Claude disappeared tomorrow, could you still contribute? Using AI ≠ Being a Great Engineer I’m not anti-AI. I use Claude. I use Cursor. I use Copilot. But I don’t depend on them. There’s a difference between boosting productivity and becoming a prompt monkey. The first one makes you valuable. The second one… doesn’t. Let’s get real: code was never the point. It was always about solving problems, navigating ambiguity, simplifying complex systems, designing clean architecture. None of that goes away with AI. In fact, it becomes more important. The Skills You’ll Regret Not

"Most" Xbox One and Series X games are compatible; discs will still work after being claimed.

Debian is polling its developers on how to handle AI-assisted contributions, with options that range from broadly permitting them to banning them outright. Whatever the outcome, I think this is one of the more consequential governance conversations in open source right now, and not for the reason the headlines suggest. The framing everyone reaches for is philosophical. Is generated code authored? Is it derivative? Does using a model make you less of a contributor? Those are real questions and I do not have confident answers to them. But if I imagine actually being a Debian maintainer, my problem is not philosophical at all. It is that my queue is full and my reviewing hours are finite. The bottleneck was never writing code Volunteer projects have always been constrained by review capacity, not by supply of patches. The scarce resource is someone knowledgeable enough to say "this is correct, this fits our conventions, I will own the consequences if it breaks." Assistants change the ratio between those two things dramatically. The cost of producing a plausible patch has fallen much faster than the cost of evaluating one. That asymmetry is the whole story. A project can absorb a lot of contributors when each contributor's output is roughly proportional to their understanding. It struggles when someone can submit a large, fluent, superficially reasonable change to a subsystem they have never read. I want to be careful here: plenty of experienced maintainers use these tools well, and their patches are better for it. The failure mode is not the tool. It is the decoupling of confidence from comprehension. Why detection is the wrong axis A ban sounds like a clean answer, and I understand the appeal. But I am skeptical it can be enforced in a way that means anything. You cannot reliably detect generated code, especially after a human has edited it, and especially for the kind of small idiomatic patch that makes up most of a distribution's traffic. A rule you cannot enforce d

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

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

2024 was the year AI was everywhere. The ads, the praise, the feeling that something had already been decided without me. I am in my fifties. I had to decide whether to watch or take part. I decided to take part. I started with VS Code, on a paid plan. I did not have to think about what to build. Something had been sitting in my head for years: an automated trading system. I have lived fifty years, and while raising children the money got tighter, not looser. Financial freedom was moving away from me, not toward me. So I wanted to make money with automated trading. I think the idea first arrived in my mid-forties. That is why the decision to take part came so quickly. Whatever I said out loud would simply get built. That was the hope I walked in on. I do not really know how to code. But the AI would handle that part, so I trusted it. Where the illusion first cracked A year inside VS Code taught me that two names mattered: GPT and Claude. I used them in turn. I used them one at a time. Two problems. First, even on a paid plan the usage ran out fast. Faster than I expected. The road ahead was long and I was sitting still, waiting for a quota to reset. The second one was worse. The explanations were excellent. The results were not. That is where the illusion cracked for the first time. I still could not let go, so I paid for more. Adding Cursor bought me some headroom. And a different problem showed up immediately. Switch the model and it wants to start over Change the model, and it wants to rewrite everything from the beginning. Handed code written by a different AI, it would rather replace the whole thing than edit it. That is when I understood that switching AI mid-project is a bad idea. Everyone talks about pricing. Almost nobody talks about this one. And this is the one that actually held me back. I spent a lot of time fighting the tool. In the end I paid for Claude's hundred-dollar plan, and from then on I worked with Claude. What I gained: the job nobody wanted

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

I just started a blog and published my first blog post about Logical Volume Management. I'm new to documenting my work, so I'd really appreciate any feedback on the content, clarity, or writing style in general. This site is a mix of a blog and a portfolio. Since I'm new to all of this, it would be great to get some feedback on whether this post works well just as a blog post, or if it actually holds up as a portfolio project too, before I keep writing more. www.mvtechblog.com Thanks in advance.