Blog - Posts by Yash Sharma

Google Summer of Code 2019 | Final Report | OpenAstronomy | NDCube

2019-08-24T00:00:00+00:00

Google Summer of Code 2019 | Final Report | OpenAstronomy | NDCube

GSoC FTW!

For those who are geeky and want to see the PRs submitted…

Here is the link where all my PRs for completing the project are present. > # Google Summer of Code (GSoC) is an online, international > #program designed to encourage university student participation in open source software development.

Details of my Organisation and Project

Before I start writing my report, I would like to thank my mentors Daniel Ryan and Stuart Mumford. They have been quite helpful in guiding me through the project, and have been quite responsive. Special thanks to Nabil Freij, for guiding through the project here in SunPy/NDCube.

NDCube is the fundamental class of the ndcube package and is designed to handle data contained in a single N-D array described by a single set of WCS transformations. NDCube is subclassed from astropy.nddata.NDData and so inherits the same attributes for data, wcs, uncertainty, mask, meta, and unit. The WCS object contained in the .wcs attribute is subclassed from astropy.wcs.WCS and contains a few additional attributes to enable to keep track of its relationship to the data.

SunPy: The Sub-Organisation that I worked in.

My GSoC project was under OpenAstronomy, and NDCube is a SunPy affiliated subpackage for handling ND Data arrays and perform data-analysis on them.

NDCube is a SunPy affiliated package for easily dealing with ND-Data cubes along with convenience method that allows the data cubes to be sliced, attach meta-data to it, and easy to use plotting methods, to visualize an ND-Data. It uses SunPy’s visualization to plot more than >2D cubes and provides sliders to shift the different dimensions, so even if users are using only 2D dimensions at a time, we can still leverage the other dimensions.

My project with NDCube was to port the internal API to match all the proposals laid out in APE14 and make sure that NDCube works in the same manner as it was working. The project was particularly interesting because I had a first-hand chance of interacting with API designing and how the different patterns were used to implement that. NDCube uses FITS-WCS to interact with, but APE14 leveraged the NDCube to use any WCS object implementing all the base methods laid out in the proposal. This was really exciting and I had a chance to use gWCS along with FITS-WCS in NDCube.

Blogging and details of my work

My weekly notes about my progress have been documented in my blog. Feel free to check out and suggest changes if needed.

Breakdown of my project

As described in my proposal, I had broken down my project into three parts —

Porting NDCubeBase to use APE14
Porting NDCubeSequence to APE14
Support plotting in NDCube

All the associated PRs have been blogged in the PR post that I made earlier. Feel free to check them and gauge the progress that I made.

Some Visuals associated with my project

Example of a WCS plotting with NDCube

Example of WCS Line Plotting with NDCube

My Experience with working with NDCube/SunPy

Right from the start, I was really interested in working in SunPy, because of its amazing community and responsive mentors which I had planned to learn from them. The mentors were really helpful, right from designing the proposal to implementing them, always filling out on potential hurdles and rescuing me out every now and then.

I decided to list out the tasks which could not be completed, as the rest of the checkpoints were achieved successfully.

Here are some tasks which I had planned but could not be done

Writing gWCS test-suite for NDCube — This was an optional part but having spent time with the code-base a lot, I realized that this could be done in a short time. However, this being an optional part, got pushed right at the end, and eventually had to be dropped off from the weekly tasks. I have planned to complete it after GSoC, so it remains on top of my priority list.
Completing plotting of NDCubeSequence — I had completed almost all of the tasks as I had planned in my proposal but remaining one — Completing the plotting for NDCube Sequence objects. I had made the PR, but on close digging with the codebase, I realized that the master codebase was buggy, and a bug fix was needed to be made before resuming my porting. I made the PR, and after consultation with my mentor, we decided to drop the priority for the bug fix and just concentrate on my porting. I made a PR but it remains open till the bug is fixed in the master branch.

My Experience with Google Summer of Code

