I don't understand why people are against this so much. Black does a sanity check and compares the AST before and after to make sure there aren't any meaningful changes (unless you are running it with --fast). So there is almost no risk that it will break your code.
There is nothing more frustrating than coming back from a coffee break only to find out that you have to rerun your CI check because of a trivial formatting issue.
It might be just me, but I feel like remembering the foreign key name is more difficult than remembering the columns that you need in the ON clause. Especially since you can usually find the column names by just seeing the data in the table (select * from x) wheres seeing the foreign key names is much harder (show create table x?).
Also, if you use an ORM it will usually generate foreign key names that are almost impossible to remember.
I have worked on a Google project as a contractor and I can confirm that over-engineering was our biggest problem. I was also partially to blame, but at the time I did not know better.
To fix this problem you can set up you CI server to merge into the base branch automatically before running the code (in fact you should probably do this by default for other reasons).
This way your devs won't have to merge, they can just rerun their tests, which should be the same workflow as if your CI config is separate from your codebase.
I've been using GitHub actions for my personal projects for the past few months. The documentation was not the best and the UX was not polished at all, so the experience was painful sometimes. A lot of my problems will be solved with the features announced today, except I'm not sure if they're also adding a way to cache e.g. dependencies between jobs.
While writing your own actions was painful (at least for me), reusing actions that other people wrote worked like magic. I think the reusability aspect is going to be huge when Actions get more and more popular.
The article makes some good points. Here are my thoughts:
> 1. Preliminary Checks
+1 for this, but I would also add that you need to add as much formatting/linting into this step as possible. You shouldn't be pointing out formatting issues in your code review.
> 2. Understanding
This is super important! Pull requests that do not explain their purpose in the description should not be reviewed.
The PR description is also really important when git bisect leads you to the PR when debugging a new bug.
> 3. Usability Test
A lot of debate regarding this, but I believe this is extremely important if not the most important part of your code review. For details read this section[0]
> 4. Code Review
A few good tips in the article, I'd just add that you should be polite and try not to waste people's time.
Actually, pair programming is a way of doing code reviews. Some teams consider pair programmed code as already reviewed. I don't have enough experience with pair programming to confirm this, but it is an interesting idea.
I felt the same way as you do, I used the git CLI directly and could never use a git GUI.
But then I figured out that Atom's git integration is actually quite neat and I started using it mostly to do `git add -i` as it makes staging files or parts of files really easy.
I still don't trust it with pushing/pulling, switching branches etc. so I still drop to the command line for those, but the atom git integration is incredibly useful for seeing your changes and committing a particular part of them.
We use IRC and a custom bot that logs chat history and does some other cool stuff. It works surprisingly well and it's really easy and fun to add new functionality to the bot.
I've tried KDE briefly a few months ago and I didn't like it. The reason was they were way to many customization options. I spent more than an our going through all the settings and I got completely overwhelmed.
Gnome Shell has little to no options out of the box, but it has extension that do just that.
Unity recently added some basic options into the default (new tab in the appearance dialog). They didn't add a lot of options but just the ones I seem to need :)
I prefer mutter to compiz too. I don't really care about resources as both of the shells run smooth on my laptop, but compiz can't show full screen flash video (youtube) on my secondary monitor, which is a little annoying.
I've heard awesome things about Awesome. I need to give it a try in the near future. Thanks!
From my experience 12.04 is quite stable, you are going to see a few app crashed reports but apart from that everything should work.
And I agree, Ubuntu (as well as other Linux distros) has come a long way. 4 years ago there was no way I could get my graphics card to work, today it works both on open source and propriety drivers. Amazing!
There is nothing more frustrating than coming back from a coffee break only to find out that you have to rerun your CI check because of a trivial formatting issue.