andix

45 ms·

961.
by andix 3y ago
Always report anything suspicious to the flight attendants. In the past there were some accidents that could've been prevented if passengers spoke up. As a passenger you have no idea what is dangerous and what isn't. And the cabin
962.
by andix 3y ago
If I had to chose a name for it, it probably would be "Regex 401".
963.
by andix 3y ago
I think this kind of complexity is not the reality of most developers. They just stop all old services, update them and re-start them during a maintenance window.
964.
by andix 3y ago
I'm convinced that development and operation (deployment) should be thought of separately. The branching model for the code should only serve the purpose to create a working product (artifacts of some kind). Those artifacts should be v
965.
by andix 3y ago
Whenever I even mention doing trunk-based people look at me like I'm an idiot and have no idea about anything. Same if I say "I'm not doing TDD, because I think it's bad". I've seen so many people claiming to d
966.
by andix 3y ago
I get that. But aren't we all struggling with complex branching strategies and microservices, because someone told us "that's how Facebook/Google is doing it!"? :D
967.
by andix 3y ago
I don't like long lived branches. For me a branch is work in progress. Work should be finished, once finished the branch should be deleted. If you start work again, create a new branch. But sure, if supporting an older release is some
968.
by andix 3y ago
If Google and Facebook are doing it, then we need to start doing exactly the same! /s
969.
by andix 3y ago
How I've done it: Just tag the commit that is used to build a release. If you need to add a fix to an older release, create a branch from the tag. Do the changes trunk based on this branch, then tag and release. If needed just repeat i
970.
by andix 3y ago
I'm not sure if any branching strategy helps supporting multiple software versions simultaneously. There is a reason why "rolling releases" are the default now. For a short while it may work to just merge bugfixes to older ve
971.
by andix 3y ago
Sounds like you can't agree on what you're doing and what your goals are.
972.
by andix 3y ago
Sounds neat, but I still think complexity is removed if the deployment is not directly linked to the code repository. For me the code repositories purpose is to build software, and operation is not it's responsibility. I prefer having
973.
by andix 3y ago
If there are multiple environments it quickly gets impossible to keep track of "what's in production" as a branch. Two possible solutions: Git tag everything that's getting deployed. Or just keep track of the commit hash
974.
by andix 3y ago
I think you're mixing up a lot of things. Trunk-based development also doesn't mean that you are not allowed to create branches. And you can still check out an older version.
975.
by andix 3y ago
Multi-repo software products maintained by the same team are another thing I'm probably never going to understand. In reality the components are never fully decoupled and nearly always released together. When splitting up a product int
976.
by andix 3y ago
I honestly don't see the drama in most European cities, it's not like in NYC. Street parking is very limited in bigger cities, so you might need to park in expensive parking garages. Or use other methods of travel. Only in areas w
977.
by andix 3y ago
There is one solution for the cookie notices that is very seldomly talked about: just don't use any marketing cookies, then you don't need consent from the user :)
978.
by andix 3y ago
It's the same for many European cities and towns. Many cities started to reduce it down to 0.5 parking spaces per flat or less, because many of those parking spaces tend to be empty in bigger cities. And just increase prices for housin
979.
by andix 3y ago
Web Components can't be (pre-) rendered server side, right? I wouldn't chose a technology that comes with this limitation.
980.
by andix 3y ago
MobX is awesome, but I never really liked HOCs. Recent React apps I made didn't have any global state management, there was no real need for it. I quickly evaluated zustand and liked the hook based API much better than mobX. Feels even
981.
by andix 3y ago
I had to learn all that the hard way ;)
982.
by andix 3y ago
I think it would be great to improve the speed of web applications. Including all the advertisements ;) But I'm really doubting if Next.js is actually solving this problem. They are heavily caching everyting, so it might bring big bene
983.
by andix 3y ago
There are cases where the wal file is not merged on shutdown of the application. I think a corrupted database can also prevent merging the wal file automatically. A corrupted database can often be repaired, but it needs to be done manually.
984.
by andix 3y ago
I have to say that I've seen Redux being abused until insanity (and probably misunderstood) much more often than hooks. And much harder to clean up that mess, because it's a centralized mess. The hook mess is usually decentralized
985.
by andix 3y ago
The more I get into RSC I have the feeling their main purpose is to pump up Vercel bills. A reason to buy more of their expensive compute resources. They are nice in theory, but I don't see that many benefits over simple SSR, or the mo
986.
by andix 3y ago
I miss the good old days without the internet.
987.
by andix 3y ago
Vite is the new unofficial CRA. Superior in nearly every aspect.
988.
by andix 3y ago
What you're proposing sounds nice in theory. But interactive UI code is always kind of a mess. In my experience react is a very good middle ground. And nobody is forcing react developers to mix too many responsibilities into one compon
989.
by andix 3y ago
My junior developers started to come to me with the question: how can I do this without useEffect? Because they already know that their PR will be rejected. Usually we can figure it out within a few minutes, and make everything less compli
990.
by andix 3y ago
I know. So either use an existing library or build your own. But don't useEffect instead.

More ›