GSoC had been an integral part of my sophomore life, as it was something that I wanted to try out, with the associated perks and the hyped-up( but true!) steep learning curve. I had started my contributions right from January when people are unsure with the organizations and the type of projects that they want to commit to for the rest of the summers. I chose SunPy because of its fantastic community of developers from whom I learned a lot.

There was blogpost by NumFocus which highlighted my learnings during GSoC, so I would be sharing some unique points (not share the old ones :P) that highlighted my learnings —

Make sure you have a good understanding of the subparts of the project

I have had some moments where I just went about my tasks without having a solid understanding of them. I had to revert back to understand it again, so I recognized my shortcomings after my first evaluations and made sure that I had a solid understanding of the problem, rather than diving into it, without understanding the what and why of the problem.

Make sure you have some backup tasks to fall back upon

I have had moments when my work progress dried out, but talking with my mentor(s) and having some backup tasks did help me with my case of sitting idle. This turned out to be crucial in the last few weeks, as I had little to no time of starting out on a new feature. Thanks to my backup tasks, I had to carry forward them rather than starting them from scratch.

Make sure you have fun

Well, this depends on org-to-org, so I would not consider it as a universal fact. I had fun in interacting with the weekly community meetings arranged in every Wednesday. Other developers were quite helpful and curious about the progress of my project, and I was really happy to share the progress of my work.

GSoC is surely an experience of a lifetime, and I would suggest everyone who is enthusiastic with Open-Source and want to develop industry graded software, then GSoC is the right place.

Ciaos Adios!

[Week 06] — First Evaluations and Completing the first half

2019-07-08T00:00:00+00:00

First Evaluations are Completed!

This blog post deals with the entry of tasks that I did for the 6th week for the project under Google Summer of Code 2019.

First Evaluations results are out

So the first evaluations results are out, and fortunately, I have passed the first evaluations. This was a mini-victory moment for me, and to top it up, my PR regarding the first evals was merged which was sweet for me!

I got a mail from Google, stating that I have passed my evaluations, and my mentor had given positive feedback. I was overjoyed and jumping out of happiness! I am not comfortable in sharing my mail here, but I am happy to state a few of the comments by my mentor.

My mentor commended the amount of hard work done and suggested me to improve my check-ins with the progress and keep pushing the code to GitHub so that how much progress I am making could be gauged.

This was imperative as it would help me in assessing my strengths and not over-working them, and work on my shortcomings as soon as possible. I had decided with my mentors that for the second part of the project, I would rather break my PRs into several small parts, each of them dealing with a small sub-task, that could be individually integrated back into NDCube.

Gearing up for the next sub-part

If any of my readers had been gauging my progress, here is a tab which contains most of the task that should be completed to check-off the task. I had covered most of the tasks of NDCubeBase. I was concerned with the working of axis_world_coords, which I had re-written earlier, and not sure about the working of it.

I decided to add it to my later tasks, as I started with planning for the next half of the project, the plotting. This required me to read through the docs for understanding the plotting. I had earlier worked with the plotting earlier, so I had been familiar with the code of plotting.

The trick was to break the codebase into small portions, as the plotting code was delegated into small methods which worked out the plotting of 1D, 2D and >2D NDCube objects. @DanRyanIrish had earlier advised me to break out the code into small parts, each of the refactoring dealing with different types of NDCube objects.

Tasks for the next week

The tasks for the next week remains a bit confusing. I plan to take on plotting, before trying out the changes that I made for the first part of the coding. My mentor @Cadair would be out on his vacations for around 2-3 weeks, so @DanRyanIrish would be expected to take in the charge. I don’t expect him to be available every now and then 😛, but I plan to make progress without pinging them every now and then.

Link to my previous post

[Week 05] — Testing out the codebase! — Link

[Week 05] — Testing out the codebase!

2019-07-08T00:00:00+00:00

Testing FTW!

