Booklog 2024
2024-12-31
魏武注孫子, read count: 1, page: 172 ~ 177, pages read: 6
地形篇 第十。 6 つの地形、 通・掛・支・隘・険・遠とそれぞれに応じた戦い方について。敵が十分に攻撃できるくらい弱くても地形によっては勝率は半分だととく。 また 6 つの敗因、走る・弛む・陥る・崩れる・乱れる・北げるは将によるものとする。 地形は軍の助けであるので、うまく利用すれば必ず勝つとす。 また将の話にも触れ、将は必ずしも君子に従うべきでない(状況に臨機応変であるべき)、 兵を大切にすることで従わせる(ただしそれだけでは統率できない)と、以前の話を繰り返す。 「六種の地形」四方に通ずる通では先んじて高い南向きの地の得て両道を確保し敵を討つ。険阻で互いの勢力圏が交錯する掛では的に備えがなければ討てる。 自軍も敵も出る利がない支では敵を半分ほどおびき寄せて討てば利がある。 山間の谷間である隘では先に自分を満たせれば、山川や丘陵である険では先に南向きの高い地を得れば、待って敵を打つ、そうでなければ敵を追わない。 互いに遠い遠では勢が等しければ戦う利がない。 地の利を得られなければ戦わない徹底さからも地の利を得るための軍争の重要さがわかる。
2024-12-30
ピアリング戦記 日本のインターネットを繋ぐ技術者たち, read count: 1, page: 8 ~ 24, pages read: 17
第 1 章 ピアリングを巡る静かな戦い。 BGP で繋がる個々のネットワークを AS(Autonomous System) と呼ぶ。 AS は ISP やコンテンツ事業者、データセンター事業者、学術機関や大企業などが運用し、世界で一意の番号 ASN(AS Number) が割り当てられている。かつては 16 bit だったが 32 bit に拡張された。 BGP により接続しあった router を peer と呼ぶ。 peer は互いに経路情報を交換している。 AS 内の IGP は RIP, IS-IS, OSPF などがあるが、 EGP である BGP は AS 間の力関係や金銭を勘案した調整ができ、それを policy と呼ぶ(Local Preference, AS_PATH Prepend)。 AS の力関係はトラフィック量で決まり、大手から Tier 1, Tier 2, Tier 3 に分かれる。 AS 同士の接続は transit と peering がある。いずれも BGP で接続するが、 transit は金でより大きい AS と従量課金で接続、 peering は相互の AS のメリットがあり無償で接続する形態である。 peering では相互の AS でネットワークの到達性を高める動機がなく、 AS 自身とその下位の AS へのトラフィックは送信されるが、 transit を経由したり peering をまたぐトラフィックは送信しない形態が多い。 peering をする動機は、大手が自身のトラフィックを獲得して transit のサービスを成立させたり、 transit のトラフィックを減らしコストダウンを図ったり、通信品質の担保、スケールアウトのため等がある。 peering を解消するのを depeering といい、相互の AS にメリットがなくなったり政治的な事情で行われることがある。 めちゃくちゃビジネスライクなんやなというのを第 1 章で理解した。
2024-12-29
ピアリング戦記 日本のインターネットを繋ぐ技術者たち, read count: 1, page: 1 ~ 7, pages read: 7
第 1 章 ピアリングを巡る静かな戦い。 ピアリングは BGP の形態の一種で組織のネットワークとネットワークを繋ぐので、 ISP 同士のビジネスの力学が働いたりする。 Internet は internetworking のことで、ネットワーク同士を繋ぐことで成り立っている。 これは雑に言うと router が routing table に基づき next hop に packet を送信することの集合で成り立つ。 ここで機械的に動的な routing の仕組みが必要になる。 ネットワーク内の routing protocol は IGP(Interior Gateway Protocol)、 ネットワーク間の routing protocol は EGP(Exterior Gateway Protocol) と呼ばれる。 この EGP で BGP(Border Gateway Protocol) が使われる。
2024-12-28
ピアリング戦記 日本のインターネットを繋ぐ技術者たち, read count: 1, page: i ~ viii, 129 ~ 142, pages read: 22
はじめに と あとがき を読んだ。 インターネットを作り出す人の営み、特に組織同士をつなげるピアリングという日本のインターネットを構築する形態について、 2011 ~ 2021 年の発展・変遷をまとめてるぽい。 わたしはピアリングも知らなければ BGP も知らないので興味深く読ませていただく。 目次に「堂島問題」と出てきたところでデータセンターのらへんのやつかと笑ってしまった。
2024-12-27
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 297 ~ 314, pages read: 18
第 11 章 有限状態機械プロパティ サーキットブレーカーのモデルを書いて FSM(有限状態機械) プロパティを書いていく。 テスト対象の挙動を理解してないとかけないとか、テスト結果の統計情報からテストが期待した分布になるよう重み付けを調整したりとか、これまでの章で学んだことを活かしている。 PropEr では～という話なので FsCheck でどうしよう...というところではあるが、この辺りの感覚は共通して参考にできる。 付録は飛ばした。これでこの本は終わり。あとは本でシミュレートしたのを実践してかないと。
2024-12-26
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 285 ~ 297, pages read: 13
第 11 章 有限状態機械プロパティ
PropEr では取りうる状態が 1 つでそれがイベントにより遷移していく有限状態機械のモデル化に特化したプロパティがある。
ステートフルプロパティと似ているが、状態の組み合わせが爆発する(前提条件で大幅にパターンを絞らないければならない)ような場合、
各状態に名前をつけることができ利用者がそれを判別できるようなケースに向いている。
例題として circuit_breaker というライブラリを対象にした例が挙げられている。
この場合の取りうる状態は、 ok(遮断されておらずシステムが有効な状態), tripped(障害が多発しシステムが遮断された状態),
blocked(利用者が操作を止めるために意図的にサーキットブレーカーを落とした状態) があって正に状態機械向きである。
2024-12-25
魏武注孫子, read count: 1, page: 166 ~ 171, pages read: 6
行軍篇 第九。 「謀略」兵力は多ければ良いものではない。謀略により敵情を理解すれば後方支援部隊でも敵を破れる。 深謀遠慮もなく敵を侮れば必ず敵に捕らえられる。 「文と武」兵が将に親しんでおらずに罰を与えれば兵は服従しない。兵が将に親しんでいて罰を与えなければ驕り怠惰となり用いることができない。 そのため兵を命令するには文(仁恩)を以てし、統率するには武(軍法)を以てする。 平素より民草に命令を行われていれば服従する。これは将と民草が信頼し合っているからである。 曹操は文を仁、武を法と解釈し、唐の李筌は仁恩、軍法と解釈した。 事例として、諸葛亮が張郃を破った話。
2024-12-24
魏武注孫子, read count: 1, page: 160 ~ 166, pages read: 7
行軍篇 第九。 「自然の情報」自然の変化から敵の動きを知る。木が揺れ動くのは敵が伐採し切り開いたため。 草を結んで障害とされているのは自軍を疑わすため。鳥獣の動きから敵の伏兵や包囲を知り、砂塵から敵陣の動きを知る。 「敵の状態」敵と接触があれば欺き合いであると捉える。敵の使者が謙っていれば進軍・強気であれば退却を疑う。 敵の軽車が先に出れば陣を布いており、人質のない和平は謀略である。走り回っている敵は進軍の機会を伺い、半分進んで半分退けば誘っている。 「敵の情報」(間諜により)敵情を知ることで、飢え乾き、疲弊、軍規の乱れ、兵の離心、といった状況や、敵の戦いの行き詰まりや困惑、 敵軍が休息を狙っていたり奇兵・伏兵をを企てようとしている出方等を把握できる。
2024-12-23
魏武注孫子, read count: 1, page: 154 ~ 159, pages read: 6
行軍篇 第九。 「軍を置く場所」軍は高い場所と陽を好み、丘陵や堤防ではその南側で右に背にするのが地の利とす。 「危険な地形」絶澗(深い渓谷)・天井(水が溜まる地形)・天牢(深い山道)・天羅(網で人を閉ざせる地形)・ 天陥(陥没した窪地)・天隙(谷間の狭い道)という六害の地形から自軍は遠ざかり、敵の背にさせる。 「伏兵のいる場所」群のそばに険阻(高低入り乱れた地)・潢井(池)・蒹葭(草の多い地)・林木(木の多い地)・ 蘙薈(覆い隠せる地)がある場合は伏兵がいると考え慎重に探索せねばならない。 近くにいて動かない敵はその布陣が険阻であることに頼っており、敵の誘いに乗らない。 ここまでが地形に関する話で、以降は敵情を図る。
2024-12-22
魏武注孫子, read count: 1, page: 150 ~ 154, pages read: 5
行軍篇 第九。 「地の利」行軍するには有利な地形を選ぶ。山では南側を移動し自軍が敵より高い場所で戦う。 川では敵が川を半分渡り水に浸からせた状態で戦う。南側の高い土地に陣取れば水攻めにあうこともない。 湿地ではなるべく戦わず、やむを得ぬ場合は木々を背にして戦う。平地では高い地形を右後ろにし、より低い地形にいる敵と戦う。 この 4 つの地の利は、黄帝が四方の諸侯に勝った所以である。 より有利な高い日向の地形に陣取るには、先に出た軍争が必要ということか。
2024-12-21
魏武注孫子, read count: 1, page: 149 ~ 150, pages read: 2
行軍篇 第九。 前半は行軍する際には地形に応じた方法を取る。軍に適した、避けるべき、慎重に捜索すべき地形について触れる。 後半は敵の行軍に関する情報を収集し、接触した際には「兵は詭道」の考えに基づいた間諜などの駆け引きで、敵の情報収集と分析を行う。 最後に将が兵に命令するのには信頼関係で以て行うべきであるととく。 状況を見るべきであるとかの話であるけど概説しか読んでないので詳細は各節を読んで判断する必要があるか。
2024-12-20
魏武注孫子, read count: 1, page: 143 ~ 148, pages read: 6
九変篇 第八。 「変に備える」諸侯を屈服させるには害を、煩わせるには事業を、飛びつかせるには利を以てす。 敵が来ないこと攻撃してこないことをあてにせず、自軍の備えをあてにする。 「将の五危」軍を全滅させ将を殺すのは必ず五危による。 必死な将は(柔軟さに欠き)殺しやすい。生き延びようとする将は捕虜にしやすい。 将が短期であれば侮って、清廉潔白であれば辱めておびき寄せることできる。 将が民草を愛すれば民を痛めつけることで救いのために煩わせることができる。 事例として五丈原の戦い。廉潔なるは辱む可し。
2024-12-19
魏武注孫子, read count: 1, page: 137 ~ 143, pages read: 7
九変篇 第八。 最初の五つの土地は九変それ自体とあまり関係ないことからテキストに乱れがあるとされる。 戦いは原則通りの正と臨機応変な変があり、道・軍・城・地・君命において変を知り、戦いにおいては常に変に警戒しなければならない。 孫子は将の選択が勝敗を決めるとし、選ぶべきでない将の特徴、必死な将、生き延びようとする将、短気な将、清廉潔白な将、民草を愛する将の「五危」を挙げる。 「五つの土地」圮地(水浸しの地)では宿営しない・衢地(四方に通ずる地)では諸侯に攻められぬよう盟約を結ぶ ・絶地(活路のない地)では留まらない・囲地(山に囲まれた地)では謀略を使う・死地(撤退できない地)では必死に戦う。 軍争篇と九地篇とテキストの重複がある。 「変の必要性」経由すべきでない道、戦うべきでない軍、攻めるべきでない城、争うべきではない地、従うべきでない君命がある。 これらの変を知り、利害を測る必要性をとく。 曹操は九変に対して五変なのは合わせる必要がないか、九を究と捉えていた。九つの変化でなく五つの変からの臨機応変な対応が必要であると考えた。
2024-12-18
魏武注孫子, read count: 1, page: 130 ~ 136, pages read: 7
軍争篇 第七。 「有を与える気」気芯力変の点から攻撃の機会をとく。 気は敵の士気が衰えたとき、心は敵の心が乱れたとき、力は敵が遠くから来たりて疲弊しているとき、変は整った大きな敵陣でないとき。 士気が朝昼夕で衰えていくのを、北宋の梅堯臣は初め中頃終わりの比喩と解釈する。 事例として夷陵の戦い。 「軍の禁忌」八つの禁忌、高い丘に向かわない、丘を背に迎撃しない、偽りの敗走を追撃しない、鋭敏な兵を攻撃しない、 囮に食いつかない、自国に帰る(帰師の)敵を遮らない、包囲する時は完全に包囲しない(一部を開ける)、窮地の敵に迫らない 事例として博望坡の戦い(偽りの敗走)、穣城の戦い、鄴城の戦い(帰師)。 帰師の敵を遮らないのは、敵に必死に自国に「勢」があるため。
2024-12-17
魏武注孫子, read count: 1, page: 126 ~ 129, pages read: 4
軍争篇 第七。 「風林火山」軍を詐術によって変幻自在に変化するさまを風林火山陰雷霆に例える。 風林火山陰雷霆なところを風林火山にしたのは語呂のせいかも？とのこと。 Web で検索して調べるに火と雷霆が速さを表して重複すると捉える説があるが、侵略の勢いと機敏に進軍することを表すと思うので誤読だろう。 「指揮系統」場に応じて鐘・太鼓・旌旗といった命令系統で軍を将の意のままに動かす。 魏武注がなくテキストに問題があると言われているようだが、内容は簡潔でわかりやすい。
2024-12-16
魏武注孫子, read count: 1, page: 119 ~ 125, pages read: 7
軍争篇 第七。 「百里の行軍」長距離の行軍は軍を疲弊させるため、軍争の際には長距離を移動しないことが重要となる。 事例として諸葛亮が孫権に救援を求めた外交を挙げる。 「地の利」敵情を知らない者は交戦できず、地形を知らない者は行軍できず、道案内を用いない者は地の利を得られない。
2024-12-15
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 278 ~ 284, pages read: 7
第 10 章 ケーススタディ：書籍の貸し出しシステム。 前提条件によって収縮が失敗してしまう。前提条件は本物の bug に対してのみ機能するように調整がいる。 PropEr では同じモデルを使って並列テストも実行できる。それがこのステートフルプロパティのサニティチェックになる。
2024-12-15
魏武注孫子, read count: 1, page: 115 ~ 118, pages read: 4
軍争篇 第七。 軍争(敵と勝利を争うこと)は、敵に先んじて有利な地を得ることである。これには「迂直の計」を用いる。 魏武注ではそれを敵軍に自軍が遠くにいるように見せかけ先手を打つこととする(詭道である)。 敵よりも遅く出発しながらも先に有利な地を占めるには、地の利を得てなるべく長い距離を移動しない。 風林火山陰雷霆を実現するには兵を統率し一つにする。 加えて軍の朝昼夜の気に留意し、犯してはならない戦いの禁忌を示す。 「有利な地を占める」戦争の中、将が命を受け軍を編成し敵と対峙して宿営するまでで、先に有利な地を占め勝ちを争う≒軍争ほど難しいことはない。 軍争の難しさは、(策略によって)敵軍には自軍を遠くにいるように見せかけ油断させて利とするところにある。敵より遅く出て先に到着するのを遠近の計(迂直の計)を知る者である。
2024-12-14
魏武注孫子, read count: 1, page: 111 ~ 114, pages read: 4
虚実篇 第六。 「無形になるには」無形であれば熟練の間者や智者にもはかれない。 勝利したときの形は知れど勝利を制した形は無形であるので知る者はいない。 これは形が敵に応じて限りなく変化するためである。 「無形と水」軍の形は水に似る。水が高きから低きに流れるように、軍は実を避けて虚を攻める。 水は地により流れを定め、兵は的により勝ちを定める。このように敵に応じて勝利を得るものを神(しん、人智を超える働き・法則)という。 よくわからなかった「神」を理解できた。
2024-12-13
魏武注孫子, read count: 1, page: 104 ~ 110, pages read: 7
虚実篇 第六。 「無形の防御」敵の虚をつくことを hit and away のようにとく。 敵の守らなけれなならまい所をつくことで、敵は守りを固めた陣を離れ戦わねばならない。 敵に疑わせることで、攻めたい所に攻めさせない。 「無形の攻撃」自軍が無形であれば敵は兵力を分散せねばならず、自軍の兵力を集中して敵の少数の部隊を圧倒できる。 「敵の情報を知る」勝ちをなすには、敵の情報を知り、策略で以て敵の形をあらわにする。 曹操は、軍形篇では為すことができないととかれた勝利を、戦う日時や地形を知ることによって敵への抑止力となり、敵に戦いを仕掛けられないようにできると解釈した。
2024-12-12
魏武注孫子, read count: 1, page: 101 ~ 104, pages read: 4
虚実篇 第六。 「虚の効用」敵の虚(敵がいないとこを行軍し守っていない所)を攻める。 よく攻めよく守るものは情勢が漏れず敵からすれば掴みどころがなく無形・無声(変幻自在で気配もない)となり敵の命運を掌握できる。 「無形」は形がなくなるのではなく、途方もなく大きく変幻自在であり、常なる形がないという意味。黄老思想を背景とする。 「無声」は気配がないこと。老子十四章。 事例は蜀漢滅亡。
2024-12-11
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 270 ~ 278, pages read: 9
第 10 章 ケーススタディ：書籍の貸し出しシステム。 わざわざ失敗するようテストを書いてリリース前にバグを「減らす」(時間とともにバグは必ず見つかる)。 また PBT は確率的なテストなためプロパティ再実行のたびに違うエラーが見つかることもある。 モデルによっては実際のシステムが受け付けるパターンと違う場合がある(例えばエスケープが必要な文字)。 その場合はプロパティで検証したいことによってプロパティを分けるべき。
2024-12-11
魏武注孫子, read count: 1, page: 97 ~ 101, pages read: 5
虚実篇 第六。 先手を打って戦いの準備を整えておくのが実、後手に回り準備が至らないのが虚。敵を虚に追いこめば勝てる。 更に高次になる(策によって？)と自ら虚になり、虚になった軍は無形・無声となる。 無形となった軍は情勢が漏れず敵に把握できなくなる。敵に形を表させ自軍は少数であってもどこからでも攻められ、勝利する。 敵を無形にさせないためには、敵の情報を知る必要がある。そのため策略をめぐらし敵の形をあらわにする。 無形は形の極致であり、間者にも智者にも見抜けない。 軍の形を水のように常形・常勢を持たせないためには、敵の形に対応できる神(策に長けた？)の力を持った将が必要となる。 孫子は形・勢・虚実で臨機応変な戦法を組み立てて勝利するととく。 「虚と実」敵に利を与えるか急所を攻めれば、敵は実から虚に追い込める。
2024-12-10
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 260 ~ 270, pages read: 11
第 10 章 ケーススタディ：書籍の貸し出しシステム。 モデルを使ったテストをする方法として shim (詰め木)と呼ばれる通常の操作を wrap するモジュールを使う。 shim を使ってプロパティを組み立てる。状態に依存する処理とそうでない処理のコマンドの生成は分ける。 shim 、前提条件、状態を進める処理、事後条件の定義は繰り返しが多くなりがち。 それは簡潔さと自明であることの良い兆候である。 決定論的なモデルを記述するのが難しかったり、事後条件で登録したデータを検証しにくかったりする場合、 それはシステムの可観測性など開発の方法を見直す機会しれないというシグナルであると。
2024-12-10
魏武注孫子, read count: 1, page: 84 ~ 96, pages read: 13
兵勢篇 第五。 「勢とは何か」激しい水の流れが石を流すのは勢による。鷙鳥が獲物を仕留めるのは節による。 勢は弩の張り詰めた弦で、節は引き金を引く近さや瞬間のようなものであるとする。 「勢を生み出す勇」軍隊の強弱は形を決まる。勇怯が勢を決める。なお勇を起こすのは気であるらしい。 「権変により起こす勢」敵に見せかけの自軍の不備を見せて引き付け、本来の形により敵を待つ。 勝機を人に求めず権変により起こす勢に求める。 官渡の戦い「之を予へて、敵に必ず之を取らしむ」敵に利を与えその隙をつく。 合肥の戦い「能く人を択びて勢に任す」不利な形ながら奇襲をかけるという権変で勢を得て勝利する。 呉の平定「円石を千仞の山に転ずるが如き者は、勢なり」形と勢の両方で優越したものは竹が自ら割れていくかの如く勢が止まることがない。 「破竹の勢い」はこの杜預の言葉を起源とする。
2024-12-09
入門・倫理学, read count: 1, page: 44 ~ 55, pages read: 12
輪読会のやつ。Ⅰ倫理学の基礎 第 2 章 倫理理論。 徳倫理。近代的な規範倫理学の理論的限界を打破するためアリストテレス倫理学への回帰。 人間が開花するために必要な性格の特徴。規範倫理学は道徳的性格に対処できない。 客観性が曖昧で、相対的である≒ルール化が難しいつまり規範的でない。 流れ的には徳(性格)→義務(行為)→功利主義(結果)。 第 3 章 権利論。 権利は法的な場面でよく用いられるが、倫理的議論の中でもよく用いられる。生存権など。 権利が侵害される場面＝人間の利益や価値が損なわれる場面で問題となる。 自由権、プライバシー権は自由権から派生する(他者を私的領域に踏み込ませない権利)。敵視的に自由はある主の抵抗権であった。 社会権(社会的基本権、生存権的基本権)。個人の生存や維持を国家に要求する権利。 歴史的に自由権により生じた様々な問題を是正するものとして社会権が重視されるようになった。 自由権は消極的権利「～からの自由」、社会権は積極的権利「～してもらう」
2024-12-09
魏武注孫子, read count: 1, page: 79 ~ 84, pages read: 6
兵勢篇 第五。 孫子は勢を巧みに用いることで弱い軍隊でも強い軍隊を破ることができると説く。 まず勢にふれる前に、始めに分数(数で部隊を分かつ)・形名(旗と鼓による指揮系統)・奇正(正面か不意をつくか)・虚実(空虚な軍か充実した軍か)を用兵上の重要な事項とする。 勢は怯と勇であるとし、怯えず勇気を出せば、強大な軍隊にも千仞の山から小石を転がすように勝てるとする(どうも士気でもなく、意図的偶発的な勢いの流れのようなもの)。 「用兵上の重要事項」曹操は奇正を、先に出撃して正面から戦うか、後から出撃して戦うかと注釈する。 「奇正の組み合わせ」正面から戦うか正により敵と会戦しながら、後から出撃する奇により相手の不備をつき勝利を抑える。 奇正の組み合わせは敵によって変化するため無数にある。
2024-12-08
魏武注孫子, read count: 1, page: 75 ~ 78, pages read: 4
軍形篇 第四。 「形で勝つ」形とは度・量・数・称・勝、土地の収穫高を測り動かせる兵力を算出し彼我を比較して勝利に至る。 「明確な勝利に向けて」このため敵軍よりも有利な形を取れば明確に勝利を得られる。 要は物量的な話を述べているのが形、形成が不利でも勝利する事例に関しては「勢」で議論されているらしい。
2024-12-07
魏武注孫子, read count: 1, page: 71 ~ 75, pages read: 5
軍形篇 第四。 「当たり前に勝つ」先述の通り勝つとわかった戦争で勝利するので、勝つことは優れたことではないとする。 これは先に上げた形で以て勝敗を廟算したからであるとする。 実例として官渡の戦いの袁紹と田豊の例を挙げる。
2024-12-06
魏武注孫子, read count: 1, page: 66 ~ 71, pages read: 6
軍形篇 第四。 孫子は戦争には負けない形があるとする。その形とは軍の動静を見せない形と説く。(ここまでが前半) 形をとれば戦う前から処理は決まっている。何故それが分かるかは展開可能な兵力でもって彼我を比較するからとする。(ここが後半) (見せない形とのつながりがよくわからないが？) 形が優位であれば水が低きに流れるように当たり前に勝つ。だが優勢な形を持たない場合は勝てないのか？で篇が終わる。 「負けない形」自軍にできるのは負けない形を取ることのみで、勝てるのは相手が負ける形(隙や油断ができたとき)である。 「形を隠す」敵が守って形を見せないときは勝てないが、敵が攻めに転じたときに形を見せれば勝てる(転じて攻めることが負けにつながることを曹操は示唆する)。
2024-12-05
魏武注孫子, read count: 1, page: 63 ~ 65, pages read: 3
謀攻篇 第三。 「勝利の五つの条件」彼我の実情を把握しているか、兵の多寡による戦い方を知っているか、君臣が戦いの目的を等しくしているか、十分に準備をしてるか、君主が有能な将に裁量を任せているか。 曹操はこれを先にでた五事であるという。 「百戦して殆からず」このように彼我の実情を把握し、どう戦うか正確に判断すれば、何度戦っても危険はない。 この言葉は有名だし状況把握して正確な判断をしていれば～というくだりは理解していたけど、有能な将の裁量に任せているかというところは知らなかったので、新たな気づきかな。
2024-12-04
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 252 ~ 259, pages read: 8
第 10 章 ケーススタディ：書籍の貸し出しシステム。 大規模なシステムの検証はシステムに対して有効・無効なデータを把握するところから始まる。 まず広範囲なテストから始める。エラーの中にはステートレスプロパティが得意とする検査が引っかかることもあり、その場合は調査のためにステートレスプロパティを書くこともある。 早い話が E2E test なので sample のような DB 伴うものは TestContainers でも使わんとこれはめんどくさそうやな。
2024-12-04
魏武注孫子, read count: 1, page: 56 ~ 62, pages read: 7
謀攻篇 第三。 「兵力差ごとの戦い方」孫子は彼我の兵力差によって戦力を変えるべきと説く。 これに対し、曹操は下邳で呂布を降伏させたことから将の能力次第で 10 倍どころか 2 倍でも包囲できると説くが、他の条件が揃ってのことなので参考にならないと後年批判されている。 「将と君主」君主は将を任命したら、将の判断を尊重すべきと説く。礼(仁義)を中心に置く国政と軍政では原理原則が違うため、君主は軍事に介入しないことが重要であるとする。
2024-12-03
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 241 ~ 252, pages read: 12
第 10 章 ケーススタディ：書籍の貸し出しシステム。 現実のシステムのステートフルプロパティでテストする。 大局的な視点からはじめ、徐々に対称を絞り込み、最終的に決定論的で厳格なプロパティにする。 テスト対象となるコードの実装の節なので特になし。
2024-12-03
魏武注孫子, read count: 1, page: 50 ~ 56, pages read: 7
謀攻篇 第三。 「謀を討つ」謀略の段階で敵を討てば戦わずに屈服させることができるとする。 孫子との思想としては戦う善しとしていない。本書はそこからも奇策で以て戦わずに勝利することを指すのが妥当であろうとする。 外交策・離間策で以て相手を屈するのを理想とするが、それが実現できない場合の次善の策としてなるべく早期の決着、やむを得ぬ場合の下策として城攻めを示している。 曹操はこれを敵が謀略を練り始めた段階に先制攻撃をかけることとと理解するが、それは赤壁の戦いで降伏に固執し黄蓋の偽降に敗れた経験による可能性を本書は示す。
2024-12-02
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 231 ~ 240, pages read: 10
第 9 章 ステートフルプロパティ。 シーケンシャルな処理を自動的に並列実行に変換してテストしてくれる。その例。 FsCheck では並列実行する機能はあるけど自動で並列テスト化する機能はないような... 最先端はこういうことができるというレベルの認識で留めておくか。
2024-12-02
魏武注孫子, read count: 1, page: 46 ~ 50, pages read: 5
謀攻篇 第三。 孫子の原則の 1 つとして、戦わずに勝つのを理想とする。 孫子では、戦いを善悪で判断せず、ただ現実にあるものとしてその目的を突き詰めてゆく。 相手を自分に従わせることをその目的とし、なるべく傷つけずに従わせるを善しとする。 「戦わずに勝つ」百戦して百勝するのではなく国を丸ごと取るのを最善とする。これは孫子は戦争は不吉な道具であるとする老子の思想の影響下にあるため。 しかし曹操は中心都市を落とさなかったことで降伏した将に背かれ敗北した経験からか、中心都市を落とすことを「国を丸ごと取る」ことと解釈する。
2024-12-01
魏武注孫子, read count: 1, page: 36 ~ 45, pages read: 10
作戦篇 第二。 「長期戦の否定」兵は拙速である必要があり巧遅は求めない。勝っても疲弊していれば他国に狙われる。 「食糧を奪う」一度戦争を始めたら再び徴兵したり自国から兵糧を送らせない。兵糧が不足すれば敵から奪う。 「敵に勝って強さを増す」降伏した戦車を自軍に取り込み、降伏した兵を優遇し戦わせ、自軍を増強していく。 「兵を知る将」国家に安寧をもたらすのは兵法を知る将である。
2024-11-30
魏武注孫子, read count: 1, page: 29 ~ 36, pages read: 8
始計篇 第一。 「戦わずに勝ちを定める」廟堂で占って戦争の吉凶を得ていたのを五事七計で勝算の多寡を測ることで置き換え、合理的に判断しようとした。 作戦篇 第二。孫子の中でもまとまりよく、一貫して長期戦を避けるべきと説く。 やむを得ず戦争になった場合はとにかく長引かせない。 短期戦でも膨大な費用がかかるので、敵から兵糧、兵や戦車といった戦力を奪うことの重要性を説く。 「一日ごとに千金」大規模な軍隊を遠方に兵糧を伴わせて戦うには莫大なコストを消費する。 実例として官渡の戦いで烏巣奇襲を挙げる。
2024-11-29
魏武注孫子, read count: 1, page: 22 ~ 28, pages read: 7
始計篇 第一。 「兵は詭道」孫子においては戦争は騙し合いであるとする。これは敵の情勢に応じて変化するので先に伝えることはできないとする。 曹操はここに水のように常に変化することで敵に実情を探らせないのも詭道としている。 実例として白馬の戦いと烏桓遠征があるとしていて、これらはいずれも敵の不意をついたもの。
2024-11-28
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 217 ~ 230, pages read: 14
第 9 章 ステートフルプロパティ。 モデルの構築は利用者(運用者)の気持ちでメンタルモデルを構築するところから。 ここでは有効期限がないキャッシュのプロパティのモデルとして FIFO リストを利用している。 ステートレスプロパティ同様より単純な同じ振る舞いをするものを探し出して使うイメージか。
2024-11-28
魏武注孫子, read count: 1, page: 17 ~ 22, pages read: 6
始計篇 第一。 「七計」主・将・天地・法令・兵衆・士卒・賞罰で以て、君主は将が五事を理解しているか測る。後ろ 3 つが五事になくてより具体化された項。 「将の任免」孫子にある計に従う将は必ず勝ち君主に重宝され、従わなければ必ず負け放逐される、みたいな感じ。 「計と勢」計によって有利であることがわかれば「勢」を加えて勝利の可能性を広げる、ということらしい。「勢」は春秋戦国時代に思索された概念で兵勢篇 第五で論じてるとのこと。 ここまでが合理的に勝敗を予想するくだりかな。
2024-11-27
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 212 ~ 217, pages read: 6
第 9 章 ステートフルプロパティ。 生成したテンプレートどの部分に何を書かなければならないか。 実行するコマンドを生成する抽象的なモデルの段階と、実際のシステムを実行する現実の段階の両方で利用される関数がある。 そのためモデルに対する副作用を避けなければならない、とか。 Model-based Testing でも同じなんかな(特に調べた訳では無い)。
2024-11-27
魏武注孫子, read count: 1, page: 12 ~ 17, pages read: 6
始計篇 第一。(本来は計篇だった可能性が高い) まず孫子の原則として、1.戦わずして勝つを理想とする、2.戦争の基本的性格を詭道とする、3. 戦争を合理的に解釈するの 3 つがある。 これらにより、合理的な勝敗の予測、戦争が経済を滅ぼす実践的な説明、戦争を解明しようと試み、現代にも通づる普遍的な組織論といった特徴を持つ。 「兵は国の大事」戦争は国の存亡を左右するので良く洞察しなければならない。五事七計でもって勝敗を予測する。 「五事」戦力を道(民心)・天(時期)・地(地理的優位性)・将(将の能力)・法(軍事力や権力)で測る。みたいなところか？ 面白いが読み解くのがなかなか難しいな。
2024-11-26
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 205 ~ 212, pages read: 8
第 9 章 ステートフルプロパティ。
ステートフルプロパティが有効なのは「コードが何をすべきかは単純だが実装が複雑」なパターン。従来の結合テストやシステムテストが該当する。
形式手法未満のモデル検査の亜種といえる(らしいがわからん)。
モデル・コマンドのジェネレーター・実際のシステムの 3 つのパーツで成り立つ。
システムの振る舞いモデルと検証対象のシステムに、検証対象の操作をあらわす前提条件を与え、モデルと検証対象のシステムを事後条件により確かめる。みたいな感じか。
こういう仕組みは、自動じゃないけど今 pocof の SelectPocofCommand にやってるテストと同じ感じなので、熟達したらかなりイケそうな気がしてきた。
FsCheck 的には Model-based Testing なんかな。
2024-11-26
魏武注孫子, read count: 1, page: 11 ~ 12, pages read: 2
まず孫子と始計篇 第一の概要。孫子は孫武の主張を中核とするが、それを奉ずる学派の共有テキストでもあり、整合性に欠く面もある。 始計篇は比較的まとまっていて、本書では便宜的に段落を分けて読解を導いてくれる。 「兵は国の大事」「五事」「七計」「将の任免」「計と勢」、ここまでが戦争は国家存亡の分かれ道であるから合理的に判断し勝利を導かねばならないという主張。 「兵は詭道」戦争は即ち騙し合いであり人として正しいことが勝利に繋がらない。戦争を所与の条件とし敵の備えのない不意をつき必ず勝利を導かねばならないという主張。 「廟算」戦争における勝ちを定めることの重要性を説き、勝利は合理的に導けるものであるという主張。 2 頁しか読んでないが一旦ここで区切るが良いか。
2024-11-25
入門・倫理学, read count: 1, page: 35 ~ 44, pages read: 10
輪読会のやつ。Ⅰ倫理学の基礎 第 2 章 倫理理論。 義務論(deontology)または義務にもとづく理論(duty-based theory)。 正しい・正しくない行動のタイプ≒義務によって行動を制約される義務論敵制約。 カントの倫理学では、義務にかなっているだけの行為は適法性があるだけで、道徳性はないとみなす 。 定言命法・人間の尊厳・自立としての自由でもって義務を特定できるとした。 ロスの倫理学は一応の義務で義務の衝突を回避できるとした。 ロールズは功利主義の欠陥は幸福の配分に触れられていないこととし、社会契約説によって配分の原理を構築できるとした。
2024-11-25
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 200 ~ 204, pages read: 5
第 8 章 標的型プロパティ。 標的型プロパティの独創的な使い方として通常のプロパティではできない使い方がある。 例えば計算量が爆発して実行時間が伸びるようなケースは、実行時間が最大化する方向にでー他を探す必要があり、通常脳プロパティではできない。 標的型プロパティは仕様やロジックの穴を探すのに特に光るものがある印象。
2024-11-25
魏武注孫子, read count: 1, page: 1 ~ 10, pages read: 10
面白そうだったんで買った。孫子を複数のテキストから定本したのは曹操だという。 そのため曹操の軍事思想を理解しなければ孫子を真に理解するのは難しい。 その思想の背景を知ることは、当時の人がどのように理解し実践していたかを知ること。 曹操はあくまで訓詁学に基づいた注釈を行っていたというのも興味深いな。読書家なんや。
2024-11-24
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 192 ~ 200, pages read: 9
第 8 章 標的型プロパティ。 標的型プロパティで狙いたいのはエッジケース、例えば木構造が片方に偏ってるとかがあってる。 焼きなまし法の計算時間で明らかに通常のジェネレータより遅くなる。 独自に近傍関数を定義することでより効果的な選択をさせることができる。 ただしカスタムジェネレータで狙いのデータを生成するのと同様、ランダムさは狭まる。 このことからも満遍なく多様なデータのプロパティとは分けて考えるべきところなんかな。
2024-11-23
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 185 ~ 192, pages read: 8
第 8 章 標的型プロパティ。 通常のプロパティは各ケースが独立しているが標的型プロパティは後続のケースのデータ生成に影響を与えることができる。 それにより特別なジェネレータを作ることなく標準的なジェネレータで狙ったデータを生成できる。 標準的型プロパティは焼きなまし法(Simulated Annealing)という統計的な手法で値を探す。 初期は山登り法(Hill Climbibg)が利用された。元は探索マクロとして追加された機能。 PropEr の進んだ昨日だけあって FsCheck には Targeted Property なさそうなのでそういう手法もあるのかという程度の理解。
2024-11-22
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 170 ~ 184, pages read: 15
第 7 章 収縮。
失敗したケースを再現する最も簡単な形を探す機構が収縮(shrinking)。
最も簡単な形はジェネレーターにとってのゼロ点、概ね空を指す値だったり中間点を指す。
特殊なケースは例えば初期位置が定まっているデータ。 Unix タイムスタンプであれば 1970 年 1 月 1 日。
このようなデータ構造が複雑な場合は簡単な形が得られないこともあり、その場合は収縮機能を制御する機構を使う。
PropEr はマクロだけど FsCheck だと shrinker という seq を返す関数で表現してるみたい(まだ試してない)
2024-11-21
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 156 ~ 169, pages read: 14
第 6 章 プロパティ駆動開発。 ネガティブテスト。不測のケースを探るのには広範囲を対称とする曖昧なプロパティが適している。 完全にランダムだと満遍なく事例をカバーしにくいので、意図的に予測可能なデータを混ぜていき、ばらつきが狙い通りかは統計情報で評価していく。 またポジティブテストの制約を緩めることで不測のケースを探索するのも良い。 この不測のケースの中には動的型付け言語だから起こり得るものがあり、静的型付け言語の場合だと厳しく型で制約しているから起こり得ないものもある。 とはいえちょいちょい制約子忘れるのでそういった漏れを発見できるかもしれないのは大きそうな。
2024-11-20
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 144 ~ 156, pages read: 13
第 6 章 プロパティ駆動開発。 1つ目のプロパティでカバーできなかったケースのテストを新たに作る。複雑化しないように小分けにする。 これはジェネレーターも同じで、テストしたいパターンを構成する最小の要素のジェネレーターを作る。 それらを組み合わせて複雑なパターンを網羅する。 ここまでは想像の範囲で期待の挙動をするかテストするポジティブテスト(ハッピーテスト)。次節からネガティブテスト。 単純で本実装とは違う形で実装ってのが結構むずそうよなーやり方は色々あるってのはわかるんやけどバイアスかかりそう。
2024-11-19
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 137 ~ 144, pages read: 8
第 6 章 プロパティ駆動開発。 TDD と同じように PDD する。 ポジティブテスト(テストがスべきことの検証)とネガティブテスト(プログラムが処理できないことのテスト)の技法を探っていく。 最初に簡単なプロパティを書き、それを green にするために最小実装、実装後統計を見て妥当性のチェック。 プロパティ書いてジェネレータを書いて実装してって流れは F# だとコンパイルエラーうざそうで先に空実装しちゃいそう。 TDD もなんか苦手やし。
2024-11-18
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 121 ~ 136, pages read: 16
第 5 章 信頼できるテスト。 ココまでで出尽くしてるかのようで特に気づく点なかった。 FsCheck で同じような実習してみるのが練習になりそうやけどまだやってない。
2024-11-17
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 111 ~ 121, pages read: 11
第 5 章 信頼できるテスト。 PBT のアイデアを使った事例テスト。 総当たりの範囲が狭く実行時間も許容できる場合は PBT より事例を列挙するほうが良いケースもある。 この場合原因の追跡のしやすさは劣るが、実例が網羅されるためランダム性は必要なくより信頼性も高くなる。
2024-11-16
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 93 ~ 111, pages read: 19
第 5 章 信頼できるテスト。 これまで学んだ内容を実践する。 モデル化、事例テストの汎用化、不変条件、対象プロパティと事例テストによる固定化(anchor 錨)。 ここでは CSV のプロパティを書くためにまずジェネレータからかいてるが、仕様のコード化という点で TDD に通じる。 プロパティを定義するとその仕様の曖昧さが生み出すというのもいいな。 避けられない既知のバグを正解ケースとして、またプロパティの実装上避けられない暗黙の仕様のテストも事例テストが向いてる。 こういう事例テストの用途はリグレッションテストも該当する。
2024-11-15
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 84 ~ 92, pages read: 9
第 4 章 カスタムジェネレーター。 シンボリックコール。失敗したプロパティの出力が解読不能なバイト列などのデータ形式の場合に使える。 関数呼び出しやその引数をシンボルとして記録し、失敗時にその履歴が追跡できる感じ。 FsCheck にはシンボリックコールそのものはないみたい。それっぽいものを代替手段で実装することはできそうなので参考にはなるか。
2024-11-14
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 76 ~ 84, pages read: 9
第 4 章 カスタムジェネレーター。 再帰ジェネレーター。 繰り返しで作れるデータは概ね可能。 ただし正格評価で呼び出し階層が深くなりすぎる場合があり、そのときは遅延評価することで回避する。 確率的に再帰の終了条件を設定する場合、確率が固定されたり異常なサイズのデータが生成されることもある。 その場合繰り返し回数だけランダムに生成して、データの生成を通常の関数で記述することで軽くできる。 Erlang 力低くてピンとこんが正確評価は FsCheck も同じだし、他のエッセンスも似たようなもんだろうと推測する。
2024-11-13
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 65 ~ 76, pages read: 12
第 4 章 カスタムジェネレーター。 リサイズジェネレーター。生成される値の範囲を狭める。ただし狭めた分ばらつきが得られなくなる点に注意する。 変換ジェネレーター。データの生成と変換がジェネレーターとプロパティに分かれてしまうようなケースをジェネレーターにまとめられる。 またフィルタとして働く制約条件を設けるジェネレータもある。ただし除外されるデータの量が大量だと変換で賄う方が速いケースもあるので注意する。 生成・変換のいずれにしても効率的に欲しいデータを生成するには十分でなく、その場合確率を調整して狙いのデータに近づけることもできる。 ただし CSV や XML のような構造化データの生成には十分でないため更にテクニックがいる。 ここまできたら実際にテスト対象に必要なデータを試行錯誤するのが実践的で良さそうやな。勘所は練習しないとつかめなさげ。
2024-11-12
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 54 ~ 64, pages read: 11
第 4 章 カスタムジェネレーター。 まんべんなくランダムなデータでは発見できると限らない。 限られたエッジケースに焦点を絞るようなテストに最適なデータを、カスタムジェネレータで生成する。 まず統計情報をとりデフォルトジェネレータで生成された値がテストに十分か見極め、不十分ならカスタムジェネレータを利用する。 カスタムのデータ生成はそら欲しくなるよなという印象。
2024-11-11
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 46 ~ 53, pages read: 8
第 3 章 プロパティで考える。 正順の処理に対して逆順の処理を書ける場合はそれが対称プロパティとなる。 対称プロパティそれだけでは整合性を保証するのみだが、不変条件を組み合わせることで強固なプロパティが得られる。 コツとして、複雑な処理をプロパティ 1 つだけで信頼性を高めようとせず、複数のプロパティに分けて段階的に検証していくのが望ましい。 この辺は従来のテストと同じかな。
2024-11-11
入門・倫理学, read count: 1, page: 27 ~ 35, pages read: 9
輪読会のやつ。Ⅰ倫理学の基礎 第 2 章 倫理理論。 倫理理論というツールを使うことで直観的に難しい場面での合理的な判断を補助する。 規範倫理学→帰結主義→功利主義。 帰結主義は良い結果で良し悪しを判断する立場であり、功利主義の良い結果とは関係者の幸福。 功利の原理と結果で判断する行為功利主義の限界を修正するために道徳規則を追加した規則原理主義。 二層理論では直観レベルと批判レベルの二段階で判断する。 多分ザクッと理解する意図の章なので用語を覚えるのからスタートかな。
2024-11-10
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 36 ~ 46, pages read: 11
第 3 章 プロパティで考える。 優れたプロパティの実装は標準的なテストよりも難しいが、習熟するためのテクニックはある。 まずモデル化。単純で正しいと信用できる代替の実装。実行速度に問題があったとしても初手としては意味がある。 複数の実装パターンがない場合には従来のテストケースの汎化をする。どこまでを信頼するかは開発者の判断。 次に小さく分解した部分で常に真となるはずの不変条件を使う。単一の不変条件だと役に立たなくても他の部分の不変条件と組み合わせで信用を高められる。 テクニックがあるとはいえこの辺は実装しつつ習熟するしかないやろな。
2024-11-09
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 25 ~ 36, pages read: 12
第 2 章 プロパティを書く。 備え付けジェネレータとコード化したルールを組み合わせてどテストを書くかってところ。 最初はサクッと書いてその結果からジェネレータを変える等プロパティを調整してく。 結構試行錯誤な印象。あとこの段階では組み込みのジェネレータ知らんことにはどうにもならなそう。 使うツールに習熟する必要あるって話の片鱗かな。
2024-11-08
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 19 ~ 25, pages read: 7
第 2 章 プロパティを書く。 コード化されたルール、ジェネレータ、フレームワークが揃ってプロパティが得られる。 PBT には基礎的なステートレスプロパティとより複雑なステートフルプロパティがある。 あとは PropEr の使い方とか。後ほど FsCheck ではというあたりも自習しておく。
2024-11-07
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 11 ~ 18, pages read: 8
第 1 章 プロパティベーステストの基礎。 従来のテストは単純なツールと多くのコード。 PBT は強力なツールと少しのコード化されたルール。 そのためツールの支援がなければ話にならんということで本で使うツールの紹介。 .NET もテストプロジェクトを分離するし FsCheck も同じ感じでやれそうやな。
2024-11-06
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 1 ~ 11, pages read: 11
第 1 章 プロパティベーステストの基礎。 プロパティベーステストは従来のテストと根本的にアプローチが異なる。 従来のテストは事例を並べるが、プロパティベーステストは「どのような入力を与えても常に同じであるような振る舞い」≒プロパティを定義する。 プロパティベーステストが適さないケースもあり、従来のテストより考えることが多くなり技能も必要だが、素晴らしい結果をもたらしてくれるって感じか。 事例ベースのテストは想像の範囲の仕様を記述するが、プロパティベーステストは想像の失敗をあぶり出す。そうそう、それこそ求めてるものよ。
2024-11-05
実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: i ~ xii, 目次, 索引, pages read: 12
前から FsCheck を使いたいと考えてたが手探りすぎたのでなんか手引が欲しく、ちょうど良さそうな本が出たので積読してた。 少なくとも和書だと PBT について書いてるのがこの本しかないっぽいし。 はじめ PBT 基礎を習って、その後は演習等実践を通して理解を進めていくみたい。良さそうや。
2024-11-04
本を読む本, read count: 1, page: 256 ~ 265, pages read: 10
日本人の読書 - 訳者あとがきにかえて。あとがきのフリしたエッセイ。 短編を行ったり来たりして読む、訳書が悪文でも何度も読み込む。そのため読書技術が発展しなかったといった日本的な読書の特徴について触れられてた。 ただ時代の変化でそのような技術が有用であろう、という締め。なんか感想文チック。読書技術が発展しなかった背景でどう向き合うかみたいな話ではないんか。 読後の感覚的には、(まともな)技術書やビジネス書に限れば読書技術が活かせる気もするので、独学で実践するしかないか。
2024-11-03
本を読む本, read count: 1, page: 247 ~ 255, pages read: 9
15 読書と精神の成長。残すはあとがきのフリしたエッセイぽいので、実質この章で終わり。 良書は読者に多くを求め、積極的な読者も自身に多くを求める。良書は多少難しかろうが脳が衰えない限り読者の成長に寄与する。 そのような本は希少であり、読むたびに新しい発見がある。この限られた良書がシントピコンにつながるわけやな。 個人的に定期的に読み返す本はあるが、それがシントピコンになるかはわからんな。 アカデミックな読み方を修練するしないに関わらず、本を読み続ける習慣の後押しになった気がする。
2024-11-02
本を読む本, read count: 1, page: 241 ~ 246, pages read: 6
14 シントピカル読書―読書の第 4 レベル。 著者の言葉を読者の言葉に翻訳することを良しとしない反対派への反論みたいな感じ。 書籍が正確で読者によって翻訳可能あれば書籍同士は「語り合う」ことができ理性的なコミュニケーションは可能だというのを「原理」と指しているぽい。 なんとなく、書籍は著者・その時代背景や言語の違いがあろうが誤読のない限りは読者の言葉で表現されて然るべきだろうから、反対派の方が的外れな気はするな。 そしてシントピカル読書の段階のまとめの便利な一覧。
2024-11-01
本を読む本, read count: 1, page: 235 ~ 241, pages read: 7
14 シントピカル読書―読書の第 4 レベル。 シントピカル読書の実例。同じ言葉でも意味を違えた使い方をしている著者のグループがあり、 読者の問に即した方をより意味を明確にした読者の言葉で表現したグループとしてとらえ、その中での論争に注目する。 そしてシントピカル読書の手引としてのシントピコン(The Great Books of the Western World)。これ和訳ないのが残念よな。 西欧の思想というか概念の索引ぽいし、現代的な思想の源流を知るのに絶対いいやろ。
2024-10-31
本を読む本, read count: 1, page: 227 ~ 235, pages read: 9
14 シントピカル読書―読書の第 4 レベル。 シントピカル読書の5つの段階。関連箇所を見つける。著者に折り合いをつける。質問を明確にする。論点を定める。主題についての論考を分析する。 分析読書とシントピカル読書で違うのは主体が読者にあること。読者の言葉で著者の理解を顕し、読者の問いに対する著者の答えから論点を見出し、その論考を分析する。 分析の中で意見が対立するとき、独善的に答えを判断しようとするのでなく、客観的で公平な立場でもって分析しなければならない。これが難しいと。 著者の言葉を自分の言葉に翻訳する時に読み違えるなよってことと思うが、読み込むこと以外でどうバイアスを除くかは難しいよな。
2024-10-30
本を読む本, read count: 1, page: 219 ~ 227, pages read: 9
14 シントピカル読書―読書の第 4 レベル。 1 つの主題を定めることの難しさ。曖昧な同一主題をはっきりするためにもまず読書量が必要になる。 ここで点検読書をすることで短い時間で主題に関連した書物を見つけることができる。 技術書の場合、ある意味点検しやすいのかもな。自分の経験でだ身がしょぼい本を「点検」時に見分けれたことないのは多分スキル不足かな。
2024-10-29
本を読む本, read count: 1, page: 208 ~ 218, pages read: 11
13 小説・戯曲・詩の読み方。 小説はなるべく短時間に没入して読んだほうが良い。現実を離れその世界を経験するところに意義がある。 戯曲も同じ様に読むべきだが、舞台を前提としている点で小説のような背景の描写がないので、想像力が求められる。 戯曲も詩も声に出してみると良い。リズムや韻を通して理解できるものがある。 大人になってから戯曲とか詩とか読んだことないわ。挑戦してみるか。
2024-10-28
本を読む本, read count: 1, page: 197 ~ 208, pages read: 12
13 小説・戯曲・詩の読み方。 文学を読むのは教養書を読むのより難しい。なぜ面白かったかを知るのが難しい。 ある意味積極的な受け身でもって感動を妨げぬよう「文学の影響力に抵抗してはならない」 また教養書と同じ接し方で「分析してはならなず」、同じ尺度で「批判してはならない」。 とはいえ教養書と同じ規則が適用できる点もある。 カテゴリ・あらすじ・全体の構成の把握や解釈、作品を楽しんだうえで批判する努力など。
2024-10-27
本を読む本, read count: 1, page: 180 ~ 196, pages read: 17
12 読書の補助手段。 付帯的読書。名著が前の時代の知識を引き継ぐ大きな流れの一部ってのは、技術書でも同じやな。 注釈書や抜粋はチートたりうるため読者自身の思考の機会を奪う可能性がある。 辞書・百科事典は知識の補完に使うが、使うには良い方を知っていたり質問できる知識が必要になる。 今どきだとわからない言葉に対しては検索で済ますこと多いな、と思った。 表面的な理解になるからそこは物理・電子の参考図書でも同じか。
2024-10-26
男のスコッチウィスキー講座 100 蒸留所 巡礼試飲旅, read count: n+1, page: 152 ~ 253, pages read: 102
少し前に Angus Dundee 社の The Double Peat って酒を手に入れたのだけど、アイラとスペイサイドのブレンドらしく、スペイサイドのピーテッドモルトって何だ？と思ってリファレンスとして調べた。 結局わからなかったが。この本はこの本でとてもおもしろいので価値はあるのだけど、 10 年以上前に買ったやつだし、より網羅的な定番の本も欲しいなと思った。
2024-10-25
本を読む本, read count: 1, page: 177 ~ 180, pages read: 4
12 読書の補助手段。 読書に、ある本一冊だけを読む本質的読書と他の助けを借りる付帯的読書とする。これまでの規則は前者に適応される。 しかし誰しもそれまでに読んだ本や経験からの知識があるので、全くの本質読書はない。 経験には日常で得られる普通経験と科学実験のような限られたシーンでしか得られない特殊経験がある。これらは本の種類に応じて関わりが違う。 経験で以て評価するってのは特に手法を説くタイプの技術書に対してよくやるな。結局どっかの誰かの持論なので経験が増えるほどそういう本は批評しやすくなる。
2024-10-24
本を読む本, read count: 1, page: 160 ~ 176, pages read: 17
11 著者に賛成するか反論するか。 反論や判断保留の詳細を述べてる。 反論の根拠として、知識不足・誤認識・推論間違いを示すか、或いは全体的な分析の不完全を明らかにする。 前者のいずれの根拠もなければ、即ちそれは著者の意見にある程度賛成しなければならない。 反論の根拠のケースを挙げると、新事実による情報の陳腐化や、著者自身の時代背景によるバイアス等。 そして分析読書の規則のまとめ。この箇条書き便利やけどもっと早く気づきたかったな。点検読書してたら見つけてたなコレ。
2024-10-23
本を読む本, read count: 1, page: 144 ~ 159, pages read: 16
10 本を正しく批評する。 分析読書の第三段階。批評。批評の第 1 規則。本を理解したと確実に言え、そのうえで賛成・反対・判断保留の立場を明らかにする。 批評の第 2 規則。反論は筋道を立ててすること。けんか腰は良くない。 批評の第 3 規則。反論は解消できるものだと考えること。 読書は著者との対話であるので、最低限理解して著者と同じ目線まで登ってからでないと対話にならない。 「わからない」も批評的判断だが、単に読み方が悪いだけだったり、その本だけで理解が難しいこともある。 読書の成功は知識を得ることにあり、その目的を見失わないこと。誤解と無知による反論がほとんどである。 賛成・反対・判断保留にしてもその根拠を示さねばならない。 まじめにちゃんと読み込んで誠意を持って批評しろよって感じか。
2024-10-22
本を読む本, read count: 1, page: 126 ~ 143, pages read: 18
9 著者の伝えたいことは何か。 第 6 規則 もっとも重要な分を見つけ底の含まれる命題を見つける。命題を自分の言葉で表現できて初めて見つけたといえる。 第 7 規則 一連な分から基本的な論証を見つけ組み立てる。パラグラフ(日本語でいう段落でなく意味段落か)から論証が見つからない場合は命題を拾い集めて組み立てる必要がある。 著者自身の判断(肯定/否定)が 6 で、その理由が 7 。 第 8 規則 著者の解決が何であるかを検討する。解釈の 3 規則(第 5 ~ 7 の規則)から解決できたこと・ぶつかった課題・できなかったことを知る。 この 8,9 のセクションあんまピンときてなくてふわっとしてる。実際に本を読むときにここは〇〇で～みたいに意識的にしないと身にしみて感じられないかも。
2024-10-21
入門・倫理学, read count: 1, page: 1 ~ 26, pages read: 26
輪読会のやつ。はじめに、とⅠ倫理学の基礎 1 章 倫理学の基礎。 現代的な倫理学の基本的な考え方について。 直観(感ではない)はそれだけで自明足りうるが、衝突する場合には理論的に解決する必要がある。 また直観は経験や常識に基づくため旧来の偏見を含むことがある。 合理的な倫理的判断は、事実と価値(観)を区別し、一貫性、公平性が必要となる。 おもしろい。日本の文脈に則した英米系の倫理学入門書という立ち位置みたい。あと BOX に書かれてる内容が本文で出た話を深めて良い。
2024-10-21
People Powered 「ビジネス」「ブランド」「チーム」を変革するコミュニティの原則 遠くへ行きたければ、みんなで行け, read count: 1, page: 286 ~ 318, pages read: 33
輪読会のやつ。今回は宿題。 日本語版解説と書いてるが当書籍のモデル Code for Japan に当てはめて説明してる。 あんま解説って感じではないかな。そういう一例だと思って読むのが良い。
2024-10-21
本を読む本, read count: 1, page: 109 ~ 125, pages read: 17
8 著者と折り合いをつける。 分析読書の第 2 段階、第 5 規則。重要な言葉を手がかりに著者と折り合いをつける。重要な言葉を見つけ、その言葉の指す意味を正確に掴む。 言葉自体は曖昧であり、その言葉を著者と読者の間で同じ使い方をして初めて思想を共有できる。 重要な言葉の探し方は色々ある。日常語でないもの、著者が強調しているもの、他の著者と違った使い方をしているもの。 重要な言葉の意味を掴むには前後の単語を総動員してパズルのように掴む。決まった方法はない。 重要な言葉は複数の意味で使われることもあるが、読み手にわかるようはっきり使い分けているなら曖昧さを含まない。 重要な言葉は単語・短い句・長い句で同じものが表されることもある。これはよりはっきりと読者に理解させたい意味を示す。 この章の規則はちょっと難しいな。概ね何度も繰り返し使われる言葉だったりする気がしてたけど。技術書はそのへん曖昧な言い回し少なくて優しい部類なのかも。
2024-10-20
本を読む本, read count: 1, page: 87 ~ 108, pages read: 22
7 本を透視する。 分析読書の第 2 規則。自分の言葉で要約する。これは「どんな分類か」では主題や目的を把握すること。 分析読書の第 3 規則。本の各部分がどのように統一性を持って順序付けらた構成をしているか示す 。 2 つの規則は密接に関係しているが、分けることで段階的に理解できる。第 2 規則は本の全体像を、第 3 規則は本の骨格を把握する。 分析読書の第 4 規則。著者の問題としている点は何かを知る。意図を組まずして統一性を見出すことはできず、骨格が何のためのものか知ることはできない。 ここまでの 4 つの規則を実践できて、分析読書の第一段階となる。 ここまでひとつの本に深く切り込んで考えようとしたことなかった気がするわ。あーなるほどねという他の知識とのグラフ的な繋がりを作りイメージはあったけど。
2024-10-19
本を読む本, read count: 1, page: 66 ~ 86, pages read: 21
6 本を分類する。分析読書の第 1 規則。フィクション・ノンフィクション、教養書か否か、教養書であれば理論的なのか実践的なのか。 この本は「実践的な」本に分類される。 なるべく早い段階で、できれば事前に点検読書で分類が把握し、特定のカテゴリの中で役に立つ本なのかを見極める。 書名・表題について深く考える。直接的に分類できなくても序文・目次・索引から(それでも分からなければつまみ読みから)のシグナルで分類できる。 ただしシグナル自体にも疑問を以て受け取る必要がある。 ここまで分類に注意するのは、科目によって教師の教え方が変わるのと同じく、分類によって本の読み方が変わるから。 そうか～という感じ。無意識にやってたであろう分類、意識的にやろか。
2024-10-18
本を読む本, read count: 1, page: 52 ~ 66, pages read: 15
5 意欲的な読者になるためには。 何に関する本で、何がどのように詳しく述べられていて、全体として真実またはある部分が真実なのか、それにはどんな意義があるのか。読者は積極的に問わなくてはならない。 書き込みでもって本と対話する。 読書の規則を 1 つずつ練習して滑らかにつなげて習慣とする。 書き込みは付箋貼って昔はやってたけどは長らくやってないなあ。 メモを取っても PAA はやめて PDA 的にやるようになった。時代の流れかの。
2024-10-17
本を読む本, read count: 1, page: 39 ~ 51, pages read: 13
4 点検読書ー読書の第二レベル。 読むに値する本か組織的に「点検」する。表題・序文、目次、索引、帯のキャッチコピー、結び、重要そうな章をつまみ食いする。 表面読みは、一度で理解できなくても最後まで読み通すことで次の読書の土台になる。 目次の点検苦手でやってないからもうちょい気合い入れてやろう。索引は結構気になって見るねんよな。 索引がしょぼい本はあとから読み直すときにつまみ読みしにくねんよな。
2024-10-16
本を読む本, read count: 1, page: 32 ~ 38, pages read: 7
3 初級読書ー読書の第一レベル。 高等教育までには身につけるであろう読書スキルを想定してる。 愚痴が多いけど、そんだけ身についてないやつが多いってこっちゃろな。 素朴に読んでだらこのレベルに留まってんやろからこの先に進も。
2024-10-15
プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 242 ~ 269, pages read: 28
Part 4 Chapter 13 コーディングにおける共同作業 新しい開発者のオンボーディング。これで終わり。 シニア開発者とジュニア開発者の間には、大量の長期記憶の差があり、結果としてシニア開発者の与える大量の情報が認知的負荷をかけ過ぎてしまうことがある。 初心者プログラマの行動を新ピアジェ主義モデルで理解する。初心者プログラマの理解のプロセスは意味波(理解のため抽象と具象を行き来する)に従う。 これらを踏まえたうえでオンボーディングを行うと。 いまこういうことに関わる機会ないのでそういう機会が万一あった時に備えて心の中に留めておく。 一通り読んだので、自分や誰かの理解がイマイチでも認知プロセスのどのへんに問題があるのかくらいは気を使うきっかけは持てたかもな。
2024-10-14
本を読む本, read count: 1, page: 26 ~ 31, pages read: 6
2 読書のレベル。 初級読書(本が何を述べているか理解する)、点検読書(短い時間で素早く全体を把握する)、分析読書(時間の制限なく本の理解を深める)、シントピカル読書(1 つのトピックで何冊も相互に関連付け理解を深める)。 どうも今の理解度だとうまく言葉にできてなそうや。
2024-10-13
本を読む本, read count: 1, page: 1 ~ 25, pages read: 25
積読消化。1 読書技術と積極性。 完全に受動的な読書はなく、情報を受け取るにも積極的に頭を思考して著者の意図を理解する。高度な本であればなおさら。 読書はある意味、教師から学ぶ行為である。ただし問いなおすことはできず、ただ与えられた情報から自発的に理解を深める点では、発見する行為といえる。 今がむしゃらに本読んでるだけなのでこういう本で読み込みのレベルが上がると更に良さそうよな。
2024-10-12
プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 225 ~ 241, pages read: 17
Part 4 Chapter 12 コーディングにおける共同作業 より大きなシステムの設計と改善。 コードベースの認知特性を予測する術として Chapter 11 で出た CDN(Cognitive Dimensions of Notation) から派生した CDCB(Cognitive Dimensions of Code Bases) がある。 13 の次元を持つ。エラーの発生しやすさ、一貫性、拡張性、隠れた依存関係、暫定性、粘性、段階的評価、役割表現力、マッピングの近接度、ハードな心的操作、副次的表記、抽象化、視認性。 エラーの発生しやすさを下げると粘性が高まる等、特性はトレードオフの関係にある。 特性はプログラミング言語・フレームワーク・エディタのようなツールの選択で決まるような制御しにくいものもあれば、コードの構造的・言語的な問題で改善できるものもあるのは救いか。 どの特性を重視するかはチームのスキルセットや好みの問題やろな。言語の選択によってエラーの発生しやすさを上げてまで粘性を高めたいとは思わんかな。 暫定性と段階的評価は REPL でカバーできそうやなと見えるし、言語やフレームワークの選択は固く、それで下げた特性はツールでカバーて感じが好みか。
2024-10-11
プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 209 ~ 224, pages read: 16
Part 4 Chapter 11 コーディングにおける共同作業 コードを書くという行為。 プログラミングは 5 つの活動で構成される。検索・理解・転写・増強・探索。それぞれに異なる認知システムを利用するので適したアプローチが異なる。 プログラミングではゾーンに入るのに時間がかかり、一度割り込まれると戻るのに約 25 分かかるので、戻るための目印を置く＝ロードブロックリマインダ。これは後述のテクニックを使ってる。 割り込みから復帰しやすくするための 3 つのテクニック。 1 コードのメンタルモデルを保存する、 2 展望記憶(TODO のような未来の記憶)を補助する、 3 下位目標のラベル付け(解決ステップを細分化したテキスト)。 割り込みを防ぐための FlowLight わろた。集中してる時赤色点滅してたら気になりそう。マルチタスクできないのはもう昔からわかってるもんね。やらぬが吉。
2024-10-10
プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 188 ~ 208, pages read: 21
Part 3 Chapter 10 より良いコードを書くために 複雑な問題をより上手に解決するために。 問題解決を構成する要素はゴール状態・スタート状態・ルール。最適な方法で状態空間を遷移してゴール状態に到達するのが問題解決。 問題解決能力向上には自動化と範例というテクニックが使える。 自動化は、潜在記憶(手続き記憶)≒無意識にタイプする等の肉体的な記憶。認知不可をかけないが、負の転移を起こしがちなので学びほぐしが要る。 潜在記憶は長期記憶を形成するテクニック(間隔を空けて反復する)で強化できる。 範例は、問題解決のためのレシピを利用した学習。レシピが学習関連負荷を下げて脳が忙し過ぎて記憶できない状態を避け、長期記憶を形成しやすくする。 なんか何事も練習あるのみって感じやなやはり。
2024-10-09
プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 173 ~ 187, pages read: 15
Part 3 Chapter 9 より良いコードを書くために 汚いコードとそれによる認知負荷を避けるための 2 つのフレームワーク。 コードの臭いは構造的アンチパターンで、名前は言語的アンチパターン(概念的)。 構造的アンチパターンはワーキングメモリに負担をかけ、誤ったチャンク化を引き起こす。言語的アンチパターンは負の転移を引き起こす。 コードの臭い。一部は OOP の文脈に依存してたりあまり一般化できるものではないねんよな。エッセンスは FP とか他の文脈にも活きるねんけど。 恐らくそのエッセンスと思ってきたところが認知プロセスに関わる部分なんやろな。
2024-10-08
プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 161 ~ 172, pages read: 12
Part 3 Chapter 8 より良いコードを書くために よりよい命名を行う方法。 略語が指す意味がそれほどコンセンサスが取れてないから略さない方がいい。 キャメルやスネークそれぞれ一長一短あるが全体として一貫性がとれてたらどっちでも良い(でもゼロから始めるならキャメル推しらしいが)。 誤った名前がバグを導くかは因果関係があるとは限らない。 雛形を少なくし、フェイテルソンの 3 ステップで名付けることで品質の高い命名ができる。 コレだけ読むと、キャメル＆ケバブで推奨される動詞が決まってる PowerShell の cmdlet 命名アプローチは勝ち筋やん。
2024-10-07
People Powered 「ビジネス」「ブランド」「チーム」を変革するコミュニティの原則 遠くへ行きたければ、みんなで行け, read count: 1, page: 269 ~ 285, pages read: 17
輪読会のやつ。 これまでの総集編という感じなので特に新しいキーワード等はなかった。 ただ、できませんでしたじゃないねんぞッてあたりや、完璧でなくてもいいが追い求めろよというあたりは、強い気持ちを感じる。 また、もう一度この本を読み直せよって、学び続けることの重要さを示してるあたりもエモくて良かった。 あとは日本語版解説だけなので、これで本編は終わり。
2024-10-07
プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 147 ~ 160, pages read: 14
Part 3 Chapter 8 より良いコードを書くために よりよい命名を行う方法。 名前はコードの大部分を占める。名前の文法を適用することで名前の品質を高め、チャンクを促す、ビーコンになる等して短期記憶・長期記憶を助ける。 命名の難しいのは linting できないとこと感じてるのでバトラー方式の linter ないんかな。
2024-10-06
プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 131 ~ 146, pages read: 16
Part 2 Chapter 7 コードについて考える 誤認識：思考に潜むバグ。 学習した知識が他の分野でも役に立つのを転移(transfer)という。 同じ領域の学習が容易になるのを学習中の転移(transfer during learning)という。 長期記憶に格納された知識が学習に役立つのは学習の転移(transfer of learning)という。名前似過ぎてややこし... 転移にも種類がある。 無意識にスキルを伝達する一般道の転移(Low Road Transfer)、意識して伝達する高速道路の転移(High Road Transfer)、対象の領域の遠近で近転移、遠転移、 学習に良い影響を与える正の転移、悪い影響を与える負の転移。 遠転移はほとんど自然発生することなく、適切に近い領域に転移することがよい学習効果につながる。 負の転移が誤認識を生む。これを抑制するために概念変化(conceptual change)でメンタルモデルを置き換えたり、抑制によって正の転移を促す。 ただし正しいモデルを構築しても古いモデルが邪魔をすることも常に起こり得る。
2024-10-05
プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 109 ~ 130, pages read: 22
Part 2 Chapter 6 コードについて考える プログラミングに関する問題をよりうまく解決するには。 コードの読解にメンタルモデルを利用する。メンタルモデルはデータ構造やパターン。 想定マシンはプログラミング言語が何をしているかを抽象化するモデル。理解の際に記憶に定着した誤ったモデルが利用されることもある。 これらのメンタルモデルは互いに競合せずに問題に適用することもできる。長期記憶のスキーマと強く関連づくものほど有用。 結局のところ身近な概念で振る舞いを表現するから、自身の持つ語彙力が貧弱だと貧弱になりうる。 つまりちゃんと勉強しろよって話に聞こえるよな。メンタルモデルそれ自身もどれだけ手札があるかという話だし。
2024-10-04
プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 93 ~ 108, pages read: 16
Part 2 Chapter 5 コードについて考える コードの深い理解に到達する。 コードの読解に関してクヌース先生だけ別格でわろた。 Coders at Work 家のどっかに積んでるわ。 プログラムの読解には言語能力が強く関係しており、自然言語を読むためのテクニックがコード読解にも使える。 過去の知識の活性化、読解の監視、コードの重要性の判断、変数から推論、コードの可視化、自問自答、コードの要約。 こうやってキーワードを羅列するとフレームワークのようになるけど、こうなると個人的に全然やらなくなるタイプのやつ。 特に手で表を書き出すとかが字も図も下手で苦手なのでなんかいい感じに自分のスタイルに組み込みたいな。
2024-10-03
プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 77 ~ 93, pages read: 17
Part 2 Chapter 5 コードについて考える コードの深い理解に到達する。 変数の役割フレームワークは読み解くときにマーキングの方法だけでなく書くときにも使える。 チャールズ・シモニーのハンガリアン記法の正しい使い方にも可能性がある。 ただいずれも強制力がないからなあ。 どこからコードを読み始めるかという起点がフォーカルポイント。 これってエラーログとかの外的要因で明確なら困らなさそう。 読解するのが目的だとエントリポイントや関数の先頭からとか、より難易度高くなる選択肢しかないんやろな。
2024-10-02
プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 57 ~ 76, pages read: 20
Part 1 Chapter 4 コードをより良く読むために 複雑なコードの読み方。 コードが複雑だとコレまでの手法は通用しない。問題の処理に用いられる短期記憶＝ワーキングメモリが 2~6 個しか同時に処理できないため。 課題内在性負荷＝問題自身の複雑さ、課題外在性負荷＝コードの書き方や読み手の知識不足に起因する複雑さ。 複雑で読めないコードには認知的リファクタリングを施すか、依存関係グラフ、状態遷移表といったツールで理解を深める。 仕事なら認知的リファクタリングという選択はあるかな。趣味プロであえてやる意味ないし好きじゃないな。 妙にリスト内包表記が槍玉に上がっててかわいそう...
2024-10-01
プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 41 ~ 56, pages read: 16
Part 1 Chapter 3 コードをより良く読むために プログラミング言語の文法を素早く習得する方法。 現在の科学でわかっているのは、長い期間期間をかけて勉強した方が長く記憶に留まるということ。 記憶には貯蔵強度と検索強度があり、すぐ記憶から引き出せないのは検索強度が低いから。 この状態を web の検索とかでカバーしてしまうと検索強度が上がらないままになる。 意図的に思い出そうとすること≒想起記憶、また覚えたての概念を他の既知の概念につなげる精緻化≒推敲が強度を高めるのに有効に働く。 素早く習得できたことないので参考にしよ。
2024-09-30
プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 15 ~ 40, pages read: 26
Part 1 Chapter 2 コードをより良く読むために コードを速読する チャンク、感覚記憶、アイコニックメモリ。 パターン、コメント、ビーコンの適切な利用がチャンクを形成するのを助ける。 長期記憶にパターンが充実してるほど、短期記憶のスロットを節約でき、効率的に記憶できるってか。
2024-09-29
プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 1 ~ 14, pages read: 14
Part 1 Chapter 1 コードをより良く読むために コーディング中の混乱を紐解く 知識不足 = 長期記憶、情報不足 = 短期記憶、処理能力不足 = ワーキングメモリ。 長期記憶がストレージ、短期記憶 = RAM、ワーキングメモリ = CPU 。これらはわかりやすく抽象化してるだけであることに注意。 実際は、例えば短期記憶に欠落する情報でも長期記憶内でパターン化された情報を参照して推測したり、相互に作用している。
2024-09-28
プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: iii ~ xviii, pages read: 16
積読消化回。 10 年以上前にリファクタリング・ウェットウェアを読んだ時からこういう本は好きなので。 見た感じワーキングメモリにも触れてるぽい。脳のワーキングメモリを鍛える！もだいぶ前読んだので学びほぐしみたいな感じで臨む。 ファストアンドスローも持ってるけどどこに行ったかわからなくなってるしこの機会に探し出そう。
2024-09-27
ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング, read count: 1, page: 222 ~ 242, pages read: 21
付録。ドキュメンタリアンの採用、ドキュメントに取り組み続けるためのリソース等。 htmltest は知らなかったがすぐ使えそうなので試してみる。あとがきにもあるがあとは実践あるのみよな。 仕事と趣味プロでドキュメントライティングを実践していこう。
2024-09-26
ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング, read count: 1, page: 208 ~ 221, pages read: 14
chapter 11 保守と非推奨化。これで本編は終わり。お気持ち表明みたいなのなくあっさり終わったのが本書らしい気もする。 サービスとドキュメントのリリースを同期するのとか、リファレンスの生成、保守作業の自動化らへん。 7 章でもそうだったけど本書は自動化に慎重派で、 toil を見極めてやれよと。 web ドキュメントが標準の原題だと削除って選択肢はなかなかないやろうな。実際よくページが無くなって困るし。ページ残して新しいのに流すか、自動でリダイレクトか...
2024-09-25
ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング, read count: 1, page: 192 ~ 207, pages read: 16
chapter 10 構成。情報アーキテクチャ出てきた。ずっとやらずに来てるなー。 情報アーキテクチャで利用者がコンテンツのメンタルモデルを作り上げるのを支援するらしい。 作って終わりじゃないので保守に本質があると思うしメンタルモデルを検証し続けるって書いてるけど、それは次の章みたい。
2024-09-24
ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング, read count: 1, page: 172 ~ 191, pages read: 20
chapter 9 品質測定。前半は知らないことが多く、ほーという感じだった。 Textlint は使ってるけど、 HemingwayEditor も試してみよう。測定するまでもなく機械的に改善できるならあらかじめやっておきたいよな。 なんかプロジェクトの KPI を定めるのと同じような印象を受けた。
2024-09-23
ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング, read count: 1, page: 157 ~ 171, pages read: 15
chapter 8 フィードバックの収集とその対応。 課題の完了をユーザに通知するのを推奨してるが、しないとこ結構ありそうな印象。どこぞのクラウドも皆無だったし。 ユーザーコミュニティの設立についてはサラッと触れられてる程度。 People Powered 読んだ感じ思いつきで始めれるもんでもないし、ここで深追いする話ではないからそんなもんか。
2024-09-22
ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング, read count: 1, page: 145 ~ 156, pages read: 12
chapter 7 公開。 結構重厚なフローやけど会社のサービスのドキュメントともなればそういう感じかも。 CD してないと詰むなと思ったが、はじめは toil を実感するためにシンプルに手動でやるとのこと。そうなのか... 自作のツールはリリースノートちゃんとやってないしはじめてみるかー。
2024-09-21
ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング, read count: 1, page: 125 ~ 144, pages read: 20
chapter 6 画像や動画といったビジュアルコンテンツ。 視覚的により読者に理解しやすいが、アクセシビリティの配慮と陳腐化の速さに難しさがある。 インフラ構成図とか書くといつも線が絡まるので、そもそも図を書くの難しいねんよなと思っている。
2024-09-20
ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング, read count: 1, page: 107 ~ 124, pages read: 18
chapter 5 サンプルコード。 目的が明確で簡潔で正確で拡張可能であること。テストされてて自動生成でサンドボックスがあって、みたいな話。 そーいや前 .NET のドキュメントの repo 見たときもスクリプトは分かれてたなー、そういうあれか。つながった。
2024-09-19
ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング, read count: 1, page: 93 ~ 106, pages read: 14
chapter 4 編集。 技術的な正しさと必要うな情報の完全性はやってそうやけどその後の構成とか簡潔さの編集は中々訓練してない難しそう。 フィードバックの受け方送り方。 plussing は覚えとこう。 ストーリーにもあるけどコードレビューと同じなので HRT を意識したいところ。
2024-09-18
ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング, read count: 1, page: 69 ~ 92, pages read: 24
chapter 3 ドラフト。 ドキュメントの構成要素を使い分け、流し読み上等で簡潔に、重要なことははじめに書く。 完璧を目指さず満たすべき要素を網羅してるか注意して初版を書き上げたら一歩踏み出せたと。 なかなか普段ここまで考えて書いてないなって気がするわ。
2024-09-17
ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング, read count: 1, page: 47 ~ 68, pages read: 22
chapter 2 終わり。 ドキュメントのタイプとパターンというのは意識して考えたことなかったので学びになった。 届けたい先に合わせて提供するパターンが変わる。ここは何度か噛みしめるように読もう。
2024-09-16
ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング, read count: 1, page: 29 ~ 46, pages read: 18
chapter 1 終わり。 この本でも届けたい相手のペルソナを作る。「遠くへ行きたければ、みんなで行け」でも「インディゲームサバイバルガイド」でもそんな感じだった。 仕事ではガチでやるのは当然として趣味レベルでサクッと始めるには重いな。呼吸をするようにペルソナを作れるようになれってことなのか。 社内向けにはあえて知識の呪いにかかったまま文書を書くこともあるけど、どうなんやろね。ペルソナにそぐうならいいのかな。
2024-09-15
ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング, read count: 1, page: 1 ~ 28, pages read: 28
前回が軽かったので今回は積読消化回。積み過ぎて日があたってたところのオレンジが褪せてる。 わたしは仕事でサブシステムを作ったら文書や障害対応の手引なんかを書くのは結構好きだ。 それに対し称賛されることもあるけど、逆にしょーもないことすんなと批判されることもある。 書いてもコイツラ読まへんなーという状況も常にあるので、なんかきっかけを掴めたらいいな。 「ドキュメントは機能の 1 つ」、いいなあ。はじめに、は入門 Kubernetes の人。 この本はツールになるべく触れてないらしく、良い。ツールで解決できたら誰も困ってないもんな。
2024-09-14
世界一流エンジニアの思考法, read count: 1, page: 234 ~ 270, pages read: 37
第 7 章とあとがき。コレでこの本は終わり。 わたしは生成 AI の出現で何も不安感じなかったのであんまこの感覚わからんのよな。 実際に仕事でシステムに組み込んだり日常的に ChatGPT や Github Copilot 使って楽させてもらってるが、それ以上のものを感じたことはないな。 中盤のエモいところも、そういうのとは距離を取ったらいいってだけだとアラフォー入る頃知ったわ。 総じてパラダイムシフトに遭っても自分が楽しんで進める道を行こうって話だと認識した。自分の人生は自分で決めろってやつ。 最後に、氏はラッキーという言葉を何度も書いてるが、 Luck is what happens when preparation meets opportunity. と言われるようにそれも積み重ねがあってのことなので見習いたい。
2024-09-13
世界一流エンジニアの思考法, read count: 1, page: 203 ~ 233, pages read: 31
第 6 章。所謂ライフハック。昔 MIND HACKS を読んで以降色々試行錯誤してるのでかなり浅く読む。 休息時間を作るためのタイムボックスとか、エネルギーロスの縮小、フィジカル強化みたいなところ。 氏はテスト値上げるのにサプリ使ってるけどわたしはサプリはなんとなくアダプトゲンしかやらない。 実際にギター弾いたり自重トレしたり読書したりで気分切り替えていくと効果あるよな。 家族いると家事育児で必然的に仕事の枠決まるしある意味生産性は上げざるを得なくなる。
2024-09-12
世界一流エンジニアの思考法, read count: 1, page: 165 ~ 202, pages read: 38
第 5 章。自己組織化されたチーム。 自己組織化されたチームは結構勉強したのでせやなってかんじ。良くない組織だと従業員も子供扱いを求めてるフシあってやな。 「自分以外のものになる」ことは期待されないの、マッコールさんみあるわ。こういう信頼で機能するの、みんなやる気があって真摯に取り組むからやねんよな。
2024-09-11
世界一流エンジニアの思考法, read count: 1, page: 131 ~ 164, pages read: 34
第 4 章。コミュニケーション。 シンプルに伝え、知らないことを恥じずに聞き、 HRT で以て議論する。 特別なことはないが、楽しんだもの勝ちってのはホントよくわかるわ。
2024-09-10
世界一流エンジニアの思考法, read count: 1, page: 96 ~ 130, pages read: 35
第 3 章。脳の負荷を減らす。 この章の話に沿うとわたしは殆ど Level 2 で知識に対して何も制御権を持ってない。 イラチの話はわからんでもないが悪しき大阪のせいちゃうやろｗ 時間をかけて確実に 1 つずつ積み上げていって完全な制御権を得る。理解・記憶・反復やと。
2024-09-09
世界一流エンジニアの思考法, read count: 1, page: 56 ~ 95, pages read: 40
第 2 章は Be Lazy 。コレを 2016 年に読んで、その後ブログに載ってたエッセンシャル思考も読んだんだった。 いま 100% 身についたかというとそうではないかも知れんけど、これがきっかけで自分のやり方が再構築されたのよな。 やっぱいいな Be Lazy は。
2024-09-08
世界一流エンジニアの思考法, read count: 1, page: 1 ~ 55, pages read: 55
メソッド屋のブログで Be Lazy 読んだころからファンなので読み始めた。とりあえず 1 章。 目次見る感じ概ねブログや note で見た内容なのでサラッと読む。
2024-09-07
プログラミング F#, read count: n+1, page: 267 ~ 287, pages read: 21
なんか降りてきてコード引用符の章を行ったり来たりして読んだ。 古いので Microsoft Learn で code quotation のページも合わせて見る。 pocof のクエリに code quotation 使えるよな。動的に関数生成したら速いかはわからんので試さないといけない。 読後、訳者の人 dmmf 本のレビュワの人だと気づいた。
2024-09-06
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 267 ~ 287, pages read: 21
設計を更新するのに型駆動でコンパイルエラー活用してやるって話。 このときにはじめに作ったドメイン文書には触れないんかー。これで本は終わり。 本を通して、 computation や active pattern の F# 機能を活用することあれど、データと処理が分割された FP の特徴を活かして静的型駆動でドメインを表現するテクニックの話だったと理解した。 個人的に気になった F# でのパフォの改善等は触れられてない(link は多少あるか)ので自分でやれってことやろな。
2024-09-05
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 252 ~ 266, pages read: 15
RDB への永続化。 少しテーブル設計に触れてるけど、元々キレイな世界とその他で分けてるのだし、テーブル設計は RDB の事情に合わせてやればいい。 ORM 使わないのはわたしの好みなので良い。補償トランザクションは知ららなかったので調べておく。
2024-09-04
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 240 ~ 251, pages read: 12
永続化。CQS と CQRS は違うと。モデル自体が分かれてるのが CQRS でいいかな。 イベントソーシングのも当然触れられてるが、十分に説明できないとスルーされる。
2024-09-03
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 219 ~ 239, pages read: 21
シリアライズは地道に手で書く感じ。キレイな世界に出入りするための通過儀礼みたいなもんか。 高級なモデルから平易なデータ構造に落とすため single case union すらもシリアライズ用の DTO に丁寧にマッピングする。
2024-09-02
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 188 ~ 218, pages read: 31
FP 的エラーの扱い。 ようやく railway oriented. 明示的エラーといえば Java の検査例外を思い出す。
bind, map からの独自 computation って流れだがわたしはあんま使いこなせてないからなじませたいな。
結局のところエラーの扱いがクリーン()なコードを汚すからその複雑性を DSL に寄せるという理解。
それ自体は好きだが Go のように愚直にエラー処理書くのもわかりやすいといえばそうやと思うので流派かなあ。
2024-09-01
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 167 ~ 187, pages read: 21
FP のテクニックでドメインのパイプラインを繋ぎ終えた。 lifting してて良い。 例外避けたいから次章出直すとのこと。Expecto と FsCheck は試せてないからそのうちやりたい(と言いつつ随分経った)。 部分適用による依存性の注入はわたしもよくやるのだけど、多過ぎると面倒なので Record に詰め込むことをしている。 この章のアプローチでは引数に羅列しているのが、どうなんだろ。 この本でモナドでの実装は詳細に触れないようなので自分で考えな。
2024-08-31
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 155 ~ 166, pages read: 12
パイプラインでドメインを繋ぐ。
例だからか知らんが failwith 使ってるので、好みじゃない。バキバキ副作用やん。更に失敗する可能性のある関数と示せないのがな。
不安になったので先の章を見たら computation で Result 使いつつどうにかする話が出てそうなので、ちょっと安心した。
エラーをどう扱うかも設計時から考えてほしかったな。
2024-08-30
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 139 ~ 154, pages read: 16
FP の話。パイプラインでドメインを繋いぎた本なので後半に進む前にどうしても話したかったんやろなと思った。
ゼロ除算を愚直にサポートするならわたしは愚直に Either(Result) を使うかなと思ったが、 違った。
引数用に 0 存在しない型を作っとくみたい。DDD では多分キレイなドメインの世界ではエラーなぞ存在せぬという意思表示なんやろな。
どこで match で切り分けるかの違いだけなんで、そういう流派という理解。
2024-08-29
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 131 ~ 138, pages read: 8
型だけで設計したので、最終的に関数合成しないのかなとかあんまピンとこないところもある。 Saga という言葉は知らなかった。 長時間稼働するやつは DDD 関係なく必然的にそうなるよなという感じ。
2024-08-29
People Powered 「ビジネス」「ブランド」「チーム」を変革するコミュニティの原則 遠くへ行きたければ、みんなで行け, read count: 1, page: 248 ~ 269, pages read: 22
輪読会のやつ。 ミートアップのレシピみたいな感じ。 あと採用について。やぱ方向性と情熱が同じ方向向いてないと何やっても無理よなと思った。
2024-08-28
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 113 ~ 131, pages read: 19
ワークフローをパイプラインに落とし込む。 サブステップをパイプ処理に当てはめて in/out の型も作る。型しか出てきてない。 依存関係は高階関数でやるのは FP ならそうよなという感じ。
2024-08-27
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 98 ~ 112, pages read: 15
型システムを利用してドメインに不正な値が入らないようにする等。
private construct のくだりはまあわかるが match 使えないの痛いのとテストも書きにくくなるのでそこはあまり好かん。
整合性の部分はまあせやろなという感じ。
整合性を保たねばならないトランザクション自体エンティティでは？というのはそうかも知れん。
2024-08-26
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 83 ~ 97, pages read: 15
レシピをべースにモデル化していく続き。
値オブジェクト・エンティティ・集約はここで例示しつつ触れられた。
NoEquality を使う辺り .NET と一緒に使うことを考えなければその方が simple で楽なのはわかる。
でもいつまでどこまで .NET から離れれるかよな。資産を使った方が楽なものもあるし。
2024-08-25
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 72 ~ 83, pages read: 12
レシピをべースにモデル化していく。
パフォ問題に対するための Unit of Measure が出て来ず Struct とコレクションの単純型だけか。
数値しか使えんし触れないのかな。
2024-08-24
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 54 ~ 71, pages read: 18
定義したドメインをモデルにするための F# のレシピ。 単純型と言う名で single case DU 使ったりしてるがデータ量によっては遅いし、氏の blog であるよな Unit of Measure 使うトコじゃないかなという気はする。
2024-08-23
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 42 ~ 53, pages read: 12
FP 的にコンテキストの構造とかコードの構造とかこうするよなという話。 必要になるまで MSA やらず monolith よなというのはまとも。
2024-08-22
People Powered 「ビジネス」「ブランド」「チーム」を変革するコミュニティの原則 遠くへ行きたければ、みんなで行け, read count: 1, page: 224 ~ 247, pages read: 24
輪読会のやつ。 この章はコミュニティの人をアゲさせるインセンティブ設計について。 会社のエンゲージメントとかと似た印象を受けた。
2024-08-22
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 30 ~ 41, pages read: 12
一通りモデリングのステップをなぞった。 わたしの DDD の理解はかなり浅いが、 Evans に始まりそれいいなと思った人々の我流をまとめてる広義にそう呼んでる認識なので、この dmmf のそれも FP でやるならこうよな、という感じを受けてる。パイプラインのメタファーは好きなのでいいけど。
2024-08-21
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 15 ~ 29, pages read: 15
イベントストーミング終わった。 原著者が Railway Oriented の人なのもあってワークフローを中心にしてる印象で、モデリングにもパイプラインのメタファーが基礎にありそう(勘)。 次モデリングのステップの理解を深めてく感じ。
2024-08-20
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 6 ~ 14, pages read: 9
DDD の紹介。イベントストーミングの途中。 先をざっと見た感じ第 1 部はモデリングに徹するみたいなのでやはり丁寧な印象。
2024-08-19
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: vi ~ 5
冒頭を読んだだけ。なんとなく丁寧な印象を受けた。
Years
Books
- Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう
- People Powered 「ビジネス」「ブランド」「チーム」を変革するコミュニティの原則 遠くへ行きたければ、みんなで行け
- ピアリング戦記 日本のインターネットを繋ぐ技術者たち
- プログラマーのための CPU 入門 CPU は如何にしてソフトウェアを高速に実行するか
- プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ
- プログラミング F#
- ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング
- 世界一流エンジニアの思考法
- 入門・倫理学
- 実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう
- 本を読む本
- 男のスコッチウィスキー講座 100 蒸留所 巡礼試飲旅
- 魏武注孫子