shred45

Do you know if there will be another South Bay Systems meet?

I don't think this really tells you anything, and it also will impact the quotes they are making, even if they are holding the position for now.

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.

> they make a higher than normal spread

Is this known for sure? I thought the value of this order flow to them was the lack of adverse selection.

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.

[1] - https://github.com/oauth2-proxy/oauth2-proxy

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.

This is really great, I remember the original post and had made a note to look into it myself but never got the chance.

In the third paragraph of the first section you mention the "Toledo" protocol out of the blue. Is this a result of autocorrect?

Thanks for writing this up!

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.

Location: Chicago, IL

Remote: Preferable

Willing to relocate: Yes

Technologies:

- Python (10 years)

- Rust (3 years)

- Application architecture and security (5 years)

- Project / developer management (3 years)

- Data Engineering (Python, Hadoop, Spark (Scala), Kafka, Postgres)

- Web Development (Rails, Flask, HTML, CSS, React)

- ML (training and validation, DNN / RNN / CNN, GLM, Random Forest, Bayesian Optimization)

- DevOps (Docker, Kubernetes, AWS, Google Cloud, Terraform, CI / CD)

Resume/CV: Email me please.

Email: hn_freelancing@protonmail.com

SEEKING WORK | Chicago, IL | REMOTE

Technologies:

- Python (10 years)

- Rust (3 years)

- Application architecture and security (5 years)

- Project / developer management (3 years)

- Data Engineering (Python, Hadoop, Spark (Scala), Kafka, Postgres)

- Web Development (Rails, Flask, HTML, CSS, React)

- ML (training and validation, DNN / RNN / CNN, GLM, Random Forest, Bayesian Optimization)

- DevOps (Docker, Kubernetes, AWS, Google Cloud, Terraform, CI / CD)

Resume/CV: Email me please.

Email: hn_freelancing@protonmail.com

There may be some backlash, given how painful the transition has been for a lot of people. I think a lot of people are conflating "remote work" with "social distancing". The later is the cause of a lot of your feelings of loneliness. The former can significantly increase your flexibility to maintain quality relationships. As someone who works 100% remotely, this has been an especially lonely period for me as well.

Right now, many people are still getting used to working from home, and many I suspect consider this to be a temporary measure, which has prevented them from getting settled. In a real switch to remote work, you would be properly invested in setting up a long-term productive environment. The beauty of remote work is you would have the agency to experiment and find what habits and schedules makes you the most productive, without the added constraints of the office. This process would probably take several months, and for a while you would miss the structure of the office, but I think it has the possibility to increase your productivity and quality of life.

For me, remote work does not mean that I work alone, it just means I work with a group of other remote workers that I consider to be close friends. I think it has the potential to increase quality social interactions while working, not decrease. In a society where more people are working remotely, I think the ability to forge relationships outside of work will only increase.

I think the wide-angle lens contributes a lot to this effect. I found that tree skiing was the best way to get a sense of speed with these cameras.

My problem with GoPro was that it became apparent that they relied on a yearly upgrade cycle. I'm willing to do that for an iPhone that I use daily, but not a camera that I use a few weekends a year. After they released a 1080p camera and the remote that let you operate the camera without constantly removing your helmet, I stopped upgrading. I occasionally watch their product launch videos but I just don't want to spend any more on this product space. I think the image stabilization has potential, but the 3D / 360' camera is a gimmick until there are better ways to consume and edit that content.

Another big problem out on the slopes is that phone batteries drain quickly in the cold and operating phones with gloves on is still a chore. Any app-based improvements that GoPro has introduced feel like a non-starter to me in many of the environments that GoPro is useful.

