bluepnume

Show me some code you can only write using either call, apply, or bind.

Call, bind and apply should be discarded and forgotten about, they add too much confusion, there are better ways, and they end up being used as terrible interview questions.

Incidentally, we should also discard `this`, unless directly inside an instance method of a class.

Before you post a comment about Bitcoin fees, please take a little time and try out lightning. It's come an incredibly long way, it's very fast, and very cheap, and very easy using a mobile wallet.

The Waldo example is more an explanation of "what" a ZKP is than "how" a ZKP works. Not a terrible starting point, but yep, definitely doesn't capture the complexity of the real deal.

> Hey everyone, I want to apologize for the inappropriate use of power here. I should have called him to understand his point of view and work it out. Which is what I'll try to do now, and see if we can get his project back up again. I'm sorry Radon.

> The lesson for me here is that I now have a responsibility towards our community and supporters to be kind and model better behavior. I'm sorry I let you down and I promise to do better in the future.

Fixed it for ya!

Of course, apologies. Should have been clear I was talking about 2MB+ blocksize rather than segwit. Some great points!

Take a look at "The Blocksize War" for a fantastic rundown of the events that led to Bitcoin not increasing its throughput.

TLDR: Massively rushed changes, pushed by people with a lot of power on the network (miners and corporations), which ended up being largely antithetical to Bitcoin's decentralization thesis.

Bitcoin's value is in its stability, its decentralization, and its lack of hurried change. It is in the control of everyone, not just the powerful actors in the system. Its value is not in its ability to pivot every few years like a startup to fulfill some new purpose.

I tried doing the same in JavaScript/JSX a small while back: https://medium.com/@bluepnume/writing-regex-in-jsx-without-r...

Building regexes programmatically does seem to take a lot of the pain out of it.

I actually don't mind this too much -- because "Yeah", "Right", "OK" and so on are often just used as passive acknowledgements that I've said something, rather than an assertion that what I've said makes sense, is agreeable, and is fundamentally correct.

Yup. This is known as 'double submit'. https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...

Very cool! I remember working on an evolutionary algorithm at one point to generate CSS versions of images using random fonts, positions and transforms. The results you've got here are very impressive.

Neither question gives a specific enough answer to get us out of the current mess.

Referenda are great for when you have a specific plan of action, and the question is just "implement this plan: yes or no".

Anything less, and nobody is clear what anybody was actually voting for. There's a reason Parliament votes on legislation after it's written, rather than before.

That's a fair point. I wonder if 'make network calls' was ever considered as an app permission, or if it was just considered so ubiquitous that it would be granted by default. Or if there was any thought made around 'same domain' and 'cross domain' restrictions for apps.

Yes. But according to MDN it's largely unimplemented.

The point where this becomes annoying is, when you're building a third party app or experience that is designed to be embedded in an iframe. Not a hidden iframe to track users, or for advertizing, but as a first-class experience, which can be embedded and displayed on a page on a different domain, and interacted with by users.

I wish the latest round of privacy restrictions (which I think are overall a decent idea) would take these use cases into account, or at least allow a mechanism to request the user's permission to use third party cookies for sites they trust.

Native apps have pretty robust permissioning systems. Why shouldn't websites?

(For context, these are some of the things we use at PayPal to build embeddable cross-domain components: https://medium.com/@bluepnume/introducing-paypals-open-sourc...)

Very neat! Now just need to figure out how to plug svgo into my jsx rendering pipeline, at build time.

The thing that I find difficult with OWASP: there doesn't always seem to be comprehensive examples provided for what these attack surfaces could be used for. That makes it difficult to both understand the impact of a particular issue, and test for it.

As an example: https://cheatsheetseries.owasp.org/cheatsheets/AJAX_Security...

I'm fascinated to know how this could actually be exploited. But there's no hint or reference to that. It's just "don't do this".

PayPal | Mid/Senior JavaScript and Mobile Engineers | San Jose, CA | Non-remote | Full-time | https://www.paypal.com

Looking for mid-level and senior engineers to join the PayPal Checkout team.

We're building out the next generation of checkout products and SDKs in node.js, javascript, graphql, ios/android, and whatever awesome tech you bring to the table. We're really trying to innovate around what it means to checkout online, and we're all about hiring engineers who are interested in shaping both our technology, and our products.

Shoot me an email at dbrain [at] paypal [dot] com and let me know the kind of role you're interested in, and I'll let you know if there's a good fit for you!

Vouching for Ty. Been working with him on brainblocks.io for the last few years, the guy is a solid engineer, leader, and a fast learner. Had a fantastic experience working with him!

I wrote a quick article on the differences between portals and iframes: https://medium.com/@bluepnume/google-chromes-portals-like-if...

I work on the client-side javascript SDK for PayPal (documented at https://developer.paypal.com/docs/checkout/).

We took Michael's feedback from his original article at https://fman.io/blog/paypal-for-saas-99-problems/ very seriously. We're not all of the way there yet; but if anyone has any remaining concerns about the integration, I'd be glad to take them onboard!

Sure -- but the majority of that static analysis (in the absence of type annotations) is inferring types and then running everything through the type-checker, right?

Good point! Let me update.

I was going for unique keywords with no repetitions.

I got to 14 (now 15!) in javascript so far:

    async function* foo() {
        return yield delete void await null in this instanceof typeof new class extends async function () {} {}
    }

(not sure whether the code needs to successfully run? But it at least parses)

What's really fun is seeing how babel transpiled the above function:

https://babeljs.io/repl/#?babili=false&browsers=&build=&buil...

EDIT: here's an explanation https://medium.com/@bluepnume/how-many-keywords-can-you-plac...

Ironically though, using _.get or _.set makes that code virtually impossible to type.

I maintain PayPal's cross domain suite of libraries [0] and I'm fully intending to drop Flow for TS. The single thing I'm waiting for is https://github.com/Microsoft/TypeScript/issues/21699 since we use a fair amount of custom jsx rendering [1]. That's the one main thing (for me) that Flow is way stronger at right now.

[0]: https://medium.com/@bluepnume/introducing-paypals-open-sourc...

[1]: https://medium.com/@bluepnume/jsx-is-a-stellar-invention-eve...

> Show me a Typescript codebase not using the type 'any'!

https://github.com/krakenjs/zoid

Admittedly Flow, not TypeScript -- but 99% the same thing syntax-wise. And yes -- it was difficult to set up and get working comprehensively, but now it's there, it's fairly easy to maintain, and it's invaluable when refactoring, accepting PRs, or adding new features.

Most people using `any` should really be using `mixed` (flow) or `unknown` (ts) which at least force you to check before you use some property of those types.

As someone who deals with a lot of browser features which are already a little quirky, like iframes, popups, and cross-window messaging -- I've found Edge makes little to no improvement on IE. The number of corner cases the browser fails to support is astonishing. So I'm absolutely glad to see it being dropped.

I built out https://github.com/krakenjs/fetch-robot to avoid some of the esoteric issues around CORS endpoints -- and to avoid the performance hit of that preflight request.

It acts as a `fetch` implementation that allows you to declare cross-origin policies in advance, then channel the requests through an iframe which enforces those policies.

I built a little library to help solve this problem: https://github.com/krakenjs/fetch-robot

All requests are channelled through an iframe on the domain you want to make requests to; then the iframe publishes a policy for which requests are allowed to go through.