magic_lobster_party

  • 1 Post
  • 103 Comments
Joined 1 year ago
cake
Cake day: August 15th, 2024

help-circle

  • There are two main use-cases you want your color theme to address:

    1. Look at something and tell what it is by its color (you can tell by reading text, yes, but why do you need syntax highlighting then?)
    2. Search for something. You want to know what to look for (which color).

    I disagree. I want syntax highlighting because I think it’s easier to read. I don’t care much about which color everything is, just that different things have different colors. I don’t remember any color mappings, and I’m never thrown off guard if the color mapping change.

    When I read var count = 0L, I want to know that var is syntactically different from count, and count is different from 0L. That’s it.


  • Dedicate yourself with a more long term project (1+ months). I think the best way to learn is through the pain that comes with larger code bases.

    Start small. Add more and more features. If there’s something you don’t know how to make, find a tutorial or a guide and make it work with your project.

    Eventually you’ll discover pain points in your project. The feature you want to make doesn’t fit well with your current code. This is good time to learn from your previous mistakes and adapt your old code for the better (refactoring).

    Over time you’ll learn more and more techniques to write code that can grow. You’ll see for yourself why some coding styles are considered bad and why some are better. This is difficult to see just by working with short term weekend scripts.

    Don’t worry about failing. No one writes ”perfect” code. You’ll learn from your mistakes.




  • I think this is dependent on context. Linus is working with a very public repository. Private repositories shared with a small team have different conditions.

    What works in my smallish team at my company is:

    • Enable squash commits. Each PR should be squashed to a single commit. This makes the master branch linear and simple. This ensures each individual commit on master has been reviewed and is in a working state.
    • You can do whatever shit you want on your own branch. It’s going to be squashed anyway.
    • Don’t base your work on some other team member’s branch, unless agreed upon. That’s their work. You should only depend on the master branch.
    • Never rewrite what has already been committed to the master branch.







  • I would buy it if the excuse was they wanted an actor that could do voice as well as motion capture, and maybe David Hayter wasn’t cut to do both at the same time. In some promo it sounded like they wanted someone who could do both. In the age of motion capture, it’s going to be jarring to record voice lines in a booth separately. Particularly if multiple actors interact with each other in a scene.

    But no. There was barely any interesting acting at all from Snake. Most of the acting was carried by the other characters, while Snake was just grunting doing nothing in particular.

    I’d rather take MGS4 Snake any day.



  • I think no discussion about parrying is complete without mentioning Ultrakill. It strikes a good balance between being usable without being an auto win button.

    In Ultrakill, besides from dealing extra damage and gaining style points, parrying enemy attacks is one of the most effective ways to regain health. Low on health? Find an attack to punch and you’re back in action.

    This creates a risk reward system. Committing to a parry is risky. If you miss you lose health - and it’s easy to miss when there’s 10 other things going on at the same time. It’s not always easy to find an opening to commit to.

    It also had a bug in early development where the player could also parry their own shotgun bullets if timed correctly. This was developed an intended mechanic, so Ultrakill is the game where punching your own shotgun bullet makes them go faster.