I have 20 years of experience in software development, infrastructure automation, and CI/CD. These days I mostly write Go or Python, but I’ve worked in a range of languages as needed.
Strong Linux background (and other Unixes), AWS experience going back to the early days (when the CLI was a JAR), with time spent in GCP and Azure as well.
Open to interesting problems and even boring ones too, especially if they touch infra, automation, or systems engineering.
I have 20 years of experience in development, infrastructure automation, and CI/CD. I'm a polyglot but nowadays I default to Go. Most of my time is spent on Linux and I have experience with other Unixes as well. I've been an AWS customer since 2006, when the cli was still an executable jar, and I have experience in GCP and Azure.
I specialize in infrastructure automation and Kubernetes. I'm a polyglot but nowadays I default to Go. Most of my time is spent on Linux and I have experience with other Unixes as well. I've been an AWS customer since 2006 and have experience in GCP.
This is kind of a problem with non-paid support I think. I had an AWS account with some credits that were going to expire and decided to use them to spin up a bare metal instance. My account was immediately flagged and I got locked out. I finally managed to reach someone who made me jump through hoops changing my password and rotating my API keys. It still took a few days before I was able to log in again, and by then my credits were expired. Luckily I wasn't doing anything important in my account, but someone running a business would have been screwed.
It's not that. We don't want to switch shell syntax between workstation and server, for example. The fish users I've known moved very slowly when they had to hop on a server, or build a new container image where it involved a 'docker run' into the shell to test it out. If you know bash or sh well enough to do those things quickly then there is no incentive to use fish.
> If you know bash or sh well enough to do those things quickly then there is no incentive to use fish.
I honestly think you might misunderstand why a lot of people use fish. I know bash “pretty well”—I’ve written and maintained my fair share of complex bash scripts, and remain pretty comfortable opening a shell in a running docker container or EC2 instance to debug various nonsense. What makes fish attractive to me for use as my login shell is the creature comforts which are very nice to have on my regular workstation, but aren’t really necessary when mucking around in some random environment: syntax highlighting, tab completion/autosuggestion/history search which “just works”, somewhat nicer syntax for writing simple scripts for personal use, saner word splitting, and so on. I guess I can’t really speak for other fish users and am perhaps biased by learned bash first a couple decades ago, but I don’t personally find it especially burdensome to have to remember multiple shell syntaxes/semantics (I already use half a dozen in my day to day work; what’s one more?), and I view it as a reasonable price to pay for a UI I find much more pleasant on whole.
But `docker run` is the same in every shell. The only things that really change is the syntax for looping over files, advanced globing, things like that. Control-R, tab completion etc all works more or less the same with some minor quirky differences, but nothing that would slow somebody down.
Context: I used bash for about 5 years, zsh for the next 10 before switching to fish.
I use bash and also have no patience for configuring tooling. Your fish dotfiles are more complicated than my bash ones. I used to work on a team where many of the other engineers used fish. I never saw it doing anything I couldn't do in bash, although it looked a little fancier. But the annoying thing was when they asked me for help, and none of the commands I gave them worked in fish. It made for very slow troubleshooting sessions.
i am using fish for more than a decade and i don't have any dotfiles for it. (do i win? :-p )
your commands to help not working in fish? that is rather surprising. i would think that fish users should be aware that shell specific things in fish are different, so they should have been able to cope and translate as needed.
and it's not what you can do in fish that makes it special. it's how you do it. the syntax coloring, the completions, the syntax itself...
the key thing for me is how it handles searching history and autosuggestions. i just learned how to somehow recreate this setup in zsh, and i am very curious if bash can do that too: https://news.ycombinator.com/item?id=37274207
btw i believe bash got a lot better at command completion after fish popularized the idea.
I've had Python code break a number of times when moving between 3.x minor releases. For a distro like CoreOS that is single purpose and intentionally kept minimal, I can see the value in a rolling release. For a traditional OS though, I do not want to be forced to spend my day fixing stuff because an update ran last night. Choosing when to change language and dependency versions is a feature.
How often is common to you? I've seen it happen plenty, and not just with Python. Even Go, which has a reputation for maintaining backwards compatibility, had bugs that caused breakage on patch releases during the go.mod transition. Even if breakage happens rarely, when it does happen it causes unplanned work. I'd rather be deliberate in when I choose to upgrade so I can plan for issues.
As mentioned, they weren't bugs but multiple planned breakages.
IMHO, Python devs learned the wrong lesson from the 2 --> 3 transition. Should have been, "minimize big breaks." Instead they learned, "make lots of small breaks spread out evenly and avoid X.0 releases." The result is that planning around deprecation (always be breaking) is untenable for enterprise-style development.
I have a small amount of experience making cheese, and have only made it with pasteurized milk as it is not easy to find raw milk where I live. However, in the US at least, there is both pasteurized and ultra pasteurized milk. Pasteurized uses a lower temperature for a longer period than ultra pasteurized. The vast majority of milk in the US is ultra pasteurized. My understanding from reading articles on cheesemaking is you can't really use it to make cheese as the curd doesn't develop correctly. While I haven't made cheese with raw milk, there is no doubt it tastes better than processed milk. I know because I worked on a dairy farm when I was young, and used to drink it practically straight from the cow. I did get sick once though, so it's an actual risk.
> Always talk about a second application. For each abstraction, the “app” is the layer above it. For example, a filesystem is an app for a block device; TCP is an app for IP. You should be able to describe the functionality of a layer without ever referring to the specifics of the app (e.g., you don’t need to know what a file is when talking about an SSD’s internals).
This is so true. It’s very common to see infrastructure being built in terms of the application that will run on it instead of designing the application to run on the infrastructure. A lot of brittle, unmodifiable messes are the result of this.
Part of the challenge is knowing how to slice the layers and when. Premature optimization is often crossing such layers too soon. Yet there are times when it becomes necessary for performance, such as Oracle bypassing FS to write to block devices or kernel patches for specialized networking cases.
I’ve had a lot of success building good abstractions with a version of this “second app” idea. The delta between designing for 1 app and designing for 2 apps is vast, but once you’ve designed for 2, you are generally very close to being able to support N apps. By the time you get to 3, you understand the problem domain very well and have a lot of confidence in your interfaces.
I have 20 years of experience in software development, infrastructure automation, and CI/CD. These days I mostly write Go or Python, but I’ve worked in a range of languages as needed.
Strong Linux background (and other Unixes), AWS experience going back to the early days (when the CLI was a JAR), with time spent in GCP and Azure as well.
Open to interesting problems and even boring ones too, especially if they touch infra, automation, or systems engineering.
GitHub: https://github.com/cloudboss, https://github.com/rjosephwright
LinkedIn: https://www.linkedin.com/in/rjosephwright/