WEB+DB PRESS Vol.136 技術評論社Amazon 表紙に「最終号」と書かれているのが、ちょいと悲しい。 技術雑誌の存在ってなんだろうなと考えてみると、一つ一つの記事の深掘りは当然単行本に比べると浅い。でもすべての技術にたいして専用の技術書が出る訳でもない中、ブログ記事などに比べると、編集者の目を通っていることと、一回あたりのページ数が少ない分だけ入りやすいことで重宝する。それに「今、こういう技術が話題になっているんだな」って、ざっと理解できるのも良い。目の前で使わない技術でも、いつか使う日がやってくる時に、「そういえば、ちょっと前に特集されていたなー」と思い出せるだけでも知識のインデックスとして有効に機能してくれる。 そんな雑誌が無くなってしまうのは、けっこう寂しいし、何か大きな穴が空いてしまった感じがする。でもそれを実感するのは今日・明日ではなく、ずっと先のことだと思うけ

なっとく！関数型プログラミング 作者:Michał Płachta翔泳社Amazon 良い、買おう、読もう、（コードを）書こう、以上！ めっちゃ良いですよ、この本 中盤のプリミティブじゃやりづらい→直積→直和→二つ合わせてADT→値を取り出すためのパターンマッチの解説の流れの疾走感がいいですね— magnoliak🍧 (@magnolia_k_) 2023年8月6日 『なっとく！関数型プログラミング』は、2022年に出版された『Grokking Functional Programming』の邦訳版で、主にScalaを題材として関数型プログラミングを学んでいくための入門書("Grokking"は、完全に理解する、という意味)。あくまで関数型プログラミングの考え方、コードの書き方、良い設計の指針の解説が主眼に置かれているので、Scalaの言語機能の入門書ではない。Scalaの言語仕様を網羅

ソフトウェア設計のトレードオフと誤り ―プログラミングの際により良い選択をするには 作者:Tomasz Lelek,Jon SkeetオライリージャパンAmazon ソフトウェア開発経験の最初の段階で「一つの機能には複数の選択肢が有って、メリット・デメリットがそれぞれ有り、それらはトレードオフの関係に有り、容易には決めることができない」という事実を教えてもらえる機会に遭遇できていれば、その人はとても幸運だと思う。 先輩や上司が一方的に、「一つの確かな方法」をただ伝える、みたいな場面（それが必ずしも一般的にはそうとは言えない方法であったとしても）も多いのではないでしょうか。 どんなに設計上の意思決定ができている人でも、その頭の中では「色々な選択肢の中で悩んで、ベストではないかもしれないけど、前の前の課題に対してよりベターな方法」を選んでいる。でもその思考の過程を見せてくれる人はとても少ない。

レガシーコードとどう付き合うか 作者:めもりーシーアンドアール研究所Amazon めもりーさんの『レガシーコードとどう付き合うか』を読んだ。 これは優秀なプログラマであり、CTOとして経営に参画しためもりーさんならではの1冊でした…とはいえ、果たして人生何周目だったらその経験をここまで分かりやすく言語化できるのか分からない。 簡単に言えば、以下の記事の完全版、というか、経営とエンジニアの両サイドから見た「企業が顧客に価値を届けるという営みにおける”エンジニアリング”とは何か？」というテーマなんじゃないかと思います。 note.com [目次] CHAPTER 01　なぜレガシーコードが生まれやすいのか CHAPTER 02　レガシーコードを改善するための道筋 CHAPTER 03　レガシーコードを読む力 CHAPTER 04　レガシーコードを改善するための準備 CHAPTER 05　レガシ

なぜかiPhoneのpodcastアプリの再生状態がリセットされてしまって、購読しているpodcastの再生回が分からなくなってしまった。 そこで、ふと一番よく聴いている宮川達彦さんのRebuild.fmを第一回から聞き直してみると、丁度10周年（先日のエピソードでそう言っていた）ということで、10年前の空気感が感じられて面白くなってずっと聴いている。 何気なくhttps://t.co/9JjdrBEhcgの第一回を聞き始めたら2013年って言ってて驚いた— magnoliak🍧 (@magnolia_k_) 2023年1月28日 昔のhttps://t.co/9JjdrBEhcg聴き直しを続けているけど、ずっとPerlの話をしている回とか、Dockerっていうのがあってさ！って話をしている回とかあって面白いなー ブログとかだと分からない当時の雰囲気って感じだ— magnoliak🍧

