What you expecting called natural sorting. Mac employed natural sorting back in 90s. What you get is legitimate Alphabetical sorting which used by Linux and Windows. Natural sorting parses tokens in the string and compares them. Alphabetical sorting compares two strings by comparing individual characters at same index (position). Alphabetical sorting is quite common as it simpler to implement (or rather harder to screw up) and yields predictable results

One of many libraries for Python which implements natural sorting https://github.com/SethMMorton/natsort

I’d leave my job if Musk would become CEO at my job.

If administration does not change agency’s policy in the the way it contradicts your moral I’d say it’s ok

No, that means you falling into author’s bait where they misuse term “delete”. Refactoring is not equal to deleting. One can be result of another. But the truth is that extendable code needs to be modular to be extendable. And modular code is easy to refactor. Author couldn’t not name it “Write code that is easy to refactor, not easy to extend” coz it’s even more dumb

No, title only

Right, but my initial comment was about article’s statement being wrong. Refactoring in the way you described will make code harder to delete which is bad according to the article.

I don’t understand too. Are you suggesting me to drop bunch of features in the product?

TLDR;

My current project has mostly easy to delete code and not easy to extend. Why? Coz shit was copy-pasted 50 times. It’s not fun to work in this project.

Post commit hook to push + always squash on merging feature branches

I mean, mom could be right. Maybe there’s a rule on router to block Fortnite servers after 21:00. She just doesn’t tell that she the one turning it off

He just applied Russians’ favorite soviet era saying “those who is not with us is against us”

Whatever, I’m using it regardless of what shitty commercial alternatives tried to be shoved down my throat. If Draw.io goes shit I’ll just switch to ditaa

After closer look I can say this is great idea. Initially I thought this messes with Lit’s lifecycle bringing React’s lifecycle drawbacks but seems like it’s not. I think at some point you should get in touch with Lit devs and see if it can become part of Lit lab or even Lit itself

Is it better than React functional components in any way? I don’t see benefit over React functional components or even Lit’s class components

AFAIK major contributor into low Chinese EV prices are subsidies and tax breaks for manufacturers. I know they have significant tax breaks in US. It would be interesting to see how they compare. Because if they are mostly on par this is pure corporate greed stopping them. Especially in case of Tesla. They are not overpaying workers and don’t use luxury materials

Though in reality, management will push back any unorthodox approaches/solutions/approaches as risk and additional losses on R&D.

‘’’ Note: When I say “top-level” I am talking about the URL that you see in the address bar. So if you load fun-games.example in your URL bar and it makes a request to your-bank.example then fun-games.example is the top-level site. ‘’’ Meaning explicit creds won’t be sent. Even if fun-games knows how to send explicit creds, it can’t because fun-games does not have access to creds which stored for your-bank. Say suppose your-bank creds stored in local store. Since current URL is fun-games it can only access local storage of fun-games, not your-bank.

Thank you! I was always wondering why the heck this (mostly) useless and broken mechanism exists. I had hesitations about disabling it but had doubts about my understanding. Now I know I’m right

“Stateless” is not what “I” want, it is part of definition of REST.

Can do != what spec says you should do. You can also send clown version from the post but don’t be surprised people will find it… funny

Again, I’m not telling you are doing wrong. I’m telling you are mixing REST and RESTful web services

REST calls are same as in 2001. There is no REST 2.0 or REST 2024. Because REST is architecture guideline. It’s just more data sent over it today. HTTP code IS code. Why your system issued it is implementation detail and have nothing to do with resource representation. Examples you provided are not 403. “Too many users active” does not exist in REST because REST is stateless, closest you can get is “too many requests” - 429. Insufficient permissions is 401. I don’t even know what is “blocked by security” but sounds like 401 too. Regardless, you should not provide any details on 401 or 403 to client as it is security concern. No serious app will tell you “password is wrong” or “user does not exist”. Maximum what client should hope for is input validation errors in 400.

For those with “internal tool, I don’t care” argument - you either do not know what security in depth is or you don’t have 403 or 401 scenario in the system in the first place.

Now hear me out, you all can do whatever you want or need with your API. Have state, respond with images instead of error codes, whatever, but calling it REST is wrong by definition