なぜNotionはAI時代の勝者とならないのか｜いけぴ | プロダクトエンジニア
Notionは全てのオブジェクトをブロック構造で管理してるので、AIリーダブルではないんですよね。その複雑さをUIで完璧に隠蔽しているのが美しかったしデファクトとなった所以だと思ってるけど、なんとAI時代と相性が悪かった。 https://t.co/zZvTnKtJvF — いけぴ / Takahiro Ikeuchi (@iktakahiro) April 26, 2025 なんとなく、あれ、最近のNotionってなんか使いにくい？と感じている人が増えてきているようなのだけど、じつはAI時代においてNotionの強みが打ち消されてしまってきているという話だと思っているので、その解説記事を書く。 最初に結論なぜNotionはAI 時代の勝者とならないのか、という問いに最初に答えると、次のようになる。 NotionのBlock構造がAIへの知識供給の妨げになっているから 成果物とドキュメント
画面仕様書への静的検査器を実装したらたくさんの欠陥を発見できた話 - DeNA Testing Blog
SWET第二グループのKuniwakです。本記事では画面仕様（後述）の仕様書に対する静的検査器を開発した事例について紹介します。 伝えたいこと 画面表示と画面遷移を記述する仕様書は機械可読にできる 仕様書が機械可読であれば仕様の静的検査ができる 静的検査によって自身の担当範囲の15%の画面から計40件弱の欠陥を発見した 機械可読な仕様書にはさらなる応用が見込める おさらい：仕様とは 仕様の定義はいくつかあります。 ここでは仕様とは実装の正しい振る舞いを定める基準とします。 ある実装が正しいと判定されることを、実装が仕様を満たしたといいます。 誰による判定でも実装が仕様を満たしたかどうかの判定結果は一致すべきです。 さて実装の欠陥と同様に、仕様にも欠陥が生じえます。 本来正しいと意図した実装の振る舞いを誤っていると判断したり、その逆に誤っていると意図した実装を正しいと判断する仕様には欠陥があ
What is TSDoc? | TSDoc
TSDoc is a proposal to standardize the doc comments used in TypeScript code, so that different tools can extract content without getting confused by each other's markup. The TSDoc notation looks pretty familiar: export class Statistics { /** * Returns the average of two numbers. * * @remarks * This method is part of the {@link core-library#Statistics | Statistics subsystem}. * * @param x - The fir
Vitestでドキュメンテーションテストする
ドキュメンテーションテストをご存知でしょうか。 ドキュメンテーションテストとは、ドキュメントに記載されたコードを実行し、その結果が期待通りであるかを検証するテストのことです。 これにより、ドキュメントの内容が常に最新の状態であることを保証することができます。 Rustでは公式がrustdocというツールを提供しており、これを使うことでドキュメンテーションテストを行うことができます。 この記事では、TypeScript/JavaScriptでドキュメンテーションテストを行うVitest向けのプラグインを紹介します。 vite-plugin-doctest vite-plugin-doctestは、Vitestのエコシステムを利用してドキュメンテーションテストを行うためのプラグインです。 Vitestとは おそらく、この記事を読んでいる方はほとんど知っていると思いますが、VitestとはVit
ドキュメント翻訳プロジェクトを立ち上げると技術のキャッチアップもできる
Svelte Advent Calendar 2022 1日目の記事です。 前書き 皆さんはSvelteというフロントエンドフレームワークをご存知でしょうか。雑に紹介すると、ReactやVueと同じカテゴリに属するものです。また、SvelteKitというSvelteを使ったアプリケーションフレームワークもあります。こちらはReactにとってのNext、VueにとってのNuxtにあたります。 Svelteはパフォーマンスが良く、軽量で、わかりやすく、公式ドキュメントやチュートリアルが充実しているなど様々な面で優れており、Stack Overflow Developer Survey や State of JavaScript などのテック系のサーベイにおいて、該当の部門で1位を取るなど、近年注目を集めています (もっとSvelteについて細かく紹介したいところですが、 今回の記事の趣旨とは異
伝えたい人に届ける技術記事の書き方 - Qiita
こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2021 、初日の記事です。 なにこれ？ 苦労して執筆した技術記事は、伝えたい人にしっかり伝えたいですよね。 また、最後まで読んでもらいたいですよね。 一方で、構成などに課題があって、伝えたい人になかなか伝わらないことがあります。 この記事は、伝わる記事の書き方について、私の個人的なノウハウを書き記したものです。 これからアドベントカレンダーの記事を執筆される皆さんにとって、少しでもお役に立てられれば幸いです。 この記事のゴール 以下の理解を得ることをゴールとします。 以下2つの要件を踏まえた記事構成を心がけること。 構成要件①：技術を紹介する上で最低限説明の必要な内容を網羅すること。 特に課題をしっかり伝えること。 構成要件②：読み手が段階的に理解しやすい順番になっていること。 告知の仕
インストールしたプラグインのREADME.mdをお手軽に見れるvim-readme-viewer作った
作った動機 世界中のvimmerは、vimについて知りたいことがあればすぐにhelpを引くと思います。 何しろ:help {知りたいこと}するだけです。 オンラインでも見ることができます。vimならここ(日本語版)、neovimならここ(英語版)です。 プラグインの設定もたいていはhelpを引きながらやれます。 便利にhelpを引くためのTipsもいろいろな人が書いています。 Vimのhelpを快適に引こう - haya14busa Vim :helpがユニークな3つのポイント、vim :helpを読むための敷居を下げる3つの事柄 - Qiita しかし、中にはhelpがないプラグインも存在します。 特に新しめのneovimのプラグインや、colorscheme系のプラグインにはhelpが用意されていないことが多い印象です。 そんなときは、README.mdを見にいきます。helpがなくて
rustdoc中でmermaidを使って図を書く
この記事ではmermaidをrustdoc中で使う方法についてまとめます。 Aquamarine crate 結論から先に書くと、aquamarineというcrateが存在し、これを使って次の様にAttributeを書くと使えます： #[cfg_attr(doc, aquamarine::aquamarine)] /// ```mermaid /// graph LR /// s([Source]) --> a[[aquamarine]] /// r[[rustdoc]] --> f([Docs w/ Mermaid!]) /// subgraph rustc[Rust Compiler] /// a -. inject mermaid.js .-> r /// end /// ``` pub fn example() {}
GitHubのREADMEをサクッと高品質で書けるサービス作ってみました。 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? みなさんは GitHub でオープソースソフトウェア(OSS)を開発して公開する時、README をどのように書いているでしょうか？ GitHub が自動で作ってくれる README に含まれるのはタイトルだけですし、OSS 開発初心者の場合、そもそも README に何を含めるべきかわからないという方もいらっしゃるのではないでしょうか？OSS 開発に慣れている方でも、コードを書くのはいいけれど README を書くのは面倒だと思ったことはありませんか？今回はそんな README 難民の方々向けの Web サービスを作ってみました。 L
Google社のテクニカルライティングの基礎教育資料がとても良かったので紹介したい - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに エンジニアにとって、仕様書などの技術的な文章を書くこと（テクニカルライティングとも言います）は避けて通れません。ただ20年来多くのエンジニアの方々と同僚として接してきて思うことは、エンジニアの方の中には「文章を書く」ということに苦手意識がある方が一定数いるということです。 でもこの「テクニカルライティング」のスキルは、才能というよりは一種の「技能」だと思うんです。ある一定の原理原則を理解して実践を繰り返すことで、必ず一定レベルで習得できるものだと著者は信じています。 もしこのテクニカルライティングの原理原則をまだ体系的に学習し
vim-jpの活動とプラグインとヘルプファイル - Qiita
お題 今回の話題は「vimのヘルプの公開」です。 序 vim-jpはvim界隈でも活動実績が評価されてるユーザーグループです。(なんとなくはしっこに参加させてもらってます) ここの成果はいろいろありますが... vim本体の不具合の確認やパッチ作成の場(日本語) vital.vimという有用ライブラリプラグイン(他のプラグインに取り込んで使う) vimのヘルプの日本語訳 などがあります。 ここで今回のに関係するものとして「vimのヘルプの日本語訳」があります。 本体の日本語化などはKaoriya(香り屋)版vimで有名な @koron さんや @mattn さんらが始めて、ヘルプについても多数の方が継続的に翻訳更新しつづけているものです。現在は @h_east さんらが積極的に活動されてますね。 これはプラグインとしてvimへ導入できるので、その用途での利用が多いかと思います。 ただ、あわ
GHC のノートコメントについてのあれこれ
someFunc = let v = 42 -- See Note [The Answer To Life] in v {- Note [The Answer To Life] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "The Answer to the Ultimate Question of Life, the Universe, and Everything" is 42. After seven and a half million years of calculation, deep thoughts finally output the answer. -} 例えば， https://gitlab.haskell.org/ghc/ghc/blob/ghc-8.6.4-release/compiler/prelude/TysPrim.hs#L593 のような感じ
Pythonプロジェクトのdocstringの網羅率を計算するパッケージdoc-covをつくった - ぴよぴよ.py
みんなのdocstring書くモチベーションをあげるために、docstringの網羅率を計算して Pull Requestごとにdocstringの網羅率(coverage)の変化を表示したいな〜と思って調べたんですが、 そういった網羅率を計算するライブラリが見つけられなかったので、自分で作りました。 インストールの仕方と使い方を紹介します。 インストール pip install doc-cov これでdoccovコマンドが使えるようになります。 使い方 基本的には計算したいプロジェクトのパスを指定するだけ。 デフォルトではpublicな関数のdocstringの網羅率が出力されます。 $ doccov tests/sample_project function 3 / 5 60.00% Options 細かいオプションはREADMEにありますが、 いくつか例を出しておきます。 csv出力
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - kecbigmt/docgent: 社内のチャットをもとにドキュメントを作成・更新して、同じことを2回答える必要をなくすためのAIエージェント
GitHub - nalgeon/codapi: Interactive code examples for documentation, education and fun
Kodemo
GitHub - mintlify/writer: ✍️ AI powered documentation writer
https://roogle.hkmatsumoto.com/
GitHub - ExtremaIS/literatex-haskell: transform literate source code to Markdown
Idrisdocの使い方 | κeenのHappy Hacκing Blog