DEV Community: Majd Al Mnayer

The Final Stretch of My Open Source Journey: Part 3

Majd Al Mnayer — Thu, 05 Dec 2024 18:15:31 +0000

For the third week of my final open source course assignment, several events have transpired.

First, I'm glad to announce that I've successfully made all user messages sent using the WYSIWYG editor compatible with the existing MarkdownRenderer component! This means that once I transitioned all user messages from textarea to use the MarkdownRenderer component, everything worked exactly as expected, and it looks amazing!

Now users can easily write markdown in the input, send it, and view it in their chat history with the LLM. The goal was to make chat-ui behave exactly like claude, and the mission was successful!

However, there are downsides. My communication with the repo maintainer has ceased, despite my several attempts to contact them. My issues (one, two) and pull request remain open but have received no updates whatsoever.

I've attempted several times to communicate with the maintainer on the issues, but no reply has been given. The maintainer continues to reply to some other issues and pull requests, but not mine.

This has been extremely disappointing, as I put a lot of time and effort into making the requirements work exactly as expected. Seeing my work neglected like this is truly heartbreaking. What's even worse is that I discovered and resolved an issue in my pull request where LLM-sent messages weren't being converted into Markdown properly when using the MarkdownRenderer component — which was then used by the maintainer in a commit they made to the repo (and this happened after my pull request was up).

I've truly enjoyed working on this issue and this project, but it's extremely disappointing to see such poor communication take place in the open source community. Certainly nothing can be all "flowers and roses," however, this is something that shouldn't happen.

Aside from my disappointment, I would say this has been extremely rewarding. I ended up learning what a What You See Is What You Get editor is and how to create one, learned a new framework (svelte), and many other things. I would certainly recommend working on open source projects to everyone out there — you meet lovely people, learn many new things, and work on amazing projects! Just perhaps, maybe not chat-ui.

The Final Stretch of My Open Source Journey: Part 2

Majd Al Mnayer — Fri, 29 Nov 2024 15:03:47 +0000

For the second week of my final open source course assignment, I decided to contribute once again to Hugging Face's chat-ui!

The issue I created was to add Markdown rendering to user messages that are sent and stored. At the time, user messages were being displayed as unrendered markdown text.

To tackle this, I created an issue detailing my planned approach. I intended to use Marked to conditionally render certain markdown elements into HTML. After diving deep into Marked's documentation, I discovered this was indeed possible - you can simply disable the elements you don't want to render into HTML!

As I started working on the implementation, I noticed something interesting: there was already a MarkdownRenderer component in place. This component was being used to render the LLM's replies from Markdown into HTML. However, it wasn't working properly for my use case.

Strangely, while the Markdown was being converted to HTML, the elements weren't displaying on-screen - they were showing up as strings instead. This behavior was puzzling, as the code appeared correct after multiple reviews. I even started doubting my understanding and created a new empty project with TailwindCSS, copying chunks of HTML and CSS from the chat-ui project to test pieces individually. Everything worked fine in isolation.

After several hours of code review, I finally spotted something unfamiliar in the Markdown Renderer component: a function called escapeHTML was being used to escape HTML, even though DOMPurify was already being used for sanitization right after!

The solution? I deleted this function, and suddenly everything worked perfectly! The markdown was now rendering properly on screen, and I could even edit the response.

The entire process took over 30 hours collectively, and the result was deleting a single line of code! Sometimes the simplest solutions are the hardest to find.

What remains is for me to implement Markdown Rendering to the user messages, and allow the user to modify their previously sent messages as well!

The Final Stretch of My Open Source Journey: Part 1

Majd Al Mnayer — Mon, 25 Nov 2024 00:47:28 +0000

I can't believe this semester is almost over! To be fair, contributing to open source projects doesn't even feel like coursework - it feels real, and it's been amazing.

For our last deliverable in this course, we are asked to work on an issue, or several, similar to the previous deliverable. It should feel real, be a genuinely good contribution, and mean something both for us and the project!

Now, I don't really have anything specific in mind. I might contribute to projects I've already contributed to, or I might choose something new and exciting, but either way, whatever I end up doing is going to be worth it! I'm mainly looking for something fun and engaging. I'm not so fussy about what language or technology is used per se; I just want the idea or the domain to be fun!

In previous deliverables, I've contributed tests, bug fixes, features, simple documentation updates, and refactoring. I can't think of anything that I haven't done, therefore, it wouldn't really matter to me what type my contribution is, as long as I feel like it meant something, that I learned something from it, and that it benefited the project!

