Dhruv Ahuja

I owe my career to open-source communities. I'm not sure newcomers can say the same.

2026-05-15T00:00:00+00:00

Open-source is cool</h2>

Ever since I started learning programming, I knew I wanted to align myself with the open-source community, because of the following characteristics I found admirable:

the way people built software in collaboration, with developers contributing from across the world, and the genuine care for good documentation, including internationalization (i18n) efforts.</li>
the impact open-source had on the industry. From startups to trillion dollar behemoths, everyone relied on open-source software for critical workflows. Many teams maintain their separate forks to manage business requirements, push patches, or build features that align with their needs.</li> </ul>
Perhaps the most impactful was also the hardest to articulate: I simply found the ecosystem, and the de-facto "marketing" around building in public, genuinely cool. And I knew I wanted to contribute to open-source and "build my credentials", which in turn would elevate my career.
Open-source has defined my career</h2>
In 2021, I'd chosen Python over Javascript as the language to learn, build some projects, and like thousands of others, break into tech. After learning the basics, came the time to learn web development.
I picked up FastAPI instead of Django, because I saw this talk</a> by FastAPI founder Sebastián</a>, and thought that async-first and type safety in web apps sounded great and was the future, even though I barely knew what Python types were at the time.
Finding my people</h3>
Alongside the coding, I loved reading opinion pieces, GitHub issues, and tech discussions on Reddit and Discord. Over time, I began participating as an enthusiastic beginner — slowly making friends, finding mentors, and learning things I absolutely wouldn't have learnt otherwise.
A mantra I've carried through every role since, including my recent transition to DevRel, is that you don't have to be the best: by being passionate, curious, and proactive, you can make friends and be remarkable.
Landing that first role</h3>
I wanted to make a mark online, and besides coding, that meant being active in these communities, learning how they thought about things, being genuine, open to feedback on my code, and being somewhat opinionated.
I couldn't be the best developer out there, but I could put my first real project, a CLI-based song downloader, out on Reddit, get genuine feedback from better programmers, and build some credibility in the process.
I landed my first job in July 2022, after about one year of learning programming, as a web developer for a small startup using FastAPI on the backend. Their CEO was impressed by my GitHub project, and the documentation and discussions around it. And so, the stars aligned, and I broke into tech.
Delving deeper</h3>
In late 2023, I was obsessed with Rust, and found similar support in the r/rust subreddit and the official Discord server. This was some of the most enjoyable time I had programming: being blown away by Clippy's helpful error diagnostics, admitting to a couple Rustacean friends about how I broke down in tears dealing with Tokio's lifetime requirements, when I was rewriting my CLI song downloader</a> in async Rust, and the joy I felt seeing my blogs being accepted for the This Week in Rust newsletter</a>.
These small wins meant the world to me. They assured me that I'd "made it", that I'm a part of these communities I have admired since the beginning, as at least a little more than an enthusiastic novice. In fact, I owe my career to these communities, all the internet strangers who answered my silly questions (most infamously, "how many endpoints should a typical web API have?", for which I received scathing critique), helped break down design patterns, and plan out my career.
Many of these strangers have gone on to become people I deeply respect and look up to, and a few have even become lifelong friends.
When the floodgates opened</h2>
Fast forwarding to 2026, and things have changed significantly. LLMs have reduced the barrier to entry for generating code, memos, and documentation of all kinds. You could ask Claude to generate a 10-page manifesto for your startup idea and it will gleefully do that.
While producing output has never been easier, it has made it incredibly difficult to be taken seriously.
This has led to online communities and platforms being bombarded with low-effort content. Often, the users posting these projects have little idea about the internals, and even resort to using AI for responding to comments on their posts.
For users looking to participate in genuine discussions or understand the intent and implementation details, such posts are a waste of time and effort.
Communities push back</h3>
To combat this flood of low-effort content, moderators of most communities have begun tightening the rules. For example, many large subreddits now outright flag posts that have a GitHub link, or are perceived as "AI slop" — the term given to this sort of AI-generated content. The first rule in the r/python subreddit, titled No showcase posts</code>, explicitly states:
Due to an increase of showcases featuring AI content such as working with multiple AI models or wrappers around APIs, this is no longer allowed. Please post your showcases in the appropriate monthly showcase post or a daily thread instead. </code></pre>The r/programming subreddit, which has ~290K weekly visitors, banned all AI-related content</a> for the month of April, with the community responding to the change positively in a follow-up thread</a> started by the moderators to gather the community's feedback. Open-source repositories under siege</h3> Similarly, many renowned GitHub repositories have adopted extreme measures to counter this problem. cURL</a>, for one, completely scrapped its bug bounty program</a>. Daniel</a>, cURL's founder and development lead, published a blog post a few days later explaining why the problem had become unmanageable. In the comments, Piotr</a> from the Apache Log4j team further detailed their own struggles — overseeing an influx of low-effort reports to the Log4j Bug Bounty Program since July 2024. This lines up with the time when engineers truly began harnessing the power of LLMs for speeding up their development workflows. Credit: Daniel's Blog</a></div> Although I have cherry-picked a few well-known examples here, I am certain these changes are not limited to larger communities or programming codebases. Communities of all shapes and sizes, including individuals, have been struggling under the weight of AI-driven activities. By this point, almost all of us have run into a wall of overly-verbose Markdown documents, complete with elaborate Mermaid diagrams and references to dozens of sources for further reading, at work or elsewhere. Ironically, in my experience the Mermaid diagrams often do more to explain the concept than the pages of generated text. An uphill battle for newcomers</h2> While the tightening grip on public platforms affects everyone, I believe newcomers have it the worst. Those getting into the tech industry now face an uphill battle: an already tough job market now sees tech companies use AI to automate the tasks that junior engineers used to take on, learn from, and grow in seniority over time. Couple that with the heightened scrutiny on content shared in public spaces, and the opportunities to get into open-source have narrowed significantly. Maintainers are already burdened, other passionate community members are burnt out by AI slop, and people increasingly become suspicious of anything that seems AI-generated (and it often is). I think the current mindset adopted by communities against AI-slop can best be encapsulated by slightly tweaking the Python adage on duck-typing: If it sounds like AI and reads like AI, then it must be AI. </blockquote> And honestly, they're not wrong. Still, rather than give in or leave things to deteriorate further, these communities are fighting back. The subreddit bans, tighter rules, and honor systems are all steps taken to stem the flood. While these actions might seem harsh or extreme to many, moderators and maintainers have deemed it necessary, if the care for craft is to be maintained. Through all of this, I consider myself genuinely fortunate to have found those people when I did — early, when I needed it most. I've witnessed what made open-source great up close, and I'm afraid that things might never be as good as they were (or seemed to be, personally), particularly for the people just now finding their footing. I don't think it's all doom-and-gloom though. The adaptation processes have already begun, and I believe they will strike the right balance. But for the newcomers, the path is narrower and the signal harder to find among the noise. I hope they still get to experience what I did.

