Note: I'm currently taking a break from this course to focus on my studies so I can finally graduate
Based on the article: Using checklists for code review
In general, people are pretty good at the code review process, but it's sometimes surprising what can slip through. A natural consequence of the way our brains look at the world is that it's easy to pay a lot of attention to small details and code style flubs, and completely miss the big picture.
Obviously, not everything is applicable for every change. If the review request isn't making any changes to UI, then skip the first two checklists entirely. If a change is a bug fix, typically don't review it for architecture and design principles.
Put the big stuff first (e.g. architecture). You don't want to work through a ton of small issues before realizing that everything has to be rewritten.
Do a pass through the code for each and every item in the checklist. By only looking for a very specific type of defect, each pass goes relatively quickly, even for large changes. Focu
Don't solve the problem given (as it's stated), figure out what the real underlying problem is.
To understand design, you have to be a good observer and question things. Travel with a camera and take photos. Don't use flash, use natural lighting when possible.
Affordances are the relationships (read: possible actions) between an object and an entity (most often a person). For example, a chair affords sitting for a human. Affordances enable interactions between entities and objects (similarly, anti-affordances prevent or reduce interactions). The presence of an affordance is determined by the properties of the object and of the abilities of the entity who's interacting with the object.
Signifiers are signals, communication devices. These signs tell you about the possible actions; what to do, and where to do it. Signifiers are often visible, but invisible (secret) signifiers do exist, like clicking a YT video to play
For every power user that writes in asking for a feature, there’s one new user (and ten potential users) that felt the opposite way.
When you’re evaluating potential features, part of your role is to be an advocate for the long tail of users that won’t yet advocate for themselves.
| <div id=":vz" class="ii gt m145ad5537035869c adP adO"><div id=":vy" class="a3s" style="overflow: hidden;"><div><div class="adM"> | |
| </div><div bgcolor="#fafafa"><div class="adM"> | |
| </div><table border="0" cellspacing="0" cellpadding="0" width="100%" bgcolor="#fafafa"><tbody><tr><td align="left" valign="middle" height="40" bgcolor="#e4eff7" style="color:#787878;font-family:Arial;padding:5px 30px 5px 30px"> | |
| <div style="font-size:14px;letter-spacing:1px;font-weight:bold;color:#787878"><a href="https://eventing.coursera.org/redirect/K94Ky5AdlhxW-FQnYSZZtJPNSf_mKt0SlLY3BJoPtzGpi9uZUEt5y2t4OE_LPJ_BCElO-LwczCh98rRU3vjkFA.KYet1zUYKuWJE3yZ5nv7dQ.ew5zeZYivcmzO41tPxqLBchVIzZJsUl86CrpCEZL-BqfouGmyTiOsoHV6zgPWIft-5F1i2Ug42EeeOJS1yfZ-yZdoMF_Oc5dO2aP7vtdCqLHEQLkq4-vHwBL8nGe-T7Lypqw5CtuKyoVwWGNHb0s-n1mM3r5RfTIVyrGJYV4m8NKQI-m4K18qD0fszw5u0_OxR_24DUqzkXqfMfOD9_MwhEkfow89tPO2CYoYdWths3E9TQ3gK_KdRjJRm8AfgKVyacIGbanQ3tUENlDUy_E7E9YMuAmYCXUHe02U2p5FlEQW7LnDqTtG3MYC3uVCOW46Bs3_oIFzlryBTrariC7y1s3KXDtwE83vBW9t65D62 |
useful command for debugging.
tail -f <filename>
tail -f -n <number-of-tailing-lines> <filename>
#example to tail from last 1000 files
tail -f -n 1000 <filename>