記事をPicture-in-Pictureで読めるようにしてみた | stin's Blog
Document Picture-in-Picture APIというWeb APIがあります。まだブラウザの実装が限定的ですが、Chromeなら116から使えるようです。 Picture in Picture(以下PiP)と言えば、動画を再生しながら別のタブを開いたり別のアプリケーションを開いたりできる機能ですが、"Document" Picture-in-PictureはそれをHTML要素でも可能にするAPIです。最近Google MeetがこのAPIを使い始めて、別タブに移動したタイミングで勝手にPiPを表示するようになりました。なんか賛否あった気がしたけど僕は便利に使っています。決してミーティングに集中していないわけではないです、えぇ。 このブログサイトでも、Document Picture-in-Picture APIを使って記事をPiPで読めるようにしてみました。APIをサポート
GitHub - hashicorp-forge/hermes: A document management system
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.
Design Tokens Format Module 2025.10
Design Tokens Format Module 2025.10 Draft Community Group Report 18 January 2026 Latest published version: https://www.designtokens.org/TR/2025.10/format/ Editors: Louis Chenais Kathleen McMahon Drew Powers Matthew Ström-Awn Donna Vitan Authors: Daniel Banks Mike Kamminga Ayesha Mazrana (Mazumdar) James Nash Adekunle Oduye Kevin Powell Feedback: GitHub design-tokens/community-group (pull requests,
How Stripe builds interactive docs with Markdoc
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
【メモ】良いDesign Docs(Software Design Document)を書くためのリソース集
自分が良い Design Docs(Software Design Document)を書くために、読んだ/参考になったリソース集 一覧 Design Docs とは Design Docs at Google デザインドック(Design Doc)について デザインドックで学ぶデザインドック 残業も減らせる!? 上級エンジニアになるための Design Doc 超入門 「Design Doc」って何なのか？ What Is A Design Doc In Software Engineering? (full example) What is a Design Doc: Software Engineering Best Practice #1 https://github.com/kaiinui/note/blob/master/Design--Designdoc.md Googleの
Open API × Rails × TypeScriptでのスキーマ駆動開発｜Offers Tech Blog
プロダクト開発人材の副業転職プラットフォーム Offers を開発している、株式会社 overflow にて EM をやっております磯崎と申します。 日々プロダクトを開発している中で、様々な格闘があるかと思いますが、その中でも大分格闘してきた Open API を用いたスキーマ駆動開発について今回は書いてます。 この構成で運用してよかったと今のところは思ってますが、色々面倒な事や落とし穴にも直面してきました。自分たちの中に溜まっている知識を書き記していくのでどこかでお役に立てればハッピーです ☺️ 最初に API を定義、その後開発を進めていくスキーマ駆動開発 そもそもスキーマ駆動開発とは、はじめに API を定義し、それを元にフロントエンド・バックエンドと開発を同時に進めていく開発フローです。 フロント実装においては通信部分で、「何を送信すべきか」、「何が返ってくるのか」を予め決まった状
GitLabで学んだ最高の働き方 Developers Summit 2022-02-18
Page Scrolling Vertical Scrolling Horizontal Scrolling Wrapped Scrolling
API Improvement Proposals
Welcome AIPs are design documents that summarize Google's API design decisions. They also provide a framework and system for others to document their own API design rules and practices. AIPs are a combination of design guidance and a system we use to manage and track that guidance. Learn more about how the AIP program works in the first AIP!
Material for MkDocs
Documentation that simply works Write your documentation in Markdown and create a professional static site in minutes – searchable, customizable, in 60+ languages, for all devices. Get started Learn more It's just Markdown Focus on the content of your documentation and create a professional static site in minutes. No need to know HTML, CSS or JavaScript – let Material for MkDocs do the heavy lifti
2020年上半期に公開されたセキュリティ関連文書まとめ - トリコロールな猫/セキュリティ
リアルタイムには情報を追っておらず、お知らせ一覧等から調べているため抜けがあるかもしれません。 ルールは以下。 公共性の高いものを載せています WGや研究会の純粋な活動報告書、個別のインシデント・脆弱性は載せていません 情報源はこの辺。 security.nekotricolor.com 政府機関 経済産業省 エネルギー・リソース・アグリゲーション・ビジネスに関するサイバーセキュリティガイドライン 2019/12/27 総務省 文書タイトル 公開日 我が国のサイバーセキュリティ強化に向け速やかに取り組むべき事項(緊急提言) 2020/01/28 IoT・5Gセキュリティ総合対策 プログレスレポート2020 2020/05/22 Wi-Fi利用者向け 簡易マニュアル（令和2年5月版） 2020/05/29 Wi-Fi提供者向け セキュリティ対策の手引き（令和2年5月版） 2020/05/29
設計書には何を書くべきなのか - terurouメモ
設計とは、 要求（やりたいこと）をヒアリングする 要求を要件（何を満たさないといけないのか）に落とし込む 要件を実現するために考えられる手段を洗い出す 手段の検証を行う 検証結果を元に、どの手段を使うかを選定する 選定した手段を合意する（一部要件を満たさない事項がある場合は、代替策や妥協ラインについても合意する） 合意内容を元に、実装や設定に落とし込む をやることである。画面設計や機能設計のように、3-5の検証/選定が薄くなったり曖昧になったりするものはあるが、一般化するとこの流れになる。 設計書には、上記の設計でやってきたことを順番に書いていけばよい。これを文章構成のテンプレに落としていくと、 要求 要件 方式 対応案（いわゆる比較表で書いていくのが楽） 検証結果 選定・合意結果（合意した代替策や妥協ラインについても記載する） 詳細設計（どういう実装にするとか、パラメーターにするとか、細
Design Docs at Google
One of the key elements of Google's software engineering culture is the use of design docs for defining software designs. These are relatively informal documents that the primary author or authors of a software system or application create before they embark on the coding project. The design doc documents the high level implementation strategy and key design decisions with emphasis on the trade-of
TSDoc を書きたい & TSDoc で使えるタグ一覧 - ぽ靴な缶
いつも TypeScript 書いてるんですよ、そしたら function の前にコメント書くじゃないですか、/** ... */ で書いてるけど正直のところ中身は勘で書いている。@returns や @deprecated とかよく見るし、雰囲気で使っているけど、本来なんのタグが使えるかあんまり誰も分かってない。補完のときに表示されてラッキーぐらいの感覚。でも謎のタグを使ってるの見たら気になるし、今 TypeDoc でドキュメント生成していなくても、標準的なフォーマットがあるなら従っておきたいじゃん。そして TSDoc でインターネットを検索しても、こう書けばいいみたいな記事がすぐ見つからねぇ〜〜 まだ標準は無い リポジトリ見に行く microsoft/tsdoc: A doc comment standard for the TypeScript language ふむふむ、現行の多く
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - hackergrrl/art-of-readme: :love_letter: Things I've learned about writing good READMEs.
GitHub - sourcegraph/doctree: First-class library documentation for every language (based on tree-sitter), with symbol search & more. Lightweight single binary, run locally or self-host. Surfaces usage examples via Sourcegraph.
React
GitHub - docuowl/docuowl: 🦉 A documentation generator