That someone being me not knowing why in hell would I write this monstrosity... git blame + some archeology work to get jira ticket number (I put issue numbers in commit message/branch name) and from that I know why.
Much of my life as an older dev includes balancing my relationship with my past, current, and future selves. Be kind to your future self; be compassionate of your past self. And don't forget, they really are different people ;)
I thought about some about 360 videos and oh boy it looks hard. First of all it uses obnoxious amount of data. Oculus go for example has resolution of 2560 x 1440 (1280x1440 per eye) and horizontal fov in region of 90 degrees. You need about 5k in horizontally to fill 360 degrees of horizon and at least 1440 vertically for video to look decent. All this bandwidth and even that is not that good. For best vr experience you would need to go for 360 3d video so final resolution is doubled. That gives us 5120 x 2880 video. Couple that with 60fps for additional immersivness and I don't even want to know how many gigabytes you will need for any mid length video. And that is only technical part of problem.
Second problem is that there is no framing in cinematic sense. You don't worry about filming crew accidentally getting in frame or bouncing off mirror. You need to either hide them entirely or embrace somewhere in 'frame'. It's okish in documentaries or videos from live events (eg music concert from front row). Immersion in headset gives you another problem. Any scene cut needs slow fade to black so you don't induce motion sickness (no fast action scenes with changing camera every other second). Speaking of motion sickness, camera must be fixed or move very slow.
Vr and 180 or 360 movies are very young and we need whole new generation of filmmakers but from what I have seen it has great potential. Properly made 180 3d films are immersive and you actually feel like you are there
So much this. I don't see myself deploying anything big in Erlang anytime soon but learning it (and building one or two small projects) gave me intuition about message passing concurrency. This knowledge transferred very nicely to Android programming with Kotlin coroutines. My colleague was astounded learning how easy it is to model concurrency with actors and channels and how much of it just works.
From linked post:
Note: Your "Linux files" are any of the files and folders under %localappdata%\lxss - which is where the Linux filesystem - distro and your own files - are stored on your drive
It does say later on that storing files on windows filesystem and accessing it via /mnt/c is ok
As hard as rust is in itself, it tries to lower most of the other barriers to entry for new programmers. I think that central package repository coupled with sane package manager and consistent documentation is must have for any new language on the market. Both Rust and Elixir have official package manager and repository with documentation hosting and it makes life much easier. This and not having to worry about another holly war later on.
I feel the same. From my own experience, I've done both 9h-10h of productive work for few weeks in challenging projects and 8h ass-in-seat in crappy and bad managed ones.
