Here we go, after a week from this post, I got a nice report to give.
After wrapping up with the dependency-discovery service, I started to work on the follow up issues for it. One of them was related to creating a Dockerfile so that it can spawn a container from it and put it live. The precursor to this was rewriting the script that generated the list of dependencies that the service would read. This script would update the dependency list every version bump so it would never go stale. The PR that addresses this is #2838.
Another issue I worked on was related to a CSP violation on the status dashboard. There were actually two CSP problems that were separate from each other. Figuring this out was somewhat challenging, as I did not know about CSP before.
Finally, another status-related issue was the terminal that showed the build log was not resizing to cover the whole vertical space available. While I solved in a more JS-centric approach, @dukemanh guided me on a more CSS declarative approach throughout the review.
The Birth of the dependency-discovery service
Right after the release of Telescope 2.6, I was somewhat frustrated with my progress. I managed to finish the starting point of the dependency-discovery, although it did not offer much. Some issues were created as a follow-up.
One of these logical steps was dockerizing the service. A couple of points were brought out, and a conclusion was made: we would need to rewrite the script that generates the dependency list into a more portable version. This meant rewriting the bash script into JavaScript.
It was not difficult, although it was longer due to the lack of tools like sed, sort, and other Unix tools. Either way, the script had the same performance as the bash script, so we did not lose that much and gained portability.
The next step, which I am going to work either on Sunday or Monday, is the Dockerfile for this service. It shouldn't be hard, as I had used docker before, but I have not written a Dockerfile on my own before.
Content Security Policy is a pain and a blessing
For #2605 and #2511, I thought that these issues were related, but when I started to understand the nuances behind the issues, I realized they were two separate issues that were thematically related (CSP related).
Most of my explanation is found in the issues, so I wouldn't want to repeat myself, but I would like to say that CSP is both a pain and a blessing. The concept itself is very simple to understand, but some of the error messages don't provide a lot of context, so I had to put a hypothesis and prove that it was the case. I ended up being right, thankfully. This way of debugging really reminds of programming in C (when there is a segmentation fault...)
Terminal Resizing: Two Approaches
For the last issue, I would like to emphasize two approaches to a problem.
Imagine you have a special UI element that is not resized by normal means. That is, the UI element cannot be resized by a simple CSS statement. How would you approach about this?
For a more concrete example, this special UI element is a terminal-like canvas, that shows text with a monospaced font.
When I faced this problem I started to research whether the terminal offered an API for something like this. Indeed, since the element was from the xterm.js library, it did offer something for my use case. Now that I knew that it existed, I decided to think of a way I would approach it, which I elaborated further in the thread of the issue.
However, another approach surfaced when review of the PR was being carried out. @dukemanh mentioned that if we could resize the container of the terminal with CSS, then the terminal-fit-addon would figure out the size of the terminal.
He was right, and I agreed on it. The only problem is that I do not enjoy CSS that I am not familiar with, which is mostly all the time! Either way, I decided to embark on this, mostly with the help of Duc. At the end, I was surprised that Duc could solve the issue, to the point that I asked how he thought of the solution. His response was "I didn't, I learned a lot of CSS while struggling to work on the Telescope frontend and building the layout of one of my projects." This left me thinking about the two approaches shown.
The two approaches show two ways of programming that some people might prefer over the other: an imperative solution and a declarative solution. The reason I went with the imperative solution was because it was easier for me to not only figure out, but also write the solution for it. However, the declarative solution is more natural for a person not familiar with the code to actually read and understand. Because of the inherent open-source objective of Telescope, the declarative approach was given a preference, and I am glad that it was.
Top comments (0)