What your link shows is that train punctuality in 2022 was 92.5 %. That is shocking bad. Back in 2018 at least 10 countries were doing better than Switzerland.
Once more a variation on how to lie with statistics... It does not matter if the overall statistics show a somewhat high value, mostly driven by predicable and frequent travels between Cantons in the mountains, where there is maybe just one track. What matters is the experience of the majority of commuters on urban centers. From [1] in 2022, the year of most recent statistics.
"The punctuality values in the last three months on some major intercity routes are below the threshold:
Zurich HB - Bern: 73.5 percent of on-time arrivals and departures
But you are doing the same thing. Switzerland has a high standard of 3min is late. What actually important if you make your connections. In Switerland you make your connection like 98ish% of the time.
This article picks out some of the worst lines over a very short time period. You can do that in most networks. Some German ICE lines have 23% on time.
I ride some of those city to city pairs and those numbers don't line up with my experiance over the last couple years.
I'm not sure how Statista got their info, but most other countries define "late" as being more than 5 minutes behind schedule. In Switzeland that limit is lower with only 3 minutes not counting as late.
Can’t tell from that link but historically the Swiss punctuality standard is three minutes where other countries use five or more, Japan being the notable exception.
CFML was the easiest way to get into dynamic, server-side rendered pages back in the day. It was insanely productive and easy for a person cutting their teeth on programming as it was such a small leap from HTML.
I don't know of anything that still ticks those boxes but if you're just looking for (1) easy-ish, (2) interspersing HTML tags and code, and (3) server-side rendered simplicity, then PHP is still a very viable successor.
Disable source maps in the debugger. They are likely the source of your frustration and frankly I still do not understand why they are on by default given how bad the experience is of actively debugging with them on.
That’s not under the conditional breakpoint heading. You would just override the value to be a getter in the console, or you could even change it in your source code if you have write access.
Thanks, I know I could do it in the console or the original source. But I was referring to the fact that the sentence in the post says to convert it to a getter "either in the original source code or using a conditional breakpoint."
You can put any expression into a conditional breakpoint, so anything you can do in the console you can do in a conditional breakpoint.
So, if you're doing this sort of thing once, you can just type it into the console and you're golden. But if you want to modify a stack local variable over and over again every time it is initialized, it's much easier to do in a conditional breakpoint because then it will happen every time that line of code runs, and your debugger never has to pause. (see https://alan.norbauer.com/articles/browser-debugging-tricks#...)
I'm the author of the article and my advice is that you stop reading it and go learn about Replay.io instead. It's the most slept on web tech and will up your debugging game immensely. Seriously, go check it out.
You can't have 100% test coverage with these kinds of bugs, because these bugs create unreachable expressions.
You can either find out you have these bugs from lint errors or you can find out by finding them in code coverage reports while chasing 100% code coverage. Most people would obviously prefer the former.
>Over half (58%) of 6,000 professionals who responded to a recent Glassdoor poll said they’d never return to a company who laid them off. In the tech sector specifically, just 46% of workers said they’d boomerang. Men were slightly more likely to consider boomeranging than women, and older workers were more open-minded than younger ones.
It's not a super majority, but 54-58% does feel like "masses". I can see it both ways here.
Even this isn't very relevant. So they won't return to the company that laid them off, but that doesn't mean they won't work for a different company that laid off other people. I highly doubt any of these companies will have a hard time hiring people because of their layoffs. In the end, people will still go work for them because they pay at the top of the market.
>So they won't return to the company that laid them off, but that doesn't mean they won't work for a different company that laid off other people.
Sure, but I think the point is less "companies that layoff lose good employees for good" and more "if you layoff employee you lose that tribal knowledge forever". Is that something that a company will die from? Probably not, at least not in one fell swoop. But having half the people feel that way is some non-neglible brain drain.
Remember that part of the original reason the Big companies paid that much was as an anti-poaching measure. They didn't want competition getting top talent nor for top talent to be future competitors as they startup their own business. I wonder if the latter is going to pop up more with these kinds of movements.
