Forem: Rudy Chung

Release 0.4 Final

Rudy Chung — Sun, 11 Dec 2022 22:37:12 +0000

What I did

After creating the project creation UI, I used my experience in contributing to the UI to improve the contributing document. I updated any references to tools such as Node.js and Jest with links to the webpages for these tools.

Goals

I think I mostly achieved my goals. The form has its data fields updated as they change. Although this data is not sent anywhere currently, with the way it is set up it should not take too much more effort for the form UI that I have created to perform its function. I would have liked to have aimed higher, but with the project still in a preliminary phase it is difficult to integrate the difference components together without them all being present.

How I did it

It was difficult to get the UI to look close to what I wanted, since I had to integrate what already exists and its CSS styling with my own additions. However, I managed to get it done by using the existing CSS stylesheet with my own component.

Since I had free rein over what I could use, within the limits of what already existed for the project (using React), I decided to use Material UI components to create the UI.

For the text input fields I used the TextField components, which was fairly straightforward. For the date field, I used MUI X DatePicker component. Validating dates manually is difficult to do, so the DatePicker component was perfect for this use. It also allowed for a more intuitive way to select a date than a simple text input. All of this was contained within Items in a a vertical Stack component container in order to arrange the inputs. In the App level, I placed the existing upload interface as well as my project creation form UI within a reverse horizontal Stack component.

What did I learn

I learned that open-source project creation can be an slow process. Waiting for code reviews and approval for changes can take a long time. With larger communities for a project, it would probably be a faster process since the community would be more organized, with more contributors to conduct code reviews.

I also learned a bit more about the Material UI library. I had previously learned about the library through previous projects but have never created a UI of my own using it. I had to chance to build my own UI from scratch using the library and found it very simple to use and find documentation for.

How did I leverage the community?

After I created the project creation UI, I asked in the community Slack channel if there were any further issues I could work on to add to my contributions. One contributor filed a few issues which I could work on. This is how I managed to start working on the issue to update the contribution document.

Release 0.4 Progress

Rudy Chung — Tue, 06 Dec 2022 19:35:52 +0000

What I have done so far

I have had my pull request merged for creating the UI for creating a new project. What I have created is purely visual and has little functionality. With my contribution, I have integrated my UI with what already exists.

Obstacles

In addition to the work I have for other courses, the open-source contribution process has been much slower than I expected. I am currently trying to get a better understanding of how the project is meant to work and how each contributor's work moves toward it. With a project which has not yet completed its basic functionality, it is hard to understand what can be done to further it along the development process.

What I will do next

I will ask the project's contributors what can be done to move the project forward, and try to have that done before the deadline. To accomplish this, I will create a new issue and a pull request after discussing with the other contributors.

Release 0.4 Planning

Rudy Chung — Tue, 06 Dec 2022 18:33:27 +0000

The Project I chose

For 0.4, I plan to create the UI for my-photohub. I am choosing this project because I thought the concept of it was interesting. Also, I wanted to work on a React project, I had previously worked on a personal project using React and wanted to put that practice to use on a real project. Another reason I chose this project was because did not want to spend too much time looking for an external project to work on that was viable.

My Plan

I first looked at the UI at already existed for the project. Then, I created a mock-up for the changes that I was proposing.

First I will create a UI allowing for submission of project details. There is already an existing issue for this. Then, I will add the functionality for the form. Currently, it is being contributed to by others who are adding the different components for the project. Hopefully, the project will be closer to being function through my contributions.

Goals

I plan to create the basic UI for the project, and have the form perform its functionality. I do not want to aim so high that I will not be able to achieve my goal by its deadline, but I also want to contribute something substantial to the project. Hence, I will aim to contribute as much to the project regarding the UI as possible.

OSD600 Lab 10

Rudy Chung — Sat, 26 Nov 2022 05:50:19 +0000

The first try

I originally planned to use build2, but I found it to be much more complex than I expected. There was plenty of documentation to read for build2. The main documentation was all about the setup process, but there were also documentation pages for building, testing, and package management.

The second try

As a result, I decided to use Conan instead. I installed Conan through pip, which requires Python. After installing Python, I ran

pip install conan

This installed Conan for use in the command-line terminal. After installing Conan, I had to add a conanfile.py file.

conan new SauSaGe/1.0.0

The file has a bunch of fields with dummy info that need to be filled in. The next step requires a CMakeLists.txt file as well as CMake, of which how to create is a process of its own.

The next step is building the package.

conan create . SauSaGe/beta

This will build the package in ~/.conan/data directory, which will contain the source code as well as the executable file.

