标签：#showdev

a local, Claude-powered brain-assistant for solopreneurs I kept losing good ideas — not because I forgot to write them down, but because nothing ever went back and connected them. A task on Monday, an idea on Wednesday that was secretly the same problem, a question on Friday that contradicted something I'd decided two weeks earlier. All of it just... sat there. So I built Dot Connector : a small local app where every capture is a "dot," and every few captures, Claude reviews the stream against a standing memory and surfaces three things — non-obvious connections between notes, contradictions with what you said before, and open loops you haven't closed yet. The architecture is deliberately simple. It's Express + vanilla JS, no build step, no account system. Every capture gets a cheap, fast Claude call for auto-tagging. Every 3rd capture triggers a deeper "sweep" — a second Claude call that looks at recent captures alongside standing memory and open loops, and returns structured updates: new memory facts, dot-connects, contradictions, and open-loop resolutions. Why local-first. no server of my own, notes never leave your machine except the direct calls to Anthropic's API, bring-your-own API key so there's no subscription — you pay Anthropic directly, typically well under $1/month for personal use.] Its just a steal one-time $29 download All info and download get it here: https://dot-connector.eu

A week ago I put a rough, honestly-a-bit-thin version of PulseWatch in front of real people for the first time. Within days, two different strangers — independently, unprompted — found two real gaps in it. Neither was catastrophic. Both were exactly the kind of thing you only find by watching someone else use the thing you built. This is the story of both, and the fixes. Bug one: the run that never ends This first bug came from a friend testing it on a real script. His question was simple: "What happens if start fires twice before end ?" Good question. At the time: nothing good. Here's why. PulseWatch works on two pings — a job calls /start when it begins and /success (or /fail ) when it's done. The server tracks whichever run is currently "open" for a monitor. The bug: if a job's process restarts mid-run — a crash-and-retry, a redeploy that catches it mid-flight, a scheduler firing twice — you get a second /start before the first run ever closes. The old run just sits there, open forever, an orphan with no ending. Worse, because the watchdog was still waiting on that run's expected finish time, it could fire a false "still running" alert for a run that was, for all practical purposes, dead and abandoned. The fix is a small rule with an outsized effect: a new /start supersedes whatever run is currently open. The old run gets marked superseded — a terminal, non-alerting status — and a fresh run begins clean. The watchdog was updated to treat superseded as a dead end: nothing to wait on, nothing to alert about, and it never shows up in a user's run history. It's not a failure and it's not a success. It's just "this run doesn't matter anymore, a newer one replaced it." The logic, roughly: def handle_start ( monitor ): open_run = monitor . get_open_run () if open_run is not None : open_run . status = " superseded " open_run . finished_at = now () new_run = Run ( monitor = monitor , status = " running " , started_at = now ()) db . session . add ( new_run ) db . session .

This is the next big thing! I've been working on Moonlight AI for almost 6 months now and today I have big news. Automated Applications . That's right, Moonlight AI will have automated applications for the 2.0 version! What is Moonlight AI? Moonlight AI at first, was a project that was aimed to compete with Upwork. That definitely didn't work out even at the development phase so I had to pivot to another project. A month after the conception of the original version, I met a potential co-founder for a new initiative. Moonlight has been repurposed to be a capabilities mapping engine based on worker experience. We used a resume parser and a local LLM to map the capabiities based on skills and job experience alongside Github integration to use as proof of work. The project ultimately didn't work out, the potential cofounder was MIA so my only recourse was to rewrite Moonlight AI to be another thing, which ended up being a glorified job board which is how it works now. The Development Process Moonlight AI was vibe-coded in a night. Modifications were done the same way with different LLM models. LLMs today are what I call an automated entry-level developer since juniors is the wrong term because juniors at least have from 1-3 years of experience in the professional landscape and are more than just coding monkeys, where as entry-levels are just that, developers with 0 years of experience. Today, Moonlight AI should be done the correct way: reading the code and writing it too. Why let an LLM to do my job as well as think for me? DO YOU WANT ME TO GET ALZHEIMER? BECAUSE THAT'S HOW YOU GET ALZHEIMER! Anyways, exercising the mind is very important, that's what make us humans. People today have an obsession with automating their lives completely and end up like the humans in WALL-E. End of rant. The Future (Conclusion) I don't know the future, but I envision Moonlight AI to be a tool to make unemployed people lives a little less unbearable. I know how frustrating is to use a jo