モデル、新規に作り上げる時よりも、手を加える時に、最小の手の入れ方だとアドホック過ぎて将来の負債になる、完全過ぎると工数が爆発して今できなくなる 一方で元のモデルも決して悪くない さて、そんな時どうする？という問いかけに答えられるか？って話ですよ— magnoliak🍧 (@magnolia_k_) 2023年2月10日 この話、要はバランスで終わらせても良くないので、事後評価をどうするかってところを定型化するのかなぁって思ってる— magnoliak🍧 (@magnolia_k_) 2023年2月10日 おそらく教科書的には、抽象度がキープされるように修正しましょう、元の設計者の意図を踏まえて修正しましょう、依存関係のレイヤーが崩れないように修正しましょうって話になると思うんだけど、一方で修正しないといけない”難しくて複雑な”要件が目の前に有り、それを実現することを考えるだけでも設計

引き続きThinkCentre M75q Tiny Gen2上にインストールしたUbuntu Serverの環境構築を続けます。 blog.magnolia.tech メインPCとファイルを共有するためにSambaでファイルサーバを立てることにします。 直接Ubuntu Server上でSambaサーバを立ててしまうと管理が面倒なのでDockerで立てることにします。 Sambaのイメージを選ぶ ネットを検索するとdperson/sambaというイメージを使って構築する事例がよく出てきますが、残念ながらイメージの更新が止まっているようです。 他のイメージを探したところ、servercontainers/sambaというイメージが見つかりました。 GitHubのリポジトリを見たところ、具体的なバージョンを指定するのではなく、定期的にAlpineのイメージを取得してインストールできたSamba

ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用 作者:田中 ひさてる技術評論社Amazon 予約してまで買ったものの、なかなか時間が取れず、読めていなかった『ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用』をようやく読み終わりました。 筆者である田中ひさてるさん自身で描かれた表紙の可愛らしさからは想像もできないハードな内容なので、一気に読もうとすると「分かった気」になるだけで全然理解していなかった、ということになりがちなので、3回くらいぐるぐる読むといいと思います（そうです、この本は本文もイラストも丸っと同じ人が書いているのです！！）。 目次 第1章 クリーンアーキテクチャ 第2章 パッケージ原則 第3章 オブジェクト指向 第4章 UML（統一モデリング言語） 第5章 オブジェクト指向原則 SOLID 第6章 テスト駆動開発 第7章 依存