Releasing

I used GitLab for this step, which requires a GitLab account. I set up an account and created a project. After that, go to the project's page to obtain the project id. Now you can add your remote to your list of remotes in Conan run

conan remote add <remote-name> https://gitlab.com/api/v4/projects/<project-id>/packages/conan

You also need to log in to to upload your package, this requires an access token, which can be found on GitLab in Edit Profile -> Access Tokens. After you create your access token, you can run this

conan user <gitlab-user> -r gitlab -p <access-token>

With the remote in your list, and your GitLab account logged into, you can finally upload your package.

conan upload SauSaGe/1.0.0@SauSaGe/beta --all

Released

My package is here, after a few hours of research.
To install using this package registry, create a SauSaGe directory containing a conanfile.txt file, the contents of which are

[requires]
SauSaGe/1.0.0@SauSaGe/beta

[generators]
make

Then, install the package

 conan install SauSaGe --remote=<remote-name>

I did not have to change much about my code to set it up for the package registry. Although I did need to install a variety of tools to go through the process. The whole process only added 2 files to my project.

Testing

I had a classmate test test the code through the package registry. There were some struggles due to having to install Python, Conan and CMake. There were also some issues with adding the applications to PATH environment variable in order to run all these tools through the command-line terminal. But overall, it went smoothly.

Release 0.3 External Pull Request

Rudy Chung — Wed, 23 Nov 2022 03:52:42 +0000

For my release 0.3 for OSD600, I have to create a pull request for an external repo. The repo I contributed to was cve-bin-tool. This post was late because I had was busy with other commitments and projects compounded with problems finding workable issues. In the future, I would definitely follow my own advice and search for issues early and often. I didn't follow this advice and found myself in this position.

My pull request

My pull request involved updating syntax for some files in order to modernize the code in the project. I've had minimal exposure to Python, only having worked on another student's SSG made in Python, so it was somewhat of a shift to understand the basics of Python syntax. There isn't much more to say at the moment, but I will update this post as I receive feedback from the maintainers and hopefully have my pull request merged.

What I learned

Definitely look for issues that are "good enough", and as stated earlier to look for issues early and often. I took the last few days just too search for issues only to come up with nothing. There definitely are much less viable issues now that Hacktoberfest is over, which though I expected but didn't didn't anticipate a drought to this degree. For release 0.4, I will keep these things in mind and try my best to set myself up for success.

Release 0.3 Internal Pull Request

Rudy Chung — Mon, 21 Nov 2022 05:47:47 +0000

For my release 0.3 for OSD600, I have to create a pull request for an internal Seneca College open-source project. The repo I contributed to was my-photohub.

My pull request

My pull request involved moving some auto-generated documentation from the top of a file into the contributing document. After submitting my pull request, I was asked to make some changes by a contributor. This involved making some script arguments more generic. After this, more contributors reviewed my pull request before it was merged into the project.

What I learned

From this pull request, along with actually making code reviews, I learned more about how the code review process worked. Previously, I had only worked on repos that were managed by a single author. However, this is the first time I have created a pull request reviewed by multiple people. This is also the first time I had changes requested for my pull request. I feel like integrating requested changes was quite simple as those who are requesting changes will often provide good guidance on how to make those changes.

Release 0.3 Code Reviews

Rudy Chung — Mon, 21 Nov 2022 05:19:03 +0000

As a part of my release 0.3 for OSD600, I had to create 2 code reviews for internal Seneca College open-source projects. Both of my code reviews were for vscode-seneca-college.

My Reviews

The first review I made was for a pull request for creating a readme and contributing documents. My review comments were concerned mostly more on grammar and formatting. With documentation, some things may be unclear especially instructions for setup. This can cause a lot of confusion, especially when many people will be reading that documentation. That's why it's very important for documentation not only to be accurate but clear to the reader as well as to avoid confusion.

The second review I did was for a pull request adding a snippet for a Visual Studio Code extension. I was not really familiar with how snippets worked initially, so I had to do some reading on them before doing this review. The code in the pull request looked similar to the documentation example, and testing it seemed to function properly. My issue with the the pull request was with the terminology used in it. The term "course" seemed more appropriate to me than "Class" in that context, and the change I suggested was made.

What I learned

I learned what is possible for code reviews, they are not always purely technical or even coding related. I can help by proofreading and improving the readability of not just code contributions but documentation contributions as well. I can learn from code reviews as well. By testing code contributions and reading their related documentation, I can learn things I didn't know before. I learned what it is like on the other side of a pull request as well. Having to read other's code and provide suggestions if necessary was a much different experience than actually contributing to another's code.