Hi everyone! I’m a developer at the beginning of my journey, and I’ve just finished working on a small project that brought me a lot of joy: Capybara Game. It’s a cute game where you feed your capybara and improve her happiness level. You can choose between 5 different types of food or pick your own snack. If the capybara likes the snack, her happiness level rises; if she doesn't like it, the happiness level falls. Your progress is saved automatically. Keep in mind that your capybara gets hungry over time, so make sure to check back and feed her regularly! I went for a minimalist, cozy design. The interface is clean and intuitive, focusing on a relaxing user experience that lets the player focus entirely on the capybara. I built this project using HTML, CSS, and JavaScript. Hope you're interested in playing! You can do it here: Play the game here I’d love to hear your thoughts! If you have any ideas for new features or if you find any bugs, feel free to let me know in the comments.

What happens when you stop writing controllers, services, repositories and mappers - and let PostgreSQL be the backend. MIT-licensed, and yes, I built it. Full disclosure right away: I built the thing I'm about to show you. It's called NpgsqlRest , it's MIT-licensed, there is no paid tier, no telemetry, no "book a demo" button. I'm just a guy who spent two years deleting layers from his stack and now wants to show someone the hole where the backend used to be. The standard pattern The standard data access pattern for modern business applications looks like this: UI → Fetch → Controller → Service → Repository → ORM → SQL → Database Seven arrows. And if you look closely at what most of those layers actually do - they take data from one side and pass it to the other side, slightly renamed. The Controller maps the request to a DTO. The Service passes it to the Repository. The Repository asks the ORM nicely. The ORM generates SQL that you then inspect in a log because you don't trust it (correctly). We built entire careers on maintaining this pipeline. I know because I did, for decades. But once you realize database-aware tests are trivial to wire up, you can drop the Repository. Once you get good at SQL, you can drop the ORM. And then you look at the Controller and realize it's just boring glue code that ships bytes between HTTP and the database. Glue code can be automated. So: UI → Database That's it. That's the architecture. Show me or it didn't happen Fine. This is a file called users.sql . Not a function, not a stored procedure - a plain SQL file sitting in your repo: /* HTTP GET /users/ @authorize admin, user @cached @cache_expires_in 30sec @timeout 5min @param $1 department_id text */ select id , name , email , role from users where $ 1 is null or department_id = $ 1 ; You run npgsqlrest (a single native executable, no runtime to install) pointed at your PostgreSQL, and: $ curl -s 'localhost:8080/users/?department_id=1' | jq [ { "id": 1, "name": "Alice", "email":

You didn't set out to build a framework. You set out to test a login form. But somewhere between the first WebDriver driver = new ChromeDriver() and the fiftieth flaky CI run, you built one anyway. There's a BaseTest . There's a DriverFactory . There's a WaitUtils class that everyone copies, and no one fully trusts. There's a reporting hack bolted onto TestNG listeners, and a block of CI YAML that only one person understands. That's a framework. You just never called it one — and that's exactly why it's so expensive. The framework you didn't mean to build Here's the pattern, repeated at nearly every Java shop: // The BaseTest that grows a little every sprint public class BaseTest { protected WebDriver driver ; @BeforeMethod public void setUp () { driver = new ChromeDriver ( /* options someone tuned in 2022 */ ); driver . manage (). timeouts (). implicitlyWait ( Duration . ofSeconds ( 10 )); // …plus retries, screenshots, and env switching bolted on over time } @AfterMethod public void tearDown ( ITestResult result ) { if ( result . getStatus () == ITestResult . FAILURE ) { // take a screenshot… somehow… attach it… somewhere } driver . quit (); } } It looks harmless. It's ten lines. But it never stays ten lines, because production testing keeps asking for more: parallel execution, a second browser, cloud grids, retry-on-flake, a report your manager will actually open. Each request adds a little more plumbing — and every line of that plumbing is code you now own. The five costs nobody budgets for 1. Maintenance you can't schedule. Selenium 4 lands. ChromeDriver changes its options API. A dependency bump breaks your screenshot logic. None of this is on the roadmap, all of it is on you, and it always arrives the week before a release. 2. Onboarding that lives in someone's head. A new engineer can't just read the docs — there are no docs. Onboarding is "sit with Priya and she'll explain the wait helpers." The framework's real specification is tribal knowledge, and it wal

