There are way too many dipshits who are way too happy to come out of the woodwork when this topic is brought up to try to drop an FYI wisdom nugget on you about how github.com will let you skip a few of these steps and do the edit/commit thing directly in your browser. Great job on almost entirely missing the point, morons. Let's be excruciatingly clear:

If, at any point, "submit a PR" comes up during an explanation of how to do a run-of-the-mill edit on your project's wiki, then your project does not have a wiki.

From the homepage:

Repla is a macOS app that can[...]

That's like the complete opposite of "just give me a document that I can double click to open from disk and view in my browser"...

I suspect VS Code's non-native look has actually contributed to the uptake from a subset of its users. A fullscreen terminal-based editor like Vim is also non-native as far as widget sets are concerned, but pleasantly so in at least one respect. When Chrome was released, when you asked people what they liked about it, sure they'd say it was fast and whatnot, but for a non-trivial segment of the world, they just liked how visually slim it was. They appreciated how little chrome was actually in Chrome. VS Code managed to reap dividends on its imports of the same approach to its "shell", even while not being particularly fast. (People point to VS Code as an example of a snappy Electron app, and they're not wrong insofar as the comparison goes to other typical Electron apps; on an absolute, non-weight-class-adjusted scale, though, VS Code is still pretty clunky—people just ignore it because of how slim it appears in comparison to IDEs like MonoDevelop[1].)

1. https://upload.wikimedia.org/wikipedia/commons/0/01/Monodevelop-main-window.png

This complaint reflects an obsession that also explains a continual interest in today's news. It's not quite FOMO. Rather, it's an agitation that no one is producing anything which you can miss out on!

This is not something that should be lamented. Technological progress should be cumulative (along witth non-technological progress, for that matter).

Grids like these are user-hostile—a clear choice to prioritize aesthetics over experience. In order to see what any given app does, I have to either:

1. Figure it out by the name alone
2. Click each one to fetch the relevant info (and wait for it to load)
3. Mouse over each item to read the title text

People are so quick to point out the lack of interest for people (and programmers, esp.) to pay for software. If this were distributed as HTML, maybe a way to hack around this unfortunate cognitive hangup would be to frame it as If you're buying an ebook: the manual for the software. It just so happens that this manual can be interpreted by a machine.

Meanwhile, not only does the scope of this tool not merit the Big Sur requirement, it doesn't even require a Mac. It interaction style is so free of intracies that it could be developed (and distributed) as a single HTML file with a text input and some script blocks.

Around @11:16:

"What made HyperCard the ubiquitous product it was in the early 90s... was the fact that it was included free with every Macintosh sold. So anybody could use it to create somethnig, then share their creation with somebody else with the confidence that the other person would be able to run it."

So that was in that day. What is the box today?

Let me ask it another way: What is available on every computing device[...]?"

I would encourage us all to find ways to make the system immediately available to users.

#restofthefuckingowl

This tool should be a "codebook"—a downloadable document meant to be stored in an offline copy e.g. on the user's local disk, a la PDF (except still actually HTML, as here). I shouldn't need to "go to" anywhere to use it; that should only be necessary to get it the first time.

It's conceivable that people would find it overly cumbersome having to deal with this when prototyping from a REPL—enough to consider it a bad experience to keep them from trying.

A live IDE could recognize that the user probably doesn't want that to happen for a given object, since it only just appeared a little while ago, so it should offer some fixup to save time for the user.

Not the first time I've seen this sort of thing, but certainly the most egregious instance I know of. (What the hell was going on when 'hhjinks' typed that out and hit "reply"?)

I know people are really fond of this talking point, but it doesn't hold up.

if you come to work at my sandwich shop, and you show up every day to make sandwiches, and then payday comes and I stiff you, then I have definitely stolen from you.

The strongest retort to this is that this would be an instance of fraud, since in the sandwich shop we probably came to an agreement beforehand that I would pay you e.g. $15 per hour, but in the case of IP, this is incomparable because we never agreed to anything. This is pretty straightforwardly addressed by the observation that we live in a society where IP laws are in effect, so regardless of how any one person feels about IP in the abstract, we're all bound by the rules that are known at the outset. Because your decision as the creator to move forward and create the thing was predicated on an understanding that the rules are such as they are, then I actually do have an obligation to observe them just the same as my obligation not to stiff you for making my sandwiches. I don't get to start a game of Parcheesi with you under the pretense that we're going to play fair and then reveal midway through that I won't be governed by all the rules on basis that I don't believe that they're entirely justified. Fairness cannot follow from false pretense.

The one way that it would be fair would be if I made my position known from the beginning and then everyone agreed to play anyway under my augmented ruleset, but it's important to observe that the obligation lies with me. What this doesn't mean, in a society with IP laws, is that it would be sufficient for me to declare (e.g. in a manifesto posted to my blog, or in an Internet message board comment, or whispered into the night) that I don't agree with IP and then proceed to fill up on all the stuff that I'd like. What proceeding with my augmented Parcheesi ruleset looks like is disengaging from the society where IP law is in effect and moving to Russia or Shenzhen or the habitat I've set up on the edge of Schiaparelli crater.

Morrissettesque irony

I have deleted /index.html. Right now, if I visit https://crussell.ichi.city, then the server returns a 404 (but it successfully(?) gives a directory listing). This is not a problem for e.g. https://crussell.ichi.city/bookmarklets/, which similarly lacks an index.html

It would be nice to be able to have good subject lines. I'm thinking that if you register your form, then you should also be able to register a template string that can be used to build a good subject line (like "Riku key request for riku@x.colbyrussel.com"—built from Riku key request for ${email}).

It would be nice to have actual timestamps on these. The general approach is to include this as title text at least. ("At least", because I'm sure there's some semantic way to represent it, but I'm not sure what it is.)

probably don't want enumerable IDs

Maybe for new accounts, inline the manual here.

This should be a button. (GET should be idempotent and free of side effects.)

it would be nice to make this a link for easy copy and paste from the context menu. (You can use an event handler in JS to admonish the user not to click it and then cancel the event—or just copy it to the clipboard.)

Neat hack. Could be combined with something like a local (or statically hosted) yub to prevent leaking private information.

Later the industry began to call them "patterns" (cf Gabriel).

Another unanchored thought I've had on these matters is coming around to viewing namespace collision as a feature, not a bug. If a programming system is designed to allow you to link against a given module and more or less ignore any and every transitive dependency that this will bring in—because the programming environment makes it excessively easy to do so—then that's a pretty strong reason to consider whether or not that approach to information hiding is actually an anti-feature.

On the other hand, if during your work on a program you have to reconcile the names used within the system (i.e., such that no two module names collide), then it subtly encourages you to make sure you are able to account for every module that your program depends on.

People reflexively assume that this would make it cumbersome (or even intractable) to work on a program any larger than a toy, but empiraclly we can observe that a single, shared namespace can, by and large, scale way better than these protests would lead us to believe. It's not out of the question that a project might reach, say, 100kloc with very little friction arising as a consequence of this sort of forced reckoning. (And it's worth considering of the friction that it does impose: is it any worse than the costs we've observed over the last ~10 years from the systems that set out to solve this problem?)

John Nagle is fond of making the observation that there are three fundamental and recurring questions that dominate one's concerns when programming in C.

More broadly (speaking of software development generally), one of the two big frustrations I have when dealing with a foreign codebase is the simple question, "Where the hell does this type/function come from?" (esp. in C and, unfortunately, in Go, too, since the team didn't take the opportunity to fix it there when they could have...). There's something to be said for Intellisense-like smarts in IDEs, but I think the criticism of IDEs is justified. I shouldn't need an IDE just to be able to make sense of what I'm reading.

The other big frustration I often have is "Where does the program really start?" Gilad Bracha seems to really get this, from what I've understood of his descriptions about how module definitions work in Newspeak. Even though it's reviled, I think Java was really shrewd about its decisions here (and on the previous problem, too, for that matter—don't know exactly where FooBar comes from? welp, at least you can be reasonably sure that it's in a file called FooBar.java somewhere, so you can do a simple (and cheap) search across file names instead of a (slow, more expensive) full-text search). Except for static initializers, Java classes are just definitions. You don't get to have live code in the top-level scope the way you can with JS or Python or Go. As cumbersome as Java's design decision might feel like it's getting in your way when you're working on your own projects and no matter how much you hate it for making you pay the boilerplate tax, when it comes to diving in to a foreign codebase, it's great when modules are "inert". They don't get to do anything, save for changing the visibility of some symbol (e.g. the FooBar of FooBar.java). If you want to know how a program works, then you can trace the whole thing, in theory, starting from main. That's really convenient when it means you don't have to think about how something might be dependent on a loop in an arbitrary file that immediately executes on import, or any other top-level diddling (i.e. critical functionality obscured by some esoteric global mutable state).

Something happened that caused people to get mixed up about the idea–expression distinction. The single function as a module model is fine, but that doesn't justify the concrete technical decisions behind (e.g.) node_modules. The original development practice of just pasting the relevant code into your project should not have been sacrificed to satisfy the format/conventions of deficient tools. If function X is lifted from some other quasi-authoritative source, then the tools themselves should be improved to deal with that—not force humans to carve each of these modules up into their own repo, etc.

The design of the lix package manager for Haxe rests upon the right idea—taking the code into your repo mitigates "software erosion".

That's the explicit goal of triplescripts.org in its early stage—eliminating "implicit step 0" from software development.

Alan Kay at OOPSLA 1997: "It should travel with all the things that it needs".

See also: - Open Source is not enough - Actually portable executables - Package distribution is source distribution

A fork: https://www.colbyrussell.com/bookmarklets/creator.html

Worth considering why these private notes are not first-class Hypothes.is annotations already (even if not marked public)!

... assuming you're a Rubyist and you have gem and ruby installed.

Bob Nystrom is fond of avoiding LOC measurements in favor of number of semicolons.

Bad link (currently points to @chrisaldrich's profile page)

typo?

Wanderer:

You are looking for http://akkartik.name/about

Good use of XSLT to style an otherwise boring—and unfriendly—XML document (even though I dislike some of the specifics, like the font-size override).

The template is here: https://feeds.buzzsprout.com/styles.xsl

Why did we decide that every static site generator should invent their own ad hoc templating system again, instead just using XSLT, which is already standardized (and browser-native)?

A few comments: - I had no idea that Mac OS Server once upon a time supported wikis and that it was so featureful (includes blogs, too!). For everyone on HN and alike who are prone to saying that it needs to be easier to run a server for normal people, someone would do well to just outright copy the apparent experience showcased here. - The edit-mode transition (you can see it around @9:20) is simple and subtle and nice.

A substantial subset of the personal homepage contingency associated with blogging advocacy "movement" doesn't understand this.

Just like GitHub makes things a non-starter today, unless you've bought in to it the way non-technical people bought in to walled gardens like Facebook and excluded everyone else.

The Ui, for one.

GitHub's accessibility even wrt programmers leaves much to be desired for anyone who was familiar with highly productive workflow before GitHub came along and apparently handicapped everyone's ability to conceive how things could be any better.

See also vgr on tools: https://www.ribbonfarm.com/2022/02/10/tools/

You're looking for https://web.archive.org/web/20150310003402im_/http://core0.staticworld.net/images/article/2015/03/marriott-ord-booking-100571886-large.idge.jpg

"... unfortunately"

useful pattern

The web app accessible from the subscriptions page maintains persistent state (browser features are reimplemented in code-on-demand payloads), so it will suffice to invoke the bookmarklet once, and then it stays resident, even across "page" "loads". So one approach would be to have the user navigate to the subscriptions page, select the subscriptions, invoke the bookmarklet, automatically navigate to the first show, have them invoke the bookmarklet again, automatically navigate to the previous page and then to the next show, have them invoke the bookmarklet again, and repeat until we've gathered everything. This would make for on the order of N clicks, where N is the number of subscriptions.

Alternatively, it looks like the show pages are sufficiently RESTful (in the true sense), so we could just fire off a bunch of XHRs and parse the responses...

Also available at <https://archive.org/details/hartoriginal1965>.

This URL is referenced by Ted himself in his upload (to the Internet Archive) of the seminar "Hard and Fast Thoughts for a Softcopy World":

<https://archive.org/details/HardAndFastThoughts1966>

Meanwhile, a copy has already been available through IA, too:

<https://archive.org/details/nelson-file-structure>

(...albeit uploaded independently by Erica Fischer and not Ted.)

shouldn't

Also, this would be a good trick to use to realize "README.html":

If folks were really committed to improving the developer experience, [...] development would work like this: ¶1. Download the project source tree ¶2. Open README.html ¶3. Drag and drop the project source onto README.html

This is also a ripe place for the toolbench pattern to manifest.

The README can both appear to take care of the ABCs and also act as the entry point to any other shell stowed away in the project. For example, in atticus.js, the README contains a line that says to run the tests "use tests/harness.app.htm on the project repo". We could kick off the build process, open up Contribute.app.htm, squirt the contents of README.txt.htm over there, and then display that to the user, making that region "live" (so actually getting to the test runner and running the tests is even easier).

Unused.

Should have probably written "this entire section (including the preceding code block and the one that follows)".

"to speak"

"blocks containing our flavored pseudocode"

Good opportunity here for the command-posting (postMessage-based) CLI paradigm.

It's not just job postings. There are a related set of problems that should be solved here.

The best thing that could happen for jobseekers in technical roles would probably be a guerilla effort to eliminate HR and internal recruiters from the job posting →interviewing → hiring pipeline as much as possible.

What should this look like? A company that actively canvases for "leads" by talking directly to the prospective applicants' would-be coworkers and that compensates them for (a) high-quality, realistic, no-BS job postings that "route around" the fluff that comes out of the other parts of the org (b) information and involvement that leads to actual hires. By the time an application actually gets to the traditional handlers, it should be more or less a done-deal ready for being rubber-stamped.

What's the source of the money faucet here? Start with existing referral programs. Maybe ask the hiree themselves to pledge a percentage of their first X paychecks (and then help them during salary negotiation to get more from the company—e.g. sign-on bonuses—than they otherwise would have gotten themselves, so it's covered).

"outsider writing" and "out-insider writing" (e.g. Exporting Google Podcasts subscriptions)

"comprehensive codebook"?

Weird phrasing. What counterfactual is implied?

There's no real reason why Node/NPM should be required for this. You could dump the logic into a bookworms.html file and run it in the JS runtime that's already on someone's machine (their Web browser)...

A reference to the phrase "useless use of cat". See e.g. https://porkmail.org/era/unix/award.html

MarketWatch doesn't have editors?

It would be nice if people would stop saying this—and saying it like this—as if it's a badge of honor. jQuery is a fuckin' beast. 10 years ago, the reason that the browser was being brought to a crawl on any given pages often came down to the fact that it was using jQuery. jQuery is the reason that bloated frameworks became normalized and brought us to where we are today. So, enough already with this just-a-little-jQuery stuff.

Wordle's spread on social media was enabled in part by its low-tech approach for e.g. sharing scores.

One low-tech approach that could've been used here for data persistence would be to generate and prompt the user to save their latest scorecard in PDF or Word format—only it's not a PDF or Word format, but instead "wordlescore.html" file, albeit one that they are able to save to disk and double click to open all the same. When they need to update their scorecard with today's data, you use window.open to show a page that prompts the user to open their most recent scorecard (using either Ctrl+/Cmd+O, or by navigating to the place where they saved it on disk via bookmark). What's not apparent on sight alone is that their wordlescore.html also contains a JS payload as an inline script. When wordlescore.html is opened, it's able to communicate with the Wordle tab via postMessage to window.opener, request the newest data from the app, and then update wordlescore.html itself as appropriate.

these should be em dashes

Good example of developer tunnel vision and something akin to the consultant effect or Pournelle's Iron Law—the opposite of disintermediation.

I get the sense while reading this that the mentions of communities and commenters are HN and its users, just without explicitly naming either.

Sure enough, the positive examples given link to HN, which makes me think that the negative examples where links are (probably deliberately) omitted are pulled from the HN comment section, too.

No shit.

There's been so much productivity regression, esp. driven by GitHub community norms, that it's exasperating to watch.

I think PG is equivocating on "writing" here.

So the thesis is tautologically true—and a lot less insightful. We're talking about thinking here.

Simple disagree, but maybe we're not watching the same movies.

The disconnect between the efficiency of explaining versus doing is real.

I don't understand what this means right now.

I agree that we should not regard the conventional understanding as true—in the sense of treating it as always true. But I disagree with the suggestion of this piece, which is that it is never true.

We shouldn't conclude too much from the existence of "broken" versions that were discarded. Much of the manufacture of clarity that comes out of writing is really just a consequence of putting it down in a way that is accessible to other people (probably, as PG says here, as a result of multiple revisions), but it's not necessary for firsthand understanding. Suppose I write some code, and it is correct. Later, I revise it to be clearer to a wandering party. This takes work, but have I accomplished anything with respect to what PG is saying here? Did I, when originally setting out to put it into a fixed form, find that my understanding was lacking and have to confront this and then only after reconciling the issue truly understand it—whereas I didn't before? No. It was correct before, and it's not more correct now; it's possible that I understood it perfectly well, I just didn't understand how to better explain it to others.

Additionally, on the topic of fully formedness, when I write, a possible outcome is that the result is an incomplete snapshot (a less fully formed version) of the full version in my head. Writing is almost always IO-bound.

cf Carl Sagan as Mr. X, and Ted Nelson on nonlinear structure.

No. Counterexample: "it turns out". And I've run into my share of pithy HN comments conveying some choice heavy-lifting thought terminator. The simple writing in these instances is usually employed to cover up dishonesty—for the same reason that Mencken's quip about non-solutions that are "neat, plausible, and wrong" is often transformed to additionally characterize the offending offer as "simple"—because people know how effective a helper simplicity is to duplicity.

AIUI, your account's contribution graph and feed are still public, not private, without a way to opt out—just like on GitHub.

So Gitea—or Codeberg, at least—should be amenable to the suggestion of un-messing the process of self-hosting where it brings the aspiring self-hoster into contact with NodeJS/NPM silliness. Make that part optional.

But, notably, you can't assume their availability, due to touch-based devices.

More specifically, never changes anything in a way that causes breakage. (Platforms that change in a way that is merely cumulative are not a problem.)

Counterintuitively, this is probably not the correct course of action. Related: https://hypothes.is/a/cd4J-uM1EeuKF1NB5CRzbQ

The role of Python and how hard it's pushed on researchers is something people need to get realistic about.

Disagree. Sounds plenty bad.

Do you need an exploration tool to find your way through unfamiliar stories (e.g. books, films)?

Geez.

Try https://github.com/rgx1/FediRenderer, traveler.

But maybe you don't need to do that. Maybe it would be instructive to take lessons from the traditional (pre-digital) publishing industry and consider how things like "print runs" and "reissues" factored in.

If you write a blog post in 2017 and the page is acceptable*, and then five years later you're publishing a new post today in 2022 under new design norms and trying to retrofit that design onto your content from 2017, then that sounds a lot like a reprint. If that makes sense and you want to go ahead and do that, then fair enough, but perhaps first consider whether it does make sense. Again, that's what you're doing—every time you go for a visual refresh, it's akin to doing a new run for your entire corpus. In the print industry (even the glossy ones where striking a chord visually was and is something considered to merit a lot of attention), publishers didn't run around snapping up old copies and replacing them with new ones. "The Web is different", you might say, but is it? Perhaps the friction experienced here—involved with the purported need to pick up a static site generator and set your content consistently with templates—is actually the result of fighting against the natural state of even the digital medium?

* ... and if you wrote a blog post in 2017 and the page is not acceptable now in 2022, maybe it's worth considering whether it was ever really acceptable—and whether the design decisions you're making in 2022 will prove to be similarly unacceptable in time (and whether you should just figure out the thing where that wouldn't be the case, and instead start doing that immediately).

Useful term. Consider: "antimodern computing" in general or more specifically: "antimodern software engineering", "antimodern Web design", "antimodern deployment strategy", etc.

If you can't imagine how stuff like this would be possible, "then", as Roy Fielding quipped, "most likely you just haven’t defined enough resources".

In principle, this data is the sort of thing I'd expect to be available from Google Takeout. It's not. All right, fine. But then, it's the sort of thing I'd expect to have its API documented so sufficiently motivated people can bodge together their own "client"—something similar to the availability of the Google Books APIs. This, too, is missing. I don't expect the appearance of either, at least not any time soon.

Lots of people forget (or were never conscious of) the bent that the US went on around this time (post 9/11).

A lot of people can look at an artifact of that era like Idiocracy and think, "HAHA OMG SO TRUE" while thinking of how the world feels right now. But that's a mistake. Idiocracy in particular was a response to what it felt like at the time the movie was made. There are lessons, sure, but any time you try to interpret the past in terms of the present, you're going to miss some things.

Anti-intellectualism in the US at the time of this interview was nuts, and the way things are right now doesn't even come close.

You could say the same thing about Oberon (which funnily enough was directly inspired by PARC's work).

See You Can't Tell People Anything.

Personal observation: Cut has always struck me as a more exotic operation than the sense you seem to get about it hearing folks who were in computing prior to the 1990s speak. As far as I know, almost everyone I've encountered probably thinks foremost of "copy and paste".

https://archive.org/details/DTCJefRaskinDoc019

should be "than"

This response is pretty evasive. It's true, but (a) Raskin's name was changed from his original birthname, and (b) it doesn't answer the question that was asked. (It's a response to a question/statement that wasn't asked.)

See also Seven Laws of Sane Personal Computing (with particular attention to Law III).

Hey, sounds a lot like the approach to Firefox UI decisions circa 2010.

should be "limits"

should be "Engelbart"

I like this distinction—"new world" smartphones vs "old world" smartphones.

double lame

lame

That's not what they are.

Suppose the server were sending rel=canonical in a Link header for non-document resources (e.g. images like this one). Is the Hypothesis bookmarklet/extension thorough enough to deal with this?

This is a common enough feeling (not about Publii, specifically; just the general concern for flexibility and control in static site generators), but when you pull back and think in terms of normalcy and import, it's another example of how most of what you read on the internet is written by insane people.

Almost no one submitting a paper for an assignment or to a conference cares about styling the way that the users of static site generators (or other web content publishing pipelines) do. Almost no one sending an email worries about that sort of thing, either. (The people sending emails who do care a lot about it are usually doing email campaigns, and not normal people carrying out normal correspondence.) No one publishing a comment in the thread here—or a comment or post to Reddit—cares about these things like this, nor does anyone care as much when they're posting on Facebook.

Somehow, though, when it comes to personal Web sites, including blogs, it's MySpace all over again. Visual accoutrement gets pushed to the foreground, with emphasis on the form of expression itself, often with little relative care for the actual content (e.g. whether they're actually expressing anything interesting, or whether they're being held back from expressing something worthwhile by these meta-concerns that wouldn't even register if happening over a different medium).

When it comes to the Web, most instances of concern for the visual aesthetic of one's own work are distractions. It might even be prudent to consider those concerns to be a trap.

Same as https://www.geoffreylitt.com/images/computing-books.jpg?1643577208.

(There are relevant annotations there.)

Need to take the union of all these papers' bibliographic entries and dump them here.

staticgen source: https://github.com/geoffreylitt/homepage/tree/master/source/wildcard

I've spent a lot of time in frustrated conversations arguing the case for browser extensions being treated as a first class concern by browser makers (well, one browser maker). But more and more, I've come to settle on the conclusion that any browser extension of the sort that Wildcard is should also come with the option of using it (or possibly a stripped down version) as a bookmarklet, or a separate tool that can process offline data—no special permissions needed.

(This isn't because I was wrong about browser extensions; it's precisely because extension APIs were drastically limited that this becomes a rational approach.)

Referenced from https://www.geoffreylitt.com/inspirations.html

on top stacked laying flat on the left side, next to a potted plant on the right two other books to the right of the plant, spines not visible

tools for thought rheingold MIT Press logo concept design: the essence of software jackson designing constructionist futures nathan holbert, matthew berland, and yasmin b. kafai, editors MIT Press logo structure and interpretation of computer programs second edition abelson and sussman MIT Press Indroduction to the theory of computation

top shelf ordinary orientation: books upright, spines facing out tops leaning to the left

toward a theory of instruction bruner belknap / harvard tools for conviviality ivan illich harper & row the human interface raskin addison wesley the design of everyday things don norman basic books changing minds disessa MIT Press logo mindstorms seymour papert unknown logo understanding computers and cognition winograd and flores addison wesley software abstraction jackson revised edition MIT Press logo living with complexity norman MIT Press logo the art of doing science and engineering—learning to learn richard w. hamming stripe press logo the computer boys take over ensmenger recoding gender abbate MIT Press logo weaving the web tim berners-lee harper dealers of lightning: xerox parc and the dawn of the computer age michael a hiltik harper the dream machine m. mitchell waldrop stripe press logo from counterculture to cyberculture fred turner chicago the innovators walter isaacson simon & schuster paperbacks a people's history of computing in the united states joy lisi rankin harvard the media lab stewart brand penguin logo

bottom shelf ordinary orientation: books upright, spines facing out tops leaning to the right

about face: the essentials of interaction design cooper, reimann, cronin, noessel 4th edition wiley the new media reader wardrip, fruin, and montfort, editors designing interactions bill moggridge includes DVD MIT Press logo interactive programming environments barstow, shrobe, sanderwall mcgraw hill visual programming shu software visualization editors: stasko, domingue, brown, price MIT Press logo types and programming languages pierce MIT Press logo smalltalk-80: the interactive programming environment goldberg addison wesley constructing the user... statecharts qa 76.9 .u83 h66 1999 the human use of human beings: cybernetics and society wiener da capo pasteur's quadrant stokes brookings scientific freedom: the elixir of civilization donald w. braben stripe press logo a pattern language alexander, ishikawa, silverstein, jacobson, fiksdahl-king, angel oxford the timeless way of building alexander oxford

Not accessible.

Yes. From https://news.ycombinator.com/item?id=22991437:

Despite how toxic it is, Twitter is very simple: get account, follow a few people, and you get a text field where you can write stuff, hit "Publish", and you can reach your audience.

Since "blog" is too opaque today, even with reminders like this, maybe the pro-blogging movement (that is, from the Latin pro; not as in "professional") should re-orient itself and take up a campaign around the phrase "lab log".

Likewise, I wish reading an academic paper were more often like reading a blog post where they explain their work—most academics suck at academic writing! As a result, getting through the paper is usually tedious.

Shouldn't this parenthetical be written, if anything, as "academics (including students)"?

I don't think we'd get this at all, and I think that's the real takeaway from YAGNI: most people are really bad at figuring out what they're "gonna need". If they weren't, then the phrase wouldn't exist.

The truth notwithstanding about whether or not they'd be right if they felt that way, I'm not sure it's accurate to say that this feeling actually exists. Certainly the the way people speak about new tech and the rationalizations that they reach for when adopting something new suggests that they think the thing that they're transitioning to is going to be the right one this time.

Mmm... those devices are getting faster and gaining new powers, not gradually shedding either...

Yeah, but...

Keeping your website's look 'up to date' requires changes, but keeping your website up does not require "keeping its look 'up to date'".

The problem almost certainly starts with the conception of what we're doing as "building websites".

When we do so, we mindset of working on systems

If your systems work compromises the artifacts then it's not good work

This is part of a broader phenomenon, which is that when computers are involved with absolutely anything people seem to lose their minds good sensibilities just go out the window

low expectations from everyone everyone is so used to excusing bad work

sui generis medium

violates the principle of least power

what we should be doing when grappling with the online publishing problem—which is what this is; that's all it is—is, instead of thinking in terms of working on systems, thinking about this stuff in such a way that we never lose sight of the basics; the thing that we aspire to do when we want to put together a website is to deal in

documents and their issuing authority

That is, a piece of content and its name (the name is a qualified name that we recognize as valid only when the publisher has the relevant authority for that name, determined by its prefix; URLs)

that's it that's all a Web site is

anything else is auxiliary

really not a lot different from what goes on when you publish a book take a manuscript through final revisions for publication and then get an ISBN issued for it

so the problem comes from the industry

people "building websites" like politicians doing bad work and then their constituents not holding them accountable because that's not how politics works you don't get held accountable for doing bad work

so the thing to do is to recognize that if we're thinking about "websites" from any other position things that technical people try to steer us in the direction of like selecting a particular system and then propping it up and how to interact with a given system to convince it to do the thing we want it to do— then we're doing it wrong

we're creating content and then giving it a name

If we define its success by quality of discussion, I think it has also failed. My interactions on Mastodon have almost universally resulted in experiences that were worse than a typical HN interaction (already not great!), for example. About on par with what you've always been able to find in places like /r/programming or Keybase chat or IRC—ostensible nerds memetically regurgitating low-effort cynical takes and being hostile to outsiders who haven't yet sufficiently ingratiated themselves to the community. Very little diversity of thought or norms of interaction.

So how about a voluntary breakup? Something that the unfederated networks would never do unless trying to avoid being the target of litigation for anti-competitive practices, but where is the pressure to refrain from doing this for mastodon.social or anywhere else in the fediverse?

Backend for Backblaze's B2 suspiciously absent.

That's the problem—thinking about this in terms of "wanting software". It's wanting to publish. Tech workers have an especially hard time understanding this.

You're probably not under the impression that when the last person you heard of who got their book published finally pulled it off, they did it as a matter of wanting, say, an InDesign workflow versus something else. Because they weren't, and it didn't factor into their motivations at all—not even a little bit.

This page is useful, but it needs footnotes citing the relevant standards.

Consider a "man2blog" — combining several things:

• a publication pipeline/authoring tools combo that is effected by copying the tool's manual somewhere, where the manual includes, like here in ANPD, an exact (machine executable) specification of its behavior
• the plain.txt.htm format https://www.colbyrussell.com/LP/debut/plain.txt.htm

So the steps look like:

1. Clone the repo, which is empty except for a lone "README.txt"
2. Write your blog post(s) as markdown and commit to the repo
3. Upload a copy of README.txt to your web host, except name it man2blog.txt.htm instead
4. Visit the URL for your copy of man2blog.txt.htm in your web browser
5. Press Ctrl+Enter
6. Feed in the sources to your blog

You could also include in the text of README.txt aka man2blog.txt.htm instructions for how to author an "adapter" for your web host, so that when man2blog.txt.htm finishes processing your input, it transfers control to the adapter, which handles automatically uploading the build artifacts. (The adapter should, of course, also live as a first-class piece—i.e., content—on your site, too, the way that ANPD explains it.)

Name chosen as a nod to the use of Template:Should be SVG on Wikipedia