Oh yeah you’re completely fucked.
THIS TIME I was not.
genius would be remembering to put the spacer file bacj when you are done fixing the server the first time.
But it would be nice on a mac or PC when the disk space gets low and everything grinds to a halt. Delete the 8GB file then work on other cleanup.
Maybe wrong thread but is anyone here an excel wizard
How do I write a conditional formatting rule where only if the value in column b is greater than column a does excel change the cell colour? This assumes all the values in both columns are different and not fixed.
If you want to format B1:B100, you should be able to just add a rule for less than A1 (not $A$1), and it will compare each cell in column B to the corresponding cell in column A.
I think I’ve probably asked this before, but…
People say “commit often”. How often do you commit? Like ballpark how many times a day on average?
I commit anything I wouldn’t want to lose. Try not to over-commit, because that can be obnoxious, but definitely work pieces that can be considered “chunks” of related work, that I have tested, will get committed. Some days it ends up being 1-2 commits, other days it turns out to be 10+.
A bunch of smaller commits is much easier to roll back and test, in my opinion. Not to mention easier to review.
1 Like
It’s not really much different to saving changes in Word or Excel - when you don’t want to redo your work and there are no conflicts, commit it, and always before end of day.
2 Likes
Are you sharing a primary develop branch with the other devs and everyone commits straight to that? Or do you have your own branch?
The way we work each dev has a personal dev branch, or maybe a feature branch that is shared by multiple devs, which are spawned off of and then merged back into the develop branch with a pull request when ready.
In that case you want to pull the main develop into your personal branch at least once a day. But how often you commit/push to your branch doesn’t really matter much except as a backup in case your computer dies.
Pull requests are nice because they’re a nice snapshot of the changes that’s easy to go look up. But I know not every shop works that way.
2 Likes
The thing right now I’m thinking about is a javscript function that is 10 lines long. It works, but there’s certainly no guarantee it won’t change - even today - and it will almost certainly be moved to another file. I could see someone who is going to try to step through what changes I’ve made want to see it as a chunk, so I guess that’s a good time to commit even though it’s unlikely anyone does want to look at it that closely.
I guess I’ll commit. My only feedback on git so far is when I made another branch to work on (first time I’ve ever done that btw) and let them look at it before merging and I was applauded for it, but they said it wasn’t necessary - small team - just feel free to commit anything to main.
99% of professional development is done in git feature branches that gets merged back into master after code review/QA review and are squashed to 1 commit. Which means commit as much as you want. I usually do 1-4 times a day if I’m like actually writing code. Any time you get to “dev complete” on a feature do a commit imo.
No one does commits right to master (professionally) and most git repos will prevent that anyways.
3 Likes
Is that true during development, when there really is no production version yet?
Anyway, these people do on this project anyway, people are getting paid, and they’re all programmers for like 25+ years at least some of whom have worked on very large projects at very large companies, but this is a very small project at a very small company.
That’s nerve-wracking.
1 Like
yea that’s a big red flag. lol. I’ve never heard of a shop where people are just constantly ramming stuff into main/master but I guess it can work if the team is small.
Maybe the thing is that this isn’t really “main”, it’s all development. No harm can be done. There is a live production thing, but we’re not touching that atm.
No production version yet is a different story. But do you at least have a development environment that you’d rather not break? Or is this all front end code?
I still don’t understand how these devs wouldn’t want to review your work first as the new guy. Are they looking at your commits if you don’t ask them?
It’s front and back. Breaking it would not be a big deal at this point. There are only two people working on it (mostly just me) and a third consulting.
