Smotko
Joined 15 years ago
Karma
266
Submissions
42
Member since
Feb 10
Recent submissions
Comment · 3 years ago
Comment · 4 years ago
This looks really cool, awesome job! We desperately need something like this at my day job, but unfortunately we use MySQL and Django.
Comment · 4 years ago
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.
Comment · 4 years ago
I'm not sure if this was intentional or not, but it made me chuckle:
Your pain is our concern so here's some wisdom:
undefinedComment · 7 years ago
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.
Comment · 7 years ago
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.
Comment · 7 years ago
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.
Comment · 7 years ago
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.
[0] https://blog.codereview.chat/2019/06/27/code-reviews-and-you...
Comment · 7 years ago
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.
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.