This blog post deals with the entry of tasks that I did for the 5th week for the project under Google Summer of Code 2019.

First evaluations are nearing!

My task for this week was cut-out; complete the testing and pass my first evaluations. Well, it wasn’t as strict as it sounds, as my mentor has been quite supportive, and he was more than happy to pass me for the first evaluations for the amount of work that I had put. However, I personally felt that delivering complete content before the first evaluations were important, for it would unfair for anyone to pass me for the sake of hard work. Final results matter, so I was determined to complete off the tasks, before riding on to the next set of challenges.

Testing out the Slicing

So I started out with commenting out all tests, and un-commenting each of them one by one, and seeing if they are failing. Well, it was manual work, but I was more than happy to do, considering the mentally draining work that I did the week before.

Each test cases were written with a specific use case, and my code was performing well with each one. After completing the refactoring of the test-suite, I was mostly finished with them, with two of the tests failing. I was not sure what was happening, so I discussed my issue with @Cadair and @DanRyanIrish. They were quite happy with the progress, and I had a telecon with them, through which I explained how I rewrote the codebase and explained the assumptions that I took while writing them.

Code reviews are important!

Well before I had my telecon, I was assisted with my mentors for a code review, and boy it sounded quite intimidating. Imagine working out a workable solution, and then get suggested by the mentors, a much simpler and elegant solution. It was helpful and scary at the same time — Helpful in the sense that it changed my way of approaching a paradigm of coding, and scary because I was unsure if I met with the standards of coding.

Telecon with my mentors

After finishing up with the suggestions from my mentor, I discussed out the two failing test cases, which was bothering me for a long time. @DanRyanIrish was away for a long time, so he asked me for a telecon to get updated with what I have been up to this time. @Cadair also joined me, filling out on the holes that I made throughout the discussion, as he was quite active while I was writing and pushing my code.

During the telecon, after closely looking through the code, @Cadair suggested that the ordering of slicing for WCS object required input parameters in the cartesian format, opposite to what I had assumed in my code. This sounded really scary I had written my code with that assumption. This was really heartbreaking for me, as I didn’t expect such a conceptual error from my side. This meant that I hadn’t read the assumption well, and certainly threatened my progress.

Diving into the docs again

In order to fix this, I was determined to dive into the docs again, as I wasn’t sure how the stuff was working. I mostly considered the slicing of WCS as a black box, which was a big conceptual error from my part. I learned how not believe certain assumptions, and the code is written provides the concise proof of the assumptions taken — Nothing more, nothing less.

On further brainstorming, I found that the slicing used NumPy convention(opposite of cartesian convention), and that was the result why most of the tests were not breaking. This was a big green flag, but I was worried about those two failing test. On close inspection, I found that both of them used Cartesian ordering instead of NumPy ordering, which was why it was breaking. It was sloppy from my side, as dealing with a huge number of test-cases certainly invites a mistake or two.

I was able to get my PR merged, as Cadair was mostly impressed and convinced about the tests passing, and asked me to focus on the next part of the project which was plotting.

Content for the next week’s blog post

The next week comes after my first evaluations have been done, so I plan to document out my evals result and discuss my next target of the coding.

Link to my previous post

[Week 04] — Climbing the Everest — 02— Link

[Week 04] — Climbing the Everest — 02

2019-07-08T00:00:00+00:00

Sustaining the journey!

This blog post deals with the entry of tasks that I did for the 4th week for the project under Google Summer of Code 2019.

Using the Slicing API

The previous week, I had went through the docs, and played with some of the test cases of slicing. Now I was fairly ready to implement them in NDCube . I had long chats with my mentor, @Cadair who was always free to hear out my doubts, sometimes suggesting alternative ways to approach, filling me with hints and tips to approach the problem, rather than serving it out in a platter. This was really crucial and ensured that I enjoy the coding without hampering the learning part.

