243 karma · joined October 4, 2017
What if users' possession on FTX are actually valued much less now?
Corporate governance, accounting, and all the other boring stuff should literally be the first things which you should look at when assessing whether to fuel or not an exchange.
Something very similar is also written in Cal Newport's Deep Work book, where Jack Dorsey's typical day is outlined just as a series of interruptions.
I guess that tweeting between these interactions is not that time-consuming for him, + he actually sleeps at the workplace and is 100% focused on work.
Consider that Apple is also 25% of total assets of Berkshire (around 250$B), so it's not much of a surprise that Berkshire is going into the main manufacturer of the biggest stock they have - hence the strong linking between the wto.
You could then use (e.g.) OpenID to connect to the specific instance of Supabase with those secrets from your application
They surely must have saw that there is a hole to be filled, but I find it a bit hard to see them surpassing Gumroad.
Also, I would say that the difference is not much "scaling" a CRUD app for request/seconds, but for engineers on a single codebase/service, also architecturally. It's one thing to work alone on your project (which will probably handle k req/s, it's very easy nowadays with classic PostgreSQL and some other queues like RabbitMQ if you need event-based system). It's another to work on the same system with 100x more features, complexity (either in the same monolith or in different micro-services), and especially understand how to be pragmatic and solve problems you did not account for.
No amount of study can prepare you, other than first years at work. Afterwards, in my opinion, the challenges become improving the technology to scale more, and management.
Unfortunately, it is not stable yet... but we all used Terraform <1.0 for years, and I'd say the experience was never that bad.
Another interesting platform which grows on similar concepts is Composer: https://www.composer.trade
A big missing piece in OP's project is a backtesting - I think that a very important part of testing your strategy is trying it on real-world data.
Also, I think that for a platform such as yours, credit cards are absolutely a must. The risk in opening it to scammers (mining, torrent seeds, etc) is just to high; I remember reading this from fly.io [0] that explains the pain in reducing fraud.
0: https://community.fly.io/t/new-prepaid-credits-and-a-bonus-s...
Languages may not be able to restrict the operations you make on certain variables even if they are private, and even if you should use only public interface, it always happens that you try to tinker with libraries internals to get your hack working... Having this explicit in the name to me is just a stronger repetition of this concept!
No idea on the long term effect, but surely I will remember for a while being delirious for three days straight.
"Having problems" in this world (any kind, not only due to the github scale!) is something that happens - we are not perfect and we work on an incredible amount of layers of complexity.
It is sufficient to actually touch production code on a daily basis to see that it can happen to the best, with the best observability systems or processes. The key is avoiding blaming, and understanding iteratively how to fix the problems underneath (faster recovery, detection time, and so on).
Also, tools such as Tabnine take away the plumbing from coding - I am so much more focused on the high-level design and goal of what I am doing if I don't have to pass so much time trying to remember what I wanted to write...
Basically, a thread is visible at a first glance from the UI, while that's not true in Slack. Also, you can kinda replicate Zulip structure by just using channels with naming conventions, so you have: - generic channels, e.g. for status update for many stakeholders - specific channels for each feature - threads in each channel where you discuss a single point
Usually, in our workspace, it's the person leading the discussion that at some points decide to redirect the talk somewhere else
Also, I find feature-specific channels to be such a pleasure. It's easy to have everyone focused on the same topic in a given channel, without any confusion or missing information between different channels or private messages.
Moreover, I have also considered Slack to be asynchronous - meetings are necessary for sync work, but I find Slack to be working perfectly if no one expects that you reply within minutes, but within a few days (if you are not actively working on a project - in that case a lot of times is just easier to schedule very fast meetings during no-focus times)
(The documentary also touches various interesting point, such as open-source in the eyes of upper management, and so on... surely there is some better source/book/article, but I found the format pretty chill and easy to absorb)
I had the "pleasure" to work a bit with a PHP legacy server written in Laravel, and I thought that the framework was alright - the problem was in the PHP code written with it (specifically its typing). I think laravel is opinionated and can help to have a consistent codebase... curious to know why you had such a bad experience, and where you were happier :D
Imagine a code without `if result is not None` basically!