buddydvd

The part of regex

    [\w\.-_]

should really be

    [\w\.\-_]

instead.

But not that's not what caused the problem mentioned in this post.

(edited for clairifcation)

I tried out your command and got different line count compared to the output of the commands mentioned in the post. The man page for comm says it assumes inputs to be pre-sorted. To do that, you need to sort the input files before passing them to comm.

  # show only items in both a and b
  comm -1 -2 <(sort -u a_list) <(sort -u b_list)

  # show only items unique to a
  comm -2 -3 <(sort -u a_list) <(sort -u b_list)

  # show only items unique to b
  comm -1 -3 <(sort -u a_list) <(sort -u b_list)

Get a copy of Merriam Webster's Visual Dictionary and just go through its approx. 1000 pages of high-quality illustrations. It efficiently introduces you to countless tip-of-the-ice-berg topics/industries that are very much remotely related to tech. It humbles you and evokes that feeling of self-insignificance like when you look at aerial view of cities through an airplane window.

Thanks for the link. Awhile back, I had implemented an n-bit cipher (where 1 <= n <=64) with an unbalanced Feistel network and used hash function as the basis of the round functions. I then wrap it within a cycle-walking function to form a cipher for any number smaller than 2^64. I did all this so I can generate scrambled 5-char path IDs of short URLs (e.g. test.com/xA7bc) with domain size of 62^5.

+1 for skip32.c since it's O(1) space and O(1) time. With the prime approach, you may need to call it multiple times to reject numbers greater than 2^32-1. Also, a generalized Feistel algorithm may be used to generate permutations with fewer than 32 bits with the same constant space/time requirement and may be helpful in skipping specific IP ranges.

Non-consumable in-app purchases are restorable on any iOS device you can sign in with your iTunes account. When you buy a new iOS device and use StoreKit's restore transaction feature, Apple will generate a new receipt with UDID of that device. In-app purchases are tied to your iTunes account whereas embedded UDIDs are tied to devices you sign in with your iTunes credential.

The UDID embedded in receipts prevents/deters people from sharing them with others using MITM techniques. Sharing does happen and Apple's article helps address that issue.

Lowercasing the first character--by itself alone--does not address inverted case scenario (e.g. "PaSsWoRd" and "pAsSwOrD" evaluate to "paSsWoRd" and "pAsSwOrD" respectively).

One way to resolve that issue is to create two versions of the password (one with normal casing and one with inverted casing, but both with the first character lowercased), sort them, and pick the first result.

    ["pAsSwOrD", "PaSsWoRd", "PAsSwOrD"].map(function canonicalize(pwd) {
        function invert(str) {
            return (str == str.toUpperCase()
                    ? str.toLowerCase()
                    : str.toUpperCase());
        }
        var head = pwd.substring(0, 1).toLowerCase();
        var tail = pwd.substring(1);
        var vers = [head + tail,
                    head + tail.split("").map(invert).join("")];
        return vers.sort()[0];
    });

Which gives the following result:

    ["pAsSwOrD", "pAsSwOrD", "pAsSwOrD"]

The three different variations get canonicalized into one version. With it, you can just store one hash instead of three.

There's a bug in the first optimization example. Specifically, class "point"'s "up" and "down" methods still reference the "move" method as "move" instead of "b". It can be fixed by replacing the original statement "p.move(10)" with "move.call(p, 10)" for the "up" method (and similarly for the "down" method).

Despite the bug, I think it illustrates a good point. You can adopt a specific coding style that help you achieve higher level of minification/obfuscation.

It would be nice if languages like TypeScript can perform this transformation for you.

I'm not sure what you mean -- Facebook disabled the iframe approach long ago.