Release 0.3 PR2

  For release 3 we have to make 2 PR's. The first one must be for the Telesope project and the second one must be for an external project. These PR's must "build up" from the PR's we did for release 0.2. This blog post will highlight working on the PR for Telescope. When I started this the first place I went was to the issues page on the Telescope repository. I saw there were some tests that needed to be written and were interested in taking on one of these issues. These were more complex than the test I wrote for the first part of 0.3 so  I saw it as a good opportunity to improve my skill. I asked in Slack for some advice on what to do and was given this idea from David:


This seemed like a good test to write (challenging but something I can figure out) so I made an issue for it and started working! When I first wrote the test everything looked fine but it kept on failing. At first, I thought that's good, if we pass an invalid date shouldn't the test fail? Turns out I didn't funny understand the syntax of Jest testing. David explained to me that when:
 expect(() => createPostWithDates('Thu, 45, Nov 2014', 'Thu, 35 Dec 2014')).toThrow()
fails jest is saying "this should throw but it didn't". So I went back to see why it won't throw. I tried many things: at first, I thought there might be something wrong with the enduseDate function, I kept rewriting the tests, but nothing was working. I went back to the issue and made a comment letting the maintainers know my troubles. Calvin took a look and also couldn't figure out why this kept failing. After some discussion, we asked David for some help. Turns out my understanding of this issue was wrong. The entire time I thought an invalid date is something like Jan 40 2015. Turns out the date object already checks that for us (I did not know that before!). For this reason, the ensureDate() function only needs to check if we are passing a date object or not. After learning this, I was able to complete the test! 

I then made a pull request and got my code merged!
This experience made me learn to always take some time, in the beginning, to really understand the issue and code surrounding it. Although at times one is excited to start and finish something we sometimes fail to realize that spending time, in the beginning, to understand the code will save us time while writing some new code. Before I end this blog I would like to thank Calvin and David for helping me with the road bumps I encountered with this issue. Looking back I am really happy this happened as this experience led me to learn something new about the Javascript Date object.   







 

Comments

Post a Comment

Popular posts from this blog

OSD600 Release 0.4 Part 3

Image
 This is the last blog for OSD600 and the last part of release 0.4! I am excited to be writing this as after this I will be done with everything I need to do for my classes this semester, and graduate! One issue I noticed while working on this is I did not fully understand what was needed to "port" a component from Gatsby to Next. At first, I thought everything you needed to do to port a component was in this migration guide  posted in the issue . After talking to some people on Slack I learned we must not only follow the migration guide but also convert the JavaScript code in the components to TypeScript. I have worked with Typescript before so I had an idea of how it works/what it is (it's basically JavaScript with types), but I never knew how to convert JavaScript code to TypeScript code. After doing some research I learned this process can be broken down into two simple steps: 1. Change all the .jsx files to .tsx files. 2. Add types to all the variables made. Eg. func
Read more

OSD 600 Lab 2

I really enjoyed this lab as is helped me understand the process/workflow of contributing to open source. I wrote a separate article on that which can be found here .  During this lab, I created an issue  on the original repository saying I wish to implement additional features to the code.  Once I got approval from the original author to do this I forked and cloned the project, created a new branch called issue-2 , and uploaded the code I wrote to it. After that, I made a pull request to the original repository. For my feature, I added the v and version arguments to their command-line tool. The process of getting my work accepted was exciting as I got to hear from the person who wrote the code and learn what it is exactly they want. This a great opportunity to improve on the code you wrote. One problem I had was after I got the feedback I was not sure how to edit code on the issue-2 branch, after doing some research I learned how to switch branches via the git checkout command. I al
Read more