DEV Community: Roman Rezinkin

DPS909 - Release 0.4 Week 3 - Final Update

Roman Rezinkin — Sun, 12 Dec 2021 02:34:01 +0000

Introduction

Well, as we approach the end of the semester, here I am with my final blog post. For this week, I focused on finishing my Release 0.4. As my previous blog posted mentioned that for week 3, I would continue my work on Issue-605. Since my first part of release 0.4 was working on introducing a Legend into the same repository (on top of reformatting and fixing a lot of the page that the legend lived in), I picked up issue-605. There were a few enhancements that were in need of changes, which included removing a footer bar which lives right below the email subscription input fields. The second issue was regarding the color of the subscribe button in the hover stage.
Image for reference:
Footer Issue
Hover Color Issue

Fixing the Footer

The footer was a rather simple fix, although it took me quite a bit of digging to discover where it lived within the repository.
After using the Chrome Inspect Tools, I was able to identify where the footer CSS location was, and made my fix:

That was rather simple, but I think the final product looks a lot better than the original:

PR Link

Fixing the Hover Color

The next fix that I needed to address was the color of the hover. Just as I did for the footer steps, I used the Chrome Inspector to find the CSS file that I needed to modify, in order to get the appropriate color. Once I found it, I noticed that it was using a SCSS format variable, to get the color of the hover, so instead of using that variable, I used a color picker, and found the color of the actual footer. This was a value of #222, and I decided that it is better to have consistency in color, so I went ahead and used that color.
Fix:

As you can see, the color of the subscribe button is the same color as the footer when the user hovers over it!
PR Link

Extra Fixes

Another fix that I did during the PR was actually an extra request by a commentator of the PR. PR Comment Link. The commentator requested that I fix a small issue where the input fields were not correctly aligning in mobile view, So I went ahead and made the change. This took a little investigating too because I had to use the Mobile View that Chrome Inspector lets you use, and see at which point the field became misaligned. I was able to make the fix with a simple padding addition to the left.
Fix:
And here is the result of that Fix:

Pull Request

Here is the pull request mentioned in this blog post: PR

Conclusion

In conclusion, this adventure through Meshery really opened my eyes to how careful you have to be when working on a big repository. By submitting PR's, you have to expect that your initial work will not be 100% to how the developers of that open source project want it, and since this is an open source project, you have to be really open to criticism since you are a first time contributor.

DPS909 - Release 0.4 Week 2 - Progress Update

Roman Rezinkin — Sun, 05 Dec 2021 16:48:53 +0000

The Continuation

So this week I went ahead and started making some more progress to finishing up one pull request. My goal for this week was to get some approvals for my Legend pull request. As I have been making changes, the comments suggested further making more changes, so that not only does the legend look more like the Layer5 legend, but also get the table to look more like it too.

This is the reference that I was going for.

After many iterations and changes, I was finally able to get my chart and legend to look almost identical to the reference one.

One of the biggest challenges was to ensure the table and legend were responsive, and would change sizing according to the screen size. Luckily, with Google Chromes device toolbar, it made the job of seeing the website on different devices simple. I was able to emulate iPhone, iPad, iPad Pro and many other different screen sizes.

Here are my final designs, according to screen sizing:

Desktop
iPadPro
Ipad
iPhoneX

One thing that I wanted to challenges myself with was to expand my CSS knowledge, and working on this pull request has really helped out with that front. After many different code changes, playing around with the CSS media queries.

CSS media queries:

I am actually pretty proud of the work that I have achieved in the pull request, as it has expanded my knowledge of CSS, and how everything works within it, and I know that these newly developed skills will come in handy in my future!

For the next week, I will start work on my next issue, and I will be back with another blog update, showing you guys the progress that I have achieved!

DPS909 - Release 0.4 Post 1

Roman Rezinkin — Fri, 03 Dec 2021 20:23:45 +0000

I am approaching this weeks blog post slightly late, as I had a few issues.

For our course in open source development, we were tasked with finding a repository to work on, where we could either add a new functionality, fix a family of bugs, or find a bug that would take many reviews and plenty of time to figure out and get merged.

After searching through many different open source repositories, I was unable to find anything that peaked my interest. I was struggling and was slowly loosing hope. However, one thing that kept on occurring was my ongoing PR fixes for my release 0.3 external project Meshery. My ongoing PR was full of reviews, and I was constantly making small changes based off those comments. That is when it sparked to me that this pull request was essentially what our professor was looking for in release 0.4, so I decided to do two things.

