Cook very large or numerous portions. Use what you need for 1 meal, freeze the rest to save for future meals. Based on how much your family eats in that first meal, divide up the remaining amount into that sized portions when freezing. Warm up the frozen food in the oven (still may take an hour, but you can do other things during that time).
Frozen vegetables are pretty cheap and easy to warm up quickly in the microwave or an air fryer. They may not be as good for you as fresh produce, but that can be a reasonable tradeoff based on the season and free time.
Chest freezers are reasonably cheap to buy (new or used) and cheap to operate, assuming you have the physical space and an open electrical outlet. They don't consume much electricity, mine uses about 75W for the compressor (when it's running, which is less than 50% of the time) and about 250W for the defrost heaters (which seem to turn on for about 15 minutes roughly once per day.
One extra thing to consider is preparing something that can transform easily into many dishes.
We cook a "big meal" every weekend (now in winter time is chickpea+meat stew - "cocido madrileño"). It takes around 1 hour to make, but the time is not proportional to the quantity. So we make enough for 3-4 meals for my family of 3 on a big pot.
The nice thing about this stew in particular is that you can reserve the liquid, meat and chickpeas in separate containers in the fridge. The liquid is a very good base broth for soups (heat up, add some noodles, done in minutes).
The meat can be consumed cold, or can be the meaty base of other things (croquettes). We can also rebuild the dish by adding broth, chickpeas and meat into a plate and microwaving it (again, minutes). Or we can add some rice and have a "paella de cocido" (that takes a bit longer, around 25 minutes).
You have to adapt this idea to whatever is available to you in your area and your personal tastes. Perhaps you can prepare a big batch of mexican food, to eat in tacos/wraps/with salad. Or some curry base that can double up as a soup.
It’s definitely some marketing, but way less than it could be. It recommends looking at the redis docs to build a reds client rather than the websites own tutorial/paid product for doing so.
I’m all ears for a better approach because squashing seems like a good way to preserve only useful information.
My history ends up being:
- add feature x
- linting
- add e2e tests
- formatting
- additional comments for feature
- fix broken test (ci caught this)
- update README for new feature
- linting
With a squash it can boil down to just “added feature x” with smaller changes inside the description.
If my change is small enough that it can be treated as one logical unit, that will be reviewed, merged and (hopefully not) reverted as one unit, all these followup commits will be amends into the original commit. There's nothing wrong with small changes containing just one commit; even if the work wasn't written or committed at one time.
Where logical commits (also called atomic commits) really shine is when you're making multiple logically distinct changes that depend on each other. E.g. "convert subsystem A to use api Y instead of deprecated api X", "remove now-unused api X", "implement feature B in api Y", "expose feature B in subsystem A". Now they can be reviewed independently, and if feature B turns out to need more work, the first commits can be merged independently (or if that's discovered after it's already merged, the last commits can be reverted independently).
If after creating (or pushing) this sequence of commits, I need to fix linting/formatting/CI, I'll put the fixes in a fixup commit for the appropriate and meld them using a rebase. Takes about 30s to do manually, and can be automated using tools like git-absorb. However, in reality I don't need to do this often: the breakdown of bigger tasks into logical chunks is something I already do, as it helps me to stay focused, and I add tests and run linting/formatting/etc before I commit.
And yes, more or less the same result can be achieved by creating multiple MRs and using squashing; but usually that's a much worse experience.
You can always take advantage of the graph structure itself. With `--first-parent` git log just shows your integration points (top level merge commits, PR merges with `--no-ff`) like `Added feature X`. `--first-parent` applies to blame, bisect, and other commands as well. When you "need" or most want linear history you have `--first-parent` and when you need the details "inside" a previous integration you can still get to them. You can preserve all information and yet focus only on the top-level information by default.
It's just too bad not enough graphical UIs default to `--first-parent` and a drill-down like approach over cluttered "subway graphs".
stacked diffs are the best approach and working at a company that uses them and reading about the "pull request" workflow that everyone else subjects themselves to makes me wonder why everyone is not using stacked diffs instead of repeating this "squash vs. not squash" debate eternally.
every commit is reviewed individually. every commit must have a meaningful message, no "wip fix whatever" nonsense. every commit must pass CI. every commit is pushed to master in order.
What are you referring to? I may be missing a line from the article but it seems mostly focused around a lingering GitHub Actions bug and the direction of GitHub.
Then... don't use GHA and move to other CI/CD/Workflow platform.
If you try it, don't like it then don't use it, GitHub does not force you to use GHA anyway, and moving away from GitHub due to their direction sounds like a political movement. It's like someone who stop shopping from Walmart, not because they sells bad product but because they support the Republic, then going to a local shop that sometimes close unexpectedly sound unreasonable.
Only incident we needed AWS support we had an engineer on call with us for several hours (including a shift change for them). Might’ve been a one-off but has seemed like their support is pretty phenomenal (also talked with someone who worked there and they thought it was good).
100% this. I have used support multiple times, there were times when calls took more than 12 hours. We used basic and Whenever I needed support I turned on to "Business" - from memory it costed 100 bucks a month.
If you pay for enterprise support they will absolutely stay on a call with you during a production outage. Best support I've seen from any of the vendors I've used.
Yeah I thought they were going to show something cool like multi-tenant architecture. Odd to write this article when it was clear they expected to be impacted as they were reaching out to customers.
I think you're missing the point. What I took away was that: "Because we design for zero dependencies for full operation, we didn't go down". Their extra features like tiered storage and monitoring going down didn't affect normal operations, which it seems like it did for similar solutions with similar features.
I’m not the person you’re replying to, but I’m interested in your response to your own question if you’re up for sharing.
My uninformed opinion if you want it: No, it’s not normal for someone to speak to an attorney before traveling. That question is a tad rigged though since I do find it normal to talk to an attorney if you’re doing something abnormal[0] to a legal document, especially to a legal document used to (ideally) rigorously confirm your identity.
[0] uncommon is likely a better choice of words, but I hope the added indirection isn’t necessary in this format of discussion
reply