Aram Zucker-Scharff

If I see one more ‘this election is Facebook’s fault’ tweet, take or thinkpiece I might spontaneously combust. Could you any more miss the point?

Facebook is a tool for more efficiently deciding what content you see. The problem has never been how we look out on to the world, but what we choose to perceive. This was always the case, Facebook just makes it more visible. There are no excuses. No one walked into the voting booth and accidentally voted for Trump. Even his biggest supporters were aware of the litany of allegations. The debates were the most watched of all time. But people saw what they wanted to see and voted how they wanted to vote.

If we want to look at a media failure, it was in the primaries, it was early 2016. We created momentum around Trump almost by accident and he used it to mobilize. But the last few months have been filled with excellent well-publicized coverage. Trump voters knew who they were voting for because it was impossible not to.

So, if you want to point fingers for the state of the election, we can look to the media, the economics of journalism, the politicians, the advocates, the funders, the fundraisers and, more than all that, the people who voted. Looking there is where you’ll find understanding, motive, interest, fear, avarice, love and hate. That’s the story. Those things aren’t in an algorithm. They aren’t the functions that drive the engineering of social media.

Instead of continually trying to pass the blame to a robot, do useful reporting about the people who voted, the communities they are in, the way they think. This election is on us. Humans. We don’t get to put that on anyone else’s shoulders.

If this is a failure, we failed. If this is an opportunity to rise, we have to grasp it. If resistance is required we must provide it. If watchdogs are needed, we have to pay attention. If someone must speak then only we can do it. There is no Uber for a better humanity. Just us.

I’m now keeping a collection of terrible awful no-good ad-tech code. This isn’t just code that tracks you, I mean code that is actually written terribly and breaks sites all around the web.

All of this is simply obtained by clicking on the link in the console to the file that contains the terrible ad code when it is executed on the site. Occasionally I run it through jsbeautifier for your pleasure.

Many of these scripts are run (usually breaking themselves, if not the sites they are on) daily across the web.

So here we go:

• AdapTV
• TruEffect
• Moat Video

Sometimes you’re working with an open-source code library that has a number of interested contributors but has been abandoned by the project maintainer. There are a few options for keeping the project up to date. The most obvious one is to cut the branch off the tree and start your own repository. However, that’s not always the optimal solution. Sometimes the maintainer is fairly high profile, or the code is linked in a lot of places, or for whatever reason abandoning the base git tree just won’t work.

In that case, there are options for essentially running the project from upstream; where you keep your branch attached to the original project tree, but pull in the pull requests from other interested parties. Using this technique you can keep your branch up to date with the best pull requests, but without fracturing the project. In addition, if the project maintainer ever comes back, they’ll have a handy single pull request with all the new features that you’ve been maintaining.

This is based on a StackOverflow response.

First you’ll want to add the other upstream fork as a remote of your repository.

git remote add otherfork git://github.com/request-author/project.git

otherfork in this example is the name you are giving the remote repository (like origin). You can add as many other forks as you’d like, as long as you give them different names.

If you find that the other upstream repository is storing their commits for the pull request on something other than their master branch, then you’ll need to bring those other branches in too.

git fetch otherfork patch-branch

Once that is done, you can treat otherfork/patch-branch like any other branch in your repository. If you want to bring in the commits from the pull-request on the downstream project, you have a few options.

You can cherry-pick the SHA of the commits you want to integrate:

git cherry-pick <first-SHA1> <second-SHA1> <etc.>

You can use a standard merge, or a git pull:

git merge otherfork/patch-branch

or

git pull otherfork patch-branch

Using these methods you can have your version of the codebase living upstream of the project base but still examine, test and merge pull requests to the base as if you were the project maintainer. This should make it easier to have up-to-date code without fragmenting the project.

First install the JSHint package for Atom.

At the base of your project you’ll need a .jshintrc file. It should enable ES6.

{
	"esversion" : 6
}

Then under Atom -> Open Your Config add the following:

jshint:
  supportLintingJsx: true