1) Look through issues in the same repository, and see if there was any other kind of work that I can pick up, things such as features or bugs.
2) Reach out to my professor, and see if it is possible to extend my PR work from release 0.3 into release 0.4, as the content work for that PR increased, due to more requested changes.

So for release 0.4, I am going to be continuing my work on my existing PR, and also begin to work on issue-605, and that would make up my scope of the release 0.4 project.

My goals:
1) Finish off the PR for the Legend, and get it merged as soon as possible.
2) Begin slowly chipping away at the newsletter subscription bug, and begin the process of getting PR feedback, so that way I have enough time to hopefully merge my changed before the due date of release 0.4

DPS909 - Lab 10

Roman Rezinkin — Fri, 26 Nov 2021 00:06:00 +0000

Introduction

For lab 10 in the DPS open source project course, we are tasked with making an official release of our static site generators that we have worked on over the semester.

The Release

My static site generator (link) was basically ready for a release... or so I thought.
I began my adventure with choosing a release tool and package, which ended up being PyPi. I followed these steps in order to begin the process of packaging and release my static site generator.

In general, the steps were very easy to follow, and I was able to get a version 1.0.0 out in no time. Here is a link to V1.0.0.

After following the commands and installing my package, I ran into a massive issue. I had no main function to call, which would introduce a heap of usability issues for any users. So I decided my static site generator needed a few fixes, before I made new releases.

My Issues

Issue 1

The first issue that I faced was the fact that my static site generator had no official main function to call upon. Yes it had __main__ but that would be troublesome for a user to call instead of simply calling a main function.

Issue 2

The argument parsing was very specific for my tool, which introduces a heap of usability issues for the user. I wanted to rework my argument parsing, so that users can type any command in any order, and the program would still function correctly.

Issue 3

The last issue was refactoring my code, and organizing it with a folder structure. I noticed that in the main folder of my static site generator, I had test files, main logic files and other files. This would make the process of working on my repository a nightmare.

The Fixes

My program underwent many changes.

Issue 1 Fix

The remedy for issue 1 could be found here in this commit. Now with this, I was able to have a proper main function that any user of my static site generator package can utilize.

Issue 2 Fix

The remedy for issue 2 can be found here in this commit. As you can see I introduced a new way of parsing my arguments through the use of the argparser library that is available for python. What a relieve!!!

Issue 3 Fix

The remedy for this issue took a few commits.

The reason why there were so many commits, is because with refactoring it introduced new folders, which broke a lot of my integration tests that I had enabled, and since I am on a Windows machine, I could only address the Linux issues when I would push a change to Github.

User Testing

The user testing was done along side user a-rokay, who was nice enough to try to use my package in a test script. Ahmad's feedback was very positive, and the only change that was recommended was a slight change to my README.md file.
Here is a screenshot of the feedback:

How to use my SSG

The instructions to use my static site generator could be found in my README.
This README will outline all of the instructions needed in order to get my SSG package up and running in your own script.

But to summarize, you need to run the following command:

pip install staticsg-rrezinkin

This will install the static site generator into your libraries, and now you can easily utilize it in your own project.

To utilize the static site generator

from staticsg import romanssg

romanssg.main(sys.argv[1:])

As you can see, we need to import it into our python file, and then we can simply call the .main function, and pass it arguments. The list of arguments could be found here: Command List

DPS909 - Lab 9

Roman Rezinkin — Sat, 20 Nov 2021 16:19:47 +0000

Introduction

For this week in DPS909 our lab challenged us to implement continuous integration into our static site generators. To accomplish this, we would use Github Actions, which is going to allow us to automate workflows in response to events that occur in my static site generator Github Repo.

Setup

The setup part of GitHub Actions was rather simple, all we had to do was follow these steps. Since my project is developed in python, I ensured to use pytest as my testing platform, since my project already has test code written in pytest. Doing so would make it very easy to implement GitHub Actions into my repository.

The work

So now that GitHub Actions was configured, I had to make a new test in a branch. Luckily I forgot to implement a test for one of my functions, so after a quick implementation, I committed my changes and pushed them to my Repository.

Now after opening my PR, I was able to confirm that my continuous integration was operating as expected. So ensure that failures would be caught, I pushed a commit with a broken test, and on my PR I was able to see the failure.

The second part of the lab was to find a partner in our class, and test their continuous integration by implementing a new test case. I chose to work on A-Rokay's static site generator, as it was written in Python so it would be very easy to work on. Here is the Pull Request I made to test their continuous integration.

Conclusion

Overall, I really enjoyed implementing continuous integration into my repository. Introducing this will ensure that very high quality code is being pushed to the main branch. I think almost every repository should have some sort of testing enabled that provides some coverage of the code base.

