The general position under English law is that IP rights created by an employee within the course of employment automatically belong to the employer; where there is any doubt as to whether an employee or their employer owns IP rights, the relevant legislation largely favours employers."
It's been that way for decades, while the UK was in EU.
I had to get it written into an employment contract that Open Source activity outside of work was my own.
I mean, fair enough if the contract mentions working in your free time to use / contribute to the IP of the company you work for (or that of the competitor), but I was more referring to working on hobby projects not relating to your work.
The situation isn't any different in NL either. Although there is no blanket your-company-owns-your-**s policy (your IPs), the general rule is: if you create something in your spare time that your employer could well have paid you for (i.e. it's in line with your job description), the IP belongs to your employer.
The idea behind this is that your employer pays not just for your time, but also for the skills you acquire during your work. Therefore, the output of those skills has at least partial ownership. There's a huge gray area which contains liabilities and opportunities for both sides, which is why most companies insist on signing off on personal projects. The alternative is fighting it out in front of a judge, should it ever come to that.
If all the environments are made of rocks and water (and therefore oxygen and hydrogen atmosphere) then chemically you've got enough for converting sunlight to power, surely?
> By using a machine you switch from having one well understood, pretty standardized ui paradigm: put stuff on track, tracks goes to checker, checker checks them through, you pay and bag your stuff
Even this is not universal. In Sweden the checkouts have that divider so the checkout clerk can start scanning the next customer's products while you're packing.
In the UK, you can't move on until the other person has bagged and removed which you're expected to do before paying, which makes self-checkout considerably faster because you're already bagged.
Most houses don't have an external mailbox, the mail goes through the front door and into a basket. A lot of houses on terraced streets have no front garden and open directly onto the road, especially in cities.
There is doorstep letter and parcel collection for less than a dollar.
There were shops which had ways to get data on and off mobile phones possibly with custom cables, I'm not sure how they did it. I had a Nokia data transferred to a Samsung once.
I think they could also SMS the ringtones to the phones.
For this purpose, 6 feet and 2 meters are the same measure.
It's "about this far apart" and the UK isn't going to advise their population to "stay at least 185cm apart" anymore than the US is going to advise "stay at least 6'6" apart".
Not breathing the same air and not sneezing / coughing / speech spitting on others is what the 6 feet, 2 meters numbers are about.
As usual the best solution is one that avoids the problem. If working remotely is an option, if not even being at risk is an option, just don't place the bet and keep holding that curve down.
If anyone is still thinking in terms of "like returning to normal", at least before there's a wide-spread and effective vaccine, they're already starting from the wrong foundation of thought.
Nodejs is faster than Python as a general rule, anyway. As I understand, Nodejs compiles Javascript, Python interprets Python code.
I do a lot of Django and Nodejs and Django is great to sketch an app out, but I've noticed rewriting endpoints in Nodejs directly accessing postgres gets much better performance.
CPython, the reference implementation, interprets Python. PyPy interprets and JIT compiles Python, and more exotic things like Cython and Grumpy statically compiles Python (often through another, intermediate language like C or Go).
Node.js, using V8, interprets and JIT compiles JavaScript.
Although note that, while Node.js is fast relative to Python, it's still pretty slow. If you're writing web-stuff, I'd recommend Go instead for casually written, good performance.
The compare between Django against no-ORM is a bit weird given that rewriting your endpoint in python without Django or ORM would also have produced better results I suppose.
Right but this test focused on concurrent IO. The bottleneck is not the interpreter but the concurrency model. It doesn't matter if you coded it in C++, the JIT shouldn't even be a factor here because the bottleneck is IO and therefore ONLY the concurrency model should be a factor here. You should only see differences in speed based off of which model is used. All else is negligible.
So you have two implementations of async that are both bottlenecked by IO. One is implemented in node. The other in python.
The node implementation behaves as expected in accordance to theory meaning that for thousands of IO bound tasks it performs faster then a fixed number of sync worker threads (say 5 threads).
This makes sense right? Given thousands of IO bound tasks, eventually all 5 threads must be doing IO and therefore blocked on every task, while the single threaded async model is always context switching whenever it encounters an IO task so it is never blocked and it is always doing something...
Meanwhile the python async implementation doesn't perform in accordance to theory. 5 async workers is slower then 5 sync workers on IO bound tasks. 5 sync workers should eventually be entirely blocked by IO and the 5 async workers should never be blocked ever... Why is the python implementation slower? The answer is obvious:
It's python specific. It's python that is the problem.
The general position under English law is that IP rights created by an employee within the course of employment automatically belong to the employer; where there is any doubt as to whether an employee or their employer owns IP rights, the relevant legislation largely favours employers."
It's been that way for decades, while the UK was in EU.
I had to get it written into an employment contract that Open Source activity outside of work was my own.