So I used the new slicing API, which was written by @Cadair and @astrofrog, and boy, it was a breeze in using it, as it required minimal code refactoring for performing slicing of wcs object. Since an NDCube object contains WCS, extra_coords and bunch of other helper methods, so the slicing of extra_coords was something, that wasn’t implemented earlier, and I had to do it from scratch. I had a talk with @Cadair, who warned me about thinking out the slicing of extra_coords in advance, and it turned out to be true, as it was another beast to be taken care of.

Rewriting the slicing API of extra_coords

So far, after implementing the slicing of WCS object, I was left with refactoring the code of slicing API(more of a redesign) of extra_coords and I was up to the task. After consulting numerous examples and test cases for the ideal working of sliced extra_coords, I went after writing up the slicing API. It was confusing, but at the same time, I had broken down the code rewriting into small subparts, and I finished off each of the small portions, as I consolidated my way towards completing my work.

Finishing up the refactoring

Well, after testing out numerous cases(well not exactly a lot of examples!), I finally pushed my changes to GitHub, and a PR was made for the changes that I made. The code was written, and I was mostly convinced about the behavior of the code, though the test suite was failing, and needed to be resurrected. This was ok, for me the most challenging part of the project was implemented, and considering the plan that I had earlier chalked out while rewriting the API, I was sure that it would work as intended.

Task for the next week

So, after rewriting and installing the new API for slicing, I was now left with modifying the slicing tests, partly because the type of object returned by APE14 (the API that I was implementing) was different from the earlier ones while having the same return values. So that was considered by me more of a manual work rather than requiring the brainstorming stuff. In a way, I was happy to work with the tests, for it was mentally frustrating to cover such an intense task in a week, and I wanted to cherish the way how the new API was working, and what a way to do that was the testing. So I am looking forward to it.

Link to my previous post

[Week 03] — Climbing the Everest — 01 —Link

[Week 03] — Climbing the Everest — 01

2019-06-19T00:00:00+00:00

Climbing the Everest — Starting the trek!

This blog post deals with the entry of tasks that I did for the 3rd week for the project under Google Summer of Code 2019.

Reading through the Docs

This week marks my initial stab toslicing of NDCube. The best place to start with the refactoring of any code-base, or any method, is reading through the docs, and figuring out how they work currently. Sometimes, figuring out how the present behavior is, and what parts are we looking to refactoring, can easily ease out the process, and help in breaking the refactoring to small parts.

I had a look into the astropy docs, and boy, they have documented each part of the logic, explaining the what and why of the code. Trust me for I have been contributing to open-source projects over for more than a year, and this sounds delight for any developer, for good docs removes the overhead of how the code works, but to focus on the high-level overview of what we want to achieve.

Playing with the slicing

Trying out any feature is more realistic than reading about them, and so I started with creating examples from previous tests of NDCube and how they fit into the scheme of things. Hands down to @Cadair and @astrofrog, for what a concise and behavior agnostic API they had made. This abstracted most part of slicing for WCS object, that NDCube uses underneath.

The real deal starts with refactoring the slicing of extra_coords. This now had to be done using APE14 methods, so I had to first try out a few examples of slicing extra_coords before refactoring it. Soon, after going into the rabbit hole, I realized, it would require refactoring of internal helper methods that the slicing of extra_coords uses. This sounded way too much work, but something that had to be done.

Rewriting the helper methods

The helper methods were based on a logic, which would not apply after we migrated to APE14. So certainly it required me to rewrite them. A common practice that I found, while refactoring, was to go top-down. A top-down approach would mean that you would refactor stuff which you want, to the methods that would get refactored for working correctly. This helped me in worrying about methods which would get affected, rather than worrying which method needs to be refactored.

I started refactoring the helper methods but got stuck at a fundamental point. But @Cadair came to rescue, and he suggested some attributes of WCS which would do my job. This was really crucial as getting stuck would have sucked out more time. This solved my problem, as I went out re-writing the helper methods, working to a behavior as I wanted.

Tasks for the next week

