itcharlie

In the last few months I have been learning Flutter and Dart and recently I saw a youtube video from our very own Perl Wizard Randal Schwartz ( Vibe-coding with Gemini CLI ) where he is exploring the use of Google Gemini to vibe code Flutter applications. Gemini Cli is a command line tool that gives you the power of Gemini AI right in your command line prompt. In the beginning of Randal's adventure with Gemini he wrote this AI prompt "review the app @youtube_watcher. Tell me the Good, the Bad and the Ugly." and AI delivered a very detailed response on what is and isn't working within the application.

After seeing this very detailed report I decided to do the same on ev-calc-pricing a perl dancer project I worked on and I was amazed to see Gemini work on a perl dancer project. At this point I realize that Gemini is capable of assisting coders in any language/ framework and it can provide insight on software engineering best practices for you application.

Gemini's response below:

---------------------------
> review @ev-calc-pricing and give me the Good , the Bad and the Ugly

✦ Based on my review of the ev-calc-pricing project, here's "The Good, The Bad, and The Ugly":

The Good

* Clear Purpose: The application has a well-defined and easy-to-understand purpose: calculating the cost of EV charging by US
state.
* Simple Structure: The project follows a standard Perl Dancer2 application layout, making it familiar to developers experienced
with the framework.
* Separation of Concerns: The core business logic is separated into the EVCalc.pm and StateRates.pm modules, which is a good
practice.
* Data is Centralized: The state electricity rate data is stored in a single module (StateRates.pm), making it easy to update.

The Bad

* Manual Data Management: The state electricity rates are hardcoded in the StateRates.pm module and appear to be manually updated.
This is error-prone and time-consuming. The bin directory contains scripts that seem to be for generating this data, but the
process isn't automated.
* Lack of Tests: There are only two very basic test files. The existing tests only check if the main module can be loaded. There
are no tests for the calculation logic or the web interface.
* Outdated Data: The data in average_electric_rates_by_year.csv only goes up to 2023. The electric_rates.txt file seems to contain
data for 2020 and 2021. The data in StateRates.pm is more up-to-date, but the presence of older, unused data files is
confusing.
* Inconsistent Data Sources: The README.md file mentions multiple data sources, and there are several data files in the bin
directory (average_electric_rates_by_year.csv, electric_rates.txt). It's not immediately clear which one is the single source of
truth or how they are used.

The Ugly

* Hardcoded Data: The StateRates.pm module is a large, hardcoded hash. This is inflexible and makes the application difficult to
maintain. A better approach would be to store this data in a database or a configuration file that can be updated without
changing the code.
* Redundant and Unused Scripts: The bin directory contains several scripts (generate_state_rate_hashdb.pl,
generate_state_rate_hashdb2.pl, rewrite_ev_charge_price_calculator.pl) that appear to be one-off scripts for data processing.
These should be better documented, organized, or removed if they are no longer needed.
* No Input Validation: The application does not appear to have any input validation on the form submission. This could lead to
unexpected behavior or errors if the user enters invalid data.

---------------------