The vTual Project: Build Alpha v.0.1 Report, Final Part

It's been almost one month since the last update about Part 4 of vTual Build Alpha v.0.1 Report was posted. This blog post will summarize what has happened and the next course of vTual development and progress.

This blog post will be the final report from the development side of vTual version 0.1 before its release.

Ongoing Progress

There are numerous developments currently underway on the operational side of things.

One of the key focuses is the optimization of the backend, particularly concerning the implementation of external APIs, such as those from YouTube and Twitch.

The goal is to maximize the usage of these APIs without exhausting the quota before the reset period occurs.

The external APIs from YouTube and Twitch are crucial, serving as the backbone of vTual's operations in delivering up-to-date information about your favorite content creators activities.

When the API quota is depleted, data retrieval becomes impossible, which can significantly hinder or even stop the service's ability to provide timely updates.

While the Twitch API does not seem to offer the option for quota increases, YouTube appears to provide an opportunity for such requests. vTual submitted a quota increase application on October 20, and the process is still ongoing as stated on last report.

This procedure can be quite lengthy as evaluations are typically conducted on a weekly basis, and there are numerous factors that the YouTube team must assess to determine whether vTual meets the criteria for a quota increase. These factors include both the user interface and user experience, as well as the technical implementation.

vTual is planned for release once this process is completed. In the meantime, it will remain in a closed sandbox environment, where continuous optimizations will be carried out to enhance its performance and functionality.

This careful approach ensures that vTual will be well-prepared for its eventual launch, compared to a hasty decision.

Future Progress

As a programmer, skill development is essential, especially in a field where technological advancements occur at a rapid pace. A moment of complacency can lead to the emergence of new technologies within minutes.

This dynamic is also reflected in my relationship with vTual; whenever a new feature idea arises, I find myself needing to learn various new concepts to bring that idea to fruition.

During its development from early February to November 2024, I have absorbed a wealth of new knowledge while also striving to enhance my existing skills for greater optimization.

Throughout the development of vTual, particularly in version 0.1, I feel a sense of satisfaction and pride in the final product, as it aligns with the vision I have held since 2019-2020, the year when the idea for vTual was born.

However, as a programmer, I recognize that the codebase of version 0.1 is overly complex, suboptimal, and redundant.

Long-term maintenance will be challenging if we continue to rely on this codebase. While optimization is one potential solution to address these issues, I do not believe that a complete overhaul of the 0.1 codebase is a straightforward option.

The core problem lies within the very foundation of the codebase itself. Initially, vTual was developed with a "just make it work" philosophy, resulting in many modules being written without proper standardization. This includes arbitrary variable names, inefficient loops, and repetitive function definitions, among other issues.

It wasn't until around mid-August that the development of vTual began to implement the DRY ("Don't Repeat Yourself") principle, which ultimately led to wrapping each action into reusable modules and standardizing variable names, among other improvements. In short, the vTual 0.1 codebase is a blend of order and disorder.

While optimization on this scale is still feasible, it requires extra effort that may be equivalent to starting from scratch.

Given that the range of features offered by vTual is still relatively limited, I believe that a "rewrite" would be a much easier and more efficient option.

Not only would this approach allow for a more structured development process, but it would also enable the incorporation of many new elements that could enhance the latest version compared to the current 0.1 codebase.

That said, the decision to rewrite remains a topic of discussion. I have yet to determine the right time to embark on this journey—whether it will be realized in version 0.2 or triggered by specific case, such as the release of Laravel 12.

While there is no definitive timeline for this decision, I remain ambitious about fully optimizing vTual and adding new features in the future.