January: 29

Notes

2025

• Hashmap

  04:09PM

  One of the issues that we need to resolve before the end of the gamejam will be the lazy / macro / map. The hashmap that we are using right now from std collections will not be the best for multithreading. Thus we need to find a replacement for it, hmm.

  04:11PM

  The next couple builds have to focus on the part of the data structure and I also need to map out some of the caching.

• Issues

  07:45PM

  First issue ticket that we will have to make is for upgrading the supabase core image that gets provided or built off of in kilobase. I believe the current supabase image is 15.1 and we need to upgrade to 15.6.

  Issue ticket 2 will be for finishing the discord.sh tags and making sure that migration happens amoung the tags without any problems.

  Issue ticket 3 is for the migration of server table, tags and their relationship inside of the postgres. This is important before we start the front end development. The option for front end can be nextjs or astro. The other option could be to use tamamgui for the front-end. This would make thigns a bit more interesting, yet the otherside of this would be, hmm wait, actually nevermind. We can not use tamagui and have to stick with either astro or nextjs, I will hold off on this until after the gamejam.

2024

• 7:30am - Payment

  Payment

  It is the end of the month, I need to double check all the auto payments for the end of the month and wanted to make sure that everything was working. I been trying to find ways to use AI to help manage the cashflow but honestly it seems to be a bit overkill because it does not do much to help. If anything it might be a waste of resources and time because autopayment and the timing around the credit (30 days) is already enough to handle most transactions. Instead of waiting until the end of the month, just a simple script to double check payments and pay within 14 days or post the date out to 27 days seems to handle the issue.

• 8:50am - Rust

  Rust

  More rust through out the day! I went through a bit of a stump and was thinking of rotating out the Diesel and switching to SQLx and SeaORM but honestly that might not be worth the time investment. I decided to rename the routes module to sys because it felt like it would make more sense later down the line. Having the route / routes within the internal package is not worth it, as it can be kept to the application layer.

• 10:30am - Entity

  Entity

  Before doing the Auth module, I think it would make sense to build out the entity module. This will be extended in the future for multiplayer, users, economy and much more! The first one that I will add is the generic_response.rs under response, just to make sure that it works within the package.

  Next concept within the Entity will be the header_response.rs which will handle the basic headers and include a generic cookie for now.

  After pushing through the header_response, the next file within the response would be the shield_response.rs

  This will extend the header response with a x-kbve-shield, moving away from using the spellbook approach and rather using the impl.

• 4:35pm - Regex

  Regex

  Taking a break from the entity creation and building out the sanitization! Starting with the regex, which I will place under the sanitization_regex.rs and then added extraction functions for each of them.

  I ended up renaming the module to regex_extractor.rs and now I am going to expand around it for the time being. One interesting test case was that I could migrate the ULID check into a regex, which should help with speed of verifying if its valid. Before we were using a function like this:

      pub fn validate_input_ulid(ulid_str: &str) -> Result<&str, &'static str> {
  
          // ULID is usually 26 chars.
          if ulid_str.len() != 26 {
              return Err("ulid_invalid");
          }
  
          // Crockford's base32 set
          let base32_chars = "0123456789ABCDEFGHJKMNPQRSTVWXYZ";
  
          // Validate each character
          for c in ulid_str.chars() {
              if !base32_chars.contains(c) {
                  return Err("Invalid character in ULID");
              }
          }
  
          // ULID is valid
          Ok(ulid_str)
          }

  The sanitization module is now just two core files, the regex_extractor.rs which will isolate the regex and provide helper extraction functions. Then there is the validator.rs, which holds the new ValidationBuilder.

  The way we would use this is:

          let mut validator = ValidatorBuilder::<&str>::new()
              .password(); // Add password validation rule
  
          let input = "YourPassword123!"; // The input password to validate
          let result = validator.validate(&input); // Pass the input to the validate method
  
          match result {
              Ok(_) => println!("Password is valid."),
              Err(err) => println!("Validation failed: {}", err),
          }

  ^ That is the example for the password validation.