ソフトウェアエンジニアに必要な資質の一つ目は「エラーメッセージが出たら、読んで理解しようとする姿勢」です— magnoliak🍧 (@magnolia_k_) 2022年12月11日 最近のプログラミング言語の傾向として、エラーメッセージを改善して、より分かりやすいメッセージが出力されるようになっていますね。 gihyo.jp techlife.cookpad.com 上記は、PythonやRubyの事例ですが、最近の言語はどれもエラーメッセージが親切になってきました。 それでも読まないのはなぜなんでしょうね…一番の近道だと思うんでけどね。 とはいえ、エラーメッセージを読むだけで解決するバグばかりでもないので、エラーが解決しない時にさっさと方向転換するのも大事な方針ですよね。 二つ目は「何処で作業を打ち切って方向転換するか判断しようとする姿勢」です— magnoliak🍧 (@magn

［試して理解］Linuxのしくみ　―実験と図解で学ぶOS、仮想マシン、コンテナの基礎知識【増補改訂版】 作者:武内 覚技術評論社Amazon 2022年も良い技術書がたくさん出版されましたが、その中でも『Linuxのしくみ』はぜひ手元に置いておきたい1冊ですね。 特に、主にアプリケーションレイヤーを主戦場としている人たちにとって、OSは各種ミドルウェアと比較すると「よく分からないもの」という存在になりがちです。しかし、OSがなければアプリケーションも動かないわけで、基本的な知識としてこの本に書かれているようなレベルのことを押さえておくと性能が出ない時に無闇に資源を増やす前に考えるべきことの気づきが得られます（無闇に資源を増やす、という選択肢が取れる時代になったのは、それはそれで良いことですが） 特に、前半のプロセス周りは、「sar」「taskset」など自分も今までちゃんと使ったことがない

説明のために手順を確認したので、その覚書。 作業環境にリポジトリを用意する github.com $ git clone git@github.com:isucon/isucon12-qualify.git Dockerをインストールする www.docker.com 値上げが最近話題になりましたが、個人利用は無料です。 www.docker.com 次回はRancher Desktopを試してみます。 rancherdesktop.io docker-compose.ymlを書き換える 一箇所だけ書き換えないと、起動しません。 Docker Hubから「mysql/mysql-server:8.0.29」のイメージが無くなっていて、MySQLが起動できません。8.0.30以降のバージョンを指定しましょう(無くなった理由は探せませんでした...)。 2022/11/06追記 mysql-s

設計の「why」を言語化できる人は強いんですよ— magnoliak🍧 (@magnolia_k_) 2022年10月29日 っていうか、驚くくらい「why」が上手く表現できないんですよ、普通は 手順は言えても、なぜ？が言えない— magnoliak🍧 (@magnolia_k_) 2022年10月29日 設計において、すべての決定について仔細に「なぜ、そうしたか？」を言えるべきなのだけど、これを上手く言語化できない人は多い。「このプロジェクトでは以前からそうしているから」「そうするのが当たり前だと思っていた」などなど、本当に理解してないまま「設計という作業」を進めている人もいれば、上手く自分の行為を言語化できないだけの人もいる。 また、必ずしも自分が設計したことについて説明する場面ばかりとも限らない。既に存在する設計から「なぜ」を類推するしかない場面もある。他人のコードを読み取るとき

原著が出てたときから割と気になっていた「ベタープログラマ」を読んだ。 全体的な感想 第Ⅰ部はコードスタイルや、不要なコードの存在、テストコードを書く話など、非常に実践的な内容が多かった。 第Ⅱ部は割と考え方というか、思想的な話になっていって、第Ⅰ部をきちんと読んで危機感を持って行動を変えられる人であれば自然とそこに到達するのでは？と思った。 まずは第Ⅰ部をしっかり読んで、自分の置かれた環境との差異や、これから行動することを書き出す、みたいな読み方をすると良い。 第Ⅲ部以降は、もう完全に生き方というか、エンジニアとしての振るまいや、哲学の話になってくるので、一気に通読する、というより少し間を置いて拾い読みしながら読み進めて行くと良いかも。 流し読みしても全然役に立たないタイプの内容なので、読書メモは必ず書いた方がいいと思うし、書かれていることが万人にとって正解、といった類いのものでもないので

「コンウェイの法則」というのがある。 Melvin Conwayが『How Do Committees Invent?』という論文にて発表した考え方を指す言葉。筆者自身による論文の紹介文に書かれている、以下のくだりが端的にその内容を表している。 Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure. システムを設計する組織（ここでは情報システムだけでなく、より広い意味で定義する）は、必然的に組織のコミュニケーション構造をコピーした構造を持つ設計を

紙の技術書を開いたままの状態にして、参考にしながらコードを書きたい時ってありますね。ただ、本を開いた状態にしておくのが結構大変です。ブックスタンドなどもありますが、けっこう大きいし、持ち運びには向いていないです。 そんな時には、ステンレス製のクラスプ クリップがおすすめです。ペンケースにも入るサイズなので持ち運びもできます。 (写真の本は、最近読んでいる『Learning Go』です) 紙の質にもよりますが、150ページくらいまでは止めておけるし、それ以上のページになれば自重で本全体は開いたままの状態になるので、めくれないように手前のページを数ページ軽く挟んで押さえておけばいいだけです。 一番大きなサイズでも275円なので、試しに買えるレベルなのもオススメの理由の一つです。 ステンレスクラスプ クリップ シンプル 書類 整理 オフィス 備品 Lサイズ ステンレス製 DAS-2501 スリッ

システム運用アンチパターン ―エンジニアがDevOpsで解決する組織・自動化・コミュニケーション 作者:Jeffery D. SmithオライリージャパンAmazon いやー刺さりまくる名言のオンパレードみたいな1冊『システム運用アンチパターン 』。 この本で最初に出てくる具体的な事例が「パターナリスト症候群」という内容なんですけど、これまでの技術書にありがちな「作業品質向上や、効率化のため」というより、組織のアジリティを下げてしまう「重い承認プロセス」を排除するために自動化しましょう、と言っているところが良い。 自動化をする理由が効率化とか、品質じゃなくて、重い承認プロセスを不要にするためである、というところが新しいし、アンチパターンに技術で立ち向かうところが、良い— magnoliak🍧 (@magnolia_k_) 2022年4月23日 なので、そもそも「承認プロセス」というのは何

エンジニア版ベストキッド 師匠 「ログを出す！ログを読む！」「syslogに出す！ loggerで出す！」「ログレベルアップ！ダウン！アップ！ダウン！」 生徒 「クラウドネイティブなマイクロサービスの作り方を教えてくれる約束だ！」 プロダクション環境にて… 生徒「ログが…有る！これだ！」— magnoliak🍧 (@magnolia_k_) 2022年4月10日 ふとベストキッドの台詞を思い出して、雑に書いてみたけど、案外いいこと書いてるなーって自分でも思ってしまった。 loggerの使い方は入門書に載ってたり載ってなかったりするし、どんなタイミングでどんな情報をどこに出すべきか？みたいな話は一子相伝の秘伝の技みたいになりがちだし。 まさにそう思います。https://t.co/ZKTTtdwB1d— Hideo Fukumori (@hideo_fukumori) 2022年4月11日

ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ 作者:Mark Richards,Neal FordオライリージャパンAmazon とても良い本だ！アーキテクチャのパターンは体系的に整理されているし、アーキテクチャを議論する上で、共通の語彙となり得る用語を解説している（コンウェイの法則や、凝集度など）。 後半は、リスクや、チームビルディング、交渉術まで多岐に渡るトピックを網羅している。 必要なことは全部書いてある...けれど、なんとなく初めてPMBOKを読んだときに抱いた感想...読み始めてからすぐに「果たしてこの本に書かれている通りの考え方に沿って振る舞えばアーキテクトになれるのか？」という気持ちになりはじめたところで1章の最後の方に出てくる「ソフトウェアアーキテクチャの法則」が出てきて、「そうだよなー」という気持ちに。 ソフトウェアアーキテクチャはトレード

クソコードができあがるのは「影響の及ぼすコンポーネント量を最小にする」という個別最適の価値観が支配的になった時、です 影響の及ぶ範囲を小さくするために、巨大で複雑なコードの塊を一箇所に追加し始めたりするのです そうした方が関心の範囲が限定できるから...だけど、全体最適ではない— magnoliak🍧 (@magnolia_k_) 2022年3月12日 でも悪気はないんです 真面目に巨大で見通しの悪いコードを作り上げていくけど、影響範囲が最小になる方が常に正しい、という価値観は「わかりやすい」んですよ— magnoliak🍧 (@magnolia_k_) 2022年3月12日 「変更量が最小になる」「影響が最小になる」...目の前のタスクをこなすためには、それが一番良いことに見えるんですよね でも、「継続的に同じペースが保てるか？」「スケールするか？」というと、そんなことは無いけど、そ

2021/12/20追記 指摘されて気づいてしまいましたが、間違ってますね... 以前スライドを書いた時に全然気づいていませんでした 反省のために消さずに、取り消して残しておきます 「年齢計算ニ関スル法律」という法律がある。 明治三十五年法律第五十号（年齢計算ニ関スル法律） | e-Gov法令検索 とても短い法律で条文は3つしかない。 ①　年齢ハ出生ノ日ヨリ之ヲ起算ス ②　民法第百四十三条ノ規定ハ年齢ノ計算ニ之ヲ準用ス ③　明治六年第三十六号布告ハ之ヲ廃止ス ポイントは①で、生まれた日から起算するので法律上は1年が経過した時に1つ歳を取ることになる。つまり、誕生日の前の日の24時に年齢が加算されるので、日単位でみると誕生日の前の日にもう年齢は進んでいる、ということになる。 同じ年の4月2日生まれの人と、4月1日生まれの人とでは小学校に入学する年度が違う、というのはよく聞く話だと思う。 この