CORS error related to React and Babel

I'm throwing hands if someone commits directly to master or dev.

Our juniors don't even have rights to merge on dev / master. Yes, It's a hassle to review, but it's saved many an ass more times than I can count.

Human error is real, old scripts happen. Reviews and long gh / slack threads is how we solve that. Test thrice (human, human, machine) merge once.

Seems git really is everyone's favorite topic
 
And do yourself a favour, which is in line with the general thinking in this thread, DO NOT use git desktop GUI's.
Otherwise, you end up knowing how to use e.g. VS Code SCM, not actual git.

also dont get into bad habits - I have a rule for all our developers - you may not use "git add ." - this is a sure-fire way to commit a node_modules, or secrets to the repo.

Here is an extract from our rules/processes around git
No-one I know uses git without some additional tool.

Using VScode is no different than using magit, except the one is designed for human beings, whilst the other is designed for ...other creatures.
Screenshot 2021-11-04 152245.png
 
Naah, miss me with that.

I commit everything I want to MY branch. From debugger statements to commented out code. Everything.
I like to make a snapshot of where I am before I sign off for the day. I push every day as well as I don't want to lose a day's work due to a crashed harddrive or stolen laptop.
If I were to be hit by a bus, my colleagues have access to my branch.

I will clean up my branch before publishing the PR and inviting reviewers though.

Also, having a nice GUI that shows me what is staged and what isn't, with an easy to use comparison tool is invaluable. I can and have used the command line before and still do for some tasks. For adding and committing changes? Nah, I'll use a GUI for that.

If for some strange reason people in a team push directly to master on the other hand....

But that is fine. In fact it is part of our process

* All code must be pushed to the remote before leaving for the day.


That is in no way the same as committing AND pushing a secret, or a 100meg file, that is now in the repo forever (even if they realise they did this and "uncommit")
 
"git diff" - the ultimate easy to use and read comparison tool ;)

I bet you guys copy and paste with your mouse too - drag, right click, copy, move to position, right click, paste :ROFL: :love:


tbf, I did use tortiosegit on windows for diffing, just because at that time the terminal support in general was poor - thankfully I am no longer afflicted
 
Last edited:
Seeing that we are on the topic of git...
i read that you commit almost as often as you save. If this is true then you typing a huge amount of commit comments. This statement i guess is based on the idea of committing your changes as you evolve a part of the code.
often i find myself making a whole lot of changes then spending lots of time figuring out what change goes with what and then staging & committing that
how are you folk approaching this?
 
Seeing that we are on the topic of git...
i read that you commit almost as often as you save. If this is true then you typing a huge amount of commit comments. This statement i guess is based on the idea of committing your changes as you evolve a part of the code.
often i find myself making a whole lot of changes then spending lots of time figuring out what change goes with what and then staging & committing that
how are you folk approaching this?
I prefer squash merge, as in here's the feature PR.
Some like granular commits, I follow the team/project for their approach.
 
svn merge conflicts :mad:
I still remember, as a mid level sitting with a POT of coffee and a fresh pack of smokes at 2am, working my way through a particularly nasty merge + tree conflict. It was weeks of work, from 4 devs. And cause I'm frontend, I'm always the last to merge. One of the seniors at the time decided he needed a symphony upgrade, 1.4 if memory serves.

It was such a shitshow, I gave up at 7am and just left. 2 screens running np++ and furiously copying, building, failing, paste and replace... try again.

We ended up regenerating the entire codebase, new file structure, optimizing the queries, the whole kit and kaboodle, and the place I worked still had the gall to bill for it.

Now any company I walk into, given half a chance (in the first week) I rate their ticketing and review process. It's a great indicator of company ethic and a good yardstick for longevity.

Looking back at it, and how much time I wasted, cause I wanted to do things "right", I still chuckle at how we get hung up about stuff that doesn't even exist anymore (xslt, never again...)

Prost!
 
Seeing that we are on the topic of git...
i read that you commit almost as often as you save. If this is true then you typing a huge amount of commit comments. This statement i guess is based on the idea of committing your changes as you evolve a part of the code.
often i find myself making a whole lot of changes then spending lots of time figuring out what change goes with what and then staging & committing that
how are you folk approaching this?
We follow a 250 / 250 rule most of the time.
Don't commit anything with a diff higher than 250 (add or remove) and you should be able to explain what you did in 250 characters or less.

And a one liner explanation with a 250 pr is going to get you grilled.

Obvs there are exceptions (eg. a class to functional refactor comes to mind) but you can logically split those, and augment any docs while you are there.

