Code quality

Before creating the code, it is crucial to prioritize its quality.
It should be the foremost consideration in the development process.
To ensure code quality, we can utilize automated tools that help with code analysis.
However, it's important to note that automated tools may not cover all the necessary rules.
As a result, manual code review becomes essential to enforce coding standards.
Personally, I have dedicated significant time to code reviewing and checking for adherence to code style.
Additionally, I have employed Python to create additional code checks.
It is worth mentioning that not all rules can be checked automatically, requiring manual effort in certain cases.

Code documentation

"Now, hold on!" you might ask,
"Are we jumping straight into coding?"
My answer is a resounding "Nope".

Before embarking on the coding phase, it is vital to consider code documentation.
Since the FVA Software employs two programming languages, it is imperative to establish clear documentation rules for both C++ and Python.

Consequently, I have familiarized myself with documenting C++ code using Doxygen markdown and have gained proficiency in generating documentation based on Doxygen markdown.
It's quite remarkable how confident I am now in configuring Doxygen.

Implementation

Finally, we can proceed to the coding phase!
For the development of FVA Software, I have chosen the versatile QT library, which supports multiple operating systems such as Windows, macOS, and Linux Ubuntu.
Since the software requires a user interface (UI), I initially utilized QWidgets, including components like QWizard and QWizardPage.

However, I soon realized that employing QML would offer a more streamlined approach for UI implementation.
Therefore, my plan is to transition from QWidgets to QML.

I was pleasantly surprised by the ease of utilizing QT for creating a multimedia content player.
The flexibility of QT allows me to work with multiple UI languages.
To facilitate this, QT suggests using the following components:

• QTranslator;
• QtextCodec;
• Qlocale;
• QtextDecoder;
• QtextEncoder.

Additionally, I discovered that working with SQLite using QT is remarkably straightforward.

However, I later made the decision to switch from SQLite to CSV for data storage.

As my project involves working with two programming languages, I needed to establish a means of integrating Python code into the C++ application.

Last but not least, I acquired knowledge on how to create a riff parser, adding another valuable capability to the project.

History of internal metadata formats

The history of internal metadata formats in FVA Software reveals the evolution of how the software stored and managed metadata.
Initially, the metadata was kept at the file system level inside the Photo Album.
Each folder in the Photo Album had two files: folderDescription.json and description.csv.

The folderDescription.json file stored information that was common to all files within a folder, such as
device ID, tags, people, place, and event.

On the other hand, description.csv was used to store information about files under a folder that had different internal metadata.
It had columns for

• Name
• Place
• People
• Device
• WhoTook
• Description
• Scaner

However, this approach of storing metadata at the file system level had limitations in terms of flexibility and maintainability.
Adding or modifying a column in folderDescription.json or description.csv would require updating the entire photo album file system structure.

To address these limitations, the decision was made to move the folderDescription.json and description.csv files to an SQLite database.
The database schema was designed to store the same information as before.
During the import of new files to the photo album, the FVA software created SQL updates to the database.
These SQL updates were saved to be able to recreate the SQL at any time.
Although this approach improved flexibility and maintainability compared to the file system approach, merging folders in the photo album still caused significant changes in the SQL updates.

Finally, it was decided to consolidate all the information into a single CSV file for internal metadata.
This CSV file does not keep track of which folder a file is stored in, allowing for easier merging of folders without issues.
However, it results in some duplication of information since common information for all files in a folder is simply copied.

"And what did you learn?" you might ask.
The lesson learned is that before implementation, it is crucial to consider how easily you will maintain product changes.

The history of internal metadata formats in FVA Software demonstrates the importance of designing a system architecture that is flexible and maintainable from the start.