There is something about those SMB posters. They do like to chase you across forums.

I can't remember but there was some issue we spent a day trying to debug and it turned out to be some dev had a weird .bashrc or bash_profile issue.

As a lead at a big corporation with a big messy set of devs, I need to know all my devs are on the exact same environment.

If you know what .bashrc is and you can deal with issues then sure - knock yourself out.

When some dependency asks a dev to modify their .bashrc, then I spend all day trying to figure out what's going on - because this dev is clueless and doesn't even know what .bashrc is much less remember tweaking it - then I have a problem.

Nailed it.

You guys are weird, this is my entire .bashrc

I?m going to talk out of my ass and say that forcing everyone to use the exact same environment is going to cost you a lot more than this one error.

Not just in their lost productivity but in alienating a lot of awesome devs that are out there.

I use a fairly different build environment than most of the devs on the projects I work on. But I know that, and if I have a problem I can't figure out, I go back to the stock build env before involving anyone else. My env choices are my own problem.

(Mostly, I run unit tests in a non-standard way, where I get much finer control via my IDE than you normally would, because it's a lot faster)

I don?t think we ever had any classes that went deep into things like shell scripts. I remember one class had ?negative value assignments? (if you didn?t do the assignment you lost something like 5% of your final grade) that tested basic Unix commands and tools. They were simple and just meant to introduce tools to people.

Most knowledge about these things came from work or playing around.

BTW, I go back and forth on the utility of using docker, but where it really shines is dev environments. We used to have a multi page procedure doc on how to get a build env set up. Now it is literally "install docker, check out repo, and run docker-compose up"

And recently I have been working on making linux packages for a product, and testing installation on a bunch of machines. It is *so easy* to do repeatable tests with docker, because I get to start with a clean "machine" every time, in the flavor of my choice. I can make a change to the package, restart the docker container, and reinstall as if I'd never installed it before. It's kind of finicky because it's a bootstrap install - you are getting a custom package from a web server that has some things specific to you baked in, so there's a lot of back and forth. I would be pulling my hair out if I didn't have SOME kind of cleanable VM to use.

I'm not at all experienced with backend webdev and am having some sql woes. I'm using sequelize which is a javascript ORM of sorts. I have a threads table and a comments table trying to make a basic forum/commenting type app. I want to get the 5 most recent comments from the 5 most recently updated threads. Yet apparently putting a limit on an associated object doesn't work so great in sequelize.

ie

does not work.

Now I've dug up some github issues and sql tricks on how to get the data I want,
https://github.com/sequelize/sequelize/issues/1897
https://stackoverflow.com/questions/...he-first-table

but I"m more concerned with how I should go about this? Is doing the n+1 queries to get the comments even a bad practice? At what # of queries does it become a problem? I've also considered just trimming the results before sending the response. Should I just use whatever the ORM api provides to write my own query?

If you were looking over a prospective employees github would making n+1 queries or over fetching data be a red flag? I'm kind of in a weird spot of having some knowledge about these kinds of things but not enough experience to know whats standard and what becomes a performance problem very quickly.

Thanks and sorry for the briandump.

I really don't like ORMs. SQL is not that complicated.

So I guess what your solution is, is to get the top 5 threads, and then do 5 queries to get the top 5 comments in each thread? In some database systems, that's about the best you can do. I'm pretty sure you could do it in one query in postgres, using the "over" partitioning syntax. This page has some examples that I think are near what you want
https://www.postgresql.org/docs/9.1/...al-window.html

I can't think of a way to do it in mysql, in one query, that is very good. It's been too long since I've used oracle or sqlserver to even have an opinion on those.

Yeah I'm not a fan of this. Out of curiosity, what was the issue you had with a dev changing their environment? At my job we tend to have build scripts set (or check) important environment settings before running the build.

Yo suzzer, I gotta +1 the other fellas. Whatever you think is a problem with bashrc is really a problem with something else.

Again - if you know what you're doing knock yourself out. I'm not going to force you to do anything.

It was something that required a change to .bashrc that I had to spend all day debugging on a dev's computer who *did not* have any idea what he was doing.

I can't remember what the exact situation was. So I will drop this until it comes to me.

At my school, it really depends on which classes you pick. You can graduate not touching shell scripts or you can graduate with lots of experience with it.

I had two classes that gave a deep dive into it, which I'm glad we did since I use it every single day at work. I don't technically remember all the commands but I'm familiar enough to know what to google. And doing that can really increase your productivity.

It wasn't a rock star dev like all of us here obviously. Any dev who knows what they're doing and wants to customize I am fine with. I customize the hell out of my environment, but I know how to figure it out when something isn't working right. I have a whole other set of issues to worry about with offshore devs and spotty contractors.

But I can't remember the issue so I will defer. I just remember spending all day trying to debug some dev's path issue or something. We checked the profile and found nothing. Finally figured out the issue was in some .bashrc file that had somehow been modified. (Or it could be the other way around.)

You guys seriously haven't lived until you've had offshore and onshore devs to look after. I spent a good 8 hours trying to figure out why some offhore devs couldn't log on. Turns out they were using localhost instead of local.[company].com. So the cookie wasn't being set. Well that and some other issues. But it was fun.

Speaking of offshore. We might be getting a NOC(?) to take care of our oncall issues in the next quarter. If this goes through, it's basically a salary bump and I'll be so happy. I hate having to schedule my life around on-call even though I only go on once every 2.5 months.

We have some stuff in bash_profile that sets environment variables for certain dev setup and artifactory. I also have some custom preferences (like seeing which git branch I'm using on the prompt).

I also have a similar file for vagrant that port forwards and some vmware configs.

I assumed they are mostly set it and forget it configs, and while I'm sure the errors are not obvious, when I was helping that senior engineer with her environment, one of the first things I did was check out her vagrant file to make sure it was correct looking.

The first things I was asked when I first started when asking questions was if I had the right bash_profile and I had sourced it.

I remember recently making a ./bash_aliases file (in Linux Ubuntu), and the ./bashrc file automatically loads the ./bash_aliases file, so you can keep them separate.

Suzzer, I don?t know how to reconcile your two posts. Saying everybody has to have the exact same environment isn?t the same as saying people can customize stuff as long as they know what they?re doing.

The problem is that a bunch of people think they know what they?re doing but don?t. I just think that the problems caused by these people are worth it for the benefits you get with people that do know what they?re doing (source: my ass).

Speaking of configs, I found this on HN this morning:

it was incredibly stable and a simple matter of telling the mkinitcpio config to use the amdgpu module and not the radeon module when building the initramfs.

For the configs Grue has, I'd be using bash in /usr/local/bin.

I have stuff like "emacs -mm" which just forces emacs to open in full screen.

Your git aliases should be in ".gitconfig" -- that's what it's for. I do alias "g" to git though in my .bashrc.

Also, I know you're just joking, but customizing your bashrc isn't weird. It's really useful and most experienced command line users do it, for the same reason you do anything ergonomic.

Since you use git alot, eg, you'd immediately benefit from git completion:

https://github.com/git/git/blob/mast...ompletion.bash

Everyone who doesn?t work in a windows environment should learn basic shell scripting if for no other reason than to see what the really olds thought about UI and syntax, nothing beats spending an hour on a script only to find you do need a space between operators and characters....

I think what Suzzer is trying to say is that newbs using standard build environments is a good thing. It?s one of those rules you should learn before breaking...

When you phrase it in the general terms, I guess?

But there's a lot of pretty trivial things you can configure (aliases, formatting, editor preferences, random tools, etc.) that I can't imagine ever telling new devs they can't touch the config files.

I actually think that's the wrong lesson. The details of syntax are often the part bash gets "wrong" -- and someone new to programming might see the stuff like "if... fi" (and plenty others) and think, "lol, why would i learn this outdated weird-looking nonsense when i can just script in python or ruby?"

and that would be completely missing the point, because unix/bash get all the big things right -- the whole system is based on functional pipelines. in fact, that's a massive understatement, because not only is the basic design right, it's way better than the design of majority of all the latest hot ****.

so i'd say the reasons to learn it would be 1. understand an example of great design 2. learn to "see through" syntactic details that don't really matter but that newbs are obsessed with 3. it's just practical to know