Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)L
Posts
0
Comments
53
Joined
3 yr. ago

  • This is what I need, an explicit reason that makes one choice better than another. If hyphens make for a smoother experience, then I'll reconsider my default behavior.

    Thanks for pointing out this benefit.

  • Now I use lowercase and underscores everywhere.

  • I see this every sprint.

  • This was a good blog post. I have started using approach #3 as well for just about every situation where I was originally planning on just using a enum type by itself. Inevitably I end up needing to apply shared state to all of my enums (create date, parent table ID, etc.) and this approach has really worked out very well. You can also add some convenience functions for returning if the kind is one of the variants (ex: IsKeywordSearch) to make if-statements easier to read (and a match on the type enum is overly verbose when you don't need the properties contained within the enum itself).

  • This looks like the old logo died, laying in a pool of blood. I would like to imagine that they may be subtly acknowledging the end, or at least the art director is.

  • When the car is at a stop is when he is most vulnerable. He must fight everyone, right there, until the car starts moving again.

  • The main one that jumped out to me was a scroll issue on iOS when using multiple fingers. I just looked it up to share a link and it may be fixed? It's the mentality of "Eh, we might fix it one day" that is the bulk of why I didn't stick with Flutter. A bug this annoying lingering for as long as it did said volumes to me.

    Possibly fixed: https://9to5google.com/2023/12/28/google-fixes-flutter-infamous-scrolling-bug/

  • I wanted to get into Flutter but it seems like there are some bugs that are either unfixable or that they have actively decided not to fix. I didn't want to end up wasting my time building on such a foundation, but it's definitely nice for certain projects that fit within the supported functionality.

  • Isn't it part of some secret Pokémon lore that humans are Pokemon? Someone made a video on YouTube about it a few years ago.

  • This was a great blog post. I love Rust and Bevy, but I can definitely see why you made the switch.

    The primary issue with your decision to use Rust/Bevy, for me, was that you were taking on the task of getting others to work in a difficult language for novice developers. I would never suggest Rust as someone's first language, coupling that with a regularly-changing library like Bevy.

    I would love to know what the pros and cons were between Unity and Godot. If you were going to switch to C# anyway, Godot seems like the next logic choice to me, so I'm curious about what your team's evaluation was for that engine.

  • I leave mine in the trunk and have only walked into the store without them twice. Not forgetting them before walking into the store and putting them back into the trunk after unloading them is the hardest part.

  • Exactly. The functions of the super trait are also required when implementing the child trait's functions, as you would expect from inheritance.

  • Basically, you can generalize your trait types into their parent (super) traits for situations when functionality is specific to those supertrait objects.

    As an example, if you have a trait CanBark and it is a super trait for the trait IsDog, you can coerce your references of &dyn IsDog into a &dyn CanBark. You can then work with other trait types that share a super trait.

     
        
    trait CanBark {
        fn bark(&self);
    }
    trait IsSeal: CanBark { }
    trait IsDog: CanBark { }
    
    fn bark_as_group(barkers: &Vec<&dyn CanBark>) {
        for barker in barkers {
            barker.bark();
        }
    }
    
    let spot: &dyn IsDog = get_spot();
    let seal: &dyn IsSeal = get_seal();
    let barkers: Vec<&dyn CanBark> = Vec::new();
    barkers.push(spot);  // coerced
    barkers.push(seal);  // coerced
    bark_as_group(&barkers);
    
      

    At least, I hope this is possible now. If it's purely "you can return a coerced type from a function", that is less useful.

  • Wow, that trait feature is great. I've been eagerly waiting for that one for a long time. Thank you to everyone who made that possible.

  • I kept most of my bindings the same as the normal QWERTY keyboard, so I don't have much of an issue swapping between them. I had debated a lot about changing to other keyboard layouts and I'm really glad that I didn't.

  • I love my Moonlander. I'll never go back.

  • I had a coworker who would sometimes not create a method as being static to the class and would therefore need to create a default instance to call said method. "It's domain-driven design."

  • Sounds good. Please share what you find and what you end up going with.

  • There are a few different ways to solve this problem without using unsafe and I'm not sure what would be considered idiomatic. Another option is to ultimately encapsulate all of the nodes in a reference-counted box like Rc or Arc and specify the type of your parent/child/sibling references to the same reference-counted box type. With that, you just share cloned instances around as needed.

    The primary drawback here is that for mutable access you end up having to perform a lock every time on an underlying Mutex (or something similar). You also no longer have direct access to the singular instance of the node.

    There are pros and cons to every approach.