u/UkrMalt

I’m a solo iOS developer building a small workout app and want the interactions to feel intentional without adding a giant animation pipeline. For rerolls, progress, completion states, and subtle feedback, would you stay with SwiftUI transitions and SF Symbols, use Lottie or Rive, generate assets and edit them, or make everything yourself?

I’m looking for a practical workflow that stays around free to $20–30, performs well on-device, and respects Reduce Motion. What have you actually shipped, rather than just prototyped?

For a small NestJS service, I’m thinking of keeping alert delivery outside the normal response path. If a Telegram or webhook notifier times out, should the exception filter only record the notifier failure and let the request complete, or are there cases where the application error should include delivery failure? How do you keep retries and queue size bounded?

If grouping uses raw error strings, IDs and sensitive values can create too many fingerprints. But aggressive redaction can make unrelated failures look identical. Do you redact before fingerprinting, normalize selected fields, or keep a separate grouping key?

When SIGTERM arrives, should an Express service stop accepting requests, finish current requests, drain a small outbound queue, and then exit? How do you decide what gets a timeout or gets dropped? I’m interested in small services rather than Kubernetes-specific solutions.

TypeScript catches a lot for consumers, but deployment config still needs runtime validation. For environment-driven packages, do you validate everything during startup, validate lazily when a feature is used, or do both? What makes configuration errors easiest to fix without exposing secrets?

I’m running Ollama on an M4 Pro Mac with 48 GB unified memory and testing local coding models for repository work.

Direct Ollama inference is fine. Qwen3.8 27B-MLX runs well enough for me, and the local endpoint is http://127.0.0.1:11434. The trouble starts when the model is used through an agent with file and shell tools.

The same read-only task produced very different results:

- Claude Code + Qwen3.8 completed it accurately

- Codex + Qwen3.8 stayed in “Working” and never returned a usable answer

- Codex also showed model metadata and catalog warnings for the custom model name

Has anyone made Ollama plus a custom Qwen model reliable for tool-using coding agents?

I’d especially like to hear about model templates, thinking/tool-call compatibility, context limits, and whether you use a proxy or adapter between Ollama and the agent.

If one failing dependency causes the same error on many requests, sending every stack trace to Telegram or a webhook becomes noise.

Would you put fingerprinting and cooldown logic inside Express error middleware, in a separate notifier service, or behind a queue?

Which request context is essential in the alert: route, status, request ID, deployment version, or something else?

I’m building an open-source package with an Express adapter and would appreciate feedback from people running real Express APIs.

When the same database error happens 20 times, sending 20 notifications creates noise. Process-local fingerprinting with a count and cooldown helps, but it does not deduplicate across replicas.

For a service with one or two instances, is that useful enough to ship, or is cross-replica grouping essential? What metadata makes a grouped alert actionable?

I’m building an open-source Node package around this and want to validate the design before adding more integrations.

I’m working on a small NestJS service where the same failure can be thrown by many requests.

I’m comparing two approaches: let the exception filter send every error, or fingerprint repeated errors locally and send one alert with a count and cooldown.

For a small service, where would you put this logic: inside the exception filter, a shared provider, or outside the process? Which context should always be included: route, status, request ID, deployment version?

I’m looking for a series where the day-to-day training or practice actually changes the characters and affects the plot. Sports, martial arts, music, or another craft are all fine. I’d prefer something grounded and not built around nonstop tournament power-ups. What would you recommend?

I’m building a small workout generator with a flow of preferences → generated session → reroll/start. I’m trying to avoid putting all of the generation logic in the view. Would you keep the generator as a pure service owned by a view model, or model each step as navigation state? I’d like rerolls to be repeatable in tests and not lose the user’s constraints.

My iOS app generates workouts from a set of exercises and constraints. I want the same inputs to be reproducible in tests and previews, while production still feels random. Would you inject a seeded RNG, pass a generator protocol through the model, or keep randomness at the edge and test the generated constraints instead? I’m looking for a small approach that won’t make the app’s architecture noisy.

