GSoC 2018: Changing Stuff and Seeing What Happens
Know all the things!
The large and unfamiliar codebase is still (at) large. But it’s a little less unfamiliar now. Most of it is thoroughly documented, which certainly helps. Plus, my mentors put in a lot of thought into constructing my tasks so as to allow my acquaintance with the codebase to be gradual. I’ve experimented with quite a few parts of the it by now, and I’ve gained a better overstanding of the way it works. Oh, and I’ve also helped to improve Moriel’s tutorial for the UI library by fixing some typos and small errors.
Not gonna lie. Things that seemed unclear at first glance do not become second nature overnight. They do, however, get more and more readable. When I find that I get stuck too frequently, I go back to the tutorials and docs, or review some of the more advanced JS concepts that I’m less experienced or less familiar with.
When I run into a function I don’t understand, I try to write it by myself in Neanderthal.js™, a wonderful framework I just made up and would definitely build some day. But not really. The idea is to write a simplified version of the function you want to understand, assuming you know WHAT it’s doing but you’re not sure HOW. As you refine your own version, you might find that you are getting closer and closer to the implementation of the original function. Personally, I find this very effective.
And when you think about it, it’s kind of like when you’re asked to put something “in your own words” (we’d get these assignments in elementary school). So… your own Neanderthal words, I guess.
Just so you know, according to Wikipedia,
“It is not known whether Neanderthals were anatomically capable of speech, and whether they actually spoke.”
Blame it on my TDD
I think the most exciting part for me over the past couple of weeks, was learning and practicing Test Driven Development for the first time. I’ve heard of TDD before, but never had a chance to take part in a project that follows this practice. I noticed how weirdly excited and pleased I sound when I tell people about it: “First you write the tests, then you run them and they fail, and then you write the actual logic, run them again, and then they pass!”
Time for another quote from Wikipedia:
“To write a test, the developer must clearly understand the feature’s specification and requirements.”
Well, sometimes we do, but not always. And that’s what I’d like to talk about next.
Ch-ch-ch-ch-challenges
The mockups for the new design are not all finished, and that is because the desired functionality is not entirely defined yet. The project still undergoes refinements and modifications, as complex architecture questions arise. For instance, the UI functionality might get highly complicated. For another instance, the categories have sub-categories, and those have sub-categories of their own, and so on. It probably wouldn’t be possible to handle every sub-sub-sub-sub-level, due to what has recently been referred to as “technical insanities” (that’s the professional term , I believe).
Now, while current Recent Changes search filters are hardcoded, the Category filters are not predefined, and therefore must change based on whatever categories are available at Wikipedia at the time of the search. So I’m checking to see whether the current filter system is flexible enough to allow the reuse of existing classes to implement this filter or not. I’m also learning how to add a new component that can filter by a dynamic set of options.
All this must connect to Wikipedia’s API. None of the currently existing filter have this functionality. We’re still not sure how generalized and reusable this filter, or in fact filter group, should be. I started implementing a limited version of it. The final design might turn out to be different, but I’m learning how the system is built and how to change stuff, and see what happens.