As of my writing of this post, I have still not decided on what project to work on. I might contribute to Hugging Face's Chat-ui, I might find a new project, or work on one that I contributed to in the past. I am hunting for an issue that is not too easy, is fulfilling to work on, and teaches new things!

And if time permits, with the finals of my other courses drawing close as well, I will take on more issues! Part two of this journey should be out by the end of this week, where I finally decide on what I will be working on and what progress I've made so far!

OptimizeIt Is Unleashed!

Majd Al Mnayer — Sun, 17 Nov 2024 22:34:48 +0000

Finally, OptimizeIt is released on npm!

npm was definitely the go-to, since I use it as a package manager for OptimizeIt. Let's discuss how this process went from A to Z.

Setting Up Releases

First things first, I had to create an account on npm. Afterwards, I had to update the package.json file to include repository, bugs, and homepage URLs. I also had to create an .npmignore file to ignore everything that is not included in the build directory. Then, I did a fresh install and build, and using the cli, I logged into my newly created npm account.

Once that was done, I created a tag for version 1.0.0, and I published OptimizeIt for the very first time using npm publish. I didn't have to update any code, files, or anything—it just worked!

It was much easier than expected, as those were the exact steps I took, and boom! OptimizeIt was now on npm!

This is great and all; however, I wanted to automate this. I didn't want to do this manually every single time. Additionally, after doing this, the releases section on the GitHub Repo was not updated with the most recently added release! I wanted a way to automate all of this—ideally: tag, publish to npm, publish on GitHub, finish.

To do this, I had to add a new job to my current workflow that runs only when a new tag is detected. I had to retrieve an NPM_TOKEN from my npm account and add it to GitHub Secrets so that my newly added job could access it to publish to npm!

For the GitHub releases part, however, I didn't have to create any secret manually, as the workflow already listens in on the repository's permissions and fetches the GITHUB_TOKEN, which is required to create a release on GitHub.

After adding the new workflow, creating a new release is simpler than ever. These are the exact steps that I must do every single time I need to create a new release:

npm version 1.0.2

git push origin v1.0.2

This will automatically trigger the workflow and execute linting, building, testing, and if all pass, publishing. Now, everything is automated—both npm and GitHub's releases are updated automatically!

Testing The Release

Testing the release went much better than I thought. The very first time OptimizeIt was run, it complained that no API Key was provided. However, a quick glance at the README.md immediately tells the user how to provide that using the toml config!

Afterwards, very thorough testing was done on all of its features, until... It was time for OptimizeIt to output some files. This is when the issue happened. Not that it wasn't working as intended, but whenever OptimizeIt creates a file in the output directory, it does so in the output directory in its directory. As in, if the user uses either its html, markdown, or output features, the file created is somewhere in node_modules in the system. While this does work, and it did work as intended... I personally thought this was very unintuitive and cumbersome. Therefore, small updates were done to OptimizeIt to now automatically create an output file at the current directory where the OptimizeIt call was invoked. As in, no matter where users are in their system, if they use any of OptimizeIt's output features, it will now automatically create an output folder and place the updated file within! This was much more intuitive than before, hassle-free, and very helpful!

Aside from that, no issues arose when testing OptimizeIt, and it works beautifully!

How Should You Use OptimizeIt

OptimizeIt is intended to be installed globally, as in:

npm i -g optimizeit

Its purpose is to offer help for the user, no matter where they are in their system. Using OptimizeIt has not changed! It works just like it always did; a very thorough explanation can be found here. However, a small example of my favorite feature is:

optimizeit examples/main.cpp examples/main.py --html

This would generate an html file in your output directory, showcasing the differences in the before and after usage of OptimizeIt:

Users can also customize its configurations however they want using the toml config option that OptimizeIt uses!

Summary

Now that OptimizeIt is released, anyone can use it for a little help in optimizing the performance of their source code! I know, I know—do not use AI to alter your code because it will break it, never use AI to write your code, it's unreadable, it's not good enough... I've heard it all. However, you, the reader, would be lying if you said you've never used AI before to help give you ideas on how to improve your code! I understand that no one should solely rely on AI to write their code; however, optimizing it, on the other hand, is something that every developer does! Whether it's to optimize an entire file, give you ideas on how to approach a problem differently, or simply make code readability improvements, OptimizeIt is here to help you Optimize it!

Well, what are you waiting for? Try it out!

Open Source Contribution: Round 2

Majd Al Mnayer — Tue, 12 Nov 2024 19:07:38 +0000

For Hacktoberfest, I started my open source contribution journey slowly, working my way up from fixing a small issue in a README.md file to contributing to a large open source project.

