To be honest I had always a lot of thoughts about this how Rama would be filled with air.... I mean it spins, but how Ramas filled it with air? Central Sea was one of sources, but water wasn't possible there before whole Rama being filled with air. So my thinking was always, air enters in the center, goes in all directions, hits surface which is 750 km/h... so ~40% of speed of molecules... how much it "slows down" Rama? Would there be needed some additional force to spin it? How long it would take to "calm down", and build gradient of oxygen/air in Rama...
Always was thinking about writting some simulation for it, but it was always "someday" ;-)
Just assume that Ramans were "złote rączki" and everything simply clicks together. I mean, if they were capable to build such ships in the first place, it wouldn't be (and wasn't) a problem to fill these with capable environmental control systems and suitable drive.
In the other books characters are put into hibernation so they could travel at high speeds. Perhaps atmosphere was removed and only minimal breathing mixture was provided for the passengers.
By the way, I think SciFun had an episode on this channel about O'Neill cylinder
You know that there is no Facebook in China? The same for Instagram, Twitter and YouTube.
Even Google Search is not available in China.
And not because those companies didn't want to work in China, simply China forbade them to do it.
Funny thing, even TikTok in China is blocked... Chinese audience have Douyin from ByteDance.
So it isn't like this that "bad US is doing something to poor Chinese company"
There is no Facebook in China for the same reason there will be no TikTok in the United States. Both Meta and ByteDance won't let another country run their business. Facebook was given the chance to operate in China if they complied with China's rules
I was thinking more about -Xint, or in Docker, or x86 JVM, but my guess is that somebody already tested it ;-)
Other thing is that one of developers in my team who is on M1 and 14.4 is able to run Java app, so...
As long as you have some days in office for everybody it may work, but it should not be done in this way that some people are working from home, and some are working from office. Long before COVID (~8 years before ;-)) we had situation where one our colleague was in office only on Mondays, and big part of team was WFH on Friday and sometimes even Thursday & Friday, so best collaboration was on Monday, little worse on Tuesday-Wednesday and Thursday-Friday almost nothing was happening
Yeah, but ask for developers to do better documentation and you will get angry answers ;-)
Remote work requires higher seniority, more independence and more decision making on worker side, but a lot of people don't want to make decisions, so there is a lot of meetings, calls and similar stuff which is replacing normal in office interaction. Things which were solvable in office by going to someones desk are now in need of coordinating some meetings, finding time which fits both sides and so on. Stuff which was done by talking during walk for lunch is now meeting. Meeting in person which took 30 minutes are taking 60-90 minutes because people are not build to use simplex channel where only voice is transferred. Stupid things like drawing something on whiteboard is impossible.
Working from home you don't have all this stuff which is happening next to watercooler.
IMHO WFH is making people also less happy, it is more comfortable, but makes people more miserable.
Tons of assumptions in this that don't fit with my experience. I need a meeting, now I just send a message on teams. "Hey, do you have a minute for a call? Yes, great. No, ok, when is a good time for you?"
I wouldn't say that, it just requires better juniors.
You can't do as much hand holding remotely but remote mentoring is definitely possible. But it requires employees that have above average communication skills and an ability to debug and investigate themselves.
These abilities aren't cheap but pretty much required to pass a serious Engineering/CS program. The difference is just night and day.
> Things which were solvable in office by going to someones desk are now in need of coordinating some meetings
Or a well written email.
> Stupid things like drawing something on whiteboard is impossible.
In office yes, remotely not. Simply they are having a lot of problems, they can describe why this is a problem, they may miss Daily so there may not be an occasion to ask.
It is also much easier to be busy working from home. Much easier to say that someone spend last 2 hours answering on questions on Slack or similar, or on e-mails, or was waiting for answer from somebody else (very often they will ask question before lunch break).
In office team is doing self monitoring, remote it doesn't work so well.
Especially in case where most of companies pretend to work from office working from home.
If something goes from higher ups it is constrain, team can try to squeeze into constrains, some people will be unhappy but this is something over theirs heads so they will be able to live with it (especially people who joined company before COVID). If this will be left to teams in many cases there will be peer pressure, some kind of blackmail and similar, latter this will result in a lot of passive aggressive comments and behaviors.
But it sounds better than "Sorry for terminating your positions but we need to keep our finances in check not to loose share values, and we are accountable for shareholders"
(edited from "Sorry for terminating your positions but we need to keep our finances in check not to loose share values, and according to law it is only thing we are force to do")
Public company is accountable to shareholders, in case if share prices will go down shareholders will want to know why, and some activist investor may go to the court complaining that company was able to have better financial results it should not work on some stuff and should fire people.
yeah, but in real world when this kind of problem will need to be solved people will most probably sort O(NlogN), or use priority queue O(NlogK), or even will go with something like O(N*K), almost no one will go with O(N) algo and because usually N and K are rather small and this code will not be called too often time complexity may be ignored. Still any solution shorter than O(N) will be called inefficient. And in real world they will know N and K from this what kind of problem they are solving, and this will not be hidden in mist of abstraction with assumption that "candidate should ask".
I mean, in the real world you probably use a library method. If I were an interviewer I would not be expecting the candidate know about median-of-medians (O(n) worst case). I wouldn't even expect they know a-priori about quickselect (O(n) avg). But I don't think it's unreasonable that given a few hints, a candidate could understand and implement quickselect in 30 mins. Most people know about quicksort already, and quickselect is not very different. You can even give them the partition and select_pivot function at the start and then if there's time have them fill those in. In the rare situation they haven't even heard of quicksort, you can even write the shell of the algorithm for them, and have them adapt it to quickselect.
Even then, all thats probably a bonus - a priority queue implementation, or many other possible solutions are probably good enough for me.
Moreover, with the micro-optimized SIMD quicksort algos that are perennially cropping up on this website... I would be willing to bet that "sort and take first N" is objectively faster than my crappy Python implementation -- even if it is linear time.
Always was thinking about writting some simulation for it, but it was always "someday" ;-)