With LXC any changes you make to the os/filesystem are persisted and there after the container boots up and shutsdown. So I don't have to worry about ephemeral storage or changes being lost. It feels more like a "computer" if that makes sense.

Containers still have some risk since they share the host kernel, but they're a pretty good choice for protection against the types of attacks we see in the JS ecosystem. I'll switch to VM's when we start seeing container escape exploits being published as npm packages :)

When I first started doing development this way it felt like I was being a bit too paranoid, but honestly it's so fast and easy it's not at all noticeable. I often have to work on projects that use outdated package managers and have hundreds of top-level dependencies, so it's worth the setup in my opinion.

I know we aren't supposed to rely on containers as a security boundary, but it sure is great hearing stories like this where the hack doesn't escape the container. The more obstacles the better I guess.

Is anyone using bun in production? Would love to hear your experience.

Im interested in Playwright, but wondering how you find the visual runner compared to Cypress? Are you able to run your tests in the browser and use a `debugger` or dev tools?

From the blog post it says read-only replicas are created close to users and kept up to date with the latest data.

- How should I think about this in terms of CAP? If there's a write and I query a replica what happens?

- How are writes handled? Do they go to a single location or are they handled by various locations?

I'm excited to try this. It's so cool to see databases being distributed "on CDNs" for lack of a better term.

I will say I've found that using prettier makes nested ternaries much more readable.

I couldn't imagine using them without prettier, but since every app I work on these days uses prettier nested ternaries aren't so bad.

However, after a while your app will end up with classes like .profile-card--inner, .profile-card__wrapper, and .profile-card__inner__wrapper--horizontal. When that happens it's usually easier to use those utility classes directly in the HTML template. You'll end up with something like:

Find out problems folks are having and from there narrow that list down to those that are easily solvable by slackbots.

This is true, but the thing you're missing is that there's not many folks out there that can add value for customers. That's why engineers who create value get paid so well, which is the articles point.

I've noticed that engineers that get paid the most tend to understand the technical and business trade-offs that come from decisions they make.

Comments URL: https://news.ycombinator.com/item?id=14187576

Points: 6

# Comments: 0

* There's going to be a lot of discussion and consensus building. Most of the team is going to have an opinion on the subject.

* Setting up new accounts for team members, teaching team members how to use the new tool, and change management all take time.

* Most teams have integrations within their chat apps, these will have to be switched or re-implemented to use new APIs.

I think it's fair to say that most team tools have good moats. The longer the team has used a tool the stronger the moat becomes.

On the other hand, if you're a front end developer or you find yourself working on CSS multiple times a week then you should absolutely use a preprocessor.

There are tradeoffs between the two approaches, but preprocessors do save you time so the added complexity can be worth it the more you work on styling.

If Uber is able to integrate with other apps this introduces a high switching cost for those apps... and that gives them a pretty solid moat. Excited to see how this API gets used.

Being able to design UIs without opening a single CSS file has made HTML pretty fun and I've found I'm much better at componentizing the right things.

Things that I think must exist between cofounders.

* You must like and trust each other.

* Make sure you are able to be candid with each other.

* Know each others weaknesses. Really another way of saying have realistic expectations.

If you have no prior work experience try working on a small one-off project to get a feel for each other's working styles.

* Learn you a Haskell by Miran Lipovaca

* Purely functional data structures by Chris Okasaki

* List open source on your resume.

* During interviews talk about your open source accomplishments. Use open source as a way to show you have experience in software development. This is especially helpful with team based open source projects.

* If you are contributing to an open source project with a community be vocal in that space. Answer stack overflow questions, write blog posts, tweet, and get involved in other online areas where discussion takes place.

* Build a website for your open source project. HTML content is easier for most people to consume compared to a github repo with README.md.

* Speak at a conference or meetup. A great way to get started with this is to give a 5 minute lighting talk demo for the project at your local language meetup.

Doing these things will help you market yourself and your open source work. This usually opens the door to networking with people that have similar interests, which is a great way to further your career.