This repository has been archived by the owner on Sep 18, 2019. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 369
/
bit006_github-browsability-wins.html
335 lines (290 loc) · 22.8 KB
/
bit006_github-browsability-wins.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta charset="utf-8" />
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="generator" content="pandoc" />
<title>The unreasonable effectiveness of GitHub browsability</title>
<script src="libs/jquery-1.11.3/jquery.min.js"></script>
<meta name="viewport" content="width=device-width, initial-scale=1" />
<link href="libs/bootstrap-3.3.5/css/bootstrap.min.css" rel="stylesheet" />
<script src="libs/bootstrap-3.3.5/js/bootstrap.min.js"></script>
<script src="libs/bootstrap-3.3.5/shim/html5shiv.min.js"></script>
<script src="libs/bootstrap-3.3.5/shim/respond.min.js"></script>
<script src="libs/navigation-1.1/tabsets.js"></script>
<link href="libs/highlightjs-9.12.0/default.css" rel="stylesheet" />
<script src="libs/highlightjs-9.12.0/highlight.js"></script>
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-68219208-1', 'auto');
ga('send', 'pageview');
</script>
<style type="text/css">code{white-space: pre;}</style>
<style type="text/css">
pre:not([class]) {
background-color: white;
}
</style>
<script type="text/javascript">
if (window.hljs) {
hljs.configure({languages: []});
hljs.initHighlightingOnLoad();
if (document.readyState && document.readyState === "complete") {
window.setTimeout(function() { hljs.initHighlighting(); }, 0);
}
}
</script>
<style type="text/css">
h1 {
font-size: 34px;
}
h1.title {
font-size: 38px;
}
h2 {
font-size: 30px;
}
h3 {
font-size: 24px;
}
h4 {
font-size: 18px;
}
h5 {
font-size: 16px;
}
h6 {
font-size: 12px;
}
.table th:not([align]) {
text-align: left;
}
</style>
<link rel="stylesheet" href="libs/local/main.css" type="text/css" />
<link rel="stylesheet" href="libs/local/nav.css" type="text/css" />
<link rel="stylesheet" href="//netdna.bootstrapcdn.com/font-awesome/4.0.3/css/font-awesome.css" type="text/css" />
</head>
<body>
<style type = "text/css">
.main-container {
max-width: 940px;
margin-left: auto;
margin-right: auto;
}
code {
color: inherit;
background-color: rgba(0, 0, 0, 0.04);
}
img {
max-width:100%;
height: auto;
}
.tabbed-pane {
padding-top: 12px;
}
.html-widget {
margin-bottom: 20px;
}
button.code-folding-btn:focus {
outline: none;
}
</style>
<div class="container-fluid main-container">
<!-- tabsets -->
<script>
$(document).ready(function () {
window.buildTabsets("TOC");
});
</script>
<!-- code folding -->
<header>
<div class="nav">
<a class="nav-logo" href="index.html">
<img src="static/img/stat545-logo-s.png" width="70px" height="70px"/>
</a>
<ul>
<li class="home"><a href="index.html">Home</a></li>
<li class="faq"><a href="faq.html">FAQ</a></li>
<li class="syllabus"><a href="syllabus.html">Syllabus</a></li>
<li class="topics"><a href="topics.html">Topics</a></li>
<li class="people"><a href="people.html">People</a></li>
</ul>
</div>
</header>
<div class="fluid-row" id="header">
<h1 class="title toc-ignore">The unreasonable effectiveness of GitHub browsability</h1>
</div>
<div id="TOC">
<ul>
<li><a href="#be-savvy-about-your-files">Be savvy about your files</a></li>
<li><a href="#get-over-your-hang-ups-re-committing-derived-products">Get over your hang ups re: committing derived products</a></li>
<li><a href="#markdown">Markdown</a></li>
<li><a href="#readme.md"><code>README.md</code></a></li>
<li><a href="#finding-stuff">Finding stuff</a></li>
<li><a href="#html">HTML</a></li>
<li><a href="#source-code">Source code</a></li>
<li><a href="#delimited-files">Delimited files</a></li>
<li><a href="#pngs">PNGs</a></li>
<li><a href="#linking-to-a-zip-archive-of-your-repo">Linking to a ZIP archive of your repo</a></li>
<li><a href="#links-and-embedded-figures">Links and embedded figures</a></li>
<li><a href="#let-people-correct-you-on-the-internet">Let people correct you on the internet</a></li>
</ul>
</div>
<p>One of my favorite aspects of GitHub is the ability to inspect a repository’s files in a browser. Certain practices make browsing more rewarding and can postpone the day when you must create a proper website for a project. Perhaps indefinitely.</p>
<div id="be-savvy-about-your-files" class="section level4">
<h4>Be savvy about your files</h4>
<p>Keep files in the plainest, web-friendliest form that is compatible with your main goals. Plain text is the very best. GitHub offers special handling for certain types of files:</p>
<ul>
<li>Markdown files, which may be destined for conversion into, e.g., HTML</li>
<li>Markdown files named <code>README.md</code></li>
<li>HTML files, often the result of compiling Markdown files</li>
<li>Source code, such as <code>.R</code> files</li>
<li>Delimited files, containing data one might bring into R via <code>read.table()</code></li>
<li>PNG files</li>
</ul>
</div>
<div id="get-over-your-hang-ups-re-committing-derived-products" class="section level4">
<h4>Get over your hang ups re: committing derived products</h4>
<p>Let’s acknowledge the discomfort some people feel about putting derived products under version control. Specifically, if you’ve got an R Markdown document <code>foo.Rmd</code>, it can be <code>knit()</code> to produce the intermediate product <code>foo.md</code>, which can be converted to the ultimate output <code>foo.html</code>. Which of those files are you “allowed” to put under version control? Source-is-real hardliners will say only <code>foo.Rmd</code> but pragmatists know this can be a serious bummer in real life. Just because I <em>can</em> rebuild everything from scratch, it doesn’t mean I <em>want</em> to.</p>
<p>The taboo of keeping derived products under version control originates from compilation of binary executables from source. Software built on a Mac would not work on Windows and so it made sense to keep these binaries out of the holy source code repository. Also, you could assume the people with access to the repository have the full development stack and relish opportunities to use it. None of these arguments really apply to the <code>foo.Rmd --> foo.md --> foo.html</code> workflow. We don’t have to blindly follow traditions from the compilation domain!</p>
<p>In fact, looking at the diffs for <code>foo.md</code> or <code>foo-figure-01.png</code> can be extremely informative. This is also true in larger data analytic projects projects after a <code>make clean; make all</code> operation. By looking at the diffs in the downstream products, you often catch unexpected changes. This can tip you off to changes in the underlying data and/or the behavior of packages you depend on.</p>
<p>This is a note about cool things GitHub can do with various file types, if they happen to end up in your repo. I won’t ask you how they got there.</p>
</div>
<div id="markdown" class="section level4">
<h4>Markdown</h4>
<p>You will quickly discover that GitHub renders Markdown files very nicely. By clicking on <code>foo.md</code>, you’ll get a decent preview of <code>foo.html</code>. Yay!</p>
<p>Aggressively exploit this handy feature. Make Markdown your default format for narrative text files and use them liberally to embed notes to yourself and others in a repository hosted on Github. It’s an easy way to get pseudo-webpages inside a project “for free”. You may never even compile these files to HTML explicitly; in many cases, the HTML preview offered by GitHub is all you ever need.</p>
<p>What does this mean for R Markdown files? <strong>Keep intermediate Markdown.</strong> Commit both <code>foo.Rmd</code> and <code>foo.md</code>, even if you choose to <code>.gitignore</code> the final <code>foo.html</code>. As of <a href="https://github.com/github/markup/pull/343">September 2014</a>, GitHub renders R Markdown files nicely, like Markdown, and with proper syntax highlighting, which is great. But, of course, the code blocks just sit there un-executed, so my advice about keeping intermediate Markdown still holds. You want YAML frontmatter that looks something like <a href="https://gist.github.com/jennybc/402761e30b9be8023af9#file-yaml_frontmatter_rmd_keep_md-yml">this</a> for <code>.Rmd</code>:</p>
<pre class="yaml"><code>---
title: "Something fascinating"
author: "Jenny Bryan"
date: "`r format(Sys.Date())`"
output:
html_document:
keep_md: TRUE
---</code></pre>
<p>or like <a href="https://gist.github.com/jennybc/402761e30b9be8023af9#file-yaml_frontmatter_r_keep_md-yml">this</a> for <code>.R</code>:</p>
<pre class="yaml"><code>#' ---
#' title: "Something fascinating"
#' author: "Jenny Bryan"
#' date: "`r format(Sys.Date())`"
#' output:
#' html_document:
#' keep_md: TRUE
#' ---</code></pre>
<p>In RStudio, when editing <code>.Rmd</code>, click on the gear next to “Knit HTML” for YAML authoring help</p>
<p>For a quick, stand-alone document that doesn’t fit neatly into a repository or project (yet), make it a <a href="https://gist.github.com">Gist</a>. Example: Hadley Wickham’s <a href="https://gist.github.com/hadley/820f09ded347c62c2864">advice on what you need to do to become a data scientist</a>. Gists can contain multiple files, so you can still provide the R script or R Markdown source <strong>and</strong> the resulting Markdown, as I’ve done in this write-up of <a href="https://gist.github.com/jennybc/04b71bfaaf0f88d9d2eb">Twitter-sourced tips for cross-tabulation</a>.</p>
</div>
<div id="readme.md" class="section level4">
<h4><code>README.md</code></h4>
<p>You probably already know that GitHub renders <code>README.md</code> at the top-level of your repo as the <em>de facto</em> landing page. This is analogous to what happens when you point a web browser at a directory instead of a specific web page: if there is a file named <code>index.html</code>, that’s what the server will show you by default. On GitHub, files named <code>README.md</code> play exactly this role for directories in your repo.</p>
<p>Implication: for any logical group of files or mini project-within-your-project, create a sub-directory in your repository. And then create a <code>README.md</code> file to annotate these files, collect relevant links, etc. Now when you navigate to the sub-directory on GitHub the nicely rendered <code>README.md</code> will simply appear.</p>
<p>Some repositories consist solely of <code>README.md</code>. Examples: Jeff Leek’s write-ups on <a href="https://github.com/jtleek/datasharing">How to share data with a statistician</a> or <a href="https://github.com/jtleek/rpackages">Developing R packages</a>. I am becoming a bigger fan of <code>README</code>-only repos than gists because repo issues trigger notifications, whereas comments on gists do not.</p>
<p>If you’ve got a directory full of web-friendly figures, such as PNGs, you can use <a href="https://gist.github.com/jennybc/0239f65633e09df7e5f4">code like this</a> to generate a <code>README.md</code> for a quick DIY gallery, as Karl Broman has done with <a href="https://github.com/kbroman/FruitSnacks/blob/master/PhotoGallery.md">his FruitSnacks</a>. I have also used this device to share Keynote slides on GitHub (<em>mea culpa!</em>). Export them as PNGs images and throw ’em into a README gallery: slides on <a href="https://github.com/Reproducible-Science-Curriculum/rr-organization1/tree/27883c8fc4cdd4dcc6a8232f1fe5c726e96708a0/slides/organization-slides">file organization</a> and some on <a href="https://github.com/Reproducible-Science-Curriculum/rr-organization1/tree/27883c8fc4cdd4dcc6a8232f1fe5c726e96708a0/slides/naming-slides">file naming</a>.</p>
</div>
<div id="finding-stuff" class="section level4">
<h4>Finding stuff</h4>
<p>OK these are pure GitHub tips but if you’ve made it this far, you’re obviously a keener.</p>
<ul>
<li>Press <code>t</code> to activate <a href="https://github.com/blog/793-introducing-the-file-finder">the file finder</a> whenever you’re in a repo’s file and directory view. AWESOME, especially when there are files tucked into lots of subdirectories.</li>
<li>Press <code>y</code> to <a href="https://help.github.com/articles/getting-permanent-links-to-files/">get a permanent link</a> when you’re viewing a specific file. Watch what changes in the URL. This is important if you are about to <em>link</em> to a file or <a href="http://stackoverflow.com/questions/23821235/how-to-link-to-specific-line-number-on-github">to specific lines</a>. Otherwise your links will break easily in the future. If the file is deleted or renamed or if lines get inserted or deleted, your links will no longer point to what you intended. Use <code>y</code> to get links that include a specific commit in the URL.</li>
</ul>
</div>
<div id="html" class="section level4">
<h4>HTML</h4>
<p>If you have an HTML file in a GitHub repository, simply visiting the file shows the raw HTML. Here’s a nice ugly example:</p>
<ul>
<li><a href="https://github.com/STAT545-UBC/STAT545-UBC.github.io/blob/master/bit003_api-key-env-var.html" class="uri">https://github.com/STAT545-UBC/STAT545-UBC.github.io/blob/master/bit003_api-key-env-var.html</a></li>
</ul>
<p>No one wants to look at that. <del>You can provide this URL to <a href="http://rawgit.com">rawgit.com</a> to serve this HTML more properly and get a decent preview.</del></p>
<p><del>You can form two different types of URLs with <a href="http://rawgit.com">rawgit.com</a>:</del></p>
<ul>
<li><del>For sharing low-traffic, temporary examples or demos with small numbers of people, do this:</del>
<ul>
<li><del><a href="https://rawgit.com/STAT545-UBC/STAT545-UBC.github.io/master/bit003_api-key-env-var.html" class="uri">https://rawgit.com/STAT545-UBC/STAT545-UBC.github.io/master/bit003_api-key-env-var.html</a></del></li>
<li><del>Basically: replace <code>https://github.com/</code> with <code>https://rawgit.com/</code></del></li>
</ul></li>
<li><del>For use on production websites with any amount of traffic, do this:</del>
<ul>
<li><del><a href="https://cdn.rawgit.com/STAT545-UBC/STAT545-UBC.github.io/master/bit003_api-key-env-var.html" class="uri">https://cdn.rawgit.com/STAT545-UBC/STAT545-UBC.github.io/master/bit003_api-key-env-var.html</a></del></li>
<li><del>Basically: replace <code>https://github.com/</code> with <code>https://cdn.rawgit.com/</code></del></li>
</ul></li>
</ul>
<p><em>2018-10-09 update: RawGit <a href="https://rawgit.com/">announced</a> that it is in a sunset phase and will soon shut down. They recommended: <a href="https://www.jsdelivr.com/rawgit">jsDelivr</a>, <a href="https://pages.github.com/">GitHub Pages</a>, <a href="https://codesandbox.io/">CodeSandbox</a>, and <a href="https://unpkg.com/#/">unpkg</a> as alternatives.</em></p>
<p>This sort of enhanced link might be one of the useful things to put in a <code>README.md</code> or other Markdown file in the repo.</p>
<p>You may also want to check out this <a href="https://chrome.google.com/webstore/detail/github-html-preview/cphnnfjainnhgejcpgboeeakfkgbkfek?hl=en">Chrome extension</a> or <a href="https://htmlpreview.github.io">GitHub & BitBucket HTML Preview</a>, though recently I’ve more success with <a href="http://rawgit.com">rawgit.com</a>.</p>
<p>Sometimes including HTML files will cause GitHub to think that your R repository is HTML. Besides being slightly annoying, this can make it difficult for people to find your work if they are searching specifically for R repos. You can exclude these files or directories from GitHub’s language statistics by <a href="https://github.com/github/linguist#using-gitattributes">adding a .gitattributes file</a> that marks them as ‘documentation’ rather than code. <a href="https://github.com/jennybc/googlesheets/blob/master/.gitattributes">See an example here</a>.</p>
</div>
<div id="source-code" class="section level4">
<h4>Source code</h4>
<p>You will notice that GitHub does automatic syntax highlighting for source code. For example, notice the coloring of this <a href="https://github.com/jennybc/ggplot2-tutorial/blob/master/gapminder-ggplot2-stripplot.r">R script</a>. The file’s extension is the primary determinant for if/how syntax highlighting will be applied. You can see information on recognized languages, the default extensions and more at <a href="https://github.com/github/linguist/blob/master/lib/linguist/languages.yml">github/linguist</a>. You should be doing it anyway, but let this be another reason to follow convention in your use of file extensions.</p>
<p>Note you can click on “Raw” in this context as well, to get just the plain text and nothing but the plain text.</p>
</div>
<div id="delimited-files" class="section level4">
<h4>Delimited files</h4>
<p>GitHub will nicely render tabular data in the form of <code>.csv</code> (comma-separated) and <code>.tsv</code> (tab-separated) files. You can read more in the <a href="https://github.com/blog/1601-see-your-csvs">blog post</a> announcing this feature in August 2013 or in <a href="https://help.github.com/articles/rendering-csv-and-tsv-data">this GitHub help page</a>.</p>
<p>Advice: take advantage of this! If something in your repo can be naturally stored as delimited data, by all means, do so. Make the comma or tab your default delimiter and use the file suffixes GitHub is expecting. I have noticed that GitHub is more easily confused than R about things like quoting, so always inspect the GitHub-rendered <code>.csv</code> or <code>.tsv</code> file in the browser. You may need to do light cleaning to get the automagic rendering to work properly. Think of it as yet another way to learn about imperfections in your data.</p>
<p>Here’s an example of a tab delimited file on GitHub: <a href="https://github.com/jennybc/lotr/blob/master/lotr_clean.tsv">lotr_clean.tsv</a>, originally found <del>here</del> (nope, IBM shut down manyeyes July 2015).</p>
<p>Note you can click on “Raw” in this context as well, to get just the plain text and nothing but the plain text.</p>
</div>
<div id="pngs" class="section level4">
<h4>PNGs</h4>
<p>PNG is the “no brainer” format in which to store figures for the web. But many of us like a vector-based format, such as PDF, for general purpose figures. Bottom line: PNGs will drive you less crazy than PDFs on GitHub. To reduce the aggravation around viewing figures in the browser, make sure to have a PNG version in the repo.</p>
<p>Examples:</p>
<ul>
<li><a href="https://github.com/jennybc/STAT545A/blob/master/hw06_scaffolds/01_justR/stripplot_wordsByRace_The_Fellowship_Of_The_Ring.png">This PNG figure</a> just shows up in the browser</li>
<li>A different figure <a href="https://github.com/jennybc/ggplot2-tutorial/blob/master/gapminder-country-colors.pdf">stored as PDF</a> <del>produces the dreaded, annoying “View Raw” speed bump. You’ll have to click through and, on my OS + browser, wait for the PDF to appear in an external PDF viewer.</del> <em>2015-06-19 update: since I first wrote this GitHub has <a href="https://github.com/blog/1974-pdf-viewing">elevated its treament of PDFs</a> so YAY. It’s slow but it works.</em></li>
</ul>
<p>Hopefully we are moving towards a world where you can have “web friendly” and “vector” at the same time, without undue headaches. As of <a href="https://github.com/blog/1902-svg-viewing-diffing">October 2014</a>, GitHub provides enhanced viewing and diffing of SVGs. So don’t read this advice as discouraging SVGs. Make them! But consider keeping a PNG around as emergency back up for now.</p>
</div>
<div id="linking-to-a-zip-archive-of-your-repo" class="section level4">
<h4>Linking to a ZIP archive of your repo</h4>
<p>The browsability of GitHub makes your work accessible to people who care about your content but who don’t (yet) use Git themselves. What if such a person wants all the files? Yes, there is a clickable “Download ZIP” button offered by GitHub. But what if you want a link to include in an email or other document? If you add <code>/archive/master.zip</code> <em>to the end</em> of the URL for your repo, you construct a link that will download a ZIP archive of your repository. Click here to try this out on a very small repo:</p>
<p><a href="https://github.com/jennybc/lotr/archive/master.zip" class="uri">https://github.com/jennybc/lotr/archive/master.zip</a></p>
<p>Go look in your downloads folder!</p>
</div>
<div id="links-and-embedded-figures" class="section level4">
<h4>Links and embedded figures</h4>
<ul>
<li><p>To link to another page in your repo, just use a relative link: <code>[admin](courseAdmin/)</code> will link to the <code>courseAdmin/</code> directory inside the current directory. <code>[admin](/courseAdmin/)</code> will link to the top-level <code>courseAdmin/</code> directory from any where in the repo</p></li>
<li><p>The same idea also works for images. <code></code> will include <code>image.png</code> located in the current directory</p></li>
</ul>
</div>
<div id="let-people-correct-you-on-the-internet" class="section level4">
<h4>Let people correct you on the internet</h4>
<p>They love that!</p>
<p>You can create a link that takes people directly to an editing interface in the browser. Behind the scenes, assuming the clicker is signed into GitHub but is not you, this will create a fork in their account and send you a pull request. When I click the link below, I am able to actually commit directly to <code>master</code> for this repo.</p>
<p><a href="https://github.com/STAT545-UBC/STAT545-UBC.github.io/edit/master/bit006_github-browsability-wins.md">CLICK HERE to suggest an edit to this page!</a></p>
<p>Here’s what that link looks like in the Markdown source:</p>
<pre><code>[CLICK HERE to suggest an edit to this page!](https://github.com/STAT545-UBC/STAT545-UBC.github.io/edit/master/bit006_github-browsability-wins.md)</code></pre>
<p>and here it is with placeholders:</p>
<pre><code>[INVITATION TO EDIT](<URL to your repo>/edit/master/<path to your md file>)</code></pre>
<p>AFAIK, to do that in a slick automatic way across an entire repo/site, you need to be using Jekyll or some other automated system. But you could easily handcode such links on a small scale.</p>
</div>
<div class="footer">
This work is licensed under the <a href="http://creativecommons.org/licenses/by-nc/3.0/">CC BY-NC 3.0 Creative Commons License</a>.
</div>
</div>
<script>
// add bootstrap table styles to pandoc tables
function bootstrapStylePandocTables() {
$('tr.header').parent('thead').parent('table').addClass('table table-condensed');
}
$(document).ready(function () {
bootstrapStylePandocTables();
});
</script>
<!-- dynamically load mathjax for compatibility with self-contained -->
<script>
(function () {
var script = document.createElement("script");
script.type = "text/javascript";
script.src = "https://mathjax.rstudio.com/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML";
document.getElementsByTagName("head")[0].appendChild(script);
})();
</script>
</body>
</html>