Where does 250 come from, and this is project dependent, (our bigger projects clock 500). Trial and error, newbies slinging 2000 line diffs, and then having to waste time unraveling their own mess, while not being able to explain why they rewrote a swath of scss or reducers / gql.

Most of our PRs are way below, easy to review, easy to read up on, easy to recover from.
 
We follow a 250 / 250 rule most of the time.
Don't commit anything with a diff higher than 250 (add or remove) and you should be able to explain what you did in 250 characters or less.

And a one liner explanation with a 250 pr is going to get you grilled.

Obvs there are exceptions (eg. a class to functional refactor comes to mind) but you can logically split those, and augment any docs while you are there.

Where does 250 come from, and this is project dependent, (our bigger projects clock 500). Trial and error, newbies slinging 2000 line diffs, and then having to waste time unraveling their own mess, while not being able to explain why they rewrote a swath of scss or reducers / gql.

Most of our PRs are way below, easy to review, easy to read up on, easy to recover from.
None of that made sense... i am relatively new to git and currently use it in a solo type of setting
 
None of that made sense... i am relatively new to git and currently use it in a solo type of setting
In solo terms. Commiting every time you save, is overkill. Break the problem down into logical / reasonable chunks. Something you think you can accomplish in let's say 2 hours. Solving a problem takes time.

If you need to break for lunch, do a commit, done for the day, commit. Think of it as way points in your problem solving journey.

The whole point of git is not to use it like cloud storage (https://vscode.dev if you really want to work like that), it's to create a logical trail of solutions that culminate in the current state and function of your app.

Think of it like a book of short stories, you should be able to read and re-read the "stories" to reconstruct what you did, and why you did it. At the end of the day git should be your safety net, not a hinderence.

I hope that makes sense.

My team, design or dev works on this principle, and it has served us really well. We have lost little to no code, even when we've had power outages, github going down, or dev boxes straight up failing. All because we work in a similar manner. I had my iMac fail on me last year, mobo dead in the water. It took me exactly 6 hours from getting my new mbp to being back on track, reviewing PRs and picking up where I left off with a websocket implementation. I essentially lost 3 hours, if that.
 
Last edited:
Seeing that we are on the topic of git...
i read that you commit almost as often as you save. If this is true then you typing a huge amount of commit comments. This statement i guess is based on the idea of committing your changes as you evolve a part of the code.
often i find myself making a whole lot of changes then spending lots of time figuring out what change goes with what and then staging & committing that
how are you folk approaching this?
I do exactly this - wouldn’t say I spend lots of time on it, but I definitely chunk my commits.
To be clear - I give zero ****s about “git history”.
I do it for myself.
I try to do everything in life excellently.
I guess it is a sort of OCD - but have my moments of “screw it, ‘git add .’ ‘git commit -m “a lazy message”’ “. But I am allowed to do this, because I am elite, and I am making a conscious choice do do it in that moment - “do what I say, not what I do”/“rules for me, rules for thee” :)
 
Last edited:
I still remember, as a mid level sitting with a POT of coffee and a fresh pack of smokes at 2am, working my way through a particularly nasty merge + tree conflict. It was weeks of work, from 4 devs. And cause I'm frontend, I'm always the last to merge. One of the seniors at the time decided he needed a symphony upgrade, 1.4 if memory serves.

It was such a shitshow, I gave up at 7am and just left. 2 screens running np++ and furiously copying, building, failing, paste and replace... try again.

We ended up regenerating the entire codebase, new file structure, optimizing the queries, the whole kit and kaboodle, and the place I worked still had the gall to bill for it.

Now any company I walk into, given half a chance (in the first week) I rate their ticketing and review process. It's a great indicator of company ethic and a good yardstick for longevity.

Looking back at it, and how much time I wasted, cause I wanted to do things "right", I still chuckle at how we get hung up about stuff that doesn't even exist anymore (xslt, never again...)

Prost!
svn lock, svn cleanup. Getting cold chills thinking about it :X3:

I remember when we moved from svn to git.
Merging seemed like magic. TBH, I kind of “like” resolving git merge conflicts, no idea why :ROFL:

Still glad that my professional life never included CVS or TFS
 
I do exactly this - wouldn’t say I spend lots of time on it, but I definitely chunk my commits.
To be clear - I give zero ****s about “git history”.
I do it for myself.
I try to do everything in life excellently.
I guess it is a sort of OCD - but have my moments of “screw it, ‘git add .’ ‘git commit -m “a lazy message”’ “. But I am allowed to do this, because I am elite, and I am making a conscious choice do do it in that moment - “do what I say, not what I do”/“rules for me, rules for thee” :)
I think we've both been on either side of that coin. Where rules where enforced, on some.

