.Net, Rails, and other stuff: May 2017

Sunday, May 28, 2017

Nothing Matters More Than Coding Fast

Saturday, May 27, 2017

Flexbox explained using animated gifs

https://medium.freecodecamp.com/an-animated-guide-to-flexbox-d280cf6afc35

yap-json

https://github.com/cesarferreira/yap-json

Pipe your json into yap-json to make it pretty

curl -s https://api.github.com/users/cesarferreira | yap-json

git: View changes in last commit of a file

https://stackoverflow.com/questions/10176601/git-diff-file-against-its-last-change

See last commit's changes: git log -p -1 filename

See last 2 commits' changes: git log -p -2 filename

Tuesday, May 23, 2017

https on StackOverflow

https://nickcraver.com/blog/2017/05/22/https-on-stack-overflow/

Monday, May 22, 2017

Mavo - A new, approachable way to create Web applications

http://mavo.io/
Mavo helps you turn your static HTML into reactive web applications without a single line of programming code and no server backend.
Developed in the Haystack Group at MIT CSAIL and led by Lea Verou.

Rails Active Record: To combat N+1 queries

https://evilmartians.com/chronicles/fighting-the-hydra-of-n-plus-one-queries

Linux tools

https://bsima.me/clog/server-tools.html

Sunday, May 21, 2017

Code Reviews related

Want to note down this thought so that I can think about it more later:

Problem:
- code review is usually done on a pull-request
- code-reviewer usually feels some pressure to not suggest trivial changes
- developer who wrote the code also feels pressure to not submit anything for code-review until he/she has reached a certain point
- note that the developer is getting too invested in his/her code by the time his/her code goes to code-review
- since the code-reviewer is aware of this, he/she might feel some pressure to mark the pull-request as 'code reviewed'

Possible Solution:
My thought is:
- developer submits a 1st pull-request that is explicitly marked as Temp Pull Request (and Do Not Merge label)
- this 1st pull-request is only for getting feedback (big and small changes)
- this 1st pull-request will not get merged even though it might be good
- developer has to create a second normal Pull Request which he/she is more confident of
- this second normal Pull Request will also have to code-reviewed and will be a candidate for getting merged

Advantages:
- less pressure on developer when giving the Temp Pull Request for review
- less pressure on code-reviewer while offering feedback for a Temp Pull Request
- Based on whether a reviewer is looking at a Temp Pull Request or a Normal Pull Request, he/she can be in the proper mindset to review the code
- The Normal Pull Request can include a link to the Temp Pull Request. Reviewer can see comments of the Temp Pull Request to get more context.