There are a few styles for code reviewing, like just take a look around the code. Maybe something missing character or the naming variable does not fit our organization code standard such as using camelCase or Sentence case, or maybe to use CAPITALIZE string for constant.
But sometimes or perhaps it should happen when you do some code reviewing, do checkout branch to your local machine. To check the process on the Pull Request issue.
In this case, I use 3 level branches: upstream, origin, and local. Which is a pull request that happens on the upstream level.
Part of [TIL] series on my medium page.
CAP principle :
Consistency : data consistency for each machine
Availability : system still works while one of the machine is down
Partition Tolerance : system still works while the machine not connected
You could only choose 2 of 3 in CAP theorem .
I would like to make this series of [TIL] as my knowledge base, so basically I will make this as my library. Maybe could be useful for you too.
Build a system (example : API for regional data) which can handle 1000 requests per second. On the second month requests increase to 10,000 per second, then third month increase to 100,000 per month.
Vertical Scaling :
Increase current server : make higher RAM, CPU, HDD.
Build new server with same specifications
Comparison between Vertical and Horizontal Scaling :
Have you ever realized how is your engineering journey so far?
When your first code was the same old Hello World? When you’ve clean up drive on your PC or laptop or cloud repository, and then you see your first project? Or just happened today when you see some bugs…
I’ve been working on software development industry about 10 years. First two years, work as freelance web developer. Work at real office happens in next job, work as programmer in some IT consultant company for two years. Next job was Database Application Engineer for three years. After work with two…