#documentation

17 bookmarks tagged with #documentation · RSS Feed · ← All Tags

Kevin Webb: "One of the best examples of LLM developer tooling I've heard is from a team that supports software from the 80s-90s...."

https://bsky.app/profile/triangulator.org/post/3lqqgkkst2k2r
One of the best examples of LLM developer tooling I've heard is from a team that supports software from the 80s-90s. Their only source of documentation is *video interviews* with retired employees. So they feed them into transcription software and get summarized searchable notes out the other end.

GitHub Pages

http://pages.github.com
GitHub Pages are hosted for free and easily published through our site, the GitHub for Mac app, or from the command line. Manage your site’s content from GitHub using the tools and workflow that you’re familiar with. Learn about publishing with GitHub Pages here.

Documentation/HowTo - OpenStack

https://wiki.openstack.org/wiki/Documentation/HowTo#First-time_Contributors
At the core of OpenStack is the community and collaboration that we do - the same rules for the code apply to documentation too. Ideally any code contribution that is merged into the base has documentation to go with it. Anne Gentle is the coordinator for all documentation efforts, both community-based and "official" docs. This page describes the methods we use to create the basis for world-class documentation for OpenStack developers and users.

Events/live - jQuery JavaScript Library

http://docs.jquery.com/Events/live
"When you bind a "live" event it will bind to all current and future elements on the page (using event delegation). For example if you bound a live click to all "li" elements on the page then added another li at a later time - that click event would continue to work for the new element (this is not the case with bind which must be re-bound on all new elements). "

Quetzalcoatal: A public service announcement

http://quetzalcoatal.blogspot.com/2008/11/public-service-announcement.html
"If your code will be seen by the world at large, one of your first tasks should be to write documentation. Document all functions as soon as you write them (before is also helpful). Provide samples on how to use code as soon as you finish a module (or earlier, if possible). Do not wait until your 5.0 release. Do not wait until your 1.0 release. Do not even wait until your 0.5 release. Do it as you write your code. The sooner, the better."

xml2rfc

http://xml.resource.org
"take your XML source (using the format defined in RFC 2629 and its unofficial successor) and see how the results look like in the original ASCII look-and-feel or the new modern HTML rendition of that look-and-feel."