Suddenly Remote # Suddenly changing how an entire organization works is very disruptive and suddenly being unable to share space is a novel problem. Most disaster recovery plans and business continuity plans lack aspects of continuing to work when you can’t be co-located with co-workers. See https://allremote.info for more information. Handbook Template # A suggestion for many companies finding th
Whether you’re learning a new library or API or you’ve been using it for years, it can feel like the documentation gets in your way more than it helps. Maybe the tutorials are too basic, or the reference manual is too sketchy, or the relevant information is split across multiple pages full of irrelevant details. We’re exploring a way to get you the information you need, faster. By surfacing the mo
Sign up for a Google Workspace account. Create a Google Cloud project. Enable the following APIs for Google Workspace APIs Admin SDK API (optional, if enabling Google Groups as document approvers) Google Docs API Google Drive API Gmail API People API Also, to enable searching for users, the Google Workspace domain admin needs to enable external directory sharing. See more details: https://support.
GitHub - Shopify/graphql-design-tutorial
This tutorial was originally created by Shopify for internal purposes. We've created a public version of it since we think it's useful to anyone creating a GraphQL API. It's based on lessons learned from creating and evolving production schemas at Shopify over almost 3 years. The tutorial has evolved and will continue to change in the future so nothing is set in stone. We believe these design guid
At Stripe, our product docs are designed to feel like an application rather than a traditional user manual. For example, we incorporate a user's own API test key into code samples, making it possible to copy and paste code that seamlessly works with the user's own account. We have client-side interactivity, like checklists and collapsible sections. We tailor the content to the individual user, con
VS Code の拡張作っている際に CHANGELOG.md が自動生成され、書き方はKeep a Changelogに従えと書かれていたので紹介する。 ここに書かれていることは絶対ではなくただ提案しているだけである。意見がある人は話し合おうという温度感っぽいので、納得いかない場合は issue 立てると良いと思う。 僕自身はなんでもよくてある程度型が欲しかっただけなのでこれからはこれに従って書いていこうと思う。ただまぁ Semantic Versioning もそうだけどちゃんと従おうとすると以上にだるくなってくるので雰囲気従うくらいだと思う。 CHANGELOG の原則 機械的に生成するのではなく人間の手で書く 各セクションへのリンクが容易にできる 1つのバージョンごとに1つのサブセクションを作る リリースは新しいものが上に来るようにする 日付のフォーマットは YYYY-MM-DD
Some recent experiences have prompted me to rethink the value of treating docs like code in some respects. I want to return to focusing more on content rather than technical workflows, especially when creating new content. Some of the docs-like-code processes exclude too many people in non-engineer roles who would otherwise contribute to the review and development of the content. “Prose like prose
RFCs - requests for comment - or Design Docs are a common tool that engineering teams use to build software faster, by clarifying assumptions and circulating plans earlier. There are some similarities between writing automated tests for your code, and writing RFCs before you start working on a non-trivial project: Software engineers who write tests for their code - and ask for code reviews on it -
Googleでの「Design Docs」とは 2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1～2週間をかけて書く」ものです。 今回は Google のソフトウェアエンジニアである @cramforce 氏が自身のブログで「Googleでの Design Docs」について解説している記事を公開されていたため、氏の許可を得て翻訳しています。 原文： www.industrialempathy.com 関連書籍： Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 読了目安：11分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
1月がまるっとスキップされている... だと...。 hisaichi5518.hatenablog.jp id:hisaichi5518 さんがこういうことを書いていて、非常にわかりみがあった。 一方で、Notionというツールはそこまですごい銀の弾丸ではないというか、得意な分野と無理に使っても旨味がない分野/工夫しないと使えない分野が結構極端にあるような気がしていて、とりあえず僕は僕で雑な感想を残しておこうと思った。 個人の日記レベルですが。 今までの経験で、 Notion が効果を発揮する箇所 日記、日報 雑に書き始める、更新できる、コメントできるのがいい。リストとの相性もいい timesチャンネルみたいなやつはNotionで運用した方が本当はいいのかも 物理的なカンバンの代わり 融通無碍に書き込める、メタ情報を融通無碍に追加できる、というのは、物理的な看板を融通無碍にレイアウトした
Notionでドキュメントを書いてる。ドキュメントは書く、共有する、読むなどユーザーそれぞれ色々なシナリオがあり、そのシナリオそれぞれでつらみがある。 Notionに限らずすべてのサービスは使っていればつらいところはあると思っていて、つらいとはいえNotionから別のドキュメント管理サービスに乗り換えたいという気持ちは全くなく何がつらいのか考えNotionでなにか出来ることはないか考えたり、つらみを共有することで知見を得たい。 検索がつらい フロー型とストック型の情報が入り乱れる 検索をする時はストック型の情報を探すことが多い。例えば、リリース作業手順ドキュメントを探したいときに「リリース 作業 手順」で検索するけど日報や議事録などは検索から除外したい。 Notionの検索には、FilterでPageの指定が出来るのでそれを駆使するしかない。Pageの指定をした場合、Pageの配下は検索対
InfimaA modern styling framework for content-driven websites 🔥
本書『サバイバルTypeScript』は実務でTypeScriptを使う開発者のための入門書です。そして、このページはTypeScriptの特徴を最速で把握できるよう、数百ページからなる本書のコンテンツをつまみ食いした要約です。 » 本書について詳しく知る » とにかく今すぐTypeScriptを書いてみたい TypeScriptとはJavaScriptのスーパーセットとなるプログラミング言語。静的型付け言語であり、プログラムの正しさが静的に検査できる。ライブラリやIDEなどの開発環境が充実しており、大きなエコシステムを持っている。Microsoftが2012年に開発し、オープンソースで公開した。» TypeScriptの特徴について詳しく知る » TypeScript誕生の背景について詳しく知る TypeScriptはJavaScriptのスーパーセットスーパーセットとは、元の言語と
After a lengthy alpha stage in order to ensure feature parity and quality, we are excited to officially release the first Docusaurus 2 beta. With the announcement of this beta, the team is even more confident that Docusaurus 2 is ready for mainstream adoption! Docusaurus adoption Don't fear the beta tag! Docusaurus 2 is widely adopted and growing fast: To get a fuller understanding of the quality
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
