Difference between revisions of "OSD600 and DPS909 Winter 2018 Lab 3"

From CDOT Wiki
Jump to: navigation, search
(→‎1. Pick your Bug(s))
(No difference)

Revision as of 15:39, 14 February 2018

Fixing a Bug In VSCode

This week we've been looking at how one approaches fixing a bug in a project like VSCode, see https://github.com/humphd/vscode/tree/good-first-experience-issue-42726#walkthrough-fixing-a-bug-in-visual-studio-code.

In this Lab, you are asked to continue your practice of these techniques, and try researching a fix to an existing bug.

A few instructions before you begin:

  • You must have already completed Lab 2
  • You may work in pairs/groups for this lab, but you must each do your own write up
  • You are not required to fully fix your bug and submit a pull request. This lab is about research, and learning the techniques and tooling only.
  • If you do fix your bug, and want to submit a pull request, please speak with me so we can co-ordinate your work with other students (i.e., so people don't take opportunities from one another).

1. Pick your Bug(s)

From the list of available VSCode Issues on GitHub, you can work on any bug you like (i.e., has the 'bug' label). Here are some suggestions of bugs that might be worth considering:

I opened some big number of files (), tried to search in them with Ctrl-Shift-F, but I got a message: spawn ENAMETOOLONG

Pick one or more bugs to work on during this lab. It's OK if other people are working on the same bug, since you're not required to submit a pull request, only do the research.

2. Research, Debug, and Try to Understand the Bug

After choosing your bug(s), try to recreate them in your dev build of vscode. What is your bug all about? Can you confirm that the bug exists? Can you reproduce it? You might have to do some work to alter your environment in order to get the bug to occur.

Try to figure out where the code is that relates to this bug. Use the Debugger, search through files in GitHub and git, look at other Issues and Pull Requests (especially closed ones) which may have code or other clues.

See if you can narrow down what is likely causing this bug.

It's OK if you can't. Keep track of all your research, guesses, what you tried, what worked, what didn't, questions you have, ideas you're exploring, etc. We'll need all that info for your blog post.

If you get really stuck, consider switching to a different bug from the list above. Don't waste a lot of time lost on a bug you can't solve. Make sure you're making progress, or switching tracks if you're stuck.

3. Can you Fix it?

After you do your research and start to locate the code related to the problem, see if you can make a fix. Your fix can be a simple one, it doesn't have to be perfect at this point: we're doing research.

What did you fix? What happened when you did? Did your fix correct the bug? Did it break anything else (other parts of the app, the tests, etc)?

Keep track of what you do.

3. Blog

Write a blog post about your experience researching and fixing a bug in VSCode. Some things you could discuss in your post:

  • Which bug(s) did you work on?
  • What was this bug about? How do you make it happen (steps to reproduce)?
  • What did you do to try and track down the cause? How close did you get?
  • What tools, techniques, approaches did you take when researching? What worked well, what didn't?
  • Were you able to do a fix? What did you change? Did it work for all cases, or was it just a start?
  • What did you learn while doing this? What kinds of things did you notice in the code that were surprising or new to you?

Please add a line for your blog in the following table:

# Name VSCode Bug(s) (URLs) Blog Post (URL)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
Retrieved from "https://wiki.cdot.senecapolytechnic.ca/w/index.php?title=OSD600_and_DPS909_Winter_2018_Lab_3&oldid=131500"