40 |
41 |
45 |
46 | 47 |
57 |
58 |
59 |
60 |
61 |
--------------------------------------------------------------------------------
/test_projects/readme/_expected/index.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 | jekyll-build-pages
42 | 43 | 44 |45 |
46 | 47 |
Buy our red shirt in medium!
48 | 49 | 50 | 51 | 52 | 55 | 56 |
40 |
41 |
57 |
58 |
59 |
60 |
61 |
--------------------------------------------------------------------------------
/test_projects/simple/_expected/index.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 | jekyll-build-pages
42 | 43 | 44 |Readme Test
45 | 46 |Uses jekyll-readme-index plugin by default.
47 | 48 |Here’s a jemoji 
40 |
41 |
58 |
59 |
60 |
61 |
62 |
--------------------------------------------------------------------------------
/bin/sync_expected_output.ps1:
--------------------------------------------------------------------------------
1 | #!/usr/bin/env pwsh
2 | #Requires -Version 7.2
3 |
4 | <#
5 | .SYNOPSIS
6 | Trigger the workflow that records the tests expected outputs, wait for its execution to finish,
7 | then bring back those results locally.
8 |
9 | .DESCRIPTION
10 | This script is meant to run locally outside of Actions. It relies on `gh` and `git`.
11 | #>
12 |
13 | # Get the repository's path (ps1 extension on the script is required for PSScriptRoot to be available 🤦)
14 | $repositoryPath = Resolve-Path (Join-Path $PSScriptRoot '..')
15 |
16 | # Get the test_project's path
17 | $testProjectsPath = Resolve-Path (Join-Path $PSScriptRoot '../test_projects')
18 |
19 | #
20 | # Utilities
21 | #
22 |
23 | # Run a command and validate it returned a 0 exit code
24 | function Invoke-Command {
25 | param (
26 | [ScriptBlock] $Command
27 | )
28 |
29 | & $Command
30 | if ($LASTEXITCODE -ne 0) {
31 | Write-Error "Command failed: $Command"
32 | throw
33 | }
34 | }
35 |
36 | # Get the current git ref name
37 | function Get-GitRef {
38 | $commitId = Invoke-Command { & git -C $repositoryPath rev-parse --abbrev-ref HEAD }
39 | $commitId.Trim()
40 | }
41 |
42 | # Create a temp folder and return its path
43 | function New-TemporaryFolder {
44 | $path = Join-Path ([System.IO.Path]::GetTempPath()) ([System.Guid]::NewGuid())
45 | New-Item -ItemType 'Directory' -Path $path | Out-Null
46 | $path
47 | }
48 |
49 | #
50 | # Main
51 | #
52 |
53 | # Init
54 | Set-StrictMode -version 'Latest'
55 | $ErrorActionPreference = 'Stop'
56 |
57 | # Get git ref name
58 | $ref = Get-GitRef
59 |
60 | # Run the workflow
61 | Write-Host 'Queue workflow'
62 | $workflow = 'record.yml'
63 | Invoke-Command { & gh workflow run $workflow --ref $ref | Out-Null }
64 |
65 | # Wait for a few seconds for the workflow to get created
66 | Write-Host 'Wait a few seconds...'
67 | Start-Sleep -Seconds 5
68 |
69 | # Lookup the run id (it is not perfect because of the APIs...)
70 | Write-Host 'Lookup run id'
71 | $runId = Invoke-Command { & gh run list --workflow $workflow --branch $ref --limit 1 --json databaseId --jq '.[].databaseId' }
72 |
73 | # Wait for the workflow to finish
74 | Write-Host "Wait for workflow $runId to complete"
75 | Invoke-Command { & gh run watch $runId --exit-status }
76 |
77 | # Download the artifacts in a temp folder
78 | Write-Host 'Download artifacts'
79 | $tempFolder = New-TemporaryFolder
80 | Invoke-Command { & gh run download $runId --dir $tempFolder }
81 |
82 | # Iterate over the test projects
83 | Get-ChildItem -Path $testProjectsPath -Directory | ForEach-Object {
84 | # Construct the artifact path and make sure a matching artifact is found
85 | $artifactPath = Join-Path $tempFolder $_.BaseName
86 | if (Test-Path $artifactPath -PathType 'Container') {
87 | # Copy artifact to the expected output folder
88 | $destinationPath = Join-Path $testProjectsPath $_.BaseName '_expected'
89 | Copy-Item -Path (Join-Path $artifactPath '*') -Destination $destinationPath -Recurse -Force | Out-Null
90 | }
91 |
92 | # Ignore test project
93 | else {
94 | Write-Warning "Unable to find artifact for test project $($_.BaseName)"
95 | }
96 | }
97 |
--------------------------------------------------------------------------------
/test_projects/future-true/_expected/2022/03/01/we-live-in-hell.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 | Jekyll Actions Demo
42 | 43 | 44 |Hello Welcome to My Home Page
45 | 46 |-
47 |
- Original date - 2020-04-13T10:20:00Z 48 |
- With timeago filter - 2020-04-13T10:20:00Z 49 |
41 |
42 |
54 |
55 |
56 |
57 |
58 |
--------------------------------------------------------------------------------
/test_projects/future-false/_expected/2020/02/13/the-future-is-looking-bright.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 | jekyll-build-pages
43 | 44 | 45 |And it’s not even the cool hell that [redacted] are afraid of. 😭
46 | 47 | 48 | 49 | 52 | 53 |
41 |
42 |
54 |
55 |
56 |
57 |
58 |
--------------------------------------------------------------------------------
/test_projects/future-true/_expected/2020/02/13/the-future-is-looking-bright.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 | jekyll-build-pages
43 | 44 | 45 |Everything’s coming up Milhouse.
46 | 47 | 48 | 49 | 52 | 53 |
41 |
42 |
54 |
55 |
56 |
57 |
58 |
--------------------------------------------------------------------------------
/test_projects/themes/_expected/index.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 | jekyll-build-pages
43 | 44 | 45 |Everything’s coming up Milhouse.
46 | 47 | 48 | 49 | 52 | 53 |
43 |
44 |
58 |
59 |
60 |
64 |
70 |
71 |
72 |
73 |
74 |
--------------------------------------------------------------------------------
/test_projects/octicons/_expected/index.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 | themes
45 | 46 | 47 | 48 |A simple GitHub Action for producing Jekyll build artifacts compatible with GitHub Pages.
49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 |Theme: jekyll-theme-minimal
61 | 62 | 63 |
40 |
41 |
56 |
57 |
58 |
59 |
60 |
--------------------------------------------------------------------------------
/test_projects/mojombo/_layouts/default.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 | jekyll-build-pages
42 | 43 | 44 |Readme Test
45 | 46 | 47 | 48 | 49 | 50 | 51 | 54 | 55 |
29 |
61 |
62 |
30 | Tom Preston-Werner
31 | home
32 |
33 |
34 | {{ content }}
35 |
36 |
37 |
60 |
38 |
48 |
39 | Tom Preston-Werner
40 |
41 | Cofounder of
42 | Codestarter,
43 | GitHub
44 |
45 | tom@mojombo.com
46 |
49 |
54 |
50 | github.com/mojombo
51 | twitter.com/mojombo
52 |
55 |
56 | 
57 |
58 |
59 |
57 |
58 | 
63 |
64 |
65 |
66 |
70 |
73 |
74 |
75 |
76 |
80 |
84 |
85 |
86 |
87 |
88 |
--------------------------------------------------------------------------------
/test_projects/mojombo/_posts/2015-06-19-replicated.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: post
3 | title: Replicated - An Easier Path from SaaS to Enterprise
4 | ---
5 |
6 | {{ page.title }}
7 | ================
8 |
9 |
10 |
11 | Over the last year I've had a chance to learn a lot more about early stage
12 | funding and made angel investments in a handful of startups. So far I've
13 | restricted my involvement to companies with ideas in which I have significant
14 | domain knowledge. I also insist on founders with relentless product focus, a
15 | fierce desire to help their customers be more awesome, and excellent
16 | communication skills. I recently met just such a company, with just such
17 | founders, tackling a problem that has personally caused me much pain.
18 |
19 | The company is [Replicated](http://replicated.com), and founders Grant Miller
20 | and Marc Campbell are making it easier to roll out an on-prem Enterprise
21 | offering based on an existing cloud-based SaaS product.
22 |
23 | At GitHub, we burned through **a lot** of developer cycles building our own
24 | installer (several times), securing the installation environment, coding an
25 | automated licensing management system, integrating single sign-on services
26 | (LDAP, Active Directory, CAS, etc, etc), building out a searchable audit system,
27 | supporting customer-reviewable support bundles (logs and other diagnostic
28 | output), allowing numerous backup strategies, and countless other
29 | Enterprise-specific features that were killing our Enterprise deals. All of this
30 | on top of hiring and building out the necessary sales, support, and accounting
31 | teams to create a smooth Enterprise experience for our customers.
32 |
33 | Replicated provides common Enterprise functionality (much of what I mentioned
34 | above, and all of it eventually) that you can wrap around your SaaS product,
35 | resulting in a first-class on-prem product in a fraction of the time. Beyond
36 | just technology, Replicated will help you understand your Enterprise customers
37 | through documentation on best practices and insight into the requirements and
38 | reasons that large companies desire the features they do. Until you can
39 | empathise with your customer (which is very hard to do as a fast-moving SaaS
40 | startup), you'll never build the best product possible.
41 |
42 | Getting into the Enterprise market will always be hard. But by reducing the
43 | technology burden, Replicated plans to erase much of the pain so you can focus
44 | on the other human-centric tasks. Not only am I an investor in Replicated, I
45 | believe in their mission and their founders so much that I've joined as an
46 | advisor. I understand what the uphill slog of the SaaS to Enterprise climb feels
47 | like, and I'm going to do my best to ensure you don't have to suffer it as much
48 | as I did.
49 |
50 | I'm also pleased to announce that Travis CI is now shipping their Enterprise
51 | product using Replicated. To see what the installation process is like, [watch
52 | Grant install Travis CI
53 | Enterprise](https://www.youtube.com/watch?v=ViN-qkcovL0&feature=youtu.be) on a
54 | fresh server in about seven minutes. For a deeper dive, Travis CI has also
55 | published a blog post covering some of their process in [getting their
56 | Enterprise installer ready using
57 | Replicated](http://blog.travis-ci.com/2015-06-19-how-we-improved-travis-ci-installation/).
58 |
59 | In the coming weeks, you'll start to see other well-known startups launching (or
60 | re-launching) Enterprise versions of their SaaS software on top of Replicated.
61 | If you're looking to do the same, and want to save yourself a lot of heartache,
62 | email [contact@replicated.com](mailto:contact@replicated.com), and start
63 | focusing on what matters the most: your unique and kickass product.
64 |
--------------------------------------------------------------------------------
/test_projects/mojombo/css/syntax.css:
--------------------------------------------------------------------------------
1 | .highlight { background: #ffffff; }
2 | .highlight .c { color: #999988; font-style: italic } /* Comment */
3 | .highlight .err { color: #a61717; background-color: #e3d2d2 } /* Error */
4 | .highlight .k { font-weight: bold } /* Keyword */
5 | .highlight .o { font-weight: bold } /* Operator */
6 | .highlight .cm { color: #999988; font-style: italic } /* Comment.Multiline */
7 | .highlight .cp { color: #999999; font-weight: bold } /* Comment.Preproc */
8 | .highlight .c1 { color: #999988; font-style: italic } /* Comment.Single */
9 | .highlight .cs { color: #999999; font-weight: bold; font-style: italic } /* Comment.Special */
10 | .highlight .gd { color: #000000; background-color: #ffdddd } /* Generic.Deleted */
11 | .highlight .gd .x { color: #000000; background-color: #ffaaaa } /* Generic.Deleted.Specific */
12 | .highlight .ge { font-style: italic } /* Generic.Emph */
13 | .highlight .gr { color: #aa0000 } /* Generic.Error */
14 | .highlight .gh { color: #999999 } /* Generic.Heading */
15 | .highlight .gi { color: #000000; background-color: #ddffdd } /* Generic.Inserted */
16 | .highlight .gi .x { color: #000000; background-color: #aaffaa } /* Generic.Inserted.Specific */
17 | .highlight .go { color: #888888 } /* Generic.Output */
18 | .highlight .gp { color: #555555 } /* Generic.Prompt */
19 | .highlight .gs { font-weight: bold } /* Generic.Strong */
20 | .highlight .gu { color: #aaaaaa } /* Generic.Subheading */
21 | .highlight .gt { color: #aa0000 } /* Generic.Traceback */
22 | .highlight .kc { font-weight: bold } /* Keyword.Constant */
23 | .highlight .kd { font-weight: bold } /* Keyword.Declaration */
24 | .highlight .kp { font-weight: bold } /* Keyword.Pseudo */
25 | .highlight .kr { font-weight: bold } /* Keyword.Reserved */
26 | .highlight .kt { color: #445588; font-weight: bold } /* Keyword.Type */
27 | .highlight .m { color: #009999 } /* Literal.Number */
28 | .highlight .s { color: #d14 } /* Literal.String */
29 | .highlight .na { color: #008080 } /* Name.Attribute */
30 | .highlight .nb { color: #0086B3 } /* Name.Builtin */
31 | .highlight .nc { color: #445588; font-weight: bold } /* Name.Class */
32 | .highlight .no { color: #008080 } /* Name.Constant */
33 | .highlight .ni { color: #800080 } /* Name.Entity */
34 | .highlight .ne { color: #990000; font-weight: bold } /* Name.Exception */
35 | .highlight .nf { color: #990000; font-weight: bold } /* Name.Function */
36 | .highlight .nn { color: #555555 } /* Name.Namespace */
37 | .highlight .nt { color: #000080 } /* Name.Tag */
38 | .highlight .nv { color: #008080 } /* Name.Variable */
39 | .highlight .ow { font-weight: bold } /* Operator.Word */
40 | .highlight .w { color: #bbbbbb } /* Text.Whitespace */
41 | .highlight .mf { color: #009999 } /* Literal.Number.Float */
42 | .highlight .mh { color: #009999 } /* Literal.Number.Hex */
43 | .highlight .mi { color: #009999 } /* Literal.Number.Integer */
44 | .highlight .mo { color: #009999 } /* Literal.Number.Oct */
45 | .highlight .sb { color: #d14 } /* Literal.String.Backtick */
46 | .highlight .sc { color: #d14 } /* Literal.String.Char */
47 | .highlight .sd { color: #d14 } /* Literal.String.Doc */
48 | .highlight .s2 { color: #d14 } /* Literal.String.Double */
49 | .highlight .se { color: #d14 } /* Literal.String.Escape */
50 | .highlight .sh { color: #d14 } /* Literal.String.Heredoc */
51 | .highlight .si { color: #d14 } /* Literal.String.Interpol */
52 | .highlight .sx { color: #d14 } /* Literal.String.Other */
53 | .highlight .sr { color: #009926 } /* Literal.String.Regex */
54 | .highlight .s1 { color: #d14 } /* Literal.String.Single */
55 | .highlight .ss { color: #990073 } /* Literal.String.Symbol */
56 | .highlight .bp { color: #999999 } /* Name.Builtin.Pseudo */
57 | .highlight .vc { color: #008080 } /* Name.Variable.Class */
58 | .highlight .vg { color: #008080 } /* Name.Variable.Global */
59 | .highlight .vi { color: #008080 } /* Name.Variable.Instance */
60 | .highlight .il { color: #009999 } /* Literal.Number.Integer.Long */
61 |
--------------------------------------------------------------------------------
/test_projects/mojombo/_expected/css/syntax.css:
--------------------------------------------------------------------------------
1 | .highlight { background: #ffffff; }
2 | .highlight .c { color: #999988; font-style: italic } /* Comment */
3 | .highlight .err { color: #a61717; background-color: #e3d2d2 } /* Error */
4 | .highlight .k { font-weight: bold } /* Keyword */
5 | .highlight .o { font-weight: bold } /* Operator */
6 | .highlight .cm { color: #999988; font-style: italic } /* Comment.Multiline */
7 | .highlight .cp { color: #999999; font-weight: bold } /* Comment.Preproc */
8 | .highlight .c1 { color: #999988; font-style: italic } /* Comment.Single */
9 | .highlight .cs { color: #999999; font-weight: bold; font-style: italic } /* Comment.Special */
10 | .highlight .gd { color: #000000; background-color: #ffdddd } /* Generic.Deleted */
11 | .highlight .gd .x { color: #000000; background-color: #ffaaaa } /* Generic.Deleted.Specific */
12 | .highlight .ge { font-style: italic } /* Generic.Emph */
13 | .highlight .gr { color: #aa0000 } /* Generic.Error */
14 | .highlight .gh { color: #999999 } /* Generic.Heading */
15 | .highlight .gi { color: #000000; background-color: #ddffdd } /* Generic.Inserted */
16 | .highlight .gi .x { color: #000000; background-color: #aaffaa } /* Generic.Inserted.Specific */
17 | .highlight .go { color: #888888 } /* Generic.Output */
18 | .highlight .gp { color: #555555 } /* Generic.Prompt */
19 | .highlight .gs { font-weight: bold } /* Generic.Strong */
20 | .highlight .gu { color: #aaaaaa } /* Generic.Subheading */
21 | .highlight .gt { color: #aa0000 } /* Generic.Traceback */
22 | .highlight .kc { font-weight: bold } /* Keyword.Constant */
23 | .highlight .kd { font-weight: bold } /* Keyword.Declaration */
24 | .highlight .kp { font-weight: bold } /* Keyword.Pseudo */
25 | .highlight .kr { font-weight: bold } /* Keyword.Reserved */
26 | .highlight .kt { color: #445588; font-weight: bold } /* Keyword.Type */
27 | .highlight .m { color: #009999 } /* Literal.Number */
28 | .highlight .s { color: #d14 } /* Literal.String */
29 | .highlight .na { color: #008080 } /* Name.Attribute */
30 | .highlight .nb { color: #0086B3 } /* Name.Builtin */
31 | .highlight .nc { color: #445588; font-weight: bold } /* Name.Class */
32 | .highlight .no { color: #008080 } /* Name.Constant */
33 | .highlight .ni { color: #800080 } /* Name.Entity */
34 | .highlight .ne { color: #990000; font-weight: bold } /* Name.Exception */
35 | .highlight .nf { color: #990000; font-weight: bold } /* Name.Function */
36 | .highlight .nn { color: #555555 } /* Name.Namespace */
37 | .highlight .nt { color: #000080 } /* Name.Tag */
38 | .highlight .nv { color: #008080 } /* Name.Variable */
39 | .highlight .ow { font-weight: bold } /* Operator.Word */
40 | .highlight .w { color: #bbbbbb } /* Text.Whitespace */
41 | .highlight .mf { color: #009999 } /* Literal.Number.Float */
42 | .highlight .mh { color: #009999 } /* Literal.Number.Hex */
43 | .highlight .mi { color: #009999 } /* Literal.Number.Integer */
44 | .highlight .mo { color: #009999 } /* Literal.Number.Oct */
45 | .highlight .sb { color: #d14 } /* Literal.String.Backtick */
46 | .highlight .sc { color: #d14 } /* Literal.String.Char */
47 | .highlight .sd { color: #d14 } /* Literal.String.Doc */
48 | .highlight .s2 { color: #d14 } /* Literal.String.Double */
49 | .highlight .se { color: #d14 } /* Literal.String.Escape */
50 | .highlight .sh { color: #d14 } /* Literal.String.Heredoc */
51 | .highlight .si { color: #d14 } /* Literal.String.Interpol */
52 | .highlight .sx { color: #d14 } /* Literal.String.Other */
53 | .highlight .sr { color: #009926 } /* Literal.String.Regex */
54 | .highlight .s1 { color: #d14 } /* Literal.String.Single */
55 | .highlight .ss { color: #990073 } /* Literal.String.Symbol */
56 | .highlight .bp { color: #999999 } /* Name.Builtin.Pseudo */
57 | .highlight .vc { color: #008080 } /* Name.Variable.Class */
58 | .highlight .vg { color: #008080 } /* Name.Variable.Global */
59 | .highlight .vi { color: #008080 } /* Name.Variable.Instance */
60 | .highlight .il { color: #009999 } /* Literal.Number.Integer.Long */
61 |
--------------------------------------------------------------------------------
/test_projects/mojombo/css/screen.css:
--------------------------------------------------------------------------------
1 | /*****************************************************************************/
2 | /*
3 | /* Common
4 | /*
5 | /*****************************************************************************/
6 |
7 | /* Global Reset */
8 |
9 | * {
10 | margin: 0;
11 | padding: 0;
12 | }
13 |
14 | html, body {
15 | height: 100%;
16 | }
17 |
18 | body {
19 | background-color: white;
20 | font: 13.34px helvetica, arial, clean, sans-serif;
21 | *font-size: small;
22 | text-align: center;
23 | }
24 |
25 | h1, h2, h3, h4, h5, h6 {
26 | font-size: 100%;
27 | }
28 |
29 | h1 {
30 | margin-bottom: 1em;
31 | }
32 |
33 | p {
34 | margin: 1em 0;
35 | }
36 |
37 | a {
38 | color: #00a;
39 | }
40 |
41 | a:hover {
42 | color: black;
43 | }
44 |
45 | a:visited {
46 | color: #a0a;
47 | }
48 |
49 | table {
50 | font-size: inherit;
51 | font: 100%;
52 | }
53 |
54 | /*****************************************************************************/
55 | /*
56 | /* Home
57 | /*
58 | /*****************************************************************************/
59 |
60 | ul.posts {
61 | list-style-type: none;
62 | margin-bottom: 2em;
63 | }
64 |
65 | ul.posts li {
66 | line-height: 1.75em;
67 | }
68 |
69 | ul.posts span {
70 | color: #aaa;
71 | font-family: Monaco, "Courier New", monospace;
72 | font-size: 80%;
73 | }
74 |
75 | /*****************************************************************************/
76 | /*
77 | /* Site
78 | /*
79 | /*****************************************************************************/
80 |
81 | .site {
82 | font-size: 110%;
83 | text-align: justify;
84 | width: 42em;
85 | margin: 3em auto 2em auto;
86 | line-height: 1.5em;
87 | }
88 |
89 | .title {
90 | color: #a00;
91 | font-weight: bold;
92 | margin-bottom: 2em;
93 | }
94 |
95 | .site .title a {
96 | color: #a00;
97 | text-decoration: none;
98 | }
99 |
100 | .site .title a:hover {
101 | color: black;
102 | }
103 |
104 | .site .title a.extra {
105 | color: #aaa;
106 | text-decoration: none;
107 | margin-left: 1em;
108 | }
109 |
110 | .site .title a.extra:hover {
111 | color: black;
112 | }
113 |
114 | .site .meta {
115 | color: #aaa;
116 | }
117 |
118 | .site .footer {
119 | font-size: 80%;
120 | color: #666;
121 | border-top: 4px solid #eee;
122 | margin-top: 2em;
123 | overflow: hidden;
124 | }
125 |
126 | .site .footer .contact {
127 | float: left;
128 | margin-right: 3em;
129 | }
130 |
131 | .site .footer .contact a {
132 | color: #8085C1;
133 | }
134 |
135 | .site .footer .rss {
136 | margin-top: 1.1em;
137 | margin-right: -.2em;
138 | float: right;
139 | }
140 |
141 | .site .footer .rss img {
142 | border: 0;
143 | }
144 |
145 | /*****************************************************************************/
146 | /*
147 | /* Posts
148 | /*
149 | /*****************************************************************************/
150 |
151 | #post {
152 |
153 | }
154 |
155 | /* standard */
156 |
157 | #post pre {
158 | border: 1px solid #ddd;
159 | background-color: #eef;
160 | padding: 0 .4em;
161 | }
162 |
163 | #post ul,
164 | #post ol {
165 | margin-left: 1.35em;
166 | }
167 |
168 | #post code {
169 | border: 1px solid #ddd;
170 | background-color: #eef;
171 | font-size: 85%;
172 | padding: 0 .2em;
173 | }
174 |
175 | #post pre code {
176 | border: none;
177 | }
178 |
179 | #post img {
180 | max-width: 42em;
181 | padding: 1em 0;
182 | }
183 |
184 | /* terminal */
185 |
186 | #post pre.terminal {
187 | border: 1px solid black;
188 | background-color: #333;
189 | color: white;
190 | }
191 |
192 | #post pre.terminal code {
193 | background-color: #333;
194 | }
195 |
196 | #related {
197 | margin-top: 2em;
198 | }
199 |
200 | #related h2 {
201 | margin-bottom: 1em;
202 | }
203 |
--------------------------------------------------------------------------------
/test_projects/mojombo/_expected/css/screen.css:
--------------------------------------------------------------------------------
1 | /*****************************************************************************/
2 | /*
3 | /* Common
4 | /*
5 | /*****************************************************************************/
6 |
7 | /* Global Reset */
8 |
9 | * {
10 | margin: 0;
11 | padding: 0;
12 | }
13 |
14 | html, body {
15 | height: 100%;
16 | }
17 |
18 | body {
19 | background-color: white;
20 | font: 13.34px helvetica, arial, clean, sans-serif;
21 | *font-size: small;
22 | text-align: center;
23 | }
24 |
25 | h1, h2, h3, h4, h5, h6 {
26 | font-size: 100%;
27 | }
28 |
29 | h1 {
30 | margin-bottom: 1em;
31 | }
32 |
33 | p {
34 | margin: 1em 0;
35 | }
36 |
37 | a {
38 | color: #00a;
39 | }
40 |
41 | a:hover {
42 | color: black;
43 | }
44 |
45 | a:visited {
46 | color: #a0a;
47 | }
48 |
49 | table {
50 | font-size: inherit;
51 | font: 100%;
52 | }
53 |
54 | /*****************************************************************************/
55 | /*
56 | /* Home
57 | /*
58 | /*****************************************************************************/
59 |
60 | ul.posts {
61 | list-style-type: none;
62 | margin-bottom: 2em;
63 | }
64 |
65 | ul.posts li {
66 | line-height: 1.75em;
67 | }
68 |
69 | ul.posts span {
70 | color: #aaa;
71 | font-family: Monaco, "Courier New", monospace;
72 | font-size: 80%;
73 | }
74 |
75 | /*****************************************************************************/
76 | /*
77 | /* Site
78 | /*
79 | /*****************************************************************************/
80 |
81 | .site {
82 | font-size: 110%;
83 | text-align: justify;
84 | width: 42em;
85 | margin: 3em auto 2em auto;
86 | line-height: 1.5em;
87 | }
88 |
89 | .title {
90 | color: #a00;
91 | font-weight: bold;
92 | margin-bottom: 2em;
93 | }
94 |
95 | .site .title a {
96 | color: #a00;
97 | text-decoration: none;
98 | }
99 |
100 | .site .title a:hover {
101 | color: black;
102 | }
103 |
104 | .site .title a.extra {
105 | color: #aaa;
106 | text-decoration: none;
107 | margin-left: 1em;
108 | }
109 |
110 | .site .title a.extra:hover {
111 | color: black;
112 | }
113 |
114 | .site .meta {
115 | color: #aaa;
116 | }
117 |
118 | .site .footer {
119 | font-size: 80%;
120 | color: #666;
121 | border-top: 4px solid #eee;
122 | margin-top: 2em;
123 | overflow: hidden;
124 | }
125 |
126 | .site .footer .contact {
127 | float: left;
128 | margin-right: 3em;
129 | }
130 |
131 | .site .footer .contact a {
132 | color: #8085C1;
133 | }
134 |
135 | .site .footer .rss {
136 | margin-top: 1.1em;
137 | margin-right: -.2em;
138 | float: right;
139 | }
140 |
141 | .site .footer .rss img {
142 | border: 0;
143 | }
144 |
145 | /*****************************************************************************/
146 | /*
147 | /* Posts
148 | /*
149 | /*****************************************************************************/
150 |
151 | #post {
152 |
153 | }
154 |
155 | /* standard */
156 |
157 | #post pre {
158 | border: 1px solid #ddd;
159 | background-color: #eef;
160 | padding: 0 .4em;
161 | }
162 |
163 | #post ul,
164 | #post ol {
165 | margin-left: 1.35em;
166 | }
167 |
168 | #post code {
169 | border: 1px solid #ddd;
170 | background-color: #eef;
171 | font-size: 85%;
172 | padding: 0 .2em;
173 | }
174 |
175 | #post pre code {
176 | border: none;
177 | }
178 |
179 | #post img {
180 | max-width: 42em;
181 | padding: 1em 0;
182 | }
183 |
184 | /* terminal */
185 |
186 | #post pre.terminal {
187 | border: 1px solid black;
188 | background-color: #333;
189 | color: white;
190 | }
191 |
192 | #post pre.terminal code {
193 | background-color: #333;
194 | }
195 |
196 | #related {
197 | margin-top: 2em;
198 | }
199 |
200 | #related h2 {
201 | margin-bottom: 1em;
202 | }
203 |
--------------------------------------------------------------------------------
/test_projects/mojombo/_posts/2010-12-11-designer-architect-developer.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: post
3 | title: Designer, Architect, Developer
4 | ---
5 |
6 | {{ page.title }}
7 | ================
8 |
9 |
10 |
11 | Over the last six years I’ve bootstrapped three successful enterprises (Cube6 Media, Gravatar, and GitHub) and failed to gain traction with a handful of others. After a lot of thought and reflections on these experiences, I’ve identified three major skills that should be present in order to best build a successful web application. These roles can be loosely defined as the Designer, the Architect, and the Developer.
12 |
13 | In college I spent a lot of time in the campus dark room dipping rolls of film and sheets of paper into various chemical baths beneath a dim red light. The most interesting part, though, was mounting the negative into the projector and exposing the photo paper. Every time I turned on the bright light of the projector I was reminded of a saying that has stuck with me ever since: “A photograph is nothing more than an image created by light.” Think about that for a second. The only way the photograph, and hence, the viewer, interact with the original subject is via the light that was captured. None of the fancy flashes, soft boxes, bounces, umbrellas, or backdrops mean a thing if the light they produce or redirect is in the wrong place. If the light is bad, the photograph is bad.
14 |
15 | I think the same concept holds true for web applications. Adapting the saying for our own situation, I would say: “A web application is nothing more than an experience created by design.” Users can’t see what technology you use or whether you follow an agile development process or not. All they experience is what’s on the screen. It can’t be confusing, it can’t look amateur, and it can’t have spelling errors. If the UX is bad, the web application is bad. It’s that simple.
16 |
17 | The way you get good UX is by having a good designer. Someone on the team must be skilled not only in making things pretty, but in making them usable as well. Without a good UX/visual design, you may as well not even bother. It’s impossible to stress how important this is.
18 |
19 | Design comes first. It defines what you will build. Once you have an idea of what you’re creating, you need to figure out how to make it happen. That’s where the Architect comes in.
20 |
21 | With the recent explosion of open source solutions to common problems like databases, web frameworks, job processors, messaging systems, etc, you need a team member that has a broad understanding of the technology landscape. The choices you make early on will impact your company for many years, and the wrong choices can spell disaster. The role of the Architect is to choose the best tools for the job, and to decide when new tools need to be created.
22 |
23 | The Architect must also be ready to scale any piece of the site when you start attracting users. There’s a fine line between premature optimization and crumbling under the wave of thousands of new signups. A good architect will always be one step ahead of the curve, laying the groundwork for future scaling needs just before they are needed.
24 |
25 | Design and architecture dictate what you build and how you build it, but without someone to do the construction, you’re dead in the water. The role of the Developer is to turn the wishes of the Designer into reality while staying within the constraints that the Architect has put forth. In addition, the Developer has to ensure that the codebase remains healthy and protect against technical debt. Sloppy development up front means a huge amount of wasted effort later on.
26 |
27 | The three roles of the Designer, the Architect, and the Developer may reside in a single person, but it’s much more common to see groups of two or three people satisfy all these skills. In fact, the best founding teams are those where everyone fills some combination of roles. This fosters an environment of friendly argument that leads to better decisions.
28 |
29 | But whatever you do, make sure your team fills all of these roles. Once you do, executing on your idea should come easily!
30 |
--------------------------------------------------------------------------------
/test_projects/mojombo/Gemfile.lock:
--------------------------------------------------------------------------------
1 | GEM
2 | remote: https://rubygems.org/
3 | specs:
4 | activesupport (4.2.7)
5 | i18n (~> 0.7)
6 | json (~> 1.7, >= 1.7.7)
7 | minitest (~> 5.1)
8 | thread_safe (~> 0.3, >= 0.3.4)
9 | tzinfo (~> 1.1)
10 | addressable (2.4.0)
11 | coffee-script (2.4.1)
12 | coffee-script-source
13 | execjs
14 | coffee-script-source (1.10.0)
15 | colorator (1.1.0)
16 | concurrent-ruby (1.1.10)
17 | ethon (0.9.1)
18 | ffi (>= 1.3.0)
19 | execjs (2.7.0)
20 | faraday (0.9.2)
21 | multipart-post (>= 1.2, < 3)
22 | ffi (1.9.14)
23 | forwardable-extended (2.6.0)
24 | gemoji (2.1.0)
25 | github-pages (102)
26 | activesupport (= 4.2.7)
27 | github-pages-health-check (= 1.2.0)
28 | jekyll (= 3.3.0)
29 | jekyll-coffeescript (= 1.0.1)
30 | jekyll-feed (= 0.7.2)
31 | jekyll-gist (= 1.4.0)
32 | jekyll-github-metadata (= 2.2.0)
33 | jekyll-mentions (= 1.2.0)
34 | jekyll-paginate (= 1.1.0)
35 | jekyll-redirect-from (= 0.11.0)
36 | jekyll-sass-converter (= 1.3.0)
37 | jekyll-seo-tag (= 2.0.0)
38 | jekyll-sitemap (= 0.11.0)
39 | jekyll-swiss (= 0.4.0)
40 | jemoji (= 0.7.0)
41 | kramdown (= 1.11.1)
42 | liquid (= 3.0.6)
43 | listen (= 3.0.6)
44 | mercenary (~> 0.3)
45 | minima (= 2.0.0)
46 | rouge (= 1.11.1)
47 | terminal-table (~> 1.4)
48 | github-pages-health-check (1.2.0)
49 | addressable (~> 2.3)
50 | net-dns (~> 0.8)
51 | octokit (~> 4.0)
52 | public_suffix (~> 1.4)
53 | typhoeus (~> 0.7)
54 | html-pipeline (2.4.2)
55 | activesupport (>= 2)
56 | nokogiri (>= 1.4)
57 | i18n (0.9.5)
58 | concurrent-ruby (~> 1.0)
59 | jekyll (3.3.0)
60 | addressable (~> 2.4)
61 | colorator (~> 1.0)
62 | jekyll-sass-converter (~> 1.0)
63 | jekyll-watch (~> 1.1)
64 | kramdown (~> 1.3)
65 | liquid (~> 3.0)
66 | mercenary (~> 0.3.3)
67 | pathutil (~> 0.9)
68 | rouge (~> 1.7)
69 | safe_yaml (~> 1.0)
70 | jekyll-coffeescript (1.0.1)
71 | coffee-script (~> 2.2)
72 | jekyll-feed (0.7.2)
73 | jekyll-gist (1.4.0)
74 | octokit (~> 4.2)
75 | jekyll-github-metadata (2.2.0)
76 | jekyll (~> 3.1)
77 | octokit (~> 4.0, != 4.4.0)
78 | jekyll-mentions (1.2.0)
79 | activesupport (~> 4.0)
80 | html-pipeline (~> 2.3)
81 | jekyll (~> 3.0)
82 | jekyll-paginate (1.1.0)
83 | jekyll-redirect-from (0.11.0)
84 | jekyll (>= 2.0)
85 | jekyll-sass-converter (1.3.0)
86 | sass (~> 3.2)
87 | jekyll-seo-tag (2.0.0)
88 | jekyll (~> 3.1)
89 | jekyll-sitemap (0.11.0)
90 | addressable (~> 2.4.0)
91 | jekyll-swiss (0.4.0)
92 | jekyll-watch (1.5.0)
93 | listen (~> 3.0, < 3.1)
94 | jemoji (0.7.0)
95 | activesupport (~> 4.0)
96 | gemoji (~> 2.0)
97 | html-pipeline (~> 2.2)
98 | jekyll (>= 3.0)
99 | json (1.8.3)
100 | kramdown (1.11.1)
101 | liquid (3.0.6)
102 | listen (3.0.6)
103 | rb-fsevent (>= 0.9.3)
104 | rb-inotify (>= 0.9.7)
105 | mercenary (0.3.6)
106 | mini_portile2 (2.8.5)
107 | minima (2.0.0)
108 | minitest (5.9.1)
109 | multipart-post (2.0.0)
110 | net-dns (0.8.0)
111 | nokogiri (1.16.2)
112 | mini_portile2 (~> 2.8.2)
113 | racc (~> 1.4)
114 | octokit (4.6.0)
115 | sawyer (~> 0.8.0, >= 0.5.3)
116 | pathutil (0.14.0)
117 | forwardable-extended (~> 2.6)
118 | public_suffix (1.5.3)
119 | racc (1.7.3)
120 | rb-fsevent (0.9.8)
121 | rb-inotify (0.9.7)
122 | ffi (>= 0.5.0)
123 | rouge (1.11.1)
124 | safe_yaml (1.0.4)
125 | sass (3.4.22)
126 | sawyer (0.8.0)
127 | addressable (>= 2.3.5, < 2.6)
128 | faraday (~> 0.8, < 0.10)
129 | terminal-table (1.7.3)
130 | unicode-display_width (~> 1.1.1)
131 | thread_safe (0.3.6)
132 | typhoeus (0.8.0)
133 | ethon (>= 0.8.0)
134 | tzinfo (1.2.10)
135 | thread_safe (~> 0.1)
136 | unicode-display_width (1.1.1)
137 |
138 | PLATFORMS
139 | ruby
140 |
141 | DEPENDENCIES
142 | github-pages
143 |
144 | BUNDLED WITH
145 | 1.10.6
146 |
--------------------------------------------------------------------------------
/test_projects/mojombo/_posts/2008-11-03-how-to-meet-your-next-cofounder.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: post
3 | title: How to Meet Your Next Cofounder
4 | ---
5 |
6 | {{ page.title }}
7 | ================
8 |
9 |
10 |
11 | Over the last few months I've seen a number of people looking for cofounders on
12 | Hacker News or via their own personal blogs. I think this is, at best, a highly
13 | inefficient way to find a cofounder and, at worst, a way to fool yourself into
14 | finding the *wrong* cofounder. In any case, it's a naive approach to finding the
15 | person that will need to stand by your side in the coming storm that we call
16 | "running a startup."
17 |
18 | Don't get me wrong, the internet is an amazing tool for meeting people. The
19 | wider the net you cast, the more likely you are to find the perfect match. But
20 | the internet has its limitations. I've had internet friends that were engaging,
21 | witty, and brilliant online, but in person felt awkward and boring. Conversely,
22 | I know people that are volatile and inflammatory online, but present an attitude
23 | of friendliness and caring in person. This phenomenon makes it difficult to
24 | gauge an individual's personality from online interaction alone.
25 |
26 | A far better use of the internet is to find groups of people that share your
27 | interests. Track down the local users group for your language or technology of
28 | choice. The simple fact that members of these groups take time out of their day
29 | to show up means that they're more motivated and driven than the average person.
30 | Even if it's a bit of a commute to get to the meetings, start showing up
31 | regularly. Prepare a few presentations on topics that you're passionate about.
32 | Bonus points if you present on ideas related to your potential startup. Don't
33 | worry about revealing your game-changing secrets; stealth mode is bullshit. Talk
34 | to everyone. Steer the conversation toward your interests and if someone there
35 | is excited about the same things, it will be clear.
36 |
37 | It may take weeks or months, but in a good group you'll find a handful of people
38 | that you really like. If at all possible, go out drinking with these people
39 | after the meetups. This is one of the easiest ways to go from "acquaintance" to
40 | "friend" and gives you free license to bring up your craziest of ideas without
41 | sounding like too much of a nutjob.
42 |
43 | Of the people that you like, several may make excellent candidates for
44 | cofounders. Do a little research on these individuals. What does their code look
45 | like? Have they done much open source? Do they demonstrate an entrepreneurial
46 | spirit? Can they stick with a single project for a long time? Have they been
47 | loyal to their friends and companies in the past? A good cofounder should be
48 | someone with whom you feel privileged to work. And they should feel privileged
49 | to work with you. The two of you should be on very solid ground before you begin
50 | your startup adventure, because once you do, the impact of every argument is
51 | going to feel like it's been multiplied by a thousand.
52 |
53 | This all sounds like a lot of hard work. Maybe you're wondering if it would be
54 | better to just go solo. I did that with Gravatar, and, in retrospect, it's
55 | painfully obvious that I made a lot of stupid mistakes. When it's just you and
56 | your thoughts it becomes too easy to pick the first thing that pops into your
57 | head. We're programmed to think all of our ideas are good, but reality tells a
58 | different story. Truly good decisions are forged from the furnace of argument,
59 | not plucked like daisies from the pasture of a peaceful mind. A good cofounder
60 | tells you when your ideas are half-baked and ensures that your good ideas
61 | actually get implemented.
62 |
63 | The second biggest danger with going solo is the loss of motivation. Solipsism
64 | might make you feel important at first, but the constant lack of feedback and
65 | the absence of support during tough times can easily lead to a premature end to
66 | your adventure. Cofounders are like workout buddies. Just when you think there's
67 | no possible way you can do another rep, there they are, rooting you on toward an
68 | achievement that wouldn't be possible without them.
69 |
70 | Your choice of cofounder will affect everything you do in your startup. They'll
71 | share every defeat with you and celebrate every success. They'll help you
72 | understand your own ideas better by offering a different perspective. They'll be
73 | the single most important decision you make during the tenure of your startup,
74 | so choose wisely and with extreme care.
75 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # jekyll-build-pages
2 |
3 | A simple GitHub Action for producing Jekyll build artifacts compatible with GitHub Pages.
4 |
5 | ## Scope
6 |
7 | This is used along with [`actions/deploy-pages`](https://github.com/actions/deploy-pages) as part of the official support for building Pages with Actions (currently in public beta for public repositories).
8 |
9 | ## Usage
10 |
11 | A basic Pages deployment workflow with the `jekyll-build-pages` action looks like this.
12 |
13 | ```yaml
14 | name: Build Jekyll site
15 | on:
16 | push:
17 | branches: ["main"]
18 | permissions:
19 | contents: read
20 | pages: write
21 | id-token: write
22 | jobs:
23 | build:
24 | runs-on: ubuntu-latest
25 | steps:
26 | - name: Checkout
27 | uses: actions/checkout@v4
28 | - name: Setup Pages
29 | uses: actions/configure-pages@v5
30 | - name: Build
31 | uses: actions/jekyll-build-pages@v1
32 | - name: Upload artifact
33 | uses: actions/upload-pages-artifact@v3
34 | deploy:
35 | runs-on: ubuntu-latest
36 | needs: build
37 | steps:
38 | - name: Deploy to GitHub Pages
39 | id: deployment
40 | uses: actions/deploy-pages@v4
41 | environment:
42 | name: github-pages
43 | url: ${{ steps.deployment.outputs.page_url }}
44 | ```
45 |
46 | To write to a different destination directory, match the inputs of both the `jekyll-build-pages` and [`upload-pages-artifact`](https://github.com/actions/upload-pages-artifact) actions.
47 |
48 | ```yaml
49 | steps:
50 | - name: Build
51 | uses: actions/jekyll-build-pages@v1
52 | with:
53 | destination: "./output"
54 | - name: Upload artifact
55 | uses: actions/upload-pages-artifact@v3
56 | with:
57 | path: "./output"
58 | ```
59 |
60 | ### Action inputs
61 |
62 | | Input | Default | Description |
63 | |-------|---------|-------------|
64 | | `source` | `./` | The directory to build from |
65 | | `destination` | `./_site` | The directory to write output into(this should match the `path` input of the [`actions/upload-pages-artifact`](https://github.com/actions/upload-pages-artifact) action) | 66 | | `future` | `false` | If `true`, writes content dated in the future | 67 | | `build_revision` | `$GITHUB_SHA` | The SHA-1 of the Git commit for which the build is running | 68 | | `verbose` | `false` | If `true`, prints verbose output in logs | 69 | | `token` | `$GITHUB_TOKEN` | The GitHub token used to authenticate API requests | 70 | 71 | ## Release instructions 72 | 73 | In order to release a new version of this Action: 74 | 75 | 1. Locate the semantic version of the [upcoming release][release-list] (a draft is maintained by the [`draft-release` workflow][draft-release]). 76 | 77 | 2. Prepare a pull request to update [`action.yml`][action.yml] to reference the incoming version, get it approved, and merge it into the `main` branch. 78 | 79 | 3. Publish the draft release **as a pre-release** from the `main` branch with semantic version as the tag name, _with_: 80 | - the checkbox to publish to the GitHub Marketplace checked :ballot_box_with_check: 81 | - :warning: _AND_ the checkbox to **Set as a pre-release** checked. :ballot_box_with_check: 82 | 83 | 4. This will kick off a [Docker publishing workflow][docker-publish] for the newly created tag. Check the [associated workflow run list][docker-publish-workflow-runs] to verify the new Docker image is created successfully before moving on to the next step. 84 | 85 | 5. After the Docker image has been created with the new tag, find that [same pre-release][release-list] and edit it. Update it with the checkbox to **Set as the latest release** checked :ballot_box_with_check: and then publish it again. 86 | 87 | 6. After publishing it as the latest release, the [`release` workflow][release] will automatically run to create/update the corresponding the major version tag such as `v1`. 88 | 89 | ⚠️ Environment approval is required. Check the [Release workflow run list][release-workflow-runs]. 90 | 91 | ## License 92 | 93 | The scripts and documentation in this project are released under the [MIT License](LICENSE). 94 | 95 | 96 | [release-list]: https://github.com/actions/jekyll-build-pages/releases 97 | [draft-release]: .github/workflows/draft-release.yml 98 | [docker-publish]: .github/workflows/docker-publish.yml 99 | [release]: .github/workflows/release.yml 100 | [docker-publish-workflow-runs]: https://github.com/actions/jekyll-build-pages/actions/workflows/docker-publish.yml 101 | [release-workflow-runs]: https://github.com/actions/jekyll-build-pages/actions/workflows/release.yml 102 | [action.yml]: https://github.com/actions/jekyll-build-pages/blob/649f5d3c2b2462620c8945f034200e431ceddd29/action.yml#LL31C54-L31C60 103 | -------------------------------------------------------------------------------- /test_projects/mojombo/_posts/2010-08-23-readme-driven-development.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: Readme Driven Development 4 | --- 5 | 6 | {{ page.title }} 7 | ================ 8 | 9 | 10 | 11 | I hear a lot of talk these days about TDD and BDD and Extreme Programming and SCRUM and stand up meetings and all kinds of methodologies and techniques for developing better software, but it's all irrelevant unless the software we're building meets the needs of those that are using it. Let me put that another way. A perfect implementation of the wrong specification is worthless. By the same principle a beautifully crafted library with no documentation is also damn near worthless. If your software solves the wrong problem or nobody can figure out how to use it, there's something very bad going on. 12 | 13 | Fine. So how do we solve this problem? It's easier than you think, and it's important enough to warrant its very own paragraph. 14 | 15 | Write your Readme first. 16 | 17 | First. As in, before you write any code or tests or behaviors or stories or ANYTHING. I know, I know, we're programmers, dammit, not tech writers! But that's where you're wrong. Writing a Readme is absolutely essential to writing good software. Until you've written about your software, you have no idea what you'll be coding. Between The Great Backlash Against Waterfall Design and The Supreme Acceptance of Agile Development, something was lost. Don't get me wrong, waterfall design takes things way too far. Huge systems specified in minute detail end up being the WRONG systems specified in minute detail. We were right to strike it down. But what took its place is too far in the other direction. Now we have projects with short, badly written, or entirely missing documentation. Some projects don't even have a Readme! 18 | 19 | This is not acceptable. There must be some middle ground between reams of technical specifications and no specifications at all. And in fact there is. That middle ground is the humble Readme. 20 | 21 | It's important to distinguish Readme Driven Development from Documentation Driven Development. RDD could be considered a subset or limited version of DDD. By restricting your design documentation to a single file that is intended to be read as an introduction to your software, RDD keeps you safe from DDD-turned-waterfall syndrome by punishing you for lengthy or overprecise specification. At the same time, it rewards you for keeping libraries small and modularized. These simple reinforcements go a long way towards driving your project in the right direction without a lot of process to ensure you do the right thing. 22 | 23 | By writing your Readme first you give yourself some pretty significant advantages: 24 | 25 | * Most importantly, you're giving yourself a chance to think through the project without the overhead of having to change code every time you change your mind about how something should be organized or what should be included in the Public API. Remember that feeling when you first started writing automated code tests and realized that you caught all kinds of errors that would have otherwise snuck into your codebase? That's the exact same feeling you'll have if you write the Readme for your project before you write the actual code. 26 | 27 | * As a byproduct of writing a Readme in order to know what you need to implement, you'll have a very nice piece of documentation sitting in front of you. You'll also find that it's much easier to write this document at the beginning of the project when your excitement and motivation are at their highest. Retroactively writing a Readme is an absolute drag, and you're sure to miss all kinds of important details when you do so. 28 | 29 | * If you're working with a team of developers you get even more mileage out of your Readme. If everyone else on the team has access to this information before you've completed the project, then they can confidently start work on other projects that will interface with your code. Without any sort of defined interface, you have to code in serial or face reimplementing large portions of code. 30 | 31 | * It's a lot simpler to have a discussion based on something written down. It's easy to talk endlessly and in circles about a problem if nothing is ever put to text. The simple act of writing down a proposed solution means everyone has a concrete idea that can be argued about and iterated upon. 32 | 33 | Consider the process of writing the Readme for your project as the true act of creation. This is where all your brilliant ideas should be expressed. This document should stand on its own as a testament to your creativity and expressiveness. The Readme should be the single most important document in your codebase; writing it first is the proper thing to do. 34 | 35 | -- 36 | 37 | [Discuss this post on Hacker News](http://news.ycombinator.com/item?id=1627246) -------------------------------------------------------------------------------- /test_projects/mojombo/_posts/2014-04-21-farewell-github-hello-immersive-computing.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: Farewell GitHub, Hello Immersive Computing 4 | --- 5 | 6 | {{ page.title }} 7 | ================ 8 | 9 | 10 | 11 | Today is my last day at GitHub. Recent events have given me a lot of time to 12 | reflect on what's important to me, and I've decided to switch gears and focus on 13 | building something from scratch again. Since visiting the Oculus VR team at 14 | their office three months ago, I've come to believe that immersive computing 15 | (aka virtual reality) is poised to rival the personal computer, the web, social 16 | networking, and mobile devices in its impact. While the timing is more abrupt 17 | than I had intended, with everything that's happened, I think now is the right 18 | time to do this, and I'd like to explain why. 19 | 20 | First, I want to address the serious accusations that were made against me and 21 | my family over the past month. With every decision I made at GitHub and in every 22 | interaction I had with employees, I tried to treat people better than they 23 | expected and to resolve conflict with empathy. Despite that, I've made mistakes, 24 | and I am deeply sorry to anyone who was hurt by those mistakes. It devastates me 25 | to know that I missed the mark, and I will strive to do better, every day. 26 | 27 | That said, I want to be very clear about one thing: neither my wife, Theresa, 28 | nor I have ever engaged in gender-based harassment or discrimination. The 29 | results of GitHub's independent investigation unequivocally confirm this and we 30 | are prepared to fight any further false claims on this matter to the full extent 31 | of the law. I believe in diversity and equality for all people in all 32 | professions, especially the tech sector. It's immensely important to me and I 33 | will continue to do my very best to further that belief. 34 | 35 | Unfortunately, the investigation and all the attention surrounding it have me 36 | concerned that remaining at GitHub would be a distraction for both me and the 37 | company. I'm incredibly proud of what I've helped build at GitHub and I don't 38 | want the events of the past month to jeopardize that. I care too much about the 39 | company and the people here to let that happen. The GitHub team is incredibly 40 | strong, with fierce vision, and I have no doubt they will continue to 41 | revolutionize software development for decades to come. Founding and building 42 | GitHub has been the greatest adventure of my life. I've been so lucky to be on 43 | this journey with such amazing, helpful, talented, and real people. I'm going to 44 | miss working with such a great team, but I'm also insanely excited about the 45 | future. 46 | 47 | Since the early days of GitHub, I've wanted to create a different kind of 48 | business. One that was [Optimized for 49 | Happiness](http://tom.preston-werner.com/2010/10/18/optimize-for-happiness.html) 50 | and built atop a [Framework of 51 | Happiness](https://www.youtube.com/watch?v=i0FzgvYxdvk). One where great people 52 | could work on hard problems together to create unbelievably good products. I 53 | believe I was able to achieve a great deal of success with that model at GitHub, 54 | even if things didn't always go perfectly according to plan. All of this has 55 | been a tremendous learning experience for me. 56 | 57 | Last January I stepped down as CEO and handed that role over to cofounder Chris 58 | Wanstrath so I could focus on future-facing R&D projects with small teams. This 59 | kind of rapid, team-based innovation is what I live for. During my time away 60 | from GitHub I started experimenting with Go, OpenGL, and Unity with an eye 61 | towards the software side of immersive computing. It felt really good to get 62 | back into a code editor and challenge the deeply logical and analytical part of 63 | my brain. I've enjoyed the challenges of learning how to lead a company with 64 | hundreds of people, but it's very hard for me to deny the allure of coding a 65 | system that could once again change the course of history. 66 | 67 | I'm telling you this because I think stealth mode is bullshit and if you feel 68 | the same way I do about immersive computing then I want to talk with you about 69 | it. For the next few months I'm going to be living in Manhattan. My wife, 70 | Theresa, is currently participating in Techstars NYC as their very first 71 | nonprofit. Her startup, [The Omakase Charity](https://omakasecharity.org/), 72 | helps donors learn about and support nonprofits that are changing the world with 73 | technology. She's one of the strongest and most thoughtful women I know, and I'm 74 | hoping to help her succeed with her mission while I'm here. 75 | 76 | Thank you to everyone that reached out to me over the last month, including the 77 | generous team at Andreessen Horowitz. Your support has made a huge difference 78 | and I'm truly excited for what's next. 79 | -------------------------------------------------------------------------------- /test_projects/mojombo/_posts/2010-05-11-tomdoc-reasonable-ruby-documentation.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: TomDoc - Reasonable Ruby Documentation 4 | --- 5 | 6 | {{ page.title }} 7 | ================ 8 | 9 | 10 | 11 | [RDoc](http://rdoc.rubyforge.org) is an abomination. It's ugly to read in plain 12 | text, requires the use of the inane :nodoc: tag to prevent private method 13 | documentation from showing up in final rendering, and does nothing to encourage 14 | complete or unambiguous documentation of classes, methods, or parameters. 15 | [YARD](http://yardoc.org) is much better but goes too far in the other direction 16 | (and still doesn't look good in plain text). Providing an explicit way to 17 | specify parameters and types is great, but having to remember a bunch of strict 18 | tag names in order to be compliant is not a good way to encourage coders to 19 | write documentation. And again we see a `@private` tag that's necessary to hide 20 | docs from the final render. 21 | 22 | Three years ago, after suffering with these existing documentation formats for 23 | far too long, I started using my own documentation format. It looked a bit like 24 | RDoc but had a set of conventions for specifying parameters, return values, and 25 | the expected types. It used plain language and full sentences so that a human 26 | could read and understand it without having to parse machine-oriented tags or 27 | crufty markup. I called this format TomDoc, because if Linus can name stuff 28 | after himself, then why can't I? 29 | 30 | After years in the making, TomDoc is finally a well specified documentation 31 | format. You can find the full spec at [http://tomdoc.org](http://tomdoc.org). 32 | 33 | But enough talk. Here's a sample of what a TomDoc'd method might look like: 34 | 35 | ``` ruby 36 | # Public: Duplicate some text an abitrary number of times. 37 | # 38 | # text - The String to be duplicated. 39 | # count - The Integer number of times to duplicate the text. 40 | # 41 | # Examples 42 | # 43 | # multiplex('Tom', 4) 44 | # # => 'TomTomTomTom' 45 | # 46 | # Returns the duplicated String. 47 | def multiplex(text, count) 48 | text * count 49 | end 50 | ``` 51 | 52 | At first glance you'll notice a few things. First, and most important, is that 53 | the documentation looks nice in plain text. When I'm working on a project, I 54 | need to be able to scan and read method documentation quickly. Littering the 55 | docs with tags and markup (especially HTML markup) is not acceptable. Code 56 | documentation should be optimized for human consumption. Second, all parameters 57 | and return values, and their expected types are specified. Types are generally 58 | denoted by class name. Because Ruby is so flexible, you are not constrained by a 59 | rigid type declaration syntax and are free to explain precisely how the expected 60 | types may vary under different circumstances. Finally, the basic layout is 61 | designed to be easy to remember. Once you commit a few simple conventions to 62 | memory, writing documentation becomes second nature, with all of the tricky 63 | decision making already done for you. 64 | 65 | Today's Ruby libraries suffer deeply from haphazard versioning schemes. Even 66 | RubyGems itself does not follow a sane or predictable versioning pattern. This 67 | lack of discipline stems from the absence of well defined Public APIs. TomDoc 68 | attempts to solve this problem by making it simple to define an unambiguous 69 | Public API for your library. Instead of assuming that all classes and methods 70 | are intended for public consumption, TomDoc makes the Public API opt-in. To 71 | denote that something is public, all you have to do is preface the main 72 | description with "Public:". By forcing you to explicitly state that a class or 73 | method is intended for public consumption, a deliberate and thoughtful Public 74 | API is automatically constructed that can inform disciplined version changes 75 | according to the tenets of [Semantic Versioning](http://semver.org). In 76 | addition, the prominent display of "Public" in a method description ensures that 77 | developers are made aware of the sensitive nature of the method and do not 78 | carelessly change the signature of something in the Public API. 79 | 80 | Once a Public API has been established, some very exciting things become 81 | possible. We're currently working on a processing tool that will render TomDoc 82 | into various forms (terminal, HTML, etc). If you run this tool on a library, 83 | you'll get a printout of the Public API documentation. You can publish this 84 | online so that others have easy access to it. When you roll a new version of the 85 | library, you can run the tool again, giving it a prior version as a base, and 86 | have it automatically display only the methods that have changed. This diff will 87 | be extremely useful for users while they upgrade to the new version (or so they 88 | can evaluate whether an upgrade is warranted)! 89 | 90 | While I've been using various nascent forms of TomDoc for several years, we're 91 | just now starting to adopt it for everything we do at GitHub. Now that I've 92 | formalized the spec it will be easy for the entire team to write compliant 93 | TomDoc. The goal is to have every class, method, and accessor of every GitHub 94 | library documented. In the future, once we have proper tooling, we'd even like 95 | to create a unit test that will fail if anything is missing documentation. 96 | 97 | TomDoc is still a rough specification so I'm initially releasing it as 0.9.0. 98 | Over the coming months I'll make any necessary changes to address user concerns 99 | and release a 1.0.0 version once things have stabilized. If you'd like to 100 | suggest changes, please open an issue on the [TomDoc GitHub 101 | repository](http://github.com/mojombo/tomdoc). 102 | -------------------------------------------------------------------------------- /test_projects/mojombo/_posts/2016-11-10-snyk.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: Snyk - Automatically Scan and Fix Ruby and Nodejs Vulnerabilities 4 | --- 5 | 6 | {{ page.title }} 7 | ================ 8 | 9 | 10 | 11 | This is a story about a company called 12 | [Snyk](https://snyk.io/blog/welcome-ruby-users/) (pronounced "sneak"), their 13 | founder Guy Podjarny, my decision to become one of their advisors, and how they 14 | are going to help save you from malevolent agents trying to steal your digital 15 | stuff. 16 | 17 | If you're anything like me, you're simultaneously terrified and in awe of the 18 | increasing commonality of large corporate security breaches. Even big names like 19 | Ebay, Home Depot, Anthem, JP Morgan Chase, Target, LinkedIn, Dropbox, and Yahoo 20 | are falling victim to sophisticated attacks. If you spend even a few minutes 21 | looking into it, you'll be shocked at how frequently these breaches are 22 | happening now. The fine folks at Information is Beautiful have an excellent 23 | interactive visualization of the [World's Biggest Data 24 | Breaches](http://www.informationisbeautiful.net/visualizations/worlds-biggest-data-breaches-hacks/) 25 | over the last twelve years, in case you want to read all the gory details and 26 | never get a restful night of sleep ever again: 27 | 28 | 29 |
30 |
31 |
32 | I've used a fair number of emotionally charged words above that might be
33 | triggering your FUD detectors right about now. But be advised: it's not paranoia
34 | when they really are out to get you. If recent, extremely high profile (and
35 | subsequently weaponized) breaches like those of the Clinton Campaign and the DNC
36 | aren't enough to make you want to air gap your entire life, then I envy your
37 | steely-eyed mettle and implore you to teach me your meditation techniques.
38 |
39 | The fact is, security is hard. And it's getting harder every day. To win, you
40 | have to get it right every single time. To lose (and lose big), you only have to
41 | screw it up once.
42 |
43 | During my years at GitHub, I spent a lot of time assembling a dedicated security
44 | team, managing security audits and penetration tests, and working to establish a
45 | culture of security awareness amongst our development team. All of this is
46 | challenging and expensive, especially for a young company. Even worse, it's the
47 | kind of investment that's totally invisible when it's working, making it hard to
48 | sustain until that crucial and terrible moment you end up on the front page of
49 | Hacker News as the latest victim.
50 |
51 | A year ago I was contemplating this, especially the difficult proposition of
52 | having developers, furious at work on new features, constantly maintain
53 | awareness of security vulnerabilities they might be inadvertently weaving into
54 | the product. Web application developers are generally not security experts, and
55 | though I would love to live in a world where that wasn't true, it's just not a
56 | realistic expectation. Meanwhile, modern development means an increasing
57 | reliance on 3rd party code. Even a small Rails app will probably have 300 or
58 | more gem dependencies after a few months of development. It's even more in the
59 | nodejs world. This level of modularization and code reuse, driven by the
60 | explosion of high quality open source over the last decade, is amazing and I
61 | absolutely love it, but it comes at a security expense.
62 |
63 | Open source projects are not known for their excellent security records.
64 | Vulnerabilities like [Heartbleed](http://heartbleed.com/) and
65 | [Shellshock](https://blog.cloudflare.com/inside-shellshock/) painfully
66 | demonstrate the idea that "given enough eyeballs, all bugs are shallow" is
67 | completely false. In fact, due to a flaw in YAML, Rails had a [pretty extreme
68 | remote code execution
69 | vulnerability](http://blog.codeclimate.com/blog/2013/01/10/rails-remote-code-execution-vulnerability-explained/)
70 | for years. If you were running any version of Rails prior to the fix, you were
71 | vulnerable. This stuff is real, and as responsible developers, we need to be
72 | more proactive about it.
73 |
74 | Luckily, at the time I was pondering these matters, I ran into Guy Podjarny. As
75 | a former cofounder of Blaze.io and then CTO of Web Experience at Akamai (which
76 | acquired Blaze.io), Guy intimately understands the impact of security on today's
77 | web developers. He was working on an automated tool to scan and fix security
78 | vulnerabilities in 3rd party dependencies. I was intrigued. They already had a
79 | way to scan nodejs projects and look for known security vulnerabilities in the
80 | dependency tree and automatically upgrade or patch affected libraries. I thought
81 | this was pretty cool, but it was his vision for what automated security tooling
82 | could be that sold me on him and his company. I can't talk much about that
83 | now, but just know that what Snyk is today is just the tip of what will
84 | become an intelligent and proactive bodyguard for your entire codebase.
85 |
86 | A few months ago, Snyk released GitHub integration to make it fantastically
87 | simple to hook up your repos to Snyk and, my favorite feature: the ability to
88 | monitor your repo for future vulnerabilities and then **automatically submit a
89 | pull request** with the suggested package upgrade or hotfix patch (nodejs only for
90 | now).
91 |
92 | Today, [Snyk announced support for
93 | Ruby](https://snyk.io/blog/welcome-ruby-users/). Take a look at that blog post,
94 | it does an awesome job of explaining how simple it is to set up and what the
95 | generated pull requests look like. It's totally free for open source projects,
96 | and extremely cheap insurance for your important projects.
97 |
98 | Make no mistake, 3rd party code is a clear and present danger to your business.
99 | If you don't know if you're vulnerable, then you must assume that you are and
100 | take steps to protect yourself. Snyk makes it easy.
101 |
--------------------------------------------------------------------------------
/test_projects/mojombo/_posts/2011-05-03-rejected-bio-from-the-setup.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: post
3 | title: Rejected Bio from The Setup
4 | ---
5 |
6 | {{ page.title }}
7 | ================
8 |
9 |
10 |
11 | Yesterday, [the autobiographical post I wrote for The
12 | Setup](http://tom.preston-werner.usesthis.com/) went live. I wrote that post
13 | over a year ago and then entered into an epic battle with
14 | [@waferbaby](http://twitter.com/#!/waferbaby) about the length of my "Who are
15 | you, and what do you do?" section. He said it was too long. I said it could
16 | not be shortened. And so the post sat for a year, collecting dust, neither of
17 | us prepared to back down.
18 |
19 | About a month ago I decided that it was foolish to let the words I had written rot on my hard drive and so I did the only thing I knew how to do: overreact. So I cut the original nine-hundred words of my bio down to fourteen words and resubmitted it to Daniel. Those are the words you see in the post now.
20 |
21 | For your pleasure, here is the original bio in its full, unabridged glory.
22 |
23 | 24 | 25 | My name is Tom Preston-Werner. I find that the hyphenated last name 26 | makes me sound distinguished and worth listening to. I grew up three 27 | decades ago in a small city in Iowa along the Mississippi, which means 28 | I shucked a lot of corn and know exactly how many mosquitos will land 29 | on your arm should you hold it still for ten minutes at dusk on the 30 | muggiest day of the summer. As an aspiring theoretical particle 31 | physicist, I worked my way through entire shelves of scientific 32 | literature from the public library, desperately wanting to understand 33 | the bewildering mathematics that littered the pages like so many 34 | leaves on the bottom of that morning's cup of green tea. I searched in 35 | vain for instructors or classmates that could provide me with the 36 | insight necessary to comprehend the true meaning of Heisenberg's 37 | Uncertainty Principle, but all I found were underpaid math teachers 38 | and disillusioned "students" in search of their next smoke break. 39 | After obsessing over US News' Best Colleges reports for months I 40 | finally chose and was accepted to Harvey Mudd, a tiny engineering 41 | school in California famous for assigning the greatest number of hours 42 | of homework per night. This sounded just perfect to me. Finally a 43 | place I could bring up the EPR Paradox and not be immediately 44 | stigmatized as "that science weirdo with the hilariously thick glasses 45 | and unfortunate hairdo." 46 | 47 | Mudd did not disappoint. But now I had the opposite problem. In order 48 | to properly understand particle physics, you must have a deep and 49 | profound love of math. You have to be so comfortable with abstract 50 | concepts that even Picasso would be jealous. Ironically, in order to 51 | grasp the fundamental reality of our universe, you must forget about 52 | the "reality" of everyday life and start living in a world comprised 53 | of eigenvectors, Hilbert spaces, and Planck's constant. This was a 54 | leap I could not make. I like math, but I'm too easily distracted by 55 | macroscopic reality to make it my profession. 56 | 57 | Once I accepted that I would never spend late nights poring over 58 | bubble chamber printouts at Fermilab, it became obvious that I was 59 | destined to enter computer science. I started programming in BASIC on 60 | a TRS-80 that my dad bought from Radio Shack when I was 8 years old. 61 | Since then, I'd learned to love the discipline and creativity involved 62 | in making a machine do my bidding. It was like having a super-obedient 63 | but annoyingly logical little brother. He'll do anything you want as 64 | long as you tell him in precise and unambiguous language. The best 65 | thing is, the feedback is immediate. In physics, it can take twenty 66 | years to prove that a single esoteric particle even exists. When 67 | you're writing a program that displays the number of electrons in each 68 | of the shells around the nucleus of every element, the feedback is 69 | immediate and intoxicating. With just a few keystrokes, the world is 70 | changed forever. Try to get that kind of rush even once in a lifetime 71 | as a theoretical particle physicist. I dare you. 72 | 73 | In 1999, after two years of college, I dropped out of Harvey Mudd to 74 | join a startup with some friends that were graduating. It was the end 75 | of the first dot-com bubble and I thought I could strike it rich, 76 | right then and there. Sadly, like so many startups of the day, we 77 | never accomplished what we envisioned and I ended up bouncing between 78 | jobs and consulting gigs for six years until I found myself in San 79 | Francisco. If Harvey Mudd was my mecca for physicists, then San 80 | Francisco was my mecca for programmers. Where else can you be grabbing 81 | lunch at a taqueria and overhear a group at the next table discussing 82 | the finer points of optimizing C code to run on an embedded processor? 83 | 84 | I moved to San Francisco to take a job as a Ruby developer with a 85 | Wikipedia search engine called Powerset. I also began attending Ruby 86 | meetups and drinking with local software developers. There are a lot 87 | of talented people in the Bay Area and I wanted to meet them all. 88 | Within the Ruby community, a distributed version control system called 89 | Git was starting to get some attention. It was a really cool way of 90 | working with other people on code, but there wasn't an easy way to get 91 | up and running with a group of developers. Along with cofounders Chris 92 | Wanstrath and PJ Hyett (who I met at the Ruby meetups) I started a 93 | company called GitHub that would address this problem and make it dead 94 | simple to share Git repositories and collaborate on code with other 95 | developers. 96 | 97 | At first, we worked on GitHub on the side, putting in time on evenings 98 | and weekends. After six months we launched the site to the public and 99 | started charging. Not long after that, Powerset was acquired by 100 | Microsoft and I was faced with a choice: stay on as a Microsoft 101 | employee with a big retention bonus and give up GitHub or turn down 102 | the Microsoft money and quit Powerset to work on GitHub full-time. You 103 | can read more about this saga in my blog post entitled [How I Turned 104 | Down $300,000 from Microsoft to go Full-Time on 105 | GitHub](http://tom.preston-werner.com/2008/10/18/how-i-turned-down-300k.html). 106 | I think I made the right decision. 107 | 108 | Today GitHub has twenty-nine employees and more than 730,000 users with over 109 | 2,000,000 repositories. We're growing fast, and I'm having the time of 110 | my life! -------------------------------------------------------------------------------- /test_projects/mojombo/_posts/2010-10-18-optimize-for-happiness.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: post 3 | title: Optimize for Happiness 4 | --- 5 | 6 | {{ page.title }} 7 | ================ 8 | 9 | 10 | 11 | Two days ago I had the pleasure of speaking at Startup School, a yearly conference on entrepreneurism put on by the great folks at Y Combinator. Never before have I see such a high concentration of smart ambitious people in one place. 12 | 13 | You can watch the recording of my thirty minute slot on Youtube: 14 | 15 |
site.posts. Each post, in turn, contains various
78 | fields such as title and date.
79 |
80 | Jekyll gets the list of blog posts by parsing the files in the
81 | [_posts](http://github.com/mojombo/tpw/tree/master/_posts) directory. Each post's
82 | filename contains the publishing date and slug (what shows up in the URL) that
83 | the final HTML file should have. Open up the file corresponding to this blog
84 | post:
85 | [2008-11-17-blogging-like-a-hacker.textile](http://github.com/mojombo/tpw/tree/master/_posts/2008-11-17-blogging-like-a-hacker.textile).
86 | GitHub renders textile files by default, so to better understand the file, click
87 | on the
88 | [raw](http://github.com/mojombo/tpw/tree/master/_posts/2008-11-17-blogging-like-a-hacker.textile?raw=true)
89 | view to see the original file. Here I've specified the post layout.
90 | If you look at that file you'll see an example of a nested layout. Layouts can
91 | contain other layouts allowing you a great deal of flexibility in how pages are
92 | assembled. In my case I use a nested layout in order to show related posts for
93 | each blog entry. The YAML also specifies the post's title which is then embedded
94 | in the post's body via Liquid.
95 |
96 | Posts are handled in a special way by Jekyll. The date you specify in the
97 | filename is used to construct the URL in the generated site. This post, for
98 | instance, ends up at
99 | http://tom.preston-werner.com/2008/11/17/blogging-like-a-hacker.html.
100 |
101 | Files that do not reside in directories prefixed with an underscore are mirrored
102 | into a corresponding directory structure in the generated site. If a file does
103 | not have a YAML preface, it is not run through the Liquid interpreter. Binary
104 | files are copied over unmodified.
105 |
106 | In order to convert your raw site into the finished version, you simply run:
107 |
108 | $ jekyll /path/to/raw/site
109 | /path/to/place/generated/site
29 |
133 |
134 |
30 | Tom Preston-Werner
31 | home
32 |
33 |
34 |
35 |
94 |
95 |
107 |
108 | Replicated - An Easier Path from SaaS to Enterprise
36 | 37 | 38 | 39 |Over the last year I’ve had a chance to learn a lot more about early stage 40 | funding and made angel investments in a handful of startups. So far I’ve 41 | restricted my involvement to companies with ideas in which I have significant 42 | domain knowledge. I also insist on founders with relentless product focus, a 43 | fierce desire to help their customers be more awesome, and excellent 44 | communication skills. I recently met just such a company, with just such 45 | founders, tackling a problem that has personally caused me much pain.
46 | 47 |The company is Replicated, and founders Grant Miller 48 | and Marc Campbell are making it easier to roll out an on-prem Enterprise 49 | offering based on an existing cloud-based SaaS product.
50 | 51 |At GitHub, we burned through a lot of developer cycles building our own 52 | installer (several times), securing the installation environment, coding an 53 | automated licensing management system, integrating single sign-on services 54 | (LDAP, Active Directory, CAS, etc, etc), building out a searchable audit system, 55 | supporting customer-reviewable support bundles (logs and other diagnostic 56 | output), allowing numerous backup strategies, and countless other 57 | Enterprise-specific features that were killing our Enterprise deals. All of this 58 | on top of hiring and building out the necessary sales, support, and accounting 59 | teams to create a smooth Enterprise experience for our customers.
60 | 61 |Replicated provides common Enterprise functionality (much of what I mentioned 62 | above, and all of it eventually) that you can wrap around your SaaS product, 63 | resulting in a first-class on-prem product in a fraction of the time. Beyond 64 | just technology, Replicated will help you understand your Enterprise customers 65 | through documentation on best practices and insight into the requirements and 66 | reasons that large companies desire the features they do. Until you can 67 | empathise with your customer (which is very hard to do as a fast-moving SaaS 68 | startup), you’ll never build the best product possible.
69 | 70 |Getting into the Enterprise market will always be hard. But by reducing the 71 | technology burden, Replicated plans to erase much of the pain so you can focus 72 | on the other human-centric tasks. Not only am I an investor in Replicated, I 73 | believe in their mission and their founders so much that I’ve joined as an 74 | advisor. I understand what the uphill slog of the SaaS to Enterprise climb feels 75 | like, and I’m going to do my best to ensure you don’t have to suffer it as much 76 | as I did.
77 | 78 |I’m also pleased to announce that Travis CI is now shipping their Enterprise 79 | product using Replicated. To see what the installation process is like, watch 80 | Grant install Travis CI 81 | Enterprise on a 82 | fresh server in about seven minutes. For a deeper dive, Travis CI has also 83 | published a blog post covering some of their process in getting their 84 | Enterprise installer ready using 85 | Replicated.
86 | 87 |In the coming weeks, you’ll start to see other well-known startups launching (or 88 | re-launching) Enterprise versions of their SaaS software on top of Replicated. 89 | If you’re looking to do the same, and want to save yourself a lot of heartache, 90 | email contact@replicated.com, and start 91 | focusing on what matters the most: your unique and kickass product.
92 | 93 |
109 |
132 |
110 |
120 |
111 | Tom Preston-Werner
112 |
113 | Cofounder of
114 | Codestarter,
115 | GitHub
116 |
117 | tom@mojombo.com
118 |
121 |
126 |
122 | github.com/mojombo
123 | twitter.com/mojombo
124 |
127 |
128 |
129 |
130 |
131 |
129 |
130 |
135 |
136 |
137 |
138 |
142 |
145 |
146 |
147 |
148 |
152 |
156 |
157 |
158 |
159 |
160 |
--------------------------------------------------------------------------------
/test_projects/mojombo/_expected/2010/12/11/designer-architect-developer.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
29 |
99 |
100 |
30 | Tom Preston-Werner
31 | home
32 |
33 |
34 |
35 |
60 |
61 |
73 |
74 | Designer, Architect, Developer
36 | 37 | 38 | 39 |Over the last six years I’ve bootstrapped three successful enterprises (Cube6 Media, Gravatar, and GitHub) and failed to gain traction with a handful of others. After a lot of thought and reflections on these experiences, I’ve identified three major skills that should be present in order to best build a successful web application. These roles can be loosely defined as the Designer, the Architect, and the Developer.
40 | 41 |In college I spent a lot of time in the campus dark room dipping rolls of film and sheets of paper into various chemical baths beneath a dim red light. The most interesting part, though, was mounting the negative into the projector and exposing the photo paper. Every time I turned on the bright light of the projector I was reminded of a saying that has stuck with me ever since: “A photograph is nothing more than an image created by light.” Think about that for a second. The only way the photograph, and hence, the viewer, interact with the original subject is via the light that was captured. None of the fancy flashes, soft boxes, bounces, umbrellas, or backdrops mean a thing if the light they produce or redirect is in the wrong place. If the light is bad, the photograph is bad.
42 | 43 |I think the same concept holds true for web applications. Adapting the saying for our own situation, I would say: “A web application is nothing more than an experience created by design.” Users can’t see what technology you use or whether you follow an agile development process or not. All they experience is what’s on the screen. It can’t be confusing, it can’t look amateur, and it can’t have spelling errors. If the UX is bad, the web application is bad. It’s that simple.
44 | 45 |The way you get good UX is by having a good designer. Someone on the team must be skilled not only in making things pretty, but in making them usable as well. Without a good UX/visual design, you may as well not even bother. It’s impossible to stress how important this is.
46 | 47 |Design comes first. It defines what you will build. Once you have an idea of what you’re creating, you need to figure out how to make it happen. That’s where the Architect comes in.
48 | 49 |With the recent explosion of open source solutions to common problems like databases, web frameworks, job processors, messaging systems, etc, you need a team member that has a broad understanding of the technology landscape. The choices you make early on will impact your company for many years, and the wrong choices can spell disaster. The role of the Architect is to choose the best tools for the job, and to decide when new tools need to be created.
50 | 51 |The Architect must also be ready to scale any piece of the site when you start attracting users. There’s a fine line between premature optimization and crumbling under the wave of thousands of new signups. A good architect will always be one step ahead of the curve, laying the groundwork for future scaling needs just before they are needed.
52 | 53 |Design and architecture dictate what you build and how you build it, but without someone to do the construction, you’re dead in the water. The role of the Developer is to turn the wishes of the Designer into reality while staying within the constraints that the Architect has put forth. In addition, the Developer has to ensure that the codebase remains healthy and protect against technical debt. Sloppy development up front means a huge amount of wasted effort later on.
54 | 55 |The three roles of the Designer, the Architect, and the Developer may reside in a single person, but it’s much more common to see groups of two or three people satisfy all these skills. In fact, the best founding teams are those where everyone fills some combination of roles. This fosters an environment of friendly argument that leads to better decisions.
56 | 57 |But whatever you do, make sure your team fills all of these roles. Once you do, executing on your idea should come easily!
58 | 59 |
75 |
98 |
76 |
86 |
77 | Tom Preston-Werner
78 |
79 | Cofounder of
80 | Codestarter,
81 | GitHub
82 |
83 | tom@mojombo.com
84 |
87 |
92 |
88 | github.com/mojombo
89 | twitter.com/mojombo
90 |
93 |
94 |
95 |
96 |
97 |
95 |
96 |
101 |
102 |
103 |
104 |
108 |
111 |
112 |
113 |
114 |
118 |
122 |
123 |
124 |
125 |
126 |
--------------------------------------------------------------------------------
/test_projects/mojombo/_posts/2011-11-22-open-source-everything.md:
--------------------------------------------------------------------------------
1 | ---
2 | layout: post
3 | title: Open Source (Almost) Everything
4 | ---
5 |
6 | {{ page.title }}
7 | ================
8 |
9 |
10 |
11 | When Chris and I first started working on GitHub in late 2007, we split the work into two parts. Chris worked on the Rails app and I worked on Grit, the first ever Git bindings for Ruby. After six months of development, Grit had become complete enough to power GitHub during our public launch of the site and we were faced with an interesting question:
12 |
13 | Should we open source Grit or keep it proprietary?
14 |
15 | Keeping it private would provide a higher hurdle for competing Ruby-based Git hosting sites, giving us an advantage. Open sourcing it would mean thousands of people worldwide could use it to build interesting Git tools, creating an even more vibrant Git ecosystem.
16 |
17 | After a small amount of debate we decided to open source Grit. I don't recall the specifics of the conversation but that decision nearly four years ago has led to what I think is one of our most important core values: open source (almost) everything.
18 |
19 | Why is it awesome to open source (almost) everything?
20 | -----------------------------------------------------
21 |
22 | If you do it right, open sourcing code is **great advertising** for you and your company. At GitHub we like to talk publicly about libraries and systems we've written that are still closed but destined to become open source. This technique has several advantages. It helps determine what to open source and how much care we should put into a launch. We recently open sourced Hubot, our chat bot, to widespread delight. Within two days it had 500 watchers on GitHub and 409 upvotes on Hacker News. This translates into goodwill for GitHub and more superfans than ever before.
23 |
24 | If your code is popular enough to attract outside contributions, you will have created a **force multiplier** that helps you get more work done faster and cheaper. More users means more use cases being explored which means more robust code. Our very own [resque](https://github.com/defunkt/resque) has been improved by 115 different individuals outside the company, with hundreds more providing 3rd-party plugins that extend resque's functionality. Every bug fix and feature that you merge is time saved and customer frustration avoided.
25 |
26 | Smart people like to hang out with other smart people. Smart developers like to hang out with smart code. When you open source useful code, you **attract talent**. Every time a talented developer cracks open the code to one of your projects, you win. I've had many great conversations at tech conferences about my open source code. Some of these encounters have led to ideas that directly resulted in better solutions to problems I was having with my projects. In an industry with such a huge range of creativity and productivity between developers, the right eyeballs on your code can make a big difference.
27 |
28 | If you're hiring, **the best technical interview possible** is the one you don't have to do because the candidate is already kicking ass on one of your open source projects. Once technical excellence has been established in this way, all that remains is to verify cultural fit and convince that person to come work for you. If they're passionate about the open source code they've been writing, and you're the kind of company that cares about well-crafted code (which clearly you are), that should be simple! We hired [Vicent Martí](https://github.com/tanoku) after we saw him doing stellar work on [libgit2](https://github.com/libgit2/libgit2), a project we're spearheading at GitHub to extract core Git functionality into a standalone C library. No technical interview was necessary, Vicent had already proven his skills via open source.
29 |
30 | Once you've hired all those great people through their contributions, dedication to open source code is an amazingly effective way to **retain that talent**. Let's face it, great developers can take their pick of jobs right now. These same developers know the value of coding in the open and will want to build up a portfolio of projects they can show off to their friends and potential future employers. That's right, a paradox! In order to keep a killer developer happy, you have to help them become more attractive to other employers. But that's ok, because that's exactly the kind of developer you want to have working for you. So relax and let them work on open source or they'll go somewhere else where they can.
31 |
32 | When I start a new project, I assume it will eventually be open sourced (even if it's unlikely). This mindset leads to **effortless modularization**. If you think about how other people outside your company might use your code, you become much less likely to bake in proprietary configuration details or tightly coupled interfaces. This, in turn, leads to cleaner, more maintainable code. Even internal code should pretend to be open source code.
33 |
34 | Have you ever written an amazing library or tool at one job and then left to join another company only to rewrite that code or remain miserable in its absence? I have, and it sucks. By getting code out in the public we can drastically **reduce duplication of effort**. Less duplication means more work towards things that matter.
35 |
36 | Lastly, **it's the right thing to do**. It's almost impossible to do anything these days without directly or indirectly executing huge amounts of open source code. If you use the internet, you're using open source. That code represents millions of man-hours of time that has been spent and then given away so that everyone may benefit. We all enjoy the benefits of open source software, and I believe we are all morally obligated to give back to that community. If software is an ocean, then open source is the rising tide that raises all ships.
37 |
38 | Ok, then what shouldn't I open source?
39 | --------------------------------------
40 |
41 | That's easy. Don't open source anything that represents core business value.
42 |
43 | Here are some examples of what we don't open source and why:
44 |
45 | * Core GitHub Rails app (easier to sell when closed)
46 | * The Jobs Sinatra app (specially crafted integration with github.com)
47 |
48 | Here are some examples of things we do open source and why:
49 |
50 | * Grit (general purpose Git bindings, useful for building many tools)
51 | * Ernie (general purpose BERT-RPC server)
52 | * Resque (general purpose job processing)
53 | * Jekyll (general purpose static site generator)
54 | * Gollum (general purpose wiki app)
55 | * Hubot (general purpose chat bot)
56 | * Charlock_Holmes (general purpose character encoding detection)
57 | * Albino (general purpose syntax highlighting)
58 | * Linguist (general purpose filetype detection)
59 |
60 | Notice that everything we keep closed has specific business value that could be compromised by giving it away to our competitors. Everything we open is a general purpose tool that can be used by all kinds of people and companies to build all kinds of things.
61 |
62 | What is the One True License?
63 | -----------------------------
64 |
65 | I prefer the MIT license and almost everything we open source at GitHub carries this license. I love this license for several reasons:
66 |
67 | * It's short. Anyone can read this license and understand exactly what it means without wasting a bunch of money consulting high-octane lawyers.
68 |
69 | * Enough protection is offered to be relatively sure you won't sue me if something goes wrong when you use my code.
70 |
71 | * Everyone understands the legal implications of the MIT license. Weird licenses like the WTFPL and the Beer license pretend to be the "ultimate in free licenses" but utterly fail at this goal. These fringe licenses are too vague and unenforceable to be acceptable for use in some companies. On the other side, the GPL is too restrictive and dogmatic to be usable in many cases. I want everyone to benefit from my code. Everyone. That's what Open should mean, and that's what Free should mean.
72 |
73 | Rad, how do I get started?
74 | --------------------------
75 |
76 | Easy, just flip that switch on your GitHub repository from private to public and tell the world about your software via your blog, Twitter, Hacker News, and over beers at your local pub. Then sit back, relax, and enjoy being part of something big.
77 |
78 | [Discuss this post on Hacker News](http://news.ycombinator.com/item?id=3267432)
79 |
--------------------------------------------------------------------------------
/test_projects/mojombo/_expected/2008/11/03/how-to-meet-your-next-cofounder.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
29 |
144 |
145 |
30 | Tom Preston-Werner
31 | home
32 |
33 |
34 |
35 |
105 |
106 |
118 |
119 | How to Meet Your Next Cofounder
36 | 37 | 38 | 39 |Over the last few months I’ve seen a number of people looking for cofounders on 40 | Hacker News or via their own personal blogs. I think this is, at best, a highly 41 | inefficient way to find a cofounder and, at worst, a way to fool yourself into 42 | finding the wrong cofounder. In any case, it’s a naive approach to finding the 43 | person that will need to stand by your side in the coming storm that we call 44 | “running a startup.”
45 | 46 |Don’t get me wrong, the internet is an amazing tool for meeting people. The 47 | wider the net you cast, the more likely you are to find the perfect match. But 48 | the internet has its limitations. I’ve had internet friends that were engaging, 49 | witty, and brilliant online, but in person felt awkward and boring. Conversely, 50 | I know people that are volatile and inflammatory online, but present an attitude 51 | of friendliness and caring in person. This phenomenon makes it difficult to 52 | gauge an individual’s personality from online interaction alone.
53 | 54 |A far better use of the internet is to find groups of people that share your 55 | interests. Track down the local users group for your language or technology of 56 | choice. The simple fact that members of these groups take time out of their day 57 | to show up means that they’re more motivated and driven than the average person. 58 | Even if it’s a bit of a commute to get to the meetings, start showing up 59 | regularly. Prepare a few presentations on topics that you’re passionate about. 60 | Bonus points if you present on ideas related to your potential startup. Don’t 61 | worry about revealing your game-changing secrets; stealth mode is bullshit. Talk 62 | to everyone. Steer the conversation toward your interests and if someone there 63 | is excited about the same things, it will be clear.
64 | 65 |It may take weeks or months, but in a good group you’ll find a handful of people 66 | that you really like. If at all possible, go out drinking with these people 67 | after the meetups. This is one of the easiest ways to go from “acquaintance” to 68 | “friend” and gives you free license to bring up your craziest of ideas without 69 | sounding like too much of a nutjob.
70 | 71 |Of the people that you like, several may make excellent candidates for 72 | cofounders. Do a little research on these individuals. What does their code look 73 | like? Have they done much open source? Do they demonstrate an entrepreneurial 74 | spirit? Can they stick with a single project for a long time? Have they been 75 | loyal to their friends and companies in the past? A good cofounder should be 76 | someone with whom you feel privileged to work. And they should feel privileged 77 | to work with you. The two of you should be on very solid ground before you begin 78 | your startup adventure, because once you do, the impact of every argument is 79 | going to feel like it’s been multiplied by a thousand.
80 | 81 |This all sounds like a lot of hard work. Maybe you’re wondering if it would be 82 | better to just go solo. I did that with Gravatar, and, in retrospect, it’s 83 | painfully obvious that I made a lot of stupid mistakes. When it’s just you and 84 | your thoughts it becomes too easy to pick the first thing that pops into your 85 | head. We’re programmed to think all of our ideas are good, but reality tells a 86 | different story. Truly good decisions are forged from the furnace of argument, 87 | not plucked like daisies from the pasture of a peaceful mind. A good cofounder 88 | tells you when your ideas are half-baked and ensures that your good ideas 89 | actually get implemented.
90 | 91 |The second biggest danger with going solo is the loss of motivation. Solipsism 92 | might make you feel important at first, but the constant lack of feedback and 93 | the absence of support during tough times can easily lead to a premature end to 94 | your adventure. Cofounders are like workout buddies. Just when you think there’s 95 | no possible way you can do another rep, there they are, rooting you on toward an 96 | achievement that wouldn’t be possible without them.
97 | 98 |Your choice of cofounder will affect everything you do in your startup. They’ll 99 | share every defeat with you and celebrate every success. They’ll help you 100 | understand your own ideas better by offering a different perspective. They’ll be 101 | the single most important decision you make during the tenure of your startup, 102 | so choose wisely and with extreme care.
103 | 104 |
120 |
143 |
121 |
131 |
122 | Tom Preston-Werner
123 |
124 | Cofounder of
125 | Codestarter,
126 | GitHub
127 |
128 | tom@mojombo.com
129 |
132 |
137 |
133 | github.com/mojombo
134 | twitter.com/mojombo
135 |
138 |
139 |
140 |
141 |
142 |
140 |
141 |
146 |
147 |
148 |
149 |
153 |
156 |
157 |
158 |
159 |
163 |
167 |
168 |
169 |
170 |
171 |
--------------------------------------------------------------------------------
/test_projects/mojombo/_expected/2010/08/23/readme-driven-development.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
29 |
114 |
115 |
30 | Tom Preston-Werner
31 | home
32 |
33 |
34 |
35 |
75 |
76 |
88 |
89 | Readme Driven Development
36 | 37 | 38 | 39 |I hear a lot of talk these days about TDD and BDD and Extreme Programming and SCRUM and stand up meetings and all kinds of methodologies and techniques for developing better software, but it’s all irrelevant unless the software we’re building meets the needs of those that are using it. Let me put that another way. A perfect implementation of the wrong specification is worthless. By the same principle a beautifully crafted library with no documentation is also damn near worthless. If your software solves the wrong problem or nobody can figure out how to use it, there’s something very bad going on.
40 | 41 |Fine. So how do we solve this problem? It’s easier than you think, and it’s important enough to warrant its very own paragraph.
42 | 43 |Write your Readme first.
44 | 45 |First. As in, before you write any code or tests or behaviors or stories or ANYTHING. I know, I know, we’re programmers, dammit, not tech writers! But that’s where you’re wrong. Writing a Readme is absolutely essential to writing good software. Until you’ve written about your software, you have no idea what you’ll be coding. Between The Great Backlash Against Waterfall Design and The Supreme Acceptance of Agile Development, something was lost. Don’t get me wrong, waterfall design takes things way too far. Huge systems specified in minute detail end up being the WRONG systems specified in minute detail. We were right to strike it down. But what took its place is too far in the other direction. Now we have projects with short, badly written, or entirely missing documentation. Some projects don’t even have a Readme!
46 | 47 |This is not acceptable. There must be some middle ground between reams of technical specifications and no specifications at all. And in fact there is. That middle ground is the humble Readme.
48 | 49 |It’s important to distinguish Readme Driven Development from Documentation Driven Development. RDD could be considered a subset or limited version of DDD. By restricting your design documentation to a single file that is intended to be read as an introduction to your software, RDD keeps you safe from DDD-turned-waterfall syndrome by punishing you for lengthy or overprecise specification. At the same time, it rewards you for keeping libraries small and modularized. These simple reinforcements go a long way towards driving your project in the right direction without a lot of process to ensure you do the right thing.
50 | 51 |By writing your Readme first you give yourself some pretty significant advantages:
52 | 53 |-
54 |
-
55 |
Most importantly, you’re giving yourself a chance to think through the project without the overhead of having to change code every time you change your mind about how something should be organized or what should be included in the Public API. Remember that feeling when you first started writing automated code tests and realized that you caught all kinds of errors that would have otherwise snuck into your codebase? That’s the exact same feeling you’ll have if you write the Readme for your project before you write the actual code.
56 |
57 | -
58 |
As a byproduct of writing a Readme in order to know what you need to implement, you’ll have a very nice piece of documentation sitting in front of you. You’ll also find that it’s much easier to write this document at the beginning of the project when your excitement and motivation are at their highest. Retroactively writing a Readme is an absolute drag, and you’re sure to miss all kinds of important details when you do so.
59 |
60 | -
61 |
If you’re working with a team of developers you get even more mileage out of your Readme. If everyone else on the team has access to this information before you’ve completed the project, then they can confidently start work on other projects that will interface with your code. Without any sort of defined interface, you have to code in serial or face reimplementing large portions of code.
62 |
63 | -
64 |
It’s a lot simpler to have a discussion based on something written down. It’s easy to talk endlessly and in circles about a problem if nothing is ever put to text. The simple act of writing down a proposed solution means everyone has a concrete idea that can be argued about and iterated upon.
65 |
66 |
Consider the process of writing the Readme for your project as the true act of creation. This is where all your brilliant ideas should be expressed. This document should stand on its own as a testament to your creativity and expressiveness. The Readme should be the single most important document in your codebase; writing it first is the proper thing to do.
69 | 70 |–
71 | 72 | 73 | 74 |
90 |
113 |
91 |
101 |
92 | Tom Preston-Werner
93 |
94 | Cofounder of
95 | Codestarter,
96 | GitHub
97 |
98 | tom@mojombo.com
99 |
102 |
107 |
103 | github.com/mojombo
104 | twitter.com/mojombo
105 |
108 |
109 |
110 |
111 |
112 |
110 |
111 |
116 |
117 |
118 |
119 |
123 |
126 |
127 |
128 |
129 |
133 |
137 |
138 |
139 |
140 |
141 |
--------------------------------------------------------------------------------
/test_projects/mojombo/_expected/2014/04/21/farewell-github-hello-immersive-computing.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
29 |
148 |
149 |
30 | Tom Preston-Werner
31 | home
32 |
33 |
34 |
35 |
109 |
110 |
122 |
123 | Farewell GitHub, Hello Immersive Computing
36 | 37 | 38 | 39 |Today is my last day at GitHub. Recent events have given me a lot of time to 40 | reflect on what’s important to me, and I’ve decided to switch gears and focus on 41 | building something from scratch again. Since visiting the Oculus VR team at 42 | their office three months ago, I’ve come to believe that immersive computing 43 | (aka virtual reality) is poised to rival the personal computer, the web, social 44 | networking, and mobile devices in its impact. While the timing is more abrupt 45 | than I had intended, with everything that’s happened, I think now is the right 46 | time to do this, and I’d like to explain why.
47 | 48 |First, I want to address the serious accusations that were made against me and 49 | my family over the past month. With every decision I made at GitHub and in every 50 | interaction I had with employees, I tried to treat people better than they 51 | expected and to resolve conflict with empathy. Despite that, I’ve made mistakes, 52 | and I am deeply sorry to anyone who was hurt by those mistakes. It devastates me 53 | to know that I missed the mark, and I will strive to do better, every day.
54 | 55 |That said, I want to be very clear about one thing: neither my wife, Theresa, 56 | nor I have ever engaged in gender-based harassment or discrimination. The 57 | results of GitHub’s independent investigation unequivocally confirm this and we 58 | are prepared to fight any further false claims on this matter to the full extent 59 | of the law. I believe in diversity and equality for all people in all 60 | professions, especially the tech sector. It’s immensely important to me and I 61 | will continue to do my very best to further that belief.
62 | 63 |Unfortunately, the investigation and all the attention surrounding it have me 64 | concerned that remaining at GitHub would be a distraction for both me and the 65 | company. I’m incredibly proud of what I’ve helped build at GitHub and I don’t 66 | want the events of the past month to jeopardize that. I care too much about the 67 | company and the people here to let that happen. The GitHub team is incredibly 68 | strong, with fierce vision, and I have no doubt they will continue to 69 | revolutionize software development for decades to come. Founding and building 70 | GitHub has been the greatest adventure of my life. I’ve been so lucky to be on 71 | this journey with such amazing, helpful, talented, and real people. I’m going to 72 | miss working with such a great team, but I’m also insanely excited about the 73 | future.
74 | 75 |Since the early days of GitHub, I’ve wanted to create a different kind of 76 | business. One that was Optimized for 77 | Happiness 78 | and built atop a Framework of 79 | Happiness. One where great people 80 | could work on hard problems together to create unbelievably good products. I 81 | believe I was able to achieve a great deal of success with that model at GitHub, 82 | even if things didn’t always go perfectly according to plan. All of this has 83 | been a tremendous learning experience for me.
84 | 85 |Last January I stepped down as CEO and handed that role over to cofounder Chris 86 | Wanstrath so I could focus on future-facing R&D projects with small teams. This 87 | kind of rapid, team-based innovation is what I live for. During my time away 88 | from GitHub I started experimenting with Go, OpenGL, and Unity with an eye 89 | towards the software side of immersive computing. It felt really good to get 90 | back into a code editor and challenge the deeply logical and analytical part of 91 | my brain. I’ve enjoyed the challenges of learning how to lead a company with 92 | hundreds of people, but it’s very hard for me to deny the allure of coding a 93 | system that could once again change the course of history.
94 | 95 |I’m telling you this because I think stealth mode is bullshit and if you feel 96 | the same way I do about immersive computing then I want to talk with you about 97 | it. For the next few months I’m going to be living in Manhattan. My wife, 98 | Theresa, is currently participating in Techstars NYC as their very first 99 | nonprofit. Her startup, The Omakase Charity, 100 | helps donors learn about and support nonprofits that are changing the world with 101 | technology. She’s one of the strongest and most thoughtful women I know, and I’m 102 | hoping to help her succeed with her mission while I’m here.
103 | 104 |Thank you to everyone that reached out to me over the last month, including the 105 | generous team at Andreessen Horowitz. Your support has made a huge difference 106 | and I’m truly excited for what’s next.
107 | 108 |
124 |
147 |
125 |
135 |
126 | Tom Preston-Werner
127 |
128 | Cofounder of
129 | Codestarter,
130 | GitHub
131 |
132 | tom@mojombo.com
133 |
136 |
141 |
137 | github.com/mojombo
138 | twitter.com/mojombo
139 |
142 |
143 |
144 |
145 |
146 |
144 |
145 |
150 |
151 |
152 |
153 |
157 |
160 |
161 |
162 |
163 |
167 |
171 |
172 |
173 |
174 |
175 |
--------------------------------------------------------------------------------