00:04
8月9日、火曜日ですね。 地獄は朝9時に終わりました。
今日はですね、東京は良い天気なんですけど、 ちょっと自分がなんか体調悪いので、短めに終わるかもしれないですね。
はい、おはようございます。 ゆめめのkeethこと久川肌です。
じゃあ本日は朝活を始めていきたいかなと思います。 本日はですね、タイトルになりますけども、
ドキュメンテーションファーストと、 あとReadme Driven Developmentという記事を読んでいこうかなと思います。
昨日見ました、Art of Readmeという記事がありまして、 それの中に追加で貼られてたリンクですね。
この2つの記事もいいよ、みたいなのがあったので、 そこを続けて読んでいこうかなと思います。
昨日に続けて、またReadme周りの話になってしまうので、 飽きたというか、Readmeについては一旦いいやっていく方は全然、
周り見にしていただいても構いませんので。 じゃあ今日はこの辺を読んでいこうかなと思います。
改めて、ドキュメンテーションとか Readmeの大切さというところをしっかり理解しつつもですね、
他にTIPSとかこういう観点もあるみたいな、 新しい観点とかがないかなというのをちょっと期待して読んでいこうかなと思いました。
はい、では最初ですね、前者のほう、 Readme Driven Developmentのほうから読んでいこうかなと思います。
では言いましょう。最近TDDやBDD、 テストリングドリブンディベロップメントと
ビヘイビアドリブンディベロップメントですね。 TDDやBDD、エクストリームプログラミング、
スクラム、スタンドアップミーティングなど、 よりよりソフトウェア開発をするための方法論やテクニックについてよく耳にしますが、
私たちが作っていないソフトウェアがそれを使っている人たちのニーズに 合っていなければすべて無意味なのですと。
はい、これ重要ですよね本当に。 何のためっていうところをしっかり共通認識を持たないと本当に無意味になりますからね。
一応無意味というとそれはそれですけどね。 作ったものとか生み出されたものをどう使うとか、他に活かすとかっていうのを
未来を考えれば別に無意味じゃなくなるんですけど、 現時点で何をしているかというところが単純に自己満で終わってしまうので
無意味になってしまいますよねということですね。 別の言い方をしましょう。
間違った仕様の完璧な実装というのは価値がないよということですね。
仕様が間違ってたらまあそりゃそうですよね。 いくら完璧でテストも全部通っていて、
そこまで設計も素晴らしいとなっても、 間違った仕様であればそれは確かに意味がないですね。
同じ原理で美しく作られたライブラリーが何のドキュメントもないもの、 ないっていうのもほとんど無価値だというふうに言っています。
もしあなたがソフトウェアが間違った問題を解決していたり、 誰もその使い方を理解できなかったりしたら、
それは何かとても悪いことが起こっているんですよというふうに言っています。 なるほど。
ではどうすればこの問題解決できるのでしょうか。 それはあなたが持っているより簡単で独自の段落を保証するのに十分なほど重要なことですと。
03:00
まずリードみを書きましょう。
最初にコードやテスト、動作、ストーリーその他諸々を書く前に書きましょう。
わかってるわかってると。俺たちはプログラマーなんだ。 テクニカルライターじゃないんだぞと。
まあそういう意見もあるでしょう。でもそこが間違いなんですよと。 リードみを書くことは良いソフトウェアを書くために絶対に必要なことなんですよと。
自分のソフトウェアについて書くまでは何をコーディングするのか見当もつかないんです。
ウォーターフォール設計に対する大反発とアジャイル開発の最高需要の間で何かが失われてしまったんですよと。
あーでも確かにウォーターフォール開発して成功したことは一度も僕はないんですし、成功した事例を聞いたことはないんですけど。
ウォーターフォール開発やってる時は確かにちゃんとドキュメンテーションめちゃくちゃ書きましたね。
今のアジャイルになって、別に書かないわけじゃないし、書くことはいっぱい書きまして、仕様書だったりとか設計だったりとかみたいなところは全然書くんですけど、
リードみはもちろん書きますけど、アジャイルになってもなるほどドキュメンテーションではそこまでガッツリちゃんと書くかというよりも、
前に進めることが多いし、やっぱり変更が多いのでそのドキュメンテーションにコストを塞いでいると前に進むことがちょっとできなかったりとか、それが遅かったりしますね。
そもそも仕様がどんどん変わったりとか、いろんなものをどんどん変化を柔軟に取り入れつつ、スケジュール調整しつつというのがアジャイルな感じなので、
ドキュメント自体の管理コストもかかってくるっていうのが大きいから、あんまりドキュメンテーションをメインでガッツリ書くみたいなことはしなくなった印象はありますが、
一方で確かにウォーターフォール設計からアジャイル開発に移る間の中で確かに何か失われた感はありますね。
まずドキュメンテーションは絶対正しいというか絶対書かなきゃいけないというわけではないし、ちゃんとケースバイケースですけど、
必要なものがあるから必要なときに書きましょうが正しいと思っていて、ただその必要性というのが何か失われたんじゃないかというのがその何かというのが僕の感覚ですね。
ちょっと戻ります。誤解を恐れずに言えばウォーターフォール設計というのは行き過ぎなものです。
細部にまでこだわった巨大なシステムというのは結局細部にまでこだわった間違ったシステムになってしまうのです。
私たちがウォーターフォールを廃止したのは正しいことでした。しかしそれにとって変わったものはあまりにも逆の方向に進みすぎていますと。
今私たちは短い文章、ひどい文章、あるいは全くない文章を持つプロジェクトを持っていますと。中にはリードミスらないプロジェクトがあります。
それはひどいな。全くドキュメントがないのはガチでひどいな。個人開発でやる分には構わんかもしれないですけど、それを他の人に使ってもらうってなった時点でドキュメンテーションを書かないっていうのは完全NGだと思います。
これは受け入れがたいことですと。膨大な量の技術仕様と全くない仕様の間には何らかの中間領域があるはずですと。そして実際にそうなっています。その中間地点がリードミーだと言っています。
リードミードリブンディベロップメントとドキュメンテーションドリブンディベロップメントを区別することは重要です。
06:05
今言ったのは一応頭文字をとって、RDDというのはDDDの、今回のDDDはドキュメンテーションドリブンディベロップメントですね。
RDDはDDDのサブセットまたは限定バージョンと考えることができます。
RDDというのは設計ドキュメントをソフトウェアの紹介として読まれることを意図した一つのファイルに制限することでDDDから添加したウォーターホール症候群を防ぎ、長い使用や
課精密な使用を抜することができるんです。
同時にRDDというのはライブラリの規模を小さくし、モジュール化することでユーザーに保証を与えます。このような単純な強化というのは、正しいことをするために多くのプロセスを必要とせずに、プロジェクトを正しい方向に導くのに大いに役立ちます。
なるほどね。
リードミーを最初に書くことで、いくつかの重要な利点を得ることができます。最も重要なことは、どのように構成すべきか、何がパブリックAPIに含まれるべきかについて考えを変えるたびに、コードを変更しなければならないというオーバーヘッドなしに、プロジェクトを通して考える機会を自分に与えることができるということですね。
自動化されたコードテストを書き始めたとき、そうしなければコードベースに盛り込んでいたであろうあらゆる種類のエラーを発見したときの感覚を覚えていますか?
はいはいはいありますね確かに これは実際のコードを書く前にプロジェクトのリードミーを書くのと同じ感覚ですと
なるほどねうわぁまぁなんかチンッ 近い感覚は確かあるかもしれない
なるほどねテストを書いた時のその感覚とリードミーを書く時の感覚って本質的には一緒のものだと言ってますね
はいはいはい 確かに自動テストを書いたときですねコードを書き始めたときにいろいろ確かに盛り込まれていたりとか
潜在していたいろんなものが発見されるって確かに多いですよね 仕様バグであったりとか
これへん交流漏れじゃないみたいなところって結構出てくると思うんですけど これと同じことがリードミーでもできるよっていう風に言ってるんですね
はい なるほどね
リードミーでどこまで出てくるかっていうのと何を書くかによって結構話が変わりますね
OSSみたいなライブラリーを作ってるんであればリードミーの書くもので大体もう決まってますし
その辺って そこまで大きなズレはないと思いますけどプロジェクトのリポジトにおけるリードミーっていうのはどこまで
何を書くかっていうのは結構議論の要地はいくらでもありまして皆さん同士であるので ここは結構大事かもしれないですね
はい では戻ります
何を実装する必要があるのかを知るためにリードミーを書くという副産物としてあなたはとても素晴らしいドキュメントを目の前に置くことになります
またリードミーを書くのはプロジェクトの最初のうち興奮とモチベーションが最も高いときにした方がずっと簡単ですと
それはそうね 過去に遡ってリードミーを書くことは絶対的なドラッグでありそうすることであらゆる種類の
09:07
重要な詳細を見逃すことは確実ですよと言ってます
もしあなたが開発者のチームと一緒に仕事をしているのであればリードミーというのはさらに有効な手段となります
もしあなたがプロジェクトを完了する前にチームの他の全員がこの情報にアクセスできれば彼らは自信を持ってあなたのコードとインターフェース
する他のプロジェクトに着手することができます インターフェースが定義されていないと連続的にコーディングしなければならず
コードの大部分を再実装することになりますと 書き留めたものを元に議論する方がずっとシンプルですと
何も文章にしなければ問題点について延々と堂々巡りで話し続けることは簡単ですと 解決策を書き出すという単純な行為によって誰もが具体的なアイディアを持ちそれについて議論し反復することができるようになるのですと
あなたのプロジェクトのリードミーを書くプロセスというのは真の創造行為であると考えましょう
ここにはあなたの素晴らしいアイディアがすべて表現されているはずです この文章はあなたの創造性と表現力の証としてそれ自体で成り立っていなければなりません
リードミーというのはあなたのコードベースの中で最も重要な文章であり最初に書くことが適切なんですよというところでした
以上リードミードリブンディベロップメントというところでした 開発にずっと寄り添うというよりも最初にプロジェクトをスタートする時の最初にガンと書いておきましょうねという
感じだなぁ締め方でした まあでも共感味がすごく僕はあったしなるほどねというところでした
あんま新しい発見とかはなかったですけど一つの何ですか8 テストコード書く感覚とリードメカのように出るよというところは確かになってそこは気づいて
なかったので面白かったなと思いました はい以上毎こんな記事でしたので一応この記事は82010年の8月23
サンフランシスコで書かれてますねはい実に12年前の記事ですけどは出す 今でもずーっと生きるってことだってばドキュメンテーションの文化とかあのなんですかね
フィロソフィー的なものっていうのは今後もずーっと続くものでそんなに大きく変化される ことは多分人類なんでないんでしょうねっていうのも感じましたね
はい というところですではここは一旦区切ってもう1個の方ですね
はいもう1個待つと似たような文章ですけど8ドキュメンテーション ファーストっていう記事を読んでいこうと思います
これかなり短いので一瞬で終わってしまうんですよなんでちょっと残り時間どうするかは えっと
あれですね困った時の j サインほど見ましょうかね ちょっとグラグラしてし大変申し訳ないですよ
はいじゃあえっとドキュメンテーションファースト呼んでいこうと思います えっと翻訳しますね少々お待ち
はい いきましょう
私は最初にドキュメントを書き次に行動を書きますとでこのことを時々 まあ以前ですねもしくは
述べてきましたけれども読者からなぜ私がそのような仕事をするのかきちんと説明した ことがないというふうに指摘がありましたと
はぁなるほど 自分の言い分だけバンバン言ってるけどなんでっていうところですね
これはすぐに複雑な行動に飛び込むことなく自分の考えをより具体的にするための方法 なんですと
12:02
私が書き留めているものは設計文書であったりあのバグレポートのメモであったり しますがもし私が取り組んでいるものはユーザーの目に触れるものであれば
まずエンドユーザーの文章を書き留めることから始めますと 書き出すことで頭の中で考えることよりも具体的で編集しやすい
また推論がしやすいページ上の言葉として対話することができますとはい コードでは既存の構造に縛られますが白紙のページでは新しいアイディアを探求し
高知することができます これはエッセイを書くプロセスをソフトウェアに応用したものですべてが文書がされている
ことを確認する副知的な効果もあります なるほどでまたエンドユーザー向けのドキュメントっていうのはユーザーが予備知識を持っている
ことを前提にしない方が良いですこれがこれ大事ですね本当に 予備知識持っていないってことですよね何も知らないというところから書くこと本当に
と思いますね はい何かについて完璧に知識がない状態に最も近いのはそれを作る前なんですよ
って言ってますねはいですからそれを文書化するのはその時が一番良い なのでまぁ先に書くってことですね
私が書き始めた時よりも書き出した今の方が自分が伝えようとしていることをよりよく理解 しています
あなたもそうなってくれるといいのですがというところで一応この動作としては君に占め られてて後は何
rss だったりまあ1個の注釈がまあバーって書いてますけどまぁそんなところですかね はいまぁ一応ありますけど内容的にそんな変わんないのでまぁ発売しようかな
というところでしたかでもちょっとかなり短かったですけどこんなものですね はいとにかく先に書いておくほど
さらに書くとしたらエンドユーザー向けて ドキュメントをまず書くことがスタートですと
さらにエンドユーザー向けて書くんですけどエンドユーザーに予備知識がないという ところも前提において書きましょうと
これ多分あのエンドユーザー向けのドキュメントもそうですし開発者に向けてもそう と思いますね
新しい開発者がチームに所属するとジョインするとなった時にも もちろん何も知らないのでその人がスムーズに開発スタートできるように
どういうふうな環境整備必要だったりとか知っておかなきゃいけない予備知識だったり とかそのチーム内だけで通じるとプロジェクト単位でやっぱり
用語って出てくるじゃないですか ドメインが違ったりするとそこでの専門用語でいっぱい出てくるんですよね
この業界であたり前に使われてますけど僕らが知らないみたいなのがあったりするので その辺も書いてあるとか
まあいろいろ書くものはたくさんあるんですけどそういうドキュメントを書いておくことでより開発者としてもチームに入った後
スムーズにプロジェクトを進められるためには必要だなというのがあったりするので
いろんなものに対してまず何も知らない前提でドキュメントを書くというのは素晴らしいことだと思いますね
はいということでした では今2つの記事読み終わったのでちょっと早いですねやっぱり残り時間
JSERインフォーの2022年8月2日ですね の更新記事をだらっと読み終えます
その辺読み終わったら多分今日の時間終わりかなというところなので RSSをただ音読してるみたいなイメージで聞いてもらえればと思います
はい じゃあ行きましょうJSERインフォーです603回ですね
15:00
はい まず一つ目ですけども
Google Chromeでのサードパーティークッキー配信に変わるAPIとしてプライバシーサンドボックスという一連のAPIが提案されています
まず提案ですね 元々は2023年の半ばからサードパーティークッキー配信を段階的に進める予定だったんですけど
今回このロードマップが実は更新になっているそうですね なるほどねはい
更新されたんだ expanding testing for the privacy sandbox for the web っていう記事がありますね
これちょっと明日読んでみようかなざっくりですけどね でもソースコードいっぱい出てきたらあれなんでちょっと見ますけど
んー まあ なるほどですねめっちゃ短いわ
短いけど明日ですかね 読むとしても はい
で続いてプライバシーサンドボックスAPIのリリースというのは2023年クォーター3ですね まで延期されていてサードパーティークッキーの段階的な配信というのは2024年後半まで延期されています
あ ちょっと伸びたんですね まあこれはでもちょっと僕らからありがたい話ではあるかもしれないですね
人によってはもう早くやってしまいにしないっていう人もいるかもしれないですけど 新しいロードマップは次のサイトで公開されていますと
how we are protecting your online privacy っていう記事がありますね ここもあるので見てみてくださいと
はい 長いな このプライバシーサンドボックスfor the web のその具体的なところですね
かなり長いです はい
で続いてですね じゃあ続いての記事として えっと静的タイトルジェネレーターのドキュザウルスですね
はい あー懐かしいですね ドキュザウルスちょっと触ったんですけど結局使わなきゃいけなかったね 一応なんか自分のあのホームページ
あれじゃないですか 本当個人として自分自身のホームページがありますけど 僕これに一時期ですね そのドキュザウルスを使ってあのホームページ作ってました
ドキュザウルスは本来そのOSSとかその静的タイトルジェネレーターのためなので まあいろんなOSSのホームページを作る向けにはいいなと思ったんですけど
別に自分がやってきたこととかも意外と多かったり その副業したりとかいろんなコミュニティ参加してるとかっていう人であれば
あのドキュザウルスで自分のホームページを作るのも全然悪くないと思いましたね ただまあある程度デザインはちょっと似てくるかもしれないですけどもそれでも
ドキュザウルスは僕悪くないと思ったので もしあのなんか困ってるなって人いたらあの
見てみてもいいかもしれないですねドキュザウルスですね はいこれのバージョン2がリリースされましたと
はいで今回はMDXのサポートサイドバーが自動制作 サイドバー作ってくれたなありがてーなるほど
あとプラグインシステムが刷新されてあのテーマの再構築などの変更も行われてますよ とかですね
ドキュザウルスが1から2がリリースされるまで4年ほど経ってます 長かったっすね
今後のメジャーアップデートっていうのは数ヶ月内でより頻繁にアップデートしていく方針のようです ということでセマンティックアップデートの方針に切り替わったそうですね
はいで続いてエレクトロンのバージョン20ですねメジャーバージョンがアップになったようです ついに20ですかいやーエレクトロンも歴史長いですからねほんと
いや素晴らしいなGitHubすごいなほんと はいで今回はクロミウムの104
おお104か割と最新ですねとあとノードのバージョン16.15.0 V8か V8のバージョン10.4へと依存がアップデートされてますよと
18:07
あとノードインテグレーショントゥルーとサンドボックスフォルスの組み合わせを設定しない限り はレンダラーズがデフォルトでサンドボックス化されるように変更されていますよということでした
はい じゃあここからはヘッドラインですね
はいヘッドラインですけど大体リリースのとってみた感じですね はい一つ目ですけどもビューユーズっていうライブですねビューユーズのバージョン9がリリースになりましたよと
はいちょっと僕全然知らないライブラリだったんですけどはい イズサポーティッドをREFのブーリアンですね
あのなんだっけ ジェネリティクスですねジェネリティクスのREFブーリアンになりましたよということですね
であと型名をユーズなんちゃらっていうプレフィックスに統一になりましたと で多くのユーズ関数の引数に関数を渡せるようにビューユーズスラッシュマスみたいなパッケージの追加になったとか
いろんなものが変更になりましたよということでした 続いてノードジェスのリリースですねノードジェスのバージョン18.7.0がリリースになりましたと
はい で今回はプロセスドットイグジットの各コードですねのコードに数値以外を渡すケースを
デプリケートという変更にしましたと あーなるほどコードのところはもう完全に数字を入れてくださいとですね
プロセスドットイグジットなんてまあその名前通りですねプロセスを止め終了させるための コールする関数ですけどその中の数字ですねコードっていうのが
httpステータスコードですねがもう数字だけになりましたよと あとはカスタムイベントの実装とあとhttpサーバーにドロップリクエストのイベント
なるほどねドロップイベントが実装されたんですね ドロップリクエストですねはいはいはい
まあよりこれでコントローラブルになったって感じですね はい
まあカスタムイベントも実装されたというのは結構大きいかもしれないですね じゃあ続いてえっと
ビデオデブっていう オーガニゼーションの hls.js ってやつですね
はいのバージョン1.2がリリースになりました hls 確か拡張してたんだったっけ
動画のファイル拡張してた気がしますけど hls.js のバージョン1.2がリリースになりました
今回でIE11のサポート終了お疲れ様でした あとCMACCのサポートこれはちょっと僕が分からないです
あとバグ修正安定性の向上などなどって感じでした はいであとは先ほど見せましたエクスパンディングテスティング
for the privacy sandbox for the web でそのプライバシーサンドボックスのロードマップの
更新ですよということですね まあ改めていくとプライバシーサンドボックスへのリリースは
2023年のクォーター3 まで延期されてサードパーティークッキーの段階的な廃止は2024年の
後半まで延期されましたよということでした 続いて
blueboat っていうライブラリですかね GitHub のロスフェアの blueboat っていうライブラリですね
all-in-one multi-tenant serverless javascript runtimeって書いてますね クラウドフェアワーカーズのような v8
isolates でマルチテナントを実行できる javascriptの実行環境 あっそうなんや
私かなりクラウドフェアワーカーズに似た環境ですねそうすると エンジンはラストで書かれていて実行する javascript っていうのは
21:06
fetch API やリクエストレスポンスのようなウェブ標準の
互換性を持った API が一部利用できるようになりますと ラストで書かれてるのが結構ホットだな
なるほどちょっと気になりましたねこれは はい blueboat ってやつですね
で先ほど言いました次ドキュザウルスのバージョン2がリリースになりました っていうのと
エレクトロンのバージョン20がリリースになりましたよというところでした 他アーティクルですけどもこれは一つ前回
前々回かな読んだ新しいviewportの単位ですね sv lv と dv ってやつですねとりあえず真ん中
dv 使っていればいいんじゃないかっていう気はしますけどね CSS のviewport のユニットについての記事
ユニットって単位のことですねについての記事ですと もう一個の記事は help picker syntax for css
netting っていう感じですね chrome developers の記事ですねはい
developer.google.com っていう皆さん応用いたしの記事ですけど
はいヘルプピッカーシンタックス4 css ネッティングですねなお css のネスと
コーブについてのアンケートですねこれははい scss レススタイラスのようにネストする
ケースとアットネストを使うケースとあとブラッケットを使うケースについての 意見をちょっと募集してますので
皆さん興味あればここのアンケート回答してみてくださいと 一応リンク上のツイートしますので見てみてください
続いてスライドとか動画関係です今回一つですねはい 今回はムーンっていうものがあるらしいんですけどムーンで
モノレポ管理するのとあとはパッケモンかパッケモンでの cgs-esm のデュアルパッケージ
っていうところですね モノレポ管理ツールのムーンと cgs-mjs 対応の
ライブラリービルドツールのパッケモンですねについてのスライドがありますよってところでした
はいまあ僕名前しか知らないんで両方とも使ったことないのでちょっと興味ある人は 見てみてください
あとはソフトウェアツールライブラリ関係です ハイプスクリプトって何ですかっていうのがある
ライプスクリプトの型システムをタイプスクリプトの型で実装したもの っていうのがあるんですね
ハイプスクリプトってのがあるらしいです
asimplifiedimplementationoftypescripttypesystemwrittenintypescriptowntypesystemって書いてますね
そのままでした
続いてあとsafejsonvalueっていうライブラリーですね
json serialization should never failってことですね
例外を投げないjsonのシリアライズを提供するライブラリー
シリアライズできないときはエラープロパティにエラーを入れて 例外となる値は結果から除外するなどしていますと
あとはスケルトンですね
スベルトとテイルウィンドウを使ったUIコンポーネントライブラリーのスケルトンってのがあるんですね
これは知らなかったな
っていうのがあるのでこれも見てみてもいいかなと
僕は見てみたくなりましたね
ラストですね書籍関係として
typescriptとreact-nextで作る実践ウェブアプリケーション開発っていう書籍が議論評論書から出ましたということですね
next.jsの入門本として新しく2022年
24:01
今年の7月22日に発売になりましたということなので
興味ある人は見てください
この辺は結構情報キャッチアップされている方すでにご存知かもしれないですね
tsとreact-nextで作る実践ウェブアプリケーション開発というところでした
はいでは以上で今日の朝開通はこれで終わりにしたいかなと思います
最初のドキュメンテーションの話も結構大事なことなので何度読んでもいいと思いますし
人類はずっと繰り返すことになると思うので
また何ですかね数年後同じような記事がどうせ出てくると思うので
また同じようなものを読んでいる可能性がありますけどそれだけ重要だよということですね
大事なものほどやっぱりずっと続くなっていう印象があります
あとはいろいろ最後jsainfoで更新がバーッと出たので
その辺も見てもらってもいいかもしれないですね
とりあえずサードパーティークッキーの話は僕は結構なるほどってなったので
これはありがたかったですね
というところで朝方はこちらで以上にしたいと思います
火曜日ですね今日もまたお仕事頑張っていけたらと思いますし
もし外でられる方は体調管理だけ気をつけていただければなと思います
では今日もご参加いただいたたくさんの方々ありがとうございました
また明日も何かを読んでいきますのでテックな記事を読んでいけたらなと思います
では終了しますお疲れ様でした
