标签：#Productivity

OpenHabitTracker is a free, open source habit tracker that also holds your notes and tasks. It runs on Windows, Linux, macOS, iOS, Android and in a browser, with no ads and no account. Filtering and sorting habits A habit here is not measured by a streak. It is measured by how much of its interval has gone by. A habit you want to do every ten days, two days late, is at 120%. A habit you want to do every four days, also two days late, is at 150%. Because that is a number, you can filter on a range of it: only habits above 50%, only habits below 150%, or only the ones in between. That last one is everything neither freshly done nor badly overdue. You can sort by it as well, and the sort takes the repeat count into account, so a habit done three times a day and one done weekly are compared against each other rather than the daily ones always sitting on top. There are other ways to sort habits by time: how long you want between repeats, how long it has actually been averaging, how long since the last one, and how much time you have spent on it in total or per completion. Notes and tasks sort by the plain things, category, priority and title, and tasks also by their planned date and duration. Each of the three keeps its own sort order. Filtering by date Tasks have a planned date. Tasks and habits have the dates they were completed on. Both are filtered separately, each before, on, after or not on a date you pick. A filter can also take a number of days from today instead of a date. Minus seven to plus seven is the week either side of now, and it still means that in a month, because the days are counted at the moment you look rather than the moment you set it. Showing what was not done The completed-date filter has a switch next to it. Turned on, the range shows what you finished in those days. Turned off, the same range shows what you did not. Searching notes, tasks and habits Searching a note searches the whole note, not just its title. Searching tasks and habits search

I use WSL2 as my main development environment on Windows. My projects live in Linux: /home/user/Projects/... Node.js, pnpm, Git, Docker, and the rest of my toolchain also run inside WSL. When I started using Google Antigravity IDE, I wanted the same workflow I already had with VS Code: code . Something like: agy . That would have been the obvious command. But agy is already the official Antigravity CLI, so reusing it as a launcher for the Windows IDE would be confusing. So I needed another name. I ended up with: wagy . You can read it as WSL + agy or Windows + agy — both actually describe what it does pretty well. The goal was simple: WSL2 └── ~/Projects/my-project │ │ wagy . ▼ Antigravity IDE on Windows │ └── Remote WSL └── /home/user/Projects/my-project I wanted to launch the Windows Antigravity IDE directly from my WSL terminal, while keeping the project, terminal, and development toolchain inside WSL. Not opening the project through \\wsl.localhost . Not moving the project to C:\ . And ideally, not patching Antigravity every time it gets updated. After a bit of digging, the solution turned out to be quite small. The setup This was tested with: Antigravity IDE 1.107.0 Windows 11 WSL2 Ubuntu zsh Antigravity was installed on Windows under: C:\Users\<user>\AppData\Local\Programs\Antigravity IDE From WSL, that becomes: /mnt/c/Users/<user>/AppData/Local/Programs/Antigravity IDE The missing piece: --remote Antigravity IDE already supports remote targets. From WSL, this works: "/mnt/c/Users/<user>/AppData/Local/Programs/Antigravity IDE/Antigravity IDE.exe" \ --remote "wsl+ $WSL_DISTRO_NAME " \ " $( pwd ) " That was the missing piece. It launches the Windows Antigravity IDE while opening the project through the current WSL distribution. So instead of opening: \\wsl.localhost\Ubuntu\home\user\Projects\my-project the IDE works with the actual WSL environment: /home/user/Projects/my-project This means the integrated terminal can keep using the Linux toolchain: node pnpm git