This week was really busy, as I spent time in reading docs and figuring out the most optimum plan to approach slicing. Till now it has gone fairly gone according to plan, though more tasks still await. I keep chugging along, trying to keep up with the required pace, as the phase containing the real challenge has arrived.

“I will come again & conquer you because as a mountain you can’t grow, but as a human, I can.” — Sir Edmund Hillary

Link to my previous post

[Week 02] — Solving Bugs! — Link

[Week 02] — Solving Bugs!

2019-06-19T00:00:00+00:00

Solving bugs for eternity!

To those who have been my blog, it would have been a bit surprising for them for getting this blog-post a bit late. This has been a result of hectic work schedule and a little bit of procastination :P

This blog-post sums up my work for the second week of Google Summer of Code 2019.

Telecon with my mentor

As I might have mentioned(or maybe not), but my other mentor, @DanRyanIrish, was away for a while now, and after discussing with him, we managed to set up a time-slot for a telecon, for getting him updated with my work.

The main points that we discussed were, getting this #PR176 merged. We also discussed, the progress of the main PR for the project, and how much did I make progress. I went through my PR, and discussed a few points about how I refactored the existing methods, and briefly explained my understanding. Code reviews are necessary, and after discussing with Dan we decided to change the logic of some part of the code.

As I had completed most of the tasks for this week, we agreed to start the closed PR. This PR helped in writing a FITS file from a NDCube object. I had started contributing to NDCube with this PR, most of the work had been completed. I had to rebase and write the tests and docs.

Completing the tasks

Throughout this week, I had another discussion with my mentor Dan, who helped me in understanding the code of plotting. The #PR176 was failing some tests, which were part of the plotting of >1D NDCube objects. I had earlier skimmed through the code of plotting but still found understanding the code of plotting quite complex.

Dan helped me in understanding the flow of code in plotting, and it helped me in fast-tracking my work with plotting. Refactoring the tests were much easier, though repetitive. Though the real happiness lies, when all the tests pass, and there is a green color message, signaling that all of your tests have passed.

Thoughts for the next week

With most of the tasks completed for refactoring NDCube with APE14 methods, it was now clear for me to take on the second stage of my project — Slicing of NDCube. Slicing by far was presumed by my mentor @Cadair as the most complex part of the project. I was apprised by him about how the slicing can take most of the time of the project, so I was rather aware of that. I am planning to start playing with the slicing, and how it used to work for NDCube earlier, and how the behavior changes with APE14 changes. This should take a fair amount of time, so I would hope that this gets completed within a reasonable amount of time.

Link to my previous post

[Week 01] — Getting Stuff Done! — Link

Until the next blog-post, ciao-adios!

[Week 01]— Getting Stuff Done!

2019-06-03T00:00:00+00:00

It’s time for Action ; Code-Sleep-Coffee Repeat!

This blog post marks my account for the first week of coding for GSoC’19. While it may not be as long as my previous posts, I would hope to make posts every week, so it would be as recent and relevant.

Making Progress for the Week

While I had already made progress with the tasks, now it was time to get the unmerged PRs merged. I started to refine my PRs, and after going through lot of iterations, I decided to drop this idea and do something else. A fresh mind would be more receptive to find bugs.

Frankly speaking, I did not make any progress, even though in my mind I thought I made 😛. I mostly had a lot of discussion with @Cadair about the issue of failing tests of NDCube, and I spent a lot of time understanding the plotting of NDCube. The plotting seems to be very complex, and it contained small portions of code which made no sense to me at all. All the time, I spent time understanding the code, but made no progress.

Sometimes debugging is helpful in understanding the flow of code!

I had been spending time in understanding, more than making real progress. This is wrong as writing some code always help in getting unstuck. A lot of times people suggest to understand the code before making changes, but if you spend a lot of time understanding the flow of code without any progress, it is better to crack open your favourite editor and start using breakpoint to identify the flow of code and make notes (yes notes!) of the changes unexpected.

