DEV Community: Andrii Sych

Git remote branches

Andrii Sych — Fri, 04 Oct 2024 23:56:33 +0000

This week we had to add a feature to another person's repository. To be specific, we were required to add a default configuration TOML file inside of user's $HOME folder, that contains default parameters for a CLI tool. I have contributed to readMeMaker repository:
https://github.com/jadorotan/readMeMaker.git

Jadorotan's code was located all in one file, so it was pretty simple to work with it. I just had to install a library called tomli and add a function which reads default configuration file, if it is provided. All the changes were inside of approximately 10 lines of code.

I have switched to wsl completely for my development and work. I've had problems with interacting with Debian shell. To be exact, I had troubles managing user permissions and for some reason in the commit history of Jadorotan's pull request you can see how the user who committed is not SychAndrii, but root user, which is my Debian user.

Thanks to professor Humphrey's lectures, I have completely understood what branches are - just names for commits that move forward over time. I had no troubles switching between remote and local branches and merging changes from feature branch to main branch.

Having completed this lab, I have learned about how to manage many git remotes (not just origin).

Fast-forward and three-way merges

Andrii Sych — Sat, 28 Sep 2024 02:18:49 +0000

While working on my project Infusion:
https://github.com/SychAndrii/infusion

I decided to implement 2 new features - streaming responses from LLM in real time and usage of appropriate exit codes upon program completion. However, instead of creating conventional pull requests to integrate changes into main branch, I was tasked to do the merges locally in my repo, and then push results of the merges to the remote repo.

The first issue was to implement exit codes:
https://github.com/SychAndrii/infusion/issues/34

Closed with merge commit:
https://github.com/SychAndrii/infusion/commit/b01f493a8eb3c86aad00760f41f8adf0b93b231e

This task was pretty easy to implement since python provides you with a sys package to return status codes. I have decided to have 4 error status codes for my program:

0 - Program ended successfully.
1 - Invalid options provided.
2 - Invalid files provided.
3 - Unknown error.

On top of adding status codes, I have also refactored the code to be more intuitive with use of more functions.

My second issue was to implement streaming:
https://github.com/SychAndrii/infusion/issues/33

Closed with merge commit:
https://github.com/SychAndrii/infusion/commit/b01f493a8eb3c86aad00760f41f8adf0b93b231e

This task was more difficult to do because of LangChain library I am using for my project. This library is relatively new, so documentation for streaming with astream function is very unintuitive and difficult to understand.

I have always hated python and will keep doing it for the rest of my life. I tried to become more comfortable using it with this project, but after languages like C#, TypeScript, or Kotlin - I just can't take Python seriously.

Contributing to another repo

Andrii Sych — Fri, 20 Sep 2024 22:39:22 +0000

Since the beginning of this month, I've been working hard on the Open Source course I took at Seneca Polytechnic, and one the labs that we had was to create a pull request so someone else's repo and approve a pull request to your own repo, so that's what I am going to talk about.

I am going to start with a pull request that I created for an issue. The issue was to add support for a flag, which allows to see how many tokens were used in request and in response:
https://github.com/aamfahim/explainer.js/issues/22

The process of implementing this feature was pretty simple. I had to fork the original repository, commit and push the changes to a new branch, and create a pull request from the branch in in my fork to the main branch in the original repo:
https://github.com/aamfahim/explainer.js/pull/23

Implementation was pretty simple, considering the fact that I have used node.js for quite a while and my teammate does not have a lot of strict requirements considering the way I write code. After he reviewed my code, he requested me to change the names of the variables to be more descriptive, but that was about it - the changes were quite simple and straightforward.

Now, my partner has had a lot of trouble implementing the issue in my repository:
https://github.com/SychAndrii/infusion/issues/20

With his pull request:
https://github.com/SychAndrii/infusion/pull/21

As you can see, the history of reviewing and requested changes is much longer than the first pull request. The way my teammate (whose issue I appreciate, by the way) wrote code the first time involved creating a function that was only executing its code if second parameter was True, so I decided that it's not a very clean approach, and asked him to remake it. Instead of constructing Langchain's chain object using a function that sometimes does not do anything, I asked him to construct this object conditionally, but with a function, that is always useful. Additionally, my teammate has a lot of troubles dealing with Python language (so do I, to be honest), so he had a lot of trouble implementing the feature in general, because of the language and because of LangChain's multiple layers of abstractions.

Having completed this lab, I have learned how to review code on github, reject pull requests and approve them, and how to link them to existing issues. Besides that, I already had knowledge about everything we've been doing.

Infusion v0.1.0

Andrii Sych — Fri, 20 Sep 2024 22:17:35 +0000

Over the course of the past 2 weeks I have been working on a documentation-generation tool that uses Open AI API to generate new files with documentation in them. I have built it using Python, Click, and LangChain libraries. The features include:

