Refactoring for Modularity, Code Reuse, and Security Considerations
In this commit, we have undertaken a significant refactoring of the codebase to improve modularity, promote code reuse, and consider security aspects.
Modularity and Code Reuse: We introduced classes and modules to better organize the code and facilitate code reuse. Specifically, we created a new Utilities module to hold common methods that are used across different parts of the application. This module includes methods such as convert_speed_to_mbps, services_to_hash, and calculate_total_bandwidth. By placing these methods in a module, we can include this module in any class that needs these methods, thereby promoting code reuse and reducing duplication.
We also created two new classes, SystemInformationGather and DatabaseManager. The SystemInformationGather class is responsible for gathering system information, such as uplink and downlink speed, and services. The DatabaseManager class handles database operations, including testing the database connection, creating the system information table, and storing system information in the database. By encapsulating these responsibilities within their respective classes, we have made the code more organized and easier to maintain.
Database Connection Details: We made a decision to store the database connection details in a config file (config.yml) instead of the database itself. This decision was made for security reasons, as storing these details in the database could expose them to potential security risks. Storing these details in a config file allows us to better control access to these details.
Database Encryption: We discussed the possibility of encrypting the database for additional security. While we have not implemented this feature in this commit, we have laid the groundwork for it by discussing potential libraries/gems that could be used for this purpose. This is an area that we will revisit in the future.
System Information Gathering: We wrote methods to gather system information, such as uplink and downlink speed, and services, and store this information in the database. This information will be useful for monitoring system performance and for making decisions about resource allocation.
This refactoring effort has made the codebase more organized, easier to maintain, and more secure. It also aligns with our project goals and roadmap. However, it's important to note that with any refactoring effort, there may be potential issues or trade-offs. We will need to thoroughly test the refactored code to ensure that it works as expected and that there are no unintended side effects.
2023-06-04 14:41:12 -06:00
|
|
|
require 'curses'
|
|
|
|
|
require 'yaml'
|
|
|
|
|
require_relative 'utilities.rb'
|
|
|
|
|
|
|
|
|
|
class SystemInformationGather
|
|
|
|
|
include Utilities
|
|
|
|
|
|
|
|
|
|
def ask_for_uplink_speed
|
2023-06-03 13:38:30 -06:00
|
|
|
while true
|
|
|
|
|
Curses.clear
|
|
|
|
|
Curses.setpos(2, 0)
|
|
|
|
|
Curses.addstr("Please enter your uplink speed (upload speed, e.g., 1000Mbps or 1Gbps). ")
|
|
|
|
|
Curses.addstr("This is typically the maximum upload speed provided by your ISP. ")
|
|
|
|
|
Curses.addstr("You can check your ISP bill, use an online speed test, or contact your ISP if you're unsure. ")
|
|
|
|
|
Curses.refresh
|
|
|
|
|
speed = Curses.getstr.strip.downcase
|
|
|
|
|
if valid_speed?(speed)
|
|
|
|
|
return convert_speed_to_mbps(speed)
|
|
|
|
|
else
|
|
|
|
|
Curses.setpos(3, 0)
|
|
|
|
|
Curses.addstr("Whoops! That didn't appear to be a valid speed. Please try again!")
|
|
|
|
|
Curses.refresh
|
|
|
|
|
end
|
|
|
|
|
end
|
|
|
|
|
end
|
Refactoring for Modularity, Code Reuse, and Security Considerations
In this commit, we have undertaken a significant refactoring of the codebase to improve modularity, promote code reuse, and consider security aspects.
Modularity and Code Reuse: We introduced classes and modules to better organize the code and facilitate code reuse. Specifically, we created a new Utilities module to hold common methods that are used across different parts of the application. This module includes methods such as convert_speed_to_mbps, services_to_hash, and calculate_total_bandwidth. By placing these methods in a module, we can include this module in any class that needs these methods, thereby promoting code reuse and reducing duplication.
We also created two new classes, SystemInformationGather and DatabaseManager. The SystemInformationGather class is responsible for gathering system information, such as uplink and downlink speed, and services. The DatabaseManager class handles database operations, including testing the database connection, creating the system information table, and storing system information in the database. By encapsulating these responsibilities within their respective classes, we have made the code more organized and easier to maintain.
Database Connection Details: We made a decision to store the database connection details in a config file (config.yml) instead of the database itself. This decision was made for security reasons, as storing these details in the database could expose them to potential security risks. Storing these details in a config file allows us to better control access to these details.
Database Encryption: We discussed the possibility of encrypting the database for additional security. While we have not implemented this feature in this commit, we have laid the groundwork for it by discussing potential libraries/gems that could be used for this purpose. This is an area that we will revisit in the future.
System Information Gathering: We wrote methods to gather system information, such as uplink and downlink speed, and services, and store this information in the database. This information will be useful for monitoring system performance and for making decisions about resource allocation.
This refactoring effort has made the codebase more organized, easier to maintain, and more secure. It also aligns with our project goals and roadmap. However, it's important to note that with any refactoring effort, there may be potential issues or trade-offs. We will need to thoroughly test the refactored code to ensure that it works as expected and that there are no unintended side effects.
2023-06-04 14:41:12 -06:00
|
|
|
|
2023-06-03 13:38:30 -06:00
|
|
|
def ask_for_downlink_speed
|
|
|
|
|
while true
|
|
|
|
|
Curses.clear
|
|
|
|
|
Curses.setpos(4, 0)
|
|
|
|
|
Curses.addstr("Please enter your downlink speed (download speed, e.g., 1000Mbps or 1Gbps). ")
|
|
|
|
|
Curses.addstr("This is typically the maximum download speed provided by your ISP. ")
|
|
|
|
|
Curses.addstr("You can check your ISP bill, use an online speed test, or contact your ISP if you're unsure. ")
|
|
|
|
|
Curses.refresh
|
|
|
|
|
speed = Curses.getstr.strip.downcase
|
|
|
|
|
if valid_speed?(speed)
|
|
|
|
|
return convert_speed_to_mbps(speed)
|
|
|
|
|
else
|
|
|
|
|
Curses.setpos(5, 0)
|
|
|
|
|
Curses.addstr("Whoops! That didn't appear to be a valid speed. Please try again!")
|
|
|
|
|
Curses.refresh
|
|
|
|
|
end
|
|
|
|
|
end
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
def valid_speed?(speed)
|
|
|
|
|
speed.to_i > 0
|
Refactoring for Modularity, Code Reuse, and Security Considerations
In this commit, we have undertaken a significant refactoring of the codebase to improve modularity, promote code reuse, and consider security aspects.
Modularity and Code Reuse: We introduced classes and modules to better organize the code and facilitate code reuse. Specifically, we created a new Utilities module to hold common methods that are used across different parts of the application. This module includes methods such as convert_speed_to_mbps, services_to_hash, and calculate_total_bandwidth. By placing these methods in a module, we can include this module in any class that needs these methods, thereby promoting code reuse and reducing duplication.
We also created two new classes, SystemInformationGather and DatabaseManager. The SystemInformationGather class is responsible for gathering system information, such as uplink and downlink speed, and services. The DatabaseManager class handles database operations, including testing the database connection, creating the system information table, and storing system information in the database. By encapsulating these responsibilities within their respective classes, we have made the code more organized and easier to maintain.
Database Connection Details: We made a decision to store the database connection details in a config file (config.yml) instead of the database itself. This decision was made for security reasons, as storing these details in the database could expose them to potential security risks. Storing these details in a config file allows us to better control access to these details.
Database Encryption: We discussed the possibility of encrypting the database for additional security. While we have not implemented this feature in this commit, we have laid the groundwork for it by discussing potential libraries/gems that could be used for this purpose. This is an area that we will revisit in the future.
System Information Gathering: We wrote methods to gather system information, such as uplink and downlink speed, and services, and store this information in the database. This information will be useful for monitoring system performance and for making decisions about resource allocation.
This refactoring effort has made the codebase more organized, easier to maintain, and more secure. It also aligns with our project goals and roadmap. However, it's important to note that with any refactoring effort, there may be potential issues or trade-offs. We will need to thoroughly test the refactored code to ensure that it works as expected and that there are no unintended side effects.
2023-06-04 14:41:12 -06:00
|
|
|
end
|
|
|
|
|
|
2023-06-03 13:38:30 -06:00
|
|
|
def ask_for_services
|
|
|
|
|
while true
|
|
|
|
|
Curses.clear
|
|
|
|
|
Curses.setpos(6, 0)
|
|
|
|
|
Curses.addstr("Please enter the services the system should be aware of (e.g., webserver, database). ")
|
|
|
|
|
Curses.addstr("Enter the services as a comma-separated list (e.g., webserver,database). ")
|
|
|
|
|
Curses.refresh
|
|
|
|
|
services = Curses.getstr.strip.downcase.split(',').map(&:strip)
|
|
|
|
|
if valid_services?(services)
|
|
|
|
|
return services_to_hash(services)
|
|
|
|
|
else
|
|
|
|
|
Curses.setpos(7, 0)
|
|
|
|
|
Curses.addstr("Whoops! That didn't appear to be a valid list of services. Please try again!")
|
|
|
|
|
Curses.refresh
|
|
|
|
|
end
|
|
|
|
|
end
|
|
|
|
|
end
|
Refactoring for Modularity, Code Reuse, and Security Considerations
In this commit, we have undertaken a significant refactoring of the codebase to improve modularity, promote code reuse, and consider security aspects.
Modularity and Code Reuse: We introduced classes and modules to better organize the code and facilitate code reuse. Specifically, we created a new Utilities module to hold common methods that are used across different parts of the application. This module includes methods such as convert_speed_to_mbps, services_to_hash, and calculate_total_bandwidth. By placing these methods in a module, we can include this module in any class that needs these methods, thereby promoting code reuse and reducing duplication.
We also created two new classes, SystemInformationGather and DatabaseManager. The SystemInformationGather class is responsible for gathering system information, such as uplink and downlink speed, and services. The DatabaseManager class handles database operations, including testing the database connection, creating the system information table, and storing system information in the database. By encapsulating these responsibilities within their respective classes, we have made the code more organized and easier to maintain.
Database Connection Details: We made a decision to store the database connection details in a config file (config.yml) instead of the database itself. This decision was made for security reasons, as storing these details in the database could expose them to potential security risks. Storing these details in a config file allows us to better control access to these details.
Database Encryption: We discussed the possibility of encrypting the database for additional security. While we have not implemented this feature in this commit, we have laid the groundwork for it by discussing potential libraries/gems that could be used for this purpose. This is an area that we will revisit in the future.
System Information Gathering: We wrote methods to gather system information, such as uplink and downlink speed, and services, and store this information in the database. This information will be useful for monitoring system performance and for making decisions about resource allocation.
This refactoring effort has made the codebase more organized, easier to maintain, and more secure. It also aligns with our project goals and roadmap. However, it's important to note that with any refactoring effort, there may be potential issues or trade-offs. We will need to thoroughly test the refactored code to ensure that it works as expected and that there are no unintended side effects.
2023-06-04 14:41:12 -06:00
|
|
|
|
2023-06-03 13:38:30 -06:00
|
|
|
def valid_services?(services)
|
|
|
|
|
# TODO: Validate the services
|
|
|
|
|
true
|
|
|
|
|
end
|
Refactoring for Modularity, Code Reuse, and Security Considerations
In this commit, we have undertaken a significant refactoring of the codebase to improve modularity, promote code reuse, and consider security aspects.
Modularity and Code Reuse: We introduced classes and modules to better organize the code and facilitate code reuse. Specifically, we created a new Utilities module to hold common methods that are used across different parts of the application. This module includes methods such as convert_speed_to_mbps, services_to_hash, and calculate_total_bandwidth. By placing these methods in a module, we can include this module in any class that needs these methods, thereby promoting code reuse and reducing duplication.
We also created two new classes, SystemInformationGather and DatabaseManager. The SystemInformationGather class is responsible for gathering system information, such as uplink and downlink speed, and services. The DatabaseManager class handles database operations, including testing the database connection, creating the system information table, and storing system information in the database. By encapsulating these responsibilities within their respective classes, we have made the code more organized and easier to maintain.
Database Connection Details: We made a decision to store the database connection details in a config file (config.yml) instead of the database itself. This decision was made for security reasons, as storing these details in the database could expose them to potential security risks. Storing these details in a config file allows us to better control access to these details.
Database Encryption: We discussed the possibility of encrypting the database for additional security. While we have not implemented this feature in this commit, we have laid the groundwork for it by discussing potential libraries/gems that could be used for this purpose. This is an area that we will revisit in the future.
System Information Gathering: We wrote methods to gather system information, such as uplink and downlink speed, and services, and store this information in the database. This information will be useful for monitoring system performance and for making decisions about resource allocation.
This refactoring effort has made the codebase more organized, easier to maintain, and more secure. It also aligns with our project goals and roadmap. However, it's important to note that with any refactoring effort, there may be potential issues or trade-offs. We will need to thoroughly test the refactored code to ensure that it works as expected and that there are no unintended side effects.
2023-06-04 14:41:12 -06:00
|
|
|
|
2023-06-03 13:38:30 -06:00
|
|
|
def services_to_hash(services)
|
|
|
|
|
services_hash = {}
|
|
|
|
|
services.each { |service| services_hash[service] = true }
|
|
|
|
|
services_hash
|
|
|
|
|
end
|
|
|
|
|
|
|
|
|
|
def ask_for_db_details
|
|
|
|
|
Curses.clear
|
|
|
|
|
Curses.setpos(1, 0)
|
|
|
|
|
Curses.addstr("Please enter your database username: ")
|
|
|
|
|
Curses.refresh
|
|
|
|
|
username = Curses.getstr.strip
|
Refactoring for Modularity, Code Reuse, and Security Considerations
In this commit, we have undertaken a significant refactoring of the codebase to improve modularity, promote code reuse, and consider security aspects.
Modularity and Code Reuse: We introduced classes and modules to better organize the code and facilitate code reuse. Specifically, we created a new Utilities module to hold common methods that are used across different parts of the application. This module includes methods such as convert_speed_to_mbps, services_to_hash, and calculate_total_bandwidth. By placing these methods in a module, we can include this module in any class that needs these methods, thereby promoting code reuse and reducing duplication.
We also created two new classes, SystemInformationGather and DatabaseManager. The SystemInformationGather class is responsible for gathering system information, such as uplink and downlink speed, and services. The DatabaseManager class handles database operations, including testing the database connection, creating the system information table, and storing system information in the database. By encapsulating these responsibilities within their respective classes, we have made the code more organized and easier to maintain.
Database Connection Details: We made a decision to store the database connection details in a config file (config.yml) instead of the database itself. This decision was made for security reasons, as storing these details in the database could expose them to potential security risks. Storing these details in a config file allows us to better control access to these details.
Database Encryption: We discussed the possibility of encrypting the database for additional security. While we have not implemented this feature in this commit, we have laid the groundwork for it by discussing potential libraries/gems that could be used for this purpose. This is an area that we will revisit in the future.
System Information Gathering: We wrote methods to gather system information, such as uplink and downlink speed, and services, and store this information in the database. This information will be useful for monitoring system performance and for making decisions about resource allocation.
This refactoring effort has made the codebase more organized, easier to maintain, and more secure. It also aligns with our project goals and roadmap. However, it's important to note that with any refactoring effort, there may be potential issues or trade-offs. We will need to thoroughly test the refactored code to ensure that it works as expected and that there are no unintended side effects.
2023-06-04 14:41:12 -06:00
|
|
|
|
2023-06-03 13:38:30 -06:00
|
|
|
Curses.setpos(2, 0)
|
|
|
|
|
Curses.addstr("Please enter your database password: ")
|
|
|
|
|
Curses.refresh
|
|
|
|
|
Curses.echo = false
|
|
|
|
|
password = Curses.getstr.strip
|
Refactoring for Modularity, Code Reuse, and Security Considerations
In this commit, we have undertaken a significant refactoring of the codebase to improve modularity, promote code reuse, and consider security aspects.
Modularity and Code Reuse: We introduced classes and modules to better organize the code and facilitate code reuse. Specifically, we created a new Utilities module to hold common methods that are used across different parts of the application. This module includes methods such as convert_speed_to_mbps, services_to_hash, and calculate_total_bandwidth. By placing these methods in a module, we can include this module in any class that needs these methods, thereby promoting code reuse and reducing duplication.
We also created two new classes, SystemInformationGather and DatabaseManager. The SystemInformationGather class is responsible for gathering system information, such as uplink and downlink speed, and services. The DatabaseManager class handles database operations, including testing the database connection, creating the system information table, and storing system information in the database. By encapsulating these responsibilities within their respective classes, we have made the code more organized and easier to maintain.
Database Connection Details: We made a decision to store the database connection details in a config file (config.yml) instead of the database itself. This decision was made for security reasons, as storing these details in the database could expose them to potential security risks. Storing these details in a config file allows us to better control access to these details.
Database Encryption: We discussed the possibility of encrypting the database for additional security. While we have not implemented this feature in this commit, we have laid the groundwork for it by discussing potential libraries/gems that could be used for this purpose. This is an area that we will revisit in the future.
System Information Gathering: We wrote methods to gather system information, such as uplink and downlink speed, and services, and store this information in the database. This information will be useful for monitoring system performance and for making decisions about resource allocation.
This refactoring effort has made the codebase more organized, easier to maintain, and more secure. It also aligns with our project goals and roadmap. However, it's important to note that with any refactoring effort, there may be potential issues or trade-offs. We will need to thoroughly test the refactored code to ensure that it works as expected and that there are no unintended side effects.
2023-06-04 14:41:12 -06:00
|
|
|
Curses.echo
|
2023-06-03 13:38:30 -06:00
|
|
|
Curses.setpos(3, 0)
|
|
|
|
|
Curses.addstr("Please enter your database name: ")
|
|
|
|
|
Curses.refresh
|
|
|
|
|
database = Curses.getstr.strip
|
Refactoring for Modularity, Code Reuse, and Security Considerations
In this commit, we have undertaken a significant refactoring of the codebase to improve modularity, promote code reuse, and consider security aspects.
Modularity and Code Reuse: We introduced classes and modules to better organize the code and facilitate code reuse. Specifically, we created a new Utilities module to hold common methods that are used across different parts of the application. This module includes methods such as convert_speed_to_mbps, services_to_hash, and calculate_total_bandwidth. By placing these methods in a module, we can include this module in any class that needs these methods, thereby promoting code reuse and reducing duplication.
We also created two new classes, SystemInformationGather and DatabaseManager. The SystemInformationGather class is responsible for gathering system information, such as uplink and downlink speed, and services. The DatabaseManager class handles database operations, including testing the database connection, creating the system information table, and storing system information in the database. By encapsulating these responsibilities within their respective classes, we have made the code more organized and easier to maintain.
Database Connection Details: We made a decision to store the database connection details in a config file (config.yml) instead of the database itself. This decision was made for security reasons, as storing these details in the database could expose them to potential security risks. Storing these details in a config file allows us to better control access to these details.
Database Encryption: We discussed the possibility of encrypting the database for additional security. While we have not implemented this feature in this commit, we have laid the groundwork for it by discussing potential libraries/gems that could be used for this purpose. This is an area that we will revisit in the future.
System Information Gathering: We wrote methods to gather system information, such as uplink and downlink speed, and services, and store this information in the database. This information will be useful for monitoring system performance and for making decisions about resource allocation.
This refactoring effort has made the codebase more organized, easier to maintain, and more secure. It also aligns with our project goals and roadmap. However, it's important to note that with any refactoring effort, there may be potential issues or trade-offs. We will need to thoroughly test the refactored code to ensure that it works as expected and that there are no unintended side effects.
2023-06-04 14:41:12 -06:00
|
|
|
|
2023-06-03 13:38:30 -06:00
|
|
|
{ username: username, password: password, database: database }
|
Refactoring for Modularity, Code Reuse, and Security Considerations
In this commit, we have undertaken a significant refactoring of the codebase to improve modularity, promote code reuse, and consider security aspects.
Modularity and Code Reuse: We introduced classes and modules to better organize the code and facilitate code reuse. Specifically, we created a new Utilities module to hold common methods that are used across different parts of the application. This module includes methods such as convert_speed_to_mbps, services_to_hash, and calculate_total_bandwidth. By placing these methods in a module, we can include this module in any class that needs these methods, thereby promoting code reuse and reducing duplication.
We also created two new classes, SystemInformationGather and DatabaseManager. The SystemInformationGather class is responsible for gathering system information, such as uplink and downlink speed, and services. The DatabaseManager class handles database operations, including testing the database connection, creating the system information table, and storing system information in the database. By encapsulating these responsibilities within their respective classes, we have made the code more organized and easier to maintain.
Database Connection Details: We made a decision to store the database connection details in a config file (config.yml) instead of the database itself. This decision was made for security reasons, as storing these details in the database could expose them to potential security risks. Storing these details in a config file allows us to better control access to these details.
Database Encryption: We discussed the possibility of encrypting the database for additional security. While we have not implemented this feature in this commit, we have laid the groundwork for it by discussing potential libraries/gems that could be used for this purpose. This is an area that we will revisit in the future.
System Information Gathering: We wrote methods to gather system information, such as uplink and downlink speed, and services, and store this information in the database. This information will be useful for monitoring system performance and for making decisions about resource allocation.
This refactoring effort has made the codebase more organized, easier to maintain, and more secure. It also aligns with our project goals and roadmap. However, it's important to note that with any refactoring effort, there may be potential issues or trade-offs. We will need to thoroughly test the refactored code to ensure that it works as expected and that there are no unintended side effects.
2023-06-04 14:41:12 -06:00
|
|
|
end
|
|
|
|
|
|
|
|
|
|
def write_db_details_to_config_file(db_details)
|
|
|
|
|
File.open("config.yml", "w") do |file|
|
|
|
|
|
file.write(db_details.to_yaml)
|
|
|
|
|
end
|
|
|
|
|
end
|
|
|
|
|
end
|