Weird emphasis on "laptop" but maybe I'm not hip.
Show HN: Devbox – Easy, predictable shells and containers
51–60 of 196 posts
Re: Show HN: Devbox – Easy, predictable shells and containers
#52Extremely, violently unpopular opinion: a team of people developing on their laptops is an anti-pattern. I know what you're gonna say. You'll say, "It's 2022. We developers don't have internet connections; even when we do, our internet is off most of the time, and we can barely transfer 1.25 megabytes per second. How could we possibly use an IDE and filesystem monitor to copy a 10kB source file when we write to it, t…
> Maybe in another 30 years, we will have gained the technological insight to be able to figure out how to have a team full of people to work on a single server at the same time
Why is this desirable?
Re: Show HN: Devbox – Easy, predictable shells and containers
#53Extremely, violently unpopular opinion: a team of people developing on their laptops is an anti-pattern. I know what you're gonna say. You'll say, "It's 2022. We developers don't have internet connections; even when we do, our internet is off most of the time, and we can barely transfer 1.25 megabytes per second. How could we possibly use an IDE and filesystem monitor to copy a 10kB source file when we write to it, t…
If that workflow works for you, that's awesome. As a lifelong Linux user who works primarily in the terminal and uses a terminal based editor, it would work for me too. Dismissing people who work differently as being cowards is a stance I hope you'll reconsider.
Dictating to people how their workflow should look - _that_ is the antipattern. Developers should choose their OS, their editor, and virtually everything about their workflow. Forcing them to work remotely robs them of the opportunity - you can work graphically over SSH, and you can use SSH from Windows (if that is your preferred OS), but it's a hack that isn't always going to work quite right and is going to create unnecessary friction for people with different workflows than you or I. That's to say nothing of auxillary tools, like debuggers, that people may want to bring to bear. Don't get me started on getting debuggers to work over SSH, yes it can be done, yes I have done it, no I don't ever want to do it again.
The infrastructure should bend to conform to the developer's needs, and not the other way around. Generally technology should conform to the needs of humans, and humans should not be asked to contort themselves for the benefits of technology.
For instance, at my last company, I was asked to use a Mac laptop so that the team could standardize on Mac. I complied to be a team player, and this turned out to be a mistake. It robbed me of so much efficiency in the first few months, and it never worked as well for me as Debian running on my personal laptop, which cost a _third_ of the price of that Mac. I had so many frustrating issues and things that just never worked properly. But for other people, it was a great choice; I have no interest in bashing the Mac - my point is that people should be allowed to choose and customize their own tools.
Re: Show HN: Devbox – Easy, predictable shells and containers
#54Extremely, violently unpopular opinion: a team of people developing on their laptops is an anti-pattern. I know what you're gonna say. You'll say, "It's 2022. We developers don't have internet connections; even when we do, our internet is off most of the time, and we can barely transfer 1.25 megabytes per second. How could we possibly use an IDE and filesystem monitor to copy a 10kB source file when we write to it, t…
Why is it a good thing to give up remote development for a centralized solution?
I dunno, man. Some "dev ops" jerk at work is always complaining about how he has to spend all his time answering support requests from developers with errors in their local environment. It only takes like a couple hours of my week, so what? And then when our deploys fail because the server didn't have the same version of python as our local environment, he tries to blame the fact that the local and remote environments are different!
Can you believe the nerve of that guy? Keeps trying to convince us that a single centrally managed system is easier or more reliable (or whatever) than 30 randomly configured ones on multiple operating systems! I think he's nuts, personally. I have half a mind to tell my manager that he's trying to disrupt our ideal workflows.
And really, what's the problem with testing my app in an environment that isn't the same as production? Yeah, sure, I might save some time not having to maintain a local environment that everyone on my team can replicate. And, sure, developing remotely would let me change laptops without spending a week to set everything up again; but it's only a week, I have a ton of those left. And yeah, maybe the cloud network has a bunch of services that I need proxies and VPNs and other things to test from my laptop. And granted, doing development on a server with 40 CPU cores and the same network as the database and webserver is faster than my laptop.
...But if all that was better, I'd be doing it already. If it's on my laptop, I know how it works. What's better than what you already know?
Re: Show HN: Devbox – Easy, predictable shells and containers
#55Earlier quoted context omitted.
Why is it a good thing to give up remote development for a centralized solution?
I dunno, man. Some "dev ops" jerk at work is always complaining about how he has to spend all his time answering support requests from developers with errors in their local environment. It only takes like a couple hours of my week, so what? And then when our deploys fail because the server didn't have the same version of python as our local environment, he tries to blame the fact that the local and remote environment…
This is nonsense. We support a dozen developers running fully baked local development environments along with cloud-based dev, staging, and production environments. Multiple heterogeneous environments is normal.
Granted, we don’t run any node, python or Ruby, because yeah I don’t want to spend all of my time debugging monkey patching bugs.
Re: Show HN: Devbox – Easy, predictable shells and containers
#56I want to love this, and it looks amazing, but it doesn't work for me:
05:01:13 $ devbox add python2
Error: Package python2 not found.
Re: Show HN: Devbox – Easy, predictable shells and containers
#57Earlier quoted context omitted.
Why is it a good thing to give up remote development for a centralized solution?
I dunno, man. Some "dev ops" jerk at work is always complaining about how he has to spend all his time answering support requests from developers with errors in their local environment. It only takes like a couple hours of my week, so what? And then when our deploys fail because the server didn't have the same version of python as our local environment, he tries to blame the fact that the local and remote environment…
That sounds like a problem that can be solved with a CI/CD system and Docker Compose. Perhaps there is more going on here institutionally that stops this problem from being solved.
It sounds like something really frustrating is going on though, and I hope it works out.
Re: Show HN: Devbox – Easy, predictable shells and containers
#58Earlier quoted context omitted.
Why is it a good thing to give up remote development for a centralized solution?
I dunno, man. Some "dev ops" jerk at work is always complaining about how he has to spend all his time answering support requests from developers with errors in their local environment. It only takes like a couple hours of my week, so what? And then when our deploys fail because the server didn't have the same version of python as our local environment, he tries to blame the fact that the local and remote environment…
That's a really snarky way of saying, "We haven't figured out how to use Docker yet."
Re: Show HN: Devbox – Easy, predictable shells and containers
#59I want to love this, and it looks amazing, but it doesn't work for me: 05:01:13 $ devbox add python2 Error: Package python2 not found. Really bad first-run experience when the demo command doesn't work, sadly.
It's likely you have not installed the pre-requisites: namely nix. Without nix, it can't find the package.
That said, we'll improve the error message so that when nix is not installed it tells you you should install it.
Re: Show HN: Devbox – Easy, predictable shells and containers
#60I want to love this, and it looks amazing, but it doesn't work for me: 05:01:13 $ devbox add python2 Error: Package python2 not found. Really bad first-run experience when the demo command doesn't work, sadly.
It's likely you have not installed the pre-requisites: namely nix. Without nix, it can't find the package. That said, we'll improve the error message so that when nix is not installed it tells you you should install it.
As far as I can tell it is:
05:10:27 $ nix --version
nix (Nix) 2.6.0
EDIT: I installed Nix with the old-fashioned "pipe shit to bash" method and it seems to work now. When I say "work", I mean it in the sense of "doesn't fail", because it's been stuck at `devbox shell` for a good five minutes now with no indication.
Not to be too negative, I think this is a great idea and is going to be fantastic, but I guess, like any pre-release software, there are some teething problems.