• 7 Posts
  • 33 Comments
Joined 9 months ago
cake
Cake day: October 14th, 2023

help-circle



  • If our content gets federated to threads then it just means that google results will point to it first rather than to us, they will probably have better indexing and search features than the fediverse. People will also probably think the content originated on threads too (since that’s where they see it and threads could easily obfuscate info like that) instead of who actually made it.

    It could increase the short term engagement but in the long run, it will just serve to make threads better.






  • That’s not really a good solution although it is a temporary workaround.

    • Many users won’t know this is a feature they can use, or how to set it up
    • Some users use alternative instances that federate with lemmy which might not have this feature
    • Content still gets copied and hosted on this instance which might not be desireable

    Besides, at the end of the day, shouldn’t the admins and mods here curate the content according to the community’s guidelines and spirit? If someone started spamming undesired content on a forum you’re administrating, the answer wouldn’t be “all the users can just block it if it’s an issue”. I don’t think it should be the answer here either






  • Was pretty simple in Python with a regex to get the game number, and then the count of color. for part 2 instead of returning true/false whether the game is valid, you just max the count per color. No traps like in the first one, that I’ve seen, so it was surprisingly easy

    def process_game(line: str):
        game_id = int(re.findall(r'game (\d+)*', line)[0])
    
        colon_idx = line.index(":")
        draws = line[colon_idx+1:].split(";")
        # print(draws)
        
        if is_game_valid(draws):
            # print("Game %d is possible"%game_id)
            return game_id
        return 0
    
                
    def is_game_valid(draws: list):
        for draw in draws:
            red = get_nr_of_in_draw(draw, 'red')
            if red > MAX_RED:
                return False
            
            green = get_nr_of_in_draw(draw, 'green')
            if green > MAX_GREEN:
                return False
            
            blue = get_nr_of_in_draw(draw, 'blue')
            if blue > MAX_BLUE:
                return False    
        return True
            
                
    def get_nr_of_in_draw(draw: str, color: str):
        if color in draw:
            nr = re.findall(r'(\d+) '+color, draw)
            return int(nr[0])
        return 0
    
    
    # f = open("input.txt", "r")
    f = open("input_real.txt", "r")
    lines = f.readlines()
    sum = 0
    for line in lines:
        sum += process_game(line.strip().lower())
    print("Answer: %d"%sum)
    







  • Validation is usually the first step so I only start preloading after it’s done of course, but you are right - you can easily end up loading more data than it necessary.

    However, it can also result in fewer overall queries - if I load all relevant entities at the beginning then later I won’t have to do 2+ separate calls to get relevant data perhaps. For example, if I’m processing weather for 3 users, I know to preload all 3 users and weather data for the 3 locations where they live in. The old implementation could end up loading 3 users, then go into a loop and eventually into a method that processes their weather data and do 3 separate weather db hits for each of the users (this is a simplified example but something that I’ve definitely seen happen in more subtle ways).

    I guess I’m just trying to find a way to keep it a pure method with only “actual logic” in it, without depending on a database. Forcing developers to think ahead about what data they actually need in advance also seems like a good thing maybe.


  • I’m not caching or reusing method results however, and even the inputs are not necessarily cached for multiple uses. I’m just preparing all potentially required input data before the method is actually called so I don’t have to do any loads within the method itself, so the method is just pure code logic and no db interaction.

    For example, imagine you have a method that scores the performance of an athlete. The common “pattern” in this legacy code base is to just go through the logic and make a database load whenever you need something, so maybe at the beginning you load the athlete, then you load his tournament records, then few dozen lines later you load his medical records, then his amateur league matches, etc.

    What I do is I just load all of this into a cache before the actual method call, and then send it into the method as a data source. The method will only use the cache and do all the calculations in-memory, and when it’s done the result would be in the cache as well. Then outside of the method I can just trigger a save or abandon it to persist the result. If I want to unit test it, I can easily just manually fill a cache with my data and use it as the data source (usually you’d have to mock custom response from the repository or something like that, inject an in-memory repository with the same data anyway or just resign to using an integrated test).

    It’s like I’m “containerizing” the method in a way? It’s a pretty simple concept but I’m having trouble googling for it since I don’t know how to call it.