We all use what power we have as leaders, to make the best decisions we can, sometimes selfishly. It was only when I saw my decisions come home to roost, and how it affected the greater mindset of my team. (it's incredible to watch how fast power actually rewires a brain) that I learnt that rules are rules regardless of position.

That day I learnt the hard way, that power, applied by the inconsiderate is a runaway train.

A short tale of ruthless ruler mentality.

We hired 2 junior devs, one remote, one local, and handed them an angular rebuild. Basic ****, db, api generation, frontend scaffolding, with support from a copywriter and a designer for assets.

I checked in with the local and remote devs, twice a week. Mondays, and Fridays. They had to keep regular hours with a bit of a timezone difference.

The wheels came off, 3 weeks in, why? Cause the local dev, together with the copywriter decided to take the project in a different direction. And make a simple rebuild into a portfolio piece. The designer nearly quit, (it took some real sweet talking to keep her) and the remote dev started committing less and less.

So 3 weeks, into a 6 week rebuild, the project looked nothing like the specs the client had signed off on, and the junior dev had the balls to sit his ass down in a client meeting and tell the client to his face that has no idea about his market, and that the way the site is currently being rebuilt by him (alone) is going to increase product adoption dramatically.

I was thinking to myself, at that moment, motherf***er, Mercedes knows how to sell cars, they've been doing it since the 19th century. They do not need some fresh from the books 23 year old telling them how to market their product.

He walked out of that progress update meeting, and then him and the copywriter dipped for lunch.

Needless to say, I had to spin some **** about how good the rebuild actually was, speed, responsiveness and that we where really passionate about this project...

Thank god for contracts, cause I logged into his work machine and discovered how he had been ordering the designer and remote dev to do the rebuild, while he was working on "the better version" on a different branch.

IP theft, it was heading that way, internal briefs, shared with friends, yep. Designs shared publicly, you bet.

Breach of NDA, that's how we dropped him from the project.

All of this because I as the lead on this project, assumed that people could handle a little bit of power, and work as a team.

Moral of the story, iron clad contracts, and good procedure for everyone, stops bad actors from getting away with rotting a project from the inside.
 
I think we've both been on either side of that coin. Where rules where enforced, on some.

We all use what power we have as leaders, to make the best decisions we can, sometimes selfishly. It was only when I saw my decisions come home to roost, and how it affected the greater mindset of my team. (it's incredible to watch how fast power actually rewires a brain) that I learnt that rules are rules regardless of position.

That day I learnt the hard way, that power, applied by the inconsiderate is a runaway train.

A short tale of ruthless ruler mentality.

We hired 2 junior devs, one remote, one local, and handed them an angular rebuild. Basic ****, db, api generation, frontend scaffolding, with support from a copywriter and a designer for assets.

I checked in with the local and remote devs, twice a week. Mondays, and Fridays. They had to keep regular hours with a bit of a timezone difference.

The wheels came off, 3 weeks in, why? Cause the local dev, together with the copywriter decided to take the project in a different direction. And make a simple rebuild into a portfolio piece. The designer nearly quit, (it took some real sweet talking to keep her) and the remote dev started committing less and less.

So 3 weeks, into a 6 week rebuild, the project looked nothing like the specs the client had signed off on, and the junior dev had the balls to sit his ass down in a client meeting and tell the client to his face that has no idea about his market, and that the way the site is currently being rebuilt by him (alone) is going to increase product adoption dramatically.

I was thinking to myself, at that moment, motherf***er, Mercedes knows how to sell cars, they've been doing it since the 19th century. They do not need some fresh from the books 23 year old telling them how to market their product.

He walked out of that progress update meeting, and then him and the copywriter dipped for lunch.

Needless to say, I had to spin some **** about how good the rebuild actually was, speed, responsiveness and that we where really passionate about this project...

Thank god for contracts, cause I logged into his work machine and discovered how he had been ordering the designer and remote dev to do the rebuild, while he was working on "the better version" on a different branch.

IP theft, it was heading that way, internal briefs, shared with friends, yep. Designs shared publicly, you bet.

Breach of NDA, that's how we dropped him from the project.

All of this because I as the lead on this project, assumed that people could handle a little bit of power, and work as a team.

Moral of the story, iron clad contracts, and good procedure for everyone, stops bad actors from getting away with rotting a project from the inside.

I remember the hires that had us change our hiring processes to require technical tests, and I remember the team members that changed my mentality from trusting people to verifying that they are actually making the progress they say they are during the stand up meetings. Until they've proven themselves at least.
 
Top
Sign up to the MyBroadband newsletter
X