おなじことを繰り返し書いているけど、ScalaMatsuriも、関数型まつりも、「集中して聴いているのに、全然頭に入ってこない、このトークを聞くためのメンタルモデルが形成されていない...いや、単に自分の頭が悪いのか...ぐぬぬぬ...」みたいな場面にばかり遭遇するので、「自分はまだまだ何もできないやつだな」ということを理解するために参加している、みたいな側面がある

来年開催されるのかはまだ分からないけど、次回も絶対に参加するぞ！！

2025-06-19

久しぶりのfib関数

先日、関数型まつりに参加した影響で、久しぶりにフィボナッチ数を求める関数でも書くか！と思って書き始めたら、再帰＋末尾最適化バージョンが一発でそらで書けず、過去に書いたコードを見て、「あー」となったので、その記録。

なんでも忘れるものですね...

単純なループバージョン

定義の通りに書いただけ

でも再帰を使ってないので、関数型っぽくない

def fib1(n: Int): BigInt =
  if n <= 1 then BigInt(n)
  else
    var a: BigInt = 0
    var b: BigInt = 1

    for (_ <- 2 to n)
      val n = a + b
      a = b
      b = n

    b

素直に再帰を使って書いたバージョン

これも定義通りに素直に書いただけ

def fib2(n: Int): BigInt =
  def loop(n: Int): BigInt =
    if n <= 1 then BigInt(n)
    else
      loop(n - 2) + loop(n - 1)

  loop(n)

でも、末尾最適化が効かないため、処理時間は爆増する

fib2(50)くらいで全然帰ってこなくなる

末尾最適化に対応したバージョン

過去のコードを見て書き写した...

ここでのloop関数の中でのcountは、単純な再帰バージョンでのインデックスではなく、カウントダウンするためのカウンター

accの中に、累積した値を持ち回り、計算完了時点（countがゼロになった時点）で、accを取得する

def fib3(n: Int): BigInt =
  @annotation.tailrec
  def loop(count: Int, acc: (BigInt, BigInt)): BigInt =
    if count <= 0 then acc._1
    else loop(count - 1, (acc._2, acc._1 + acc._2))

  loop(n, (0, 1))

これなら、fib3(50)は当然余裕で帰ってくる

カウンターが下がっていくのと逆に、引数で持ち回っているaccがどんどん累積されて増えていく、という感覚が掴めるか？というところがポイントですね

2025-06-14

システム開発は「決めること」の連続

システム開発は「決めること」の連続なので、そこからの学びをちゃんと得ていけば、影響範囲に応じた適切な意思決定ができるようになると思うんだけど、そこを回避して「作業者に徹する」と先のキャリアで詰んじゃうよーって話をした
— magnoliak🍧 (@magnolia_k_) June 9, 2025

ほんとプログラムを書いたり、アーキテクチャ設計とかしていると、「変数の命名」みたいなレベルからコストを踏まえたミドルウェアの選定まで、影響の大きさの大小に関わらずたくさんの「決めること」が出てくる

個人開発では全部決められるかもしれないけど、受託だったり、自社サービスだったりすると、案は出せるけど、決める権限が無い、みたいな場面も多い。

でもそんな中でもプロとして、「こうあるべき」を提案できる人は、「決める立場」になった時に適切に決められるようになるし、「決める人の気持ち」への理解が深まり、より意思決定への関与が深めることができる...「君が言うなら、そうしよう」と言ってもらえるなら、それはもう「決めたも同然」なので。

「指示されたことをやりました」というスタンスを採ることは生存戦略の一つとして決して間違っているわけではないのだけど、「決める訓練」をしていない人が、「決める立場」になった時に適切に決められるか？という問題がある。

上手く組織を作る人は、権限の委譲が上手く、適切な範囲を「決めさせる」ことで成長を促していく。

そのチャンスを上手く使って、「適切に決められる人」になっていかないと、「雑に決める」とか「決めない（遅い）」とかが発生してしまう。

システム開発という、ひたすら「決めること」の連続である営みを通じて、「決める訓練」を積む、というのは有効なのではないか、と、そんなことを思った。

2025-06-08

遠い昔に読んだ『園芸家12カ月』はソフトウェアエンジアリングへのヒントがあるかもしれないと思って読み直した

園芸家12カ月-新装版 (中公文庫チ 1-3)

作者:カレル・チャペック
中央公論新社

Amazon

約100年近く前に書かれたカレル・チャペックのエッセイ本

翻訳も昭和34年と古い...5年前に新版が出て、文庫本としては非常に読みやすい体裁になっている

なんかずっと昔に読んだ記憶だと、ひたすら園芸家が庭の手入れを続ける様子が、現代のソフトウェアエンジニアリング...CI/CD環境を整えたり、新しいプログラミング言語や、ライブラリを調べたり、リファクタリングをしたり...といった活動に通じるものがあるのでは？と思って読み直してみた

うん、ただただひたすら園芸に関するオタク早口ムーブが延々続くので、そういう話ではないな、でもユーモアが有って、素晴らしい！と思ったし、「気質」という意味ではここに出てくる園芸家のような思考回路は、ソフトウェアエンジニアリングに通じるなーとは思った

フル回転で常にどこにどんな植物を植えるのか、どんな土を作るのか...そんなことばかり考えてる様子が愛おしい...

あと、ひたすらhow(土を作るとか、苗を注文するとか、どこに植えるのか）と、what（280種類にも及ぶ膨大な植物の名前の数々！）が続いて、why（園芸や、植物のどこにそんな魅力を見出しているのか、なぜそんなに熱心に庭を作るのか）という話がないのがいい

いいんだよ、やりたいんだよ！

とはいえ、1年12ヶ月、そのタイミングに合わせた「やるべきこと」を考え、膨大なやりきれないことに優先順位をつけ、時には失敗し、色々な人に相談したり、気ばかりが焦ってしまう様子なんかは胸に刺さるものが多かった

というわけで、特に役にたつ、みたいな話も無いけど、単純に面白い本なので、おすすめです、という結論でした

Magnolia Tech

いつもコードのことばかり考えている人のために。

Durock Ice King Tactileを買った

「TechTrain Mentor Kaigi 2025」へ参加してきた

「LTのためのLT会 - LTが上手くなりたい人が集うLT会」で登壇してきた

「関数型まつり」に行ってきた

トークの感想

全体的な感想

スタッフ打ち上げ

さいごに