HN user

Shicholas

96 karma
Posts1
Comments55
View on HN

I'm with you, but today most sr. attorneys & judges still print out all emails/documents to then redline. the legal field will need another 10-20 years before the foundation is present to even discuss removing Word.

yes, to take this a bit further, I love the idea that no matter what db is best, Postgres can be the starting point for all queries.

Another comment to piggy back off the ruby > python love. RSpec is a million times better than any testing library in python and bundler solved package management issues years ago that python still hasn’t solved. Glad to see I’m not alone!

DadeSystems | Ruby & Rails Devs | Remote/Miami, FL | FT | Competitive Salary, Bonus, & Benefits

DadeSystems.com is a successful company you've likely never heard of. That's because many financial institutions like Wells Fargo, Fiserv and 5/3 Bank whitelabel our best-in-class accounts receivable solution so their customers can seamlessly match invoices with payments. We are an 11-year-old company (with the same Rails codebase!) that's grown every year and have built a culture around respect, openness, and work-life balance.

Interested? Please email our VP of Engineering Doug B at doug.bradbury@dadesystems.com and mention that you came from Hacker News.

In our adversarial judicial system, you really don't have to disclose that until discovery. A lawyer may want to keep some of those similarities "close to the chest" to see how the other side responds first to some discovery requests. (this system is far from perfect).

Unpopular opinion, IAAL and frankly Replit has a case that will pass the "motion to dismiss" stage when litigation starts getting expensive b/c of discovery. The OP worked for Replit and therefore had access to private source code or "trade secrets" before creating his project. It'd take expert testimony for the OP to prove in court that his OSS project was not influenced in any way by Replit's closed-source code, which imo is unlikely.

I agree, imo the biggest change would need to come from governments themselves. This is why I think I get more altruistic "bang-for-my-buck" by donating to Bernie Sanders, Andrew Yang, the Squad, and other progressive candidates b/c we really need to move beyond capitalism.

Monoliths are even easier to manage in 2021 because of workspace dependency management (e.g. yarn workspaces, cargo workspaces) etc. You can have your cake (microservices built as separate packages) and eat it too (a monorepo workspace w/ all your code).

Our answer to the author's question, "is there a way to unify the interface across systems?" is to double-down on Postgres and in particular Foreign Data Wrappers for Elastic, Redis, and Neo4j and Postgres triggers/functions to keep the data in sync.

As the author pointed out, Postgres is a battle-tested and great option, and for us it's our company's source of truth for all data. However, there are definitely use-cases where using elastic or neo4j to look at our data in a different light are very helpful.

IMO Postgres is one of the top-5 software projects of all time, I don't feel like I'm making a bad choice by further grokking it.

Lawyers of HN:

I'm looking for a co-founder for our law firm, NeonLaw.com. We're building out a SaaS product, https://www.DeleteYourData.com so far with some decent success and plan to scale it this year. I also have some MRR with our business offering https://www.neonlaw.com/practice-areas/business and some ongoing litigation (which I hope to do less and less of).

Ideally, I can work with a privacy-conscious progressive attorney.

Interested? Please e-mail me at nick@neonlaw.com.

Mandatory "Squash and Merge" solves a lot of the author's reasons why adding code comments is necessary b/c it guarantees that each commit in the repository's main branch has a PR associated with it. For instance on GitHub, mandating "Squash and Merge" on the "main" branch means that every commit will have an associated PR Number in the commit message (e.g. "Added create user modal #70").

As someone whose gone the opposite way (moving from ECS to Kubernetes), I think the author is understating how good managed Kubernetes solutions are.

At my current job, I use Azure's managed Kubernetes service, which does a great job at providing a consistent environment that's very easily managed, no unexpected updates, great dataviz, and if you choose, simple integrations to their data storage solutions (run stateless K8 clusters if you can) and key vault. We don't do much outside of our kubectl YAML files, which as commented below has a de-facto understanding by a large number of people.

CVEs will always exist, which is why network security is important. I think we can agree that the only ingress into your cloud environments should be through API servers your team builds, and everything else should be locked down to be as strict as possible (e.g. VPNs and SSO). With a system like K8, so many eyes on the code mean so many more CVEs will exist, so I don't find this argument compelling.

My team, and so many other teams worldwide are betting that the K8 community will accelerate much faster than roll-your-own solutions, and K8 gives us the best opportunity to create cloud-agnostic architecture. Additionally, helm charts are easy to install, and afaict more software vendors are providing "official" versions - which means for a team like mine, which is happy to pay for services to manage state, in the same vain a company chooses AWS RDS over managing their own Postgres server, we can get the same benefits as the author with a cloud-agnostic solution.