dependencies and devdependencies

been a while since I never code any bugs anymore but I thought I'd mention:
if you have rails webpacker upgrade issues with the webpack loader not finding random files when you build in staging, try moving pipeline and compilation and babel related dependencies out of devDependencies in your package.json and into the main dependencies block. worked for me!

facepalms: 7 (only took 5 hours to figure it out...)

compiling and then transpiling sveltejs: babeljs, webpack, and a safari 9 problem

Been 2 years since my last post here!
just had a very fun deep dive into this annoying bug that was only affecting this one old browser.

I wrote it up here:
https://stackoverflow.com/questions/57019417/how-to-transpile-compiled-svelte-with-babel-for-safari-9/57019418#57019418

Anyway if you haven't checked out https://svelte.dev I highly encourage it - it's faster, easier, and cooler than reactjs.

This bug took me 5 hours to find and fix, but it was a fun and interesting sleuthing session the entire time that has left me feeling proud of my abilities, so I'm gonna go with facepalms: only 2 on this one.

mobile touch gotcha

I once made an angular firebase demo site called Fridge Magnets With Friends.
You can move magnets around on a virtual fridge. This involves a lot of dragging elements.
One day mobile drag stopped working, even tho I employed the clever jquery ui touch punch.

I spent hours switching the whole thing to use ngDraggable, because their mobile demo did work in mobile. Altho using ngDraggable required me to take out jquery (actually it didn't, but some forums said that would help make it work in mobile) - so I spent a while redoing the angular app without jquery.
Moment of truth: no luck.

Finally I hijacked the browser with a little shim code:

        $document.on('touchstart', function(e){

            console.log(e)

                            });

Because for the life of me I couldn't figure out why my elements weren't receiving the touchstart event in mobile.
This way I could see what element the e event was pointing to.
Turns out my footer CSS was very improperly done and covering the entire screen, so the event for touchstart, which has to have a stoppropogate() for other reasons in mobile only, never made it to the dragable elements.
Took out the footer and both solutions started working; however, jquery-ui + touch-punch still worked better than ngDraggable, so in the end, 4 hours of work (work that was, admittedly, kind of fun) got reduced to commenting out a couple lines of html. At least I understand mobile touch events now.

facepalms: 9.5

CSS property of the day: pointer-events

Do you have an absolutely positioned div that you want to show up on top of another element, but you want click and hover events (for instance) to pass through to the back element? Not such an uncommon use case!
just call our old (new, for me) friend

pointer-events: none;

And it'll pass those events right through.

facepalms: 1 (either I'm getting better at CSS or I just got lucky. According to this hilarious article, I got lucky.)

quick note on webpack imports and es6 class inheritance

I know it's crazy that I'm only now using modern javascript class inheritance for the first time, but I've been more of a backend programmer most of my career.

I've got a new hobby project that I'm doing with modern webpack / es6 / vue.js, and I just learned something that I didn't find an obvious answer to in the googs.

Basically, I'd been creating utility files with instantiated objects saved as var whatever or let whatever and then exported at the bottom:

export default {
  obj: obj
}

And this was all well and good. But then when I wanted to define a class in the same file, the export default was overriding keyword "this". So the functions defined on the class referencing this were actually referencing my export default. I could use a fairly circular reference to get back to the instantiated class object, but really that whole route is silly.

The way to make this work is to define (but not instantiate) each class in its own file. The class itself is your export default in that file:

export default YourClass extends Whatever {
  constructor () {
    this.stuff
  }
  yourFunction () {
    this.stuff + 1
  }
}

Then instantiate the class and use it in another file. Should have been obvious but well es6 takes some getting used to.

on being a professional coder

I recently finished Robert "Uncle Bob" Martin's The Clean Coder and I'd like to use this space to share, very briefly, my takeaways from the book, as I head into a new team lead position.

• Accurate estimation of coding tasks is essential if you want to maintain trust between coders and managers
• don't be afraid to push estimation back due to scope creep, etc
• TDD is a way to write better code faster in the long run 
• (I already knew this but it was good to hear it again [and again, and again, and again])
• Pair programming is also a way to write better code faster in the long run
• Never tried this in depth, but I'd really like to. Guess as a team lead that might even be up to me!

anyway I'm inspired to be more professional in my coding life, so I guess he succeeded. Book's a quick read, too.

ad blocking "controversy" aka foolishness

tl;dr:  If your website can't make money without crappy ads, and nobody looks at your crappy ads because of advances in technology, then blaming that technology puts you squarely on the wrong side of history.

The creator of peace, one of the most popular iOS ad blocking apps, just pulled his app after a day and a half because it "didn't feel right" to him. While that's his choice, this strikes me as misguided.

There's been a lot of media coverage lately about ad blocking, and complaints about a regurgitated and irrelevant tech news cycle aside, I have seen a quite a few well meaning people stating something like:

ads make the internet go round. it's irresponsible to enable ad blocking software.

As a web developer and armchair philosopher, I'm on the record as being for ad blocking software, insofar as I think it only makes the internet a better place. Crucially, I'd remind the reader that under our current more-or-less capitalist system, no business models are guaranteed by government or (mostly) morality. And tho I think capitalism has some blind spots (see healthcare, maybe?), advertising on the internet ain't one of them.

We would only improve the internet by striking back against giant, centralized ad serving systems. How anyone could honestly defend cross-site targeted ads is beyond me. Do they improve anyone's browsing experience? Do they honestly make all that much money for the sites that run them? For the businesses that pay for them?

I humbly submit that any website that subsists on google (or similar, but right now it's mostly google)'s ad network, that could not possibly conceive of another way to monetize (of which I'll speak more below) does not deserve to make money. This is the good part of capitalism. This is how we improve technology and social organization as a species. This is the process that government interruption / manipulation frequently subverts (see: the DMCA, drug laws, FCC regulation, oil subsidies, etc).

In fact, the DMCA is a useful parallel from recent history: Pirating music is very different from stealing a physical CD, all whiny record execs to the side. But a powerful industry complained that their business model had become obsolete, and instead of letting that business model die a natural death, our government guaranteed it with the DMCA's intellectual property laws. As a result, we are stuck with all sorts of negative externalities. I'd write more about it but Cory Doctorow explains it way better.

Without the DMCA, all the useless blood sucking middlemen (aka giant record labels) would have evolved or shrunken away, and maybe our entire culture would have been better off (fewer cookie cutter pop stars, anyone?). Smaller labels would have had no trouble monetizing, just like they do today anyway - with more interesting physical releases, more/better concerts, a resurgence in vintage-format media, pay-what-you-can downloads, free streaming to help spread music, and much more.

Ad blocking is the same way. I wouldn't be surprised if Google lobbied congress to pass an anti-adblocking law. When you think about it, and for the reasons stated here, it'd be very similar to the DMCA. Google has enough at stake here to make spending hundreds of millions in lobbying dollars quite worthwhile for Google. And as we know, congress is cheap.

Instead of rooting for the old ad-supported paradigm, let's brainstorm how a newer, sleeker web could monetize:

• more thoughtfully crafted ads, negotiated more directly with businesses, not served from ad farms, and hence not so easily blocked (aka native ads)
• opt-in / crowdfunded memberships with perks (plenty of tipping services out there on the net)
• merchandising
• online or offline "rent party" type fundraisers, where website fans could meet and mingle
• In general, new products that people are more interested in paying for

To reiterate and conclude: if your website can't make money without crappy ads, and nobody looks at your crappy ads because of advances in technology, then blaming that technology puts you squarely on the wrong side of history.

A similar opinion I just found:
https://snelling.io/on-ad-blocking