Another thing I did is use test-cases to identify how the input was getting modified. Sometimes, an example is really helpful to map the abstraction of a method into something practical. I used the tests to inspect the portions of code which were creating nuisance, as I submitted another PR about fixing most the issues. There are few test cases which are failing, so it would take more time before this PR is merged.

Link to previous post

Contributing my way to SunPy1.0 — Link

GSoC 2019: Community Bonding Period — II

2019-05-26T00:00:00+00:00

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

Getting selected for Google Summer of Code-2019

2019-05-16T00:00:00+00:00

This short blogpost describes the journey of getting selected for Google Summer of Code, under SunPy organisation, for 2019.

What is Google Summer of Code?

According to the sources -

Google Summer of Code is a global program focused on introducing students to open source software development. Students work on a 3 month programming project with an open source organization during their break from university.

For undergraduates students like us, GSoC, serves as an exciting and eventful opportunity to write software, for real world organisations, which provides the participants to write and learn the different aspects of real world programming.

Events building up to GSoC’ 19

Roughly, I started to prepare my case for GSoC, by choosing organisations. The organisation list is generally out by February, but many organisations, who have taken part in GSoC earlier, take part the current year also. I started to prune down my choices, and based on my interest, I chose SunPy. Since I was really fascinated with Physics, and the astronomical side of SunPy, I was quite keen to contribute to SunPy.

Working through PRs and Issues

GSoC provides a really good platform to sharpen and develop skills for building Open Sourced software. While, the codebase for SunPy is present in GitHub, it was easy for me to understand and get through the process of solving issues/bugs and making a Pull Request.

I started to solve the issues and PRs for SunPy around from January, so this provided me ample time to go through the probable projects and the code base that I would work later on.

Reading codebase requires another skill, the ability to read through long scripts, understanding the flow of code and understanding the different witch-craft done in the codebase, and learning about them, which is what that makes up the important skill for making contributions.

Making Proposal

After working through the issues and bugs, I started looking through the project ideas listed, and based on my interest, I chose NDCube. I started working on some issues of NDCube, after going through the project ideas, I chose Supporting APE14 for NDCube. This was quite fascinating, as it used N Dimensional cubical data structure for storing and manipulating astronomical data.

Getting selected for GSoC’ 19

Even though I had a very good conversation with my mentor and the SunPy project leads, I was still quite nervous during the result day. I was watching some movies to tone out my anxiety. The moment I got my result, I was really happy, and was quite relieved.

Now the upcoming months is some thing, which I look forward to, as it remains one of my challenging months for Summers.

I have written a blogpost of my first video-chat with my mentor, so stay tuned for another blogpost of my conversation.

BTW, my mentors for the project are Stuart Mumford and Daniel Ryan.

GSoC 2019: Community Bonding Period - I

2019-05-16T00:00:00+00:00

This post encapsulates my proceedings with the GSoC project that I have been working on, and a short log on the meeting that I had with my mentors.

Community Bonding Period: Getting acquainted with the environment

So first things first, after getting selected for GSoC’ 2019, all of the people of participants who got through the proposal selection, got a wave of congratulations from the SunPy developers, who are quite friendly.

Soon, I got my first mail from Open Astronomy, the organization which is responsible for conducting the event smoothly. We were asked to submit a PR without RSS feed credentials for easy access to the blog posts that we are to make every week (or two).

I never had the first-hand experience with RSS feeds, so I got a bit anxious about making one. But soon, the mentors had agreed on making an account on medium, and since medium has an RSS feed https://medium.com/feed/@yashrsharma44 it was almost taken care of. So all in all, it helped in fast-tracking the process and getting started with the blog-posts.

Gearing up for the work: Reading the codebase

Well for starters, I had been reading through the codebase of ``NDCube`` for a long period of time, right from my contribution period, so I had mostly assumed that it would be a cake walk. But boy, was I so wrong, as while going through my proposal, I had tried to make a prototype, but it was language agnostic. So all in all, what I realized that solving an issue is quite different from making a feature.

