Are you sure A is correct though? I just had to make a bunch of changes to a mobile menu while the main dev is on vacation - huge PITA because I kept having to dance around the main menu which didn't change. The classes however were already mostly (but not completely) diverged - with a mobile media query overriding most of the desktop CSS.

What is the major benefit of one component?

It seems to me like you should ask yourself this question about future changes - which things are likely to need to change in concert and which are likely to diverge? Anything that's likely to diverge should just be it's own component if that's already the path of least resistance.

Obviously adding a new menu item, or maybe tweaking a site color would apply to both the mobile and desktop menu. But for those you can always share colors and stuff, and have both components driven by the same array of menu items.

For everything else, to me it seems easier just to not abstract into a single component (or class etc). It's definitely easier to just make two components up front as you noted - so if it's even a wash for ongoing maintenance - why go through all the work?

I feel like our lead front end dev is very competent and thinks about the big picture. But maybe he tries to abstract thins out a little too much, and tends to only think about the current snapshot of requirements - not how they might change. Which doesn't mean put in a bunch of extra stuff guessing at what the changes could be - that's even worse imo. But it does mean assume there will be change. Asl yourself - ok if I need to tweak either of these menus - what strategy is going to be the most painless now and in the future?

But I don't really know enough react or css to be 100% sure.

yeah, it could go either way. Also, I use angular not react so you're mileage may vary.

One of the reasons I answered A is that there's 2 buttons at the end of the menu in my current project that are basically hard coded, notifications and log out, that everyone has, and the others are driven by an array.

So any change to those would have to be made in two spots, and invariably I forget about the mobile version. If the entire menu is driven, then yeah, probably doesn't matter one way or the other, but I'd try to stay consistent through the project of doing stuff like this one way or the other.

Kinda related, more than once I've started a post here only to delete it that was something like

You have 2 functions that do different things but have a few lines in common. How many lines in common to they need to have before you break it out into a new function? 1? 2? 3?

function1{
do A
do B
do C
do D
}
function2{
do A
do B
do E
do F
}

or

function1{
do function3
do C
do D
}
function2{
do function3
do E
do F
}
function3{
do A
do B
}

or

function1{
do A
do B
if (condition){
do C
do D
}
else{
do E
do F
}
}

So I finally got promoted. Big raise too, which I didn't expect as my first promotion was a small raise and when I asked my manager for better compensation she pretty much said it doesn't work that way.

So luckily I got a new manager and he got me promoted with a nearly 20% raise in a few months. /brag

But mostly it's a relief as feeling underpaid is really draining.

Nice work!

Scaled agile ftmfw

Sounds like SAFE is working!

trollololol gooooooooo SAFe!

In other news I may be going back to my old employer that is huge on SAFe so I guess I should stop making fun of it as it may soon be my life.

Anyone ever gone back to a previous employer? How did it go?

It sounds like they will hire me two levels above what I was at when I left, which means I would be leap frogging people that stayed. I hope that isn't too akward, but I think it happens semi-often?

I have. It went OK.

You left pretty recently, no? That would definitely breed resentment among your coworkers.
Also didn’t you leave your old employer for some good reasons?

I left last July so by the time I came back it would be about 18 months.

I did leave for some good reasons although the primary one was being expected to do work of a Principal Engineer without the title or pay. If they hire me back as a Principal Engineer that addresses the biggest issue I had.

I agree it would likely breed resentment in some coworkers that are stuck in the same position but then again they haven’t had the balls to do anything about it like leaving and moving across the country (which is what I did).

At the end of the day I would actually prefer to stay in Cali but my wife doesn’t like it here and wants to move back home so that kind of trumps everything.

Yea that’s tough. If you are okay with the pay and title of principal engineer forever then it probably be the right move.

I’m in somewhat of a similar boat. Girlfriend wants to stay in SoCal because of family and her career reasons. But I just started a new job in the Bay so I can’t transfer anytime soon.

Really enjoyed reading this for some reason. Thought I’d share:

Cal Tech Announces New initiative will train science-minded software developers to boost research

Has anyone ever tried to create and merge pull requests on github through the git-cli, or maybe github API, or any other kind of automation?

Basically our app has 14 repos (10 lambda repos which each contain multiple lambdas, 2 lib repos, one repo for api gateway and one repo for the front end react app). Each of those repos has 5 important branches - corresponding to one of our environments - dev, stage, pilot, preprod and prod. All of these environments build themselves automatically if they see a new commit to the target branch on github (via webhooks).

It's nice that I can make a fix to one of the lambdas and not have to push the entire app. However there are plenty of times I want to push the entire app from say the stage environment to the pilot environment. So far I've been doing this by manually creating and merging pull requests for all 14 repos - which gets tedious. I like pull requests because I get a nice file diff snapshot of every push to a new environment that I can always go back and check if there are any problems.

