True, git itself can’t prevent people from creating a mess of a commit graph.
TBH, lots of build systems mentioned here I’ve never encountered so far.
But this makes it clearer that one can’t reason about how viable a “one big monorepo only” approach mighy be by just considering the capabilities of current git, coming from a “manyrepo” mindset. Likely that was the pitfall I fell into coming into this discussion.
So AFAIU, if a company had:
… and all those apps would share some smaller, self developed libraries / components with the frontend and/or backend, then the “no submodules, but one big monorepo” approach would be to just put all those apps into that monorepo as well and simply reference whatever shared code there might be via relative paths, effectively tracking “latest”, or maybe some distinct “stable version folders” (not sure if that’s a thing).
Anyway, certainly never thought to go that far, because having an app that’s “mostly independant” from a codebase perspective be in it’s own repo seemed beneficial. But yeah, it seems to me this is a matter of scale and at some point the cost of not having everything in a monorepo would become too great.
Thanks!
But if not for using submodules, how can one share code between (mono-)repos, which rely on the same common “module” / library / etc.? Is it a matter of “not letting submodules usage get out of hand”, sticking to an “upper limit of submodules”, or are submodules to be avoided entirely for monorepos of a certain scale and there’s a better option?
Regarding tauri: One and a half years ago I looked into it as a potential alternative to using electron.
Back then I had to decide against it for my use case, because when the goal is that it’s a cross platform app, then one has to make sure that whatever “webview version” is used on all target OS, they all have to support the features one needs re one’s own app codebase.
Back then I needed some “offscreen canvas” feature that chromium supported (hence electron), but which webkit2gtk (used on Linux) didn’t at the time.
https://tauri.app/v1/references/webview-versions/
So it’s not always easy to give a clear recommendation on using tauri over electron. One really has to get somewhat clear on what kind of “webview requirements” the resp. app will have.
But I do hope this will (or maybe already is) less of an issue in upcoming years (things are moving fast after all).
I started using git-secret 2 years ago. It’s nice for making secrets part of the repo, while not being readable by anyone that isn’t explicitely allowed to do so (using GPG).
I went through setting up netdata for a sraging (in progression for a production) server not too long ago.
The netdata docs were quite clear on that fact that the default configuration is a “showcase configuration”, not a “production ready configuration”!
It’s really meant to show off all features to new users, who then can pick what they actually want. Great thing about disabling unimportant things is that one gets a lot more “history” for the same amount of storage need, cause there are simply less data points to track. Similar with adjusting the rate which it takes data points. For instance, going down from default 1s internal to 2s basically halfs the CPU requirement, even more so if one also disables the machine learning stuff.
The one thing I have to admit though is that “optimizing netdata configs” really isn’t that quickly done. There’s just a lot of stuff it provides, lots of docs reading to be done until one roughly gets a feel for configuring it (i.e. knowing what all could be disabled and how much of a difference it actually makes). Of course, there’s always a potential need for optimizations later on when one sees the actual server load in prod.
Coincidentally, I happen to have been reading into SEO more in depth this week. Specifically official SEO docs by google:
https://developers.google.com/search/docs/fundamentals/seo-starter-guide
To be clear, SEO isn’t about tricking search engines per se. First and foremost it’s about optimizing a given website so that the crawling and indexing of the website’s content is working well.
It’s just that various websites have tried various “tricks” over time to mislead the crawling, indexing and ultimately the search engine ranking, just so their website comes up higher and more often than it should based on its content’s quality and relevancy.
Tricks like:
Those docs linked above (that link is just part of much more docs) even mention many of those “tricks” and explicitely advise against them, as it will cause websites to be penalized in their ranking.
Well, at least that’s what the docs say. In the end it’s an “arms race” between search engines and trickery using websites.
Depends on the specific plugin. I’ve been doing music production on Linux for several years now. Back then things looked a lot worse than now. Most popular bridge solution for Windows plugins on Linux is yabridge atm. The README is well worth a closer read, cause it will answer many questions on how to get even more modern plugins to display correctly (i.e. JUCE based ones).
You didn’t mention how big those volumes are and how frequently the data changes.
Assuming it’s not that much data:
tar to archive each volume first, while using proper options to preserve permissions and whatever else is important for your usecaserestic, but maybe you can backup those archives separately and apply a more aggressive pruning strategy just for themYeah, basically anything that rewrites already pushed history and is then (force-) push is bound to create problems (unless it’s a solo dev only ever coding on a single device, who uses the remote repo as a mere backup solution).
Nobody can tell you in advance how far your interest in game dev will take you. Only one way to find out: start small (some tutorials, build some crappy first) and see if your interest sticks around as you up the challange.
Maybe game dev in Godot will end up being a significant chapter in your life, maybe it will just be a small sidequest. But once you’ve given it an honest try, no matter the outcome, you at least will know if it’s something for you or not. That in itself is already worth something.
And who knows: maybe Godot is just your entry gateway to something else you discover along the way, which you wouldn’t have discovered if you hadn’t taken on the challange in the first place.
Yeah, truely! There’s plenty of “data written” that will outlast beyond his “departure”.
I’m in the same boat as you. But considering there’s this thing called the “ad industry”, there’s bound to be a considerable portion of people that are influenced enough by ads, even just at a subconcious level, that investing money into ads is a worthwhile thing to do for businesses selling products and businesses offering ad platforms.
Yeah, especially when considering that placebo and (in this case) nocebo effects are a real thing.
What do people think would happen when being told they will be very likely diagnosed with an incurable disease in 5 years from now? Do they think their levels of stress, anxiety, negative thinking etc. will stay as if they’d never heard of that information? No, likely not. Therefore their health will potentially be affected negatively just by knowing of that information.
But the important part here is the “incurable”! Reason being that if there’s any chance one can prolong good health for longer by acting in a preventive, health supporting way couple years sooner, then yes, it likely would be better to know earlier and change something about it even if it’s likely to affect one at some point.
And what makes it even trickier is that nobody really knows what future medical advances will be like. What’s called inevitable and incurable now, might, with early treatment, actually no longer be in the not too distant future.
Have you ever learned about the following in VIM:
H,M,L,22H, …,: vertical cursor placementzt,z0,zb: vertical scroll positioning0,$,gm,gM: horizontal cursor placementw,e,b: word based cursor movementSimply holding
jorkat times also works, even more so with a decently high key repeat rate.Of course there’s a lot more: https://vimhelp.org/motion.txt.html
The trick is to only learn a couple new movement mappings at a time and use them during one’s workflow for a while, up until they feel ingrained. Then repeat, iteratively building up one’s movement skills in VIM.
One can say many things about VIM, but not that learning it’s movement mappings will make your required APM (let alone mouse clicks) go up to “get stuff done”. Honestly, once a basic set of these movements has been learned, any other editor without them will feel like a drag.