For this release, I wanted to take things up a notch. For the first project, I wanted to choose a new big project to work with: react-chatbotify. This project had many issues related to testing, which seemed right because, at the time, our weekly assignment was to write test cases, use mocks, etc., in our own project. For the second project I chose to contribute to, I went back to HuggingFace's chat-ui. This time, I wanted to contribute something much larger than I was used to, ideally something that I hadn't done before.

First Issue

For my first issue, I was tasked with creating several unit test cases for the ChatHistoryService component in the react-chatbotify repo. The issue itself was very well described; it even came with examples of how to do it, where the service was located, and the location of the test folder.

However, I had never mocked nor tested React components using Jest before, so this was an entirely new experience for me. After reading some of the existing tests, I had an idea of how to start and how mocking really worked (because I had to do a lot of it). Halfway through testing, I started to become a little irritated because of the amount of time it took to run all the test cases just to see if my test cases passed or not. But then I remembered that in that same week, Professor Humphrey had suggested, as an optional step for our weekly assignment, that we find out how to run a single test case using Jest, and I did! So I immediately went to the same project's repo and opened a new issue suggesting that a new script be added to allow running a single test file. The repo maintainer then replied and asked me if I could handle that too, which I included in my pull request!

I have to say though, I did not enjoy mocking with Jest. I personally think Jappa is superior in every way when it comes to mocking services and components! However, I did learn something new and tried it out! I also learned that if I am working on an open source project and I see something that can be improved that isn't mentioned as an issue already, I should open it up myself!

Second Issue

For my second issue in Hugging Face's chat-ui, I was tasked with completely revamping the main ChatInput component to make it support some Markdown features such as bolding and italicizing, additionally supporting code blocks, similar to the Claude AI chat input.

When I first accepted this feature, I did not realize that I would have to work with something completely new to me: Svelte, an open-source component-based front-end framework! This came as a shock to me as I opened the ChatInput component and realized that this was a file where there was TypeScript code, HTML elements, and styles all in the same file!

While it did look readable and fairly intuitive to understand, it was still a little terrifying, particularly in such a large project! Nevertheless, I immediately headed to the documentation to understand what was going on and what all of these things meant!

After practicing a little bit, I felt like I was ready to tackle the issue, and I was! I understood that Svelte offers lots of functions to help with mounting and unmounting components, manipulating the DOM, etc.

Now that I knew what I knew, it was time to start. Before I even began to consider how to solve this, I knew how these large projects feel about dependencies, so I went to the package.json file to check and see if there were things that I could work with. And what do you know? highlight.js was already included! What I immediately thought of was perhaps using the marked parser in addition to highlight.js to create and use my code blocks. But after quite a lot of time attempting this, I realized that hand-rolling this solution would not only take a lot of time but would also require a lot of code.

I then tried something different: markdown-it, which is another Markdown parser that offers some other features that I could find useful. I almost succeeded in creating this; however, I still needed a lot of code to listen in on key presses and conditions of when and when not to convert into markdown, etc.

Finally, I wanted to look for a tool that could offer much more help, and so I started looking into WYSIWYG (What you see is what you get) editors. And lo and behold, there were many editors that I could use which could help me accomplish my task.

However, after doing some extensive research, I realized that almost none of them were compatible with Svelte, and those that were did not offer what I was looking for. That is, until I found tiptap, which is a headless wrapper around another WYSIWYG editor called ProseMirror. However, ProseMirror is very low level, and tiptap is super Svelte friendly!

After reading the docs and replacing the existing textarea component with the tiptap editor, I realized, hey, this could actually work!

Now, you know, I know, and everybody knows, nothing in software development is going to work straight out of the box! I started to note some weird patterns, certain pieces of text disappearing, and other issues. That is, until I realized that I had to actually manually configure tiptap to work with my specifications. That meant disabling everything markdown with the exception of the codeblock, bolding, and italicizing. Afterwards, most of the issues started disappearing; however... my code was not colored! highlight.js was not working very well with tiptap, and so my joy faded momentarily... Until I found the incredible tool -- lowlight, which offers virtual syntax highlighting for virtual DOMs and non-HTML things based on highlight.js! And what do you know, lowlight already has an actual extension in tiptap -- @tiptap/extension-code-block-lowlight!

This was great and so easy to work with. I installed the extension, simply plugged it into the tiptap editor settings, and et voila! Everything worked spectacularly!

That is, until... I tried to work out the edge cases... Back and forth navigation, resizing, creating several code blocks in a row...

