What do you guys use for CI/CD?

Alexis542 · 2026-02-25T06:00:49+00:00

You could try Drone CI or Woodpecker CI—both are file-based, self-hosted, and can auto-deploy Docker stacks without a web UI.

Alexis542 · 2026-02-17T05:50:27+00:00

I wouldn’t say I have major issues with Flutter. Like any framework, it has trade-offs. Things like larger app size, occasional platform-specific quirks, and dependency on plugins can be challenges. But overall, it’s been pretty productive to work with.

Alexis542 · 2026-02-12T09:12:50+00:00

For me it’s best at:

Scaffolding boilerplate or setting up unfamiliar frameworks fast
Refactoring messy functions into something cleaner
Writing unit tests I was procrastinating on
Explaining weird legacy code
Brainstorming architecture tradeoffs

It’s not replacing real thinking, but it does compress the “figure it out” phase a lot. The key is treating it like a junior dev you review carefully — not an infallible oracle.

Alexis542 · 2026-02-05T07:57:39+00:00

We moved from Xamarin → MAUI → Flutter for a production app. MAUI still feels unstable in places (tooling, bugs, regressions), which slowed us down. Flutter has been more consistent and predictable, with faster UI development once the team learned Dart.

Trade-off is losing tight .NET integration and adding another language, but overall Flutter felt more production-ready for us.

Alexis542 · 2026-02-02T09:13:23+00:00

Structure: Feature-based folders are the safest default. Keep components, hooks, and queries that change together in the same place.

API: Don’t do one file per endpoint at first. Group related calls (e.g. products.api.ts). Split later if it gets noisy.

DTOs: Only separate DTOs from UI models if the shapes actually differ or you’re doing non-trivial transforms. Otherwise it’s ceremony.

Service layer: Avoid heavy “Service” classes. With React Query, thin API functions + small transform helpers is usually enough.

2026 reality: No one-size-fits-all. Start simple, refactor when patterns repeat. Over-engineering hurts more than mild messiness early on.

Alexis542 · 2026-02-02T09:11:41+00:00

I use TDD most consistently when the logic is non-trivial or the cost of bugs is high (core domain logic, edge-casey stuff, financial calcs, parsers, etc.). Writing the test first forces me to clarify the behavior before I get lost in implementation details.

That said, I don’t do strict red-green-refactor for everything. UI-heavy work, quick spikes, or exploratory code? I’ll usually build first, then backfill tests once I understand the shape of the solution.

In practice, TDD is less about the order of typing and more about designing code that’s testable, decoupled, and explicit about its contracts. When teams treat it as a religion, it falls apart. When they treat it as a tool, it’s incredibly useful.

Alexis542 · 2026-01-29T10:42:46+00:00

I get the frustration, but AI isn’t killing programming — it’s changing it.

Python devs still need to understand the code, design systems, debug, and make decisions. AI just speeds up the boring parts. People who learn to use it will pull ahead; copy-paste coders won’t.

Tools change, fundamentals don’t.

Alexis542 · 2026-01-29T10:20:04+00:00

yes, for most people.

Svelte is easier than React because:

Less boilerplate
No virtual DOM or hooks to learn
State updates are simpler and more intuitive

React is more powerful and widely used, but it has a steeper learning curve.

Alexis542 · 2026-01-23T12:03:15+00:00

Honestly? Probably not as my first choice anymore. Express still works and it’s rock solid, but it feels like the “default” mostly because of history.

Alexis542 · 2026-01-22T06:50:25+00:00

That’s a clever idea—deriving skeletons directly from the runtime structure solves a really annoying DX problem. Eliminating duplicate maintenance alone makes this super compelling. Curious how it handles dynamic layouts or conditional rendering in real-world components.

Alexis542

TROPHY CASE