2024年10月5日に公立はこだて未来大学で開催された「YAPC::Hakodate 2024」にスタッフ参加してきました。 yapcjapan.org 「YAPC」がどんなイベントかと言えば、本来は「Yet Another Perl Conference」の略なので、Perlのイベント、ということになるのですが、長い年月を経てPerlだけに捕われない、自由なイベントになってきた、という歴史があります。ただ、今回は意識的にPerl成分が多かったので、もう1周回って「Perlを書いている人にも書いてない人にもとにかく楽しいイベント」という説明が（良い意味で）難しいイベントになっていました。 2019年に開催された「YAPC::Tokyo 2019」ではスタッフとして参加し、オープニングをしゃべったり、前夜祭LTの運営をやったりと、ガッツリ参加していましたが、コロナ禍に入ってからのオンライン開

scala-tokyo.connpass.com 久しぶりのScalaのイベント「Scalaわいわい勉強会 #3【東京】」に参加してきました いやーディープなScalaの話が聞ける場所は貴重なので、最高でした 会場は乃木坂のWeWork! 開始時間を完全に間違えて18:30スタートだったのに、19:00に会場到着 （しかも、参加者に送られてはずのWeWork入館メールを紛失してしまい、運営の方に開けてもらって入場...ありがとうございました） 残念ながらちょうど一つ目の発表が終わったところで完全に聞き逃してしまいました さいわい、スライドが公開されていました speakerdeck.com コード同士の合成がシステマチックにできるところがScalaの最大のメリットだと思っていて、ただそれがちょっと複雑な構造になってくると逆に読み解くのが難しくなったり、ネストしたデータ構造を分解して詰め直す

なぜ依存を注入するのか　DIの原理・原則とパターン (Compass Booksシリーズ) 作者:Steven van Deursen,Mark Seemannマイナビ出版Amazon なんとDI(Dependency Injection)だけを扱う本の厚さが637ページ! たぶん、もう日本で今後商業出版されることは無いであろう、DI(Dependency Injection)の解説書『なぜ依存を注入するのか　DIの原理・原則とパターン 』を読みました。 はじめてDIに触れたのはGoogle Guiceだったのですが、いつの間にかオブジェクトがフィールドに生えてくる黒魔術的なテクニック、という印象でした。 ”動的に実装を切り替える”、という意味ではPerlで実行時に設定に応じて実装を切り替えるモジュールをたくさん見てきたし、自分でも書いたことが有ったので、Javaなどの言語で実行時の実装選

他者と働く──「わかりあえなさ」から始める組織論 (NewsPicksパブリッシング) 作者:宇田川元一ニューズピックスAmazon 「対話」によって、関係性の溝に橋をかけ、相手への理解を深め、新しい関係を築くための手法を、ナラティブというキーワードを軸に解説する本です。 自分は意見が合わない人が居ると、「この人がこのように発言する、意思決定することの裏にはどんな価値観があるのか？」ということを考えてしまうのですが、そのやり方が上手く形式知化、言語化されていました。 相手との新しい関係性を作る行為を「橋をかける」という表現で分かりやすく解説されています。 とはいえ、この本で解説されているように、そんな分かりやすく人の心が動くのか？というと、それは当然そんな簡単なことではないし、そんな簡単に分かり合える、なんてことも無いよなー、最後は結局「力こそパワー」みたいな展開になることも有るよなーとは

本エントリは、BGMに「僕らが旅に出る理由」を流しながら読んで下さい。 builderscon 2019へ参加してきた。 https://builderscon.io/tokyo/2019builderscon.io 特定の言語やフレームワークに特化したカンファレンスが多い中、buildersconは特定のテーマに縛られることの無い幅広さが魅力ですね(自分は見れていませんが、スーパーカミオカンデの発表はかなりTwitterのTLが盛り上がっていましたね)。 一方でPHP系のカンファレンスのように、間口が広い分、メインテーマのPHP以外の、設計や開発プロセスに関する話題もけっこう充実してきていて、必ずしもその言語を使っていないからといって最初から対象から外すのももったいないイベントも有ります。 もちろん、その言語、ライブラリに100%振り切ったカンファレンスもたくさんの学びが有ります。 (今

ついつい技術書を買いすぎて、なかなか読めないまま次を買ってしまったりして、結局読まないままになる、というパターンに時々ハマっている。なるべくそうしないように厳選しているつもりなのだけど、それでもいわゆる積読が発生してしまう。 技術書に関しては、二つのルールを守るようにしている 紙の本を買う 電子書籍の方が圧倒的に便利なのは分かっているのだけど、やはり物理的な「圧」が有った方が読もうという気になるので、技術書は可能な限り紙の本で買うことにしている 一度に読む本を限定する 机の上に無印良品の仕切りスタンドを置いてあって、ここに収まる本以外は同時に読まないようにしている 読み終わったら、本棚の本と入れ替え MUJI 無印良品 スチロール仕切りスタンド・ホワイトグレー 3仕切・大・約270×210×160mm 02856410 MUJIAmazon 無印良品 アクリル仕切りスタンド 3仕切り・約1

