以前noteに書いた記事ですが、管理上こちらにも転載。 なるべくドメインを表現したコードにしよう、というのはそりゃそうなんだけど、ちょっとした記述方法だけでもドメインが持っていた意図は容易に失われる（だからこそどうやって表現を残すか考えないといけない）っていう趣旨のエントリでした。 ドメインにはドメインの都合があるし、コードにはコードの都合があるんだよね。完全にどちらかに寄るわけじゃないけど、後世の人にとって都合の悪い寄り方はあると思う。 例えば区分コードみたいな値が有ったとして、1の時は○○という処理、2,3,4の時は△△という処理を実装する、という状況のときに、条件分岐が「区分コードが1か、それ以外」で分岐させると、2,3,4と限定しておきたかった、というドメイン知識が失われたりしませんか？みたいなことが有ったり無かったり— magnoliak🍧 (@magnolia_k_) 202

Webで使えるmrubyシステムプログラミング入門 作者:近藤宇智朗発売日: 2020/11/25メディア: Kindle版 この手のミドルウェア・プログラミング言語の入門・解説書、ひたすら語り口を優しくしているだけだったり、単にリファレンスをなぞっているかのどちらかで、教科書的な硬さとかが鼻につくんだけど、この『Webで使えるmrubyシステムプログラミング入門』は全然違う。次元が違う。 明らかに、”現場で経験値の高い先輩から指導を受けている”ような錯覚を感じさせる内容、流れになっている。 今後、この手の入門書は全部こんな感じでお願いします（あとは公式リファレンス読むんで！）と言いたくなるくらいの良書。マジで良い。 環境がmacOSを使いつつ実際のプロセスはVirtualBox上のLinuxで進む(ちゃんと両方使う前提になっている) 冒頭でmrubyのビルドの解説をする際に、さらっと「デ

ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本 作者:成瀬 允宣出版社/メーカー: 翔泳社発売日: 2020/02/13メディア: Kindle版 先日開催されたObject Oriented Conferenceに象徴されるように、最近設計論の議論が盛んでですね。設計論と言えば、「エリック・エヴァンスのドメイン駆動設計」、いわゆるDDD本がよく取り上げられてきましたけど、なかなかヘビーな本だし、案外コードは全然出てこないので、読んだ上で「で、どうすればいいの？どんなコードを書けばいいの？」という疑問がわきます。 おなじくドメイン駆動設計の解説書である「実践ドメイン駆動設計」も、語られる順番がDDD本と変えることで併せて読むことで理解を深めることを意図していましたが、やはりコードの少なさは同じくらいでした。 「ドメイン駆動設計入門」は、とにかく豊富なコード例が出てくると

理科系の作文技術（リフロー版） (中公新書) 作者:木下是雄発売日: 2016/10/14メディア: Kindle版 いまさら紹介するまでもないけど、とりあえず作文方法を学びたい時は、まずはこの「理科系の作文技術」を読むことをお勧めする。 最近ブログのエントリをざっと書いてそのまま公開してしまうことが多かったので、少し反省し、それを直すためにこの本を改めて読み直した。そうしたら、タイトルで全部言い切っているのだけど、とにかく「6 はっきり言い切る姿勢」「7 事実と意見」だけは絶対にみんな読んだ方がよい、と思った。 日常的にメールや、ブログの記事など、それなりの量の文章を書くことが多いけど、論文や雑誌の記事など、きちんと他人の目を通した上で公開される文章を書くことは、まずない。一度だけ、雑誌の記事原稿を書いたとき、自分なりにかなりの推敲を重ねたつもりでも、プロの編集の方から見れば言葉使いや、

以前noteに書いた記事からの転載 エクスポートできないので、定期的に少しずつ転載していきます。 いつかちゃんとしたスライドに書き起こしたいとおもいつつ、まだ手がついていないけど、この記事に書いている「プログラミングは、コードと、データと、改修の歴史の3つの要素が絡み合う」を分解していきたい。 コードと、データは本質的には不可分だし、その結びつきを分解できないように密に結合させているのが、改修の歴史なんだ よく「データの寿命はコードよりも長い」と言われるけど、受け継がれたデータは、当たり前だけどそれが作られた当時のコードに強い影響を受けていて、不可分だし、暗黙のうちにコードの特性を引き継いでいる。 つまり、例え直接的にはコードが無くなったとしても、コードの影響が無くなるわけではない。 そして、それらの蓄積が歴史となって、全体を形作っていくんだ。 だから、データとコードの寿命は同じくらい長い

blog.shibayu36.org 先日、id:shiba_yu36さんのブログで、同じジャンルの本を複数同時並行で読み、気になったキーワードを繰り返し選別していって、読書ノートにまとめることで知識の吸収速度を上げる、という内容のエントリが話題になっていた。 確かに同時並行で同じジャンルの本を読むことで、同じキーワードでも複数の視点で考えるきっかけになって、より理解し易いという効果が有ると思う。一方で、自分は元々一冊の本をじっくり最後まで読み切るのが苦手で、だんだんと読み方が雑になって、後半は流し読みくらいになってしまうことがよく有る。 では、どうすれば1冊の方をじっくり読み切って、かつ知識を吸収することができるか、ということを考えてみた。 「目次」と、「はじめに」をじっくり読む 前半部分は並列に読む 中盤まで行ったら最初に戻る メモできる環境を用意する 分からないキーワードは都度調べる

