GSoC 2019: Community Bonding Period — II#
So as I discussed in my earlier posts about how I started my Community Bonding Period, so this post deals with the remaining tasks that I did for the remaining part of the Community Bonding Period. ### Starting with the Week 01 tasks
I had a chat with @Cadair who is my mentor, and we decided that I
start with the tasks of the
first part of
the project. GitHub has these awesome project tabs, which help you sort
out all the tasks and todo for a GitHub project, and even though it is a
simple feature, it makes managing the stuff look neat and easy.
So I approached the tasks as it was given, and by refactoring each of the methods, I realised that as simple as the work sounds, there is a lot of overhead to cover, before a method is refactored. Even though, I have written lots of tests in my short developer period, but contributing and making changes to a new repository requires a lot of learning and unlearning, especially modifying the tests.
After going through each of the test cases, I realised, that it is a different beast all together. However the overhead does make a lot of sense, as it makes sure that the intention of a developer is shown as he/she thinks while coding up the features.
Making progress with the tasks : Coding 101#
As it happens, I made lot of refactoring, and I tested out each of the
methods, if they are performing as expected. The mantra for making a
successful contribution is Code — Test — Document all along. Well
lets add another dimension to it — Code Reviews. Code reviews are
really important, if not the most underrated task, as I got my first
PR, reviewed by
@Cadair and @DanRyanIrish.
Even though I have had my code reviewed by many people earlier, I still was a bit nervous about going through, as Code Reviews differ from the person who are reviewing. I got few suggestions as they went through, and believe me it was a really good experience, as they shared how coding style should be maintained for a given codebase, and how wandering away from them can be a nightmare for maintainers.
Overall, my PR hasn’t been merged, as it is a bigger part of my project, so lot more changes are expected, before it gets merged.
Contributing to SunPy1.0#
While the title sounds a bit misleading, as I have made PRs to
SunPy/NDCube it does not directly affect SunPy, but I have made
changes which might affect SunPy indirectly.
After completing most of the
tasks, I
decided to do something else, unrelated to my project. I had a chat with
@Cadair and he suggested me to help him to fix some tests which were
failing in SunPy/NDCube. As SunPy was quite near to be released,
so some changes were breaking SunPy/NDCube. On skimming through, I
wasn’t able to make any sense of what was happening, so I used debugging
techniques to figure out the issue. Those who don’t know about debugging
and the techniques, believe me it’s Just Like Heaven.
Python has a lot of tools by its toolbox, one of the most powerful and
the elementary tools for debugging is breakpoint(). It is supported
in Python3.7 , and it turned out as a saviour for me.
Breakpoint() helps in stopping the flow of code at the point of time
where the code breaks; where stuff happens the way it shouldn’t have
happened. It helps us in inspecting the state of the object and the
logic of the code, so you can understand the context of the issue
generated by the failing tests.
Enough of the technical jargons, let me discuss the work that I did,
which marked the ending of the Community Bonding Period. After countless
debugging, I found that the plotting code of NDCube used
pixel-values instead of pixel-edges, and since SunPy had
changed its API, now requesting pixel-edges instead of
pixel-values . I made a PR for changing the support to
pixel-edges instead of pixel-values. I got a
PR merged for 1D
plotting, but the PR for
>1D needs to be merged.
Links to previous post#
First meeting and plan of action — Link