Pinned Tweet
- Building robust, maintainable software products across a variety of sectors since 2000
- Last decade building SaaS products with Distributed Cloud/Hybrid Architecture
- Improving software quality practices and processes, advocating clean coding, testing, agile, leadership
The term Modular Monolith is funny. Like as if we didn't build monoliths like that before. I mean what other way is there to build maintainable extensible monoliths.
90s build software, ensure it has modularity.
Early 2000s create features as modules to build extensible systems, it was everywhere. In CMS, custom built software, desktop, web
Circa 2005-2010 MVC, decoupling of functionality to external soap wsdl, and later web apis.
2010-2015 more separation and decoupling of domains into "mini applications" aka microservices. Benefits of independent scaling, management by teams, build and deployments, especially with cloud services.
2015-2020. Microservices, APIs very common. Although the term micro sometimes gets overused with so many services. Increasing complexity.. and coupling leading to distributed monoliths..
2020- microservices in full swing, new developers think it's the only way... But don't really understand why (even if they think they do)
Than lots of talk about "Modular Monoliths" ... and the cycle comes back to principles from decades before, although with new tech.
Not mutually exclusive, both have value at different points.
Both C# and Java close to Rust (besides mem use), though Java's mem use is a bit insane (testing oddities perhaps?)
github.com/GlebOlsen/benchLA…
Interesting.
C# with genhttp leading on http/1.1 benchmarks with 3.1 Million requests per second baseline.
With only rust topping it for memory efficiency.
http-arena.com/#sort=rps:-1&…
Currently getting our upgrade in place from a large legacy distributed monolith with various .net core versions (from V2.x to 5) to .net10.
Important that it works, and relatively quickly. It's a $30mill MRR
Any good comparisons of
Grok 4.6
Kimi k3
Fable
GLM5.2
We all know fable.. though I've mostly being using grok 4.6 lately.. seems to do the job ... If a bit long winded if not careful. I believe Kimi k3 is leading the open weights but be handy to see comparisons
30 docker images, average build size 1gb based on building 5, slow build times, initially 39 min per image, crazy, got that down to 12min, still too long and large though
.... Damn that's huge, too large...
Turns out some common library which every deployable service had a reference on, pulled in skiasharp, which added 450mb of deps per docker image.. due to skia bringing in win, Mac and Linux deps. Oops, forgot the Linux only RID, which got the deps down to 11mb...
Though it highlights a classic case of where abstractions are needed (and weren't implemented) and in low dependency projects, to avoid bringing in direct dependencies across every project.
Anyway with rid publish for Linux only in docker, build times dropped to 4min, and images to 445mb, after a few other cleanups...that can be reduced further by using chiselled or alpine images likely. I've gotten .net5 images to about 50mb and native .net 10 aot to about 40mb...
Abstractions should always be used with potentially heavy dep chains.
Hmm so added or fixed about 30 dockerfiles today to get building,but forgot to cache mount shared libs and resources so fresh rebuilds of everything.. NuGet restores included.. ouch.
mental reminder, always cache mount... good thing was building locally on desktop.
Git Worktrees get expensive when each one has 45gb of build artifacts.. I guess it's all relative though..... i mean compared to 450gb per worktree thats not too bad.
Is there a market for e2ee source code hosting? I know there are projects implementing it.. just curious as to thoughts on it.
Aspires decent, we have about 10 solutions using it now. 7 of which are recently introduced. The others for a few years.
I have found a few issues with it though, mainly around the admin pages for things like phpmyadmin and pgadmin auto login, which were very simple with docker compose, very fiddly to get working smoothly with aspire
As part of a larger system refactor, upgrade, rewrite I placed separate repo solutions into a mono repo, with docker compose files for infra services (covering azure and Gcp) and aspire just wiring them as external services and spinning up services within each solution. This works quite well.
Question for those that build electron apps, do you use Solidjs for performance, or stick to react or similar?
Experiementing with the Voice agents lately, quite cool. much better than most automated responses around.
Hmm, doing some refactoring, at this current rate, monthly costs will be about $3,500 USD for token usage. Guess that's not too bad.
Simple, good value container hosting?
0%Render
0%Railway
75%Digital Ocean
25%other..
4 votes • Final results



