fyeahcode

If you’re living in the EU, Tumblr had to tell you what they’re doing with your data when you recently logged in. They also gave you the choice to disable data sharing with all their partners — for that, you just had to untick 327 checkboxes.

But fear no more, because with a bit of JavaScript I just wrote, they all untick immediately!

If you already left the page crying and screaming and with anger on your face, getting it back to apply the JavaScript is simple. On your dashboard, click on Account → Settings → Privacy and uncheck “Cookie Consent”:

Then, when on the page, click Manage Options → Manage → Show.

Open the developer console (*), paste the following snippet and press enter:

Array.prototype.forEach.call( document.querySelectorAll("[type='checkbox']"), (e) => e.checked = false );

And all your 327 problems are suddenly gone!

* How to open the console:

Chrome: Ctrl+Shift+J (Windows), Ctrl+Option+J (Mac)

Firefox: F12

Edge: F12

If you were asking me about THE one thing I’d suggest to every programmer, it’s this: Write unit tests.

Everybody knows they should, but many still don’t. Just do it. Learn the framework for your language, it’s worth it. Not only does it help you save possibly many hours of painful debugging in the long term, it also makes you rethink how you structured your code, rethink what it should be doing in the first place.

Not programming related, but THIS IS THE REAL ORIGINAL iPhone. Yes, that thing existed. There’s even a November 2, 1998 CNN article about it: http://edition.cnn.com/TECH/computing/9811/02/netphone.idg/

... write 100%-covering unit tests;

... set up continuous integration, linters, hinters, style checkers, ...;

... follow style guides for every language;

... meet impossible deadlines;

... meet impossible management/customer/end user expectations;

... read through terrible code others made;

... read through terrible documentation others made;

... make terrible documentation themselves;

... fight with the IDE;

... fight with the build tools;

... deal with unreproducible crash reports coming in from everywhere;

... debug code written at 2am (by themselves AND others);

...

...

...

TL;DR: Before you try to fix the error, know for certain where it comes from.

Now, this seems obvious, right? And it is. Yet, I didn’t follow this principle a few days ago, and I beg you not to make the same mistake.

A little backstory. I deployed a rather huge web app I’m writing on a brand-new server. After I had set up the database, I gave it a quick test-run and Node.JS’s generic ECONNREFUSED error popped up. Now, due to the fact that I had just worked on the database, my brain made a connection where there shouldn’t be one.

I proceeded to work on “fixing” the database for the following 7 hours, ripping every last nerve of mine out in the process, without any result. Could connect via CLI, via telnet (even remotely!), via the web interface, only my code kept endlessly throwing the same error.

Then it dawned on me. I added another string to the statement that prints database errors – and it didn’t appear, the message stayed unchanged. How could this be possible?

Well, I hadn’t yet installed the mail servers, and that was where the error actually came from, since Node couldn’t connect to those (which makes total sense, right?). But, never had I spent a single thought on just trying out whether the database worked; never had I spent a thought on the fact that the message was so generic and could come from literally anywhere.

There were many things that I found to be “super cool” when they happened. Yet, it doesn’t feel like I’m at the point already where I can look back and say that something absolutely killed it.