HN user

schneidmaster

1,417 karma

Engineering at Stripe, formerly at Aha!

[ my public key: https://keybase.io/schneidmaster; my proof: https://keybase.io/schneidmaster/sigs/42F6vHEpWZf-fXGXQSJaCk4h9Lx8DDTyBKkGpaFLIpM ]

Posts46
Comments205
View on HN
hacktoberfest.digitalocean.com 5y ago

Hacktoberfest Changes to Opt-In

schneidmaster
3pts1
about.gitlab.com 5y ago

Gitlab Security Release: 13.3.4, 13.2.8, and 13.1.10

schneidmaster
1pts0
www.aha.io 6y ago

A Treatise on JavaScript Dependencies

schneidmaster
1pts0
www.aha.io 6y ago

Transaction Deadlocks on ActiveRecord Associations

schneidmaster
2pts0
www.aha.io 6y ago

Implementing search on a static site with Netlify functions

schneidmaster
1pts1
www.zdnet.com 6y ago

Google Chrome to hide notification spam starting February 2020

schneidmaster
8pts0
www.aha.io 6y ago

Put Your Engineers on Support

schneidmaster
2pts0
schneider.dev 7y ago

Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo

schneidmaster
526pts153
www.aha.io 7y ago

Our Secret Sauce Is React Native

schneidmaster
1pts0
fivethirtyeight.com 7y ago

When We Say 70 Percent, It Means 70 Percent

schneidmaster
7pts0
schneider.dev 7y ago

Anatomy of a Phishing Attack

schneidmaster
2pts0
schneid.io 7y ago

event-stream vulnerability explained

schneidmaster
10pts0
blog.aha.io 8y ago

Show HN: Aha mobile app (built with React Native)

schneidmaster
12pts0
medium.com 8y ago

Webpack 4 Beta released

schneidmaster
168pts125
techcrunch.com 8y ago

Navdy contacts would-be creditors, prepares to liquidate

schneidmaster
1pts0
github.com 8y ago

GitHub is down

schneidmaster
4pts1
blog.aha.io 8y ago

Debunking arguments against remote work

schneidmaster
5pts0
blog.aha.io 8y ago

How to run a remote team meeting

schneidmaster
16pts1
blog.aha.io 8y ago

How I Convinced Our CTO to Switch from CoffeeScript to ES6

schneidmaster
6pts0
twitter.com 9y ago

Tweet thread from the founder of hapi.js about maintenance and financial support

schneidmaster
11pts0
schneid.io 10y ago

Email Apps Suck

schneidmaster
52pts83
www.washingtonpost.com 10y ago

As a psychiatrist, I diagnose mental illness and help spot demonic possession

schneidmaster
57pts73
github.com 10y ago

Consider deprecating Bower. (#2298)

schneidmaster
5pts3
github.com 10y ago

Show HN: React bindings for Rails 5 ActionCable

schneidmaster
2pts0
blog.aha.io 10y ago

Why You Should Not Major in Engineering

schneidmaster
3pts0
blog.aha.io 10y ago

Why Doesn’t Every App Autosave?

schneidmaster
2pts0
blog.aha.io 10y ago

Just Open Sourced: Log Search Built on Google BigQuery

schneidmaster
6pts0
www.nytimes.com 10y ago

Legion of Tech Volunteers Lead a Charge for Bernie Sanders

schneidmaster
24pts9
blog.aha.io 10y ago

The Product Manager vs. Project Manager

schneidmaster
10pts0
schneid.io 10y ago

Writing Tests for Rails: Continuous Integration

schneidmaster
2pts0

Change of venue and jury sequestration are controlled by the judge, not the prosecutor, and thus definitionally cannot be prosecutorial misconduct. And it's not misconduct for a prosecutor to disparage the defense in front of the jury unless it's extreme or falls into specific categories. Generally the prosecutor's entire job is to make the jury not believe the defense's story.

That's what I meant by the devil being in the details -- these gray area questions hinge on the specific facts. Lawyers on both sides will argue which factors apply based on past caselaw and available evidence, and the court renders a decision. For example, from the Stanford webpage I previously linked: "the creation of a Harry Potter encyclopedia was determined to be “slightly transformative” (because it made the Harry Potter terms and lexicons available in one volume), but this transformative quality was not enough to justify a fair use defense in light of the extensive verbatim use of text from the Harry Potter books". So you might be okay creating a Harry Potter encyclopedia in general, but not if your definitions are copy/pasted from the books, but you might still be okay quoting key lines from the books if the quotes are a small portion of your encyclopedia. The caselaw just doesn't lend itself to firm lines in the sand.

Again, not a lawyer, just a guy who likes reading this stuff. The devil is usually in the details of copyright cases. The Turnitin case hinged substantially on whether Turnitin's use of copyrighted essays was "fair use". There are four factors[0] which determine fair use; the two more relevant factors here are "the purpose and character of your use" and "the effect of the use upon the potential market". The court found that Turnitin's use was highly "transformative" (meaning they didn't just e.g. republish essays; they transformed the copyrighted material into a black-box plagiarism detection service) and also found that Turnitin's use had minimal effect on the market (this is where "computers don't count" comes in -- computers reading copyrighted material don't affect the market much because a computer wasn't ever going to buy an essay).

I would be shocked if GitHub's lawyers didn't argue that using copyrighted material as training data for an AI model is highly transformative. There may be snippets available from the original but they are completely divorced from their original context and virtually unrecognizable unless they happen to be famous like the Quake inverse square root algorithm. And I think GitHub's lawyers would also argue that Copilot's use does not affect the _original_ market -- e.g. it does not hurt Quake's sales if their algorithm is anonymously used in a probably totally unrelated codebase.

Your counterexample would probably fail both tests -- it's not transformative use if your software hands out complete pieces of copyrighted software, and it would definitely affect the market if Copilot gave me the entire source code of Quake for my own game.

[0] https://fairuse.stanford.edu/overview/fair-use/four-factors

There's a decent bit of caselaw indicating that computers reading and using a copyrighted work simply "don't count" in terms of copyright infringement -- only humans can infringe copyright. This article[0] does a pretty good job of summarizing the rationale that the courts have provided. My (non-lawyer) take is that GitHub is pushing this just half a step farther -- if computers can consume copyrighted material, and use it to answer questions like "was this essay plagiarized", then in GitHub's view they can also use it to train an AI model (even if it occasionally spits back out snippets of the copyrighted training data). Microsoft has enough lawyers on staff that I'm sure they have analyzed this in depth and believe they at least have a defensible position.

[0] https://slate.com/technology/2016/08/in-copyright-law-comput...

This attitude makes me kind of uncomfortable.

I think the point though is that security warnings need to be actionable and high-signal. Experienced folks are absolutely tuning out the security warnings on npm install, because 95% of the warnings are like the examples in the post -- I know they don't affect me/my use case and there's nothing I can do about them anyway. The effect is only compounded for novices who run "npx create-react-app hello-world" and immediately see something incomprehensible about a vulnerability in react-scripts > webpack > watchpack > watchpack-chokidar2 > chokidar > glob-parent. It either discourages them from programming entirely or it teaches them to ignore security warnings.

I don't disagree with your overall point -- e.g. we should absolutely teach novices "here's what XSS is and how to avoid it" early and often. But if a dependency manager is going to surface a vulnerability alert every time I install dependencies, the alerts should be 1) high severity (to the point where I should actually stop using the package if I am unable to patch/upgrade) or 2) at least immediately actionable. The current npm audit implementation does the opposite -- 95% of the alerts are totally irrelevant to my actual security posture, and the suggested command to upgrade a vulnerable dependency is unreliable and can actually downgrade to an older, even-less-secure version (!).

Sublime Text 4 5 years ago

I've used the following list of packages for eslint, prettier, and TypeScript. It's not as effortless as it should be, but the two LSP packages in particular do give reference navigation that's pretty equivalent to VS Code.

- https://packagecontrol.io/packages/SublimeLinter

- https://packagecontrol.io/packages/SublimeLinter-eslint

- https://packagecontrol.io/packages/JsPrettier

- https://packagecontrol.io/packages/LSP

- https://packagecontrol.io/packages/LSP-typescript

If you're on macos, I also recommend creating a file at ~/Library/Application Support/Sublime Text 3/Packages/User/Default (OSX).sublime-mousemap with the following contents -- this adds a cmd+click "go to definition" shortcut that's also equivalent to what VS Code provides. (I guess the path should be "Sublime Text 4" now? but after upgrading, the config at the "Sublime Text 3" path still works for me.)

[ { "button": "button1", "count": 1, "modifiers": ["super"], "press_command": "drag_select", "command": "lsp_symbol_definition" } ]

I've tried to switch to VS Code a few times -- language features (especially TypeScript) tend to work better out-of-the-box but it still isn't close in terms of performance. If you want IDE-like features to "just work" then VS Code is definitely the best choice, but the persistent (albeit sleight) input lag drives me up the wall.

AJAX (Asynchronous Javascript and XML) is purely orthogonal to DOM updates. An AJAX request is just a network request initiated asynchronously via some Javascript on the page, as opposed to a request initiated synchronously when a user clicks a link or submits a form. Response data from an AJAX request could be used to make a direct DOM mutation, update React state, log to the console, or anything else the developer wants.

Most of the issues on that dashboard don't seem related to the JS SDK, e.g. "Increased latency on marketing insights API" and "Instagram comments webhooks event delivery traffic drop". It's a blended view of every(?) Facebook developer product but you'd usually calculate 9's for each individual product.

Police absolutely do not have to read your Miranda rights in order to arrest you -- they only need to read your rights if they plan to question you with regards to a criminal investigation and they would like to use your statements as evidence in a court of law.

Breyer has actually been writing on these issues for quite some time; see for example his article "The Uneasy Case for Copyright: A Study of Copyright in Books, Photocopies, and Computer Programs" [0] -- published in the Harvard Law Review in 1970. His overall body of work demonstrates a pretty good understanding of the underlying technical issues, and he has been a reliable ally on the bench in this area.

[0] https://www.jstor.org/stable/1339714?seq=1

Aha! (https://www.aha.io) | Rails / React / Security | REMOTE

Aha! is the #1 tool for product managers to plan strategy and roadmaps. We serve more than 300,000 users worldwide.

We are looking for:

* Experienced full-stack engineers to work on the Aha! product. Our application is built in Ruby on Rails, with some React on the frontend for rich client-side experiences.

* Security engineers, with hands-on Rails development experience plus experience with compliance projects, security policy development, or other security initiatives.

* A senior product manager with experience serving the needs of product and/or engineering teams.

Aha! is profitable, you can work from anywhere in North or South America, and we offer excellent benefits. We use our own product to manage our work (which is especially rewarding) and we deploy continuously.

Our entire team is remote - in North American timezones so we can collaborate during the work day.

You can view open engineering positions at https://www.aha.io/company/careers/current-openings, and click through to a specific job for our simple application form. Our job postings also have a lot more detail about the team, our values, and what you'd be doing day-to-day.

Me and ADHD 5 years ago

Google tells me that coffee has about twice as much caffeine as black tea (depending on the blend) so your 10+ cups of tea are probably similar to my previous 5+ cups of coffee. Obviously I'm not a doctor and I can't diagnose anyone over the internet, but if you're drinking that much and it doesn't have you wired or give you trouble sleeping then you might consider talking with your doctor about ADHD.

Me and ADHD 5 years ago

Not really. Even when I first started drinking coffee (around high school) I never got much of a boost from it. I think your caution makes sense for folks with neurotypical brains, but even now (drinking 0-1 cups per day) I drink it for the flavor and/or social aspects, not because it does much for my energy or productivity.

Me and ADHD 5 years ago

Coffee consumption was actually one of the questions that I was asked when my therapist first suspected that I had ADHD. I used to drink 5+ cups per day (especially workdays) while feeling fairly little effect from it. I'm now on medication which works an order of magnitude better for managing my symptoms, and I rarely drink more than 1 cup of coffee per day.

It's also worth noting that ADHD often comes with other mental health comorbidities; in my case, it exacerbated my depression. I would often fall into a spiral of inability to focus -> feeling bad about myself for not completing work that I was generally more than capable of doing -> even less ability to focus. I still have depression, but starting on ADHD medication all-but-removed my most frequent trigger.

Aha! (https://www.aha.io) | Rails / React / Security | REMOTE

Aha! is the #1 tool for product managers to plan strategy and roadmaps. We serve more than 300,000 users worldwide.

We are looking for:

* Experienced full-stack engineers to work on the Aha! product. Our application is built in Ruby on Rails, with some React on the frontend for rich client-side experiences.

* Security engineers, with hands-on Rails development experience plus experience with compliance projects, security policy development, or other security initiatives.

* A senior product manager with experience serving the needs of product and/or engineering teams.

Aha! is profitable, you can work from anywhere in North or South America, and we offer excellent benefits. We use our own product to manage our work (which is especially rewarding) and we deploy continuously.

Our entire team is remote - in North American timezones so we can collaborate during the work day.

You can view open engineering positions at https://www.aha.io/company/careers/current-openings, and click through to a specific job for our simple application form. Our job postings also have a lot more detail about the team, our values, and what you'd be doing day-to-day.

Aha! (https://www.aha.io) | Rails / React / Security | REMOTE

Aha! is the #1 tool for product managers to plan strategy and roadmaps. We serve more than 300,000 users worldwide.

We are looking for:

* Experienced full-stack engineers to work on the Aha! product. Our application is built in Ruby on Rails, with some React on the frontend for rich client-side experiences.

* Security engineers, with hands-on Rails development experience plus experience with compliance projects, security policy development, or other security initiatives.

* A senior product manager with experience serving the needs of product and/or engineering teams.

Aha! is profitable, you can work from anywhere in North or South America, and we offer excellent benefits. We use our own product to manage our work (which is especially rewarding) and we deploy continuously.

Our entire team is remote - in North American timezones so we can collaborate during the work day.

You can view open engineering positions at https://www.aha.io/company/careers/current-openings, and click through to a specific job for our simple application form. Our job postings also have a lot more detail about the team, our values, and what you'd be doing day-to-day.

Aha! (https://www.aha.io) | Rails / React / Security | REMOTE

Aha! is the #1 tool for product managers to plan strategy and roadmaps. We serve more than 300,000 users worldwide.

We are looking for:

* Experienced full-stack engineers to work on the Aha! product. Our application is built in Ruby on Rails, with some React on the frontend for rich client-side experiences.

* Security engineers, with hands-on Rails development experience plus experience with compliance projects, security policy development, or other security initiatives.

Aha! is profitable, you can work from anywhere in North or South America, and we offer excellent benefits. We use our own product to manage our work (which is especially rewarding) and we deploy continuously.

Our entire team is remote - in North American timezones so we can collaborate during the work day.

You can view open engineering positions at https://www.aha.io/company/careers/current-openings?category..., and click through to a specific job for our simple application form. Our job postings also have a lot more detail about the team, our values, and what you'd be doing day-to-day.

Aha! (https://www.aha.io) | Rails / React / Security | REMOTE

Aha! is the #1 tool for product managers to plan strategy and roadmaps. We serve more than 300,000 users worldwide.

We are looking for:

* Experienced full-stack engineers to work on the Aha! product. Our application is built in Ruby on Rails, with some React on the frontend for rich client-side experiences.

* Security engineers, with hands-on Rails development experience plus experience with compliance projects, security policy development, or other security initiatives.

Aha! is profitable, you can work from anywhere in North or South America, and we offer excellent benefits. We use our own product to manage our work (which is especially rewarding) and we deploy continuously.

Our entire team is remote - in North American timezones so we can collaborate during the work day.

You can view open engineering positions at https://www.aha.io/company/careers/current-openings?category..., and click through to a specific job for our simple application form. Our job postings also have a lot more detail about the team, our values, and what you'd be doing day-to-day.

Aha! (https://www.aha.io) | Rails / React / Security | REMOTE

Aha! is the #1 tool for product managers to plan strategy and roadmaps. We serve more than 300,000 users worldwide.

We are looking for:

* Experienced full-stack engineers to work on the Aha! product. Our application is built in Ruby on Rails, with some React on the frontend for rich client-side experiences.

* Security engineers, with hands-on Rails development experience plus experience with compliance projects, security policy development, or other security initiatives.

Aha! is profitable, you can work from anywhere in North America, and we offer excellent benefits. We use our own product to manage our work (which is especially rewarding) and we deploy continuously.

Our entire team is remote - in North American timezones so we can collaborate during the work day.

You can view open engineering positions at https://www.aha.io/company/careers/current-openings?category..., and click through to a specific job for our simple application form. Our job postings also have a lot more detail about the team, our values, and what you'd be doing day-to-day.

Aha! (https://www.aha.io) | Rails / React / Security | REMOTE

Aha! is the #1 tool for product managers to plan strategy and roadmaps. We serve more than 300,000 users worldwide.

We are looking for:

* Experienced full-stack engineers to work on the Aha! product. Our application is built in Ruby on Rails, with some React on the frontend for rich client-side experiences.

* Security engineers, with hands-on Rails development experience plus experience with compliance projects, security policy development, or other security initiatives.

Aha! is profitable, you can work from anywhere in North America, and we offer excellent benefits. We use our own product to manage our work (which is especially rewarding) and we deploy continuously.

Our entire team is remote - in North American timezones so we can collaborate during the work day.

You can view open engineering positions at https://www.aha.io/company/careers/current-openings?category..., and click through to a specific job for our simple application form. Our job postings also have a lot more detail about the team, our values, and what you'd be doing day-to-day.

Aha! (https://www.aha.io) | Rails / React / Security | REMOTE

Aha! is the #1 tool for product managers to plan strategy and roadmaps. We serve more than 300,000 users worldwide.

We are looking for:

* Experienced full-stack engineers to work on the Aha! product. Our application is built in Ruby on Rails, with some React on the frontend for rich client-side experiences.

* Security engineers, with hands-on Rails development experience plus experience with compliance projects, security policy development, or other security initiatives.

Aha! is profitable, you can work from anywhere in North America, and we offer excellent benefits. We use our own product to manage our work (which is especially rewarding) and we deploy continuously.

Our entire team is remote - in North American timezones so we can collaborate during the work day.

You can view open engineering positions at https://www.aha.io/company/careers/current-openings?category..., and click through to a specific job for our simple application form.

I think there are two primary reasons why JavaScript projects tend to have much larger dependency trees than in ruby or other ecosystems.

1. The JavaScript standard library is much more sparse than what you get out-of-the-box with ruby or many other languages. The existence of lodash is evidence of this in itself. The infamous left-pad fiasco would never have happened if JavaScript's native String had an equivalent to ruby's String#rjust. This part of the problem is significantly improving with time -- for example, node.js 8.0 and up do have a native string pad function, padStart. However, especially for tooling libraries, using the latest native JS features means dropping support for semi-recent versions of node, and there's also generally a lot of inertia.

2. npm and yarn allow you to install multiple versions of the same package. If I have dependencies A and B, which both require different major versions of dependency C, npm and yarn will both happily install multiple copies of C. With ruby/bundler this is an error and you have to work out how to tweak your dependencies so they're all happy with the same version range. I suspect this architectural choice is largely a consequence of #1 -- especially in the earlier days of npm, getting all your dependencies on the same version of a commonly used helper library would have been nightmarish. And there are benefits to this approach; I have certainly spent long hours trying to upgrade ruby gems with version conflicts. But it results in a lot more bloat almost by default.

To answer your original question -- I don't know that anything in particular is intentionally being done. I do think we're heading in the right direction and things will be much better in a few years as packages slowly move towards new native language features rather than helper libraries. I also just don't think this is of critical importance at the end of the day. If you add up the brain cycles that I've ever spent worrying about 100MB of hard drive space, it's almost certainly less than what I've spent typing this comment :)

Actually, I guess I was wrong about node_modules not being included in the slug -- it's just that the slug is compressed so node_modules don't take up anything close to their stat size. One common gotcha is that if you have large non-code files in your git repo (binaries/images/gzips/etc), those will end up in your slug and they don't compress well so they'll add a lot of bloat. If that's the case you can use a .slugignore file[0] to tell Heroku to exclude them. Good luck!

[0] https://devcenter.heroku.com/articles/slug-compiler#ignoring...

No problem! FYI there may be something else bloating your slug. With the ruby buildpack, heroku by default will install node_modules to a shared cache directory and not include them in the slug artifact. For example I have a Rails app that has 250MB of node_modules locally but my slug on Heroku is only 93.4MB.

Rails 6 by default includes webpack to bundle assets for production. Aside from webpack, several of the top 10 on your list are libraries that ensure a great user & developer experience across browsers:

- babel transpiles ES6/7+ JavaScript syntax to the least-common-denominator of the browsers you designate as supported by your application

- core-js provides implementations of features that are not supported in older browsers -- things like array methods that cannot simply be transpiled

- caniuse-lite is a database of supported browser features to determine what needs to be transpiled and when

This toolchain allows developers to write code with the latest language features (which usually results in simpler, more elegant code) while seamlessly supporting legacy browsers as needed. If you decide to drop support for an older browser, you can simply remove it from your browserslist instead of going through all your code to figure out which hacks you put in just for that browser. It takes a ton of cycles out of development googling "can I use feature X in browser Y".

Prior to Rails 6, asset precompilation was powered by Sprockets by default. Sprockets still bundled many analogous libraries, just hidden in ruby gems instead of node_modules. For example, if you want to use SASS then you need a library that compiles SASS to CSS -- whether it's node-sass on your list or the sassc gem.

As noted in other comments, very little of this code is actually loaded in the frontend by end users.

Aha! (https://www.aha.io) | Rails / React / Security | REMOTE

Aha! is the #1 tool for product managers to plan strategy and roadmaps. We serve more than 300,000 users worldwide.

We are looking for:

* Experienced full-stack engineers to work on the Aha! product. Our application is built in Ruby on Rails, with some React on the frontend for rich client-side experiences.

* Security engineers, with hands-on Rails development experience plus experience with compliance projects, security policy development, or other security initiatives.

Aha! is profitable, you can work from anywhere in North America, and we offer excellent benefits. We use our own product to manage our work (which is especially rewarding) and we deploy continuously.

Our entire team is remote - in North American timezones so we can collaborate during the work day.

You can view open engineering positions at https://www.aha.io/company/careers/current-openings?category..., and click through to a specific job for our simple application form.

Aha! (https://www.aha.io) | Rails / React / Security | REMOTE

Aha! is the #1 tool for product managers to plan strategy and roadmaps. We serve more than 300,000 users worldwide.

We are looking for:

* Experienced full-stack engineers to work on the Aha! product. Our application is built in Ruby on Rails, with some React on the frontend for rich client-side experiences.

* Security engineers, with hands-on Rails development experience plus experience with compliance projects, security policy development, or other security initiatives.

Aha! is profitable, you can work from anywhere in North America, and we offer excellent benefits. We use our own product to manage our work (which is especially rewarding) and we deploy continuously.

Our entire team is remote - in North American timezones so we can collaborate during the work day.

You can view open engineering positions at https://www.aha.io/company/careers/current-openings?category..., and click through to a specific job for our simple application form.

Aha! (https://www.aha.io) | Rails / React / Security | REMOTE

Aha! is the #1 tool for product managers to plan strategy and roadmaps. We serve more than 300,000 users worldwide.

We are looking for:

* Experienced full-stack engineers to work on the Aha! product. Our application is built in Ruby on Rails, with some React on the frontend for rich client-side experiences.

* Security engineers, with hands-on Rails development experience plus experience with compliance projects, security policy development, or other security initiatives.

Aha! is profitable, you can work from anywhere in North America, and we offer excellent benefits. We use our own product to manage our work (which is especially rewarding) and we deploy continuously.

Our entire team is remote - in North American timezones so we can collaborate during the work day.

You can view open engineering positions at https://www.aha.io/company/careers/current-openings?category..., and click through to a specific job for our simple application form.