667
edits
Changes
no edit summary
*** https://github.com/ParabolInc/action
** [https://github.com/Seneca-CDOT/telescope/issues/112 https://github.com/Seneca-CDOT/telescope/issues/112] has notes on some research into these projects. Please add more as you find it.
== Week 10 ==
* Managing change on a fast moving project with lots of people
** Documentation doesn't work, project "rules" don't work
** Communication works (Watching Issues, Slack, in person discussions) and
** You have to enforce standards across a project using tools and automation
** Continuous Integration (CI) - [https://github.com/Seneca-CDOT/telescope/issues/43 we have Travis CI enabled]
** Static Analysis Tools
*** [https://github.com/Seneca-CDOT/telescope/pull/38 we have eslint for JavaScript using the Airbnb JavaScript Style Guide]
*** [https://github.com/Seneca-CDOT/telescope/pull/125 we have stylelint for CSS]
** Automated Tests with [https://jestjs.io/docs/en/getting-started Jest]
** Next we will [https://github.com/Seneca-CDOT/telescope/issues/96 add Prettier for standard code formatting]. Get your 0.3 PRs in before the weekend, or get ready for merge conflicts when this lands.
* [https://humphd.github.io/pretty-effective/ Case Study - Prettier]
** Web site: https://prettier.io/
** Twitter: https://twitter.com/PrettierCode
** GitHub: https://github.com/prettier/prettier
** [https://www.youtube.com/watch?v=hkfBvpEfWdA James Long introducing Prettier (video)]
** [https://www.youtube.com/watch?v=3p6XR2VeHRw Visualization of Prettier Development (video)]
** [https://prettier.io/docs/en/install.html Installing Prettier]
* Reviews
** PRs must have a title that explains the fix, links to an Issue #
** PRs must have a full description. If this is UI code, show a screenshot, or explain the fix, talk about how to review it, how to test it, what's not done, what's going to happen in further PRs, etc.
** All PRs must pass CI: eslint, stylelint, unit tests
** Don't let people land code with unrelated commits (e.g., merges with master)
** Ask people to update their master with upstream, and rebase
** Don't let people land code with changes to unrelated lines/files (e.g., package.json, whitespace changes)
** Make sure one PR doesn't undo the work of another (e.g., bad merge, erasing existing code)
** Ask yourself how we'll test every piece of code we take. We need to be able to trust it going forward.
** PRs for us to try reviewing together:
*** [https://github.com/Seneca-CDOT/telescope/pull/102 #102 - Added Extracting of URLs from blog feed function]
*** [https://github.com/Seneca-CDOT/telescope/pull/123 #123 - Fix #74: Validate blog URLs.]
*** [https://github.com/Seneca-CDOT/telescope/pull/136 #136 - Added feed list parser]
*** [https://github.com/Seneca-CDOT/telescope/pull/137 #137 - added pagination to feed for #40]
* 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