I’m looking for something built around local myths, spirits, or strange old places. Horror is fine, but I care more about atmosphere than jump scares. Short or long series are both okay. What would you recommend?

For a small repository, adding templates, bots, labels, approval rules, and a long contributing guide can make the project look organized while making a first contribution harder.

My minimum would be a reliable local setup, one command for checks, a short architecture map, clear issue scope, examples of a good PR, and fast feedback when maintainers are unavailable. Add governance only when real coordination problems appear.

What reduced the time from cloning a repository to opening a useful PR for your contributors?

I’m a backend developer, and on most projects I end up asking the team or client to add proper logging and error alerts before the first production incident.

The problem is that the bigger solutions can cost money and take real time to integrate. They also introduce another dashboard that somebody has to configure, learn, and keep checking. For a small Node.js service, alerting often gets postponed, so important failures remain in logs until somebody notices.

I was already using private Telegram bots to receive notifications from my own apps and servers. Creating a bot takes a few minutes, Telegram is already on my phone, and the message arrives somewhere I actually look. That is why Telegram became the first practical notifier when I built Wotchi.

Wotchi is an open-source Node.js package that runs inside the application. It redacts sensitive values, groups repeated errors, applies thresholds and cooldowns, and sends alerts to the console, Telegram, or an HTTPS webhook. It supports Express and NestJS and has zero direct runtime dependencies.

For example, if the same database error happens 20 times, Wotchi can group it and send one alert with the occurrence count instead of flooding the chat.

npm install @futurewindai/wotchi@beta

It is not a replacement for Sentry, Datadog, or a full observability platform. There is no hosted dashboard, persistent incident history, or cross-replica deduplication. The goal is smaller: give small services a simple alerting layer without adding another platform.

• npm: https://www.npmjs.com/package/@futurewindai/wotchi
• GitHub: https://github.com/FutureWindAI/Wotchi

I would appreciate honest technical feedback:

• Would this be useful for your smaller services?
• What would stop you from trying it?
• Which integration or example is missing?

Keeping HTTP handlers and queue consumers in one Nest application is convenient at the beginning: one dependency graph, one deployment, and fewer moving parts. The tradeoff appears when worker load, shutdown behavior, or scaling decisions begin affecting request latency.

My current boundary would be to share domain modules and infrastructure providers, but give the API and worker separate bootstrap entry points and separate processes once they need independent scaling or failure isolation. Each should have its own health checks and graceful shutdown path while using the same application services.

Do you split workers from day one, or wait for a concrete operational signal? What signal made the separation worthwhile?

A Node.js library can have a green test suite and still publish a broken package because its tests ran against source files.

For a release candidate, I think the critical check is npm pack followed by installation into clean consumer fixtures. From there, test every advertised entry point, ESM and CommonJS only if both are promised, TypeScript declarations, supported Node versions, and whether the README example runs without repository-only files.

I would rather keep that matrix small enough to run for every release than build a huge checklist nobody trusts. What packaging failure has slipped through your CI?

For endpoints that trigger payments, webhooks, or queued work, a retry can produce duplicate side effects. I’ve seen idempotency handled in an interceptor, inside each use case, or at the database boundary with a unique key.

An interceptor is reusable, but it may not know the transaction boundary. Use-case code has the context, but every endpoint must implement the same lifecycle.

For a NestJS service backed by PostgreSQL, where do you store and enforce idempotency keys? How do you handle a second request that arrives while the first one is still processing?

For a small Node.js service, a /health endpoint that returns 200 proves the process is listening. It can stay green while the database or queue is unavailable. A deeper check catches that, but it can also create load and turn a dependency issue into a restart loop.

I’m leaning toward separate liveness and readiness endpoints. Liveness checks the process and event loop. Readiness verifies critical dependencies with tight timeouts. Deployment probes use readiness, while alerts use a synthetic request that exercises the full path.

How do you divide these checks in production? Which dependencies belong in readiness, and which should only affect alerts?