DPS909 - Release 0.3 Code Reviews

Roman Rezinkin — Sat, 20 Nov 2021 05:01:47 +0000

Introduction

For the last part of the Release 0.3 assignment for DPS909, we had to review two pull requests from the internal repositories. This included Telescope and IPC144.

Code Review 1

The first code review was in the IPC144 repository. Here is the link to my review. Overall the submitted markdown file was very well audited, however, I did notice that there were some code blocks that were not utilizing any type of syntax highlighting, so I reviewed the PR and commented that there should be a possibility of using the c syntax within those two specific code blocks.

Code Review 2

The second code review was also in the IPC144 repository. Here is the link to my review. I audited the entire pull request file called More Input and Output.md, and noticed that the author did a great job with their audit. I let them know that I reviewed everything and that it all checked out. I left a comment and approved the pull request.

Conclusion

Overall, I really liked this part of the assignment as it let me review and check other students code, and gave me some real world experience with reviewing pull requests. The process of reviewing a pull request is very important, as it ensures that only the highest quality code gets pushed into the main branch.

DPS909 - Release 0.3 Internal Pull Request

Roman Rezinkin — Sat, 20 Nov 2021 04:50:36 +0000

Introduction

For release 0.3 in DPS909, we had a few parts that we needed to accomplish in the assignment. This blog post will discuss my experience with contributing to an internal repository. The repository of choice was IPC144.

To find out what exactly the IPC144 repository is, click this link.

The issue

The issue that was brought up in this internal repository, was to
audit the style-guidelines.md file. There is a very specific checklist that we had to abide by, to ensure that our audit was done correctly.
Here is the link to the issue: ISSUE-49

The PR

So, I began my journey of auditing style-guidelines.md.

Setup

The setup for the IPC144 was super straight forward. It utilizes Docusaurus. I followed the steps in the Contributing file, and was able to get it up and running quickly. By doing so, I was able to get quick reload, meaning that any changes that I would make, would be instantly reflected on the localhost.

The Audit

The audit was rather simple. I followed each item in the checklist, and would go through and ensure that the selected item was done correctly. This included items such as checking for typos, ensuring the Markdown elements are converted correctly, using code blocks for syntax highlighting, etc.

Here you can find my PR:
https://github.com/Seneca-ICTOER/IPC144/pull/92

The Conclusion

Overall, this internal issue was simple, however, it introduced me into the world of auditing pages to ensure that they are done to the highest quality. Following the checklist made my journey a ton easier, and in the end I had a high quality markdown file.

DPS909 - Release 0.3 External Pull Request

Roman Rezinkin — Sat, 20 Nov 2021 04:40:12 +0000

Introduction

For release 0.3 in DPS909, we had a few parts that we needed to accomplish in the assignment. This blog post will discuss my experience with contributing to an external repository. The repository of choice was Meshery.

To find out what exactly Meshery is, click this link.

The issue

The issue that was brought up in this external repository, was to create a Legend, that resembled a Legend from a different page within the Meshery codebase.

Here is the link to the issue: ISSUE-616

The PR

So, I began my journey of implementing the legend on that specific page.

Setup

The setup was rather easy, however with being a ruby based application, it did not really like Windows. The instructions found in Mesherys README helped streamline the process for me, however I did have to iron out some kinks. There were two gems that needed to be installed manually (tzinfo and tzinfo-data). Once those two gems were installed all I had to do was execute

bundle exec jekyll serve --drafts --livereload

Implementation

Finding where I needed to implement my changes did not take long to find. Once I saw the general structure of the code, I quickly began modifying the HTML elements and the CSS styling. The HTML elements were very quick to create, however the CSS styling took majority of my time. I do not have the most CSS experience, so I was glad I took on this challenge. The hardest part was figuring out the flex-boxes, and their positioning on the screen, as well as ensuring that with a Mobile view, everything still looked correct and in order. To make my Legend look good, I downloaded the same icons that can be found here, and used them in my legend. Doing so would make the user understand the icons better, as well as their meaning.

Here you can find my PR: https://github.com/meshery/meshery.io/pull/617

The Conclusion

Overall, I found working on this external issue really rewarding. Not only did it challenge me to get the CSS working accordingly, but it felt really rewarding once I saw it being responsive, and behaving as expected. I also found the contributors of Meshery to super nice and quick to respond to PR comments.

DPS909 - Lab 8

Roman Rezinkin — Wed, 10 Nov 2021 03:20:30 +0000

Introduction