OSD600 Lab 9

Rudy Chung — Fri, 18 Nov 2022 17:23:10 +0000

Setting up CI using GitHub Actions

This week, I set up CI for my SSG project. This involves creating a GitHub workflow for GitHub Actions to use. I started with one of the starter workflows. Specifically I used the msbuild one. To give a brief explanation of what adding this file will do, upon pushing changes or, a pull request it will create an environment that can be used to run my program. This is helpful if any tests, or other checks need to be made to verify that everything is in working order after changes to the project have been made.

My YAML file

My YAML file built the project on Windows and used my .sln file to build the project. Then, it ran the tests for my project using the built executable file. Other tasks such as using a linter to check the source code could also be performed at this point in order to validate it further.

Testing another project

How did your partner's repo and testing setup differ from yours?
I worked with sfrunza13 once again on his SSG. Even though he used Python and I used C++ for our projects, the tests were similar since they both accomplish the same task. With the understanding of the task being performed, the difference between languages did not matter significantly. Both the projects and tests were very similar. Although one significant difference was that my repo outsourced the Markdown parsing to a external module.

It was very simple to create new tests when using the existing tests as an example. Since I am still not 100% familiar with Python, it took me a little getting used to before writing my tests. However, I had worked with a previous iteration of the project before, so I did have prior understanding of how it functioned. But, there were some changes made to it in the time between the last time I worked on it and now that I had to re-read and understand the changes made to the project.

My opinion on CI

It's a very convenient way of handling contributions to my project. I can see it being very helpful in larger projects, which may get hundreds of pull requests. They would help greatly in ensuring that changes being merged do not break the project. The powerful thing about CI is that all these checks are done automatically, which greatly eases the burden of the authors and contributors of the project in terms of checking incoming changes.

OSD600 Lab 8

Rudy Chung — Fri, 11 Nov 2022 16:32:20 +0000

What I did this week

This week, I added a testing module to my SSG. Since my SSG was created using C++, I used Catch2 as my testing framework. I chose Catch2 as my testing framework since it seemed to be the most popular among C++ developers, and it was all contained within a single header file.

Setting up Catch2

The setup for Catch2 was very simple. I had to include the header to run testing, and using my own command-line argument parsing, I ran the tests from the main function. Then, by calling Catch::Session().run() in the main function, it executed my tests, which I created in a testing file that contained all my test cases. This testing file also included the Catch2 header as well.
Using the macros defined by Catch2 (TEST_CASE, SECTION, and REQUIRE), I was able to specify names for test cases and their sections and define what was expected from each test. Overall, it functioned like Jest, and I'm assuming most other testing frameworks for other languages.

Testing my patience

Since I offloaded my markdown parsing to maddy, I did not test for it because it was not my own code. As a result, it was difficult to find parts that I could test. I mostly created my test cases for end to end testing. Since the number of things to test for is always numerous, I ended up finding a few things I could test for. But, I definitely am not satisfied with the number of tests I currently have and will be adding more in the future.

Caught in the bug net

In one of my tests, I parsed both a .md and .txt file into an .html file and compared them to what I expected the parsed .html to look like. While parsing my .md file, I noticed that it did not product the same .html file as the one produced by parsing the .txt file even though both files' contents were identical. This uncovered something about maddy that I was not aware was happening. It would append a space to each paragraph before the paragraph closing tag. I made a small change to one of maddy's headers that seemed to fix the issue.

What I learned

I learned how testing can be done in C++. Using Catch2, it was very simple to create and run tests. Previously I had only done testing in JavaScript using Jest. In future projects, I will be sure to add testing as it is a good way to maintain all the required functionality and ensure it all functions as intended.

OSD600 Lab 7

Rudy Chung — Fri, 04 Nov 2022 00:05:53 +0000

What I did this week

This week, I added static analysis tools to my SSG project. The tools I added were the C++ code formatter clang-format and C++ code linter clang-tidy. Both of them can be integrated into Visual Studio 2022 using the Clang Power Tools extension, which made it handy to configure and use.

Clang Power Tools

In regards to the Clang Power Tools extension, it's usage is rather simple. After installing the extension, right-clicking the toolbar should show all available toolbar extensions.

The Clang Power Tools toolbar extension appears as so:

Clang Power Tools also contains extensive configuration options. I played around with them until I got the code formatting I desired and saved those configurations into a .clang-format file to be used in the command-line. I did the same with clang-tidy, saving them into a .clang-tidy file.

