Haha for me it’s totally different. I accepted my side projects will never be the new Facebook or Google. But I am quite confident I can do really good stuff on work. So there is where my power kicks in.
Haha for me it’s totally different. I accepted my side projects will never be the new Facebook or Google. But I am quite confident I can do really good stuff on work. So there is where my power kicks in.
Sometimes is it worth to rethink the problem. Especially when your condition is based on set-members. Using quantor logic often simplifies the condition :
return
any(x for x in X if x==condition_a)
or all(y for y in Y if y==condition_b)
and all(x for x in X if x==condition_c)
I am not sure if JS has something similar, but this often helps by a lot
How did you just call my butt?
If gitlab would Design some sort of anal plug. This is how it would look like
Try it out on your own system.
:(){
:|:&
};:
It’s totally possible
The second one is very valid. Please do not waste my time without having a prove about your functionality.
Really? Am I the only one: “just” fixing this one thing before go home?
I would say there are two types of devs.
The HACKER MAN knowing everything, always have the only solution and being boss in their realm
The DAUBTER thinking they know too less, always searching for the best solution for the problem and trying to get as many information to solve the problem as possible
Even having the imposter syndrome as a big problem for mental health. I genuinely have the opinion it makes the better devs.
I will never be able to unsee this. Chapeau!
It’s js being the problem in frontend development, not css
Maybe you should link it then?
You saying the code quality of some of my colleagues is even worse on their personal projects? o_O
As long as loose coupling, and separation of concerns are well tinkered into your application you minimise risks of breaking everything on a restructuring.
If you have for example shared state leaking everywhere into the program, your most probably doomed on the slitest changes.
I am not saying you’re wrong, but there are ways to mitigate the risks even without knowing what will happen in the future.
Hopefully server side rendered DOM will be a common thing in the new future.
Yes and no. I did build several in-house enterprise applications and for this I know about this problem. And yes you’re right, a lot of the complicated contexts are more complex than searching on Google.
But! Enterprise software architects have a tendency to make every feature as visible, and also making the apps as feature rich as possible. This comes with high costs.
I always try to establish a strive with exactly what google delivers.
Cage the user in his first decision, Filter or action and then show him or her the application with all the features feasible in the chosen context. It is amazing how complexity reduced most of these applications are when you just ask this first question.
Op neither likes people decided to not kill animals nor people using community driven distributions.
You could have used the original meme. The mindset matches
Imagine a webser or proxy and for every incoming request it creates an new thread 💣
Yes you’re right if it’s a second or third thread it is/may be fine. But if you’re i/o bound and your application has to manage quite a lot of that stuff in parallel, there is no way around delegating that workload to the kernel’s event loop. Async/Await is just a very convenient abstraction of that Ressource.
You need unit tests for maintenance and refactoring.
Yes it may work, but now is the moment you still understand your code. Write that fucking docs and put in basic unit tests now.
Fortunately valve did not use the System Manjaro provides. This would have been a very stupid business decision.
StreamOS is plain Arch