2025년 11월 4일의 Show HN

Hello,

For quite some time, I've been unsatisfied with the built-in timers on both Android and iOS; especially for workouts, when I needed to set up a configurable number of series with rest periods in between. That's when I started thinking about building something myself. It was just a timer and I said to myself "how hard could it be?", I had no idea.

The first iteration of the project worked "just fine", but the UI was an eyesore (even more than it is now), and the UX was quite awful as well. As you can probably guess, I'm not versed in design or front-end development. In fact, my last real experience with front-end work was back when jQuery was still a thing.

However, I knew what I wanted to build, and over the last few days (and with the help of the infamous AI) I was able to wrap up the project for my needs. It required quite a lot of "hand holding" and "back and forth", but it helped me smooth out the rough edges and provided great suggestions about the latest ES6 features.

The project is, as the title states, an offline-first PWA with zero dependencies; no build step, no cookies, no links, no analytics, nothing other than timers. It uses `Web Components` (a really nice feature, in my opinion, though I still don't get why we can't easily inherit styles from the global scope) and `localStorage` to save timers between uses.

I'd appreciate any comments or suggestions, since I just want to keep learning new things.

https://mytimers.app/

Hi HN,

After trying to teach a non-technical friend how to manage a Jekyll site I decided there must be a way to make building a site with a SSG easier. Options like Decap, Contentful etc. do make it a bit easier but still take lots of tech knowledge to set up.

So I built Sparktype, a browser-based CMS that outputs statically-generated HTML and CSS. My goal is for it to be as easy to use as Substack or Medium, while providing all the benefits of a static site generator including openness, simplicity, speed, security and ownership.

It handles most things that you'd need from a CMS, including creating pages, image resizing, menu management, tags, collections, listings etc. I've only made two themes so far, but I'm working on a theme store and the ability to import custom themes.

Content is saved as plain Markdown + YAML frontmatter and JSON config files, so there's no lock-in and content is easily portable to other platforms. Generated sites can be exported as a zip file to upload via FTP, committed to Github or published via Netlify API.

I'm working on cross-platform client apps using Tauri which will enable more publishing options as its not limited by what can be done in a client-only environment.

The way the system works means that the Web doesn't need to be the only interface to the content - here's a simple Go-based CLI client that bypasses the HTML altogether https://github.com/sparktype-project/sparktype/tree/main/st-...

It's very early days and there are still plenty of bugs, but I'm posting now to hopefully get feedback and see what people think. Please do let me know!

A crowdsourced map for ranking Boulder gym stinkiness and difficulty. Get a detailed view of the gym. “Is there toprope in the gym?” “Any training boards?”

Hey HN!

Suites is a unit-testing framework for TypeScript backend systems working with dependency injection.

It introduces a single declarative API for unit testing: wrap any unit with a single call and receive a correct test environment for the unit and its dependencies.

  // Test a class in complete isolation, all dependencies mocked
  TestBed.solitary(OrderService).compile();

  // Or, test how it integrates with a real dependency
  TestBed.sociable(OrderService)
    .expose(PaymentProcessor) // Use the real class
    .compile();

The backstory: while working for a fast-growing fintech startup 4 years ago, my team had to write thousands of unit tests for our NestJS backend. To scale our efforts, I've built a unit-testing framework which eliminated a significant part of the tests' code and made them a whole lot more maintainable. I open-sourced it, generalized it to support more tech stacks, and soon it gained traction.

The problem - unit testing becomes a nightmare very fast:

- You mock dependencies by hand, wire them up manually, and spend more time maintaining tests than writing them. - Unit tests are leaky and error-prone since it's unclear which dependencies are mocked - Test intention is lost in the boilerplate - Each engineer invents their own conventions - Tests break during refactors because of untyped, loosely connected mocks - Missing mock implementations go unnoticed, so tests falsely fail on unexpected undefined returns or validate the wrong behavior - Test errors for wrong mocking are confusing to engineers and coding agents alike

The nitty-gritty details:

- Fluent, auto-discoverable, fully-typed API. - DI Framework Adapters: Works out of the box with NestJS and InversifyJS - Testing Library Adapters: Works out of the box with Jest, Sinon, and Vitest

