Books/product design #82
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| 文字情報を表示する単純なプラットフォームから、高機能なアプリケーションを動作させるために成長や変化をし続けてきました。この急速な変化は、過去の技術やアイディアの痕跡を残しています。 | ||
|
|
||
| Web の起源は、情報を公開・共有するためのものだと記憶しています。 | ||
| 最初の Web ブラウザと Web サーバーは、CERN（ヨーロッパ原子核研究機構）のティム・バーナーズ＝リーによって 1989 年に考案されました。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/max-kanji-continuous-len> reported by reviewdog 🐶
漢字が7つ以上連続しています: 原子核研究機構 (ja-technical-writing/max-kanji-continuous-len)
| Web の基盤として低レベルの技術を優先することを提案されています。より高レベルな抽象化の負担はエコシステムの外側、つまり開発者コミュニティやライブラリ、フレームワークの作者たちに委ねられているのです。 | ||
|
|
||
| ### 低レベル技術の優先 | ||
| 「Extensible Web Manifesto」の考え方は、基本的には、新しい Web 機能や API を開発する際、その根底にある低レベルの技術を先に公開することを推奨しています。これにより、コミュニティがこれらの低レベルの機能を使用して実験や試作を行い、最終的には高レベルの API や抽象化を生み出すことができます。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/ja-no-redundant-expression> reported by reviewdog 🐶
【dict5】 "試作を行う"は冗長な表現です。"試作する"など簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict5 (ja-technical-writing/ja-no-redundant-expression)
| また、現代の Web 開発では、ツールのエコシステム（例：pnpm、Rollup、Vite など）にも精通している必要があります。これは、開発の効率や品質を向上させるためのステップとなります。 | ||
|
|
||
| ### 学びと修正 | ||
| 多くのプロセスをよりシンプルで迅速にするための抽象化を設計しています。これは良いことだと思いますが、問題は「何を」ではなく「どのように」にあると感じます。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/ja-no-weak-phrase> reported by reviewdog 🐶
弱い表現: "思います" が使われています。 (ja-technical-writing/ja-no-weak-phrase)
|
|
||
| 問題を解決するための知識（具体的には Web プラットフォームの知識）があるとき、抽象化がそれを妨げるときがあるでしょう。それにフラストレーションを感じます。 | ||
|
|
||
| Web プラットフォームの形状が均一でないことは、一見すると開発者にとっての大きな障壁のように思えるかもしれません。しかし、実際には、多くの開発者はこのプラットフォームを既に熟知しており、その特性を上手く利用しています。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/ja-no-weak-phrase> reported by reviewdog 🐶
弱い表現: "かも" が使われています。 (ja-technical-writing/ja-no-weak-phrase)
| ## 必要な脱出口 | ||
| ### 抽象化の問題点 | ||
| 抽象化が不十分または過剰であると、抽象化を貫通して内部で作業することが必要になる時があります。ときには、抽象化を使用しないことがあるでしょう。 | ||
| しかし、フレームワークがアーキテクチャの中心に位置するため、抽象化から外れるのは難しいことがあります。フレームワークは、特定のフレームワーク向けに書かれており、それなしでは実行できません。これに対処するために、フレームワークは、開発者がより低レベルにある primitive にアクセスできるように、抽象化に意図的な穴、小さな脱出口を提供していることがあります。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/max-ten> reported by reviewdog 🐶
一つの文で"、"を4つ以上使用しています (ja-technical-writing/max-ten)
|
|
||
| 特に大規模な場合、フレームワークを使用して開始しますが、ある時点でフレームワークを超えたり、長期間停滞したりすると、切り替えたくなることがあります。フレームワークはコードの形を変えるため、移行が難しいことがあります。ライブラリとの接触面は通常非常に小さく、1 つのライブラリから別のライブラリへの切り替えは、影響範囲が小さいタスクとなります。 | ||
|
|
||
| 脱出口はどんなライブラリやフレームワークにも絶対に必要になると考えています。すべてのユースケースを予測することは可能でしょうか。脱出口を提供することで、開発者は制限を回避して作業を続けることができます。エスケープハッチの欠点は、特にフレームワークにおいて、開発者がプラットフォームまで全体を落とすことが多いことです。これは、開発者にとって課題となることがあり、以前フレームワークが行っていた作業を再度行う必要があります。フレームワークとプラットフォームの間のギャップが大きいほど、開発者にとっての作業は増えます。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/ja-no-redundant-expression> reported by reviewdog 🐶
【dict1】 "することは可能でしょ"は冗長な表現です。"することは"を省き簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict1 (ja-technical-writing/ja-no-redundant-expression)
| ## パターンの再利用 | ||
| #### 抽象化の課題 | ||
| 抽象化での課題として、既存の Web プラットフォームのパターンを再利用しない傾向があります。 | ||
| 開発者が新しい方法を学ぶとき、”イディオム"（ある特定のコミュニティや技術の中での一般的な方法や慣習）や"純粋さ"（例えば、一貫性やシンプルさ）のためだと、不満を感じるように思えます。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.jtf-style/4.3.5.二重引用符> reported by reviewdog 🐶
"の対となる"が見つかりません。"" (jtf-style/4.3.5.二重引用符)
| ## パターンの再利用 | ||
| #### 抽象化の課題 | ||
| 抽象化での課題として、既存の Web プラットフォームのパターンを再利用しない傾向があります。 | ||
| 開発者が新しい方法を学ぶとき、”イディオム"（ある特定のコミュニティや技術の中での一般的な方法や慣習）や"純粋さ"（例えば、一貫性やシンプルさ）のためだと、不満を感じるように思えます。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/no-unmatched-pair> reported by reviewdog 🐶
Not found pair character for ".
You should close this sentence with ".
This pair mark is called double quote. (ja-technical-writing/no-unmatched-pair)
| **層状の抽象化** | ||
| それぞれのレベルでの抽象化を提供することで、開発者が自分のニーズや好みに合わせて最も適切なレベルを選択できます。 | ||
|
|
||
| 結局のところ、開発者のニーズや背景を理解し、それに合わせた抽象化を提供することで、技術の採用や成功の確率を高めることができます。これは、技術だけでなく、コミュニティや教育の側面からも、より多くの人々にとってアクセスしやすく、使いやすいものを作るための鍵となります。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/max-ten> reported by reviewdog 🐶
一つの文で"、"を4つ以上使用しています (ja-technical-writing/max-ten)
No description provided.