Chrome ships a real LLM inside the browser now — Gemini Nano, exposed through a handful of built-in...

Most remote job listings are ghosts — already filled, never opened, or posted just to farm résumés. As a developer, that annoyed me enough to solve it with code instead of complaining about it on X . So I built Remoty.work , which grades every listing A–F on how likely it is to be real . Here's how the detection actually works under the hood. The problem, from an engineering angle Job boards are an endless scrape loop. Board A scrapes Board B, which scraped Board C. The same dead listing propagates across a dozen sites, and none of them verify anything. There's no signal for "is this real," so the noise compounds until every board looks identical. I didn't want to build board number thirteen in that loop. I wanted a layer on top that answers one question every listing should have to: is anyone actually going to read my application? The architecture Everything runs on a single VPS — Postgres, scrapers, and the scoring jobs, supervised on a schedule. Deliberately boring. High level: Ingestion: scheduled scrapers pull from source boards and company ATS feeds into Postgres. Each raw listing is deduplicated by a fingerprint (title + company + normalized URL) so the same job reposted across five boards collapses into one row with a repost_count . Scoring engine: every listing gets a ghost-risk score from a handful of signals, then mapped to an A–F grade so it's human-readable, not a black-box number. The "rant" signal: I cross-reference what people say about companies in places like r/recruitinghell and hiring threads. That's where the truth about a company's hiring leaks out, and it turns out to be a strong predictor. Agents: I use DeepSeek to classify and summarize the messy text job descriptions, company chatter. DeepSeek because running this over thousands of listings every night on GPT-4-class models would have killed the unit economics before I had a single user. One infra detail I didn't expect to spend a weekend on: the frontend is on Cloudflare's edge, but the ed

I spent the last few months building a Chrome extension that detects HTML code blocks inside ChatGPT, Claude, and Gemini and lets you deploy them straight to a live URL. The "deploy" part turned out to be the easy 20%. The hard 80% was reliably watching three completely different, constantly-changing chat UIs without breaking every other week. Here's what actually taught me something. 1. MutationObserver is non-negotiable, but it will still lie to you None of these chat apps render the full response at once — they stream tokens in, which means the DOM you're watching is incomplete almost every time your observer fires. My first version tried to detect a finished <pre><code> block the moment it appeared. Result: I was grabbing HTML mid-stream, cut off halfway through a <div> . What actually worked was debouncing on DOM stability instead of DOM presence: let debounceTimer ; const observer = new MutationObserver (() => { clearTimeout ( debounceTimer ); debounceTimer = setTimeout ( scanForCodeBlocks , 600 ); }); observer . observe ( document . body , { childList : true , subtree : true }); 600ms of "nothing changed" turned out to be a much more reliable signal than "the tag now exists." Not elegant, but it works across all three sites' streaming speeds. 2. Every AI chat UI restructures its DOM without telling you ChatGPT, Claude, and Gemini all ship frequent frontend updates, and none of them are obligated to keep a stable class name for you to hook into. I initially selected code blocks by class name ( .language-html , .hljs , etc.) and had selectors silently break in production within two weeks of launch. What's held up better: matching on structural patterns instead of class names — a <pre> containing a <code> whose text content starts with <!DOCTYPE or <html . It's slower to write the first time, but it doesn't care what CSS class the framework decided to use this month. 3. "Detect the code" is easy. "Detect the right code" is the actual problem A single AI response

Just shipped Timezone Convert API — DST-aware IANA timezone conversion. Free, no key, CORS-enabled. Endpoints GET /convert?time=2026-07-16T09:00&from=Asia/Kolkata&to=America/New_York GET /now?zone=Europe/London GET /offset?zone=Pacific/Auckland GET /diff?a=Asia/Tokyo&b=Asia/Kolkata GET /zones (400+ IANA zones) Try it curl "https://timezone-convert.techtenstein.com/now?zone=Europe/London" Live at https://timezone-convert.techtenstein.com — OpenAPI 3.1 spec at /openapi.json . MIT.

