... | ... | @@ -4,6 +4,27 @@ _Following blog posts are mirrored from [DIAL's blog](https://hub.osc.dial.commu |
|
|
|
|
|
[[_TOC_]]
|
|
|
|
|
|
# August 2020
|
|
|
## August 21
|
|
|
Here we are, the final coding week! I started this week by refactoring the backend code that produces the data for feeding the graphs. I also worked on writing the docstrings for the other undocumented parts of the codebase. Later, I got hospitalized on Tuesday and had a surgery :worried: This surgery was totally unplanned and unfortunately delayed my plans for this week. After the surgery, I was still in pain and decided to do work that required less brainpower to complete while I try to recover. So, I worked revising the frontend layout I planned to implement.
|
|
|
|
|
|
I'm feeling better now, and I will try to catch up during the weekend. I am planning to keep working on my project after GSoC anyway, and this week's delay shouldn't be a problem.
|
|
|
|
|
|
Stay safe people!
|
|
|
|
|
|
|
|
|
## August 14
|
|
|
I started this week by experimenting with [D3.js](https://d3js.org/) to replace [Chart.js](https://www.chartjs.org/) library. I use Chart.js to generate the graphs on the dashboard, but for some reason, the graphs it produced were looking very blurry on the Tor Browser, disturbing me a lot. Thus, I was looking for a way to replace it with D3.js, another library for drawing graphs. D3.js is actually intended for drawing SVG objects driven by data, and some people use it for drawing SVG graphs. D3.js gives a lot of freedom to the user, but this freedom comes with a cost: the user needs to code every detail related to a graph. Whereas Chart.js is designed only for creating graphs, and users only need to feed the data, and it just works. That said, I was really unhappy with the blurry look on Tor Browser and tried using D3.js to draw the graphs. It was a horrible experience because I needed to spend time coding the functions for actually creating the graph itself, and all my attempts looked pretty bad. I couldn't manage to align the elements of the graph properly. I have mild OCD, and that unorganized look drove me crazy. So, I abandoned the idea of using D3.js and tried fixing the blur issue instead. It turns out; the blurring issue was very trivial to fix. I learned that Chart.js uses computer pixel density information to scale what it is drawing. As expected, the Tor Browser doesn't leak this information to the JS libraries, and Chart.js was assuming the pixel density of my screen wrong (I use a retina screen, where four physical pixels form one virtual pixel). I fixed this issue by simply overriding the default value with a higher value and voilà!
|
|
|
|
|
|
Later, I finished working on the dashboard design document itself and coded the functions I described in the design document. I created a parser for the Tor consensus documents. The class I created uses the parsed consensus information to calculate exit weights of each exit relay and calculates a weighted CAPTCHA rate by using the exit weight information. Now, I have the backend for generating the data for the graphs. The next step is generating the graphs themselves using Chart.js and the data generated by the backend. I plan to finish that part of the project next week and conclude the GSoC period. That said, I will keep working on the project and further improve it.
|
|
|
|
|
|
|
|
|
## August 7
|
|
|
This week I started with working on the [dashboard design document](https://gitlab.torproject.org/woswos/CAPTCHA-Monitor/-/wikis/Dashboard-Graphs). I expected to quickly finish working on it, but it turned out to be a more complex task than I imagined. I wrote a very basic draft and asked for getting feedback from people on the IRC chat. Dennis Jackson was particularly very helpful with his feedback. He suggested me to consider the exit probabilities while calculating the CAPTCHA rates. This was a critical suggestion because larger exit relays with larger exit probabilities have a greater effect on the network. So, we care about the larger exit relays more than smaller ones. That said, I didn't know how the exit probabilities were calculated, and I needed to read the dir-spec document and lots of source code to figure out how to do it. My lack of knowledge about the very inner technical details of the Tor was another issue. I needed to ask a lot of questions on IRC, and thanks to everyone who replied to my questions, I managed to understand these details and finish working on the [dashboard design document](https://gitlab.torproject.org/woswos/CAPTCHA-Monitor/-/wikis/Dashboard-Graphs). I still keep getting feedback on the content of the document, and I will probably be working on it next week to incorporate the feedback I receive.
|
|
|
|
|
|
Meanwhile, I did work on refactoring the dashboard code and encountered the [Tor Styleguide](https://styleguide.torproject.org/) for building Tor themed websites. I also worked on importing this style guide code into my code and make the dashboard compliant with the style guide.
|
|
|
|
|
|
|
|
|
# July 2020
|
|
|
## July 31
|
|
|
This week I released CAPTCHA Monitor v0.2.0, and it mostly contains changes from last week. I wrote the changelog and made changes to the README file. This release contains major changes (like the migration to PostgreSQL) that the installation steps needed to be updated.
|
... | ... | @@ -17,7 +38,6 @@ I also worked on migrating the user in the Dockerfile to a non-root user and dec |
|
|
Finally, I completed my second GSoC evaluation and finalized the second coding stage. My experience has been amazing so far, and I'm on track with coding. The dashboard and visualizations turned out to be more problematic than I expected, but I will overcome it with the help of the design document that I'm working on.
|
|
|
|
|
|
|
|
|
# July 2020
|
|
|
## July 24
|
|
|
Until this point, the "API" was a small part in the dashboard code, and it wasn't a real API. This week I spent time on creating a fully-fledged and properly documented API, which is located at [api.captcha.wtf](https://api.captcha.wtf/)
|
|
|
|
... | ... | |