if you live in the northern or Southern Hemispheres
so... anywhere in the world?
HN user
Engineering at Stripe, formerly at Aha!
[ my public key: https://keybase.io/schneidmaster; my proof: https://keybase.io/schneidmaster/sigs/42F6vHEpWZf-fXGXQSJaCk4h9Lx8DDTyBKkGpaFLIpM ]
if you live in the northern or Southern Hemispheres
so... anywhere in the world?
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 (!).
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.
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.
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.
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.
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.
My personal favorite is "United States v. Approximately 64,695 Pounds of Shark Fins" (https://en.wikipedia.org/wiki/United_States_v._Approximately...)
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.