How I ended up with 1.5 Google accounts

I'm fuzzy on some details, but this is the best I can remember about how it happened.

Fun fact, this was actually the first console game I ever played, and after playing at a friend's house, I convinced my parents to buy a Wii.
A long time ago, there was this cool video sharing platform called YouTube. I was pretty young, playing some random game called Super Mario Galaxy 2, when I discovered a couple interesting quirks of the game's gravity mechanics and recorded them with my sister's camera on my family's tripod. I had to ask my parents' permission to create a YouTube channel so I could upload the videos.

This is probably what I saw, but it's been so long I don't really remember.
On October 18, 2010, I created the YouTube channel LB725C. My online alias at the time was LB, but many sites (YouTube included) imposed a 3 character minimum. Not content to add an underscore, I came up with the clever idea to somehow use 1337 in my username, but in a subtle way. It just so happens that 1337 degrees Fahrenheit is approximately equal to 725 degrees Celsius. Thus, LB725C was born as my YouTube username. Back then, usernames were also display names. I think the email address I used was my old Yahoo email address.

You should really migrate your email from Yahoo to some other service.
At some point I had associated my Yahoo email address with my Google account. At some other point, YouTube's parent company (which wasn't Alphabet at the time) started linking YouTube accounts with Google accounts by email address. At some later point, some random social media platform operated by YouTube's parent company seemed to be destined to insert its tendrils into every other service run by the parent company.

One fateful day, I visited YouTube to look for more videos of glitches in my favorite Nintendo games, only to be greeted by a dialog, asking me to make a choice that some would find very difficult. I could continue to use my existing channel name of LB725C, or I could use my real name. But there was also a third option: I could write in whatever name I wanted. So of course, I picked that and tried to enter LB. To my surprise, it worked! I was pretty happy about that, but I didn't think much of it afterward. My channel's custom URL was still LB725C, which I was disappointed about, but I understood why I couldn't change it.

Eventually, I noticed that when I clicked my avatar in the top right of YouTube, there was another channel with my real name. A channel I had never created but which nonetheless existed, having 0 subscribers and 0 of everything else as well. Curious, I looked into everything and made a lot of discoveries. I was now logged into YouTube via Google. My Google account had a Google+ page with my real name, and this page was considered a "real person" and was permanently associated with my Google account. My "real person" Google+ page had a YouTube channel automatically created for it. But, I also had another Google+ page - this one was called LB. It also had a YouTube channel. Both existed under the same account.

This URL doesn't exist anymore, and changed several times before it was removed. I pulled this screenshot from an old forum thread where I made a very misguided attempt at defending Google+.
As I discovered these facts, I started customizing everything, changing settings and adding information. I noticed there was a way to set a password on the Google+ settings page for LB - how curious, what might that be for?

This isn't what it originally looked like, though, nor is it the original URL.
So, I tried it, and was told it had been set successfully. What? What is this password for? Apparently, it's for managers of brand accounts to use. What's a brand account? How would managers use this password? These support articles sort of explain it:

My LB Google+ page also had a randomly generated email address that I assumed was only used as a hack for Google services that needed an email address to understand the world. So, I opened another browser (or rather, created a new user profile in Chrome) and used the weird email address and the password I just set to log in. I could use YouTube just as I always could, no surprises there, but I had used the same login process for normal Google accounts, so I wondered what other services would work like this?

The first thing I tried was GMail. It directed me to a page about upgrading to GMail, which was when I found out that GMail hadn't always existed at the same time as Google accounts. It let me pick my own email address, but I've always been bad at deciding such things, so I used my channel's custom URL. Surprise! I now had a second GMail account, owned by the LB Google+ page, which was also owned by my personal Google+ page. Most other Google services worked too, including an extra 15GB of free Google Drive space.

It used to be that the LB profile would use my avatar, but that functionality broke at some point.
This was a time in my life when I really needed to figure out how to separate school life from goofing around on YouTube, and this weird dual account setup seemed like the perfect way. Back on my personal Chrome user profile, I switched YouTube to the channel with my real name and set it as the default. It was weird to see an empty subscription feed, so I subscribed to some science channels and my college's YouTube channel. I figured I may as well learn stuff if I was gonna use YouTube when I should be using it. Then I would only use the LB channel and user profile for gaming related activities. In a way, it felt like I was maintaining two separate identities, and for the most part that was how I treated it - two sides of the same coin. From each identity, I avoided mentioning the other, except for accounts and places where I had already done such things. To this day, I still have two Chrome user profiles on my computer, and I use one for college (which I'm almost finished with) and the other for gaming. If I need to focus on school, I just close a browser window (since you can have both open at the same time).