How the (Em)ighty Have Fallen— 2026-03-29T00:00:00+00:00 Machine maketh the em</h2> The em dash—heavily stigmatized as a hallmark of LLMs like ChatGPT—has suddenly become the most heavily scrutinized punctuation mark on the internet. It is not, however, a recent invention, tracing its roots back to the printing press of the 15th century. As the printing press made the written word accessible to the masses, replacing painstakingly hand-copied manuscripts, a new visual syntax was required. Printers needed a way to visually signify a sudden break in thought, a dialogue shift, or an interruption that a comma simply could not bear. The em dash was born out of pure mechanical necessity. There is bitter irony here. The punctuation mark born during the first era of literary automation is now being killed by the latest one. Today, the widespread usage of LLMs forces me to systematically erase it from my own drafts just to avoid the dreaded label of "AI slop"—a label that would immediately render the actual content of my writing meaningless. Formative suspensions</h2> Growing up, I was a voracious reader. I still remember coming home in the first grade one day to find that my dad had brought me back a massive encyclopedia from one of his business trips. By the fourth or the fifth grade, my taste had expanded from facts covered in encyclopedias and into the mysteries of Hardy Boys and Nancy Drew. As I continued to dabble in new niches, I stumbled upon the —</code> character. This, to me, was a fascinating language mechanic, not often seen but always elegant—and flexible—in its usage. "How fascinating", I remember thinking, once I started to take notice of it. And so, this elder cousin to the hyphen—whose name I would not learn for years to come—became an obsession. The imitation game</h2> I learnt the craft of writing primarily by reading voraciously, attempting to mentally capture a frame of reference for the passages I found elegant, and then recreating that feel in my homework, assignments, and the occasional short story or diary entry. This practice yielded some recognition and helped me win a few writing competitions in school—most notably a rank of around 1150 in an International English Olympiad when I was 15. All I did then—and what I still attempt to do in my day job today—is emulate the authors I admire. Nowadays, my reading material largely consists of technical blogs or documentation material. The practice of absorbing and replicating the rhythm of good technical writing is serving me well. I certainly cannot replicate James Clavell's rich, detailed prose that flows effortlessly across entire chapters, making you want to be a part of the world he cast so vividly. I have reread the ending of Shogun</a> twice within a year of finishing the novel, and what I wouldn't give to forget the narrative to be able to go and experience it afresh. However, as a saving grace, I can at least imitate that sublime language for my internal monologues. Yet, this very essay is an anomaly. I have not undertaken a written, reflective commentary like this in ages. The last time I wrote something along these lines—rather than merely thinking it—was two or three years ago in a briefly maintained personal diary. Here, I am not trying to optimize for readability scores or technical precision. I am mostly trying to let the words—and as is apparent, the em dashes—flow exactly as they come (with intense revising, of course; I am not fooling anyone). C for comma, and compromise</h2> To clarify, I have been purposefully liberal with my usage of the em dash in this piece—where else would I use it with carefree abandon if not here? I primarily use it to “expand” a topic, injecting sudden, additional context into the current narrative thread. But for my technical blogs today, I have to be cautious in how I use it. I flatten my sentences, relying on the unassuming comma to do the heavy lifting. I typically begin sprinkling em dashes throughout my text only after the initial few paragraphs, by which point the reader is (hopefully) invested enough, and fully convinced that a human actually wrote the piece, and not a bot. To be clear, this isn't a rejection of the technology itself. I actively rely on AI for content review, validating logical correctness, and automating scoped changes to content that I am taking stewardship of. Not doing so would mean losing out on a tool that is exceedingly beneficial when engaged with productively. And so, for me now—as someone whose primary goal is to share knowledge clearly and build trust without distraction—the (em)ighty have fallen. The landscape of writing has shifted, the algorithms have claimed my favourite punctuation mark, and there is little I can do about it. Creating an AI-Powered Document Translation Workflow 2025-04-19T00:00:00+00:00 Introduction</h2> After a 3-year break from learning Spanish, I decided to find a fun and efficient way to reconnect with the language -- creating an AI document translation app</a> that generates bilingual documents, readable from my Obsidian-inspired Markdown Viewer web app. Both applications run on my VPS, the Markdown Viewer being publicly exposed via Caddy. The Translation Structure</h2> The following is the output document’s translation structure: Spanish text</li> original English text</li> Spanish text</li> original English text and so on until the end of the text</li> </ul> The structure ensures that I am able to maintain a frame of reference to the original tone and language while I am reading the Spanish text. This structure allows the formation of reference points between the flow of the Spanish text versus the English written language, and helps grasp tone and meaning effectively. I’m certain there are better ways to learn the language but this has been quite interesting thus far. While I’m sure this is not the most efficient way to learn the language, I’ve found this approach to be quite engaging. The fact that I’m learning through something I built also gives me motivation. The Translation Workflow</h2> The app has Docker images for web API and CLI versions, though I primarily use the CLI version. There are only three inputs: url</code> of the webpage to be translated (mandatory),</li> name</code> defines the name to save the document by, defaulting to the OpenGraph page title if none is provided, and</li> cache</code> defines whether the crawler should use use cached webpage data for the given URL, defaulting to True</code>.</li> </ul> The web crawler extracts the webpage content, which the LLM then translates using the above structure, and the resultant document is saved to the output directory. Crawled data and its translation are also persisted in a Postgres database. You can check the core application logic here</a>. Web Crawler Configuration</h3> Crawl4AI</code> is my web crawler of choice, it crawls the given URL, prunes the content and returns a clean Markdown result. Although its dependencies increase the Docker image size, the trade-off is acceptable since the crawler runs locally, and instantiates a headless browser session. It also caches previously crawled pages, fetching content instantly for repeated URLs. Sample Crawl4AI</code> output [INIT].... → Crawl4AI 0.5.0.post4 [FETCH]... ↓ https://example.com... | Status: True | Time: 1.22s [SCRAPE].. ◆ https://example.com... | Time: 0.008s [COMPLETE] ● https://example.com... | Status: True | Total: 1.23s </code></pre> Translating the Crawled Data</h3> The choice of OpenRouter</a> as the LLM provider unlocks access to hundreds of LLM models with a single API key. This allowed for rapid experimentation to find the right model for my needs. I currently use Google’s Gemini 2.0 Flash-Lite for its affordability and speed, while handling effective translation and extraction of relevant content from the crawled text body. It can however, occasionally fail to structure the translated content under headings properly, moving the text body under the English heading instead. This hasn’t bothered me in practice, and I believe this can be corrected with further tweaking of the LLM prompts. Brief on AI Usage and Observability</h3> PydanticAI</code> was quick to setup and use with OpenRouter for my straightforward use case, and it is apparently easy to configure for more complex tasks in the future. Integrating Logfire</code> with PydanticAI for agent observability was as easy as passing a boolean parameter to the Agent</code> object instance. Logfire itself requires just a few lines of code and an API key acquired from its web dashboard. Observability data will help keep track of draw comparisons between usage costs of various models, when translating particular documents. Token usage and cost for a long, text-only article, observed in Pydantic Logfire Consuming the Output</h3> I trigger the application using Docker as a removable container, using something like docker run --env-file .env.deploy --network app-network --rm dhruvahuja/py_ai_translator_cli -v ~/docker_data/public_markdown:/app/markdown 'https://www.example.com' </code></pre> The app-network</code> Docker network connects the app to a shared Postgres instance, which stores crawled content, translated outputs, and metadata for future reference. A simple Markdown Viewer Node webapp</a> scans the output directory and lists all translated documents along with #public</code> tagged notes, making them accessible via a clean web UI. Sample document output in the Markdown Viewer app, where example.md</code> is the translated document Conclusion: AI For the Win</h2> I have enjoyed working on the application and the surrounding tooling that I’ve built to accomplish my goals. Having AI services such as v0.dev is a godsend for creating designs and POCs, like the Markdown Viewer that emulates Obsidian’s look-and-feel. AI is enabling us to build at a breath-taking pace, with increased emphasis on the desired outcome rather than the boilerplate and particulars of a language. In this case, I did not have to learn Node syntax to prepare a functional script, while acutely reviewing and understanding the rationale behind the code. I similarly wrote a toy Go app to backup my VPS’ crucial data to S3 with certain conditions, in a couple hours. Finally, I’ll be relearning Spanish through content I enjoy. I am deferring improvements to the code or the features, as it’s time to actually use I’ve built! My Quest to Find the Perfect Self-Hosted Notes App 2025-02-11T00:00:00+00:00 Backstory</h2> My search started with me looking for a good open-source notes app as I realized that my UpNote premium subscription was costing me the same as my VPS per year. I also felt excited to scratch the itch to tinker with technology, which I’ve had for quite some time now. My two main requirements were that the app needed to support all Markdown features while preferably offering some synchronization method. It also needed to have either an Android app or work well as a PWA so that I could jot down ideas or update existing TODOs and notes quickly. How I was going to backup my notes if sync wasn’t available, was a problem I intended to solve later. What about Obsidian, you might ask</h2> Now you might ask me what’s wrong with using Obsidian, as there are ways to sync notes for free. I tried SyncThing and found that I didn’t like the idea of merge conflicts resulting in two versions of the same file when editing from phone. I still use it daily for neat and structured work notes. Also, vim mode feels great to use (even though I know just the basics of vim). I take rough notes during meetings and discussions in Apple Notes, which I then rewrite and add to Obsidian or mostly directly to Notion if they need to be documented or tracked (which is almost always the case). Apps I’ve tried</h2> Affine - was the first app that I tried, seemed promising as a free alternative to Notion, which I use regularly at work and quite like. However, it kept using cloud storage, which from what I understood, should not have been the case. This irked me out a lot, and I stopped using it then and there.</li> Outline - was the one I was very interested in, being another Notion-like knowledge base app. I tried a few approaches and spent a lot of time trying to make it work on-and-off over two weeks, but couldn’t. At this point I was quite frustrated and was reaching the end of my tether and dropped it.</li> UseMemos - was the first breakthrough of sorts, something that was just worked, was self-hosting oriented and could be easily used through a PWA. I had started migrating few of my notes before feeling the lack of a folder hierarchy.</li> nb - is the next app that I found, a terminal-based all-in-one app that boasts everything that you could ask for in a notes app. The sync was perfect, you make a change and you see the git sync take place immediately.</li> </ul> nb</code> was great, however, this being CLI-only was a major blocker. I was ready to use it in tandem with useMemos</code> for the time being and thats what I decided to do... The transition to SilverBullet.md</h2> Meanwhile I had mentioned my experience and requirements over to the guys at TEO Discord, and got a great recommendation from the always-reliable Satya Bhat</a>, who recommended Karan’s very-well written article on Self Hosting Outline</a>. It featured a workaround for the OIDC based login setup that had blocked me earlier. I was going to go along with it, when Karan himself recommended SilverBullet.md</a> to me, which had seemed interesting. I tried it out and immediately fell in love. The app just worked great out of the box, had a good feel to it and was intuitive to use. The command and open page “quickbars” make it snappy to trigger a command, example git sync or change to a separate file, like one would do with Obsidian. About git sync, it required some work but what is maybe an hour of setup for a tool you’re going to be using for a long time. I had to enable the git</code> and GitHub</code> plugins, provide a git repo and a Personal Access Token to enable sync. SilverBullet was unable to push to my empty repo I’d just created, so I entered the container and set the remote, and that was it. It is quite lightweight, consuming ~350mb of system RAM at the time of writing. Did I also mention it has vim mode and the font looks cool? Yeah, I’m hooked. I’ve written this article itself using SilverBullet, and it has been a great experience: The end (for now?)</h2> I am hooked on SilverBullet. I am not a power-user making graph-like notes or interlinking them together, as such I feel like it offers me all the features that I would want. I will miss UpNote’s share notes feature available to premium members, which syncs your shared notes in real-time, has been particularly useful for me when gathering feedback on work-in-progress blog posts. Overall I’m really happy with my choice, and it seems thus far to be well-worth the time investment. I would whole-heartedly recommend it to anyone that has similar requirements as mine or wants to try a self-hosted option. That’s it, thanks for making it till the end! A Story of Optimizing Mongo DB Writes 2024-05-21T00:00:00+00:00 Introduction</h2> I am developing an application for the game Path of Exile, that will predict item prices based on the item quantity and the item price history throughout the season. It is a straightforward implementation that updates the prices for items at a fixed frequency, and requires items and their categories to be pre-populated in the database. I am running my MongoDB server on the Atlas Free Tier, hosted on AWS. The core flow is as follows: there are several categories for whom we already have general information prepared, we first create ItemCategory</code> documents with this information for each category. Then we fetch data for all items belonging to that category. The poe.ninja</a> website caches its API responses and we’re able to quickly fetch the desired data even with relatively large responses. We initially made all these API calls in a loop, and the whole process was quite smooth as the response time is always quick. Upon getting the data and parsing each entity in the response array into Pydantic models, we then map the data in the form <category_name: item_data></code> where item_data</code> is the list of items we fetched from the API. Do keep in mind that this flow will change as optimize the script down the line. Pydantic & Its Usage Here </h2> We create either CurrencyItemEntity</code> or ItemEntity</code> Pydantic model instances for each entity in API responses, based on whether it belongs to Currency</code> or the other Item</code> type, as items in the Currency</code> category have a separate API response schema. Pydantic helps maintain data integrity and validates the response data, making it easier to deal with potentially unstructured third-party data (although the APIs in this case are very consistent). There would definitely be an additional overhead for parsing the item data into a Pydantic model instance for each entity, but being able to enforce schema for third-party data in this case, and getting consistent type hint support is well worth it. Its performance has also been vastly improved with the version 2.0 release that happened late last year. The Naive Approach: Single Insertions</h2> The code for the naive approach and the first iteration of the script is available here</a>. Here we are iterating over all categories, getting their response data and mapping them into the hashmap with category name</code> as key, and the data array</code> as value. It does not take much time to gather data for 31,000+ items, as mentioned above due to the quick API responses. Calling save_item_data</code>, It takes us an average of 1216 seconds or 20 minutes 16 seconds to parse each entity’s data, create and insert Item</code> document instances and save them to the database one-by-one. I think this time is acceptable since the script meant to be run rarely, however it is practically very slow and not convenient. This makes extending the script or re-running it a chore. I am also interested in knowing how much time we can shave off from this, especially since there is a very simple optimization available. Memory usage for this approach would be high too, since we’re loading all item data entities in memory and have two objects for each entity. We will look into memory management after improving the execution time. Each save call requires network round trips between the app and the database, and database processing time. These accumulate rapidly as we save a large number of documents one-by-one. The Good Approach: Bulk Insertions</h2> The modified script using approach is available here</a>. I found using insertMany</code> for bulk-inserts the most common and the most impactful approach, when I looked for improvement advice. Pushing all DB instances to an array and bulk-inserting them all at once, took us just ~10.7 seconds! This is an incredible improvement and should be the first choice if you need to insert multiple documents. The problem here is the memory usage, which peaks at roughly 350MB and only drops towards the end of the script, where we see memory being released. This can be verified by simply restricting the maximum length of the item_data</code> array to 10,000, which would restrict the number of accessed item data records of the BaseType</code> category, which has contains much more items. Making this change reduces the peak memory usage to ~285MB. We can make one more improvement which will reduce both the memory usage and execution time, but requires a significant code refactor. The Better Approach: Producer-Consumer Pattern</h2> The mostly overhauled script using this approach is available here</a>. We rewrote the main functions, moved API calls to their own functions, added more logging statements, handled errors and wrapped the async functions into async Task</code>s. These pass data using dedicated Queue</code>s and run until they get the termination signals using sentinel values. Implementing Async Producer and Consumers means we now process information faster, by using different async tasks to concurrently get API data, parse that data, and save documents in bulk in the database. This coordination allows us to reduce the time taken further to about 9 seconds, and all the tasks finish execution almost one after the other. This is an improvement of about 1.7 seconds over the bulk-insert implementation. We also witness a big drop in memory usage, with the peak memory usage being ~271MB, or an improvement of ~ 22.6% over the previous consumption of 350MB. These are fantastic results, in my opinion. Conclusion</h2> This was a journey where I got hands-on with some general performance improvements for database writes and also implemented the common but very effective Producer-Consumer design pattern. I am sure that there are things that I missed and certain aspects that can be handled better, I’ll be keeping an eye out for any improvements. It was a great learning and experimental experience for me, and I hope that this made a good read for you. Please do not hesitate to email me</a> if you wish to discuss anything. I will be adding comments functionality to the site soon. Tag-Based Python CI/CD Pipeline 2024-03-05T00:00:00+00:00 Introduction</h2> I recently setup a CI/CD pipeline using GitHub Actions</a>, to automate code quality management, testing and Docker image deployment for my Python webapp</a>. The CI workflow triggers on every commit to the main</code> branch and formats, lints and tests the code. It uses a Redis service container</a> since the integration tests call the API endpoints, which use a caching layer before accessing the database. It also uses an action step to debug failures. The CD workflow runs on new tag pushes to the repository. Both workflows can also be run manually. Let’s get started with the setup. Initial Setup</h2> Create a Docker Hub repository to push the images to, and generate a read-write</code> scope Access Token for use with the workflows. Copy the token for use in the next step. Next, setup environment secrets so that our application can access these values during the testing step. Go to the Settings</code> → Secrets and variables</code> → Actions</code> panel in the GitHub repository and define the any repository secrets required during the workflow’s execution. Also define the Docker username and password secrets here. Use the access token generated above for DOCKER_PASSWORD</code>. Creating the CI Workflow</h2> Create a .github/workflows</code> folder in your local codebase and a ci.yml</code> file, adding the following code at the top of the file: name: CI on: push: branches: main workflow_dispatch: {} concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true </code></pre> This defines that the CI</code> workflow runs only when code is pushed to the main</code> branch. workflow_dispatch: {}</code> allows us to run the workflow manually from the Actions</code> page. Our concurrency</code> configuration ensures that the workflow’s runs are grouped together under one Git reference value and that only one run happens at a time. If a workflow is underway and another is triggered, the current run is cancelled in favour of the newer run. Next, define the list of environment variables required by the application like so: env: DB_URL: ${{secrets.DB_URL}} JWT_SECRET_KEY: ${{secrets.JWT_SECRET_KEY}} AWS_ACCESS_KEY_ID: ${{secrets.AWS_ACCESS_KEY_ID}} AWS_SECRET_ACCESS_KEY: ${{secrets.AWS_SECRET_ACCESS_KEY}} AWS_REGION_NAME: ${{secrets.AWS_REGION_NAME}} SQS_QUEUE_NAME: ${{secrets.SQS_QUEUE_NAME}} S3_BUCKET_URL: ${{secrets.S3_BUCKET_URL}} S3_BUCKET_NAME: ${{secrets.S3_BUCKET_NAME}} S3_LOGS_FOLDER: ${{secrets.S3_LOGS_FOLDER}} REDIS_HOST: localhost </code></pre> We define environment variables by reading the repository secrets we set in the initial setup section, with the exception of REDIS_HOST</code>, which is set to localhost</code> to enable our application access to the Redis service. Now comes the main part for the CI logic, the job itself: jobs: build: runs-on: ubuntu-latest services: # Label used to access the service container redis: image: redis # Set health checks to wait until redis has started options: >- --health-cmd "redis-cli ping" --health-interval 10s --health-timeout 5s --health-retries 5 ports: - 6379:6379 steps: - name: Checkout uses: actions/checkout@v4 - name: Setup Python uses: actions/setup-python@v4 with: python-version: "3.11" cache: "pip" - name: Install PyCurl Dependencies run: sudo apt-get update && sudo apt-get install -y curl libcurl4-openssl-dev build-essential libssl-dev - name: Install Dependencies run: python -m pip install --upgrade pip pip install -r requirements.txt - name: Test code run: pytest . -s -v -W ignore - name: Check Code Formatting run: ruff format --line-length=120 --check . - name: Check Code Linting run: ruff check . - name: Setup Tmate Session if: ${{ failure() }} uses: mxschmitt/action-tmate@v3 </code></pre> Let’s walk through the job’s specifics, step-by-step. The Redis service logic sets up a Redis container with health check options to ensure that the workflow waits for it to boot up, and exposes port 6379</code> to make it accessible to the application when we run the tests. Checkout</code> makes the repository’s code available to the workflow, and Setup Python</code> setups the specific Python version — 3.11</code> in our case — and caches the dependencies installed by pip</code> to make future workflow runs faster. Install Pycurl Dependencies</code> installs the dependencies required by the pycurl</code> Python library on Ubuntu. The following step installs the Python dependencies used by our application. The code testing step runs the pytest</code> test suite gathers and runs all tests in the current directory. My project has a few unit tests and integration tests for each API endpoint. The -s</code> flag outputs any Python print statements to the stdout stream, and -v</code> runs the tests in verbose mode, giving us a detailed overview of the ongoing tests. I have added -W ignore</code> to ignore the warnings emitted during the execution of the tests, primarily to help avoid the Pydantic v1 deprecation warnings</code> issued for third party libraries. I am using Ruff</code> as the formatter and linter of choice, it is very fast and I feel that it has good linting rules without being overly restrictive. It is easy to setup formatting, lint and type checks in editors and is a one-time setup and I feel that it really helps keep the codebase maintainable in the long run. The next two steps check for formatting and lint errors in the code and stop the workflow in case of any errors. This ensures that contributing developers adhere to Ruff’s code quality standards. The last step is optional, and only runs if any of the previous steps fails. It allows us to ssh into the currently ongoing workflow session to check the environment and debug issues. Be careful though, it kept running for quite a while since I forgot to cancel the workflow run manually. I am not sure if it has a time limit or it keeps running indefinitely. Creating the CD workflow</h2> The CD pipeline is quite straightforward: name: CD on: push: tags: "v*" # allow manually triggering this workflow workflow_dispatch: {} concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true jobs: deploy: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v4 - name: Log into Docker Hub uses: docker/login-action@v3 with: username: ${{secrets.DOCKER_USERNAME}} password: ${{secrets.DOCKER_PASSWORD}} - name: Get Latest Tag id: latest-tag uses: "WyriHaximus/github-action-get-previous-tag@v1" with: fallback: latest - name: Build and push Docker image uses: docker/build-push-action@v5 with: push: true tags: dhruvahuja/backend_burger:${{ steps.latest-tag.outputs.tag }} labels: ${{steps.latest-tag.outputs.tag}} </code></pre> We define the workflow to either run manually or when a new tag prefixed by v</code> is pushed to the repository, example. v0.0.1</code>. Checkout</code> is required to allow getting git tag in the third step. The next step reads the Docker username and password from repository secrets and logs us into Docker Hub. Get Latest Tag</code> reads the tag which was just pushed, if the workflow was triggered by a tag push, otherwise defaulting to latest</code>. The final step builds the Docker image with the version tag and label, and pushes it to the Docker repository URL, defined in the tags</code> directive. In this case, dhruvahuja/backend_burger</code>. Conclusion</h2> That’s it, our CI/CD pipeline is ready! There are Actions available for all sort of use-cases, and you can remove or add steps according to your needs. For example, you may choose to ssh into a server after the Build and push Docker image</code> step to pull and run the new image. I did not add this particular step since I did not have a need for it at the moment. I chose the tag-based approach for the deployment process since I wanted to deploy new images only on specific milestones, which I can manage with version tags. Writing Rust Bindings for My Python App 2023-11-06T00:00:00+00:00 Introduction</h2> spoti-dl</a>, a Python-based CLI song downloading tool was the first “proper” application that I developed. It acted as a proof-of-concept of my programming skills as a self-taught developer, and helped me land my first job. However, it lacked some basic features, mainly- no parallel downloads for albums and playlists. I recently added a few new features and re-wrote its core functionality in Rust, as I have been enjoying working with Rust’s robust type system, compiler-level error handling and syntax. Development</h2> Development was relatively smooth for the most part, as the app logic is straightforward — you accept and parse the input Spotify link, the CLI flag parameters and process downloads. I figured out general things by googling and/or through some experimentation, such as the trait implementations to parse CLI flags from String</code>s into enum</code>s and vice-versa. The lazy_static</code> macro helped me allocate a static HashSet</code> containing disallowed characters for files and folder names, on runtime. I also became more comfortable with bound traits and experienced the power of generics. I was able to use the following function across all of my download flows, as it accepts any input P</code> that can be referenced as Path</code> and any input S</code> that can be converted into a String</code> type: pub fn add_metadata<P, S>( file_path: P, album_art_path: P, simple_song: spotify::SimpleSong, album_name: S, ) where P: AsRef<Path> + Debug, S: Into<String>, {...} </code></pre> I mainly struggled when implementing the async logic to download songs in parallel, due to my inexperience with writing async code in Rust. I had to spend a lot of time working with the compiler’s restrictions and Tokio’s</a> ’static + Send</code> requirements for spawning tasks, as its work-stealing scheduler model means that a task running in one thread could be picked up by another thread. I used tokio::task::block_in_place</code> to wrap the add_metadata</code> function call as the lofty</a> crate does not support async. I added a CLI flag, allowing users to specify the number of tasks to use to process parallel downloads, and used batch downloads of 100 songs for playlists, as they can contain several thousands of songs. The following is the core async logic for parallel downloads — calculate songs to be downloaded by each task, make Arc</code>s to pass cheap, shareable clones for certain values, chunk the list of songs and create and wait for the spawned tasks to finish downloads: let parallel_tasks: usize = if album.songs.len() >= cli_args.parallel_downloads as usize { cli_args.parallel_downloads as usize } else { album.songs.len() }; let songs_per_task = album.songs.len() / parallel_tasks; let remaining_songs = album.songs.len() % parallel_tasks; let cli_args = Arc::new(cli_args); let album_art_dir = Arc::new(album_art_dir); let album_name = Arc::new(album.name); let mut handles = Vec::with_capacity(parallel_tasks); let mut start = 0; for i in 0..parallel_tasks { let mut end = start + songs_per_task; if i < remaining_songs { end += 1 } let songs_chunk = &album.songs[start..end]; let handle = tokio::spawn(download_songs( file_path.clone(), cli_args.clone(), album_art_dir.clone(), album_name.clone(), songs_chunk.to_vec(), )); start = end; handles.push(handle) } for handle in handles { handle.await?; } </code></pre> Tooling</h2> I dropped Poetry</a> as it would not be compatible with the Rust bindings and used simple virtual environments for dependency management, and Twine</a> for distributing built wheels. Pyo3</a> acts as the bridge between the parent Python code that calls a single exposed Rust function and enables all the inter-op between the two systems. Maturin</a> compiles the Rust code into a Python library, and also compiles both codebases into a distributable Python wheel. The following is a list of changes I had to make in my Cargo</code> and pyproject</code> TOML files, to ensure that the build process and pip</code> installed package worked as intended: Maturin</code> did not recognize the project as a mixed Python-Rust project, hence did not include Rust code in the distributable Python wheel. Setting lib.name</code> table’s value to match Python source directory (spotidl</code>) in Cargo.toml</code> fixed this error. </li> pyproject.toml</code> required several modifications — I needed to set the project.scripts</code> value to spoti-dl = "spotidl.main:main"</code>, partially because the project name (spoti-dl</code>) and Python source directory names were different. I also added the python-packages = ["spotidl"]</code> value under tool.maturin</code> to ensure its inclusion during the build process. I also had to add my dependencies and relevant project metadata in their apt sections, after dropping Poetry</code>. </li> Maturin</code> compiles the Rust code as a library inside our Python source directory. It adds an underscore _</code> to the library’s name by default, which is quite confusing. I rectified this by configuring the module-name</code> value under tool.maturin</code>. </li> </ul> I faced several problems when attempting to build wheels for Linux using Docker, on my M1 MacBook. I must have easily spent 15-20 hours trying to get the openssl-sys</code> crate to compile as it was the single point of failure, using both the python manylinux</code> and maturin</code> Docker images. I tried to integrate a CI/CD setup using GitHub Actions too, but to no avail, as the crate kept failing to compile. You can check the graveyard of my CI’s failed runs here</a>. Eventually I had to settle for manually compiling wheels on Linux, Mac and Windows and copying them to a folder before publishing them with Twine</code>. Conclusion</h2> This was a rewarding experience for me, as I dealt with efficiently processing large amounts of data and sharpened my skills with Rust and Tokio</code>. I witnessed a 20-25% speed increase and 50% less memory consumption in my Rust code when downloading a single song. The development process was smooth as Pyo3</code> and Maturin</code> are very well-documented and provide convenient APIs, make it incredibly easy to get started with writing FFIs for Python. Implementing a Naive Buffered Queue in Rust 2023-09-06T00:00:00+00:00 Introduction</h2> O’Reilly’s Programming Rust</code> book walks us through optimizing a part of a pipeline, in Chapter 19 Concurrency</code>. It explains how a channel-based pipeline can encounter slowdowns and high memory usage if one of the consumer threads is much slower than one of the producer threads. The producer keeps adding tasks to the queue, but the consumer is unable to consume them at a satisfactory pace. The queue will have a large amount of unconsumed data causing memory spikes. Defining fixed capacities will lower memory consumption in applications without affecting the latencies since the consumer already consumes at its own fixed pace. I had known about queues but had never thought about them in a larger scope, so I thought attempting a custom implementation would be a good way to learn more. I received a lot of help from the Rust community for this project, allowing me to better understand the concepts and improve my code :) Overview</h2> We will walk through the implementation of a simple multi-threaded, blocking, buffered queue. The Producer thread will push elements till the queue is at capacity, and block until the queue has space again. Similarly, the Consumer thread will consume elements till the queue is empty, and block until it has elements again. We do not persist the threads once the input stream is expended. Declaring our Types</h2> We can create a new project with cargo new buffered-queue-rs</code> and put our queue logic in src/lib.rs</code>, marking all code inside the file as library code. This makes it accessible to the whole project by importing it with the project name specified in the cargo new</code> command. Add the following imports to the file: use std::collections::VecDeque; use std::sync::atomic::{AtomicBool, Ordering}; use std::sync::{Arc, Condvar, Mutex, MutexGuard}; </code></pre> Next, we will define the types for our buffered queue implementation: pub struct Producer<T>(Arc<BufferedQueue<T>>); pub struct Consumer<T>(Arc<BufferedQueue<T>>); pub struct BufferedQueue<T> { data: Mutex<VecDeque<T>>, pub capacity: usize, pub is_full: Mutex<bool>, pub is_full_signal: Condvar, pub is_empty: Mutex<bool>, pub is_empty_signal: Condvar, pub elements_processed: AtomicBool, } </code></pre> These are generic</a> types, signified by the type parameter <T></code>, and can be used with any type as we have not defined any constraints on the type T</code>. Producer</code> and Consumer</code> follow the NewType</a> pattern, allowing us to specify special behaviour on the wrapped type. It will help us separate producer and consumer concerns. All the defined types use an Arc</a>, a special pointer type that enables cheap shared access to data. It also allows sharing its pointer values across threads, even though the wrapped value might not be shareable. It maintains a reference counter for each reference active in memory, similar to Python objects. Our internal queue implementation data</code> is a double-ended queue, held by a mutex to prevent data inconsistencies and enforce exclusive data access. capacity</code> is the user-defined maximum capacity for our queue. usize</code> data type ensures that the value cannot be negative. is_full</code> and is_empty</code> indicate the queue’s current state. They will be used by the is_full_signal</code> and is_empty_signal</code> Condvars</a> to allow the producer and consumer threads to wait until the queue is in their desired state. elements_processed</code> is an AtomicBool</a> and is thread-safe. The Operation</code> enum type will signal the queue’s state updates to listening threads. It maps to the queue’s push and pop operations: enum Operation<'a> { Push { is_full_flag: MutexGuard<'a, bool> }, Pop { is_empty_flag: MutexGuard<'a, bool> }, } </code></pre> Acquiring the lock on a mutex returns a MutexGuard</a>, a thin wrapper around the value held by the mutex. The lifetime specifier</a> <’a></code> in the type definition indicates how long the boolean flags are going to stay in memory. They are now associated with the enum variants and their held locks will be unlocked when the enum variants go out of scope. We can see Rust’s powerful enums here, as we can add data on individual variants like we would with a struct. Defining Producer and Consumer Logic</h2> Producer and consumer have a similar logical flow. Both have 2 methods, the len</code> method is common to both types and wraps a call to BufferedQueue</code>‘s len</code> method. Producer</h3> Producer’s implementation is: impl<T> Producer<T> { pub fn push(&self, value: T) { let mut queue_is_full = self.0.is_full.lock().unwrap(); while *queue_is_full { queue_is_full = self.0.is_full_signal.wait(queue_is_full).unwrap(); } let mut queue = self.0.data.lock().unwrap(); queue.push_back(value); println!("pushed element"); self.0.signal_queue_changes( queue, Operation::Push { is_full_flag: queue_is_full, }, ); } pub fn len(&self) -> usize { self.0.len() } } </code></pre> self.0</code> accesses the Producer’s first value in the tuple – the buffered queue Arc, to access its fields and methods. We first get the queue_is_full</code> boolean value and check whether the queue is full. Code execution will be paused until the queue has space and queue_is_full</code> equals false</code>. The wait</code> method takes a MutexGuard and atomically releases the lock. This enables other threads to update its value. It re-acquires the lock before returning. We access the internal queue if there is space, push the new element and call the signal_queue_changes</code> method that we will define on BufferedQueue</code> later. We will also implement the Drop</a> trait, which will perform cleanup after our producer is out of scope: impl<T> Drop for Producer<T> { fn drop(&mut self) { self.0.elements_processed.store(true, Ordering::SeqCst); } } </code></pre> We set elements_processed</code> value to true</code>, indicating that the producer has processed all its elements and is going out of scope. The Drop</code> trait ensures that this implementation detail remains associated with the producer. The store</code> method requires a memory ordering, which defines how application memory is organized and ensures that our code avoids race conditions and improper data access across threads. We use the strongest possible ordering, SeqCst</code>. Consumer</h3> Consumer’s methods are as follows: impl<T> Consumer<T> { pub fn pop(&self) -> Option<T> { let mut queue_is_empty = self.0.is_empty.lock().unwrap(); while *queue_is_empty { if self.0.elements_processed.load(Ordering::SeqCst) { return None; } queue_is_empty = self.0.is_empty_signal.wait(queue_is_empty).unwrap(); } let mut queue = self.0.data.lock().unwrap(); let popped_element = queue.pop_front(); println!("popped element"); self.0.signal_queue_changes( queue, Operation::Pop { is_empty_flag: queue_is_empty, }, ); popped_element } pub fn len(&self) -> usize { self.0.len() } } </code></pre> pop</code> returns an Option<T></code> meaning it will return an enum variant Some(T)</code> from the front of the queue, or None</code> if the queue is empty. We wait for the producer to add elements if the queue is currently empty. Our implementation guarantees that the queue will only pop an element from front of the queue if there is at least one element. We only return None</code> once elements_processed</code> is true</code>, signalling that we can finish our execution. Defining BufferedQueue Logic</h2> We will first write a function to create a new buffered queue: pub fn buffered_queue<T>(mut capacity: usize) -> (Producer<T>, Consumer<T>) { if capacity < 1 { eprintln!("capacity cannot be lower than 1, defaulting to 1..."); capacity = 1 } let buffered_queue = BufferedQueue { data: Mutex::new(VecDeque::with_capacity(capacity)), capacity, is_full: Mutex::new(false), is_empty: Mutex::new(true), is_full_signal: Condvar::new(), is_empty_signal: Condvar::new(), elements_processed: AtomicBool::new(false), }; let data = Arc::new(buffered_queue); let producer = Producer(data.clone()); let consumer = Consumer(data); (producer, consumer) } </code></pre> buffered_queue</code> takes a capacity and returns a tuple of Producer and Consumer types. It uses 1 as default if the capacity is 0, wraps the buffered queue value in Arc for cheap referencing and thread-safety, makes a reference copy and passes the Arc instances to Producer and Consumer types. Now we will implement its methods: impl<T> BufferedQueue<T> { fn len(&self) -> usize { let queue = self.data.lock().unwrap(); queue.len() } fn signal_queue_changes(&self, queue: MutexGuard<'_, VecDeque<T>>, operation: Operation) { let is_empty = queue.len() == 0; let is_full = queue.len() == self.capacity; match operation { Operation::Push { mut is_full_flag } => { let mut is_empty_flag = self.is_empty.lock().unwrap(); if *is_empty_flag { *is_empty_flag = false; println!("set is_empty to false"); self.is_empty_signal.notify_all(); } if is_full { *is_full_flag = true; self.is_full_signal.notify_all(); println!("set is_full to true"); } } Operation::Pop { mut is_empty_flag } => { let mut is_full_flag = self.is_full.lock().unwrap(); if *is_full_flag { *is_full_flag = false; println!("set is_full to false"); self.is_full_signal.notify_all(); } if is_empty { *is_empty_flag = true; self.is_empty_signal.notify_all(); println!("set is_empty to true"); } } } } } </code></pre> This method accepts the internal queue and operation enum types. queue</code> defines the double-ended queue value after acquiring its mutex lock. We match the operation variants and define their associated boolean values as mutable. Rust allows us to shorthand values if the variable name matches the field name, so we can write { mut is_full_flag: is_full_flag }</code> as { mut is_full_flag }</code> and so on. The method checks whether the queue’s state has changed: after an element Push</code>, whether the queue is now full and whether it was empty earlier, after an element Pop</code>, whether the queue is now empty and whether it was full before. It notifies waiting threads on the state changes if these conditions match, by calling the Condvars’ notify_all</code> method. Testing Things Out</h3> We can now test the functionality by creating a small simulation. Add the following imports to the top of the src/main.rs</code> file: use buffered_queue_rs::buffered_queue; use std::thread::{self, sleep}; use std::time::Duration; </code></pre> Write the following code in the src/main.rs</code> file and replace the existing main</code> function: fn main() { let (producer, consumer) = buffered_queue(3); let mut output = Vec::new(); let producer_handle = thread::spawn(move || { println!("initializing producer thread..."); for num in 1..=5 { let processed_num = num * num * num; // mock processing behaviour sleep(Duration::from_millis(250)); producer.push(processed_num); } }); let consumer_handle = thread::spawn(move || { println!("initializing consumer thread..."); loop { let Some(num) = consumer.pop() else { println!("exhausted queue, terminating consumer!\n"); return; }; // mock processing behaviour sleep(Duration::from_millis(400)); output.push(num); println!( "pushed to output num: {}; output_vec len: {}", num, output.len() ); } }); producer_handle.join().unwrap(); consumer_handle.join().unwrap(); } </code></pre> We initialize our producer</code> and consumer</code> values by calling buffered_queue</code>, and create a vector for the output produced by the consumer thread. Then we mark our threads with move</code>, meaning they will take ownership of any values used inside them. We use closures to write the thread logic inside the spawn</code> blocks. The producer thread iterates over a range of numbers, mocking input processing flow and pushes values to the queue. Meanwhile, the consumer thread processes values received from the pop</code> function, stopping when it receives None</code>, which is the signal to terminate execution. Finally, we receive return values of type JoinHandle</a> from the spawned threads and call join</code> on them in the main thread. This ensures that it waits for the other threads to finish before exiting. The unwrap</code> call will propagate any runtime errors in these threads to the main thread. Running cargo run</code> will output the following: initializing consumer thread... initializing producer thread... pushed element set is_empty to false popped element set is_empty to true pushed element set is_empty to false pushed to output num: 1; output_vec len: 1 popped element set is_empty to true pushed element set is_empty to false pushed element pushed to output num: 8; output_vec len: 2 popped element pushed element pushed to output num: 27; output_vec len: 3 popped element pushed to output num: 64; output_vec len: 4 popped element set is_empty to true pushed to output num: 125; output_vec len: 5 exhausted queue, terminating consumer! </code></pre> Conclusion</h2> This was a rewarding exercise for me, as it helped me get more familiar with Rust and concurrency concepts in general. You can find the full code for the exercise here</a>, there are some differences in the code shown here and in the repo. Thanks for reading my post, any feedback or advice would be appreciated! You can write to me at my email</a>. Making My First Open-Source Contribution 2023-06-11T00:00:00+00:00 Intro</h2> The title is a bit devious – it’s not my first open-source contribution per se. I have made a couple of documentation fixes but those don’t count. I just made my first proper, meaningful open-source contribution on June 9th, 2023. This is a small but still meaningful step for me in the right direction, as someone who wants to get going with making significant open-source contributions in the near future. My contribution to the theme I chose for my website was – I fixed a small issue on the light mode of the theme, and integrated a light-and-dark mode toggle button. Before diving into the nitty-gritty, let's go through some recent events that led to my contribution. I wanted to setup a personal website to use as a space for publishing my thoughts and ideas. Also, I felt that it was about time I setup a site after all. I have recently been learning Rust and have been enjoying the process so I thought I should go with a Rust-based implementation. Upon some basic research I found out about Zola, a Static Site Generator that is fast and easy to get going with, so the choice wasn’t a difficult one. Selecting the Theme and Making Changes</h2> So with my decision of using Zola finalized, I looked at the themes list on the site, and there’s one thing I must concede – the number of themes on display is not a lot. I found a couple of themes that I liked and decided to explore the one I found the most appealing as well as content-focused - Apollo</a> which is what the site’s current theme is based on. On fiddling around with the its code, I found out that the social icons weren't loading properly for the light mode. It used an inversion filter to invert their colours from black to white for the site’s dark mode, but the property was active even with the light mode. So I opened an issue regarding the same and forked the repository in the meantime. I also found Archie-Zola</a>, the theme on which Apollo is based, to have a pleasing neon-green primary aesthetic that I liked more. I also found out that it had a dark and light mode toggle button, which I then wanted to implement in my own fork as well. So I began working on making these changes. I fixed the problem with the icons’ disappearance relatively quickly, I just needed to move the relevant logic from the main file to the dark mode’s SASS file. Properly integrating the theme toggle button was much more complex and it required me to spend some time understanding the main visual logic of the two themes, and then writing the code, helping me learn about some core frontend styling logic. Making The Contribution</h2> My talks with Apollo's creator by this time had also gone well. He encouraged me to open a Pull Request. I then briefly updated him about my fork and asked him whether he would like to have the toggle button in Apollo and he had a positive response again. I then created a new branch in my fork, made the requisite changes and opened the PR</a>. It was reviewed and merged promptly, meaning I had made my first proper open-source contribution. My Experience</h2> Although this is just a small instance, I had a lot of fun with the whole thing. I had to read up on several less-explored topics. I also got familiar with how the theme operates internally, which has led to me making more tweaks for my website. I hope this can serve as encouragement for anyone reading this post, to take a look at open-source software and possibly support or take part in the development process. My plan now is to delve deeper into Rust, learn more about the language and hopefully make more contributions :D

Dhruv Ahuja

I owe my career to open-source communities. I'm not sure newcomers can say the same.

How the (Em)ighty Have Fallen—

Creating an AI-Powered Document Translation Workflow

The Translation Structure</h2> The following is the output document’s translation structure:</p> Spanish text</li> original English text</li> Spanish text</li>

The Translation Workflow</h2> The app has Docker images for web API and CLI versions, though I primarily use the CLI version. There are only three inputs:</p>

My Quest to Find the Perfect Self-Hosted Notes App

A Story of Optimizing Mongo DB Writes

Tag-Based Python CI/CD Pipeline

Writing Rust Bindings for My Python App

Implementing a Naive Buffered Queue in Rust

Making My First Open-Source Contribution