├── CODE_OF_CONDUCT.md
├── CONTRIBUTING.md
├── LICENSE
├── README.md
└── pull_request_template.md
/CODE_OF_CONDUCT.md:
--------------------------------------------------------------------------------
1 | # Contributor Covenant Code of Conduct
2 |
3 | ## Our Pledge
4 |
5 | In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
6 |
7 | ## Our Standards
8 |
9 | Examples of behavior that contributes to creating a positive environment include:
10 |
11 | * Using welcoming and inclusive language
12 | * Being respectful of differing viewpoints and experiences
13 | * Gracefully accepting constructive criticism
14 | * Focusing on what is best for the community
15 | * Showing empathy towards other community members
16 |
17 | Examples of unacceptable behavior by participants include:
18 |
19 | * The use of sexualized language or imagery and unwelcome sexual attention or advances
20 | * Trolling, insulting/derogatory comments, and personal or political attacks
21 | * Public or private harassment
22 | * Publishing others' private information, such as a physical or electronic address, without explicit permission
23 | * Other conduct which could reasonably be considered inappropriate in a professional setting
24 |
25 | ## Our Responsibilities
26 |
27 | Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
28 |
29 | Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
30 |
31 | ## Scope
32 |
33 | This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
34 |
35 | ## Enforcement
36 |
37 | Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at hwayne@gmail.com. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
38 |
39 | Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
40 |
41 | ## Attribution
42 |
43 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
44 |
45 | [homepage]: http://contributor-covenant.org
46 | [version]: http://contributor-covenant.org/version/1/4/
47 |
--------------------------------------------------------------------------------
/CONTRIBUTING.md:
--------------------------------------------------------------------------------
1 |
2 | # Contribution Guidelines
3 |
4 | ## Adding to this List
5 |
6 | All submissions should have the following format:
7 |
8 | #### [Title of thing, with link to thing](https://www.youtube.com/watch?v=JWOY6uu3VUo) (PDF/Video/etc tag, optional)
9 |
10 | * **Hype:** "The hyped claim or topic being addressed. You can be informal here, but don't be snide."
11 |
12 | * **Shower:** The counter-claim, specified well. It should explain why this thing is rigorous enough for inclusion. For example, it has benchmarks, it carefully dissects the claim, it cites research, etc.
13 |
14 | * **Caveats:** Any limitations to the thing. For example, it's old, it doesn't address a specific part of a claim, it has threats to validity, etc.
15 |
16 | * **Notes:** Anything else you think is important to include. (Optional)
17 |
18 | If any of this seems unclear to you, check out the existing list for examples of what it should look like. Here's a copyable template without formatting:
19 |
20 | ```
21 | ####
22 |
23 | * **Hype:**
24 |
25 | * **Shower:**
26 |
27 | * **Caveats:**
28 |
29 | * **Notes:**
30 | ```
31 |
32 | If any of this seems unclear to you, check out the existing list for examples of what it should look like.
33 |
34 | Not everything is appropriate for this list. Some of the reasons a contribution might be rejected:
35 |
36 | * The thing isn't freely accessible.
37 | * Not programming-related.
38 | * It's not addressing an overhyped claim. If it's being a cold shower to [COBOL on Cogs](www.coboloncogs.org/HOME.HTM), it probably doesn't belong.
39 | * It doesn't actually address the hype.
40 | * It's not rigorous enough. Abstract arguments don't count as rigorous: it has to at least show specified issues or include examples. [This](https://hillelwayne.com/post/right-tool/) is a very rough guide to what I'm thinking of.
41 | * It's incorrect or deceptive.
42 | * It's formatted in a way that makes reading it extremely difficult.
43 | * It's snide, obnoxious, angry, or just assholish in general.
44 |
45 | Ultimately, everything here is a judgement call, so please don't mail me glitter bombs if I reject your PR.
46 |
47 | ## Getting Something off the List
48 |
49 | I haven't thought this far ahead. For now please create an issue and we'll figure it out from there.
50 |
--------------------------------------------------------------------------------
/LICENSE:
--------------------------------------------------------------------------------
1 | CC0 1.0 Universal
2 |
3 | Statement of Purpose
4 | The laws of most jurisdictions throughout the world automatically confer exclusive Copyright and Related Rights (defined below) upon the creator and subsequent owner(s) (each and all, an "owner") of an original work of authorship and/or a database (each, a "Work").
5 | Certain owners wish to permanently relinquish those rights to a Work for the purpose of contributing to a commons of creative, cultural and scientific works ("Commons") that the public can reliably and without fear of later claims of infringement build upon, modify, incorporate in other works, reuse and redistribute as freely as possible in any form whatsoever and for any purposes, including without limitation commercial purposes. These owners may contribute to the Commons to promote the ideal of a free culture and the further production of creative, cultural and scientific works, or to gain reputation or greater distribution for their Work in part through the use and efforts of others.
6 | For these and/or other purposes and motivations, and without any expectation of additional consideration or compensation, the person associating CC0 with a Work (the "Affirmer"), to the extent that he or she is an owner of Copyright and Related Rights in the Work, voluntarily elects to apply CC0 to the Work and publicly distribute the Work under its terms, with knowledge of his or her Copyright and Related Rights in the Work and the meaning and intended legal effect of CC0 on those rights.
7 |
8 | 1. Copyright and Related Rights. A Work made available under CC0 may be protected by copyright and related or neighboring rights ("Copyright and Related Rights"). Copyright and Related Rights include, but are not limited to, the following:
9 | the right to reproduce, adapt, distribute, perform, display, communicate, and translate a Work;
10 | moral rights retained by the original author(s) and/or performer(s);
11 | publicity and privacy rights pertaining to a person's image or likeness depicted in a Work;
12 | rights protecting against unfair competition in regards to a Work, subject to the limitations in paragraph 4(a), below;
13 | rights protecting the extraction, dissemination, use and reuse of data in a Work;
14 | database rights (such as those arising under Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, and under any national implementation thereof, including any amended or successor version of such directive); and
15 | other similar, equivalent or corresponding rights throughout the world based on applicable law or treaty, and any national implementations thereof.
16 | 2. Waiver. To the greatest extent permitted by, but not in contravention of, applicable law, Affirmer hereby overtly, fully, permanently, irrevocably and unconditionally waives, abandons, and surrenders all of Affirmer's Copyright and Related Rights and associated claims and causes of action, whether now known or unknown (including existing as well as future claims and causes of action), in the Work (i) in all territories worldwide, (ii) for the maximum duration provided by applicable law or treaty (including future time extensions), (iii) in any current or future medium and for any number of copies, and (iv) for any purpose whatsoever, including without limitation commercial, advertising or promotional purposes (the "Waiver"). Affirmer makes the Waiver for the benefit of each member of the public at large and to the detriment of Affirmer's heirs and successors, fully intending that such Waiver shall not be subject to revocation, rescission, cancellation, termination, or any other legal or equitable action to disrupt the quiet enjoyment of the Work by the public as contemplated by Affirmer's express Statement of Purpose.
17 | 3. Public License Fallback. Should any part of the Waiver for any reason be judged legally invalid or ineffective under applicable law, then the Waiver shall be preserved to the maximum extent permitted taking into account Affirmer's express Statement of Purpose. In addition, to the extent the Waiver is so judged Affirmer hereby grants to each affected person a royalty-free, non transferable, non sublicensable, non exclusive, irrevocable and unconditional license to exercise Affirmer's Copyright and Related Rights in the Work (i) in all territories worldwide, (ii) for the maximum duration provided by applicable law or treaty (including future time extensions), (iii) in any current or future medium and for any number of copies, and (iv) for any purpose whatsoever, including without limitation commercial, advertising or promotional purposes (the "License"). The License shall be deemed effective as of the date CC0 was applied by Affirmer to the Work. Should any part of the License for any reason be judged legally invalid or ineffective under applicable law, such partial invalidity or ineffectiveness shall not invalidate the remainder of the License, and in such case Affirmer hereby affirms that he or she will not (i) exercise any of his or her remaining Copyright and Related Rights in the Work or (ii) assert any associated claims and causes of action with respect to the Work, in either case contrary to Affirmer's express Statement of Purpose.
18 | 4. Limitations and Disclaimers.
19 | No trademark or patent rights held by Affirmer are waived, abandoned, surrendered, licensed or otherwise affected by this document.
20 | Affirmer offers the Work as-is and makes no representations or warranties of any kind concerning the Work, express, implied, statutory or otherwise, including without limitation warranties of title, merchantability, fitness for a particular purpose, non infringement, or the absence of latent or other defects, accuracy, or the present or absence of errors, whether or not discoverable, all to the greatest extent permissible under applicable law.
21 | Affirmer disclaims responsibility for clearing rights of other persons that may apply to the Work or any use thereof, including without limitation any person's Copyright and Related Rights in the Work. Further, Affirmer disclaims responsibility for obtaining any necessary consents, permissions or other rights required for any use of the Work.
22 | Affirmer understands and acknowledges that Creative Commons is not a party to this document and has no duty or obligation with respect to this CC0 or use of the Work.
23 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 |
2 |
3 | # Awesome Cold Showers
4 |
5 | It's great when people get excited about things, but sometimes they get a little _too_ excited. This an awesome (rigorous and respectful) and curated (I read every suggestion and make judgement calls) list of cold showers on overhyped topics. This does **not** mean the enthusiasm is bad or wrong: we're just reminding people to stay grounded. Feel free to submit your favorites!
6 |
7 | #### [Verification Techniques](https://web.archive.org/web/20170214231046/https://www.cypherpunks.to/~peter/04_verif_techniques.pdf) (PDF)
8 |
9 | * **Hype:** "Formal Verification is a great way to write software. We should prove all of our code correct."
10 |
11 | * **Shower:** Extensive literature review showing that formal methods are hard to learn, extremely expensive to apply, and often miss critical bugs.
12 |
13 | * **Caveats:** Written in 2000 and doesn't cover modern tools/techniques, such as TLA+ or dependent typing.
14 |
15 | * **Notes:** Part of [Peter Gutmann](https://www.cs.auckland.ac.nz/~pgut001/)'s thesis, "The Design and Verification of a Cryptographic Security Architecture". The whole thesis can be found [here](https://archive.org/details/springer_10.1007-b97264/mode/2up).
16 |
17 | #### [Static vs Dynamic Typing: a literature review](https://danluu.com/empirical-pl/)
18 |
19 | * **Hype:** "Static Typing reduces bugs."
20 |
21 | * **Shower:** A review of all the available literature (up to 2014), showing that the solid research is inconclusive, while the conclusive research had methodological issues.
22 |
23 | * **Caveats:** Does not cover other possible benefits of static typing, like documentation. Does not address research on gradual type systems, like mypy or Typescript.
24 |
25 | #### [Scalability! but at what COST?](http://www.frankmcsherry.org/graph/scalability/cost/2015/01/15/COST.html)
26 |
27 | * **Hype:** "We need big data systems to handle big data."
28 |
29 | * **Shower:** Benchmarking cutting-edge graph-processing algorithms running on 128-core clusters against a single-threaded 2014 Macbook Pro. The laptop consistently wins, sometimes by an order of magnitude.
30 |
31 | * **Caveats:** McSherry is really good at optimizing his algorithms and has skills the average data scientist does not. Big data systems might be better if you have ad-hoc queries and don't want to take the time to optimize them.
32 |
33 | * **Notes:** "If you are going to use a big data system for yourself, see if it is faster than your laptop. If you are going to build a big data system for others, see that it is faster than my laptop."
34 |
35 | #### [Web Framework Benchmarks](https://www.techempower.com/benchmarks/)
36 |
37 | * **Hype:** Anything about performance or scalability of various languages/web frameworks/databases.
38 |
39 | * **Shower:** Actual hard data of various combinations of solutions under various tasks.
40 |
41 | * **Caveats:** Raw data you have to interpret yourself. ~~Does not provide a complete dump of the raw data for your own analysis.~~ Raw data can now be found [here](http://tfb-logs.techempower.com/)
42 |
43 | * **Notes:** [Continually updating](https://tfb-status.techempower.com/) with new benchmarks. All implementations are public and you can improve them with a PR.
44 |
45 | #### [Agile Methods: The Good, the Hype and the Ugly](https://www.youtube.com/watch?v=ffkIQrq-m34) (Video)
46 |
47 | * **Hype:** "We should develop software using Agile."
48 |
49 | * **Shower:** Review of all the different styles of Agile and how some of the practices (particularly replacing requirements with user stories and the lack of proper specification) are harmful in the long run.
50 |
51 | * **Caveats:** While Meyer calls out some problems, overall he's very positive about Agile and recommends it as a good (but imperfect) methodology.
52 |
53 | * **Notes:** Starts at [3:30](https://youtu.be/ffkIQrq-m34?t=3m30s). There's a [followup video](https://www.youtube.com/watch?v=Q_9k6ym5BZU) where he answers audience questions.
54 |
55 | #### [An Empirical Study on the Correctness of Formally Verified Systems](https://homes.cs.washington.edu/~pfonseca/papers/eurosys2017-dsbugs.pdf) (PDF)
56 |
57 | * **Hype:** "If I formally verify my code, I don't need to test it!"
58 |
59 | * **Shower:** Researchers looked at three formally verified systems, and found critical correctness bugs in all three. The bugs were from "a wide range of mismatched assumptions" and caused servers to crash or produce wrong data.
60 |
61 | * **Caveats:** Most bugs were at the system boundaries; none were found in the implemented protocols. Formally verified systems, while not perfect, were considerably less buggy than unverified systems.
62 |
63 | * **Notes:** Systems were verified with Coq and Z3. Further discussion at [The Morning Paper](https://blog.acolyer.org/2017/05/29/an-empirical-study-on-the-correctness-of-formally-verified-distributed-systems/).
64 |
65 | #### [Fixing Faults in C and Java Source Code: Abbreviated vs. Full-word Identifier Names](http://www2.unibas.it/gscanniello/Giuseppe_Scanniello%40unibas/Home_files/TOSEM.pdf) (PDF)
66 |
67 | * **Hype:** "Identifiers should be self-documenting! Use full names, not abbreviations."
68 |
69 | * **Shower:** Researchers had programmers fix bugs in a codebase, either with all of the identifiers were abbreviated, or where all of the identifiers were full-words. They found no difference in time taken or quality of debugging.
70 |
71 | * **Caveats:** Only applies to fixing bugs. Otherwise watertight. This is honestly one of the most rigorous and comprehensive papers I've ever read.
72 |
73 | * **Notes:** Includes ethnography on how programmers debug abbreviated code. Link is to the author preprint.
74 |
75 | #### [An Eye Tracking Study on camelCase and under_score Identifier Styles (PDF)](http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf)
76 |
77 | * **Hype:** camelCase is easier to read than under_score. So it is a best practice to
78 | use camelCase in variable names, function names, and other identifiers.
79 |
80 | * **Shower:** Several research papers have been done. But when eye-tracking software was
81 | used to test the claim, two conclusions emerged: (1) developers are equally accurate
82 | regardless of style, but (2) the under_score style can be processed faster and easier.
83 |
84 | * **Caveats:** The study's sample size was small (15 people), and "Subjects were
85 | historically trained mostly in the underscore identifier style and were all programmers."
86 | In the study, subjects were presented terms in isolation (not in blocks of code). Thus,
87 | as the study notes, there could be variance due to context.
88 |
89 | * **Notes:** "The interaction of Experience with Style indicates that novices benefit
90 | twice as much with respect to time, with the underscore style.
91 | "This paper purports to remedy difficulties in an earlier paper entitled
92 | [To CamelCase or Under_score](http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=BD104CB69764CBBB36249528028E19B7?doi=10.1.1.158.9499&rep=rep1&type=pdf),
93 | which concluded that with training, camelCase is more accurately processed. Finally, neither
94 | paper seems to have analyzed whether native language comes into play (e.g. whether it is
95 | easier for non-native English speakers to understand camelCase versus under_score).
96 |
97 |
98 | #### [Microservices - Please, don't](http://basho.com/posts/technical/microservices-please-dont/)
99 |
100 | * **Hype:** "Microservices! Microservices!"
101 |
102 | * **Shower:** Presents five fallacies of "why microservices solve problems monoliths have" and shows how either monoliths don't actually have those problems or that microservices make the problem even worse.
103 |
104 | * **Caveats:** Abstract arguments and experience, no case studies or examples.
105 |
106 | #### [VM Warmup Blows Hot and Cold](https://arxiv.org/abs/1602.00602)
107 |
108 | * **Hype**: Your favourite programming language has been updated. The new
109 | version makes impressive performance improvement claims.
110 |
111 | * **Shower**: Benchmarking modern programming languages under near-ideal
112 | circumstances, just for longer than before, suggests that we have not been
113 | benchmarking language implementations as accurately as we might wish. Many
114 | benchmarks slow down over time. Some never stabilise. Many benchmarking
115 | experiments will not be repeatable due to non-determinism. Warmup time is
116 | important, but is usually either ignored, or reported inaccurately.
117 |
118 | * **Caveats**: Only evaluates the x86_64 architecture, and for only two
119 | operating systems (Linux and OpenBSD). Experiment conducted in 2017 (prior to
120 | meltdown patching). Evaluates mainly JITted language implementations
121 | (although C benchmarks were included).
122 |
123 | * **Notes**: The experiment and the benchmark runner are published under an
124 | open source license. [Start here](https://github.com/softdevteam/warmup_experiment).
125 |
126 | #### [Scaling SQLite to 4M QPS on a Single Server](https://blog.expensify.com/2018/01/08/scaling-sqlite-to-4m-qps-on-a-single-server/)
127 |
128 | * **Hype:** "Scaling out is better than scaling up. Cloud is more scalable than bare metal."
129 |
130 | * **Shower:** Expensify found that running a single bare-metal server was both faster and cheaper than using a x1e.32xlarge EC2 instance. By using one server, they could avoid sharding their data.
131 |
132 | * **Caveats:** Does not cover if scaling out bare metal has the same advantages over scaling out EC2 (assuming you can afford sharding). Can't really compare how much cheaper the bare metal is because they don't list the cost. I'm guessing their servers are 100k each? No basis for that guess though.
133 |
134 | #### [Understanding Real-World Concurrency Bugs in Go (PDF)](https://songlh.github.io/paper/go-study.pdf)
135 |
136 | * **Hype:** Compared to other languages, Go's concurrency system of goroutines and channels is easier to understand, easier to use, and is less prone to bugs and memory leaks.
137 |
138 | * **Shower:** According to an empirical study by Tu, _et al_, there are plenty of concurrency-related bugs related to the difficulty in understanding and following the concurrency features and patterns provided by Go.
139 |
140 | * **Caveats:** This study is specific to Go. Though other languages provide similar facilities, they are not covered in this article. Also, the types of bugs seen with channels and shared memory are different. Channels lead to more blocking bugs (deadlocks, dangling channels) while shared-memory lead to more nonblocking bugs (race conditions, dirty reads).
141 |
142 | * **Notes:** "We studied six popular Go software including Docker, Kubernetes, and gRPC. We analyzed 171 concurrency bugs in total, with more than half of them caused by non-traditional, Go-specific problems"
143 |
144 | ## Plug
145 |
146 | You can find my general ravings on my [website](https://hillelwayne.com) or [twitter](https://twitter.com/Hillelogram).
147 |
--------------------------------------------------------------------------------
/pull_request_template.md:
--------------------------------------------------------------------------------
1 | - [ ] I have followed the [code of conduct](https://github.com/hwayne/awesome-cold-showers/blob/master/CODE_OF_CONDUCT.md).
2 | - [ ] I have followed the [contributing](https://github.com/hwayne/awesome-cold-showers/blob/master/CONTRIBUTING.md) guidelines and used the proper item format.
3 | - [ ] This is not a duplicate.
4 | - [ ] The resource is free.
5 | - [ ] The resource is rigorous because: (please list)
6 | - [ ] The resource is not obnoxious, condescending, etc.
7 | - [ ] My writeup is respectful of both sides.
8 | - [ ] I've added reasonable caveats.
9 | - [ ] I've noted if the resource is a video, pdf, etc.
10 |
--------------------------------------------------------------------------------