twunde

I think everyone that's worked with him, would agree :)

For the brief time he was at Cedar, he contributed a lot of high quality code

I cannot wait until Pants supports Rust as a target language (they were looking for rust consumers as of 3-6 months ago if I recall). For our python needs it was a real breath of fresh air. I'm now at a shop without it and need to deal with slow dependency installs and dependency conflicts again :'(

Hey Colin :wave: (I hope you're bringing Rust to DD)

To add onto this, Grapl had a moderate sized codebase with less than 10 engineers. I do think we could have done some optimizations in cargo, but it's simply much easier to use a tool like Bazel/pants etc that does the work for you as long as it supports your language of choice.

Plenty. Look outside of tech and you'll see that's the norm in many places.

Hey, I went to look up the book you're reading and what comes up is Unmasking Autism by Devon Price PhD. Is that the same book you're reading?

The issue with layoffs is that it's not just the low performers being fired. Typically managers are given a preference or salary amount that has to be cut. Inevitably the low performers are the first to be out on the list, but often times they'll also cut some of the high projects because they're making too much money. This even assumes that it's the managers making the decisions. If not, what happens is that layoffs are random message by someone outside the department and you can get stuck with low performers

Not useful for the OP, but for anyone considering Gusto I would highly recommend just going with a PEO, since they just deal with so many more things including remote workers in the US.

I'm at the point where if a company is using Gusto I won't accept their offer since I spent 6 months+ dreaming with healthcare billing issues because they didn't terminate the healthcare plan correctly

The issue with microservices is that you typically can't run all the microservices at once on your laptop, making end to end tests more difficult. That said, the main benefit of microservices is that they enable independent teams. To that end, teams should be writing unit tests for the individual services. For any other services they interact with there should be common mocks for those services. These mocks are the service contacts for upstream/downstream services and should be tested in integration tests. Services go through the CI pipeline and are deployed independently. There is then an increased focus on monitoring especially on error rate

Relatively off-topic, but I absolutely love the 90s/early 2000s vibes I get from this. I can't remember the last time I saw a webring, much less one with animated logos.

There are really two different groups of compliance programs: privacy compliance programs like GDPR and CCPA, and security compliance programs like SOC2, PCI and HITRUST. What's been happening over the last few years is that some of these security compliance programs like SOC2 or HITRUST are adding privacy concerns (usually as optional components) so that companies can do one audit for everything instead of doing multiple audits.

Generally speaking, json-rpc compares negatively to REST and to other RPC standards like gRPC or Thrift. REST is more popular, in large part because of Ruby on Rails, but also because it provides semantic meaning and a system that defines what the api call should be named. No need to look up the remote function, like you need to do for json-rpc. For those who prefer RPC calls, why not use a RPC system that compresses data efficiently and which use IDLs for code generation. Anecdotally, I found that many developers had difficulty understanding json-rpc, because it was so close to REST apis

The main advice with two way data syncing is to ensure that you've mapped out the data flows and make sure that it's clear which system needs to be updated to update data. I once worked on a PHP monolith that worked with a vendor .net system where because the data flows were incorrect, would routinely overwrite data changes, especially for fixed/updated changes. We eventually did a large project which fixed the data flows and cut the number of complaints to 20-30% of the original volume.

How you set up these syncs really depends on the ingest/egress options for the systems in question. Are you pulling data directly from a db? Do you need apis? Etc

Chompie (https://twitter.com/chompie1337) does a great job on exploit writeups. Take a look at https://www.graplsecurity.com/post/iou-ring-exploiting-the-l.... She's got a few more blog posts at Grapl, but she's moved on to new things at xforcered at IBM.

I just want to thank the mods (Daniel was the one mentioned in the email) for the invitation to repost this. I've no idea why some algorithm found a story I submitted from 2019 interesting, but I really like the idea of this and hope it continues to find old interesting submissions (personally I'm a sucker for all things transit). Thanks again!

To make it easier to think about databases, I group them into categories

- SQL Databases (Mysql, Postgres, SQL Server, SQLite)

- JSON document stores (MongoDB, etc)

- In-memory key-value stores (redis, memcache)

- key-value stores (cassandra, etc)

- Graph DBs (neo4j, dgraph)

- Search DBs (elasticsearch, Lucene)

- Timeseries DBs (timescale)

I consider the SQL databases and the JSON document stores to be the general default databases that my applications will use 90%+ of the time. SQL databases require defining the schema ahead of time, while with document stores I can just dump data into the database and then figure out what's needed afterwards. At this point, I usually use postgres as my go-to database since it's open-source, well-supported and has some additional features like the ability to use json, but if you're more familiar with a different SQL db use that instead. Most of the other database categories are specialized for specific use-cases (in-memory key-values are great for queues and caching, time-series dbs are great for metrics)

EDIT: https://db-engines.com/en/ranking currently shows 381 unique databases, which is probably a bit of an undercount but not by much.

I realized I didn't answer the `Why there are so many databases` part of your question. Essentially, many companies outgrow the general-purpose databases and need databases optimized to their read-write level and data structures. Analytics tend to use columnar-databases once their data sets are in the TB+ range so that their queries return quickly.

I moved to Vermont from NYC. I really miss meetups and meeting like-minded people. So far, I've been attending virtual meetups and gone to a conference in Boston.

Things to consider: - Cellphone service can be very carrier-dependent and will likely have large known dead spots. - Internet can be surprisingly good with many areas investing in fiber - Restaurant choice is greatly reduced, especially foreign cuisines. - Stores close early. - Deliveries take longer. Overnight shipping from NYC is actually 2-day shipping. - Cost of living may not be cheaper. Remember that you'll need a car and will be driving it more often. - If you're buying a house, you'll find that there's probably a decent amount of unexpected expenses. You'll likely be buying a fair amount of tools, including a lawnmower or potentially a tractor. - Many places are experiencing shortages for contractors of all kinds. Expect to have to call around and potentially wait a while for professional fixes. I know contractors that are currently booked for the next 3 years - I do know all my neighbors, which I couldn't say for any of the apartments

Vermont has a number of successful co-ops. https://nfca.coop/vt/ has a list of them.

Most food co-ops belong to co-op partnerships and many will cross honor memberships at other co-ops ie the Putney co-op will give you a member discount if you're a Brattleboro co-op member

Original CLP Paper: https://www.usenix.org/system/files/osdi21-rodrigues.pdf

Github project for CLP: https://github.com/y-scope/clp

The interesting part about the article isn't that structured data is easier to compress and store, its that there's a relatively new way to efficiently transform unstructured logs to structured data. For those shipping unstructured logs to an observability backend this could be a way to save significant money

The author of this also did a writeup of an io_uring exploit a while back that you might find interesting https://www.graplsecurity.com/post/iou-ring-exploiting-the-l... (the September 8 date is definitely wrong, probably an artifact from moving blogging platforms)

Thanks for adding that detail. I wasn't sure how much France and the US varied.

On a sidenote, I'm constantly amazed by how well my C+ high school french has held up. I can read and understand 90% of this.

Legally the biggest issues are non-competes and IP/trade secret laws. These vary jurisdiction to jurisdiction, but at least within the US are usually part of any severance agreements. Pretty much every member of the team who tried to rebuild it would have some risk of being sued and the company could be sued as well.

My god. I literally had the argument from https://qntm.org/abolish during standup.

So this is primarily a problem with small companies, although you'll sometimes see it on teams when several people leave around the same time. The typical example is a non-VC backed small business, where a senior individual is hiring a junior person because that's all there's budget for at the moment.

But yes, its absolutely an anti-pattern, because as you've pointed out junior hires do need more oversight and help. I've rarely seen the situation work out.

I've worked on a fargate + lambda migration to Nomad. At this point I definitely would have preferred to have gone with k8s. Nomad is still relatively complex, to the point where K8s is only somewhat more complex but made up with a bigger community and more tooling and features.

Features I miss: - ephemeral containers - dns integration with cloud providers - Up to date tutorials/examples, especially complex examples - Better out of the box validation/linting

You don't need to have gone to Stamford. If you have worked for a VC-funded startup, you likely have a path to a VC intro. If you haven't met a VC investor directly, you can ask one an exec to intro you. Its also worth checking to see if any coworkers have gone off to start or join startups as they can also intro you to VCs. It's also possible that some ex-coworkers may have joined a VC firm.

If you've only worked for big companies, it's probably worth checking to see if they've created a venture capital arm. Many do, including Coinbase, Google, Optum/United Healthcare.

I know you're being sarcastic, but this reminded me of Tanya Reilly's _great_ talk "The history of fire escapes: How to fail". There's a recording up at https://www.infoq.com/presentations/history-fire-escapes-res...

One thing that can be particularly helpful is if you know someone at a VC firm, talk to them about startups. And of course, use your network and chat with ex-coworkers, etc.

Assuming that you're not hardcoding anything region-specific, a copy is likely going to be the preferred method since this way you know that the AMIs are the same (ie there's no way that a dependency updated). However there are two complicating factors that may persuade you the other way. Check the cost of cross-region data transfer vs the cost of building your AMI. If your AMI is particularly large, it may make more financial sense to just rebuild the AMI. The other complicating factor is encryption. You _can_ copy an encrypted AMI per https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/CopyingA..., although perms can be a bit finicky. If you're encrypting something with a region-specific Vault or a HSM, then you'll likely need to rebuild the AMI

Actually, AWS does now support building AMIs and sharing it across an AWS Organization or OU: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/share-am.... If you're using Packer you want ami_org_arns to share with an org or ami_ou_arns to share with OUs https://www.packer.io/plugins/builders/amazon/ebs#ami_org_ar....

You do still need to create separate AMIs per region though

Don't forget the cases where the companies are deliberately lying to customers. I worked at a company that pretty much lied to its customer's security teams about what they did. Not borderline, but claimed things they didn't do and didn't have plans to implement. This is what the SOC2 audit is for.