Incus uses LXC containers under the hood, which is better for development since the containers are made for running systems/os. Docker is best for running applications, but not that great for active development containers (imo).
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.
I run incus os, which is an operating system that is made for spinning up containers and VMs. Whenever I have to work on a JS project I launch a new container for development and then ssh into it from my laptop. You can also run incus on your computer without installing it as an operating system.
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.
I've been a long time Cypress user, but recently have been feeling those pain points you mentioned, the half-async-half-sync APIs are driving me mad :)
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?
I think for css classes like ".profile-card" this approach makes a lot of sense. Tailwind has @apply, which is a great way to turn these utility classes into named css classes.
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:
<div class="flex items-center mb-4">
</div>
It's quick to write and requires no context switching!
There's a lot of problems that slackbots can solve, but asking people what type of slackbot they would pay $10 a month for is not probably not going to generate a lot of viable business ideas.
Find out problems folks are having and from there narrow that list down to those that are easily solvable by slackbots.
> the amount your company pays you is primarily determined by how much they would have to pay someone else to do the same job.
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.
It depends on the type of work you do. If you are putting together a handful of pages and only plan on spending a few hours writing CSS then probably no need for preprocessor.
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.
Neat. I've always wondered if Uber's ride sharing had a weak moat. As a consumer there's little difference for me between taking an Uber, Lyft, or something else. This makes it easy to compete in the consumer ride sharing market.
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.
As others have said it's very strange at first. My co-worker introduced it to me a little over a month ago and I remember thinking "how is this maintainable?". After a few hours it started to make sense and now I can't imagine going back to BEM.
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.
I've found the best way to know if I'm going to work well with someone is to have previously worked with them before. Look for people you've enjoyed working with, be it a co-worker, classmate, someone you've worked on open source with.
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.
Yes, all styles of programming have patterns because patterns are something humans are good at. If you want to learn more about functional programming I would recommend reading the following books.
* Learn you a Haskell by Miran Lipovaca
* Purely functional data structures by Chris Okasaki
* 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.
It depends, technical debt lets the team build features quickly today at the cost of slowing down future development.
Startups with a short runway probably don't have a future, so technical debt can be viewed as something with little downside that gets you to market faster. The tradeoff is that as your runway gets shorter debt makes it harder to try new things.
I'd say don't worry too much about technical debt before p/m fit. However, don't let anyone on your team use debt as an excuse for half-assing something that could deter finding market fit.
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.