And so, I started tackling these issues one by one. The issue that arose with back and forth navigation was that the editor was being created every time the same ChatInput component was called, such as when an error happens, resulting in the creation of more than one. Luckily, Svelte offers certain functions that help with unmounting a component appropriately. I also made sure the newly added codeblock would resize and work in all resolutions (if you REALLY want to create a codeblock and code on your phone, that is). Finally, for the most problematic issue of them all... I was, for some reason, unable to create a new code block except at the beginning of the input. As in, if I went to a newline and tried to open a new code block, nothing happened. Apparently, that is the default behavior of tiptap; however, after some extensive research, GitHub post and issue reading, and StackOverflow posts, I figured out that there was a way to customize the codeblock's behaviors! And so I did.

Once I got several codeblocks to work at the same time, the final issue arose! If I wrote some text before a code block and opened a codeblock right after, magically, the text before got inserted into the codeblock. After quite a lot of time and investigation, I realized that tiptap was removing the previously created paragraph element, taking its contents, and feeding it into the codeblock! And so I had to modify the behavior manually one more time by creating an empty element before the creation of the code block. This helped separate the codeblock from anything that came before it!

Finally, my job was done. I'd tested every edge case I could think of, polished my code, and created my pull request!

Update

But this was not done yet! I received some suggestions and ideas from the maintainer, and tiny bug that I did not encounter myself!

I was asked to separate the Markdown Editor I created from the original ChatInput component I was working on, since it might get used by other components in the future. Additionally, the maintainer had some other suggestions, such as adding a feature to allow inline code blocks like this which I did! As well as trying to apply the highlight.js theme the LLM code block responses already use to the Markdown Editor, which I also did.

Lastly, for the bug, I simply added some very well needed validation for the conditions of when the code block should be created, and that solved it like a charm!

It's so much fun getting into things you haven't done before, working with tools and technologies you are a stranger to, it keeps things exciting!

Conclusion

At the end of this release, I definitely feel like I put much more into my open source contributions in these two issues than the four last issues combined! I've learned many things, such as opening an issue myself if I could see a potential improvement that was not addressed, doing extensive research before deciding on a specific implementation, and docs, docs, docs!

GitHub Workflows: The First Line of Defense

Majd Al Mnayer — Sun, 10 Nov 2024 22:16:57 +0000

For this week, our task was to automate everything: GitHub workflows for testing, linting, building, and error checking. Additionally, I set up a dev container that contributors can use in GitHub Codespaces for a fast, hassle-free setup. Finally, we were assigned to write tests for a classmate's project!

Setting up the GitHub Actions CI workflow was straightforward, as I had already done it several weeks ago in release 0.1. The workflow includes several jobs. The first job builds the project and ensures there are no build errors. The second job runs eslint to ensure the code meets our linting standards. The third job runs the tests and verifies they all pass! I also configured the GitHub workflows to run only on pull requests when they are opened, reopened, marked as ready for review, or when new commits are pushed.

Setting up workflows is not new for me, as I’ve done it previously in the Cloud Computing course and in my job. As for adding tests to a pclassmate's project](https://github.com/cleobnvntra/genereadme/pull/19), The main difference between my partner’s testing setup and mine was in code granularity. I made sure my code is modular, with small, testable pieces working together, making it easier to test. My partner’s code, however, was constructed in a way that combined many elements in the same file, which made testing slightly harder. Still, I found that it’s possible to test effectively without needing extensive project context—I covered edge cases, handled errors, and more.

CI is amazing and should always be one of the first setups in a project, especially for testing and linting. It ensures that the project follows standards, all tests pass, and builds don’t fail before a change is pushed to the main branch!

For the optional challenges, I had already set up linting in my workflow, so this was already done. However, setting up the devcontainer was certainly challenging. I encountered an issue with the Docker visual studio code extension that caused the devcontainer's build to fail on Windows but pass on WSL. After some troubleshooting, I found a workaround: cleaning any locally cached files (using apt-get clean) before the build process started.

Finally, the devcontainer was set up with all the recommended extensions, rules, and settings required to provide a premium, hassle-free contribution experience for OptimizeIt!

And the coolest part? Anyone can use GitHub Codespaces to run the devcontainer instantly, allowing for the smoothest possible development experience when contributing. No more Operating System issues, no more “but it worked on my machine,” and no more time wasted on annoying setup steps—everything is ready for any contributor!

Summary

Overall, I’d say this week was essential for open-source development. Ensuring your repository is guarded against issues that might otherwise cause problems is the first line of defense. It’s crucial for maintaining cleanliness and adhering to standard guidelines. Additionally, having a ready-to-use development environment for contributors not only smooths the development experience but also encourages more people to contribute with ease!

Testing & Mocking With Jest!

