Skip to content

Instantly share code, notes, and snippets.

View jonschlinkert's full-sized avatar
🤔
Trying to stay in the right branch of the wave function.

Jon Schlinkert jonschlinkert

🤔
Trying to stay in the right branch of the wave function.
View GitHub Profile
<!DOCTYPE html>
<html lang="en">
<head>
<title>{{ title }}</title>
</head>
<body>
<div class="page-wrap" id="page-content-container">
{% body %}
</div>
</body>

Outline

Any of this is subject to feedback, but I recommend that documentation be written so that it's first organized around logical topics - like templates, data, content, etc. Simply because it's easier to write in a linear way and and make sure you hit all of the bullets. After that, we can create paths for specific types of users via content, navigation, search and links, so that developers vs. designers, or newcomers vs. advanced users can quickly find what they're interested in, and the information for any type of user will progressively disclose in a way that makes sense to them.

Site areas

  • By topic (templates, data, ...)
@jonschlinkert
jonschlinkert / 100x100.txt
Last active May 16, 2017 21:13
this is an example for the https://github.com/micromatch/braces readme
11 12 13 14 15 16 17 18 19 110 111 112 113 114 115 116 117 118 119 120
121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137
138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154
155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171
172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188
189 190 191 192 193 194 195 196 197 198 199 1100 21 22 23 24 25 26 27
28 29 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225
226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242
243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259
260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276

This comment was deleted from markdown-it/markdown-it#328 (comment)

I don't agree with your vision of situation. Jon Schlinkert was added to copyright string by mistake (in advance, because he fooled me with false promises) and he was not a copyright owner.

To this point I've remained quiet despite your repeated public dishonesty and not respecting the copyright on remarkable. I'm the copyright owner of remarkable, this is a fork of that project. As you know (and the entire world can see for themselves), what is now called "remarkable" initially was called remarked, which itself was a fork of marked.js.

You contacted me and asked if you could contribute to that project. I asked you why you contact "me"?, and you gave a couple of reasons, including that you thought my approach was better than other libraries you found. I said yes and you said you wanted to do a lot and potentially make major changes. I said

In an effort to improve the quality of search results on sites like https://npmjs.com, there has been more and more discussion about factoring in the ranking/scoring of dependencies to influence search results. The general idea is that a library should be ranked not only on its own merits, but dependencies should weigh into the score as well.

I’m not sure what my opinion is on this yet. I was initially in favor of this, and still might be, but this document is a summary of some things that crossed my mind about the topic.

Should dependencies weigh into the search score for a library?

  1. Some very popular libraries on npm are very poorly written, but solve problems that are sufficiently complex that few alternatives exist. From a scoring standpoint, this alone wouldn't matter because the law of averages would even it out. However...
  2. It's possible for developers to write high quality, stable code on top of lesser quality libraries.
  3. The better quality the code, and more knowledgable the maintainer
@jonschlinkert
jonschlinkert / strategic-control-point-index.md
Last active February 3, 2018 05:59
This is inspired by the book "The Profit Zone". It's been something like 20 years since I read that book, but I've used this index to guide many of the business and investment decisions I've made since that time.

Strategic control point index

Businesses with high strategic control have more sustainable profitability, stronger competitive advantage, and higher valuations. Many business hit multiple strategic control points, and it's possible for businesses to combine multiple control points, even low control, to achieve a much greater level of strategic control in aggregate.

High strategic control:

  • 10 — Monopoly, patent, own the standard
  • 9 — Control of value chain
  • 8 — Control of supply, string of superdominant positions
  • 7 — Control of distribution, owning the customer relationship, owning customer information flow

Code project conversion funnel

A page-rank-like approach to scoring code libraries for quality and dependability. This is a quick-pass attempt at translating metrics we have readily available in the code community into a conversion funnel that might be familiar to marketers.

Conversion funnel equivalent Metric Description
awareness github stars Equivalent of "likes", but only slightly better than visits (it's possible to have many stars per one visitor). This metric only proves awareness, no causal relationship to actual interest, "real" popularity, code quality, trust, intent to use, or advancement in the conversion funnel.
interest dependents Dependants are a sign of awareness and commitment from the authors that chose to depend on the library, but no correlation to actual usage, commitment from upstream implementors and users to use the dependent, and is just as likely to represent herd mentality or a reaction to recent awareness as it is to be a p
var mm = require('micromatch');
var ast = mm.parse('*(*(of*(a)x)z)', {sourcemap: true});
console.log(ast);
// results in:
{ type: 'root',
errors: [],
nodes:
[ { type: 'bos', val: '' },
{ type: 'paren',
@jonschlinkert
jonschlinkert / regex-braces-vs-minimatch.js
Last active October 10, 2016 23:44
this is a not-too-crazy pattern. It's just a date range, it could easily be a lot more complicated. By why even have to worry about how complicated your brace pattern is?
/**
* Results:
*
* - braces regex: 73 characters
* - minimatch regex: 26,918 characters
*/
console.log('braces.makeRe: "foo/{1900..2016}/bar/{a..j}/baz"');
console.log(braces.makeRe('foo/{1900..2016}/bar/{a..j}/baz'));
//=> /^(?:foo\/(190[0-9]|19[1-9][0-9]|200[0-9]|201[0-6])\/bar\/([a-j])\/baz)$/