知的・技術的進歩のスピードを限界まで加速するノートアプリ『Heptabase』 - Qiita
はじめに 1年半ほどObsidianというノートアプリを使い、Qiitaにも記事を３つほど公開をしていました。 効率的に成長するためのデジタルノート術(Obsidian x Zettelkasten(LYT Framework)) コーディングのようにノートを取る技術 がんばらないObsidianノート術 確かにNotionやEvernoteとは違う感覚のノートアプリであり、双方向リンクを利用したグラフで繋げていくノートに当時は感動を覚えました。 その反面、Obsidianを百パーセント有効に活用できていたかと聞かれると「はい」と答えることは難しいと感じています。がんばらないObsidianノート術の記事はまさにその一角であり、Obsidianの拡張性と自由度に翻弄されてしまわないように書いた記事です。 1年半を通して紆余曲折した中、先日新しいツールとの出会いがあり、自分に合うツールを見つ
がんばらないObsidianノート術 - Qiita
はじめに Obsidianという素晴らしいプロダクトが登場してから、デジタルノート術は活発化したと思います。私もその１人で、今日も楽しくObsidianを使っています。 しかし、その一方であまりノート術にこだわりが強くない方や深く理解するほど価値を感じていない人の中ではまだまだ単なるメモ帳として使われている現状があります。 そこで、今回は「がんばらない」Obsidianノート術として、「こだわりすぎない」「多様な原理原則がない」形で『書く』習慣を付けるためのノート術を書きました。 そんなノート術であったとしても、今後ノートを分解していけるような構造にしておくことで、今後の拡張性を残しています。ぜひ「難しくて挫折しまった」という人はチャレンジしてみてください。 『書く』ことで整理術は生きる Personal Knowledge Managementはの概念やLYTといった考え方は斬新で、とて
「ドキュメントの書き方」を体系的に学んだことがないエンジニアへ 書籍『エンジニアのためのドキュメントライティング』の概要
インフラエンジニア向けの書籍を取り上げ、著者と出会い、楽しく本を知り、仲間を作る場所である「インフラエンジニアBooks」。ここで、『ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング』の翻訳を担当した岩瀬氏が登壇。まずは、本書籍の概要について話します。 本セッションの対象者と、セッションのゴール 岩瀬義昌氏：ご紹介いただきました、岩瀬と申します。よろしくお願いします。『ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング』は、もともと『Docs for Developers: An Engineer’s Field Guide to Technical Writing』という洋書だったんですが、その翻訳をして、今回この機会をいただいています。 余談ですが、APC（株式会社エーピーコミュニケーションズ）さんが「カプセルト
執筆ガイドライン - MDN Web Docs プロジェクト | MDN
MDN Web Docs プロジェクトCommunity guidelinesコミュニティガイドラインContributing to MDN Web DocsMDN Web Docs への協力MDN を始めようMDN Web Docs のリポジトリーMDN Web Docs のローカライズセキュリティ脆弱性への対応策オープンソースのエチケットコミュニケーション手段コミュニティのディスカッション学習フォーラム課題の作成と作業のガイドラインプルリクエストの提出とレビューのガイドラインMDN Web Docs の役割とチームWriting guidelines執筆ガイドライン私たちが書くもの執筆スタイルガイドHow-to guidesHow-to ガイド画像やメディアの追加方法ページの作成、移動、削除、編集方法CSS プロパティの記事の作成方法HTTP ヘッダーの記事の作成方法ウェブのエラー記事
文章を書くことはプログラミングに似ている。 - CARTA TECH BLOG
技術広報のしゅーぞー(shuzon__)です。 今日は「文章を書くことはプログラミングに似ている」という話をします。 参考書籍はこちら。論理が伝わる世界標準の「書く技術」 @soudai1025からのリクエストで社内ブログを一部編纂し公開しています。 文章を書くことはプログラミングに似ている。 文章を書くことはプログラミングに似ている。 なぜならば、抽象化すると、一連のトピックに対する意味のあつまりを区切り、扱う行為だからだ。 意味ごとに構造化する行為と思えば非常に似ている。 パラグラフ・ライティングは関数に似ている ここでパラグラフ・ライティング を紹介しよう。 パラグラフの構造 パラグラフ・ライティングは関数に似ている。 パラグラフ・ライティングは段落の先頭に「その段落が持つトピックの結論」を書く。 その後、前述の事実を用いた補足とロジックが続きトピックを補足する。 段落の最後に、議論
わかりやすい文章を書くために、Google翻訳を使う | ず＠沖縄
昔から私は「わかりやすい文章」を書きたいと考えている。文章を書くコストは大きいが、それを「わかりやすくする」コストは比較的に小さい。わずかな時間を惜しんで、わかりにくいままの文章を出すべきではない。 （もちろん、わかりやすく書いても、それを読んだ人が正しく理解するとは限らない。曲解されることは常にある。しかし、それを盾に、「わかりにくい文章」を書くことを正当化してはいけない）。 私が現在、「わかりやすい文章」を書く上で気にしていることは、論理構造と音読である。後者も語りたいことはたくさんあるのだが、長くなるので別の機会にする。今回は、論理構造を明確にするためのツールとして、Google翻訳を使うことを提案する。 「わかりやすい文章の書き方」は既に多数存在するのだが文章をわかりやすく書くことは、昔から必要とされていた。書籍も多数存在する。世の中で推奨されているのは、例えば、以下の書籍である。
果てしない文章推敲を「３ステップ」で効率的に終わらせる方法｜石原尚（大阪大学教員）｜note
文章は、「これで伝わるだろう」という淡い期待を簡単に裏切ります。伝えたいことを期待通りに伝えられるようになりたいのなら、「表現の質」を高めるための推敲の技術の習得が不可欠です。 この記事では、大切ながら手間のかかる推敲を「効率的に」実施する方法を紹介します。ほとんどはじめて論文を書くことになった学生さんが、論文原稿（卒論・修論）の価値を飛躍的に向上させるうえで役にたちます。また、論文に限らず、「正しく、詳しく、丁寧に伝えたい」という気持ちで文章を書こうとする場合には、さまざまな場面で使えるはずです。 この記事で紹介する推敲の手段は、「切り分ける・並び替える・繋ぎ方を変える・削り落とす・一貫させる・まとめる・明確にする・限定する・やさしくする」の９種類です。この９種類さえ自由自在に駆使できれば、論文の文章を劇的に良くすることができます。この９種の推敲を、「まず工事して、片付けて、最後に気遣い
textlintとFlycheckによるEmacs上でのテキスト校正 - makoのノート
この記事はEmacs Advent Calendar 2021の13日目の記事です。 こんにちは。 突然ですが、Emacsでは、人工言語(Python, Rust等)でのコーディングだけでなく、メモ、ブログ、原稿書き等の自然言語(日本語や英語等)での入力も多数発生します。 自分用のメモだけであれば自分が理解できれば良いですが、他の人にも読んでもらうならば冗長な表現や誤字・脱字をなるべく避けたいものです。 そこで今回は、textlintとEmacsのFlycheckを用いて、リアルタイムのテキスト校正方法を紹介します。 この記事が少しでも読まれた方の参考になると嬉しいです。 textlint textlintとは、テキストファイルを特定のルールに従ってチェックや修正してくれるツールです。@azu_reさんという方が作られています。 ルールには色々あり、技術文書向け、誤字・脱字、英語向け、日本
Emacs で日本語文章をチェックする方法(flycheck + textlint)
うまく進めば 10分程度で、日本語文章をチェックして適切でない箇所を強調することができると思います。 Emacs 使う前に textlint を設定する 事前に textlint とプラグインをインストールする必要があります。 # textlint 本体です npm install -g textlint # 日本語でチェックするためのプラグインです npm install -g textlint-rule-preset-ja-technical-writing # org-mode で textlint を動かすためのプラグインです npm install -g textlint-plugin-org npm install -g traverse # 下記のインストールは私の環境では必要でしたが、エラーが出るまで入れなくて良いかもしれません。 npm install -g @textl
去年は182本の記事を書いた人から見た、技術的なアウトプットに疲弊しないようにするコツ - Lambdaカクテル
文脈: blog.arthur1.dev 自分は割とガンガンアウトプットする方で、たまにバズって嬉しいという品質のブログ(これ)をやっている。普段どのような心構えでやっているのか、そして続けるコツみたいなものについて書いてみようと思う(参考になるかは全くわかりません)。 あと一応断っておくと、タイトルにある "去年書いた182本の記事" は非-技術的な記事も含んでいる(けど、だいたい技術記事なので許してほしい)。 どういうときに書くか どういうモチベーションで書くか どういうときにバズるか どのようにして続けるか 余談: 箇条書きの型を統一する 参考文献 あわせて読みたい どういうときに書くか 自分は基本的にブログを「1年前(後)の自分が泣いて喜ぶ記事」というテイで書いている。自分が知りたかったことは他人も知りたかったはずだという仮説で書いていて、それを知りたかった人の総量はその技術のシェ
ChatGPT便利すぎる！！
Appleがゴミみたいなレビューで会社のアプリをリジェクトしてきた。 「Specifically, your description includes Android references.」 だって。 アプリの説明にはAndroidなんて単語は全くでてこないのに！ 念の為アプリの中身も調べたが、確かにAndroidという単語は文字列としてアプリに含まれるが、それはユーザーには見えないところにあるので問題ないはずだった。 この野郎Apple、適当な審査しやがって。 そう思って返信してやろうと思ったけどうまく書けない。 直接的な物言いは出来るけど、ちゃんとビジネスマナーに沿って書かないとリジェクトいじめされそうだし。 そこでChatGPTで聞いてみた。 「Please write a reply to Apple, who wrongly rejected my company's iOS
私の技術記事の書き方 - azukiazusaのブログ
技術記事を書くことは、最初はなかなかハードルの高い作業に思えます。文章を書くにはある程度の慣れが必要である考えています。 誰しも初めのうちはうまく文章を書くことができず、文章を書く訓練を重ねることで、内容を伝えやすい・理解しやすいある種の「型」を発見されているのではないかと思っています。 この記事では id:azukiazusa が普段記事を書く時に考えていることを書き下していきます。 見出しを先に書く コードは実行可能にする 文法エラーがないように 文脈依存にならないように foo や bar のような名前を使いすぎない 記事は1日寝かせる その他文法的な事項 見出しは ## から始める インラインコードブロックは装飾目的で使わない 英語と日本語の間に半角スペースを空ける おわりに 参考 見出しを先に書く 私が技術記事を書くときには最初に見出しから書き始めます。下記のような感じです。 見
【なるべく意識を低く保て】 書けないと悩む人のための、原稿の書き方 ： 〜雑誌原稿を実例に〜｜ふくろう
この記事は、執筆業を15年（専業5年／副業10年）ほど続けている人間が、どのように原稿を書いているかを解説する、執筆メイキング記事です。 私が2年、寄稿していた『本の雑誌』新刊レビュー原稿を例として、初稿から完成稿までどのようにバージョンを重ねているか、説明します。 ◆【前置き】この記事を書いた背景◇想定読者想定読者は、「原稿をなかなか書き出せない人」「原稿を書くのに時間がかかる人」「原稿を思うように書けずに苦悶している人」です。 ◇きっかけもともと本稿は、執筆に悩む家族のために書いた、家庭内閲覧用の文書です。 家族（執筆の専業経験なし）は、たまに専門領域の記事や書籍の執筆依頼を受けて書いています。執筆するたびに「書けぬ……書けぬ……もうだめだ……」とうめきつつ、どうにか書き上げるのが風物詩でしたが、今とりかかっている原稿はとりわけ難産らしく、毎日「何の成果も！得られませんでした！！」状態
プログラマーに贈る、わかりやすい文章を書くための技法 - LIVESENSE ENGINEER BLOG
これは Livesense Advent Calendar 2022 DAY 8 の記事です。 転職ドラフトでエンジニアをしている verdy_266 です。 僕の2022年を振り返ると、採用広報チームでの活動を無視することはできません。転職ドラフトの開発を行う傍ら、昨年末に採用広報チームにジョインし、記事の執筆や校正に多くの時間を割いてきました。 今まで記事を投稿したことがなかったこちらのブログにも共作含め5記事を投稿し、11月には Software Design への寄稿の機会をいただくこともできました。文章を書くことが思った以上に好きなんだなと発見があった年でもありました。 made.livesense.co.jp made.livesense.co.jp made.livesense.co.jp made.livesense.co.jp made.livesense.co.jp 弊
伝わる文章 | 基本要素 | SmartHR Design System
相手に誠実に、わかりやすい文章を書くための心がけをまとめました。 どういう思考プロセスからどんな表現が生まれるのか、参考として実例を紹介しています。実際に読み比べ、SmartHRの従業員として何かを伝えようとするときの、参考にしてください。 伝わる文章のガイドライン何を伝えるかによって、必要な情報の量や説明の粒度は異なります。 情報が不足していたり、逆に情報が多すぎたりすると、読者が意図を読み取れないことがあります。 読み手となる相手の状況（読む場面、事前知識など）を踏まえ、言葉にする内容や表現を厳選することが大切です。 目的に合わせて情報を取捨選択する読者の目線に立ち、コンテンツの目的に合わせて情報を取捨選択しましょう。 実例1：法律や業務に関わる記事目的業務に関係する「厚生年金保険」について正確に知りたいと思っている人に、わかりやすく内容を伝える。 Before日本の年金制度は、全国民
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
雑に思考を整理する技術と効能
テクニカルライティングの基本 2023年版
Shodo（ショドー）：自分の日本語を、信じない。AI校正・誤字脱字チェック、相互レビュークラウド
技術をわかりやすく伝えるためテクニカルライティング
「DeepL Write」が登場 ～翻訳ではなく、より正確・自然な文章提案に特化したAI／Webブラウザーさえあれば誰でも無料で利用可能