clang-formatting and clang-tidying my code

Using clang-format, I didn't find many problems with my code, since I used the built-in code formatter in VS2022 often. However, I did find that there were some formatting standards that I preferred, so I set clang-format to adjust my code to meet those standards.

With clang-tidy, there were a few issues that I had not spotted. These were mostly related to performance with arguments that were received as copies rather than references. I made those changes accordingly. There were also some minor conventions that I had neglected to follow, so I had clang-tidy adjust those as well.

Problems

I struggled a lot in setting up the clang tools in my project. Although the Clang Power Tools extension was quite easy to set up, the command-line versions of them was a different story. At first I downloaded the LLVM installer from here. But, I realized that these tools were accessible via modifying the Visual Studio 2022 installation using the Visual Studio Installer. I decided to do the latter, since my project did not require all of the LLVM tools, though I did provide a link to it in my contributing document for those who do not use VS2022.

By adding the components using the Visual Studio Installer, the clang tools are accessible through the terminal in VS2022. They can be executed using their commands as though installed through LLVM.

What I learned

In this lab, I learned about static analysis tools in C++. I had not previously used them, instead sticking to the standards set by my professors and using the built-in code formatter in Visual Studio. Although I do have some experience with static analysis tools in Javascript/Typescript, I did not know of any such tools for C++. They are quite a bit more finicky in C++ (at least in my experience) however they are just as useful.

My Hacktoberfest Recap

Rudy Chung — Mon, 31 Oct 2022 16:47:54 +0000

My Experience

My first Hacktoberfest has been a long one, spanning all of October. I saw other students had gotten all their PRs merged a week early, so I knew I had to hurry and finish mine as well. I just barely managed to get all 4 of my PRs approved within October, which was a stressful experience. But, overall I feel like I learned a lot about open-source, GitHub and Git.

I found the most difficult part to be actually finding viable issues. Issues often tended to be taken very quickly, or were too complex and required development experience with the project. I spent each day looking at new issues that matched my search criteria and I found brief moments of success between long droughts of good issues.

My PRs

My first PR was on golly-bot a discord bot. My PR added the feature of sending a goodbye message tagging the leaving user.
My second PR was on reddit-image-viewer, which allows users to purely view visual media on reddit. My PR changed the default video player to use Hls.js. This way, videos could be played with sound.
My third PR was once again on reddit-image-viewer. My PR added the title of the post which linked to the original post under each image/video. This was in response to clicking images linking to the original post, while videos being clicked played the video. Thus, there was a need to place the title to link to the post.
My fourth PR was on word-cloud-generator, which allows users to generate word clouds using various settings. My PR added capitalisation settings to the settings panel, allowing for users to specify the capitalisation of the words in the word cloud.

Tips

Get searching early, and often

In my first week and third week I had little success in finding a good issue to work on. However, I found sporadic success in the second and last weeks. There may be some dry weeks where it is difficult to find something good to work on. However, you should try to set yourself up for success and be persistent in your search for issues that you can work on. Keep searching for issues and eventually good ones will come your way.

Cast a wide net

Try to look for as many different issues as possible. Search for any projects that use the languages you know. Search for any projects that use languages you would like to know. Search for issues that under different tags. Try to cast as wide a net as possible. That way you can broaden your horizons and see as many candidate issues as possible, even if many of them may not be viable for you.

My Fourth Hacktoberfest PR

Rudy Chung — Mon, 31 Oct 2022 14:23:31 +0000

What Did I Work on?

This week, I worked on a new repo word-cloud-generator. This project allows the user to generate a word cloud based on a body of text provided to it. This word cloud can be generated using different methods and with different stylings and can be saved as a .png file.

The issue I worked on was adding a feature that allowed for selecting the capitalisation of the words in the generated word cloud. This allowed for all words in the word cloud to be all lower-case, all upper-case, or have only the first letter capitalised.

What Changes did I make?

My pull request involved making changes to both the front-end and back-end. The front-end changes I made were relatively simple, just placing radio buttons and labels on the settings panel of the page.

On the back-end, the default capitalisation was all lower-case, which was where I started. I had to first check the radio button that was checked, then modify the words received in the corresponding way.

There was not a built-in method to capitalize the first letter in every word, so I had to find my own solution. This involved iterating through every word, and modifying them to a value built from appending the capitalised first letter to the remainder of the word.

Difficulties

This project used webpack, which caches the page. This also made it so that my changes were not being made when I reloaded the page. It took me a few hours to figure out, but once I found a workaround the process of finding the solution to the issue was only a matter of time.