mirror of
https://github.com/dwmkerr/hacker-laws.git
synced 2025-12-17 12:45:20 +01:00
Compare commits
36 Commits
gitlocaliz
...
v0.1.0
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
0c35525fca | ||
|
|
0bf80bf8b5 | ||
|
|
50e2f2e6ce | ||
|
|
3ef9a5435e | ||
|
|
c18795765f | ||
|
|
93dec16bc9 | ||
|
|
4dd35e129e | ||
|
|
b6bd7b15d0 | ||
|
|
46a017ac55 | ||
|
|
abaca319be | ||
|
|
5a11b27c60 | ||
|
|
30008f11d5 | ||
|
|
442a63aab5 | ||
|
|
c6c5d6d376 | ||
|
|
41289460fa | ||
|
|
e10a96dc31 | ||
|
|
a5236c0917 | ||
|
|
ea84113520 | ||
|
|
2c29ebe1b6 | ||
|
|
f03d9a502e | ||
|
|
cbbfdbb41c | ||
|
|
c21a06765b | ||
|
|
700e57f03d | ||
|
|
a387e3fc7e | ||
|
|
491ace1341 | ||
|
|
639465c7d8 | ||
|
|
5e57095aa6 | ||
|
|
f06b64ac38 | ||
|
|
7af3c2dde8 | ||
|
|
d3c4a9a3f2 | ||
|
|
97d358a3d3 | ||
|
|
d812cd79a5 | ||
|
|
933e7aa485 | ||
|
|
5f4fb690c3 | ||
|
|
f67e1dde05 | ||
|
|
98fa2e4a2d |
43
.github/workflows/build-on-pull-request.yaml
vendored
Normal file
43
.github/workflows/build-on-pull-request.yaml
vendored
Normal file
@@ -0,0 +1,43 @@
|
||||
# This pipeline builds the PDF ebook on any pull request to master.
|
||||
name: "Build PDF"
|
||||
on:
|
||||
pull_request:
|
||||
branches:
|
||||
- master
|
||||
|
||||
jobs:
|
||||
prepare-pdf:
|
||||
# Focal Fossa. Please don't use 'latest' tags, it's an anti-pattern.
|
||||
runs-on: ubuntu-20.04
|
||||
steps:
|
||||
# Checkout the code.
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v2
|
||||
|
||||
# Set a descriptive version. For PRs it'll be the short sha.
|
||||
- name: Set Version
|
||||
id: set_version
|
||||
run: echo ::set-output name=VERSION::$(git rev-parse --short HEAD)
|
||||
|
||||
# Prepare the content files.
|
||||
- name: Prepare Content
|
||||
run: ./scripts/prepare-markdown-for-ebook.sh ${{ steps.set_version.outputs.VERSION }}
|
||||
|
||||
# Create a PDF from the prepared markdown.
|
||||
- name: Prepare PDF
|
||||
uses: docker://pandoc/latex:2.9
|
||||
with:
|
||||
args: "-V toc-title:\"Table Of Contents\" --toc --pdf-engine=pdflatex --standalone --output hacker-laws.pdf hacker-laws.md"
|
||||
|
||||
# Publish the PDF and intermediate markdown as an artifact.
|
||||
- name: Publish PDF Artifact
|
||||
uses: actions/upload-artifact@master
|
||||
with:
|
||||
name: hacker-laws.pdf
|
||||
path: hacker-laws.pdf
|
||||
|
||||
- name: Publish Intermiediate Markdown Artifact
|
||||
uses: actions/upload-artifact@master
|
||||
with:
|
||||
name: hacker-laws.md
|
||||
path: hacker-laws.md
|
||||
69
.github/workflows/release-on-tag.yaml
vendored
Normal file
69
.github/workflows/release-on-tag.yaml
vendored
Normal file
@@ -0,0 +1,69 @@
|
||||
# This pipeline builds the PDF ebook on any tag starting with 'v'.
|
||||
name: "Create Release"
|
||||
on:
|
||||
push:
|
||||
tags:
|
||||
- 'v*'
|
||||
|
||||
jobs:
|
||||
prepare-pdf:
|
||||
# Focal Fossa. Please don't use 'latest' tags, it's an anti-pattern.
|
||||
runs-on: ubuntu-20.04
|
||||
steps:
|
||||
# Checkout the code.
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v2
|
||||
|
||||
# Set a descriptive version. For PRs it'll be the short sha.
|
||||
- name: Set Version
|
||||
id: set_version
|
||||
run: echo ::set-output name=VERSION::${GITHUB_REF/refs\/tags\//}
|
||||
|
||||
# Prepare the content files.
|
||||
- name: Prepare Content
|
||||
run: ./scripts/prepare-markdown-for-ebook.sh ${{ steps.set_version.outputs.VERSION }}
|
||||
|
||||
# Create a PDF from the prepared markdown.
|
||||
- name: Prepare PDF
|
||||
uses: docker://pandoc/latex:2.9
|
||||
with:
|
||||
args: "-V toc-title:\"Table Of Contents\" --toc --pdf-engine=pdflatex --standalone --output hacker-laws.pdf hacker-laws.md"
|
||||
|
||||
# Publish the PDF artifact.
|
||||
- name: Publish PDF Artifacts
|
||||
uses: actions/upload-artifact@master
|
||||
with:
|
||||
name: hacker-laws.pdf
|
||||
path: hacker-laws.pdf
|
||||
|
||||
release:
|
||||
needs: prepare-pdf
|
||||
runs-on: ubuntu-20.04
|
||||
steps:
|
||||
- name: Download artifact
|
||||
uses: actions/download-artifact@v2
|
||||
with:
|
||||
name: hacker-laws.pdf
|
||||
|
||||
- name: Create Release
|
||||
id: create-release
|
||||
uses: actions/create-release@v1
|
||||
env:
|
||||
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
with:
|
||||
tag_name: ${{ github.ref }}
|
||||
release_name: ${{ github.ref }}
|
||||
body: |
|
||||
Hacker Laws E-Book
|
||||
draft: false
|
||||
prerelease: false
|
||||
|
||||
- name: Upload Release Asset
|
||||
uses: actions/upload-release-asset@v1
|
||||
env:
|
||||
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
with:
|
||||
upload_url: ${{ steps.create-release.outputs.upload_url }}
|
||||
asset_path: ./hacker-laws.pdf
|
||||
asset_name: hacker-laws.pdf
|
||||
asset_content_type: application/pdf
|
||||
113
README.md
113
README.md
@@ -2,9 +2,9 @@
|
||||
|
||||
Laws, Theories, Principles and Patterns that developers will find useful.
|
||||
|
||||
[Translations](#translations): [🇮🇩](./translations/pt-BR.md) [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇩🇪](./translations/de.md) [🇫🇷](./translations/fr.md) [🇬🇷](./translations/el.md) [🇮🇹](https://github.com/csparpa/hacker-laws-it) [🇱🇻](./translations/lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./translations/es-ES.md) [🇹🇷](https://github.com/umutphp/hacker-laws-tr) [🇯🇵](./translations/jp.md)
|
||||
[Translations](#translations): [🇮🇩](./translations/id.md) [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇩🇪](./translations/de.md) [🇫🇷](./translations/fr.md) [🇬🇷](./translations/el.md) [🇮🇹](https://github.com/csparpa/hacker-laws-it) [🇱🇻](./translations/lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./translations/es-ES.md) [🇹🇷](https://github.com/umutphp/hacker-laws-tr) [🇯🇵](./translations/jp.md)
|
||||
|
||||
Like this project? Please considering [sponsoring me](https://github.com/sponsors/dwmkerr) and the [translators](#translations).
|
||||
Like this project? Please considering [sponsoring me](https://github.com/sponsors/dwmkerr) and the [translators](#translations). Also check out this podcast on [The Changelog - Laws for Hackers to Live By](https://changelog.com/podcast/403) to learn more about the project! You can also [download the latest PDF eBook](https://github.com/dwmkerr/hacker-laws/releases/latest/download/hacker-laws.pdf).
|
||||
|
||||
---
|
||||
|
||||
@@ -30,6 +30,7 @@ Like this project? Please considering [sponsoring me](https://github.com/sponsor
|
||||
* [The Hype Cycle & Amara's Law](#the-hype-cycle--amaras-law)
|
||||
* [Hyrum's Law (The Law of Implicit Interfaces)](#hyrums-law-the-law-of-implicit-interfaces)
|
||||
* [Kernighan's Law](#kernighans-law)
|
||||
* [Linus's Law](#linuss-law)
|
||||
* [Metcalfe's Law](#metcalfes-law)
|
||||
* [Moore's Law](#moores-law)
|
||||
* [Murphy's Law / Sod's Law](#murphys-law--sods-law)
|
||||
@@ -44,12 +45,16 @@ Like this project? Please considering [sponsoring me](https://github.com/sponsor
|
||||
* [The Law of Triviality](#the-law-of-triviality)
|
||||
* [The Unix Philosophy](#the-unix-philosophy)
|
||||
* [The Spotify Model](#the-spotify-model)
|
||||
* [The Two Pizza Rule](#the-two-pizza-rule)
|
||||
* [Wadler's Law](#wadlers-law)
|
||||
* [Wheaton's Law](#wheatons-law)
|
||||
* [Principles](#principles)
|
||||
* [All Models Are Wrong (George Box's Law)](#all-models-are-wrong-george-boxs-law)
|
||||
* [Chesterson's Fence](#chestersons-fence)
|
||||
* [The Dead Sea Effect](#the-dead-sea-effect)
|
||||
* [The Dilbert Principle](#the-dilbert-principle)
|
||||
* [The Pareto Principle (The 80/20 Rule)](#the-pareto-principle-the-8020-rule)
|
||||
* [The Shirky Principle](#the-shirky-principle)
|
||||
* [The Peter Principle](#the-peter-principle)
|
||||
* [The Robustness Principle (Postel's Law)](#the-robustness-principle-postels-law)
|
||||
* [SOLID](#solid)
|
||||
@@ -63,6 +68,9 @@ Like this project? Please considering [sponsoring me](https://github.com/sponsor
|
||||
* [YAGNI](#yagni)
|
||||
* [The Fallacies of Distributed Computing](#the-fallacies-of-distributed-computing)
|
||||
* [Reading List](#reading-list)
|
||||
* [Online Resources](#online-resources)
|
||||
* [PDF eBook](#pdf-ebook)
|
||||
* [Podcast](#podcast)
|
||||
* [Translations](#translations)
|
||||
* [Related Projects](#related-projects)
|
||||
* [Contributing](#contributing)
|
||||
@@ -222,7 +230,7 @@ Fitts' law predicts that the time required to move to a target area is a functio
|
||||
|
||||
The consequences of this law dictate that when designing UX or UI, interactive elements should be as large as possible and the distance between the users attention area and interactive element should be as small as possible. This has consequences on design, such as grouping tasks that are commonly used with one another close.
|
||||
|
||||
It also formalises the concept of 'magic corners', the corners of the screen which a user can 'sweep' their mouse too to easily hit - which is where key UI elements can be placed. The Windows Start button is in a magic corner, making it easy to select, and as an interesting contrast, the MacOS 'close window' button is _not_ in a magic corner, making it hard to hit by mistake.
|
||||
It also formalises the concept of 'magic corners', the corners of the screen to which a user can 'sweep' their mouse to easily hit - which is where key UI elements can be placed. The Windows Start button is in a magic corner, making it easy to select, and as an interesting contrast, the MacOS 'close window' button is _not_ in a magic corner, making it hard to hit by mistake.
|
||||
|
||||
See also:
|
||||
|
||||
@@ -381,6 +389,24 @@ See also:
|
||||
- [The Unix Philosophy](#the-unix-philosophy)
|
||||
- [Occam's Razor](#occams-razor)
|
||||
|
||||
### Linus's Law
|
||||
|
||||
[Linus's Law on Wikipedia](https://en.wikipedia.org/wiki/Linus%27s_law)
|
||||
|
||||
> Given enough eyeballs, all bugs are shallow.
|
||||
>
|
||||
> _Eric S. Raymond_
|
||||
|
||||
This law simply states that the more people who can see a problem, the higher the likelihood that someone will have seen and solved the problem before, or something very similar.
|
||||
|
||||
Although it was originally used to describe the value of open-source models for projects it can be accepted for any kind of software project. It can also be extended to processes - more code reviews, more static analysis and multi-disciplined test processes will make the problems more visible and easy to identify.
|
||||
|
||||
A more formal statement can be:
|
||||
|
||||
> Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and can be solved by someone who has encountered a similar problem before.
|
||||
|
||||
This law was named in honour of [Linus Torvalds](https://en.wikipedia.org/wiki/Linus_Torvalds) in Eric S. Raymond's book "[The Cathedral and the Bazaar](https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar)".
|
||||
|
||||
### Metcalfe's Law
|
||||
|
||||
[Metcalfe's Law on Wikipedia](https://en.wikipedia.org/wiki/Metcalfe's_law)
|
||||
@@ -484,7 +510,6 @@ See also:
|
||||
- [The Peter Principle](#the-peter-principle)
|
||||
- [The Dilbert Principle](#the-dilbert-principle)
|
||||
|
||||
|
||||
### Reed's Law
|
||||
|
||||
[Reed's Law on Wikipedia](https://en.wikipedia.org/wiki/Reed's_law)
|
||||
@@ -571,6 +596,18 @@ The Spotify Model also popularises the concepts of Tribes, Guilds, Chapters, whi
|
||||
|
||||
Members of the organisation have described that the actual meaning of these groups changes, evolves and is an on-going experiment. The fact that the model is a _process in motion_, rather than a fixed model continues to lead to varying interpretations of the structure, which may be based on presentations given by employees at conferences. This means 'snapshots' may be 're-packaged' by third parties as a _fixed structure_, with the fact that the model is dynamic being lost.
|
||||
|
||||
### The Two Pizza Rule
|
||||
|
||||
> If you can't feed a team with two pizzas, it's too large.
|
||||
>
|
||||
> (Jeff Bezos)
|
||||
|
||||
This rule suggests that regardless of the size of the company, teams should be small enough to be fed by two pizzas. Attributed to Jeff Bezos and Amazon, this belief is suggests that large teams are inherently inefficient. This is supported by the fact that as the team size increases linearly, the links between people increases exponentially; thus the cost of coordinating and communicating also grows exponentially. If this cost of coordination is essentially overhead, then smaller teams should be preferred.
|
||||
|
||||
The number of links between people can be expressed as `n(n-1)/2` where n = number of people.
|
||||
|
||||
<img width="200px" alt="Complete graph; Links between people" src="./images/complete_graph.png" />
|
||||
|
||||
### Wadler's Law
|
||||
|
||||
[Wadler's Law on wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law)
|
||||
@@ -606,6 +643,32 @@ Coined by Wil Wheaton (Star Trek: The Next Generation, The Big Bang Theory), thi
|
||||
|
||||
Principles are generally more likely to be guidelines relating to design.
|
||||
|
||||
### All Models Are Wrong (George Box's Law)
|
||||
|
||||
[All Models Are Wrong](https://en.wikipedia.org/wiki/All_models_are_wrong)
|
||||
|
||||
> All models are wrong, but some are useful.
|
||||
>
|
||||
> _George Box_
|
||||
|
||||
This principle suggests that all models of systems are flawed, but that as long as they are not _too_ flawed they may be useful. This principle has its roots in statistics but applies to scientific and computing models as well.
|
||||
|
||||
A fundamental requirement of most software is to model a system of some kind. Regardless of whether the system being modeled is a computer network, a library, a graph of social connections or any other kind of system, the designer will have to decide an appropriate level of detail to model. Excessive detail may lead to too much complexity, too little detail may prevent the model from being functional.
|
||||
|
||||
See also:
|
||||
|
||||
- [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions)
|
||||
|
||||
### Chesterson's Fence
|
||||
|
||||
[Chesterson's Fence on Wikipedia](https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence)
|
||||
|
||||
> Reforms should not be made until the reasoning behind the existing state of affairs is understood.
|
||||
|
||||
This principle is relevant in software engineering when removing technical debt. Each line of a program was originally written by someone for some reason. Chesterson's Fence suggests that one should try to understand the context and meaning of the code fully, before changing or removing it, even if at first glance it seems redundant or incorrect.
|
||||
|
||||
The name of this principle comes from a story by [G.K. Chesterson](https://en.wikipedia.org/wiki/G._K._Chesterton). A man comes across a fence crossing the middle of the road. He complains to the mayor that this useless fence is getting in the way, and asks to remove it. The mayor asks why the fence is there in the first place. When the man says he doesn't know, the mayor says, "If you don't know its purpose, I certainly won't let you remove it. Go and find out the use of it, and then I may let you destroy it."
|
||||
|
||||
### The Dead Sea Effect
|
||||
|
||||
[The Dead Sea Effect on Bruce F. Webster](http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-dead-sea-effect/)
|
||||
@@ -618,7 +681,6 @@ The "Dead Sea Effect" suggests that in any organisation, the skills/talent/effic
|
||||
|
||||
Typically, highly skilled engineers find it easy to gain employment elsewhere and are the first to do so. Engineers who have obsolete or weak skills will tend to remain with the company, as finding employment elsewhere is difficult. This is particularly pronounced if they have gained incremental pay rises over their time in the company, as it can be challenging to get equivalent remuneration elsewhere.
|
||||
|
||||
|
||||
### The Dilbert Principle
|
||||
|
||||
[The Dilbert Principle on Wikipedia](https://en.wikipedia.org/wiki/Dilbert_principle)
|
||||
@@ -656,6 +718,25 @@ Real-world examples:
|
||||
|
||||
- In 2002 Microsoft reported that by fixing the top 20% of the most-reported bugs, 80% of the related errors and crashes in windows and office would become eliminated ([Reference](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm)).
|
||||
|
||||
### The Shirky Principle
|
||||
|
||||
[The Shirky Principle explained](https://kk.org/thetechnium/the-shirky-prin/)
|
||||
|
||||
> Institutions will try to preserve the problem to which they are the solution.
|
||||
>
|
||||
> _Clay Shirky_
|
||||
|
||||
The Shirky Principle suggests that complex solutions - a company, an industry, or a technology - can become so focused on the problem that they are solving, that they can inadvertently perpetuate the problem itself. This may be deliberate (a company striving to find new nuances to a problem which justify continued development of a solution), or inadvertent (being unable or unwilling to accept or build a solution which solves the problem completely or obviates it).
|
||||
|
||||
Related to:
|
||||
|
||||
- Upton Sinclair's famous line, _"It is difficult to get a man to understand something, when his salary depends upon his not understanding it!"_
|
||||
- Clay Christensen's _The Innovator's Dilemma_
|
||||
|
||||
See also:
|
||||
|
||||
- [Pareto Principle](#the-pareto-principle)
|
||||
|
||||
### The Peter Principle
|
||||
|
||||
[The Peter Principle on Wikipedia](https://en.wikipedia.org/wiki/Peter_principle)
|
||||
@@ -854,7 +935,7 @@ Also known as _Fallacies of Networked Computing_, the Fallacies are a list of co
|
||||
|
||||
The first four items were listed by [Bill Joy](https://en.wikipedia.org/wiki/Bill_Joy) and [Tom Lyon](https://twitter.com/aka_pugs) around 1991 and first classified by [James Gosling](https://en.wikipedia.org/wiki/James_Gosling) as the "Fallacies of Networked Computing". [L. Peter Deutsch](https://en.wikipedia.org/wiki/L._Peter_Deutsch) added the 5th, 6th and 7th fallacies. In the late 90's Gosling added the 8th fallacy.
|
||||
|
||||
The group were inspired by what was happening at the time inside [Sun Microsystems](https://en.wikipedia.org/wiki/Sun_Microsystems).
|
||||
The group was inspired by what was happening at the time inside [Sun Microsystems](https://en.wikipedia.org/wiki/Sun_Microsystems).
|
||||
|
||||
These fallacies should be considered carefully when designing code which is resilient; assuming any of these fallacies can lead to flawed logic which fails to deal with the realities and complexities of distributed systems.
|
||||
|
||||
@@ -862,7 +943,6 @@ See also:
|
||||
|
||||
- [Foraging for the Fallacies of Distributed Computing (Part 1) - Vaidehi Joshi
|
||||
on Medium](https://medium.com/baseds/foraging-for-the-fallacies-of-distributed-computing-part-1-1b35c3b85b53)
|
||||
- [Deutsch's Fallacies, 10 Years After](http://java.sys-con.com/node/38665)
|
||||
|
||||
## Reading List
|
||||
|
||||
@@ -871,8 +951,26 @@ If you have found these concepts interesting, you may enjoy the following books.
|
||||
- [Extreme Programming Installed - Ron Jeffries, Ann Anderson, Chet Hendrikson](https://www.goodreads.com/en/book/show/67834) - Covers the core principles of Extreme Programming.
|
||||
- [The Mythical Man Month - Frederick P. Brooks Jr.](https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month) - A classic volume on software engineering. [Brooks' Law](#brooks-law) is a central theme of the book.
|
||||
- [Gödel, Escher, Bach: An Eternal Golden Braid - Douglas R. Hofstadter.](https://www.goodreads.com/book/show/24113.G_del_Escher_Bach) - This book is difficult to classify. [Hofstadter's Law](#hofstadters-law) is from the book.
|
||||
- [The Cathedral and the Bazaar - Eric S. Raymond](https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar) - a collection of essays on open source. This book was the source of [Linus's Law](#linuss-law).
|
||||
- [The Dilbert Principle - Scott Adams](https://www.goodreads.com/book/show/85574.The_Dilbert_Principle) - A comic look at corporate America, from the author who created the [Dilbert Principle](#the-dilbert-principle).
|
||||
- [The Peter Principle - Lawrence J. Peter](https://www.goodreads.com/book/show/890728.The_Peter_Principle) - Another comic look at the challenges of larger organisations and people management, the source of [The Peter Principle](#the-peter-principle).
|
||||
- [Structure and Interpretation of Computer Programs - Harold Abelson, Gerald Jay Sussman, Julie Sussman](https://www.goodreads.com/book/show/43713) - If you were a comp sci or electical engineering student at MIT or Cambridge this was your intro to programming. Widely reported as being a turning point in people's lives.
|
||||
|
||||
## Online Resources
|
||||
|
||||
Some useful resources and reading.
|
||||
|
||||
- [CB Insights: 8 Laws Driving Success In Tech: Amazon's 2-Pizza Rule, The 80/20 Principle, & More](https://www.cbinsights.com/research/report/tech-laws-success-failure) - an interesting write up of some laws which have been highly influential in technology.
|
||||
|
||||
## PDF eBook
|
||||
|
||||
The project is available as a PDF eBook, [download the latest PDF eBook with this link](https://github.com/dwmkerr/hacker-laws/releases/latest/download/hacker-laws.pdf) or check the [release](https://github.com/dwmkerr/hacker-laws/releases) page for older versions.
|
||||
|
||||
## Podcast
|
||||
|
||||
Hacker Laws has been featured in [The Changelog](https://changelog.com/podcast/403), you can check out the Podcast episode with the link below:
|
||||
|
||||
<a href="https://changelog.com/podcast/403" target="_blank"><img src="./images/changelog-podcast.png" width="800px" alt="Changelog Podcast Image" /></a>
|
||||
|
||||
## Translations
|
||||
|
||||
@@ -900,6 +998,7 @@ If you would like to update a translation, just [open a pull request](https://gi
|
||||
|
||||
- [Tip of the Day](https://tips.darekkay.com/html/hacker-laws-en.html) - Receive a daily hacker law/principle.
|
||||
- [Hacker Laws CLI](https://github.com/umutphp/hacker-laws-cli) - List, view and see random laws from the terminal!
|
||||
- [Hacker Laws Action](https://github.com/marketplace/actions/hacker-laws-action) - Adds a random Hacker Law to a pull request as a small gift for the contributor, thanks [Umut Işık](https://github.com/umutphp)
|
||||
|
||||
## Contributing
|
||||
|
||||
|
||||
BIN
images/changelog-podcast.png
Normal file
BIN
images/changelog-podcast.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 88 KiB |
BIN
images/complete_graph.png
Normal file
BIN
images/complete_graph.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 50 KiB |
@@ -1,17 +1,22 @@
|
||||
#!/usr/bin/env bash
|
||||
#
|
||||
# Requirements:
|
||||
# - pandoc
|
||||
# - xelatex
|
||||
# brew install
|
||||
# brew cask install basictex
|
||||
# This script prepares a `hacker-laws.md` file which is in a format ready to be
|
||||
# exported to PDF or other formats for an e-book.
|
||||
|
||||
# Require that we provide the version number and get a date.
|
||||
version=$1
|
||||
date=$(date "+%Y-%m-%d")
|
||||
|
||||
if [ -z $version ]; then
|
||||
echo "version must be specified: ./prepare-markdown-for-ebook.sh <version>"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Create the frontmatter.
|
||||
cat << EOF > frontmatter.md
|
||||
---
|
||||
title: "Hacker Laws"
|
||||
author: "Dave Kerr, github.com/dwmkerr/hacker-laws"
|
||||
subtitle: "Laws, Theories, Principles and Patterns that developers will find useful."
|
||||
subtitle: "Laws, Theories, Principles and Patterns that developers will find useful. ${version}, ${date}."
|
||||
---
|
||||
EOF
|
||||
|
||||
@@ -35,6 +40,3 @@ sed -i '' '/ \*.*/d' hacker-laws.md
|
||||
# Delete everything from 'Translations' onwards (we don't need the translations
|
||||
# lists, related projects, etc).
|
||||
sed -i'' '/## Translations/,$d' hacker-laws.md
|
||||
|
||||
# Now build the e-book as a PDF.
|
||||
pandoc -V toc-title:"Table Of Contents" --toc --pdf-engine=pdflatex -s -o hacker-laws.pdf hacker-laws.md
|
||||
Reference in New Issue
Block a user