Overall, my condition wasn’t so bad, if not good, as I still had gone through the codebase and made some notes, so that was a cookie point for myself. There were some areas (which I realized during my meeting with mentors) which was not conceptually clear, though I was able to figure out the logic of the code.

Meeting with the mentors: An exciting moment

Meeting with the mentors was the first thing that I was looking forward to, as I had interacted with them earlier, and they were quite pragmatic in dealing with queries, often responding as fast as possible, with some hint of chirpy comments from Cadair, who made the moment light.

On the day of the phone-screen meeting, as they say, it was scheduled on a Friday, in the evening. I had been to the meetings once, so I knew how each of them looked like . We started with me explaining to them what was the purpose of ``NDCube`` according to me: I tried to give my point of view, about how ``NDCube`` is a utility package from a contributor’s point of view, and how I had felt about the impact of the software.

We then had a talk, in which both the mentors mostly discussed with themselves, discussing the scope of the project and how do we need to proceed. The meeting mostly proceeded with me listening to there views, as it was imperative to absorb their approach and how they thought about the working of the different parts of ``NDCube``.

Soon, I got to realize about the different contextual meaning of each of the parts of ``NDCube`` as it was quite intuitive with the way, the mentors, particularly Dan Ryan, explained. The meeting was quite long, which meant that I was starting to lose out on the objectives and pointers of the meeting. Cadair started to document down all the requirements of the project, which made it quite simple to understand it. Of course, the low-level idea about the goals required me to discuss with them as required, but the overall high-level idea helped me breaking down the projects into small doable parts, and hopefully, help me in deciding the pace of my coding.

My takeaways

The meeting in general, helped me in propelling my understanding of the project, particularly the intuition of ``NDCube``(thanks to Dan Ryan) and how it functions, so I am much better equipped to take on the further challenges of the project.

Getting selected for GSoC’ 2019

Blog - Posts by Yash Sharma

Google Summer of Code 2019 | Final Report | OpenAstronomy | NDCube

Google Summer of Code 2019 | Final Report | OpenAstronomy | NDCube

For those who are geeky and want to see the PRs submitted…

Details of my Organisation and Project

Blogging and details of my work

Breakdown of my project

Some Visuals associated with my project

My Experience with working with NDCube/SunPy

My Experience with Google Summer of Code

[Week 06] — First Evaluations and Completing the first half

First Evaluations results are out

Gearing up for the next sub-part

Tasks for the next week

Link to my previous post

[Week 05] — Testing out the codebase!

First evaluations are nearing!

Testing out the Slicing

Code reviews are important!

Telecon with my mentors

Diving into the docs again

Content for the next week’s blog post

Link to my previous post

[Week 04] — Climbing the Everest — 02

Using the Slicing API

Rewriting the slicing API of extra_coords

Finishing up the refactoring

Task for the next week

Link to my previous post

[Week 03] — Climbing the Everest — 01

Reading through the Docs

Playing with the slicing

Rewriting the helper methods

Tasks for the next week

Link to my previous post

[Week 02] — Solving Bugs!

Telecon with my mentor

Completing the tasks

Thoughts for the next week

Link to my previous post

[Week 01]— Getting Stuff Done!

Making Progress for the Week

Link to previous post

GSoC 2019: Community Bonding Period — II

Making progress with the tasks : Coding 101

Contributing to SunPy1.0

Links to previous post

Getting selected for Google Summer of Code-2019

What is Google Summer of Code?

Events building up to GSoC’ 19

Working through PRs and Issues

Making Proposal

Getting selected for GSoC’ 19

GSoC 2019: Community Bonding Period - I

Community Bonding Period: Getting acquainted with the environment

Gearing up for the work: Reading the codebase

Meeting with the mentors: An exciting moment

My takeaways

Previous Post