Majd Al Mnayer — Sun, 03 Nov 2024 22:41:05 +0000

The time has finally come to test our work! This week, we were asked to introduce a testing framework into our project and to write tests!

My go-to was Jest, particularly because I hadn't used Jest to mock services before and was curious how it would work. Of course, I had to install the TypeScript version of Jest and an ESLint plugin, but soon after, Jest was installed and running.

Jest is arguably one of the most popular, if not the most widely used, testing frameworks for JavaScript and TypeScript. It seemed only right to deepen my knowledge of its mocking capabilities for this project.

Setting up Jest was straightforward and hassle-free. Simply install the package, its TypeScript types, and voilà, it works. However, as I mentioned, since I use ESLint, I also had to install the Jest ESLint plugin so that ESLint recognizes the types without requiring explicit imports everywhere.

Testing

Thankfully, when I started developing OptimizeIt, one of my primary concerns was how to make it modular, scalable, and testable. The answer, of course, is separation of concerns and smaller functions. Unlike the code I used to write several years ago, I now consider several factors when coding. One of these for this project was ensuring that complex logic remained simple enough to be both performant and easily tested.

This made the testing process much easier; I ended up with standalone test files for each small piece of functionality in my entire project, including the Groq chat completion API!

I was pleasantly surprised to see that I hadn’t missed any edge cases. I tried to be as thorough as possible when testing each function: How could it break? What would happen if I did this? What would happen if I used incorrect data? Thankfully, everything worked as expected.

As for testing the chat completion API provided by Groq, my approach was pretty simple: Get the actual response JSON format, mock it, mock the chat completion API, and test!

I ended up with a thorough test suite for the heart of my project—the chat completion functionality—and it worked just as expected.

After several hours of writing tests, I achieved a pretty solid 96% code coverage!

Now, I have a lot of experience with testing from previous courses, personal projects, and my job. In my job, I've thoroughly tested and mocked several tricky cloud provider services. Testing OptimizeIt was straightforward, though I was initially a bit stuck figuring out how to start the mocking process with Jest since Jappa/Runner, the tool I use at work, simplifies this process.

Finally, I added a couple of extremely helpful scripts to OptimizeIt: one that runs tests whenever source code changes, one that calculates code coverage and generates a report in the coverage folder, and one particularly useful script that allows you to run a single test file! Then, I added a new job to my CI workflow that runs all the tests.

Summary

This week’s task was substantial; it’s not easy or quick to write tests that maintain high coverage (80%+) for a project with this much functionality. However, it was a great learning experience. Writing tests always helps improve the way you write code. It helps you catch edge cases you hadn’t thought of or small logical issues, like an && instead of an ||, that could cause a problem if not caught.

While it's impossible to catch every edge case, I believe there's always that one edge case you don't think of that could break your code. This is one reason why versions exist in projects—no one can make something perfect right off the bat, though perhaps over time!

Personally, what I valued most from this was keeping the source code simple. Not only does this make it more readable, but also much, much easier to test!

Clean Code: Open Source Linting & Formatting

Majd Al Mnayer — Sun, 27 Oct 2024 18:58:53 +0000

For this week, we were tasked to choose a linter, a formatter, and to add a CONTRIBUTING.md file for our project!

Personally, I always consider adding a formatter and a linter to be one of the most essential first steps before even starting to work on a project. I set them up weeks ago because I simply cannot work without following the standards. However, I will discuss them in detail, why I chose what I chose, and how I set them up.

Formatting

For formatting, my go-to is always the beloved Prettier package/extension! This was introduced to me first in the Cloud Computing for Developers course I took with Professor Humphrey last year.

Prettier is a wonderful tool that automatically formats your code based on some guidelines set in its config file. For example, here is the .prettierrc config file I use for OptimizeIt:

{
  "semi": true,
  "singleQuote": true,
  "trailingComma": "all",
  "printWidth": 80,
  "endOfLine": "auto"
}

While Prettier does have its default rules, you can add your own rules in this file. Personally, I asked it to always include a semicolon at line endings, use single quotes ('') instead of double quotes ("") where applicable, and apply some other settings!

This tool helps a dev team, a company, or a department establish its own standards and guidelines for writing clean and maintainable code.

Prettier can also be configured to automatically format on file save! This can easily be done in Visual Studio Code by simply going into the settings and enabling the option. It can also be done in many other IDEs!

I also provided a script to run Prettier manually:

npm run prettier

Linting