Design engineers increasingly work across two systems: the visual language of a product and the implementation details that make it usable. Skills for Design Engineers from ibelick focuses on that overlap, packaging practical guidance for building interfaces with stronger visual quality, clearer interaction patterns, and more consistent engineering decisions. The project is attracting attention, with +46 stars today . That momentum makes sense: design-focused AI workflows are moving quickly, but many generated interfaces still need human judgment around spacing, typography, responsive behavior, accessibility, and component reuse. The useful way to approach this project is not as a drop-in framework. Treat it as a reference layer for your development workflow. Read the relevant skill instructions, adapt them to your stack, and keep the resulting guidance close to the codebase so it can be applied consistently during implementation and review. A lightweight local setup might look like this: mkdir -p .ai/skills/design-engineering curl -L https://github.com/sponsors/ibelick \ -o .ai/skills/design-engineering/reference.html For a real team workflow, I would convert the useful parts into a checked-in Markdown file: .ai/ └── skills/ └── design-engineering/ ├── interface-quality.md ├── responsive-layouts.md └── review-checklist.md This keeps the process portable across editors and AI assistants instead of tying it to one tool. It also makes design decisions reviewable in pull requests, which is more valuable than keeping them inside an undocumented prompt. Before using the approach in production, watch for: Context drift: generic design guidance can conflict with an existing design system, so define project-specific tokens and component rules first. AI overconfidence: generated UI still requires manual checks for accessibility, keyboard navigation, mobile behavior, and performance. The strongest ROI comes from using these skills as repeatable engineering standards—not as a

Ever wondered what's happening right now on a beach in Mexico, in Red Square, or at a harbor in Norway? I run Cam-World — a free live webcam aggregator that pulls together 7,000+ public streams from 100+ countries into one searchable place. No registration, no paywall. Here's a tour of what's inside and a few things I learned along the way. 🗺 The world map is the product The heart of the site is a dark globe where every green dot is a live camera. Click a cluster, zoom into a city, open a stream — you never leave the map. Watching it for a while teaches you something: the planet has a rhythm. Webcams go online with the morning sun, and the "online" wave rolls west around the clock. 📊 Honest uptime — you can tell a dead cam from a live one Aggregators usually show you a thumbnail and pray. We check every camera automatically and show a statistics widget: the last 24 hours and 30 days as color-coded slots (online / outage / offline / no data) plus an uptime percentage. The lesson here: webcams are ephemeral. Streams die, hotels turn off cameras, storms break them. Honest stats became our most-loved feature — users check reliability before clicking play. 🔎 Search, cities, collections Search works by name, city, country and tags. There are dedicated hubs for countries and cities, and themed collections: beaches, traffic, mountains, northern lights. 🌙 Small things that matter Dark & light themes (night couch-travel vs daytime browsing), 20 interface languages, "Near me" sorting by distance, live online/offline badges on every card. Try it 🗺 World map — pick a dot, watch live 🔎 Search — find a place you love 🏠 Home feed — a rotating mix of live cameras It's free, works on mobile, and there's always something happening somewhere. What would you check first — a beach, a mountain, or your own hometown square? 👇

