Thanks! I'm going with nuxt3 on the frontend, and just firebase for everything else. Anything in the startup/remote world. There's a few go-to job boards I go to so it would be nice to get it all into once place.
I love the MBP with the M1 chip, but my biggest gripe is it lacks dual monitor support natively. I shouldn't have to use DisplayLink to get the second monitor working. Just been working on a single monitor since I got this thing because I heard DisplayLink is a buggy resource hog.
Ahh so that's what it is. I was confused because my coworker has the MBP with an M1 and dual monitor works fine for him. But that ran contrary to all research on my MBP specifically. Seems I'm due for an upgrade at some point in that case...
The 13” MBP has an M1 processor that only has support for 1 external display. It has the same internals as the MacBook Air.
The 14” and 16” MacBook Pros have M1 Pro and M1 Max processors and they support more video streams. The M1 Pro supports 2 external displays and the M1 Max supports 4.
Used this at my last company. Super painless and makes setup a breeze. Current company uses Docker and I hate it. Every company I've been at loves to throw everything into a container. Even if you setup your dev configs to maintain hot reloading, it's always slower. Node package management is also a pain no matter how you implement it with Docker it seems.
I also hate the Docker tagline that it "eliminates 'works on my machine' issues". I believe a tool like asdf would also achieve this (correct me if I'm wrong). Docker itself can go haywire depending on the machine and you're basically in hell fighting with it just to get your dev environment working. You essentially eliminate one problem in exchange for a variety of equally frustrating challenges.
I personally love docker. Almost all of it makes sense to me. It's not perfect, but very pragmatic, almost in a blunt way.
On a workstation level, people who really know their way around stuff tend to dislike docker in my experience, and for people who don't its still too difficult. One problem I think it has is that docker - still talking about workstations here - solves mostly problems on the team level, not on an individual level. But individuals tend to regard those problems as 'other peoples problems'.
Another problem is that you can work with docker just fine with barely knowing how it works, until there's a problem. In my experience, developers tend to immediately blame docker for the problem, even though its a misconfiguration of npm for example, which they would also have in a native installation.
Still, docker solves a lot of problems that aren't solved by asdf, apt or rpm, which is why it continues to be relevant and used also for workstations.
EDIT: docker on windows before wsl2 was hell too, a lot of discontent about docker that people have comes from those installs. On wsl2 it's mostly fine, if you don't attempt to mount from an ntfs file system.
In my experience as web (mostly) backend developer on Linux targeting Linux servers:
- docker is good when the deployed software runs on docker too, because dev and prod are the same and on Linux the performance hit is negligible if any. If you're on Mac or Windows it seems that it can be felt.
- docker is a good way to distribute the development environment, anecdotally much better than Vagrant or bare VMs.
- However having to always prefix commands with docker exec container is a little pain. Working in docker exec container bash is worse.
- Sharing only volumes between the host file system and docker means that sometimes I have to copy files to the shared volume instead of addressing them where they are.
- asdf doesn't have all those problems but I must be careful to pick different ports for different postgresql servers in different projects. Docker would shield those ports inside the network of the project.
All considered, I use docker when a customer uses docker, VMs when a customer uses VMs, asdf for all the other cases including my own software which I never deployed to docker so far. If I did I'd probably work in docker because I don't want surprises at deployment time.
In reality, when using Docker, Dev and Prod are almost never the same. We usually install different packages in Dev image i.e. debuggers or linters, we try to optimize the heck out of the Prod image, thus using a different build of the base image, etc.
And all this, when you are only developing on Linux for Linux.
I’m not saying this is the right way but this is very common. I also agree with the rest of your points.
Yes, I agree. I'm working on a Rails project today and the container in development has some gems we only use for development and testing: byebug, pry, rspec, timecop, simplecov, factory_bot. They won't go into the production images. The instructions for developers are
docker-compose build
docker-compose run --rm api bundle
docker-compose up
api is the name of the service in docker-compose.yml
One developer has a M1 Mac and he's using something called mutagen instead of docker. His docker-compose.yml is a little different and he's paying a performance penalty. His M1 is only 50% faster than my Intel from 2014 at running the test suite (50 seconds vs 75.) The difference is not noticeable when running only a few tests per time when working on a single feature.
The latter was the name of the compose v1 binary, so using it may cause your command to be handled with a v1-to-v2 compatibility mode. Depends on how your installation is setup. Compose v2 is implemented as a Docker CLI plugin.
I'm not sure what that means, but I don't think compose v2 is considered experimental at this point. It is included in Docker Desktop, for example. You might be running an older version. You can check `docker compose version`. Version 2.12.2 was released a few days ago.
I found docker to be pleasant to work with for support services (if your app needs postgres, redis, mail service, pdf converter, object storage, etc) in development and you need an easy command (docker-compose down; docker-compose up) to tell designers and product people to easily reset their environment to a sane state.
It is NOT great for having a live-reloading dev webservice running. People seem to swing for an all in one solution, but consideration is needed about what services you want in docker or not. Docker is great to have preconfigured database environments that are easy to tear down and start from scratch and works across multiple platforms. Docker is bad for local dev server.
> It is NOT great for having a live-reloading dev webservice running.
Oh my god this.
I was running a fastapi server on my m1 Mac in an arm Linux docker container. Everything else works great in this, but the live-reloading server was running at 200% cpu and ate 50% of my battery life!
If you genuinely think you have a better way to do it, propose it. Don't sit back with the terrible attitude of "my company does it this way which sucks" - why not try to make things better?
There are two possibilities - a) you are right, you know something your company doesn't, and by proposing your new plan in a constructive manner you might make life better for everyone b) you are wrong, you don't fully comprehend the surface area of the software you are working on, and your suggestion is short sighted and doesn't account for all of the requirements.
Either way it is helpful to put it out there - so long as you do it from the right place, with the right intention. Either you'll humble yourself, or you will eliminate an unnecessary dependency and make life easier for your team.
Then why does their company still use docker for that? Did they fail to convince anyone else? Did they disagree? Did they not even bother bringing up their frustrations? People love to complain, but rarely try to contribute to actually make things better.
The tool doesn't have to be just better. It needs to be so much better that it's worth: changing defaults / what people use now, changing documentation, verifying it works for all projects, ensuring that nobody has use cases that asdf doesn't address, and actually spending time with the decision maker to present your idea. For a larger company that may mean days of work.
Counter argument: your version is fine and may have helped to solve one particular issue in one particular company.
But countless developers in countless companies have each their own set of frustrations where they sense that something could be improved but don't know what to do with the frustration.
Frustrations are a useful symptom but learned helplessness is a terrible thing that can lead to anything from being annoyed to leaving your job to depression.
I would argue that the response was in fact a very valuable lesson.
Sometimes the problem is more that the grass looks greener on the other side. When you realize there are a bunch of day 2 problems for the "better" solution you didn't uncover beforehand, many will enter sunk cost territory
> I believe a tool like asdf would also achieve this (correct me if I'm wrong).
This is true for very simple applications, where you’re just running `npm ci` or `pip install`, but breaks down as soon as you have sophisticated dependencies with system / library requirements or dependencies (e.g. databases, caches, message brokers, queues) that are beyond the scope of asdf.
Also, since you’re probably deploying containers to production, it’s useful to have a similar environment for local development so that you know what will actually happen in production.
Best dev setup I've seen has been to use Docker compose for all of those dependencies, but just use asdf for the main application development. You get all the dependency wins of Docker for the peripherals but with the faster native local dev experience.
I said “probably” because the vast majority of deployments I’ve done over the past decade have been containerized, but I have no trouble believing that my experience isn’t indicative of the average.
It can be anything you want it to be, especially inside the confines of your own setup.
Do you want to quickly debug some software that relies on an older version of Postgres 9 but you don't want to clutter your host machine? Just run the following command to fetch and start an instance. With --rm flag it's going to be removed as soon as you terminate it:
But that was never the primary purpose of Docker. Like I can use Mac Minis as door stops, etc.
Docker runs best on top of Linux. As in actually run a Linux host , everything else in my experience is a hack. As long as you have internet access, spinning up an ec2 instance to test stuff shouldn't be too hard.
> Also, since you’re probably deploying containers to production, it’s useful to have a similar environment for local development so that you know what will actually happen in production.
This such a complete and utter lie and I'm surprised people in 2022 still believe it.
You do know what's happening when you run Docker on your Macbook, right? Right?
Ignoring your tone, here’s a concrete example: I was debugging a HTML-to-PDF service that was crashing for some payloads, but I couldn’t reproduce the problem locally.
I used Docker to run the application using the exact same image that was deployed to production, and was able to replicate the issue.
Why? Because the PDF renderer depended on loads of finicky dependencies (e.g. linked libraries), and it turns out that the default fonts in our base image didn’t support the Unicode code points in the example payload. I couldn’t replicate this outside of Docker because I have a completely different set of linked libraries and don’t stack.
you always have that option though and i assumed it was a fairly common debug thing to have to do if you use docker enough. not just for the times it works (ie you find a bug between the layers) but for all the times it isn't the culprit.
the other post mentioned setup, so i thought he meant they imposed presetup containers for developers to use?
The only problems I’ve ever seen a coworker or myself encounter with docker is not knowing it well enough. Admittedly it has a strong learning curve. There are things that will not work unless you know certain underpinnings of docker, dns/networking, etc. But to say it doesn’t work and goes haywire doesn’t make sense. It’s an extremely stable piece of software.
> I also hate the Docker tagline that it "eliminates 'works on my machine' issues".
Docker basically just takes a snapshot, which hides the problem rather than fixing it: when we want to change something, like updating a dependency, we're back to the same dependency hell.
Even worse, those snapshots are often not reproducible (e.g. running things like `apt-get install -y foo`, which depends on the latest contents of third-party servers). Again, Docker tries to hide the problem by putting snapshots into a cache.
To avoid these problems, we need the discipline to do sensible things (e.g. using specific .deb packages, rather than apt-getting whatever's latest; or using something more brute-force like Nix). Yet once we do that, there's usually no point doing it with Docker at all; since those commands work perfectly well outside of a container (if we want a container to deploy, we can tar up the resulting directory)
It depends a lot on your base image. If you use Debian locked to a release, you'll likely get the same Apache version plus small fixes / security fixes (whatever the exact Debian policy is).
That's not reproducible in the sense of "reproducible software", but it is usually good enough to build other things on top of.
If you want reproducible in the sense of unchaging/same digest, you should make a custom base image with the things you never want to change and pull it from somewhere.
What use case are you addressing here? Docker can be used to maintain development tools in various ways, but I see it as mostly operating on a different level from asdf.
For example, asdf can install tools on a developer's system. asdf can route invocations to the appropriate version of an installed tool.
Docker can be used to install tools in isolation by way of an image build. That image can be shipped off, so that developers can pull the image, and do not have to run an installation procedure. Docker can pull and run the appropriate version on demand upon invocation.
It's also not a binary choice. You can use asdf in a Docker container, and you could use Docker in an asdf plugin.
I work full-time and get monitored like this. Ever hear of Hubstaff? It's an unfortunate reality for some remote workers and I don't agree with it but it happens. There can be an inherent distrust from employers when they're unable to see you physically working. It's more of an assurance thing, but I've gotten used to working exclusively in VM's.
This is complete insanity to me. So now you're not only selling your knowledge and your time, but you're also selling your complete undivided attention with likely no changes to your paycheck. How do you employ someone and give them access to your company's systems but not give them the absolute minimum amount of trust? It makes no sense.
While I think it's stupid and would never dream of going in that direction with my staff (the most talented would probably bolt fast), in principle I see nothing wrong with it as long as:
1) The employer has paid for all necessary hardware
2) If anything goes through third-party services, I can work on the tracked environment in a way that doesn't expose my personal information in any way (e.g. I shouldn't be required to open my e-mail inbox or any other online accound not strictly tied to my employment there)
3) The employer accepts the time wasted on any friction with moving information back and forth (and/or sees to minimize need for that)
If it means running a VM, up any workstation with 16GB RAM.
I don't feel any of that solves my main issue: that I would not want to work for someone who does not trust me. That does not seem like a good environment where I can be productive and work on things which benefit my employer. The privacy issues is not the only issue.
The only case I would accept something like this is if I was working at eg the NSA, a really high value target for state actors. Then I would get why nobody can be trusted.
Oh, absolutely. I wouldn't want to work like that either. Just saying I see it as a bad decision, not ethically or morally wrong.
As opposed to, say, controling employees bathroom breaks as is routine in retail and industrial jobs in some places. Or prohibiting/preventing unionisation.
In my head when I tell a client that a project/job is X hours it means that that is the market value in hours for that project.
There is an old Italian story - I'm sure it's common in other places - about a TV repairman that goes to fix a TV at someone's house. He looks at the TV and tells the owner: "It's going to be 100$ to fix it". The owner agrees. The repairman walks up to the TV, hits it with his fist and the TV starts working again. The owner complains: "What? A 100 bucks to hit the TV with your fist?" and the handyman: "Yeah, because I knew where to hit it!".
The idea is, say that you are a 10X performer: you have two options in front of you. Option one: you charge 1200$ for ten hours of work - this will make clients happy, even if you are only working an hour. Option two: you charge 1200$ for an hour of work: none is going to hire you because there are people that are only charging 120$ an hour.
The funny thing is: even if the math always ends up the same - 1200$ - people will almost always choose the 120$ an hour because in their heads they are getting the best deal.
Back to the topic at hand: if I say that a job is 10 hours at 120$ per hour I don't want to be monitored because trust doesn't enter into it. It's a simple matter of what's the worth of the job. If you don't think the job is worth 1200$ no amount of monitoring will fix it; if you think the job is worth 1200$ then if I do it in two minutes or 10 hours should not be an issue.
The Speed-Cost-Quality triangle is lost in translation the moment the invoice hits the printer.
> Option two: you charge 1200$ for an hour of work: none is going to hire you because there are people that are only charging 120$ an hour.
The solution is to find clients that are prepared to pay for quality + reliable results and to avoid discussing work in terms of hourly rates then?
Upwork sounds like it encourages hourly projects for clients that want the cheapest price. As a freelancer, your goal shouldn't be to win over every client.
Many times this option is the best option, but it's not the best available option. This is because of a lack of trust. People are worried they are going to be ripped off, so at least want some proof that a given number of hours that seems reasonable was expended and then they check that a reasonable rate was charged per hour, and it makes them feel more confident.
These people are often very frustrating to work with.