I see this robot a lot.

As far as I can tell, the functionality I used to create the LB Google account no longer exists - instead, YouTube and Google+ just have better support for switching between multiple channels/pages owned by a single Google account. I'm not sure how much longer the LB Google account will continue to exist, but so far it's holding up fine.

This used to say LB725C back in the day.
There's one more strange part of this story, though - my YouTube channel now has two custom URLs. The original custom URL, YouTube.com/LB725C still works. But the LB Google+ page also allowed me to create a custom URL, which I thought only applied to Google+. For some reason I didn't want to use LB725C again, and instead went with the even dumber LBStuff-LB. So now I have a second custom URL YouTube.com/c/LBStuff-LB that for some reason is now the default custom URL.

Notice that this page actually shows both custom URLs for some reason.
I think it's now possible to divorce Google+ from YouTube channels and just use YouTube's channel switcher while logged into your primary Google account, but I'm really scared of what sort of damage will happen if I do that. So for now, I'll just keep my 1.5 Google accounts and figure things out as I go. What a weird trip Google+ was.



What makes puzzle platformers challenging? What makes them good?

I'm a big fan of puzzle platformers - games like Portal 1 and 2, The Talos Principle, The Swapper, etc. - and I've logged many dozens of hours playing such games, mostly due to community-made puzzles. In fact, I've played over 500 community maps for Portal 2, and I've learned quite a bit along the way. Someone asked me an interesting question that really got me thinking:
When do elements that are individually passable become insurmountable or too convoluted when stacked together?
It's a great question, and I think the answer depends on a few factors: how many options plays have at each step, which options players are likely to actually notice, and what players typically think about each option. Every player is different, but that doesn't mean you can't estimate the qualities of a puzzle without players.
How many options does a player standing in the center of the room have?
An 'option' is an action the player can perform to change the state of the puzzle, and it can either have forward progress (they get closer to the solution), negative progress (they create more work for themselves), or no progress (the option isn't part of the puzzle currently). Moving two steps to the left isn't an "option" unless it changes the state of the puzzle (e.g. the player starts or stops being in the way of a light ray, or steps onto or off of a pressure plate). Placing an object at X, and placing an object a centimeter to the left of X aren't separate options unless they have different results. In the above image, the player has two neutral options and one positive option.
Why should the player press the pedestal button on the left at this point?
Knowing what the options are is only half the battle - the player has to actually understand what those options do for them. Players have a natural desire to avoid options that look like they would result in negative progress - you don't typically see players jumping into lava believing that it might advance the story. But sometimes, they do make mistakes, and misjudge options. This is where challenge comes from: looking for options and figuring out if they are good, bad, or neutral at each step of the puzzle.
Should you put the cube on the button, or take it somewhere else first? What's a safer assumption? Why?
There's two ways to solve puzzles: you can plan things out in advance, or you can evaluate your current options and pick the one that looks the best. Generally players use a combination of both tactics, so they start acting before they have the entire solution in their head, or even the entire puzzle. Sometimes it isn't possible to see the entire puzzle without acting, making it a necessity to just start doing things with little planning.
This ramp just leads to a bottomless pit, but it isn't there for decoration or aesthetics.
A puzzle is challenging when it is difficult to distinguish between forward progress options and negative progress options. Challenge does not come from not knowing what the options are, it comes from not knowing whether to even try an option in the first place. Brute force works as long as there are no trapping situations, but experienced players know that brute force is not fun, and thus they evaluate their options to determine which to try. Since every element of a properly designed puzzle will be used at some point, the question is when to choose options - what state does the puzzle need to be in for a normally negative option to be positive?
Quick, use logic to solve this maze on your first try without running into any dead ends or loops!
Easy puzzles make the options easy to distinguish, whereas hard puzzles make the options relatively indistinguishable. An analogy would be that easy puzzles have high contrast and hard puzzles have low contrast. However, there needs to be at least some contrast - otherwise the player is left with brute force. A maze has no contrast because all options look the same. An arrow on the ground telling the player where to go has too much contrast because there is no mental effort required to determine the solution.
Not only does this map present no challenge due to high contrast, it is possible to become trapped.
Challenge is only part of the story, though - puzzles of any challenge level can also be good or bad. It's easy to point to specific problems that make puzzles worse: trapping situations, too many negative options that look positive, lack of negative options, and too much contrast for the player's skill level. A puzzle with only one option at each step is no puzzle at all, nor is a puzzle where all the options result in positive progress, as it makes the player feel like their choices don't matter.
Although this map is logically challenging, it is overly punishing. Here the player needs enough velocity to get to the exit, but the most intuitive way to gain velocity gives the player too much, resulting in their death.
On the other end of the spectrum, tricking the player too frequently with negative options that look positive can be frustrating and even rage inducing. While players should be able to make mistakes, the punishment shouldn't be severe on a regular basis. The map featured in the above image is by far the most punishing map I have played - every mistake the player makes results in having to redo a large majority of the puzzle to get back to where they were and try again.
In this map, the button opens the exit, so naturally the player spends most of their time trying to get a cube into this area to place on the button. But unless they first get blue gel underneath the angled panel and in certain other key locations, getting the cube in this area is just a massive amount of negative progress that the player believes to be positive progress.
It's important to remember that the player has to reconsider all options every time they change the state of the puzzle. Having too many options and/or too many puzzle states can be mentally exhausting, rather than challenging. It's also a bad idea to allow for the player to make considerable negative progress without realizing it - the player should be able to determine that they have made a mistake relatively quickly. The feedback loop should fit within the player's attention span so that they can still remember the moment when they made the mistake. Otherwise the player can feel as though they are wandering around aimlessly trying random things without making any discernable progress. However, it's fine to make it difficult to determine when positive progress has been made - this can make the player feel like they solved something above their skill level.

Having options that never change between puzzle states can make the puzzle feel cluttered. For example, a cube that only needs to be put in one place and then never moved from that position is effectively clutter. Either the cube and its requirement should be removed, or new requirements should be added so that the cube must be used more than once. If the challenge is simply to get the cube there in the first place, then it could probably be replaced with a button for the player to press.
Every time you change the puzzle state in this puzzle, you have to carefully re-evaluate the surprising number of options again, making it difficult to plan ahead at all.
On the other end of the spectrum, having options that change too frequently between puzzle states can make the puzzle feel overwhelming. It's important that some options stay constant for a while as others change, so that the player doesn't have to focus on everything all the time.
In this puzzle, the player is meant to learn that they can travel through portals in both directions, if they haven't already. The design of the puzzle forces the player to exit the pre-placed portal, move their own portal elsewhere, and then re-enter the pre-placed portal.
But what if you want to teach the player something without challenging them, while still making a good puzzle? Good easy puzzles are typically tutorial puzzles that teach the player something new, either by carefully using contrast to highlight the new information, or by reducing the number of options such that the player naturally chooses to use the new information. The puzzle featured above has very few distinct options, even if the player doesn't yet grasp what those options are.
An example of high contrast.
In the above image, there are many more options, but there is high contrast directing the player's attention: the player intuitively understands that each cube belongs on a button, and won't waste time putting the cubes anywhere else once they obtain them. This lets the player quickly rule out options that don't result in forward progress.
Being able to disable the barrier blocking the star requires some extra steps that first-time players wouldn't try.
High contrast can be used in specific instances of more challenging puzzles to reduce the challenge of a particular aspect of the puzzle, and low contrast can be used in easier parts to boost the challenge. This allows for keeping a puzzle feeling consistent, rather than lumpy. Lumpy puzzles have some parts that are either far easier or far harder than the rest of the puzzle, and it can make the puzzle just seem weird - the lumps don't fit naturally with the rest of the puzzle. If you want to hide secrets, however, then lumps are the way to do it, as seen above in The Talos Principle.

Of course, ninjas know that many of these principles apply to more than just puzzle games, but you're totally not a ninja, so I guess you'll never find that out.


Nobody is "created" or "equal"

The phrase "everyone is created equal" is a lie. It outright denies reality and forwards the idea that people were "created" before we even knew what DNA was.

Right now, almost everyone has different DNA, and even those who have identical DNA nearly always end up with different fingerprints (though let it be known that there is evidence to suggest not everyone has unique fingerprints). Everyone is raised in a different environment because we all occupy different positions in space. To say that everyone is equal is to ignore reality.

For someone to be "created", their DNA (or their atomic structure) has to be hand-arranged by another sentient being. This is not how evolution works, and we have only recently developed the technology to "create" people. In a few centuries we may well be able to say that all new people are created, in similar fashion to Brave New World, but right now as well as in the past, it is entirely not the case.

Furthermore, I believe many people would outright reject the idea of everyone being equal - people value their independence and their unique qualities and traits, and some even go so far as to take offense at the suggestion that they are not unique. "Be yourself" is a common expression used to promote the use and appreciation of one's unique qualities, and a large part of our culture as a whole.

Instead, the real focus of equality and equity is rights. It is correct to say that everyone should have equal rights. It is incorrect to say that everyone is equal. It is easy enough to confuse these two very different things, and very dangerous to start building arguments while in such a confused state. What worries me greatly is that the source of the phrase "everyone is created equal" comes from the United States Declaration of Independence, where Thomas Jefferson is credited as writing "All men are created equal."

Jefferson may have intended the phrase to be taken only in the context of rights (because he certainly didn't need to know what DNA was to know that people look different), but the common interpretation (that literally all men are literally created and literally equal) is anything but good. Many people simultaneously believe they are both unique and equal, which is by definition impossible. This state of cognitive dissonance results in irrational decision making and unstable logical foundations. Unfortunately, the phrase goes on to be used repeatedly throughout history, and although it is nearly always used to the benefit of society, it still ignores reality and creates cognitive dissonance. (In fact, the use of the word "men" was a bit of a problem for women's suffrage, regardless of what Jefferson intended or believed.)

It is important to consider the distinctions between being equal and having equal, because it will become a hot topic before we're ready for it.

Eventually, we will have to consider rights for artificial consciousness/sentience/intelligence, where distinct copies of sentient beings will actually be both literally created and literally equal at time of creation. While cloning is physically impossible, it is already a digital reality, and I'm not aware of any laws regarding cloned persons (unless you want to say that cloning someone is piracy). What happens when a human uploads their consciousness and there are now multiple identical-yet-distinct versions of them? I suppose they cease being equal the moment they begin having different experiences, but do they have equal rights? Would it be illegal to delete backup copies? Would it be illegal to delete all copies?

If a human body dies and/or the brain suffers irreparable damage, can a digital backup legally take over their identity? Would the the law even consider them as being distinct individuals in the first place? Would electricity have to become a basic human right? Would we even use the term "human" anymore? Would a digitized human have the same rights as a constructed intelligence like HAL9000 or Skynet? Clearly they are not equal, and each digitized human is unequal from each other, while each instance of a constructed intelligence is equal at creation. Inequality has not been accepted as an argument against equal rights thus far, but would we give inequal rights to equally constructed intelligences?

Hopefully ninjas can figure it all out, but you're totally not ninjas, so I guess you'll just have to wait and see.


Why I prefer merging over rebasing in git

The argument between rebase workflow vs merge-based workflow is a lot like the argument between spaces vs tabs. There are pros and cons for each side as well as compromises in or near the middle, but at the end of the day, it mainly comes down to one person's personal preference, typically held for unspecified reasons. So I'd like to share my preferences, and my reasons, when it comes to git: the (currently very popular) version control system which features Distributed Version Control for Directed Acyclic Graphs and a Command-Line Interface that many people mock or struggle with. If you don't already know what rebasing and merging are, you should probably just look them up yourself, as I am only going to give a brief overview. If you don't even know what git is, this blog post is not for you, and you can safely bookmark it for later when you do eventually learn programming.

On one hand, you have rebasing: you change a commit's parent to the one you want it to be, and maybe fix any conflicts that result from that change. In either case, the hash of the commit changes, because in git, a commit's hash is based on itself and all commits that come before it. Changing any commit changes its has and all the commit hashes after it. (This has the excellent property that simply having a commit's hash is enough to guarantee that it will always be the same way it was when you first found it). Thus, rebasing has the effect of destroying history by changing the parents of the commits and sometimes even the content of the commits. It can also result in commits appearing in the DAG out of chronological order. But the result is a DAG which is a nice straight line.
A "clean" DAG, typical of a rebase workflow.
On the other hand, you have merging: you create a new commit which has multiple parents. It should be pretty obvious what the implications of that are. A merge commit really only describes how to resolve conflicts. If there are no conflicts, you should consider a merge commit to be effectively empty (even if it isn't actually implemented that way). Note that merging does not modify any other commits - it only creates a new one that explains how to combine others properly. Thus, history is preserved, but at the cost of making the DAG look messy.
A "messy" DAG, typical of a merge-based workflow.
For the most part, the difference is aesthetic: you either want a clean DAG and could care less for history, or you want to preserve history and could care less how the DAG looks. However, I believe there are more compelling reasons to prefer one over the other, and that the aesthetics may actually not be what they seem.

Git supports signing commits with GPG for good reason, and GitHub supports it too. When you rebase commits, you change them, and thus it is impossible to keep the signature. Instead you have to either drop the signature, or create a new signature, and 99% of the time it can only be your signature (unless you want to rebase commits one-by-one and pass the responsibility around to each author in turn). This completely defeats the purpose of signing commits. With merging, not only do all of the parent commits keep their signature, but the merge commit itself can be signed too, which is especially useful when conflicts have to be resolved. This alone would be enough for me to avoid rebasing except in special cases.

But even if you don't bother with signing commits (even though you should), I still think it is important to preserve history. I'm not worried about little things like commits being out of chronological order. I'm concerned about making changes to resolve rebase conflicts. No matter what version control software you use, there will be conflicts that arise from simultaneous development. (Unless you don't allow simultaneous development, which is stupid). There are even conflicts which don't manifest at rebase or merge time, and are only evident when trying to compile the code or run the program. (For example, a unused variable is deleted in one branch, and another branch adds code that uses the variable - both independently work, and when rebasing or merging git will not detect any conflicts, but the resulting code will not compile without modification - I typically check for this during the merge and make changes in the merge commit).

With rebasing, you have to either modify commits to resolve conflicts (and which commit(s) do you modify?) or you have to create a new commit that resolves the conflicts (which is basically a merge commit with one parent - the wrong parent). This also causes trouble when bisecting the DAG - suddenly you run into code that would have normally compiled with a merge-based workflow but now doesn't compile due to the rebase-based workflow (if you don't modify each commit during the rebase to ensure it compiles). In either case, you are changing the commit authors' original intentions. They originally intended for their commit to be based on the parent(s) it was already based on, and they probably didn't intend for someone to modify their commit. Git does support multiple authors on a commit (but only one committer), but are you really going to go through all that effort? And how will you know which changes are attributed to which authors? This alone is enough of a headache for me to avoid rebasing except in special circumstances.

With a merge-based workflow, these problems do not exist: you never need to modify a commit, at all. No commit hashes are ever changed. Everything remains exactly as the author originally intended, and conflicts are resolved where they should be: in the merge commit. You have preservation of history as a side-effect.

As for the aesthetics, a rebase workflow only hides the complexities of parallel development. It hides them in a way that makes them difficult to rediscover when you need them. I don't believe you will never need to know how or why a change occurred in the past. A merge-based workflow doesn't try to hide the real complexity, and also makes it dead simple to discover it when needed: just look at the DAG. No detective work required, no bothering with commits not in chronological order, or wondering if all the changes in a commit were really made by the commit's author.

If understanding how and why code changes over time wasn't important, we wouldn't be using version control software like git; we'd be using dumb snapshot backups (aka primitive version control). This is a case where hiding complexity makes it harder to understand what has really happened. Again, this alone is reason enough for me to use a merge-based workflow.

Since there are multiple reasons to use merge-based workflows that I have said are reason enough alone, I think it's pretty obvious I almost never touch rebase. But I encourage you to do the research and make decisions for yourself, rather than just listening to the one guy who preferred one over the other for unspecified reasons or because "it makes the DAG look better". Of course, ninjas already know to do that, but you totally aren't a ninja, so I guess you just forgot.
I had a good reason for this, I promise. But I also wanted to see what it would look like.