However googling is not yielding much wrt to somehow automating the pull request process on github. I found this: https://hackernoon.com/how-to-git-pr...e-a5b204a57ab1

But it seems very unclear and apparently requires that you be in the repo on the correct branch. Which might work for scripting but seems painful as I want my local repos to stay on the branch they were on. Also ultimately it would be nice if this could run from a CI/CD pipeline which might not have access to all the local repos.

I feel like I can't be the first person who's tried to do this. How do people with 1000 microservices and a separate repo for each one automate this kind of thing? Maybe they never push *everything* from one environment to another?


Edit: ok I found the github API: https://developer.github.com/v3/pull...a-pull-request

It's not working but maybe it should. I'm trying to figure it out now. I know I have my repo name right but it just keeps saying "Not Found".


Edit edit: ok I guess i need to use -u with curl, and then enter my username then add the password. I wonder if I can automate that too. Yes I can. Damn that was easier than I thought. Now if I can just complete the PR.

We have a whole service that automates that stuff through the github api, including opening and merging Prs on repositories. I haven't done any work on it, but it doesnt sound like its too hard

Yeah it wasn't. I got it working.

For some reason I googled this a couple times and never found my way to the right thing. I guess "pull request" and "github" brings up so much crap you really had to work hard for filter through it.

Now for the ultra-hard part of writing a 30-line shell script that reads the PR # from the create PR request and loops over an array of repo names. Should take me half a day - 2 hours of which because I have the wrong flavor of bash or I didn't leave a space after my [[ or something.

Suzzer, have you seen Github Actions? It might be worth signing up for the beta and checking it out. Here are some ways others have used Actions to automate workflows.

Thanks I’ll check it out

Lol if you want bash tips or a proofreader lemme know

The stuff I get stuck on is so stupid it's hard to even ask for tips or google.

Like how this works:

But this doesn't:

Or how bash and sh are the same 96% of the time, but not always. It's all stuff you have to learn once and then you know it. But there's just so much of it.

I'm still not sure if indentation matters.

And why are named arguments so freaking hard? Why is that not built in?

This is the weird-ass voodoo I have to put at the top of every script to get named arguments:
I must have googled but I have no idea what it's doing now. Oh yeah, I remember - since the script that's including this line is called by other scripts, I have to do all that weirdness. bash was apparently invented before the idea of re-using code from other files.

Here's get-named-args.sh:

I think something in here only works on bash and not on sh. Or maybe it works on my mac sh, but not the sh in my AWS code build job. But it works with bash in both places.

yea, it's just a language thing. Always gotta put spaces between brackets.

There are differences. That's why at the top of all my scripts I use:
#!/bin/bash

Which forces the OS to use bash. Bash is very standard. I never use sh for the reasons you just described, it is system dependent. But bash doesn't really change between OS's.

What do you mean by this? You mean like building parameters? eg., ./myscript --dir hello_world ? I agree this is annoying to build. I have a script template I always use.

Dunno what you are trying to do but I'm almost positive there's an easier way lol.

You can use code from other files. You do source (file path). I sometimes have files that have a bunch of function definitions I always want to re-use, and I source it. You can also source env files that contain lines like

my_var=whatever

and you will inherit these vars.

You have to remember about bash is that I'm pretty sure it's older than me, and it was built on top of the bourne shell, which is probably older than a lot of us - and this shell was modeled af†er perl I believe, which is kind of a horrifically ugly language.

I don't take any joy in your pain, but I am relieved that I have a skill that seems to be somewhat in demand and not very well met by the market, because I always hear people bitching about bash and shell scripting like it's some arcane and difficult to learn thing. IMO it isn't once you get past the syntax and learn good practices. The most infuriating things are the differences Mac OS decides to have against REALLY standard command line utils. For instance, "find" utility is completely different on mac. You can't do cp -a (copy while keeping the file permissions) which is a really common thing to do. Lots of little things like that drive me absolutely bonkers because maintaining any kind of script that is supposed to run on mac and linux is basically impossible. I have an easier time shell scripting on windows machines with cygwin than I do on mac os.

Right. I get that.

Yes that last script processes named arguments and turns them into script variables. But using the --myvar somevalue style. Obviously I copied it from somewhere.

Again - how has this (or some other style of named arguments) not been tacked on to the language at some point? Blows my mind. Positional arguments are really cumbersome if you just want the default value 90% of the time for most things.

Yeah I forget #!/bin/bash sometimes then spend hours pulling my hair out. Fun stuff.

This is the style I write all of my scripts in. You can see my argument parser here - feel free to use it/steal it. I think it's pretty self explanatory but maybe it isn't.

Dont recommend running everything with set -e until you're really comfortable, lol. It terminates the script on any line that returns non-zero status to the OS. But it catches bugs in the script REALLY fast.

Here's a good explanation from a blog post I found that explains what the above parser is doing:

https://medium.com/@Drew_Stokes/bash...g-54f3b81a6a8f

You just paste that into every script?