From the experience I have from doctors in Portugal, they will ignore that. My brother was not even warned by the doctor that he was pre-diabetic after checking his blood results.
Question for the experts here :)
How much better is, regarding eyestrain, to go to a 27' 4k monitor instead of a 27' 1440p one? What about refresh rate, does it help with that as well?
I agree with that when the problem is irreversible and will cause unending pain for the person. However, this case does not seem like it. If she had like Parkinson or Alzheimer then I would understand but depression? There are very good anti-depressants that help go through if she cannot find another way to cope. Also, there might be something physically wrong that doctors might have overlooked which causes her depression.
You should always be free to destroy yourself absent any medical reason or justification. It is a personal decision and there is no reason anyone should be required to explain or justify it.
We don’t require a medical reason to enhance or build our bodies, we don’t need one to damage or destroy them.
I’m already allowed to eat fried foods 10 times a day and chainsmoke and do it slowly and painfully; if that is legal then anyone should be allowed to do it in a quick, painless, and dignified fashion.
The question is: What if the depression she has has a cause that can be curable 100% and she can have a very happy life, would she still want to do it if she knew that?
I am not sure that we "should be free" to end our life as you say. Sure, we did not have any say about coming to life but I think that if you don't have any incurable disease that causes you significant pain, you can always find something that will make life worthwhile. Unless you are born in Northern Korea or some country that restricts your freedom.
This makes sense to some extent (terminal illness or such), but one can argue as someone did above that if you're willing to make the permanent decision to "destroy" yourself, are you sane enough to legally make decision? Are you for sure not under temporary delusion, distress, or other threat? You can always "legally" "destroy" yourself through suicide, but if you want to involve a medical professional it seems very reasonable that you have the mental clarity to make the decision.
Should it be illegal for the doctor to deny me an amputation that I ask for? After all, I should be "free to destroy myself" absent any justification?
> You can always "legally" "destroy" yourself through suicide
Not in a dignified, foolproof way. E.g. can you go to a pharmacy and get a dose of morphine that will kill you with certainty? You can't, in most jurisdictions.
Forcing other people to deal with the trauma of cleaning up your bloody remains after you jump off a window isn't exactly compassionate either.
Give people a clean way out, even if you don't want it for yourself.
Recently I was reading the Learn CSS the pedantic way book and the definition for inline boxes did not match the way that anonymous block boxes were generated when an inline-level element had a block-level element as its child. So I went looking elsewhere for a more appropriate definition for that case and found this issue on standards: https://github.com/w3c/csswg-drafts/issues/1477 It was really interesting to know that I was not the only one confused. My question was: Does the inline-box generated by the inline-level element contains the box generated by the block-level child or there wasn't an inline-box that was a parent of them all but there were 2 siblings inline-level boxes of the block-level box that were wrapped in another anonymous block boxes? Reading that issue I got to know the concept of fragments, which I did not know browsers had. But the issue seems to suggest that the box tree for this case should have the inline-box as being a parent of the block-box. Which led me to another question, in that case, if I apply a border to the parent inline-level element, shouldn't it apply to the overall box that is generated (it does not)? The answer is that borders between block-boxes and inline-level boxes should not intersect but that is really difficult to derive from reading the standards alone. Anyway it was headache-inducing trying to learn the box-model pedantically :)
I wish I could learn more about layout in browsers and I trying to read the code of LayoutNG in Chromium but I need more aspirin hehehe
Dead Space series (specially 2), Max Payne, Metal Gear Solid 3, Silent Hill 2, Rule of Rose, Mass Effect 3 are the ones I remember that I enjoyed its story and cared about the characters pretty much.
- Android tablets have the Opera browser which has text reflow functionality which works much much better than anything else. This is a huge deal for me.
- I can access the file system and do whatever I want with it.
- I still like notifications more in Android vs iPadOS.
If it were not for these things, I would buy an iPad in a heartbeat.
Question: For mobile apps, wouldn't gitflow be more suitable, since the app is only released after app store validation? The release branches here seem to match well this purpose. Just to curious to know how trunk-based development is applied in practice for mobile apps.
That release branches make sense in some circumstances does not mean one has to take all of 'git flow' on board. This is the problem that the comment you are responding to notes. One should design a branching strategy depending on what one needs to do and not do things because one has a branching strategy.
True but I have seen people claim TBD should be used in all cases and I was trying to get some insights on how people use TBD for mobile apps as using release branches is not TBD as well.
I love TBD. But it has its places. For mobile apps I've used (and would use) release branches. You have a hard requirement on the way that app stores work.
You can still do TBD for most of the development of new features, though.
We always worked in a way where the master branch is running a regular release train into our internal / beta / preview release (depending on company and audience size). Both major play stores provide ways of automatically and regularly releasing builds with minimal review (internal channel, TestFlight, Firebase app distribution. etc). Those channels are fed directly from master and used for testing, showing demos to customers and other bleeding edge use-cases.
One of the builds is then chosen as an "actual release" and promoted to the release channel in the store - the commit with the cutoff is tagged in Git.
If, for some reason, a patch needs to be applied to that exact build, you can always branch off from that tag and apply patches. But that was usually avoided and a newer, fixed, build promoted as release instead. I think we had to backpatch things less than once a year and only in very rare cases.
# We always worked in a way where the master branch is running a regular release train into our internal / beta / preview release (depending on company and audience size).
Care to elaborate how you decide if it is an internal / beta / preview release? Some kind of tagging strategy or are all generated at the same time?
Oh we just chose one (I just used slashes because different systems used different names). In reality we had only two builds - the "daily" preview that was built automatically when PRs merged and were used by developers and beta testers (we published to beta channel) and the actual releases that went to production (which were market with git tags).
Release branches are fine (mobile apps, sure... web apps, probably not). Again, context is key.
You can still integrate to trunk as one would expect in TBD, no need for the delayed integration in Gitflow.
A common practice I see with mobile teams is they will create a 'release/x.y' branch sourced from trunk as part of their release routine (at some regular cadence, like 2-weeks).
If they need to (surgically) apply a hotfix, they can apply it to the release branch. Since the app store review process makes deploying immediate fixes impossible, a stronger emphasis on staging/RC QA is good as well.