The idea Every OS ships a calculator. Every one of them looks the same, feels the same, and disappears from memory the moment you close it. So I built ACALCU v3 — an Akhouri Systems product — a scientific calculator that's absurdly, unnecessarily customizable. Not because a calculator needs 30+ themes and per-button styling, but because it was a fun constraint to design around: how far can you push a "boring" utility app before it becomes something people actually enjoy using? What it does At its core, ACALCU is a standard scientific calculator: basic arithmetic, sin, cos, tan, log, √, π, percentages, and a running expression engine built on Python's math module. On top of that core, it layers: 30+ built-in themes — Royal, Liquid Glass, Wild, Cyberpunk, Dracula, Nord, Solarized, Monokai, Windows 7 / Vista / 10, OneUI 8.0, Matrix, Rose Gold, Galaxy, Fire, Ice, Neon, Vintage, Sakura, Midnight, Forest, Candy, Terminal, Gold Dark, and more. Per-button customization — right-click any button to change its color, font, or set a custom image/video as its background. Every button on the grid is independently styleable. A live "Wild" theme — a small animated plant widget that visibly grows every time you run a calculation. Calculation history — a scrollable dialog of your last 50 calculations. Persistent config — every customization is saved to a local JSON file and reloaded on next launch. Full keyboard support — number keys, operators, Enter/Escape, all mapped to the same input pipeline the buttons use. Architecture The whole thing is a single-file PyQt6 desktop app, structured around a few core pieces: python THEMES = { "DEFAULT": { "app_bg": "#0a0a0a", "display_bg": "#111111", ... }, "ROYAL": { "app_bg": "#0a0800", "display_fg": "#ffd700", ... }, "LIQUID_GLASS": { "app_bg": "transparent", ... , "transparent": True }, # ...30+ more } Each theme is just a dict of colors, font, corner radius, and optional flags (transparent, wild). The Config class resolves the active theme

Can I Afford This? 1. The Story Behind the Code ​Every developer knows the late nights, the stubborn bugs, and the quiet satisfaction of seeing a project finally come to life. For the past few weeks, my world has revolved around a single mission: building ToolVerse. ​ 2. Like many of you, I looked at the current landscape of financial tools—cluttered with intrusive trackers, forced sign-ups, and paywalls—and asked a simple question: What if we could do better? ​ 3. What if people could calculate their debt consolidation, check their ACA health insurance premiums, or map out their tax withholding scenarios instantly, securely, and completely privately right inside their browser? ​ 4. What is ToolVerse? ​ToolVerse is a collection of high-intent, lightning-fast financial decision tools designed for the US audience. It runs on a lean, efficient stack: ​ 5. Frontend & Hosting: Hosted seamlessly on GitHub Pages for blazing-fast load times and global reach. ​ ** Backend Intelligence:** Powered by Vercel server-side API execution to handle complex lookups (like ACA subsidy calculations) securely without storing user data. ​Privacy-First Architecture: No mandatory accounts, no email walls, and zero data selling. Calculations happen right where they belong—on the user's device. **​ The Reality of Solo Building** ​Building this as a solo creator hasn't been a straight line. From battling server-side routing issues to optimizing sitemaps for Google Search Console indexing, every single line of code taught me resilience. There were days when things broke, but seeing those first users land on the platform and find actual value in these tools made every sleepless night worth it. ​ 8. Let's Build Together! ​ToolVerse is growing, and its infrastructure is ready for scale. 9. I am currently looking for: ​Collaborators & Open-Source Contributors who are passionate about building useful, privacy-first web utilities. ​10. Sponsors & API Partners in the US financial and health tech space

Most engineers who stall at a level have the skill. What they don't have is anyone willing to explain the machine they're inside. The explanation you get from your manager is partial by design. They know their part of the process and not the committee's, so what comes back is "keep doing what you're doing, you're close." Which is true, and useless, and then you're close again next cycle. So here is the machine, reconstructed from what the four big companies publish, what their engineers write up afterward, and what levelling aggregators have pieced together. None of it is your company's internal doc. Check the specifics with your own manager. The ladders don't line up Stage Google Meta Amazon Microsoft Apple Typical YOE Entry L3 E3 L4 (SDE I) 59–60 ICT2 0–2 Mid L4 E4 L5 (SDE II) 61–62 ICT3 2–5 Senior L5 E5 L6 (SDE III) 63–64 ICT4 5–8+ Staff L6 E6 L7 (Principal) 65–66 ICT5 8–12+ Senior staff L7 E7 L8 67 ICT6 12+ Principal / Distinguished L8–L9 E8–E9 L10 68–69 Distinguished rare Google's L5 is a senior engineer. Amazon's L5 is a mid-level SDE II. Recruiters map between them and the map is approximate, so the year ranges are typical rather than required. Two things here matter more than the numbers. The gap between adjacent levels is not constant. Entry to mid is mostly about becoming reliable. Mid to senior is about becoming independent. Then senior to staff, which is where the ladder stops behaving like a ladder: it's a change of job, and the things that earned you the last promotion only partly transfer. And every company has a level it considers a perfectly good place to spend a career. Google's L5, Meta's E5, Amazon's SDE II or III depending on who you ask, Microsoft's 63 or 64. Below that level there is an expectation you keep climbing, and at some companies a clock. Above it, promotion is optional and much harder, and nobody will chase you about it. What actually happens in the room The four processes differ enough that optimizing for the wrong one wastes a year

git reset --hard HEAD~3 — run in the wrong repository window, at 6:40pm, immediately followed by the specific kind of silence that happens when you realize what you just did before your brain finishes processing it. Three commits of uncommitted-adjacent work, gone from the working tree in under a second. The first, most important fact: it's very likely still there git reset --hard moves the branch pointer and resets the working tree, but Git doesn't actually delete commit objects just because nothing points at them anymore — they sit in the object database, unreferenced, until garbage collection eventually cleans them up, which for most repos happens rarely enough that "eventually" can mean weeks. git reflog a1b2c3d HEAD@{0}: reset: moving to HEAD~3 e4f5g6h HEAD@{1}: commit: add retry logic to payment webhook 7h8i9j0 HEAD@{2}: commit: fix currency rounding k1l2m3n HEAD@{3}: commit: initial webhook handler The reflog is a local log of everywhere HEAD has pointed recently, and it survives a reset because a reset is just another entry in it, not an erasure of the ones before it. git reset --hard e4f5g6h Working tree restored to exactly the state before the reset, all three commits back, in the time it takes to read this sentence. When the reflog isn't enough If the commits were never made at all — you ran reset --hard on genuinely uncommitted changes — the reflog can't help, because it only tracks where HEAD and branches have pointed, not file contents that were never committed. That's a real loss, and the only real defense against it is committing early and often, including throwaway "wip" commits you intend to squash later, specifically because an uncommitted change has no recovery path at all. If the commits were committed and the reflog entry has expired — Git's default is to keep unreachable reflog entries for 90 days, reachable ones for longer — git fsck --unreachable can sometimes still find dangling commit objects directly: git fsck --unreachable --no-reflog |

1. How this project started? I'm going to be honest, it's been ages since I have written something without the use of AI to fix my writing. English is not my first language so please bear with me! With the rapid rise of AI, I felt that I have been losing passion for what I used to love at some point: learning . Nowadays, we can quickly solve most of our problems with the use of AI, often times, not even reviewing if it correct or not. That's why I decided to take some time daily to learn something new without or minimal use of AI. The first step is deciding, what should I try to learn first? Well, it was quiet easy to find out what. If you are into Linux, you have probably heard of Omarchy at this point. Like it or not, there's no deny that it's getting more popular among developers. So, why not try to build a decent looking Arch workspace? Before continuing, I would like to mention that this is not a guide. There are lot of resources online that teaches you how to install Archlinux and other packages. 2. Why Archlinux? Archlinux has -or had- the reputation of being difficult to get started with. Most of us are used to booting into a nice-looking, functional operating system. Although I have some Linux knowledge, I wanted to have a better understanding of what it takes to have a decent workspace. 3. Installing Archlinux The first step is actually installing Arch on my device. The device I'm going to use is my trusty built PC that I currently use exclusively for gaming. There are a few things to consider before jumping into installing Arch: My PC has an Nvidia RTX 5050 and AMD Ryzen 5 CPU. Need dual boot to switch between Windows 11 and Archlinux. I don't want to change the BIOS options repeatively. With this in mind, I quickly created a bootable USB using RUFUS . 3.1. Booting the USB If you are a Windows 11 user and have dual boot, you may know that Windows requires Windows Secure Boot. In order to boot another operation system, you'll need to change your Secure Boo

A three-year group chat is a knowledge base nobody can read. Somewhere in it is how long the tax office actually took, which form replaced the old one, which accountant people quietly stopped recommending. Telegram's search finds a word you already know. It cannot answer a question. The fix is boring in outline: get the history out, turn it into documents, hand them to something that reads — NotebookLM, in my case. I built that pipeline for real chats. The parsing has traps, and I list them below, but the design problem is elsewhere: packing, and making the second run idempotent. Two clients, two shapes Export exists in exactly two places. Telegram Desktop has had it since 2018 and offers JSON or HTML. The native Telegram for macOS app — the Mac-only client, not Desktop — added Export Chat History… in 12.10 (24 August 2026) and writes HTML only; the Mac App Store build was still on 12.9, without the menu item, at the end of August. Telegram Web and the phone apps have nothing. So you have to read both formats: JSON — one result.json with the chat's name at the root and a messages array: {id, date, from, text, text_entities} per message. HTML — paginated. messages.html , messages2.html , messages3.html , one page per file, each a few MB. text is not a string In the JSON export, a plain message has text: "hello" . A message with a link, a bold run or a code span has an array of runs : "text" : [ "see " , { "type" : "bold" , "text" : "section 4" }, " first" ] String(msg.text) on that gives "[object Object]" in the middle of your document, and it does it silently. Join the runs instead: // Telegram writes a formatted message as // text: ["plain ", {type: "bold", text: "…"}, …] — String() gives "[object Object]". function contentValueToString ( v : unknown ): string { if ( v === undefined || v === null ) return '' ; if ( Array . isArray ( v )) { return v . map (( x ) => x !== null && typeof x === ' object ' && ' text ' in x && typeof ( x as { text : unknown }). text ===

The Comfort Zone Trap Most developers hit a point where they know enough to be productive, and then... stop growing. You can build features, fix bugs, ship code — and still be standing still. The comfort zone doesn't feel like stagnation. It feels like competence. This is one of the sneakiest traps in a dev career. Early on, growth is forced on you — every new project throws unfamiliar problems your way, and you have no choice but to learn. But once you've built a solid mental toolkit (a stack you're comfortable in, a set of patterns that "just work"), it becomes very easy to keep reaching for the same tools on every new problem. You're productive. You're shipping. And you're not actually getting better. The danger is that this plateau is invisible from the inside. Nobody sends you a notification saying "you've stopped growing." You just keep doing what you know, at the same level, for years — until you compare yourself to someone who deliberately kept pushing, and the gap feels much bigger than it should. Why "Just Keep Coding" Doesn't Work The common advice is to just build more projects. But volume without friction doesn't teach you much — repeating the same patterns on new ideas just reinforces what you already know. Growth comes from deliberately picking problems slightly outside your current skill ceiling, not from doing more of what's comfortable. Think about it like weightlifting. If you lift the same weight every session, you get very good at lifting that exact weight — and nothing more. Progressive overload works because you're constantly pushing slightly past your current limit. Coding is the same. If every project you build uses the same stack, the same architecture patterns, and the same problem shapes, you're doing bicep curls with the same 10kg dumbbell for five years straight. The fix isn't "build more" — it's "build harder." Pick a project that forces you to learn a new paradigm (functional if you're used to OOP, distributed systems if you've only b

If you use Cursor or Claude Code heavily, you probably know this workflow: You start a new session, drag and drop a bunch of UI screenshots, architecture diagrams, or heavy project specs into the chat, and tell the AI to look at this. It works, but it causes two massive problems: Token Burn (and Credit Drain): Vision tokens and heavy text files are expensive. You waste your API credits processing those same screenshots and docs every single time you spin up a new chat. Context Clutter: The AI's context window gets clogged. Its logic degrades because it’s carrying all that heavy media and text around in its short term memory. I got tired of burning through my API credits on this daily, so I started looking into the Model Context Protocol (MCP). Why MCP is the answer Instead of dumping static files and images directly into the prompt, MCP allows your AI editor to query a local or remote server only when it needs specific information. Think of it like giving Cursor a direct database connection to your project's assets. It indexes the data once, and the AI retrieves just the pieces it needs to answer your specific coding question. The token savings are ridiculous. How I automated this (Building Dokpod) You can build a local MCP server yourself, but managing the indexing for mixed media (images, video walkthroughs, and text), handling local environments, and keeping connections stable became its own headache. So, I built [Dokpod.io] to automate the entire thing. It acts as an AI knowledge vault. You upload your UI screenshots, video walkthroughs, API docs, and codebase context into Dokpod once. It handles the indexing and gives you a simple MCP connection to plug straight into Cursor or Claude. The result: Zero repetitive uploading for images, videos, or text. Massive reduction in input tokens (saving your credits and limits). The AI actually remembers your UI references and architecture across different coding sessions. I need your technical feedback If you are wrestlin

Every serious agentic coding setup is running a harness right now. Not the model itself, but the machinery around it. The loop it runs in, the tools it can access, the context it receives, and the state it records so the next session doesn't start cold. The tech industry has settled on an equation for this: Agent = Model + Harness , and calls the practice of building the machinery: harness engineering . This post is about the half of the system that equation doesn't cover. Every agentic setup has two workers, and only one of them is a model. The other one is you, the person deciding, across many tasks and many sessions, what all of those agents should build. So the equation has a missing twin. Operator = Human + Harness. On this side, you are the raw capability; on the other, the model. The human harness is the machinery around you. Before we dive in, here are the key takeaways and steps you'll find in this article: What a human harness is, and how it complements the agentic harness Why orienting your work is essential before automating execution The core components that make up a human harness How to build a minimal, effective human harness in practice, complete with a concrete example you can implement in your own workflow What a harness actually is To understand what a harness is in an agentic system, we have to understand it from a physical standpoint. Picture a horse harness. Its purpose is to provide the mechanism needed for a horse to do work by transmitting power that already exists and turning it into useful work. Without it, you have a strong animal and a cart that goes nowhere. Call this the transmission function. Now picture a rock climber harness. This one transmits nothing. Its purpose is to secure the climber to a safe working condition (climbing without falling to the ground). It does this by catching a failed state (losing your grip) and taking a securing/remediating action. Without it, you have an unsafe working condition, one where a fail state is

Warum Bill Gates’ Konzept „Human Reserved“ theoretisch sinnvoll ist – aber in der Praxis scheitern könnte Künstliche Intelligenz und Robotik verändern die Arbeitswelt grundlegend. Bill Gates warnt davor, dass zahlreiche Tätigkeiten in Bereichen wie Recht, Kundenservice, Gesundheitswesen, Softwareentwicklung und Industrie innerhalb des nächsten Jahrzehnts automatisiert werden könnten. Sein vorgeschlagener Gegenentwurf ist das, was er „Human Reserved“ nennt: Bestimmte Aufgaben sollen weiterhin in der Verantwortung von Menschen bleiben, selbst wenn Maschinen technisch in der Lage wären, sie auszuführen. Die Idee ist überzeugend – und zugleich grundlegend problematisch. Die zentrale Herausforderung liegt in der Lücke zwischen menschliche Kontrolle zu verlangen und tatsächlich die Voraussetzungen für eine sinnvolle menschliche Kontrolle zu schaffen. Unternehmen setzen KI vor allem ein, um Arbeit schneller, günstiger und skalierbarer zu machen. Eine echte menschliche Überprüfung erfordert dagegen Zeit, Fachwissen und Geld. Wenn diese Ressourcen nicht bewusst in den Prozess eingebaut werden, kann der Mensch auf kaum mehr als den letzten Klick zur Freigabe reduziert werden. Die betreffende Person bleibt rechtlich oder organisatorisch verantwortlich, versteht die Empfehlung aber möglicherweise nicht mehr gut genug, um sie infrage zu stellen. An diesem Punkt ist der Mensch nicht mehr die letzte Instanz. Er wird zum „Meatproxy“ : einem menschlichen Stellvertreter, der einer Entscheidung formale Legitimität verleiht, obwohl diese Entscheidung faktisch bereits von einer Maschine getroffen wurde. Damit stellt sich die wichtigere Frage: Hat ein Mensch tatsächlich noch die Kontrolle – oder steht ein Mensch lediglich am Ende des Workflows? Der entscheidende Test ist nicht, ob ein Mensch irgendwo im Prozess beteiligt ist. Entscheidend ist, ob diese Person noch über das Wissen, die Zeit, die Befugnis und die praktische Möglichkeit verfügt, eine andere Entscheidung zu treffen. Was mein

Someone plugs in the HDMI cable. The room's display shows nothing, or shows 1024×768, or shows the desktop of whoever presented last week. After a minute of this, somebody says "just share your screen", and out comes AnyDesk or TeamViewer. It works. It is also the wrong shape for the problem, and noticing why turns out to be more interesting than it sounds. What remote desktop tools are actually for AnyDesk, TeamViewer and RustDesk exist to solve one problem well: reach a machine you are not near. Your parent's laptop. A server in a rack. A colleague's desktop three time zones away. Everything about their design follows from that. One person connects to one machine. That person takes the mouse. The remote screen is mirrored to them, and the whole session is framed as control — because when you are not in the room, control is the only way to do anything. Being fair about the privacy question, because it is the claim people reach for first and it is wrong: AnyDesk has a LAN mode , and in it a session goes directly between the two machines without the internet. RustDesk can be self-hosted entirely on your own infrastructure. Neither of these tools forces your screen through somebody's cloud if you configure them not to. If you have read that they do, that is not accurate. The mismatch is not privacy. It is shape. The relay, the account and the NAT traversal are not overhead — they are the product, and they are what makes reaching a machine in another country possible at all. Standing beside the machine, you pay for all three and use none of them. Where the shape stops fitting Stand in a room with four people and a Mac, and three things go wrong at once. It is one-to-one. Remote desktop is a session between two endpoints. Four people looking at one screen is not what it models, so three of them read over a shoulder. It mirrors, and mirroring is sometimes the wrong answer. Every tool in this category shows a screen that already exists. But the meeting-room problem is oft

I keep noticing the same moment in conversations: someone has a decision in front of them, but what they really want is a little space to think. “Should I move?” “Is it time to change jobs?” “Should I take this relationship more seriously?” A pros-and-cons list can help. So can talking to a friend. But sometimes the question stays unresolved because the hard part is not finding more information. It is finding a clear way to look at the information we already have. That is why I built Yi Ask: https://diluowei.com/?lang=en The product flow in one view: ask a focused question, pause with it, and reflect on a structured result. The experience starts with one focused question, not a long form. The idea Yi Ask is a small web app inspired by the I Ching and Meihua Yishu. A user writes one focused yes-or-no question, then selects two numbers through a slow, circular interaction. The selection creates the upper and lower trigrams, while the current traditional time is used for the changing hexagram. The result is deliberately structured: a directional answer: move forward, pause, or proceed carefully the conditions that support a positive decision signs that suggest waiting or checking more carefully one practical next step The goal is not to predict the future or pretend that a symbolic system can remove uncertainty. It is to help turn a vague feeling into a question with a direction. Why the interaction is slow The number selection is the most important part of the experience. A fast random button would be easier to build, but it would not create the right moment for the user. The interface cycles gently through the eight trigrams. The user stops it twice, once for each trigram. That small pause gives them a chance to keep the question in mind instead of immediately asking a different question every few seconds. It is a tiny interaction, but it changes the mood from “generate an answer” to “take a moment with the question.” The number selection is designed as a pause, not

A portfolio website should make it easy for a potential client to answer three questions: What do you...

My hot take is: Telling people that they have to build endlessly is very, very, very bad advice. If...

I spend long hours working on a computer, and one simple thing I regularly forget is drinking enough water. Most hydration apps rely on notifications. The problem? Notifications are very easy to dismiss. So I started building Hydration Buddy : a lightweight Windows app designed to stay visible without constantly interrupting your workflow. What it does Tracks daily water intake Shows your daily hydration progress Gives gentle reminders Lets you quickly log water Includes a small floating companion that stays on screen Keeps the experience lightweight and simple Why I built it The idea wasn't to build another notification app. I wanted something that could quietly stay present while I'm coding or working and make the habit harder to forget. Hydration Buddy is currently in beta, so I'm still testing the experience and improving it based on real user feedback. 🎁 The first 25 beta users get free lifetime access. You can try it here: https://hydrationbuddy.patelmahek.in/ If you test it, I'd especially love feedback on: The floating companion Reminder experience Ease of logging water Features you'd like to see next I'm building this in public, so I'll also share some of the technical decisions, mistakes, and improvements as the product evolves.

developer context switching security DevSecOps flow state developer velocity security alerts batch security patching ROI cost of context switching developer productivity security security alert fatigue developer cognitive load ad-hoc security patching interrupting developer flow engineering vp productivity metrics DevSecOps velocity context switching recovery time 23 minute recovery context switch batching security alerts SLA-backed fix campaigns security SLA for developers minimizing context switching feature delivery vs security developer experience DevSecOps The Real Cost of Context Switching What Security Alerts Actually Do to Developer Flow Back to blog What interruptions actually cost Is it worse for developers specifically? The research says probably yes The alert volume isn't imaginary — but be careful which numbers you cite The fix: batch the routine work, protect the calendar The important exception: not everything can wait for the batch A more honest way to estimate the ROI The takeaway Sources The Real Cost of Context Switching: What Security Alerts Actually Do to Developer Flow Companies keep investing in better frameworks, tighter deployment gates, and broader platform suites — and feature delivery keeps getting slower anyway. For engineering leaders trying to explain that paradox to the board, the usual suspects (headcount, tooling, talent) rarely hold up. The more useful place to look is something less visible: how often developers get pulled out of what they're doing, and what it costs them to get back in. As "shift-left" security practices spread, developers absorb a steady stream of vulnerability alerts, automated pull-request comments, and one-off Jira tickets throughout the day. The goal — a more secure codebase — is the right one. The delivery mechanism is often the problem. Scattering fixes across random moments in the workday erodes productivity without necessarily making the codebase safer any faster. The alternative a growing number of engi