For linting, my go-to is usually ESLint. Unlike formatting, which is meant to keep your code clean and readable, linting helps detect issues in your code, such as unused variables, attempts to change an immutable variable, and many more. ESLint is my go-to because I always use Airbnb's ESLint Configurations in my projects. ESLint allows you to set many rules for your source code, such as using a specific naming convention, forbidding vanilla for-loops, or prefix and postfix operators, restricting single exports in a file to export default, and many more.

The reason I always use the Airbnb ESLint Config is that it's widely regarded as one of the cleaner and more efficient ways to write code. Many smart people spent countless hours carefully choosing the best rules to follow, and which to avoid, and placed them all together in that config file, which is used by millions of projects every week!

However, ESLint is slow. It takes time to run and fix issues, particularly in large projects. I wanted to try out something I hadn't used before for this lab, since I had already implemented the formatter and the linter weeks ago. I tried Oxc, which is a JavaScript linter that is Prettier-compatible and ESLint-friendly, written in Rust.

Installing this tool was pretty straightforward, and I was really excited to see its performance given that it's written in Rust, and on their official website, they boast about how much faster their tool is than alternatives.

Not only was this tool fast, easy to use, and efficient, but it also displays errors in an incredibly intuitive way! It clearly shows what is wrong, what rule was broken, and how to fix it clearly! Unlike ESLint, which doesn't show as much detail about what went wrong.

The documentation also mentioned an ESLint plugin so that Oxc works with ESLint, that I simply injected into the ESLint config file eslint.config.mjs.

Here is an example of an error caught by Oxc, just look at how elegant and clean it is, it has colors too!

I also provided a script to run linting manually, which runs both Oxc and ESLint:

npm run lint

Pre-Commit Checks

Once both linting and formatting were set up, I wanted to dig in and see how to run both linting and formatting before a commit is made! This is something I hadn't done before, and I didn't know where to start or what to look for. My first approach was to go to Google and search "pre-commit command run packages npm". However, I didn't get very far doing that.

My second approach is to always ask ChatGPT to do a Bing (I wish it was google too, believe me) search for me and find tools that fit my criteria. And it did! I was recommended two packages, Husky and lint-staged, which work together! Husky is a package that provides ultra-fast modern native Git hooks, and lint-staged is a tool that allows running linters against staged Git files!

Once I knew what tools to use, I delved into the documentation, which was surprisingly very easy to follow. I simply had to install Husky, lint-staged, and update the Husky pre-commit script to run the lint-staged configuration I made before a commit is made!

For context, this is my lint-staged configuration for OptimizeIt:

{
  "lint-staged": {
    "*.{js,ts,json}": [
      "prettier --write",
      "eslint --fix",
      "npx oxlint --fix"
    ]
  }
}

For my config, I require formatting and linting for all JavaScript, TypeScript, and JSON files!

And it worked like magic. I tested it in different scenarios. Whenever a commit is made and a violation occurs, I get an error in my IDE with a button to check the logs. In the logs, there is detailed information about what issue happened, why the error occurred, and everything we need to solve the problem!

Results

Now, the reason I did not encounter any linting or formatting issues when I ran the scripts is that I had them installed several weeks ago. However, even when I am developing, I rarely encounter ESLint issues, mainly because I have been working with it for a while and I know how it works and what it violates. Although, encountering ESLint issues is very normal when working on new projects with different rules, and we as programmers have to simply follow these rules to provide the cleanest, most error-free code possible.

What I loved the most this week was learning about pre-commit linting and formatting. This was something new for me, and I honestly thought implementing it would take quite a while, that I'd have to work with shell scripts and other Git configurations. However, it turned out to be much easier than I thought!

Overall, these steps are extremely essential, and I believe that formatting and linting should be the very first things introduced in a project, to avoid issues if implemented later on.

Hacktoberfest Conclusion: Hugging Face Finale!

Majd Al Mnayer — Fri, 25 Oct 2024 18:52:11 +0000

For the last week of Hacktoberfest, I wanted to do something special. I wanted to contribute to a much larger repository than I had contributed to so far!

The Issue

What project would fit better than one where the theme is similar to our labs? On to Hugging Face repositories!

After browsing their repositories, I set my mind on the chat-ui project. Chat-ui is the open-source codebase powering the HuggingChat app! The HuggingChat app is a chat-based web app that allows interaction with a variety of different language models, such as llama, cohere, and mistralai models, and more!

The issue I chose discussed implementing a new feature for the existing model configuration in the app. While this is something I personally did not know before, apparently some models do not support system role prompts, but rather only user role prompts. Therefore, models that do not support system role prompts failed to work on the app.

My task was to implement a new model configuration option that allows the user to specify whether the model in use supports or does not support system role prompts.

Process