Automatically generates structured comments and documentation for source code.
Supports multiple programming languages (identified via file extension).
Handles multiple files at once (no batch processing yet).
Allows custom output directories to store the processed files.
Allows you to specify a model to use.

You can access the GitHub repo here:
https://github.com/SychAndrii/infusion

Infusion is a command-line tool designed to assist developers by generating documentation for their source code. By providing file paths, Infusion leverages language models like OpenAI’s GPT to modify the files by inserting appropriate comments and documentation. The tool supports multiple programming languages.

It is particularly useful when you need structured comments (e.g., JSDoc for JavaScript/TypeScript or JavaDoc for Java) or simple comments above functions and classes. Infusion saves the modified files to a specified output directory.

Installation

To install and run Infusion locally, clone the GitHub repository.

git clone https://github.com/your-username/infusion.git
cd infusion

After that, you will have to set up a virtual environment and install all the dependencies.

If you are on Windows, use PowerShell to set up virtual environemnt using the command:

./setup/setup.ps1

If you are on Mac / Linux, use the following command:

./setup/setup.sh

After you are done setting up virtual environment, you can use the Infusion tool by running:

pipenv run infsue [OPTIONS] [FILE_PATHS]...

Usage

To use Infusion, run the following command, replacing FILE_PATHS with the paths to the source code files you want to process.

Process a single file:

pipenv run infsue ./path/to/source.py

Process a single file with a different openAI model:

pipenv run infsue -m gpt-4o-mini ./path/to/source.py

Process a single file and specify an output folder:

pipenv run infsue ./path/to/source.py --output my_output_folder

Process multiple files:

pipenv run infsue ./file1.js ./file2.py

Process multiple files without specifying every single one of them:

pipenv run infsue ./folder/*

Process multiple files and specify an output folder to save files to instead of printing them to stdout:

pipenv run infsue ./file1.js ./file2.py --output my_output_folder

For a more practical example of usage of this tool, please see the GitHub repository! I'd love if you posted your issue to suggest any improvements in my codebase!

Infusion docs generation cli tool

Andrii Sych — Fri, 13 Sep 2024 23:48:41 +0000

Infusion is an open-source tool that is used for generation of documentation in your code files. It uses OpenAI gpt-4 model to write comments. It was my project and I wrote it in Python.

GitHub link:
https://github.com/SychAndrii/infusion

explainer.js is an open-source tool that is used to explain code snippets in your code files. It uses Groq models to write comments. It was a project of my teammate @aamfahim and he wrote it in Node.JS

GitHub link:
https://github.com/aamfahim/explainer.js

I am currently enrolled in an open-source course at Seneca Polytechnic, where we were tasked to team up with another person and review each other's code and give some suggestions for improvement using GitHub issues. I am going to describe this process.

Mode of communication

Most of the issues generated for both repositories were done using synchronous communication via Discord call. After that, we talked asynchronously using Discord messages, since there was a difficult issue for me to streamline setup of my project using bash scripts, and calling my teammate every time I needed to test if it works on his machine seemed unnecessary. Testing using Docker containers and WSL Linux sub system on my machine was not the same as testing them on Al's system, and it highlighted important bugs.

Experience of reviewing someone's code

I did not experience anything unusual when reviewing my teammate's code, since I have lots of experience with Node.JS development. I liked creating issues and then immediately suggesting solutions to them though. One problem we had is that we could not figure out a way to allow me put labels on the issues I created, only Al could do it, which was annoying.

Experience of someone reviewing my code

Al suggested a lot of room for improvement, particularly with installation of my CLI tool. When he first forked my repo, it was a requirement for the end users to go and install a particular version of python manually, which is definitely a frustrating task. Additionally, he highlighted other possible improvements for convenient usage of a tool, like introducing .env file so that you don't have to input your API key every time you start the tool. I like getting input on my code from other people because it allows me to grow as a developer and it definitely expands my view of development lifecycle.

Issues during reviewing and testing

Most of the problems we had were with my tool, because Al's CLI program was written in Node.JS and we both have a lot of experience with it. In contrast, both of us don't like Python ecosystem, so we had a lot of troubles interacting with it. When testing Al's repository, I found the docs written in his README to be misleading or confusing to understand, especially the model and api-key options. We had to go through the process of trials and errors to figure out which API keys and models are accepted by his tool. When it came to testing my repository, version of python on Al's system was very outdated (2.7), so he had to install 3.10.6 (version, required to use my tool) manually. However, even then the problems did not end. Even though he installed it, it was still not being recognized by the virtual environment my tool creates with pipenv. After that, we also had frustration with entering the API key required for the usage of my tool every time we started it. Finally, the README docs did not help with the installation. We tried to follow them, but we kept getting errors related to some scripts not being recognized on the PATH. That's when I decided that we need some sort of automation tool that does all the installation for you. One thought I had is to dockerize the application, but then it would require me to somehow map Docker volumes to the output directory and input files specified for my tool, and that would complicate everything twice. Thus, I remembered that a lot of package managers are actually command line tools, and if you install them by cloning a GitHub repo, then you need to set them up by executing some kind of bash setup script. So that was the idea that I decided to implement. Finally, both of us could not figure out a way to assign labels like bug or enhancement to the issues we filed.

Issues I filed

Issue 1

https://github.com/aamfahim/explainer.js/issues/13
Basic -h flag documentation enhancement.

Issue 2

https://github.com/aamfahim/explainer.js/issues/12
The temperature option did not work properly even if it was within valid range (from 0 to 2). Turns out the CLI framework Al uses parses all the options passed to it as strings, so I suggested converting the temperature to a number before passing it to the API request.

Issue 3

https://github.com/aamfahim/explainer.js/issues/11
My teammate forgot to implement a flag, which was mentioned in a README file as working, which is misleading.

Issue 4

https://github.com/aamfahim/explainer.js/issues/10
This one is pretty interesting. First of all, README does not explain which models are accepted by the Groq. But even the allowed model we tested did not do the job of the CLI tool, since it was classifying the code based on the safe/unsafe evaluation, which is not what we really want for this project. So I suggested narrowing down a list of allowed models to use and update the README to include this information.

Issue 5

https://github.com/aamfahim/explainer.js/issues/9
This issues covers points I have mentioned before. Some flags are misleadingly documented, and some of them are not documented enough.

Issues that were filed on my repo

Issue 1

https://github.com/SychAndrii/infusion/issues/11
The problem was that I confused LLM with my prompt. I told it that I only want source code from it, and at the same time I told it to send the word 'error' if the code it read was not following language's syntax. Additionally, I rephrased my prompt to be more strict with files that do not contain valid code.

Issue 2

https://github.com/SychAndrii/infusion/issues/10
Basic -h flag documentation rewording.

Issue 3

https://github.com/SychAndrii/infusion/issues/9
I also found it annoying to define the API key every time I run the app, don't know how I didn't think of creating .env file.

Issue 4

https://github.com/SychAndrii/infusion/issues/8
I have decided not to go with dockerizing my app, because then it would not really feel like a true CLI app, and instead decided to have shell scripts for setting up all the dependencies and the correct python version.

Issues I managed to fix

I fixed all of my issues. All of them took less than 30 minutes to fix, but there was one issue, that took me like 2-3 hours to fix:
https://github.com/SychAndrii/infusion/issues/8

It might seem weird since enhancement of README file should be easily achievable, but what the first suggestion by Al required me to completely remake the installation process of my tool, which required me to introduce 2 scripts for installation - one for bash and one for Powershell. The problem I could not solve for most of the time was that even though these setup scripts properly installed the needed version of python, this version of python was not passed down to the virtual environment, which you need to enter before using my tool. Eventually, I fixed that though.

What I learned

I have definitely improved my README skills. The way I provided example usage was very confusing for the end user. Additionally, I have finally used bash and powershell languages to do something myself, not for a school assignment, not because it was a requirement, but because I wanted to simplify the process of interacting with my tool. Finally, I decided to face the language I absolutely can't stand - which is python. Working with it was definitely not enjoyable for me, but I think it's essential to be able to use it if you want to find a job today, especially with AI trending.

My first post

Andrii Sych — Sat, 07 Sep 2024 00:10:35 +0000

Hello everyone

it's my first post on this platform, and to be honest I have never read any blogs before. I'm excited to see how it impacts my knowledge of programming technologies. I've been watching YouTube videos for a while, and sometimes have come across some frameworks that would solve an exact problem I was working on at my job / while doing my project. Nevertheless, I hate watching videos, I prefer reading, so dev.to might eliminate the problem I have and expand my view of tools available out there.

Open source

I am currently enrolled in open source development course at Seneca Polytechnic. I have decided to take it since working on large legacy projects with a lot of bugs and uncommented 500-line functions is for some reason my area of passion. You don't get this experience working on school assignments, and open source allows you to experience this in full. Besides, I took cloud computing course before and the professor there (David Humphrey) has taught me a lot of new concepts and practices, so I wanted to take a course that he is teaching.

Goals

As I've said before, I want to contribute to something that's actually meaningful to someone and is being used. It's my 7th semester, and besides co-op, I have never created something for someone to use in real life. I want to change that. Specifically, I am interested in old legacy distributed systems written in Java/C#. However, I also recognize that Python is the most in demand language today, and LLMs are trending, so might explore projects in this area as well.

Interesting open source project

The project I picked was kotaemon: https://github.com/Cinnamon/kotaemon

I found it interesting because it performs exactly a job I currently need on my project, which is giving LLM responses based on documents uploaded. It is exciting to see someone already implementing the idea you had, because you don't have to implement it from scratch using low level frameworks.