CPANに上がってるモジュール、一つ一つの粒度が小さいから読みやすいし、ドキュメントもテストもしっかり揃ってて挙動を把握しやすくて、自分にとっては最高の教科書だったな 今でも他の言語で分からない時に同じ目的のPerlモジュールを見る事があるし— magnoliak🍧 (@magnolia_k_) 2021年1月7日 自分が学んだ頃の、時代的なものもあるけど、今でもPerlのモジュールは粒度が小さく、ドキュメント、テストがしっかり用意されているので、参考にするにはちょうど良いと思っている。 ScalaのScalatraっていうWAFのメンテナンスに参加しているんだけど、HTTPプロトコルだったり、Webのお作法的なところが分からないことが有ったら、たいていPlackか、Rackのソースを見て理解するところから始める、みたいなことしてる— magnoliak🍧 (@magnolia_k_)

NO HARD WORK!　無駄ゼロで結果を出すぼくらの働き方 (早川書房) 作者:ジェイソン フリード,デイヴィッド ハイネマイヤー ハンソン発売日: 2019/01/31メディア: Kindle版 「リモートワークの達人」を書いたジェイソン・フリードと、ディヴィッド・ハイネマイヤー・ハンソン(DHH)の「NO HARD WORK!」をようやく読んだ。 2018年に原著が出版され、去年日本でも翻訳が出た、二人の最新作だ。 ちなみに、原題は「It Doesn’t Have to Be Crazy at Work」となっていて、「リモートワークの達人」のときもそうだったけど、原題の方がいいなと思う。 なお、「リモートワークの達人」の感想エントリはこちら。 blog.magnolia.tech 今回は「仕事だけに忙しく、クレイジーに働きすぎない」というテーマだ。世の中の働き方がそうなっているこ

いかにして問題をとくか 作者:G. ポリア発売日: 1975/04/01メディア: 単行本 繰り返し読み返すべき技術書、今回はGポリア著「いかにして問題をとくか」を取り上げる。 この本は、本来は"数学を解こうとする教師と学生のため"に書かれた本だ。所謂コンピュータサイエンスの技術書ではない。 だけど以前、この「いかにして問題をとくか」の中心となる”問題をとくための4つのステップ”、「問題を理解する」「計画をたてる」「計画を実行する」「ふり返ってみる」は、まさにソフトウェア開発のステップそのものであり、特に「問題を理解する」に出てくる「条件はかき表されているか」という問いかけを出発点として、ソフトウェア開発で必ず問題化する「暗黙知」について考察するスライドを書いて、そこそこ評価していただいた。 blog.magnolia.tech 個人的にはこの本を最近宣伝されてるような所謂ビジネス書として

プログラミングPerl〈VOLUME1〉 作者:ウォール,ラリー,オーワント,ジョン,クリスチャンセン,トム発売日: 2002/09/01メディア: 単行本 何度も読み返す技術書の話題で忘れてはいけないのがPerlの作者であるLarry Wallが書いた「Programming Perl」。 この本、Perlというプログラミング言語に関する解説書である共に、定期的にブログなどで話題になる「プログラマの三大美徳(無精、短気、傲慢)」に ついて解説されている原典でもある。 この三大美徳…意外と原典ではストレートには語られていない点も興味深い。三大美徳の中身は散々語られているので、ここでは原典でどのような流れで語られているのか調べた。 Perl自体の人気もだいぶ下がっているし、日本語に訳されているのはPerl 5.6対応(20年前!)の第3版しかなく、2012年に出版された第4版は日本語には翻訳

UNIXという考え方―その設計思想と哲学 作者:Mike Gancarz発売日: 2001/02/01メディア: 単行本 前回エントリで紹介した「リモートワークの達人 (ハヤカワ文庫NF)」は何度も読み返すべき本として紹介してもらったのだけど、その時に同時に上がったのが「UNIXという考え方」という本。 確かにこの本は自分も何度も読み直している。 なぜおなじ本、しかも技術書を読み返す必要が有るのだろう。 もうそこに書かれていることは分かっている。特に古い本ならなおさらだ。 この「UNIXという考え方」という本は、原著が1996年に出版され、日本でも2001年に出版された非常に古い本だ。 まだLinuxは2.0の時代、商用UNIXの方が信頼度が高いとされていた時代。 もう書かれていることは何度も語られている、語り尽くされている。 それでも今でも読むべき技術書の上位に位置したままランクを落とさ

リモートワークの達人 (ハヤカワ文庫NF) 作者:ジェイソン フリード,デイヴィッド ハイネマイヤー ハンソン発売日: 2020/07/02メディア: Kindle版 「リモートワークの達人」を読んだ この本はBasecamp社のジェイソン・フリードと、ディヴィッド・ハイネマイヤー・ハンソン(DHH)が書いた「Remote: Office Not Required」の翻訳で、単行本では「強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」」という書名だったものがこの夏に文庫化にあたって改題されたもの。 既に2014年に出版されて散々話題になっていたらしいのだけど、実は全然知らず、つい最近「リモートワークの課題はもう全部この本に書いてあって、DHHたちが通った道だ」と教えていただき、早速買ってみた。 いや、本当に悔しい。 これはコロナ禍以前の、世間でリモートワークがまだ普及し