667
edits
Changes
no edit summary
* Research on Bull/Redis code
** https://github.com/Seneca-CDOT/telescope/issues/112 has lots of ideas for Issues you could file and fix
== Week 11 ==
* 0.3 Recap
** Make sure your PRs, Issues, and Blog posts are [https://wiki.cdot.senecacollege.ca/wiki/OSD_%26_DPS909_Fall_2019_-_Release_0.3 posted on the 0.3 page]. I'll mark 0.3 and 0.4 together, in case you're still cleaning up work from the past week (you have time).
** Over 100 Pull Requests, 67% are already merged
** 476 commits to 325 files totaling more than 20K lines of code edited/added
** Top Repos: Telescope! followed by Microsoft, Mozilla, Facebook, Uber, Zeit, Elastic, GatsbyJS, .NET, and 100 others
* Telescope Updates
** [https://gource.io/ Gource visualization of the repo]
** Tour of the Code
** TODO - Plan for 0.4
** How to get involved
*** triage issues
*** reviews
*** help debug things others are stuck on in PRs
*** help people with git issues
*** fixing bugs
*** [https://github.com/Seneca-CDOT/telescope/issues/251 project management]
* Discussion of git Workflows
** Value of CI - [https://travis-ci.org/Seneca-CDOT/telescope Travis CI builds] and [https://circleci.com/gh/Seneca-CDOT/telescope Circle CI builds]
*** [https://treeherder.mozilla.org/#/jobs?repo=mozilla-central CI for Firefox]
** Rebasing vs Merging
** Linear history is better than a tangled web of merges
*** gitk on Telescope vs.
*** gitk on Prettier, node.js, WebKit, Gutenberg
** Many, Small PRS are better than a few big ones
*** easier to review
*** easier to merge
** Break your work up, leverage the community of developers we have
** Dealing with package.json and package-lock.json
* Case Study
** [https://github.com/humphd/desktop/tree/good-first-experience-issue-6390#walkthrough-fixing-a-bug-in-github-desktop Walkthrough: using history to debug with git bisect]
== Week 11 ==
* 0.4 Status Check
** [https://github.com/Seneca-CDOT/telescope/pulls Pull Requests]
** [https://github.com/Seneca-CDOT/telescope/issues Issues]
** Countdown: 2 weeks to a working program. What risks do we see? How to address them?
* Case Study: [https://google.github.io/eng-practices/ Code Review at Google]
** [https://google.github.io/eng-practices/review/developer/cl-descriptions.html Creating Reviewable Code]
** [https://google.github.io/eng-practices/review/developer/small-cls.html Preferring Small Changes]
** [https://google.github.io/eng-practices/review/reviewer/standard.html The Standard Code Review]
** [https://google.github.io/eng-practices/review/reviewer/looking-for.html How to Review Code]
** [https://google.github.io/eng-practices/review/developer/handling-comments.html How to Handle Review Comments]
* Case Study: [https://engineering.shopify.com/blogs/engineering/successfully-merging-work-1000-developers Shopify developers using git, CI, merging]
** Over 1000 developers working on the code
** Shopify changes 40 times a day
** 400 commits a day to master
** Master must always be green (passing CI)
** Master must stay close to production
** Emergency merges must be fast
** /shipit GitHub integration
** Merge queue to manage merges to master