The setup process took quite a long time (another downside of being a Windows user), even though I was using WSL, which powers an Ubuntu subsystem on my PC. Not only that, but building and running the llama.cpp server was not only time-consuming but also extremely resource-intensive. I could feel the hit my PC's performance took when I got it up and running. Nevertheless, once it was all set up, and I made sure everything worked, it was time to start development!

The very first thing I did was search for modelConfig in all the files, because it was pointed out in the issue that the new option should be added there. I immediately found the file in question.

The next step was to familiarize myself with the code. I noticed they are using Zod for validation and type inference, and I could see where all the user prompts are being passed, and system prompts are being set.

After identifying where I needed to insert the new feature, I made sure to make the least amount of changes possible to support this new feature. I added a new variable to the Zod validator, systemRoleSupported which is true by default, and simply filtered out all system prompts before they were passed to the models.

I also ensured that hard-coded system prompts preferred user prompts if the user specified that the model does not support the system prompt.

After a lot of code reading and testing, my pull request was up. I got one tiny requested change from the repo maintainer asking for a better name for the new model config option, but once that was addressed, all checks passed, and the pull request is now ready to be merged!

Hacktoberfest Conclusion

Overall, I would say this was one of the most fun and engaging experiences I've had in my program yet. The idea of contributing to random projects supported by strangers with similar goals is exhilarating. Seeing every open-source contributor and maintainer following the best practices that we were taught, and communicating effectively, was inspiring, and yet another proof that I was born to do this, because it's just so much fun!

P2P, WebSockets & WebTorrent

Majd Al Mnayer — Thu, 17 Oct 2024 23:51:23 +0000

For this week, I decided to contribute using a different language. My goal was either JavaScript or TypeScript, and I ended up finding an extremely interesting project called Blaze. Blaze is a peer-to-peer file-sharing progressive web app built using WebTorrent and WebSockets. Although there weren't many open issues in this project, I found one that seemed interesting to me. For my issue this week, I was tasked with displaying error modal popups to users for certain uncovered edge cases.

The Issue

The issue was not very descriptive, and the only information provided was, "When the connection to the Blaze server fails, no feedback is given to the user."

Therefore, my goal for this week was to investigate and analyze all uncovered edge cases where the backend might fail, resulting in no error messages being displayed to the user.

To begin, I isolated the front-end files where my modifications might take place. At first, I thought the front-end was written in React, but it turned out to use a different library called Preact, which is an alternative to React with the same API but much faster.

Afterwards, my task was straightforward: trace, investigate, isolate, and update. My first instinct was to close the connection to the backend and analyze the front-end to determine where error messages should pop up. I found several uncovered edge cases and updated the app to use an error modal, leveraging a component that already existed in the source code.

After creating my pull request, the project maintainer replied, thanking me for my well-written pull request and providing detailed descriptions. However, they also suggested some changes and asked for my opinion regarding one of them. After discussing it with the repo owner directly on the pull request, I set out to apply the requested changes. However, I noticed one of the changes seemed redundant, so I replied to their comment, asking for their opinion this time. Unfortunately, that was several days ago, and I haven't received a response yet.

Going Forward

I have to admit, it feels like a letdown not to receive a timely response after dedicating personal time to the project. While I enjoyed working on the project, learning Preact, WebTorrent, and analyzing the code, I felt disappointed that I couldn't complete my pull request this week.

Perhaps that was my own fault. The repo was active, but its last update was about a year ago. I think that from now on, I will only contribute to repositories that have been recently updated.

Despite that, I thoroughly enjoyed working on my issue this week and am looking forward to the next one!

Contributing To Open Source - C++ Edition

Majd Al Mnayer — Tue, 08 Oct 2024 23:00:31 +0000

Following last week, where I did my first straightforward open source contribution, this week I wanted to tackle bigger contributions.

For starters, I came across a C/C++ Library that prints the alphabet as ASCII art in different fonts.

However, afterward, I still wanted to do more, so I started looking for a larger project to contribute to. To my surprise, the very popular faker.js library has a C++ version in the works, faker-cxx, which I was very excited to work on!

First Contribution

For my first issue of this week, I was tasked with adding a new letter to the drpepper font in the ascii-art library.

This was a straightforward task because the file structure was very easy to navigate. There was a folder called fonts containing the supported fonts. Before I began the process of adding my new character, I examined how others had added characters to the font.

I simply followed the existing style, added my character, and then submitted my pull request.

However, I found the method of adding new fonts somewhat peculiar. Here's an example:

