Order flow in dark pools does impact the price of a security. The market maker will eventually need to trade out of that position. If there is aggregate buying pressure in the dark pool, they will adjust their quotes in both dark and lit markets.
Thanks, regarding transaction fees, I was referring to slippage (should have said transaction cost). This depends a lot on your customers rebalancing settings, but it would be good to be able to compare that directly to VOO.
Its not the median they are worried about, its the 99th percentile. They _dont_ want to trade with Optiver, 2 Sigma, etc, or some hedge fund thats working a massive trade.
Trading with a highly sophisticated counterparty can be very costly and undo the small profit they have made from thousands of other trades.
Do you manage the portfolio of each customer individually? How closely will this match the target portfolio for smaller investment sizes? I see that there are minimum investment sizes. Do I need to buy at least one share of each member of the SP500 for instance?
How do transaction fees compare with expense ratios of, say, Vanguard? I see that you account for them in your backtest, but it would be helpful to represent that in terms of an expense ratio.
I built an OAuth proxy (only Auth0 currently works) hosted on Cloudflare workers. I'm a big fan of the self-hosted OAuth Proxy [1], but some projects don't lend themselves to hosting a container, sometimes you just want to set up a simple app on Heroku, Fly, Workers, etc. and have an auth proxy sit in front of it.
My solution also manages SSL via Cloudflare and integrates with Stripe for simple fixed-price subscription billing models. The idea here is to be able to iterate on product ideas quickly without spending a day each time figuring out authentication and billing.
I did set up a marketing site at the time so that others could use it, but I don't have any users, and I'm happy to maintain it just for my own projects (half a dozen now).
It took me 2-3 weeks to make so on net I have probably not saved much time, but it really helps reduce the friction of launching things which I think is valuable.
I may be biased because I generally avoid closures entirely (I prefer the certainty over ownership and type signatures that traditional functions give), but I do my best to avoid closures when working with async in Rust. A lot of examples for frameworks will make use of async closures, and I typically convert those to functions as quickly as possible, which can be tricky the first time because of the elided types.
I'm not sure about the subreddit, but from my reading of the forum, there is still quite a lot of work / discussion to be done related to implementing said strategy in a tax efficient manner, directly purchasing bonds rather than using the ETFs, usage of TIPS, alternative asset classes like real estate, and portfolio allocation given age, etc.
I've learned that maintaining even the simplest "strategy" can be a lot of work.
I’ll second the charger. I recently bought the Shargeek Storm 2 battery and bought their recommended charger (100w GaN) on a lark. This turned out to be much more useful than the battery itself (although the battery has been great too).
I’m able to charge MacBook, iPhone, Watch, AirPods all from one brick at the same time, which means I only have to carry one brick.
I will say, I don’t believe it will charge at 100w on the main port when other ports are in use, 100w is the max across all ports. Still, I’m considering purchasing their new 140w option now to take full advantage of MagSafe.
Very cool site. The salary filter is a little unintuitive: the minimum filter appears to apply to the _lower_ end of the listed range, and be non-inclusive. For instance there is a job listed at Netgear with a range of $300k-400k, if I set the filter to $300k, it is not shown. I would probably expect it to show until I set the filter to $401k or more.
Edit: I see now that it is filtering on salary (which is visible if you look at the listing details), but the summary is showing total comp.
What confuses me is that I know for a fact that several of those projects have or will be joining the CNCF, so I’m not sure they are in need of a governing body.
What you says is true, it can be very difficult to submit ad-hoc patches to large projects. In my experience, however, this has been due to brittle, undocumented automated checks and newbie-hostile maintainers who have built a complex contribution process. I'm not convinced that a different version control system would change this. There are also many projects on GitHub that are very pleasant to work with.
It is definitely a broad term, and I think that disciplined implementation of the things that you mentioned is the real key. It just isn't as exciting to talk about.
I find "distributed systems" to be a huge source of imposter syndrome. Despite having worked almost exclusively with distributed applications for several years now, it is difficult to consider myself experienced. When I'm asked if I've worked with distributed systems, I don't think they are asking me if I've managed a Hadoop cluster. They are interested in building new applications using some of the primitives discussed in this post. All of these links are great, but the fact is that building and operating tools like this is hard. In addition to consensus primitives, your system may need very precise error handling, structured logging, distributed tracing, resource monitoring, schema evolution, etc. In the end, I probably pause for a second too long when answering that question, but I don't think its because of a lack of experience, quite the opposite!
I'm not sure how the broader community does it, but the Rust developers that I know (myself included) will typically get the code working and compiling with panics and unwraps (especially when working with a new API or just experimenting) and then do a second pass to "remove panics". This typically involved reviewing your code thoroughly, finding each panic / unwrap / expect, and using this to identify how your functions can fail. This is a good time to create error types for your API and note these cases in your documentation. You then convert functions which can fail to a Result and all of the unwraps etc. to ?. This can be fairly mechanical and really gives insight into ways that your code can fail and edge cases, but does take time.
As far as loops vs maps, I've found that your use case typically guides this. I think this is the same with other languages like Python. You aren't going to want to write a ton of complex logic in deeply nested maps and filters. But if you just need to do something more simple it might make more sense to do it in a map one-liner.
Edit: The presentation linked to in the other reply appears to confirm this process of starting with dirty compiling code and then refactoring out the possible failure modes. It covers a lot more things like using match and handling errors from other libraries.