8 Matching Annotations
- Sep 2024
-
www.theguardian.com www.theguardian.com
-
Die Fossilindustrie finanziert seit Jahrzehten Universitäten und fördert damit Publikationen in ihrem Interesse, z.B. zu false solutions wie #CCS. Hintergrundbericht anlässlich einer neuen Studie: https://www.theguardian.com/business/article/2024/sep/05/universities-fossil-fuel-funding-green-energy
Studie: https://doi.org/10.1002/wcc.904
Tags
- American Petroleum Institute
- BP
- Exxon
- disinformation
- Accountable Allies: The Undue Influence of Fossil Fuel Money in Academia
- Geoffrey Supran
- Jennie Stephens
- MIT Energy Initiative
- Campus Climate Network
- Fossilindustrie
- Emily Eaton
- Data for Progress
- Princeton University’s Carbon Mitigation Initiative
- by: Dharma Noor
- negative emission technologies
- Favourability towards natural gas relates to funding source of university energy centres
- Fossil fuel industry influence in higher education: A review and a research agenda
- Jake Lowe
- climate obstructionism in.higher education
Annotators
URL
-
- Mar 2021
-
www.chevtek.io www.chevtek.io
-
he goes on to talk about third party problems and how you're never guaranteed something is written correctly or that even if it is you don't know if it's the most optimal solution
-
-
news.ycombinator.com news.ycombinator.com
-
here is my set of best practices.I review libraries before adding them to my project. This involves skimming the code or reading it in its entirety if short, skimming the list of its dependencies, and making some quality judgements on liveliness, reliability, and maintainability in case I need to fix things myself. Note that length isn't a factor on its own, but may figure into some of these other estimates. I have on occasion pasted short modules directly into my code because I didn't think their recursive dependencies were justified.I then pin the library version and all of its dependencies with npm-shrinkwrap.Periodically, or when I need specific changes, I use npm-check to review updates. Here, I actually do look at all the changes since my pinned version, through a combination of change and commit logs. I make the call on whether the fixes and improvements outweigh the risk of updating; usually the changes are trivial and the answer is yes, so I update, shrinkwrap, skim the diff, done.I prefer not to pull in dependencies at deploy time, since I don't need the headache of github or npm being down when I need to deploy, and production machines may not have external internet access, let alone toolchains for compiling binary modules. Npm-pack followed by npm-install of the tarball is your friend here, and gets you pretty close to 100% reproducible deploys and rollbacks.This list intentionally has lots of judgement calls and few absolute rules. I don't follow all of them for all of my projects, but it is what I would consider a reasonable process for things that matter.
-
- Oct 2020
-
-
But maybe this PR should still be merged until he finds time for that?
-
Sorry this sat for so long!
Tags
- iterative process
- don't let big plans/goals get in the way of integrating/releasing smaller changes/improvements
- open-source software: progress seems slow
- pull request stalled
- big change/rewrite vs. continuous improvements / smaller refactorings
- not a blocker (issue dependency)
- waiting for maintainers to review / merge pull request / give feedback
Annotators
URL
-
- Aug 2020
-
openreview.net openreview.net
-
About | OpenReview. (n.d.). Retrieved May 30, 2020, from https://openreview.net/about
-
- May 2020
-
about.gitlab.com about.gitlab.com
-
With a single file in the repository, everyone with read access can see the contents, making it much more inviting to improve and review the build scripts.
-
- Jul 2019
-
Local file Local file
-
PMBOK® Guide 6th Ed. p.18
-