本記事の要約 ドキュメントを書かない事は、企業やチームの「負債」になる ドキュメントを書かない事は、自身の学びや振り返りの「機会損失」になる そういう文化が根付く前に、負の連鎖を断ち切ろう！ はじめに 世の中のプロジェクトには、ドキュメントが足りていない、と感じています。 でも残念な事に、ドキュメントをどうしても書きたい人は「ほとんどいない」と思います。 その一方で「ドキュメントを書いた方が良い」という事は、 何となく分かっている人も多いと思います。 やりたくない事をやらなければならないのは、嫌ですよね。 そんな気持ちは分かりますが、これを機に一度改めてみませんか。 何故なら、ドキュメントを書かない事はチームに「負債」を生むからです。 勤め人ならば少なからず一度でも、体験した事があると思います。 「どうして必要な過去の資料が無いんだ」って。 あるはずの歴史の一端がソースコードからしか分から
むかし、この国が深い森におおわれ、そこに太古からの神々がすんでいた頃から語り尽くされているドキュメントが更新されない問題について雑に書く。 実態が変わったのにドキュメントが更新されない問題はいつどの時代も絶えない。これにいちいち憤りを感じるのは不幸になるだけなので、何かしら対処を考えておかねばならない。パッと思いつくのは次のようなものだろうか。 使う 使わないから更新もされなくなる。定期的に使われるように設計して、そもそも使わない場合は消した方がいい いっそ参照回数が少ないドキュメントは自動でアーカイブしちゃうみたいな硬派なスタイルの方がいいのかも 詳細に書きすぎない 細かいところを書きすぎると保守できない。骨組みだけ大事にして、細かいところはフロー情報として分けて書くのがよい 管理者を置く ちゃんと更新されるようロールを作る。属人化しないようにロールを引き継ぐ設計も必要 個人的にはあんま
システム構成図やシーケンス図を描くとき、「どのツールを使えばいいの？」 と悩んでいませんか？ draw.io、PlantUML、Mermaid、FigJam...選択肢が多すぎて、結局いつも同じツールに逃げてしまう。でも本当にそれでいいのか不安。 この記事では、実際のエンジニアたちが使っているツールと、その選び方を徹底的にまとめました。 ▼ガッシーさんのツイート に集まった情報を参考に記載させてもらっています。デザイナー、プログラマー、エンジニア、経営層と様々な方がリアクションされていたので、みんな悩んでいるんだな…わかるぞ…と思い、しれっとまとめさせてもらいました。私も個人的にめっちゃ悩んでいたので。問題があれば削除しますのでご安心ください。 人気の図形描画・作図ツール徹底比較 1. draw.io (diagrams.net) - 最多回答の万能ツール 完全無料で高機能、幅広い用途に対
この記事は？ 株式会社ログラスでクラウドインフラエンジニアをしている中井 (@elmodev09) です。 エンジニアとして働ていると、技術選定の調査結果をまとめたり、Design Docを書く等、ドキュメントを書く機会が多いのではないでしょうか？ ドキュメントは、不必要なディスカッションを減らすための非常に強力なツールです。 特に、抽象度が高いタスクにおいては、ドキュメントをうまく活用することで議論のポイントを明確化し、効率化を図ることができます。 個人的な話になりますが、これまでに書いたドキュメントについて、「分かりやすい」「読みやすい」と言っていただけることが多いです。 （もちろん、毎回そうではなく、分かりにくい場合もありますが） 私は口頭で全てを明確に説明するのが得意な方ではないため、思考を整理してドキュメントにまとめることで、なんとかエンジニアとしての業務をこなしています。 今回
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
この記事について Go言語公式から提供されているThe Go Programming Language Specificationという文章があります。 実際のThe Go Programming Language Specificationのページ画面 この文章、個人的にはじっくり読んでみると結構得るものが大きいな、と感じるものです。本記事では The Go Programming Language Specificationって何が書いてあるの？ 読んだら何がわかるの？ 読むときにはどういうところに注目したらいいの？ 英語難しいから単語教えて！ という疑問に答えながら、The Go Programming Language Specification精読の布教を行います。 The Go Programming Language Specification とは？ The Go Prog
背景 開発チームが抱えるよくある課題として システムが変化する一方でドキュメントは更新されず腐る メンバーの流入出によって口伝でかろうじて継承された知見も失われる 検索性が良くないと過去のドキュメントが気づかれず、同じような内容のドキュメントが新規量産される 後から参加したメンバーはどちらが正のドキュメントか分からず混乱する といったことが良くあります。 解決方法としては以下のように、GitHub＆ルールベースで管理するといった例があります。 future-architect.github.io また組織・システムが大きくなってくると認知負荷を低減するためにドメインで区切るような形でチームの分割が始まりますが、 異なるチームによってシステムが管理され、システムの依存関係を全て知っている人がいなくなる CxOレイヤが大規模イベント前に現状を把握したいときに都度時間がかかってしまう チームごと
最近知った興味深いPodcast e34.fm で紹介されていたので興味を持って読んでみた本「Docs for Developers: An Engineer’s Field Guide to Technical Writing」に関するメモ。 2023/3追記：翻訳されたようだ。ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング e34.fmwww.oreilly.com この記事の目次 「Docs for Developers」はどんな本なのか 全般的な感想 各章に関する覚え書き Front Matter Chap 1. Understanding your audience Chap 2. Planning your documentation Chap 3. Drafting documentation Chap 4. Editing docum
はじめに こんにちは。カミナシでソフトウェアエンジニアをしている佐藤です。 みなさんは、アプリケーションのフロントエンドから、Amazon S3 にファイルをアップロードするときに、どのような方法を用いているでしょうか？ 「バックエンドのサーバーにファイルを送信し、バックエンドのサーバー経由で S3 にアップロードしている」「Presigned URL を払い出して、フロントエンドから直接 PUT している」など、いくつかの方法があると思います。 弊社で提供しているサービス「カミナシレポート」でも、用途に応じて上記の方法を使い分けて S3 へのファイルのアップロードを行っています。 特に、Presigned URL は、手軽に利用できる上に、バックエンドのサーバーの負荷やレイテンシーの削減といったメリットも大きく、重宝しています。 一方で、その手軽さの反面、アップロードに際して様々な制約を
はじめに 今回の記事では、学習や実務でGraphQLを活用する人を対象に、GraphQLの全体像を把握するためのチュートリアル記事になる。本記事の対象読者は以下の通りである。 GraphQLの全体像を把握したい人 公式ドキュメントの理解で苦しんでいる人 GraphQLとは GraphQLはWeb APIを開発するためのクエリ言語である。REST APIの問題を解決するために、Facebook(Meta)によって開発された。Web APIの開発において、REST APIと比較して柔軟かつ効率的なアプローチを提供できる。さらに、GraphQLではクライアントが必要なデータの構造を定義することができ、サーバから定義したものと同じ構造のデータが返される。 詳細は後述するが、GraphQL最大の特徴は必要以上に大きなデータが返されることを防ぐことにある。これによって、GraphQLは必要最低限のリク
こんにちは。テクノロジー本部のyoshikawaです。好きなW3C Recommendation は RDF 1.1 Concepts and Abstract Syntax です。 会議やチャットでのやり取りの決定事項・議事録、アプリケーションや機能の設計書・仕様書、READMEなどなど... LIFULLの開発現場においては、ソースコード以外にもこのように様々な文書の管理・蓄積(=ドキュメンテーション)を実施しています。 多くの開発者・メンバーがドキュメンテーションの重要性やその恩恵は理解はしているものの、なかなかうまく情報の蓄積・管理ができない、 その結果、本質的ではない調査に時間を取られてしまいDeveloper Experienceが下落してしまう。 このような課題を抱えているプロジェクトやチームは世の開発現場において少なからず存在すると思います。 LIFULLの開発現場にもこの
2020年に「コミットログは良くならない」というのを悟ったので、現実的な解決案である「git-notesでメモを残す」について記事を書いておきます。 前回の記事 sinsoku.hatenablog.com git-notes 詳細は git notes --help を読んでください。 概要は以下の通りです。 コミットログとは別にメモを残せる コミットはそのままなのでshaは変わらない shaが変わらないのでCIの再実行が起きない 他人のコミットにメモをつけられる 他人に作業を依頼する必要がない メモもリモートにプッシュできる 過去のコミットにメモを残せる 使い方 メモを書く git notes edit <sha> でメモを書くと、git log のときに一緒に表示される。 $ git notes edit d2cdf0b $ git log -1 d2cdf0b commit d2c
最終更新日: 2024年05月07日(火) 1. ご挨拶 2. 本記事執筆のモチベーション 3. ワークショップを通じて得たフィードバック 3-1. Pains -過去抱えた/現在進行形で抱えている辛み- 3-2. Approaches/Solutions -Pains を解消するために取った方策や導き出した解決策- 3-2-1. えいやで場所を決め打ちしてしまう(e.g., GitHub Wiki + Google docs しか使わない) 3-2-2. 個人的に、2023/12/05時点で〜みたいな書き方を心がけている 3-3. Tips -効果的な手法- 4. オーディエンスからの反響 4-1. 気づきや学び・NEXT ACTIONS 4-2. プレゼンター(@hayat01sh1da)へのフィードバック 4-3. Slack での反応 5. おわりに 1. ご挨拶 初投稿となります
今年４月からソフトウェアエンジニアとして働き始めたものです。 くまぎさんの会社ではソフトウェア開発でコード以外にはどういったものをアウトプットしていますか？ 配属された部署では設計/テスト関連では基本設計書、詳細設計書、単体試験項目書、結合試験項目書などなどをエクセル等でガチガチに作成しており非常に驚きました。 学生時代はそこまでしっかりとしたドキュメントを作成して開発したことはなく、どういったものが普通なのか、効率的なのか気になった次第です。 就職おめでとうございます。共に業界を盛り上げていきましょう。 コード以外で書くものと言ったらDD（デザインドキュメント）がもっぱら多いです。要するに基本設計書です。しかし、重要なのは業界に渡って「設計書」の指す内容には明確な合意や基準がないという事です。つまり僕のいう基本設計書があなたの会社での標準的な基本設計書ではないでしょうし、どちらが優れてい
M1Mac × Docker × SchemaSpy × MySQL8.0でテーブル定義書とER図を自動生成してみる 2022.10.19 技術 Docker, MYSQL こんにちは、システム部の能勢です。昨年の秋に入社して、今はバックエンドを中心に開発を担当しています。 「この設計資料、最終更新何年前やねん」 「なんか現実と違うんですけど」 こんな言葉にビビビっとくる方いませんか？ 最近はかなり激減したんですが、自分は少なくともエンジニアキャリアの最初の方ではこういう経験をよくしてきたタイプです。 弊社みたいにプロジェクトリリース前にドキュメントを第三者視点できっちり確認されるような体制のある開発現場ではこういうことが起こるのも低頻度だと思うんですが、実際問題世の中にはいろんなタイプの現場がありますし、そこまできっちり管理しきれない・・・こんなホンネが漏れるのが実情という方も多いんじゃ
2024-10-05 YAPC::Hakodate 2024 https://yapcjapan.org/2024hakodate/
設計ドキュメント腐る問題、 Git管理で運用してみた 本当のところ 2023.12.5 真野隼記 ドキュメント管理を制する 陳腐化を防ぐための実践事例 Lunch LT
VS Code の GitHub Copilot が MCP クライアントとして動作する仕組みが追加されたので、Copilot から気軽に自社製品の質問ができたら、快適ではないだろうか？考えた。 そこで、ハルシネーションをできるだけ少なくし、かつ安価で自社製品ドキュメントへの質問ができる仕組みを作ってみることにした。ちなみに LLM 系の知識はほぼ無い。 できあがった Sora Document MCP (Local) 0:00 /0:57 1× GitHub Copilot + Sora Document MCP デモ まぁまぁの速度で、質の高い回答を箇条書きで返してくれるようにはなった。 仕組みについて自社製品のドキュメントは Sphinx というフレームワークをを利用しており、reStucturedText (以降 rst) というマニアックなもので書かれている。この rst を L
72ページ / A5サイズ / 電子版はPDF（フルカラー） / 紙の本は表紙カラー、本文モノクロ 技術書典16（2023年5月25日～6月9日）の新刊「読み手につたわる文章 - テクニカルライティング」です。 「書籍版＋PDF版」は紙の本と電子書籍（PDF）がセットになっています。 「PDF版」は名前のとおり、PDFをダウンロードできます。紙の本はついてこないので注意してください。 この本は技術書典オンラインマーケットでも購入できます。 https://techbookfest.org/product/3t8AGqtB65jsPtPhx6m5fr 「ダウンロードカード用」は、既に紙の書籍をお持ちの方向けのファイルです。紙の書籍を購入された方は、あとがきの後ろにダウンロード用のパスワードが記載されています。ダウンロード後、あとがきに記載されているパスワードでZIPファイルを解凍してください
こんにちは、以前 FlightBooksというサービスを立ち上げていたのですが、2年ほどメンテしていなかったため、ローカル動作するOSS版として公開することにしました。 OSS版を作るにあたり、エディタ部分はVSCodeなりお好きなエディタを使ってもらうとして、 MarkdownからHTMLを生成する部分 HTMLからPDFを生成する部分 を切り出して公開しました。 ほかのサービスや技術と何が違うの？ 技術書をマークアップテキストで書くプラットフォームとしては、Re:VIEW、Vivliostyleなどがありますが、FlightBooksは「出版やDTPに関する知識がなくても印刷所にだしたい」というエンジニア諸氏のために開発されました。 「商業印刷」にどこまで向き合うか ご家庭のプリンタに印刷を指示すると、ファイルの情報がプリンタドライバに送信され、そこでインクの出し方を制御するためのデー
本連載では、VSCodeにフォーカスし、基本的な使い方から拡張機能の活用、そして本格的な開発現場での利用を想定した高度な機能までを紹介していくことで、読者がVSCodeマスターになるお手伝いをします。VSCodeは、プログラミング以外の用途にも使えます。第10回では、VSCodeをドキュメント作成のためのテキストエディタ、Markdownエディタとして使う方法を紹介します。 はじめに Microsoftの提供するVisual Studio Code（VSCode）は、2015年の最初のリリースから、今では開発用エディタの定番の座を占めるまでになりました。これには、無償で使えることも大きいですが、何よりエディタとしての使いやすさ、そしてさまざまな拡張機能によっていくらでも使い勝手を向上させたり、利用の領域を拡げたりできることも大きいでしょう。 本連載では、このVSCodeにフォーカスし、基本
吉祥寺PMにおける「マネジメントする人される人ナイト」というイベントで登壇した内容のスライドです。実際に見せた内容については、公開の予定がないため、気になる方は https://x.com/suguru_ohki までDMで相談いただければと思います。 [内容について] マネージャーの皆様方、こ…
Workgroup: HTTP Internet-Draft: draft-ietf-httpbis-bcp56bis Obsoletes: 3205 (if approved) Published: 22 March 2022 Intended Status: Best Current Practice Expires: 23 September 2022 Author: Building Protocols with HTTP Abstract Applications often use HTTP as a substrate to create HTTP-based APIs. This document specifies best practices for writing specifications that use HTTP to define new applicati
マンバ通信では、次の記事制作に向けてカンパ・寄付を募集しています。 少しのご支援でも大きな励みになります！ いやあ、まさか諸星大二郎先生が漫画を描いている瞬間を目にできることが今生であろうとは思わなんだ。 NHK「浦沢直樹の漫勉」*1という番組である。浦沢直樹が漫画家と、その執筆場面を5台の固定カメラで撮った映像を見ながら、毎回語りあう。浦沢は、漫画家の中では批評的で実践的な言葉を持つ作家*2で、作家ごとに重要なポイントを言葉で探り、対話で進めてゆくことができる。その手練は見事である。 また漫画家は、喋りが苦手で、うまく言葉を繰り出せない人も多い。漫画をよく知らない取材者に対して、時に見当違いな発言になったり、寡黙になってしまうのは、漫画の制作作業の内訳について双方が語りあえる言葉を持っていないからなのだ。 困ったことに漫画家は、一方でちょっとした違和感にも繊細に反応し、「何か違うな」と思
HashiCorp、ドキュメントの作成／レビュー／共有などを容易にする「Hermes」ドキュメントマネジメントシステムをオープンソースで公開 TerraformやVagrantなどで知られるHashiCorpは、「急成長するグローバル企業や遠隔地に拠点を置く企業にとって、書く文化は必要不可欠なものだと考えています（we also believe a culture of writing is a necessity for a fast growing, global, remote-oriented organization.）」として、同社内でも文書による情報共有文化が積極的に行われていると説明しています。 その同社が社内で開発し利用しているドキュメントマネジメントシステム「Hermes」を、オープンソースとして公開しました。 We are pleased to announce th
はじめにフューチャー技術ブログのリレー形式の連載である、春の入門祭り2023の1日目です。TIG真野です。 ここ数年、Markdownで設計書をチームで書き、GitHub（GitLab）上でレビューするフローを採用しています。なるべくテキストベースで設計開発フローを統一するため、私の所属するチームでは以下のようなツールを採用しています。 シーケンス図、業務フロー図 Markdown中にPlantUMLで記載 参照はGitHub上からも見れるように、pegmatite を利用 システム構成図など画像系 Diagrams.net（draw.io）で作成し、.drawio.png の拡張子でMarkdownから参照 これだけは目視で差分チェックとなる Web API定義 OpenAPI SpecのYAMLファイル 参照はGitHub上からも見れるように、swagger-viewer を利用 ER
TypeScript解読アシスタントこれはTypeScriptのコードリーディングを支援するツールです。 既存TypeScript案件に参加した際に、既存コードを読むにあたって、次のような悩みを解決するためのものです。 TypeScriptの構文がよくわからない「??って何？」「#nameの#ってコメント？」「<></>って何？」言語機能の名前がわからず、調べようがない「string | undefinedの|ってなんて名前？」「value as anyってなんて機能？」「[K: string]: stringって何？」使い方左のエディターに解読したいTypeScriptをコピペする解読したいコード部分をクリックする右エリアにコードの意味などが表示されるサンプルコード入力するコードがない場合はサンプルコードでお試しください。 サンプルコード機密情報コードはすべてオフラインで処理され、サーバ
2023年6月28日に開催された「Findy×freee」さんのコラボイベントに登壇した「新人エンジニアが入っているプロジェクトにおけるREADMEの書き方」の登壇スライドです エ…
こんにちは！逆瀬川 ( https://twitter.com/gyakuse ) です！ 今日は契約書の更新差分の比較をGPT-3とGoogle Document AIを使ってやってみたいと思います。 概要 異なるバージョンの契約書をPDF解析システムとGPT-3を使って自動的に比較し、リスクなどの検討も自動で出力する仕組みを作る。 Colab 使い方 Document AIの準備 (作成方法など詳しくは後述) Google CloudのDocument AIでプロセッサを作成する プロセッサ一覧から作成したプロセッサを選び、予測エンドポイントをコピーする https://console.cloud.google.com/ai/document-ai/processors json形式のAPIキーファイルをダウンロードしておく OpenAI APIキーの準備 すべてのセルを実行 比較した
従来のベクトル検索では、親チャンクに相当する文書全体がベクトル化されていました。しかし、この方法では前後に全く関係のない文章が含まれてしまい、類似度が減少する問題がありました。結果として「本当は欲しかった文章なのにスルーされた！」という事象が発生しやすくなります。また、「ベクトル化された文字列＝RAGで使われる文字列」だったりすると、RAGで使われる文字列がぶつ切りな内容で適用されてしまい、AI側での解釈が難しかったり、変に単語だけ注目されてしまってハルシネーションの温床になることがあったりもしました。 今回のDifyナレッジ設定 親チャンク分割設定 親子チャンクの設定として以下の通りにしています。親チャンクは文書全体と段落単位の2種類の分割方法を選択できます。 文書全体を指定すると、ドキュメントによっては想定以上の膨大な量になることがあり、うまくコンテキストに含められなくなる可能性があり
Teedyはさまざまな種類のファイルの中身を読み取って検索できる状態にしてくれるドキュメント整理ツールです。受信したメールを自動で取り込む設定もできるとのことなので、実際にセルフホストして使い勝手を確かめてみました。 sismics/docs: Lightweight document management system packed with all the features you can expect from big expensive solutions https://github.com/sismics/docs TeedyのインストールにDockerを利用するので、下記のリンクから自分の環境に合った方法でDockerをインストールします。 Install Docker Engine | Docker Documentation https://docs.docker.com
こんにちは、エンジニアのkinoppydです。本日は、SmartHRが公開したOSSガイドラインに関してご紹介します。 github.com SmartHR OSS ガイドライン SmartHRでは、すべてのサービスでOSSが使用されています。Ruby、Ruby on Rails、React、TypeScriptは必ずすべてのサービスで使われていますし、その他にもたくさんのOSSがSmartHRのサービスを構成しています。これらOSSによってSmartHRのサービスは支えられているので、我々もOSSに対してなにか貢献をすることができると良いなと思っています。しかし、現在社内には業務時間中のOSS活動に関する明示的な文章が存在せず、業務としてOSSにコミットする労務/法務的なルールが不明でした。また、OSS文化に対する経験が浅い人にとっては貢献する方法などもよくわからず、ハードルが高いと感じ
公開の対象となる行政文書の特定の作業が不十分だったと不備を認め、はじめの公開決定内容を取り消すことを毎日新聞社に伝えた通知書＝大阪市中央区で2022年9月1日午後3時9分、石川将来撮影 新型コロナウイルス対応にあたる保健所の負担軽減を図ろうと、大阪府が3月に始めた人材派遣事業「新型コロナ事務処理センター」。「緊急を要する」として原則禁止のはずの再委託が承認されるなど、「特例」を重ねた契約実態が明らかとなり、毎日新聞が報じた。取材は情報公開請求を駆使して進めたが、その過程で目立ったのが行政文書の管理や開示に関わる府側のさまざまな違反行為だ。取材の舞台裏を報告する。 事業は九つある府の保健所に民間スタッフを派遣し、陽性者発生届の入力など4業務を委託する内容だ。委託先は入札ではなく随意契約で決まり、旅行会社「近畿日本ツーリスト西日本支社」（大阪市）と事業開始日と同じ3月22日に契約が結ばれた。た
本稿では、gihyo.jp編集部で利用しているMarkdownファイルの記述方法を主に解説します。 注意：gihyo.jp編集部内でのみ採用しているMarkdownの書き方をまとめた文書を、記事の体裁を取って公開したものです。なお、記事公開後に記述方法を追加・変更する可能性もあります。 Markdownとは？ はじめに、筆者の把握している範囲でMarkdownについて概説しておきます。 近年は一般向けのウェブサービスやテキストエディタでも利用されてきているMarkdown。端的に言えば、テキストファイル上で文書を書くための構文です。文書の読みやすさに焦点を当てており、Markdown形式のテキストファイル（＝Markdownファイル）をそのまま見れば文書とその構造が理解できるように、Markdown特有の編集記号や字下げを用いて表現します。また、MarkdownファイルをHTMLファイルに
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。
概要 皆さまはメモを取りたいときやタスクを管理したい、アイデアを何かにまとめたいといった場合、どのようなものに頼っていますでしょうか？ 非デジタルであればノートだったりメモ帳を使用しているかもしれませんし、デジタルであればメモアプリだったりテキストエディタを利用、もしくはクラウド管理されているアプリを利用してるかと思います。 今回はデジタルで利用するメモアプリの話題について取り上げていきたいと考えていますが、もしデジタルでメモを取っている方はどのようなアプリや Web サイトを利用されていますでしょうか？ 有名どころで、メモやタスク管理、ドキュメント管理、データベースなど、仕事で使う様々なツールが 1 つにまとまっているアプリ「Notion」を利用されている方が多いのではないかと考えています。 www.notion.so 私自身も普段からこちらの「Notion」を積極的に利用させていただい
Learn up-to-date, idiomatic C++ with code examples, concise explanations, cheat sheets and infographics. -- Lerne aktuelles, idiomatisches C++ mit Code-Beispielen, knappen Erklärungen und Infografiken. -- 学现代的C++ // 代码示例，简洁的说明和图表
TechFeed Experts Night#12 〜 【VSCode, Vim, Emacs】エンジニア向けエディタ最新動向！にて発表した資料です。 ※8分間のLTなので「詳細はググれ！」となっているのはご容赦ください🙏 https://techfeed.io/events/techfee…
What’s changing In Google Docs, you can now select “Automatically detect Markdown” from Tools > Preferences to enable auto correcting for Markdown syntax, a lightweight markup language for applying formatting using plain text. Currently, Google Docs supports some Markdown syntax, such as: * or - followed by a space autocorrects to bullet points Various ways to start a numbered list similar to Mark
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
