one convention to fix early: mrr is gross by convention, before processor fees and before tax. keep the fee drag as its own line rather than netting it off, otherwise you cannot compare your mrr to anything and you lose sight of what the fees are actually costing you.
Hattie Corbin
@mulch_mule
Vegetable gardener on heavy clay, zone 6, fourteen seasons in. I mulch obsessively and have opinions about wood chips that I will share unprompted.
66 credit Contributor
- From answers
- 0
- From questions
- 69
- Lifetime
- 69
Measure before you tune. docker stats for the crude version, or run cAdvisor and get real numbers. I've watched people set max-old-space-size by feel and then spend a week wondering why p99 got worse, a heap that's slightly too small gives you constant major GCs, which is death by a thousand 40 ms pauses instead of one clean crash.
It's genuinely fine and you should keep doing it until something specific hurts. The pipeline material exists to solve problems you don't have, several people deploying at once, needing to know who shipped what, needing to roll back at 2am without your laptop.
Three habits worth building now though, because they're cheap and annoying to retrofit:
- put the deploy in a script in the repo, even if it's three lines. Then it's documented, and "run this from CI" is later a five-minute change
- never edit files on the server. Everything comes from git. The moment you fix something with vim on the box, you have a state you cannot reproduce
.envon the server, never in the image, and write down somewhere which keys it needs
That's it. Blue-green at nine users is cosplay.
The manual versus manifesto distinction is the most useful thing in this thread and I am stealing it. It also explains why the books I loved most changed the least.
Get a month of your own half hourly data first, export it, and multiply it by each tariff's rates in a spreadsheet. It takes an evening and it beats every anecdote in this thread including mine.
Set it up, then restore to a specific point in time on a throwaway box before you believe any of it. Setup is the easy half.
Check starter liquid volume as well as temperature. You want about 10% of the batch from a mature previous one. When I moved house I unknowingly cut mine to about 5% because I'd bottled everything, and the next three batches were sluggish.
Ask yourself how old the concentrate was when you judged it. Cold brew keeps in the fridge for a week or so but it is not static, and a batch I loved on day one tasted exactly like your description of papery by day four. If you brewed on Sunday and formed your opinion on Wednesday, brew a small batch and taste it within a few hours before you blame the bean.
Only if it genuinely is a weekend. Export is the classic thing that looks like a weekend and turns into eleven days once you hit attachments and encodings. Charge now, promise export with a date on it.
stay free, get to 50, then charge everyone at once with a launch. better momentum, better story
On enforcement: think hard about how much you want to build. Hard technical enforcement in a self-hosted product is a permanent tax on your engineering and it produces the worst support tickets you will ever get, at 2am, from a customer whose licence check failed during an outage. I issue keys that state the entitlement, report usage in the admin UI so the customer can see their own number, and audit at renewal. Honesty plus visibility has cost me very little and saved a lot of code.
The Wall is the correct next read here and it is also about 240 pages, which fits the commute constraint better than most of the usual suggestions.
Quarantine before pests is the step people skip when the plant looks pitiful and they want to rescue it. That is how a courier delay becomes a spider mite problem across the whole shelf.
Worth adding that start_period matters a lot here. Without it, healthcheck failures during boot count as retries and the container gets marked unhealthy before it ever finished starting.
Also just check what caddy does when a backend is down. Default is to 502 immediately. With two upstreams and passive health checks configured, it retries the other one and the user sees nothing. Might be a four-line Caddyfile change for you.
you did get a customer, they just didn't pay. that's still validation, keep the feature and sell it to someone else
Also, 2% by weight of what? It should be the cabbage plus any added water, not the cabbage alone. Getting that wrong is how people end up at 1.4% wondering why things are lively.
Before you change feed, look at how much of it is not going into a hen. I had an open trough and was losing a genuinely embarrassing amount to billing out, spillage and rats at night. A treadle feeder cost me about 60 and my sack went from lasting four and a half weeks to lasting seven with the same four birds. That paid for itself inside a season and the rat problem stopped at the same time.
Went with slim for exactly this reason, sharp is in there too.
Fair, though I like being able to deploy without pushing to a remote branch first. Probably a habit worth losing.
1.42 GB down to 297 MB. And the .dockerignore was sending a 900 MB local node_modules as context, which explains why even 'cached' builds felt slow.
do you actually need client side search for 150 pages? a decent sidebar plus ctrl-f gets people most of the way and costs nothing
That's most of your extra hours right there. Use warm water to land at 25-26C and see what happens.
Measure the dough temperature, not the room. 24C ambient with cold flour and cold water easily gives 20C dough, and every degree below about 24 stretches the timeline noticeably. Cheap probe thermometer, measure after mixing, adjust your water temperature to hit the target.
Practical bit: propose things closer in. "Are you free tonight?" has a much higher hit rate with a chronic canceller than something booked three weeks out, because they're answering about a state they can actually see.