Also, see this project that is in a similar space as Coursier:
15,024 karma · joined April 22, 2012
The closest thing available is probably public health guidelines. These are reliable, evidence-based resources that have been carefully crafted to be useful to all people. For example:
https://www.nhs.uk/conditions/baby/caring-for-a-newborn/
Of course, the context of a public health guideline is limiting. The average person cannot be given the whole, messy truth. The public health guidelines are a way to simplify that complex landscape, and provide a guide that is easy for that average person to follow correctly and safely.
Breastfeeding often does not come as naturally as one might think. A newborn's brain may be barely developed enough to do it. It is not unusual for new mothers to enter a state of negative thinking as a result of breastfeeding difficulties (or anything else, really). A lactation consultant can help a great deal. They can provide advice on technique, and they can act as a coach/therapist.
The postpartum period may be difficult for the mother. Try to be a keen observer, and don't hesitate to ask your doctor for advice on how to proceed if it seems like things are not going well.
On a related note: seek help. In the context of the entire history of human parenthood, it is very unusual for the two parents to be the only direct caregivers of a child. If you have a support network that would help you, make use of it. This could be family, friends, neighbours, or people from some other community group you are a part of. Hire someone to help if you can. This is not just about helping hands; it is also valuable to receive outside input and emotional support. For example, someone with parental experience knows that caring for a newborn is typically straightforward and easy in many respects, whereas a new parent on their own may find it overwhelming and frightening. Even just having someone at your side will help make you feel more at ease. It is also very nice to have a reprieve.
I recommend this series of articles on baby sleep, sleep training, and more:
https://www.bbc.com/future/article/20220131-the-science-of-s...
https://www.bbc.com/future/article/20220322-how-sleep-traini...
I also recommend this subreddit as a jumping-off point for more evidence-based resources (the typical caveats about information from social media apply):
Our user-friendly and featureful website was a big part of our appeal. A lot of the non-Rails functionality was the unseen "secret sauce".
I think this approach worked well. Most of what you need for a web app is commodity functionality. Correctness is not even particularly important in many cases. The Rails ecosystem has a lot of useful tools that make it easy. For example, there are multiple options for automatically adding a comprehensive admin panel. This let our non-technical admins manually accomplish CRUD tasks in the web app's domain. This allowed us to avoid overengineering. We could implement something that covered 80% of cases, and manually handle any edge cases or things that happened infrequently. An example is locking user accounts when a person left a customer's company; they could just email us and an admin would manually go in and check the "locked" box for the user. This allowed us to move very fast on new web app features, and focus on other aspects of the system.
There were downsides, of course. One of the big pain points was upgrading Rails itself, and dealing with dependency hell at times with various libraries. You also have to know many things about how Rails works, which involves a lot of quasi-mysterious and implicitly-performed things. For example, I recall frequently coming across function calls, and then I would look for the function definition, only to find that it was a function that doesn't exist in the code and was generated at runtime by Rails.
edit: This comment I made recently is relevant, since it speaks to the motivations for using a monorepo and trunk-based development within a business: https://news.ycombinator.com/item?id=41293123
Piper <-> Mononoke
CitC <-> EdenFS
Obviously, the immense scale of these companies constrains the possible solutions. I would be interested to know what design decisions are different between them.
It doesn't necessarily indicate much about the deployment model. You can have many separately releaseable things in one repo, and you can have one independently releaseable thing based on the sources of many repos.
Monorepos enable, but don't require, source-level co-evolution. Or maybe a better way to put it would be: many projects can have a shared history. Many-repos require independent source-level evolution. In the open source world there is no real choice: every project wants to be independent. The authors of a given project can do what they wish with it.
One weird thing to think about is that monorepos can accomodate many-repo style workflows. You can still develop projects completely independently within a single repo. Of course you can store separate projects on separate revisions, which would be weird. An even weirder approach would be having all projects in a given revision, but have totally independent builds, no single-version policy, no requirement for atomic compatibility, et cetera. These are all things that are often imposed for monorepos, but that are also not requirements. Basically, you can treat each project as independent even if their sources are stored together. I don't think there are any reasons to actually do this, of course.
In a standalone project, would you accept a change that is incompatible with other code in the project? For example, would you allow a colleague to change a function in a way that breaks the call sites? No, you probably would not.
The attitude within monorepo shops is that this level of rigour should be applied to the entire company. Nobody should be able to make a change anywhere if it would break anything elsewhere, or they should only be permitted to do so with intention. There are caveats to this, but that is the general idea.
To reformulate the statement made in the intro of this post: "maybe it’s not a great idea to outsource _any critical_ functionality to random people on the internet."
It has long been a standard, best practice in software engineering to ensure dependencies are stored in and made available from first-party sources. For example, this could mean maintaining an internal registry mirror that permanently stores any dependencies that are fetched. It could also be done by vendoring dependencies. The main point is to take proactive steps to ensure your dependencies will always be there when you need them, and to not blindly trust a third-party to always be there to give your dependencies to you.
I prefer using long options in shell scripts for similar reasons. Easier for future maintainers to search for.
I have yet to see this ever happen, despite working in Java shops using Optional heavily since it was included in the JDK. I would guess that this is due to developers using better tooling. IDEs commonly provide warnings when returning null, or when violating a "soft" nullability assertion marked by an annotation. NullPointerExceptions seem fairly rare.
There are alternative models that are more considerate of student happiness, such as: https://en.wikipedia.org/wiki/Summerhill_School
Any experience with VMWare Fusion or Parallels?
The problem I had with UTM was that occasionally I would attempt to switch back to the guest, and I would find it "dead": unresponsive, no visual output. I sought help from the community on debugging the issue, but I could not determine what was occuring. My use case is perhaps not common, so not many people have run into the same issue with such a new project.