vs D()
{
    vs character = getCharGrid(4, 5);
    character[0][0] = character[0][4] = character[1][1] = character[1][3] = character[2][1] = character[2][3] = ' ';
    character[0][1] = character[0][2] = character[0][3] = character[3][1] = character[3][2] = character[3][3] = '_';
    character[1][0] = character[2][0] = character[2][2] = character[2][4] = character[3][0] = '|';
    character[1][2] = '.';
    character[1][4] = '\';
    character[3][4] = '/';
    return character;
}

I'm not entirely sure why it was done this way, but it seems to allow for clear modifications if needed in the future.

Second Contribution

For my second issue in the faker-cxx library, I had to add a new faker function to the Date module. This function should mimic its JavaScript counterpart.

At first, I thought, "It's just one function... how hard can it be?" But I was wrong.

I had to read through a lot of code to understand how everything was structured, where things were declared, where they were exported, how tests were conducted, and how to add new ones.

The contributing guidelines emphasize that all additions must be thoroughly tested.

There were many custom types and reusable functions, so I had to familiarize myself with each one before I could start coding.

Once I identified the necessary files and became accustomed to some initially unfamiliar C++20 syntax, like:

void doSomething(const& auto param){}

I realized this is syntactic sugar for templates! This use of auto allows the function's parameter type to be deduced without explicitly specifying it.

After understanding the internal functions (used internally for development but not exposed in the API), I added two functions. One accepts two ISO dates, and the other two timestamps. Luckily, there was already an internal function to generate a random date between two given dates, so I mainly needed to manage parameter conversions and preparations.

Once the functions were ready, I documented them for the API and created and ran the necessary tests. Adding tests was initially confusing, but after examining existing ones, it became straightforward.

However, running the tests proved challenging. I needed to build the entire library using cmake, which usually wouldn't be an issue, but I encountered a persistent error with the fmt dependency not found.

Despite following all the steps (on both Windows and Unix), I couldn't get the cmake build to succeed. After several hours of debugging, I decided to try another build method provided by the project, using bazel, which was much simpler.

After successfully building the project and running the tests, I was delighted to see all tests pass. I then tested my newly added function in a fresh C++ project, and it worked perfectly!

Finally, my pull request was accepted without any requested changes!

It felt really great contributing to a well known library like faker, that I have personally used at my job!

Final Thoughts

This week's contributions were incredibly rewarding and exciting. I feel more confident than ever in my ability to contribute to open source projects. Next week, I plan to explore contributions to a project in a different language!

Optimizing OptimizeIt

Majd Al Mnayer — Sun, 06 Oct 2024 18:37:39 +0000

This week is a nice change of pace. We are tasked with refactoring our projects!

This means renaming badly named variables, abstracting away logic, creating functions out of duplicate code in several files, looking out for any performance-impacting logic, renaming files, rearranging directories, and more.

Refactoring

This required a deep dive into the code, reading every line, and tracing execution because I did not want to make any modification that would impact the current functionality of the program. I just wanted to make it better in any way possible.

At first glance, I could see some duplicate code in my flag handlers. This was an easy fix. I factored out the duplicate code, made a helper function, and called it where applicable.

Afterwards, I noticed that the file structure in my project was a bit chaotic. I then decided to move all helper functions to their own helpers folder. There are two such folders: one is a global helpers folder, and the other is specific to argument handling.

Then, during further inspection, I noticed some code was out of place. For example, I had a function that handles file names in the argument handler file. I moved it into its own file, attempting to separate all code that did not share the same context into their own files.

After completing these three refactors, I decided to use my own tool on itself! That's right, OptimizeIt is going to optimize it! I used OptimizeIt to optimize main.ts, because it was starting to get unmaintainable with lots of different logic existing there—some for handling output, some for processing files, and some for executing it all together.

OptimizeIt then optimized it by separating each chunk of logic into its own function! This greatly enhanced not only readability but modularity as well. I then proceeded to create different files in the helpers folder for each of those functions, and now my main.ts looks super clean, elegant, and the complex logic that I once had is now in its own files.

For my final touches, I addressed certain nitpicks I had in the past, such as changing the token usage short flag to -u instead of -tu, separating all interfaces into their own files, and some renaming, such as renaming Config to TomlConfig.

Finally, I bumped the version up from 0.1.1 to 0.1.3, because at some point I forgot to bump the version up to 0.1.2, even though I had a 0.1.2 release on my repo.

Once the refactoring was complete, I then squashed all of the commits into one, amended it, and merged into main!

Overall, more work was done than I anticipated. You can see all of the changes in this commit. However, I now feel much more confident about the state of OptimizeIt, as it's looking very modular, easily maintainable, and super readable!