Not far. Just show all changes. Like the blog article already states, for many projects you already have code formatters, so changes in format usually don’t happen a lot - and if they do there might be a reason you don’t want to hide (like… you change your rules of code formatting).
For all the other example I neither see the point why you would want to hide it. If you don’t want to see commas added in a list, make it a rule that the comma always has to be appended after the last element. Most languages allow that. Semantic equivalence? The JS example isn’t even equivalent because „this“ may have a different context.
I’d prefer to have a „dumb“ diff that simply shows all the changes instead of adding these kind of complexities. Just keep your MRs small and there’s no real issue.
The healthy workflow is: notice formatting discrepancies -> reformat -> reopen the diff, now containing only intentional, substantial changes.
Of course the edited source files should have been reformatted automatically, on save or on build, before someone opens a diff: this should never happen except as a symptom of inadequate reformatting (e.g. I decide to adopt redundant commas at the end of comma-separated lists) or abnormal operations (e.g. non-reformatted code was accidentally committed to version control).
This is default on Mac if you use the Trackpad. Just to be sure I just tested with "man ls", which is also used in the example video.
If I use my keyboard, I prefer to not have smooth scrolling.
Scrolling with the trackpad is continuous and smooth in Terminal.app. On macOS I often prefer to cat files and then scroll them myself because of how nice it feels - and how much direct control I feel like I have over the scrolling position.
I wish it worked with man pages, vim and less. But that sounds like a hard problem.
The same is still possible in PHP to include HTML code into you PHP files. But it's rarely still being done like this.
It's considered good practise to separate your PHP (business) and HTML (view) logic.
You're right. But this only means that it won't be possible that you use the same template for different slots. Personally, I don't remember I ever needed that. Actually, most template engines I know work this way (https://twig.symfony.com/doc/2.x/templates.html#template-inh..., "{% block content %}").
But still, it's easy to archieve that by just creating another sub template.
So your first template file is the layout, the second one contains the main block definition, and that definition you just include another sub template which can be reused elsewhere.
Please, please don't mix up ORMs with ActiveRecords. ActiveRecords are one way to implement an ORM, but it's not the only way. I think many say they hate ORMs when they actually mean ActiveRecords.
For bigger projects ActiveRecords suck, yes. But also you need to have some database layer logic which most likely does some Object & Relation Mapping (ORM).
Every blog post should include a human readable date. In fact, this extends to almost anything online and even offline. Timestamps are hard to read.
Use date and time:
Every blog post should include the time it has been created. In fact, this extends to almost anything online and even offline. I was reading Jan Kremers post about blog timestamps and it was not immediately clear to me what time the post was created. Only when I did a look into the HTML source I discovered the time there.
I went back to RCS ($Id$) for my blog text files, so by default I get it all in UTC. That is the one thing I hate about git, it does not allow you to tag the file with ci information. So RCS tags my entries automatically.
But a non issue to me these days, I moved away from git due to changes Microsoft made after it purchased github. I am back "home" to RCS and anon ftp.
No, that would be crazy. Ofc I want syntax highlighting. There's a bug in the newest version which removes syntax highlighting. I thought it's more common, so I understand that probably most are not understanding my comment.
https://github.com/lapce/lapce/issues/2747
There are so many unknowns and unknown unknowns in medical sciense, especially regarding the human body.
Did evolution really keep two kidneys if you actually just need one? I doubt it. When considering a donation you should also not only think about if you might die. There are more factors like quality of life. In the end, a whole organ will be removed from your body. This will have some effect.
I was wondering about that, but not enough to do any actual research. I figure that hunter-gatherer's diet consisted of a whole lot of meat (seasonally perhaps) and then two kidneys were of advantage. My doctors recommended against eating big steaks. I wasn't eating much of those before and had no need to adjust.
I can't tell the difference (six years after the procedure), but then, I'm no athlete monitoring his performance closely.
I remember reading an article about people in poor countries selling a kidney and thereafter being too sick to work as fishermen or whatever. Some charity was trying to discourage poor people from selling body parts as a get-rich-quick scheme.
I'm skeptical this will have little to no impact on quality of life and productivity for the author.
> Did evolution really keep two kidneys if you actually just need one? I doubt it.
Aside from the nervous system, pairing is the default condition of all mammalian organs which develop from the mesoderm or ectoderm: they can then go on to fuse into a single larger structure, as with the heart, but as far as I know they're never simply lost on one side during normal development.
Kind of obvious for both of them though: evolving two hearts is putting two pumping systems in parallel on the same fluid reservoir. Given how the pump works (evolution can't handle making gears in general), you'd need a precise synchronization system to keep everything working properly - you're basically much more likely to die from the "high availability" system then a very robust single system (and the usual proviso: evolution doesn't need you alive, it needs you to reproduce and the offspring have some decent chance of survival. Percentage survival rates are just fine.)
Same for the brain but I'd say writ large: easier to make an extra human then try and coordinate a redundant brain.
Those ones are much easier to answer: they require very good coordination between each other. "Split-brain" is literally a canonical failure mode in the study of distributed systems, for example. (We kind of do have two brains, right, linked by the corpus callosum; there's a reason they're so close together.)
Is there still demand?
Is it better paid? There's a German website where you can compare average hourly rates for different programming languages and according to this COBOL developers get lower than average. This might not be significant, but does someone know how the situation is globally/in the US?
If that's the mean, I wonder what the median would be – I wonder whether, for example, people with million-dollar salaries are being counted for other languages.