Hey, also don't have a time for a full review, but had one comment. I've been a pretty passionate user of GitLab for 2+ years and really loved the industry-leading integrated CI/CD. I have found that page load times on both GitLab and GitHub, however, are pretty bad, with GitLab being the worst. Many administrative tasks, such as logging in -> finding repo -> checking a ci/cd test -> merging / releasing the branch, take 10+ page loads, and each one is quite slow. I ended up moving my personal projects to sourcehut simply because pages are more lightweight and server response times are faster. If GitLab could spend some time reducing the number of pages required for common tasks (not asking for a single-page-app!), and could reduce page load times as much as possible (I know this isn't trivial with Rails), I think that would greatly reduce the friction I feel when using the produce.

Forgot to put SEEKING WORK

Location: Chicago, IL

Remote: Preferable

Willing to relocate: Yes

Technologies:

- Python (10 years)

- Rust (3 years)

- Application architecture and security (5 years)

- Project / developer management (3 years)

- Data Engineering (Python, Hadoop, Spark (Scala), Kafka, Postgres)

- Web Development (Rails, Flask, HTML, CSS, React)

- ML (training and validation, DNN / RNN / CNN, GLM, Random Forest, Bayesian Optimization)

- DevOps (Docker, Kubernetes, AWS, Google Cloud, Terraform, CI / CD)

Resume/CV: Email me please.

Email: hn_freelancing@protonmail.com

Location: Chicago, IL

Remote: Preferable

Willing to relocate: Yes

Technologies:

- Python (10 years)

- Rust (3 years)

- Application architecture and security (5 years)

- Project / developer management (3 years)

- Data Engineering (Python, Hadoop, Spark (Scala), Kafka, Postgres)

- Web Development (Rails, Flask, HTML, CSS, React)

- ML (training and validation, DNN / RNN / CNN, GLM, Random Forest, Bayesian Optimization)

- DevOps (Docker, Kubernetes, AWS, Google Cloud, Terraform, CI / CD)

Resume/CV: Email me please.

Email: hn_freelancing@protonmail.com

Location: Chicago, IL

Remote: Preferable

Willing to relocate: Yes

Technologies:

- Python (10 years)

- Rust (3 years)

- Application architecture and security (5 years)

- Project / developer management (3 years)

- Data Engineering (Python, Hadoop, Spark (Scala), Kafka, Postgres)

- Web Development (Rails, Flask, HTML, CSS, React)

- ML (training and validation, DNN / RNN / CNN, GLM, Random Forest, Bayesian Optimization)

- DevOps (Docker, Kubernetes, AWS, Google Cloud, Terraform, CI / CD)

Resume/CV: Email me please.

Email: hn_freelancing@protonmail.com

I have found Terraform to be a great way to manage Docker Swarm. I use one Terraform project to provision VPC, EC2, security groups, and install Docker with TLS authentication set up. I then use a second Terraform project to manage Docker resources on these servers. The Docker provider is definitely not perfect, but it allows me to easily manage hundreds of configs, secrets, and services on several clusters. I think this is a great pseudo-Kubernetes solution that is more tractable for smaller shops.

I think this solution is much more maintainable than things like Helm or Docker Stacks, with easy inspection of desired resources, configurations, and Terraform 12's nice new diffs when applying. I definitely think if my needs graduate to Kubernetes, I would explore the Terraform route here as well. In general I think Terraform is really poorly designed and incomplete, but that it is also a rough first iteration on what is the future of DevOps and large-scale resource management.

Haha, I would also consider myself obsessed with good documentation. That would make for a very interesting post. Cheers.

I think this is an interesting analysis, but I'm not sure I can agree with some of the logic here.

For example, a large component of "reliability" comes down to your implementation (multi-regional, graceful fail-over, etc.). It is entirely possible that the statistical reliability of individual components of one of these clouds is worse, but they have engineered their architecture on top of it to handle these failures gracefully. It is very difficult to estimate the probability of an unforeseen multi-regional black swan event that would actually threaten these businesses.

It is also worth noting that these businesses have a choice between their original on-prem datacenter, which was likely built under a similar engineering and management culture (and therefore similar quality), and their cloud offering, which is probably equal or better than on-prem (generally public products will be more polished, better documentation, more consistent, etc.). Factor in the waste of maintaining extra data centers and capacity when their cloud is likely not 100% utilized by customers and the decision seems obvious. Cloud and on-prem could both be terrible and they would still likely migrate to their own cloud for sheer efficiency reasons. They really don't have a choice to use a different cloud.

The author also tries to reason about the complexity of the requests being handled by each business (e-commerce vs. email) and I think it is very difficult to do this meaningfully. All of these companies have to integrate systems, developed by separate teams, which contain lots of unique functionality and data. I'm not sure I agree that e-commerce is necessarily more complex than Google maps or docs. I would have speculated that Google's architecture is generally more complex than Amazon's based on my subjective interactions with the platforms and experience with the two engineering cultures. Even if there are large differences in complexity, this strikes me as using layer 7 information to reason about layer 1-4. As we move to serverless and managed offerings this might make more sense, but I think for most businesses, clouds are very much just compute, storage, and network right now, which doesn't have much bearing on how complex of an architecture you can engineer on top of it.

Another thing I don't see discussed a lot is documentation and stability of API. I have never had an unpredictable API response from AWS or GCP. Their docs may not be perfect but they are generally accurate. Alicloud definitely gets respect for handling Singles Day, however I have run into very unreliable documentation and API behavior. It is always a bit of an adventure re-applying a Terraform template that I made only a few months ago. Perhaps their internal team gets more heads up when things change, but I consider DevOps reliability to be a real issue there. I have also noticed occasional issues with single-zone network latency, managed Hadoop version compatibility, and other general fit-and-finish things.

In general I consider all of these clouds to be equivalent enough in reliability that it just isn't a deciding factor. The location of clients and APIs that I'm working with is a much bigger factor (if they are already in a cloud zone somewhere). I subjectively prefer AWS because I have worked with them longer and I am more familiar, but I have had projects where it made sense to use each of the 4 clouds and I think being able to accommodate those requirements with equal degrees of reliability is exactly what good engineering is about.