Most Android media apps solve only one part of the problem. A video player plays videos. A music player handles songs. A PDF reader displays documents. A text-to-speech app reads text. A vault hides private files. But real media libraries are not separated that neatly. My phone may contain downloaded movies, music, lecture notes, ebooks, PDFs, recordings, subtitles, and files I do not want exposed in the normal gallery. Constantly moving between different apps creates friction and breaks playback or reading continuity. That is why I built Nexo Player : an offline-first Android media app that brings local playback, document reading, audiobook generation, text-to-speech, and private storage into one experience. What Nexo Player does Nexo Player currently supports: Local video and audio playback PDF and EPUB reading PDF, EPUB, and text narration Background audiobook generation MP3, M4B, and ZIP export Multiple narrator voices Resume playback and reading progress Equalizer, sleep timer, subtitles, and playback-speed controls Picture-in-Picture Secure Vault protected with PIN or biometrics The app is built natively for Android using Kotlin , Jetpack Compose , and Android Media3 . The main product idea: local-first media The core rule behind the app is simple: A local file should remain local unless the user explicitly chooses otherwise. This rule influenced the entire product. Opening a downloaded video should not require an account. Reading a PDF should not require uploading it to a server. Listening to a generated audiobook should remain possible without a permanent internet connection. Private files should not leak into normal galleries, thumbnails, or recent-history screens. Offline-first is not only about caching data. It means the main workflow must remain useful, understandable, and recoverable without depending on the network. Building the playback layer For video and audio playback, I used Android Media3 as the foundation. The visible player looks simple, but a

Hi DEV community! 👋 I'm Widodo, an independent web and mobile app developer. In my day-to-day workflow—whether I am developing mobile apps, structuring databases, or setting up serverless continuous integration pipelines—I constantly rely on quick online utilities. Things like formatting code, generating QR codes, or stripping metadata from images. But I realized a massive flaw in the current ecosystem of free online tools: Privacy and Performance. If you search for a "Free EXIF Data Remover" or "JSON Formatter," 90% of the top results force you to upload your sensitive files to their remote servers just to perform a basic operation. Not only is this a massive privacy risk, but it also introduces unnecessary latency. Since my core development philosophy has always leaned towards offline-first architectures and minimal server dependencies, I decided to build my own solution. Enter Ic2Share.com . It is a growing directory of web utilities built on a strict zero-server-upload architecture. Everything executes instantly within the user's browser. Here is a breakdown of how I built some of the tools and the client-side APIs powering them. Secure EXIF & Metadata Stripper (Canvas API) Most EXIF strippers use backend libraries (like PHP's exif_read_data or Python's Pillow). I wanted this to happen entirely offline so users wouldn't have to upload their personal photos. The solution? HTML5 Canvas Re-rendering. When a user drops an image, the browser reads it via the FileReader API. I then draw that image onto a hidden element. When you export the canvas back to a Blob using canvas.toBlob(), the browser automatically discards all original EXIF headers (including the exact GPS coordinates and camera models). It is fast, secure, and costs $0 in server compute. The Online Teleprompter (requestAnimationFrame) I built an auto-scrolling teleprompter for video creators. Initially, I thought about using CSS transitions or setInterval for the scrolling text. However, CSS can cause jit

I wanted to play with AI image generation without paying for Midjourney or dealing with Discord bots. So I built SnapShift — a free web tool that transforms photos into artwork in seconds. What it does: Upload any photo (portrait, pet, landscape, product) Pick from 50+ styles — cyberpunk, anime, oil painting, Ghibli, movie posters, 3D figurines, and more Download in 1K or 2K quality No signup, no limits, completely free Tech stack: static site on GitHub Pages, AI generation via Agnes API with Cloudflare Worker proxy. Try it: https://snapshit.fun Would love to hear what other styles you'd like to see!

🔒 ATLOCK v4 — I stopped trusting my own app's encryption, so I rebuilt it TL;DR — ATLOCK is a...

