Did you intend to reference "It's a wonderful life?" When I read your comment I imagine a tiny child in Jimmy Stewart's arms, exclaiming the joys of capitalism ;-)
My employer fits your first criteria precisely. Turbo and Stimulus provide exactly as much interactivity as we need. The appearance is that we're trying to avoid Javascript. The reality is that we are (successfully) minimizing context switching when working on the code base.
I was curious and did some math. A five minute zoom call is not realistic; you probably need 15 minutes per person. If my math is correct, and if no one was even a minute late, it would take 225 hours to lay those people off sequentially, assuming 24/7 meetings. If you had 15 managers making those calls, it would still take 15 hours to complete all calls. Let's call that three business days, during which no other work gets done anywhere in the company.
I once worked at an employer who performed five rounds of layoffs in the space of a few months. I cannot recommend that method.
I agree with you, the 900-wide bandaid was the only practical option.
You and (other person) started your lives on different dates, in different places, in unique circumstances; you are statistically unlikely to end those lives at the same time and place. If the two of you appear to be following the same path for a portion of those lives just enjoy the company while it lasts. There is no single, universal measure of success, so the fact that one person's achievements exceed your own in one area is cause to celebrate that other person but not a reason to feel bad about yourself. Be better than you were yesterday, be kind to those around you. Your story (hopefully) has decades left to tell. It probably includes major characters that you haven't even met yet.
There is one single feature of homebrew that regularly bites my coworkers. You can refer to software by name@version ("brew install postgresql@11" or "brew install postgresql@12") and there is no confusion about what you are installing; or you can refer to software by name only ("brew install postgresql") and the version number is calculated to be "most recently released." (v13 at the time this was written.)
Hypothetically I have two machines that I want to build out and give to developers. One machine arrives on Monday. My script runs "brew install postgresql" (no version), because of when I ran that script postgresql@10 gets installed. Tests pass, I hand that machine off to a new developer. The second machine arrives on Wednesday. I run the same script, but because v11 of postgres was added to homebrew on Tuesday, the second machine receives postgresql@11 even though the first machine received @10. Same script, two days apart, different major version of postgresql.
Yes, I can write my scripts carefully to avoid this. But consider this scenario: a new developer encounters a problem, tries to solve it themselves, finds a seemingly helpful blog, and ends up with postgresql@13 and node@15 when everyone else in their team is using postgresql@11 and node@12. Now tests are failing, but only for this one developer and only locally...
Doesn’t apt (for instance) work the same way? Or docker images without a tag? I’d you don’t specify a version in each case then you get the latest available. I’d you want a specific version pinned then you should specify it. I think I don’t see your point, works as intended. If you enforced mandatory version specification every time, you’d have to know exactly which version is which package for anything you install: apt install Firefox > nope won’t work, instead you have to know what is today’s latest Firefox version (changes every couple of days/weeks)
It's not really how apt works but rather how Debian works: you use apt with a specific release repository of Debian (stretch, buster or whatever ISO you installed).
Debian is really strict about its releases and won't push a breaking change in a specific version of the OS.
For instance, `apt install htop` will only ever install the 2.X version of htop in Buster. Including security patches and all, but you won't get a 3.0.0 version without going sideways and add a specific repository for that. Debian will ship with htop version 3 in the next release, but you'll have to upgrade the entire distro for that.
Brew is different in that it allows anybody to merge a new breaking version of the software you use, so `brew install htop` on Monday could give you the 2.x version, and on Tuesday will install the 3.0.0 version.
You could maybe compare it to the rolling releases of Arch. But Arch has a better way of handling it than Brew: they test, they prepare, they communicate for bug changes..
Brew would benefit from segmenting their offering, but you'd lose the bleeding-edginess of it. Really, if you want reproducible packaging on Mac, I'd use nix or docker. If you want convenience and edge, use brew and deal with it.
> For instance, `apt install htop` will only ever install the 2.X version of htop in Buster. Including security patches and all, but you won't get a 3.0.0 version without going sideways and add a specific repository for that. Debian will ship with htop version 3 in the next release, but you'll have to upgrade the entire distro for that.
Debian has an official backports repository if you want that behavior. It just gives you the freedom to choose.
On most debian-based distros, most packages aren't upgraded to a new major version in the repos for a particular version of the OS. If a new version of postgres is released, it won't be added to the apt repos for the current stable debian, ubuntu, etc. distributions. Instead it will be included in the repo for the next major release of the distro.
There are exceptions to that, for example browsers like Firefox and Chromium, but upgrading the major version of Firefox is much less risky than upgrading the major version of postgresql.
Rolling release distros like Debian Sid (and archlinux, though that doesn't use apt) don't work this way, which is why rolling release distros have a reputation for being less stable.
That’s really interesting, does anyone have a book or blog post taking about this versioning and releasing strategy?
I feel like as a new dev there’s so much in engineering I could learn from that’s already been solved and re-solved again and again or at least addressed by existing distribution systems.
However the reading materials to learn about some of this stuff seems far and few or very niche, sitting on some cached blog post from the 90s..
apt generally doesn't switch you to a new incompatible version of a package unless you upgrade your whole install. Browsers are not libraries and have special status due to their importance and having security and feature updates not separated.
If the solution to homebrews handling of major versions is to not use homebrew, I think it indicates there are issues.
I think it should work like almost Linux distros where the major version is fixed for a release lifecycle, and any other installations require modification. So say brew install postgresql should always install 12, and if you want something else you have to add the version modifier.
This is a side point but the docker suggestion is far cleaner if you work on multiple apps as you can easily configure and run multiple versions with Dockerfiles and compose files to be exactly right for each app, with only the plugins the specific app needs, data stored in a custom location for each app, and the ability to turn off postgres for an app. System postgres installs and upgrades are a needles pain for development.
But I agree that's nothing to do with brew conversation.
Not just different apps but having multiple working environments for the same app - very useful when you wreck the db on a feature branch and need to jump to another to fix a bug etc.
We do this where I work and while it’s great that it solves this problem, but Docker on macOS leaves much to be desired. The situation with filesystem performance is abysmal, and if you’re unlucky, CPU usage can go through the roof even when running a few lightweight containers.
That is my preferred solution and I think it works great. I have persuaded a couple of coworkers to switch, but only a couple so far.
Containerized Postgres is a real win, but running OpenLDAP (+ custom schema) as a containerized application has measurably improved my quality of life. Kudos and great gratitude to the people behind
https://github.com/osixia/docker-openldap
I think you could also utilize 'Brewfile' with pinned versions, where needed, and the latest available for the rest. I manage my environment this way when migrating from one work laptop to another. Works fine so far.
Alternatively, you can create your own 'tap' to gain more control over some packages.
For databases, I'd stick to running them as containers, too.
Homebrew is not ideal, of course, but there are ways to achieve desired goals until we have something better.
It's actually worse than you think since the @version notation needs to be explicitly marked by the maintainer of the package.
If they don't do this then there is no easy way to install an older version of a package, you will have to get the old .rb file from the brew git history and execute it yourself.
Apt sidesteps this problem because Debian-based releases are not rolling releases. Unless you install a custom PPA, if you are running Ubuntu 18.04 and you "apt-get install postgres" you will always get version 10.x. The major version number will not get bumped for Ubuntu 18.04.
If want to use a version of postgres other than 10.x, you can either use a different version of Ubuntu or install a custom PPA.
Apt's target audience is systems administrators. Homebrew's target audience is independent developers who might need to have four different versions of Postgresql installed simultaneously on their laptop, because they maintain Rails/Django/Node apps for four different clients who are each unwilling to upgrade for whatever reason.
IMO homebrew is "messy" because it is trying to solve a harder problem. If there is such a thing as an average enterprise software developer, I would argue that homebrew is trying to solve problems that the enterprise developer does not have.
For example Ubuntu X.Y LTS always use a pinner version of Apache 2.xxx and it will remain that version throughout that LTS release, such as 18.04. what they do for you is apply security patches and bump Apache 2.xxx.Y where Y is the security release applied patch. Apache stays at 2.xxx for the duration of that LTS and is considered the Stable version. Want something newer like Apache 3.x install from a PPA or an all-in-one bundled Snap package...
Except dpgk/apt is pretty good about keeping track of what libraries are being used. I've had homebrew upgrade readline to the next major version, uninstalling the version that all my other utilities were linked against. Admittedly, this was years ago and I don't know if that still happens; the experienced has soured me on homebrew and I actively avoid having to run the brew command and risking the same again.
I found it much worse that installing anything STILL by defaults upgrades literally everything. You have to actually set an ENV variable to stop this behaviour. My stuff constantly broke because I'd forget about this and install something else and a couple days later I'd go "what happened??"
It was doing this until recently when I set the env variable. It updates itself every time and then updates everything else too. Maybe I did something wrong to trigger this behaviour but it was definitely updating the packages
I've seen the exact same behavior. I didn't realize it was behind an environment variable. I passed a package to the command and for the next week I was dealing with issues from everything being upgraded.
The Well-Grounded Rubyist is my favorite Ruby book because it really drives home just how internally consistent the Ruby object model is. It gave me a deep appreciation for the aesthetics of Ruby.
This. Ruby’s syntax sugar makes it easy for newcomers to miss the elegance of what’s actually happening with everything being an object and every expression reducing to passing messages between objects. When you dig in and really understand what’s going on, the lightbulb moment is very neat.
Just adding to the choir. This is a great tool. I prefer using open source software when possible, but I also like to pay for the tools that makes my job easier. The developer is aiming at corporate, volume licensing and I understand how a Patreon account would run counter to their business strategy. I wish there was a 'small dollar donations' channel, though. I like this tool enough to throw them some regular money.
I won't presume to answer for the OP, but my (remote conference attendance) pet peeves include: I have printed out important information (but forgotten to email it); let me use the whiteboard that is mounted on the same wall as the camera to illustrate a concept; I will speak exactly loud enough so that only people in the room can here me; I will use the free tier of some conferencing service, and start the call fifteen minutes early so that the connection drops halfway through the meeting.
Well said. The biggest offenders are usually companies & not the remote employees. I am in a great spot where I don't experience these today but the most frequent I've seen are:
Poor microphones set up around the conference room that make it hard to hear everyone.
No webcam at all or a bad webcam setup that doesn't allow the remote attendees to see the gestures people make.
Multiple people talking at the same time, but having very quiet conversations.
Using a whiteboard, a projector or showing a screen by turning your computer around but not making it visible to remote attendees.
* Basically doing things that the remote people can't participate in.
A few years ago, I was on a green-field project and one of the senior developers was remote. The rest of us were co-located in a "lab" (converted conference room). While our teleconferencing tools were mostly adequate, white-boarding was problematic. "Smart boards" aren't usually. We ended up with an extra webcam pointed at the board and just had to remember to plug it into whoever's laptop was leading the meeting. Not ideal, but worked ok.
Almost thirty years ago now, driving around on a hot summer day with a couple of friends. One guy puts a punk mix tape in the player, and the guy with a college music scholarship was aesthetically offended. "Anyone could make this music," he complained.
The other guy nodded in agreement and replied, "that's the point."
The other thing about punk is that it's really more an attitude. Some punks are really skilled musicians and lyricists that bring a lot of outside influence into their music.
I got into playing the accordion because I decided that I wanted to learn some Dead Kennedys songs on the accordion (no I am not duckmandu). Some of them are quite tricky. Compare to the Sex Pistols who are musically boring but more than made up for it with the attitude and lyrics.
Good choices. I was thinking of Bad Brains, who started out as a fusion band, and Craig Finn's early stuff, but that probably gets into more post-punk.
If we're going out in the world of genre-spanning punk, Husker Dü, Hot Snakes/Drive Like Jehu, Wire, and (possibly if you count them) Shellac deserve a strong recommendation. The creativity and diversity in the world of post-punk is remarkable.
Was just reading parent comment and thinking “we don’t play ska anymore, we don’t play ska anymore, because it sucks”
Punk is so interesting in his variations. Compare with metal where speed, black, alternative etc are quite coded and baroque, whereas punk still manages to stat fresh.
I think while there are plenty genre that requires more skill than punk, that doesn’t make punk itself the musical equivalent of simpleton.
In some aspects, it’s the artigianal counterpart of the mass produced pop.
A beautiful sentiment :) I believe this should apply to tech as well – it shouldn't be an exclusive field and building logical apps should be simple. That's kind of why I chose to brand my freelance business as Punk Rock Dev.