Suites provide two modes of testing: (inspired by Martin Fowler's writings [0])

- Solitary: For testing units in a vacuum, it creates type-safe mocks of all the unit's direct dependencies. - Sociable: For testing units with other related units, it allows the developer to define which dependencies to mock.

Eliminating boilerplate and making mocks type-safe drastically helps coding agents (e.g. Claude Code) to write correct tests in a single pass and avoid entering infinite loops, significantly reducing token cost.

You can read more about Suites on our website: https://suites.dev

What's next?

- A dedicated skill for Claude Code - Extended docs with real-world patterns - More test utilities for common backend scenarios

Suites is fully open-source and actively maintained for 4 years. I would love you to check it out and get your honest feedback!

[0] https://martinfowler.com/bliki/UnitTest.html

I have lots of free time.

I recently got fired and decided to channel my energy into something productive. Over two weeks, I spent 16-hour days building a tool that converts Australian bank PDFs into clean, reliable CSVs, tailored specifically for Aussie banks.

Most Aussie banks only provide statements as a PDF, and generic converters often fail: columns drift, multi-line descriptions break parsing, headers shift. Existing tools don’t handle it well and I wanted a tool that just works.

To get started, I used my own bank statements to build the initial parsers. There was a "duh" moment when I realised how hard it is to get more realistic test data. People don't just hand over their financial ledgers. This solidified my core principle: trust and privacy had to be the absolute top priority.

I initially tried building everything client-side in JavaScript for maximum privacy, but performance and reliability were poor, and exposing the parsers on the front-end would have made them easy to copy.

I settled on a middle ground: a Python and FastAPI backend on Google Cloud Run. This lets me balance reliability with a strict privacy architecture. Files are processed in real-time and the temp file is deleted immediately after the request is complete. There is no persistent storage and no logging of request bodies.

My technical approach is straightforward and focused on reliability:

- I use pdfplumber to extract text, avoiding complex and error-prone OCR.

- I apply a set of bank-specific regex patterns to pinpoint dates, amounts, and descriptions.

- A lookahead heuristic correctly merges multi-line transactions. Each parser is customised to its bank's unique PDF layout quirks.

The project is deliberately focused. Instead of supporting hundreds of banks with mediocre results, I'm concentrating on a small set to get them right. It currently supports CommBank, Westpac, UBank, and ING, with ANZ and NAB next. The whole thing is deployed on Cloudflare Pages and outputs clean CSVs ready for Excel, Google Sheets, Xero, or MYOB.

It was a fun challenge in reverse-engineering messy, real-world data.

Try it out here: https://aussiebankstatements.com

I'd love to hear feedback. If it breaks on your statement, a redacted sample would be a huge help for improving the parser.

I'm also curious to hear how others here have tackled similar messy data extraction challenges.

We're building Merlin to speed up electrical component selection, starting with ceramic capacitors. Overview video: https://youtu.be/FrGrivAKhnc

The problem: We hated the tedious work of choosing components: copying specs into spreadsheets, taking screenshots from multiple datasheets, and cross-referencing parameters across manufacturers.

What we built:

- A comparison tool that displays all relevant electrical/mechanical specs along with the performance curves in a single view

- An alternates tool that identifies equivalent parts based on a reference component

We think this helps because: Instead of juggling multiple browser tabs and Excel sheets, you can quickly verify if a part meets your requirements and find alternates when your current part is out of stock or EOL. We found it also helps during the design phase to readily compare specs and find better parts.

Try it out at www.get-merlin.com - we'd love your feedback, especially:

- What information are we missing that you need?

- What component types would be most valuable?

- How does your team currently handle component selection?

You can use the comparison tool for free, and we have a 14 day trial of the alternates tool available now.

Mental arithmetic has been a hobby of mine for a while. It's fun and good exercise for your brain.

When I switched to iOS, I couldn’t find a decent app. Most had ads, sign-ups, excessive gamification, or mandatory subscriptions, and none were customizable enough. So I built my own.

Athena Math lets you

- Practice operations not normally found in mental math apps: modulo, square roots, percents, GCD and LCM - Tailor each session: set your time or problem limits, choose digit ranges (1–5), mix digit lengths (e.g. 55 + 436), and select any combination of operations you like. - A detailed stats screen that shows the time you spent on problems, problems per day, percent correct, etc. All graphs are filterable. - A history screen that shows all your sessions. - You can import and export your history for offline analysis or to transfer - Offline tutorials are included for all operations - Lastly, you can use it immediately. There are no accounts.

So far, it's received a positive response from the mental math community. It's an incredible feeling to have people actually value my work enough to pay for it. (This was my first app).

I've had a lot of fun building Athena math and using it myself. Practicing obscure operations like GCD, LCM and square roots has taught me to see patterns in numbers that I didn't see before. Overall, it's improved my number sense.

It's built in React Native + Expo/EAS. I use Fastlane to manage app store metadata (and store in version control), and it's using a serverless AWS backend for payment verification. History is stored locally in an SQLite database.

It's free to use! You're limited to 12 sessions daily, but if you wanna keep using for free, you can simply delete your daily sessions. You loose history and stats, but it's an option. You can also just set the time limit to infinity.

I know mental math is not the sexiest market, but I'd love feedback from the HN community -- on the app, the UX, or the technical setup. Any ideas for improvement? What are your thoughts?

Thanks for reading and happy hacking!

Hey HN, we’re Iyan and Datta, founders of Barcable. Barcable connects to your backend (HTTP, gRPC, GraphQL) and uses autonomous agents to generate and run load tests directly inside your CI/CD. No configs, no scripts. It scans your repo, understands your API routes, and builds real test scenarios that hit your endpoints with realistic payloads.

Docs: https://www.barcable.dev/documentation

We built this out of frustration. Every team we’ve worked with ran into the same issue: reliability testing never kept up with development speed. Pipelines deploy faster than anyone can validate performance. Most “load tests” are brittle JMeter relics or one-off scripts that rot after the first refactor.

Barcable is our attempt to automate that. It:

- Parses your OpenAPI spec or code to discover endpoints automatically - Generates realistic load tests from PR diffs (no manual scripting) - Spins up isolated Cloud Run jobs to execute at scale - Reports latency, throughput, and error breakdowns directly in your dashboard - Hooks into your CI so tests run autonomously before deploys

Each agent handles a part of the process—discovery, generation, execution, analysis—so testing evolves with your codebase rather than fighting against it.

Right now it works best with Dockerized repos. You can onboard from GitHub, explore endpoints, generate tests, run them, and see metrics in a unified dashboard.

It’s still a work in progress. We’ll create accounts manually and share credentials with anyone interested in trying it out. We’re keeping access limited for now because of Cloud Run costs.

We’re not trying to replace performance engineers, just make it easier for teams to catch regressions and incidents before production without the setup tax.

Would love feedback from anyone who’s been burned by flaky load testing pipelines or has solved reliability differently. We’re especially curious about gRPC edge cases and complex auth setups.

HN has always been a huge source of inspiration for us, and we’d love to hear how you’d test it, break it, or make it better. — Iyan & Datta https://www.barcable.dev

This is a powerful online curve fitting tool that supports fitting dozens of commonly used functions and implicit functions. It features a clean interface and simple operation. If you need to perform curve fitting but don't want to learn professional software like Matlab or Origin, you can try this tool.

I'm building ReadMyMRI to solve a problem I kept running into: getting medical imaging data (DICOM files) ready for machine learning without violating HIPAA or losing critical context.

What it does: ReadMyMRI is a preprocessing pipeline that takes raw DICOM medical images (MRIs, CTs, etc.) and:

Strips all Protected Health Information (PHI) automatically while preserving DICOM metadata integrity Compresses images to manageable sizes without destroying diagnostic quality Links deidentified scans to user-provided clinical context (symptoms, demographics, outcomes) Uses multi-model AI consensus analysis for both consumer facing 2nd opinions and clinical decision making support at bedside Outputs everything into a single dataframe ready for ML training using Daft (Eventual's distributed dataframe library)

Technical approach:

Built on pydicom for DICOM manipulation Uses Pillow/OpenCV for quality-preserving compression Daft integration for distributed processing of large medical imaging datasets Frontier models for multi model analysis (still debating this)

What I'm looking for:

Feedback from anyone working with medical imaging ML Edge cases I haven't thought about Whether the Daft integration actually makes sense for your use case or if plain pandas would be better HIPAA/privacy concerns I am not thinking about

Happy to answer questions about the architecture, HIPAA considerations, or why medical imaging data is such a pain to work with.

Hi HN! I'm Vince. I built Nallely, a modular reactive Python framework for creating custom MIDI instruments by patching signal-processing modules together, like a modular synthesizer for controls systems. Nallely focuses on real-time, thread-isolated, reactive behavior, letting you experiment with emergent behaviors.

Demo video: https://www.youtube.com/watch?v=rbMnKAdqAVI building a patch from scratch and hot-debugging a running instance near the end.

Key features: * Visual patching interface for connecting reactive modules (neurons), * Extensible via Python API, WebSocket, and/or code generation, * Integrates any input source (MIDI, webcam, ...) to control synthesizers.

# Yes, but why? Existing software/libraries that proposes MIDI manipulation are powerful but not friendly to live experimentation. They are low-level, hard to rewire on the fly, and often heavy for embedded or headless setups. I wanted a system that could also evolve dynamically where modules could be patched, hot-swapped, and debugged in real time.

# Architecture The system is built around a reactive threading model with no shared data: each neuron lives in its own thread and communicates by sending messages through channels. No more CC,... , at the neuron level, everything is a signal (a simple int/float value through time). No global tick, each neuron works on its own time. Each neuron being reactive, they are sleeping the majority of the time. The system takes heavy inspiration from the "Systems as Living Things" philosophy and Smalltalk by treating each thread as a small living entity more than a processing unit. Here is how to code a simple Sample&Hold module:

class SampleHold(VirtualDevice): input_cv = VirtualParameter(name="input", range=(0, 127)) trigger_cv = VirtualParameter(name="trigger", range=(0, 1), conversion_policy=">0")

    @on(trigger_cv, edge="rising")
    def hold_value(self, value, ctx):
        return self.input

The control layer uses a small WebSocket protocol that the react-based web UI uses to control and introspect sessions. A WebSocket-bus neuron lets external application auto-register to it to send/receive signals: another neuron in the network can serve signals captured from any source. They're useful to distribute computation loads on different machines.

# What have I learned so far A simple threading model can be powerful in a MIDI/music context: * you can stop/resume a thread, stopping a part of the processing chain seamlessly; * overflown neurons can mitigate the pressure without impacting the whole session; * if a thread crashes, it is paused to give you the ability to debug the instance, and resume it; * simple websockets have an acceptable throughput.

I was expecting a system entirely based on Python threads to be really ineffective, but it's surprisingly reasonable. Empirically I see ~1-2 % CPU per thread. A 20 threads classical session (~45 patches) uses roughly 21% CPU and 45MB RAM on CPython 3.13 GIL. CPython 3.14 no-GIL shows similar CPU but ~65MB RAM. Feedback loops raise usage (~38 %). Interestingly, on CPython 3.13 the load spreads across multiple cores, I suppose that the threads are sleeping enough to release often the GIL.

# Try it! You can grab a precompiled PyInstaller built binary in the latest github actions artifacts. Doc is linked in the README, and deep-dive posts are available here: https://dr-schlange.github.io/nallely-midi/posts.

# I would love feedback * What could be improved to make it easier to get familiar with? * Are there blind spots or design choices that could be problematic long-term? * Although it's MIDI-oriented, the system is really signal-agnostic, any idea for non-audio use-case? (e.g. visuals, etc)

Hey HN -

Kiran and Vijay here.

We built Oodle after seeing teams forced to choose between low cost, great experience, zero ops, and no lock-in. Even with premium tools, debugging still meant switching between Grafana for metrics, OpenSearch for logs, and Jaeger or Tempo for traces - copying timestamps, losing context, and burning time during incidents.

So we decided to rethink observability from first principles - in both architecture and experience.

Architecturally, we borrowed ideas from Snowflake: separated storage and compute so each can scale independently. All telemetry - metrics, logs, and traces - is stored on S3 in a custom columnar format, while serverless compute scales on demand. The result is 3–5× lower cost, massive scale, and zero operational overhead, with full compatibility for Grafana dashboards, PromQL, and OpenSearch queries.

On the experience side, Oodle unifies everything you already use. It works with your existing Grafana and OpenSearch setup, but when an alert fires, Oodle automatically correlates metrics, logs, and traces in one view - showing the latency spike, the related logs, and the exact service that caused it.

It’s already in production across SaaS, fintech, and healthcare companies processing 10 TB+ logs/day and 50 M+ time-series/day.

We’ve both spent years building large-scale data systems. Vijay worked on Rubrik’s petabyte-scale file system on object storage, and I helped build AWS S3 and DynamoDB before leading Rubrik’s cloud platform. Oodle applies the same design principles to observability.

You can try a live OpenTelemetry demo in < 5 minutes (no signup needed): https://play.oodle.ai/settings?isUnifiedExperienceTourModalO...

or watch a short product walkthrough here: https://www.youtube.com/watch?v=wdYWDG3dRkU

Would love feedback - what’s your biggest observability pain today: cost, debuggability, or lock-in?

Just an experimental little npm library for creating a quick feedback loop when writing code.

The basic idea is that it runs a quick check on any code when a file is written to, and when code is committed.

I expect there are quite a few bugs etc but it has been running smoothly enough for me so far.

https://github.com/whatever555/ollama-watcher

Convosphere is a location-based chat app where you can join local conversations, events, and meet people nearby — all without sharing personal data.

Main features: • GeoChat: join or create chats within a custom radius. • TrustScore: reputation system to keep conversations safe. • Events: discover or host local activities. • AI integration: Sfera AI curates local news and creates events based on them. • Teleport mode: explore chats from any city.

Available for Android, iOS and Web: https://convosphere.app

I'd love to hear feedback, especially about improving onboarding and local discovery.