アドバイス頂き書き換えました 「Bizの意思決定はいかに例外を捨てるか、Devの意思決定はいかに例外を拾うか」 これ凄いいい言葉だな！ https://t.co/V8gbMA3oMr— magnoliak🍧 (@magnolia_k_) 2024年1月12日 タイトルに書かれていることが全てなのだけど、時にBizの人と、Devの人の目線というか、着眼点の違い、意思決定に至るスピード感の違いの元は、どこから来るのか？と思った時に、それを表現する言葉がようやく見つかった気がする。 以前書いた関心の非対称性に関するエントリを一言で言うとって話なんだけど。 blog.magnolia.tech で、結局これをどうやって乗り越えていくのか？ってことなのけどね。 誰も悪意の有る人はおらず、みんな一生懸命なのに、それぞれの価値観の違いが擦り合わないことで上手く行かない、みたいなことにならないためにはお

GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ 作者:千田 和央翔泳社Amazon 紹介された本はなるべくその場で注文して実際に読んでみる、というのを実践するように心がけています。この本もそうやって紹介されたので、すぐに買って読んでみました。 当たり前ですが、単にリモートワークにすれば全ての問題が解決する、業績が上がる、リモートワーク最高！という内容ではありません。 この本の中心は、GitLab社が作った「GitLab Handbook」をベースに、組織の価値観、それをベースにした仕事のやり方、評価のやり方を定義、可視化することで、よりみんなが満足して、より高い成果を出すための環境作りの方法が解説されています。 GitLab社はオールリモートで運営されていて、2,000名を超える従業員が特定のオフィスを持

実践プロパティベーステスト ― PropErとErlang/Elixirではじめよう 作者:Fred HebertラムダノートAmazon Erlang/ElixirのPropErというライブラリをベースに、プロパティベーステストの考え方、テストの実践的な書き方を学ぶための本です。 『実践プロパティベーステスト ― PropErとErlang/Elixirではじめよう』www.lambdanote.com 書名だけ見ると「Erlang/Elixirは使ってないからなー」と避けてしまうかもしれませんが、それはもったいなく、言語に関係なく、”プロパティベーステスティング”という手法の本質的な活用の仕方が学べるようになっています。 ここしばらくScalaのScalaCheckというプロパティベーステストライブラリを使ってテストを書くことに挑戦していたのですが、今一つより良い書き方が分からず、何か

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

Software Design (ソフトウェアデザイン) 2023年7月号 [雑誌] 技術評論社Amazon 今月のソフトウェアデザイン 2023年7月号、ちょっと興味深かったのは特別企画の「GOFデザインパターン歴史探訪」。 DDDとかもそうだけど、原典となる書籍が古くなって、特にアップデートもされていない場合、「原典だから」という理由で読むことをおすすめされても現代と状況が変わりすぎていて、コンテキストが合わず、どこを読めばいいのか分からない、みたいなことに遭遇する。 それが「周辺知識獲得のお勉強」であればまだいいのだけど、実務のためにサクっと「編集者の目を通った情報」を通じて理解したい時にこの手のまとめは凄く助かる。 GoFが生まれた時代的な背景から、そもそも想定されていた適用領域、現代における利用方法までコンパクトにまとまっていて分かりやすかった。 キャッチーなキーワードを「習得し

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

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

プログラマー脳 ～優れたプログラマーになるための認知科学に基づくアプローチ 作者:フェリエンヌ・ヘルマンス,水野貴明,水野いずみ秀和システムAmazon ずっと前に買ったまま積んでいたけど、GW期間にようやく読み進めることができた。 なぜコードを理解するのが難しいのか、それは理解する方法に問題があるのか、それともそもそもコード側に問題があるのか、といった内容が書かれている本 読み物としては非常に興味深いし、これまで出版されたことの無いテーマなので、新人プログラマを指導する人には一読する価値が有る

継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣 作者:David Farley日経BPAmazon 書名の「継続的デリバリー」はCI /CDの解説書かな？とも思わせてしまうので若干ミスリードなんだけど、「工学とは何か？」「ソフトウェア工学とは何か？」「工芸と工学は何が違うか？」ということを解説した1冊。 『継続デリバリーのソフトウェア工学』を読み始めた そういえば、最近「ソフトウェア工学」ってキーワードを聞かないなーって思ってたけど、本書にも「最近敬遠されてない？」って書かれてた— magnoliak🍧 (@magnolia_k_) 2023年1月28日 まぁ、確かに「ソフトウェアの品質分析がー」とか、「設計書を書けばコードが自動生成ー」みたいな、「管理！」的な価値観が大きかったように思われてたんじゃないかなーとか思った— magnoliak🍧