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/)G
Posts
8
Comments
1298
Joined
2 yr. ago

  • There is no assumption of privacy when operating heavy machinery. You are quite literally wearing an identification tag on the vehicle at all times, such that you can be identified in the case of violating rules.

    Speed cameras are good, actually. As mentioned in the article, speeding was reduced by 71% at the installation sites.

    So is using design to manage speeds - also mentioned in the article.

  • You can't really use a speed bump on higher speed roads, where speed cameras can be a good choice to enforce speed limits.

    Strategic use on roads with a desired speed around 70 km/h around areas with collision risk is a good use-case for speed cameras. This is how they are often deployed in Sweden - you put up a sign warning drivers that a speed is imminent, and compliance with the speed limit becomes essentially universal. A drop in crash risk follows.

    Using speed bumps and roundabouts is also obviously good, but they serve different use-cases.

  • Speed cameras are a form of enforcement - you exceed the speed limit, you get a ticket. Quite literally the definition of enforcement.

  • I want to remember being fingerprinted at a Canadian airport the one time I had a layover there in 2018.

    This is all pretty common these days.

  • You enable it using git config, after that it will apply to whatever frontend you're using.

  • Depending on how structured your commits have been, it can either be very difficult to get a rebase through or a complete breeze. There are some features to make it easier - rerere being the main one I'm thinking about.

  • Hötorget station. A particularly confusing one to understand the exits, I never seem to be able to get out where I want.

  • What's your mental model for a Git commit, and a Git branch?

    Once I properly learned those two concepts, understanding rebases became a lot easier.

    I'll try to explain it to the best of my abilities.

    • Think of a commit being a patch - a description of how to take a particular file from one state to another
    • A branch is a list of patches to be applied in order, from the point where the branch was created until the last commit on the branch

    When you rebase a particular branch, what you're essentially doing is taking all of the commits that are currently on your branch, checking out the other branch, and then applying each of the patches in order on that new branch.

    A rebase can be cleanly applied if the premise for each commit has not changed when applied, but if the premise has changed, you get a conflict to be resolved before being able to continue the rebase.

    I mentally model a rebase a bit as a fast version of how it would look like to build the branch I was on, but on top of the branch I'm rebasing on.

  • ps aux | xargs kill -9

  • If you're not using the toilet brush, please start doing so

  • Well, you might be inclined to not roll the feature out at all, depending on the results you see from the rollout/an A/B-test. Also, having it written out with a date in the changelog binds you to that date, unless you want the embarrassment of not shipping on a promised time. Maintaining a changelog for very large app development organizations is also a pretty damn hard task, trying to coordinate whatever all teams are releasing in a particular build.

    I agree that getting cute with the changelog messages is a bit stale. Might as well not add anything at that point.

  • Modern mobile app development almost always releases features gradually behind feature flags, so changelogging things is not necessarily practical to do.

  • I'm guessing this is in reference to a scenario where a review of the PR has already been performed, and the rebase+force push is made to introduce new changes to the PR, possibly to address PR feedback.

    I agree that these changes should be made in separate commits, for the benefit of the reviewer.

    There are other scenarios where rebases are appropriate though, such as getting potentially incompatible changes from the main branch into the PR, and here I believe a rebase+force push is the right tool for the job.

  • Force pushing is necessary when using rebases, and rebases are an essential tool, so you should not be afraid to force push under normal circumstances.

  • Don't be afraid of rebases, they are an essential tool in Git.

    This particular fear can only be addressed by understanding.

  • It's mostly for undoing a rebase or merge you're not happy with.

  • The dose makes the poison, really. It's quite hard to reach a harmful amount of sugar by just eating fruit - you're likely to get either full or bored with eating fruit before you start reaching unhealthy levels of sugar. Combine this with fruits and berries generally being a good source of dietary fiber, this makes for a good combination of attributes you want in healthy food.