-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
191 lines (161 loc) · 9.93 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8"/>
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1"/>
<title>The Cobbler's Children Have No Shoes</title>
<link rel="stylesheet" href="https://unpkg.com/@csstools/normalize.css" />
<link rel="stylesheet" href="assets/site.css"/>
</head>
<body>
<main class="main">
<h1>"The Cobbler's Children have no Shoes"</h1>
<p>
There is an old phrase, it has appeared in <a href="http://english.stackexchange.com/questions/159004/the-cobblers-children-have-no-shoes">different forms
in perhaps a dozen languages</a>, but the sentiment is all the same: Since you do a thing for a living,
'someday' you will do the thing properly for yourself and your family, but right now, you save all your best
effort for your customers.
</p>
<h1>We Are All the Cobbler's Children</h1>
<p>
In software, we also save our best work for our customers. Unfortunately we also <em>use software to make
software</em>. "Someday" rarely comes, and for decades some of the most maladapted pieces of software you could
encounter were developer tools. Good Enough has ruled the day for a long time, and only in recent years have
things changed in any perceptible manner.
</p>
<p>
The problem with this is that humans negotiate, all the time, even when we don't think we are. We tend to
adjust our expectations to what is going on around us. Those "Would you spent $1000 for this?" commercials
bank on this tendency. It's called <b>Anchoring</b>. Our belief is that if you use awful tools while trying to
make something great, you won't do your best work.
</p>
<h1>How you can help</h1>
<p>
I am looking for like-minded individuals. People who understand the multiplicative effect on productivity that
a good tool offers, and the subtle ways that an otherwise good tool can undo its own advantages. I'd like to
find other people who count the cost of using their tools against the 'accidental complexity' of their projects
and are highly motivated to find better options or make improvements to existing ones.
</p>
<p>
What I hope to do is create a small group of people, probably full stack developers, who understand Human
Factors but can also contribute substantially to tools development. I'm hoping to organize people to identify
developer tools that are already in the range of Good Enough to 'fairly decent' and collaborate to fix them. And
also to identify other tools that need better alternatives and work together to create them or help people who
can.
</p>
<p>
If you'd like to help, check out the list of projects below, or suggest a new one.
</p>
<h1>What We're Working On</h1>
<p>
See the full list on our <a href="https://github.com/cobblers-children">GitHub organization page</a>, but here
are the highlights.
</p>
<h2>New Generation Project Management Tools</h2>
<p>
Virtually every single project management tool currently in existence was designed before CI/CD became
widespread. They all keep it at arm's length instead of inviting it in. In a very Paradox of Choice sense,
some of my best experiences with a PM tool were with Trac - a dead simple but highly integrated management
tool. We seek to build something on this philosophy, leveraging CI/CD concepts, and modern visualization tools.
</p>
<h2>Production-Ready Frameworks</h2>
<p>
The HEW Projects.
</p>
<p>
For ease of development, many libraries come configured in a very easy to start manner. Some say the user
should know better, others claim the code should be secure by default. The argument is always an either-or
scenario.
</p>
<p>
In an active community the definition of 'correct configuration' changes over time. A project generator may
help keep new developers safe, but create challenges for existing users. In place of generators we propose
leveraging underutilized features of DCVS tools such as Git, creating simple Git repositories that can be
forked, so that users can periodically merge changes from the upstream repository to stay in sync. Getting the
base project correct out of the box becomes a group effort, rather than down to each team.
</p>
<p>
This structure also works well wonderfully in a microservices or other non-monolithic architecture. Getting
headers, logging, failure behaviors, stat collection, correlationIDs, and load balancing right once, and copying
it across projects using Git, rather than by hand.
</p>
<h2>CommonMark</h2>
<p>
In the world of Wiki and Markdown, fragmentation has always been a problem. In the interests of easing that
learning curve we support Jeff Atwood and his friends' attempts to create
<a href="http://commonmark.org/">CommonMark</a>, and to create new ways of teaching simplified markup to new
people.
</p>
<p>
As the world has become more and more computerized, we have moved on from solving purely technological problems
to trying to organize information and people to deal with social, political, environmental, and health issues.
This now often involves gathering ('crowdsourcing') short prose from experts. While this is changing over time,
the fact of the matter is that there are many interesting and worthwhile problem domains where computer skill
are not highly valued, and those with the deepest expertise or the most interesting experiences are still often
not particularly computer savvy, and have no interest in becoming so.
</p>
<p>
We are also working with markdown learning tools such as
<a href="https://github.com/cobblers-children/commonmarkify">commonmarkify</a>, which is our CommonMark
adaptation of the <a href="https://github.com/tibastral/markdownify">markdownify</a> project, a hybrid MarkDown
editor that formats the source markup in a style similar to the final output.
</p>
<h2>Other Avenues</h2>
<p>
In addition to these projects, we have some other ideas we'd love to work on.
</p>
<h3>Multi-device programming</h3>
<p>
We are fast approaching a world where only technologists own fast computers. In the early 90's a "Developer
Grade Machine" could easily run you $8000 in inflation-adjusted dollars. Today you can have a similar machine,
often for much less than $2000. But with everyone migrating to tablets and smart phones we might not be able to
enjoy those economies of scale for much longer. There may come a day when developers are buying gamer machines
or server grade hardware because nothing else exists.
</p>
<p>
At the same time we have all of these internet gadgets, and unless we are specifically developing software for
them we do not benefit from them in our daily coding, and when they become too antiquated we have no use for
them at all, even though they could work as an auxiliary display. We would like to see these devices applied to
greater use:
</p>
<ul>
<li>Browser integration with IDEs, so that tablets can be used to visualize and navigate project information</li>
<li>Browser integration with reporting and code analysis tools to provide live data</li>
<li>High quality Responsive Design for common software developer tools</li>
<li>Ubiquity of 'livereload' behavior, allowing for faster confirmation of cross-device compatibility</li>
</ul>
<h3>Safe by Design Libraries</h3>
<p>
The internet is rife with articles proclaiming the Top 10 Mistakes in Problem Domain X, in which they enumerate
the common or even clichéd manner in which we as developers often manage to produce the same classes of errors
in our code. We believe that rather than indicating a moral failure by the user that it is instead due to Human
Factors in the API design. As the number of libraries we use increases, this work will become much more important.
</p>
<p>
Most APIs are filled with low level details and false friend functions which harm the obviousness of a piece of
code. We believe in the idea that there can and should be Safe by Design alternatives to these tools in which
code is Obviously Correct or Obviously Incorrect. Some areas we wish to apply this principle to are:
</p>
<ul>
<li>
<a href="http://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time">Time calculations</a>
- no two machines will agree on what time it is or what time it will be, even with NTP
</li>
<li>Internationalization - composing sentence fragments makes you sound like Yoda</li>
<li>Caching - implicit caching is dangerous and should be avoided. Know when you're caching.</li>
</ul>
<h3>Using Docker to Run Selenium Tests on Jenkins</h3>
<p>
Running Selenium in Docker is supported by the Selenium Team, and is a great way to run tests locally without
worrying about an errant keystroke causing your tests to fail. This docker-compose script can be used to run
Selenium tests on your CI server, which is typically a headless environment. This also supports remote
observation of a Selenium run, an important debugging option that is often overlooked.
</p>
<p>
This project, <a href="https://github.com/cobblers-children/docker-jenkins">'docker-jenkins'</a> is just a small
set of scripts to combine work done by the Jenkins community with work done by the Selenium community into
something that is interesting and useful in its own right.
</p>
</main>
</body>
</html>