For this week in open source development, we were asked to implement testing for our static site generators. We had to research for the optimum testing platform for our code base. Since my static site generator uses Python, I opted to use pytest.
The reason I chose pytest is because it is one of the most popular Python testing platforms and allows for very in depth test creations. I also really liked that Visual Studio Code could utilize it, which made my implementations that much easier.

Implementing Testing Code

Since my static site generator has many helper functions that allow me to process folders, files, write to files, create css files, etc, I began my quest of writing my tests. At first, I had some difficulty understanding how pytest works, but after a few sample test cases, I began getting the hang of it.

Since my code works with files, my approach was to call the functions, let them produce the expected file, and verify by using assert command. The assert command allows us to verify the expectation of the return of a function. However, since my functions are mainly void, I would assert that a file was created, such as this:
assert os.path.isfile("example.html")

To view all of my tests, click on this commit 4b18e4b

Conclusion

Overall, I had a lot of fun implementing testing code via pytest, and it really challenged me. I believe that with the addition of new functions, I will be able to quickly create effective tests that will ensure my code is up to the full standards that I want to achieve.
One thing that I noticed was the difference in how my code checks for the environment. This is something that I need to relook into because since I am developing on a Windows computer and not a Linux based, the paths of the files are different, which introduced a small headache whenever I was dealing with paths.

DPS909 - Lab 7

Roman Rezinkin — Fri, 05 Nov 2021 23:51:43 +0000

Introduction

For this weeks lab in DPS909 (Open source development) we accomplished some big things. The purpose of the lab was to implement a few new features into our static site generator (mine).

New Features within RomanStaticSG

The first task was to create a Contributing.md file within our project. This file is responsible for letting new developers understand how to contribute to my open source project. This was something that was very crucial to add in my open source project.
You can see the changes here

Feature 1

For feature 1, we had to implement a formatter for our project. Since my static site generator is developed in Python, I opted to use the black formatter. It has the best features, and is one of the most popular formatters for Python.
You can see the changes that the formatter did, as well as my simple bash script that the user can run to format the files at the same time.
Commit

Feature 2

For feature 2, we have to implement a linter for our project. Since my static site generator is developed in Python, I opted to use Pylint. This linter is very powerful and has many great features. After running the linter, it provided me a lot of feedback on how I can improve my code. So I spent about 30-40 minutes fixing it all to make my code 100% efficient. This included changes file names, changing variable names, etc. All of my changes could be found here Commit

Feature 3

The final feature was to implement IDE integration. This meant integrating my formatter and linter so that the next developer would have automatic usage of the formatter and linter, instead of running my shell scripts. Anytime something is automatic rather than manual, it makes the setup process and development process that much easier. I introduced a .vscode folder and a settings.json file that introduces a few parameters to enable Pylint and Black.

Conclusion

Overall, this lab was not too difficult, however, it introduced me to Python formatters and linters. These features cleaned up my code, and will also ensure that any future contributions will be done up to standard. The introduction of the CONTRIBUTION.md file, will also allow new users to gain a perspective how they can contribute to my open source project.

DPS909 - Release 0.2 W4

Roman Rezinkin — Sun, 31 Oct 2021 17:59:47 +0000

Week 4 Hacktoberfest

For this week, I have chosen to work on this repository: link. The issue that was asked from the creator was to implement jwt tokens that should be returned when a user authenticates themselves into the program.

The issue could be found here: issue link

I have made a PR with my changes, which could be found here:
PR Link

Here is my commit link:commit

Currently, I am waiting for the owner to add the Hacktoberfest label to the issue, as well as review my PR.

DPS909 - Release 0.2 W3

Roman Rezinkin — Fri, 29 Oct 2021 00:04:46 +0000

Introduction

For the third week of hacktoberfest, I chose to work with another html project. This time I found a project that needed help with Accessibility improvements.

The Work

The issue identified that the website had a few flaws for user accessibility. Here you can see the problems that Lighthouse (a google chrome inhouse website tester for accessibility, performance etc.) brought up.

My Code Change

Here is my PR. As you can see in my PR, I changed a few things to land the 100 Accessibility rating on Lighthouse. I changed the main green color to be slightly darker, as the white text did not have enough contrast, so that vision impaired users wouldn't be able to properly read the webpage.
The second change I was regarding the images and icons. They did not contain an "alt" parameter, which would show text, in the case that images failed to load. Next, I modified the menu button, as that was also very difficult to differentiate. Finally, I reordered the headers in the website, as they were not chronological (h1->h2->h3, etc.).

Conclusion

Overall, in this week for hacktoberfest, I learned about Google Chromes Lighthouse, as well as how to optimize a website so that it is accessible for all types of users.