Disclosure: this is a write-up about my own side project — a combat analytics tool for AION 2. No affiliation with the game's publisher. Links at the end. Architecture A Windows desktop app: Rust backend + Tauri v2 webview UI . It passively captures the game's TCP traffic (npcap), reassembles streams, parses the game's undocumented binary protocol, feeds a combat model (damage, heals, buffs, deaths, boss detection), and pushes aggregates to a small JS frontend. Nothing touches the game client — no injection, no memory reading. If the packet didn't say it, we don't know it. Pain #1: the protocol is a moving target Nobody hands you a spec. The protocol is varint-heavy, partially compressed, and changes with game patches. You end up doing packet archaeology: capture a fight, stare at hex dumps, correlate "I pressed this skill at 19:32:04" with byte patterns, build a parser, and then — the fun part — keep it alive after every patch , usually reverse-engineering the diff within hours because your users' raids are tonight, not next week. One hard-won lesson: log everything behind toggleable trace categories. Our tracing setup keeps hot-path log callsites at literally zero cost when disabled (Rust tracing with Interest::never() + atomic per-category flags), so a user can flip a "Trace: Packets" checkbox, reproduce a bug, and send a log that actually contains the bytes we need. Pain #2: entity identity is a lie The single hardest correctness problem wasn't parsing — it was identity . A player is not one ID: your character has a stable "owner" entity that carries your buff bar, your damage lands under a transient combat entity whose ID changes between pulls, leave the dungeon and the game re-binds you to a brand-new ID, names arrive from different packets than damage, sometimes seconds later, sometimes never (mid-fight app start). Get any of this wrong and a healer's healing lands on a ghost row, or a player's buffs vanish from the saved fight because their ID was recycled 7

Over the last few months, I’ve been turning small workflow problems I encounter on my Mac into focused utilities. Rather than building one enormous productivity suite, I wanted each app to solve a specific frustration well. I also wanted to build software the way I prefer to use it: local-first, available through a one-time purchase, and usable without creating another account or paying for another subscription. Here are five of the apps I’ve built so far. ScreenShelf My desktop used to become a temporary storage zone for screenshots, folders, documents, links, and files I needed for active projects. Folders helped with long-term storage, but they were not always useful for things I wanted to keep visible and nearby. ScreenShelf creates a customizable visual shelf for: Files and folders Screenshots and images Links Text Applications Frequently used project materials You can organize items across separate pages, customize the appearance of each page, and keep different groups of materials available for different projects. It also includes a Recents area that surfaces recent screenshots, which is helpful when the small screenshot preview disappears before you can interact with it. ScreenShelf is essentially the space between a cluttered desktop and a deeply nested folder system. Learn more about ScreenShelf PopNote Some reminders are too small for a full task-management system. You might need to remember to send a file in twenty minutes, check something after lunch, or complete one small step before ending the day. PopNote is a lightweight menu bar app that creates timed pop-up reminders on your Mac. The reminders appear as small visual bubbles rather than traditional notification banners. You can choose a time, add an icon, and let the note reappear when you need it. It is designed for temporary reminders that should remain noticeable without becoming another project to organize. Learn more about PopNote File Fetch I frequently download, save, rename, copy, and move

Body: ​Hi everyone! 👋 ​I am excited to share my latest project, LingoBridge-AI, which I have been building to solve a critical problem in rural healthcare. ​The Problem 🩺 ​In many rural areas, patients receive medical reports that are complex and filled with technical jargon. Due to this, they often struggle to understand their own health conditions, which leads to confusion and delayed medical care. ​The Solution: LingoBridge-AI 💡 ​I developed LingoBridge-AI, an AI-powered tool designed to: ​Simplify complex medical reports into easy-to-understand language. ​Translate information into local languages to ensure better accessibility for patients. ​Bridge the gap between healthcare providers and patients who have limited medical literacy. ​Tech Stack 🛠️ ​Built using Python and AI frameworks. ​Focuses on accuracy, simplicity, and user-friendly output. ​Check it out! 💻 ​You can view the source code and documentation here: 👉 [ https://github.com/cherukuriLakshmi/LingoBridge-AI ] ​I am still working on improving this, and I would love to get some feedback from this amazing community! If you have any suggestions on how to improve the AI or the user experience, please let me know in the comments below. ​Thanks for your support! ​Tags (Add these at the bottom): ai #healthtech #opensource #python #beginners

Hoi hoi! I’m @nyaomaru, a frontend engineer currently fighting the intense European heatwave by...