msfukuiの日記

おおまさのみみはそらのみみ。

2025年の振り返りと2026年の目標

今年も今日から始まりましたが、昨年も何かとありましたので、書いて眺めていきます。

2025年の振り返り

以下の目標を設定していたのですが、何とかいずれも達成できたのでは..と思っています。

  • 仕事を続けたい
  • 家庭で過ごす時間を増やす
  • カンファレンスや勉強会の登壇にチャレンジしたい

引っ越しました

家庭内じゃんけんに勝って、三男の希望により、4月に空き家となった山梨県の奥さんの実家に、下の子どもたち二人と引っ越しました。

奥さんと長男は東京住みのまま、次男は進学して寮に入ることになり、一緒に暮らしていた家族がばらばらな場所で住むことになりました。

子どもたちの食事など最初はどうなることかと思いましたが、主に週末に来てくださる奥さんの頑張りにより何とか回っています。感謝。

4月の最初の移動のタイミングでは、IPA の試験と会社イベントでのリアル登壇が重なってしまい、心も体もかなり無理をしてしまったのですが、今では地元の生活やイベントごとにも慣れてきて、文化の違いに戸惑いつつも、周りが自然だらけで移動してきてよかったと感じます。

ただ、生活には自家用車が必須な地域で、子どもたちの送迎がとても大変なところが現在のつらみです。

ねこと暮らしています

10月にご縁あって兄弟の保護ねこを二人引き取らせていただくことになり、一緒に暮らしています。

まだ3か月程度ですが、子どもたちとも仲良しで、夜は寒いからか二人ともベッドまで来てくれて、いつも一緒に寝ています。幸せ。

少しだけ副業を始めました

ご縁があって、前職のつながりで月に20時間程度、副業をさせていただいています。

初めての経験で、知らない手続きもたくさんあり、この年になっても勉強させていただいています。確定申告が今から怖い。

2026年の目標

いつも行き当たりばったりで低空飛行ですが、今年ものんびりとやっていきたいです。

仕事を続ける

今の職場に入って3年目になりました。引き続き現場を楽しみながら研鑽を続けていきたいです。

カンファレンスなどでの外部登壇へのチャレンジ

お声がけいただいて、5月に会社のイベントで初めての外部登壇をさせていただいたのですが、今年こそはできればカンファレンスや勉強会での登壇にチャレンジしてみたいです。

体重を..何とか..

ご飯を食べすぎていますね。きれいに右肩上がりに増えていっているので、食事を控えつつ、適度な運動で適正体重を図っていきたい所存です。

その他

読んだ本や見た映像作品はちょっと整理がついていないので別記事にするとして。

買ってよかったもの

子どもたちの送迎用（という名目）で、カワサキの W230 を買いました。おおよそ20年ぶりのバイクなのですが、これほど楽しくテンションの上がる乗り物はないなって思います。

次回は大型を狙っています。まれに動画を見ながら買いたいのを今はぐっとこらえています。

なお、キーボードの購入は落ち着いてきて、かなり抑えめになりました。

最後に

欲しいものがまたいろいろと出てきたので、今年もできるだけためらわずに購入していけるといいなって思いました。

本年も何かといろいろあるかと思いますが、どうぞよろしくお願いいたします。

2024年の振り返りと2025年の目標

今年も今日でおしまいですが、今年も何かといろいろありましたので、書いて眺めてみます。

2024年の振り返り

仕事をしています

昨年の9月頭に前職を退職後、12月から新しい職場で仕事をしています。早くも1年と1ヶ月ですね。主に PHP と JavaScript/TypeScript と SQL に触れています。

プログラマーとして仕事に取り組みたい、と思っているのですが、実際にそうなっているかは、、まだまだ微妙。

この1年で特に PHP を触ってきて、オブジェクト指向な考え方と一緒にようやく最近手に馴染むようになってきた気がします。コードを書くのが本当に楽しいです。

エディタは、仕事では会社で購入いただいている IntelliJ IDEA + IDEA Vim を使っています。こちらも徐々にですが手に馴染んできている気がします。

キーボードを比較的たくさん買いました

こちらも昨年から継続なのですが、今年買ったキーボードを数えてみるとちょうど 10 個でした。

今のところ自宅では Womier SK71 、会社では Lofree Flow Lite に落ち着いています。

そういえば夏に買った keyball 44 は、山に夏休みに持って行った後まだ組み立て終わっていないのだった。頑張ろう。

今年は使わないものはメルカリさんなどで整理した上で、購入量は減らしていきたいですね。

ご飯を食べ過ぎました

うーん、昨年の退職時には 76 kg だった体重が 2 kg 程さらに増えました。今年もたくさんのおいしい食事に恵まれてとても幸せでしたが、調子に乗ったためか年末に健康診断に引っかかってしまい、現在特別観察中です。

元気ではあるのですが、腰の痛みなど、体のあちこちにガタが来始めているのを感じた年でもありました。

幕間

あれ？去年が（結局書いていないけれど）激動の年だったからか、今年はあんまり思ったよりも書くことはなかったかも。

2025年の目標

いつも通り、低空飛行でぼちぼちとやっていきたいです。

仕事を続けたい

プログラマーとして仕事を続けられるように、でも無理しない程度に、引き続き頑張りたいです。

来年はいろいろと家庭の事情でいくつかの地域を巡回しながら仕事をすることになりそうなのですが、勤務先がリモートで仕事ができる環境なのが本当にありがたい。🥲

勤務先から戦力外通告されないように、楽しみながら研鑽を続けたいです。

家庭で過ごす時間を増やす

昨年の退職後から4ヶ月ほど転職活動のかたわら主夫業をやってみていたのですが、仕事を再開した後はそちらに夢中になるあまり、すっかりおまかせに戻ってしまいました。これは本当に反省。

一年たって仕事のリズムもわかってきたので、今度こそは家事の分担度を上げて、子どもたちとの時間を増やしていきたいです。

勤務先のみなさんをみていると、きちんとその辺りを両立されていて本当にすごいなって思います。

カンファレンスや勉強会の登壇にチャレンジしたい

今年は昨年に引き続いてカンファレンスの当日スタッフを2つやらせていただいて、楽しかったので来年もできるだけ継続したいなって思っているのですが、せっかくなので登壇にもチャレンジしてみたいです。

もともと、仕事を再開してから3年目には..と目標に設定していたのですが、勤務先の周りのみなさんが次々と登壇されているのをみて、やってみたい欲が高まってきました。ネタを探さなければ。。

その他

追加で定番な振り返りを。

今年読んだ本

もうちょっとあったかもですが、覚えているものをソフトウェア関連の本に絞って書いてみました。

  • Clean Architecture 達人に学ぶソフトウェアの構造と設計
  • 組織を変える5つの対話 - 対話を通じてアジャイルな組織文化を創る
  • ルールズ・オブ・プログラミング - より良いコードを書くための21のルール
  • チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計
  • ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本
  • ちょうぜつソフトウェア設計入門 - PHPで理解するオブジェクト指向の活用
  • Elixir実践入門 - 基本文法、Web開発、機械学習、IoT
  • ゼロから学ぶFlutterアプリ開発

勤務先では O'Reilly の購読サービスを契約していただいていて、読みたい本が無限にあるのがとてもありがたいのですが、そうなると、そこでは読めない本を買ってしまうという動きを繰り返してしまいました。

よかった本、あんまり刺さらなかった本などありましたが、比較的いろんなものを幅広く読んだ感じがします。

積まれている本も多いので来年はペースを増やしたいのと、もう少しコードを書くのに役立つ本を増やしたいです。

今年見た映像作品

うーん、来年こそはサブスクリプションサービスを何か契約したいと思っているのですが、覚えているものはなんとなくこんな感じでした。

映画館に行きたいって思うのですが、機会を作るのがなかなかに難しいですね。今年こそは劇場で何かしら観たい。

買ってよかったもの

キーボード周りを除くとあんまりないのですが、SHOCKZ OPEN FIT は取り回しが良くて、出勤中にポッドキャスト聴くのとリモート業務用に使っています。電池持ちがもう少し良ければ、、というのと、スマートフォンと PC 両方に繋げていると、電話かかってきた時に自動で電話側に切り替わってしまうのがつらいので、業務中は PC のみに繋げているのがちょっと悲しい。

後は、まだ試していないのですが、年末にサンタさんから届いた「電車で Go!」のマスコンの使い勝手に期待しています。

最後に

本年も大変お世話になりました。良いお年をお迎えください。🎍

来年もなにかと色々あると思いますが、どうぞよろしくお願いいたします。☺️

Vim Terminal mode 周りの設定の備忘録

もうちょっとちゃんと Vim を使っていきたい欲が高まっているので、少しずつ設定を入れたり本を読んだり Youtube を眺めたりしているのですが、 Terminal 周りの設定で四苦八苦したので、備忘録を兼ねて。

やりたいこと

これ。

qiita.com

Vim のウインドウ分割と Terminal 機能を気軽に使える状態にしたいなって思っていて、記事を拝見しごもっともだなって思って、設定に足を踏み入れたのですが、いろいろと地雷を踏みました。

やったこと

今のところこのあたりの設定に落ち着いています。L343 - L352 あたりと L377 以降になります。

github.com

前提

私有の Intel Macbook Pro と会社から支給されている M2 Macbook Pro の Terminal.app で Terminal 版の Vim を利用する想定です。

外付けの英字キーボードを使っています。

Windows のことは（環境はあるのですが）一旦脇に置く。

GUI 版の Vim は今まで使ったことがなくて、今のところ今後も使う予定がありません。

踏んだ地雷と対処

最初に Claude3 に対処方法を聞いてみたのですが、聞き方が悪いのか、最後まで意味のある対応内容を回答してくれることはありませんでした。

正反対のことを回答することが多く、AI はこの用途には向いていなさそうなことがよくわかりました。

Terminal.app の設定

プロファイル > キーボード の「メタキーとして Option キーを使用」にチェックを入れる

Option + いろんなキーを押すと、制御文字ではなくていろんなギリシャ文字っぽいものが入力できて、なんだーって思ったのですが、比較的たくさんの情報があって気がつきました。

IntelliJ IDEA の Terminal でも同じ設定があるみたいであとで試してみる。

https://youtrack.jetbrains.com/issue/IDEA-165184

Vim の Meta キーのマッピング設定

<A-..> の設定を入れてみたのですが、動作せず、理由を探していたところで、以下の比較的古い記事を拝見しました。

thinca.hatenablog.com

Option キーは ESC とマップする必要があるみたいで、アレンジして nmap <ESC>t <A-t> などと設定を入れてみると動作しました！

この情報、なかなか見つからなくて、時間がかかりました。

Vim Terminal mode 周りの設定

最初の記事のマッピング設定をアレンジして入れてみました。

当初 tmap の設定が漏れていることに気が付かず、二日ほど時間を無駄にしました。。

慣れるとサクサク操作できて快適。

" Alt key を normal mode で有効にする
nmap <ESC>w <A-w>
nmap <ESC>t <A-t>
nmap <ESC>s <A-s>
nmap <ESC>v <A-v>
nmap <ESC>j <A-j>
nmap <ESC>k <A-k>
nmap <ESC>o <A-o>
nmap <ESC>; <A-;>
nmap <ESC>/ <A-/>

" Alt key を Terminal 内の Vim でも有効にする
tmap <ESC>w <A-w>
tmap <ESC>t <A-t>
tmap <ESC>s <A-s>
tmap <ESC>v <A-v>
tmap <ESC>j <A-j>
tmap <ESC>k <A-k>
tmap <ESC>o <A-o>
tmap <ESC>; <A-;>
tmap <ESC>/ <A-/>

" ターミナルモードのキーマップ変更 (C-w をシェルで有効に)
set termwinkey=<A-w>
" ターミナルジョブモードで垂直分割した右ウインドウを開く
noremap <A-t> :vs<CR><C-w>l:term ++curwin<CR>
" ターミナルジョブモードからノーマルモードに切り替える
tnoremap <A-t> <C-\><C-n><CR>
" 水平分割した上ウィンドウを開く
noremap <A-s> :sp<CR>
" 垂直分割した右ウィンドウを開く
noremap <A-v> :vs<CR>
" ウインドウ間移動
noremap  <A-j> <C-w>w
tnoremap <A-j> <C-\><C-n><C-w>w
" ウィンドウ間を逆に移動
noremap  <A-k> <C-w>W
tnoremap <A-k> <C-\><C-n><C-w>W
" 他のウィンドウを閉じて最大化する
noremap  <A-o> <C-w>o
tnoremap <A-o> <C-\><C-n><C-w>o
" コマンドラインモードに移行
noremap  <A-;> :
tnoremap <A-;> <C-\><C-n><C-w>:
noremap  <A-/> /
tnoremap <A-/> <C-\><C-n>/
" ウインドウ操作時にターミナルノーマルモードの場合は
" 自動でジョブモードに切り替える
autocmd WinEnter * if &buftype ==# 'terminal' | normal i | endif

おしいところ

tmap で ESC + .. をキー割り当てしている関係上避けられないのですが、 Terminal job mode で開いているターミナルで、コマンドラインの vi mode のノーマルモードへの切り替えに ESC キーの入力待ちが発生します。

根本的に Option キーを Karabiner-Elements で別キーにマッピングすることも考えたのですが、Terminal.app 以外の操作に悪影響がありそうだったので、ここは一旦あきらめています。

その他

プロンプト表示をシンプルな内容に見直したり、 fzf-tab を入れたり、vimwiki を使うようになったり、少しずつタイピング練習したり、新しいキーボードを買いすぎて怒られたりしています。

今しばらくは Vim と IntelliJ IDEA の両方でコードを書くことになりそうです。使いこなせるようになる日は来るんだろうか。。頑張ります。

「Clean Agile」「エクストリームプログラミング」を読みました

新しい職場での参考図書の一つとして「Clean Agile」を紹介いただいたので購入して読んでみました。

https://www.tumblr.com/asciidwango/631315320701960192/clean-agile
asciidwango.jp

買ってみて「ボブおじさん」の本を読むのが初めてであることに気がつきました。「Clean Code」も「Clean Coder」も「Clean Architecture」も未読。「アジャイルソフトウェア開発の奥義」も未だ積まれたままでした。読みます。。

薄いのと技術的な詳細が書かれた本ではないので、待ち時間などに比較的サクサクと読み進めることができました。副題の「基本に立ち戻れ」にある通り アジャイルソフトウェア開発宣言 の作成の経緯から始まって、どうしてアジャイルを選択するのか、アジャイルではないことは何か、が平易な文章で書かれていて、特にアジャイルな開発が比較的当たり前になっている現在においてその論旨の必要性を含めて納得感を持って読むことができました。プロセスも大事だけど技術スキルを磨いてプロの仕事をしよう、というメッセージが印象に残りました。アジャイルコーチが、ビジネススキルも技術スキルもないからと文中で二度ほどボコボコにされているのがちょっと気の毒な感じでした。

この本を読む少し前にたまたま XP の白本を読み直していました。段ボール箱をひっくり返しましたが初版の本が見つからず..結局第2版を買いました。

www.ohmsha.co.jp

最初に読んだ時のことはあんまり覚えていなくて、テストファースト、ペアプログラミングなどの技術的プラクティスだけが印象に残っています。たぶん00年代前半だったと思うのですが、恐らく当時の自分には XP の登場の背景や、当時の開発者の抱えている閉塞感や怒り、みたいなのが見えていなかったのだと思います。改めて読んでみて、まずは著者の怒りと情熱がストレートに伝わってきて、こんなに熱い本だったんだな、ということにまずは実感を持って驚きました。みなさんの感想にもたくさん書かれていたはずなのに。

なお書かれている中だとP.83-84にある「開発のプルモデル」の意味するところ今も（特に図が）理解できていなくてピンときていない。リソース効率とフロー効率の話? とも思ったがどうも違うみたいな気もする。もうちょっと別の方面からも調べてみたいなって思いました。

両方の本とも、なんでソフトウェア開発をこんなやり方でやるの? みたいなことが原点としてシンプルに言語化されていて、振り返りにもなり、楽しく読むことができました。

ちなみに XP 本を探していた際にダンボール箱からは他に懐かしい書籍がいくつか出てきまして、見つけた以下も読み返していました。

www.amazon.co.jp

だいぶ読みにくい..のと、 XP 本以上に内容を全く覚えていない。「ソースコードは設計なのか?」という章で Ruby のまつもとさん(Matz)の言葉が引用されていて、おおってなりました。

本を読んでいるとソフトウェア開発なんもわかってないなって改めて思いまして、今後はもうちょっと読むペースを上げていきたいです。

国会図書館に行ってみました

タイトルは、前回に引き続き 2355 のおやすみソング「小石川植物園に行ってみました」へのオマージュです。

時間がたくさんあるので、隙間を見つけてはお出かけしているのですが、先日ついに憧れの地に踏み入れました。

とても古い記事になるのですが、

msfukui.hatenablog.com

調べる予定にしていた「構造的プログラム設計の原理」の内容について、4年越しに実際に調べてきました。

その話は後で書くとして、その後は NORTH CAFE で美味しいカツカレーを食べて幸せでした。*1

投稿者: @msfukui
Threadsで見る

3時間くらいの滞在でしたが、能動的に調べ物をしたい場合は、周りの雰囲気も含めて最高な場所でした。また行きたい！

肝心の調べ物について

該当の箇所は、序文と第12章の両方に見られていて、その前後の文章を含めてとても興味深いのですが、一旦、第12章の記載を引用してみます。

最適化(optimization)という言葉は間違って使われている. ラテン語からの意味では(プログラムを)最適化するということはできるだけ良くすることである. しかし, われわれが最適化されたプログラムを使うのは, できるだけ小さく, 又は速くすることである. 小さくしたり速くしたり, またはできるなら両者を行うときには色々な意味で悪くしがちである. 理解が困難になり, 保守がむずかしく, そして間違い易くなることであろう.

簡単に言えば, 最適化にはお金がかかる. 我々の最適化についての基本的態度を２つの規則で定義しておこう.

  • 規則1: 最適化を行ってはいけない.
  • 規則2: まだ最適化を行ってはいけない.

最初の原則は, われわれが最適化する前にそうすることの積極的ではっきりした根拠を必要とすること, およびしばしば正当化する根拠が存在しないことを述べている. もしその結果が使用されない計算機の CPU 時間を大きくするだけならプログラムを速くすることは意味がない. もしメモリの標準サイズにより分類された部分で使われない場所の数を多くするだけなら, プログラムを小さくすることは意味がない. もしプログラム・エラーのためにできたプログラムを 5% だけ再実行させることになりそうなら, 実行時間で 5% 減らしても意味がない.

2番目の規則は, 最終的には最適化するつもりでいても, 最適化されてない設計でいつでも始めなければならないことを述べている. 最適化されていない設計のみが十分な理解に必要な明白さと単純さを持ちうるものである. もし論理的エラーを導くことなく最適化するつもりなら, われわれは自分のプログラムを十分理解しなければならない. プログラム保守にたずさわってきた者はどうみても単純でないプログラムを変えるのがどれほど危険かよく知っている. 明らかに無害な変更でも驚くべき, かつ悲惨な影響を持つものである.

この後の記述では、計算機パラメータのチューニングとアルゴリズムの変更による最適化はその対象外であることと、「カントールの有理数の数え上げ」を題材にして、その最適化をどの様に行うか、またその際に発生する特定のデータ構造や変数、プログラム順序に対する依存性について、COBOL でのプログラムを例に、ところどころでちくちくと刺しながら書かれています。本当に最適化というものが嫌なんだな、、というのが伝わってきてとてもいいなって思います。

私は COBOL についても他と同様さっぱりなので、コードの中身は雰囲気でしかわからなかったですが、上記の引用文だけでも、それぞれの規則(ルール)とその理由が明確に述べられていて、当時の時代背景を差し引いたとしてもとても面白く読むことができました。

あと、序文ではもう少し違う観点も含んで、最適化についての記載が書かれています。

最適化に関しては, 次の2つの規則に従っている.

  • 規則 1 最適化を行うな.
  • 規則 2 (専門家だけのために) まだ, 最適化を行うな -- すなわち, 完全に簡明で, 最適化されていない解決を得ないうちは行わない.

..(中略)..しかし, 2つのポイントは常に憶えておくべきである. 第一は, 最適化はシステムの信頼性を下げ保守を困難にする. それ故作ったり実行させたりするのがより高価になる. 第二には, 最適化が構造をあいまいにするので, すでに部分的に最適化されたシステムの効率を改良するのがむずかしい.

かなり薄い感想ですが、個人的にまとめるとこんな感じかと思いました。

  • 最適化にはお金(と労力)がかかる

  • 実益のない最適化には意味がない

  • 最適化は保守性の低下を招く

  • 早すぎる最適化は部分最適を招き、その後の全体最適の大きな妨げになる

その他序文では、システム設計者とプログラマを分けるのはばかげている、などの何故か今に繋がる話であったり、日本語版に際しての M.A.Jackson さんから訳者の鳥居さん (https://ja.wikipedia.org/wiki/%E9%B3%A5%E5%B1%85%E5%AE%8F%E6%AC%A1) に書かれている賛辞も読めて、とても楽しい読書体験でした。（全部は読めていませんが。。）

調べるものをもりもり見つけてぜひまた行きたい！

プログラミングも頑張ります。。

*1:今のところ食べたもの系は Threads に放り込むことにしています。

JJUG CCC 2023 Fall に行ってみました

Java 関連にはこれまであまり縁がなかったのですが、今後 Kotlin + SpringBoot という構成のシステムに携わる可能性がありそうで、雰囲気を知りたくて、参加させていただきました。

ccc2023fall.java-users.jp

ほぼ初参加だったのですが、現地開催のみ、ということで、とてもとても賑わっていました。先日の PHP カンファレンス 2023 もそうだったのですが、本格的にカンファレンスが戻ってきた、という感じで、とてもわくわくできて楽しかったです。

以下、参加したセッションについての簡単な感想です。*1*2

https://sessionize.com/api/v2/2gdy2o95/view/GridSmart

Exceptionハンドリングの基本と新しい手法について (河野裕隆さん)

speakerdeck.com

Java の例外の分類と基本的な使い方をコンパクトに説明いただいた後での、パターンマッチと sealed によるすっきりした見通しのよいコードがとても印象的でした。

これまであまり深く考えたことがなかったので、例外処理について深掘りして、自身の知識をアップデートしたくなりました。

ブランチ運用とデプロイフローを見直してリリースを楽にする (ユカイさん)

speakerdeck.com

担当されているプロダクトのブランチ運用とデプロイフローの課題とその改善内容を、わかりやすくまとめていただいていました。

たくさんある課題と改善の中で、改善の際に「失われたもの」を一つ一つ上げられているところがとても印象的でした。
フィーチャーフラグの実装により、切り戻しが格段に早く、楽になる、というコメントが、とても納得感があって良かったです。
DB migration を伴うリリースはどう自動化しているのか、フィーチャーフラグの実装により分岐が増えてコードの見通しが悪くならないか? という点は、ぜひ意見お聞きしてみたいと思いました。

レガシーなWebサービスから世界標準への挑戦 (Rina Hashimoto さん)

GMOペイメントゲートウェイでの OpenAPI 実装の提供について。「王道」という感じでした。

この規模の歴史もあるシステムだと、いろいろあって大変で、でもその中でもきちんと今のWeb標準に則った対応をされていて、この「普通に開発する」の大変さをあまり感じさせないところがとても良かったです。
途中の説明にあった「決済系なので GET は使わない」は頷いている人が多かった印象ですが、RESTful に染まっている私にはちょっとピンと来なかったです。あと「リダイレクトとコールバックだけは cookie が消えるので GET で実装」は、もう少し詳しくお聞きしてみたいと思いました。（ドメインの異なるサイト間での情報の受け渡しになるから、、ということだと納得ですがそんな単純な話ではなさそうに感じました。）

JDK 21 へようこそ (dbuck さん)

この 9 月に出た Java21 について、いくつか代表的な新しい機能についての解説。

タイトルや概要を認識していたものはいくつかありましたが、詳しい内容は全然把握できていなかったので、とても嬉しいセッションでした。内容もわかりやすくてとても良かったです。なにより解説が日本語なことがとても助かりました。。すごい。

このあたりで持って行った PC のバッテリー容量がみるみる減って切れてしまい、なんで? ってなりました。寒かったからかな。。

あと一番前の机のある席が結構空いていて、座っている人があまりいなかったのがもったいない感じでした。遠慮せずに特等席でお聞きできてとても良かったです。

持続可能なデータアーキテクチャを実現したリアーキテクティング (Katsuyoshi Urano さん)

www.docswell.com

指数関数的に増大するデータをバックエンドに持つシステムを、リアーキテクチャにより改善した話。

DynamoDB の制限の話がとても具体的な痛みで良かったのですが、どなたかも書かれていましたが、ここは JAWS-UG かと思ってしまいました。面白かったです。タイムアップになってしまったのですが、アプリケーションのリアーキテクチャの話もお聞きしたかったです。資料が後ほど公開されるみたいなので、拝見してみたいと思います。

この辺りで会議室の寒さに耐えられずに一旦外に出ました。

動くコードを書こう (kis さん)

speakerdeck.com

「きしだのはてな」で有名なきしださんのセッション。とてもこなれている感じで考えさせられる楽しいセッションでした。
内容は、先日休刊した Web + DB Press で書かれていた記事から、ということだったのですが、未読なのですが内容には既視感があり、過去にきしださんが書かれていた以下の記事を思い出しながらお聞きしていました。

nowokay.hatenablog.com

この件は昔からずっと気になっていて、先日以下でこの記事の内容をダメコードですが簡単に実装してみたりしていました。

github.com

自身のプログラムを書くことののわかりにくさのポイントとか、人に教えるときの考え方とか、AIとの棲み分けとか、コードを書く話でありながら、コードを書くこと以外で考えることが多い話題だと思いました。身近でお聞きできてとても良かったです。

アンカンファレンス (谷本さん、他)

アンカンファレンスのテーマ募集のホワイトボードがあったので、Java に詳しくない身から「Java 言語の使いどころと他の言語とのすみ分け」のチケットを貼ってみたところ、取り上げていただいていろいろな観点からみなさんのお話を聞くことができました。メンバーの持っているスキルによるところが大きいということでしたが、他にも、型付き言語であることの利点、問題があった場合の原因追及ができるツールの豊富さ、10年選手としての後方互換性の高さ、書ける・運用できる人の多さ（特にベテラン勢）など、主にエンタープライズ領域で第一線を張っている言語ならではの特徴を、著名な方々から実感を持って聞くことができて、とても参考になりました。

PHP や Ruby などで作られたシステムを、生き残って大きくなるにつれて他の言語で作り直す／一部機能を分離する、という話はよく聞きますが、知識としてその言語やエコシステム、人材の特徴などは知っていても、実感を伴わないままで選択はしたくないな、と改めて思いました。

あと、アンカンファレンスの内容については、書けない話が多いことがよくわかりました。ほぼ会話を聞いているだけでしたが、楽しかったです！

ラムダ式をHowではなくWhyで理解しよう！ (青木 澄怜さん)

speakerdeck.com

ラムダ式を理由から理解しよう、というお話。

傘のメタファーでのWhyの大事さの説明など、納得感あってとても良かったです。初心者の方に説明する際に使ってみたいと思いました。
何より一年目で登壇してお話しされているその勇気に敬意を評したいです。登壇の経緯を質問された際の、受け取った恩返しとチャレンジの話は、とてもグッときました。それを聞いた会場の、おおっ、という感じもとても良かったです。みんないい人。

スポンサーブース

Oracle さんのノベルティが欲しいなって思ったのですが、アンケートに「会社名」を書く欄があって、現在主夫なので断念しました。勇気を出して聞いてみれば良かったです。😄

GMO さんの Java クイズは、プログラムはともかく、Effective Java を読んでいないので回答を断念しました。やっぱり部外者には難しい。。

まとめ

JJUG とても良いなって思いました。今回は多くのものをいただいた形なので、次回参加するときまでに何か還元できることにチャレンジしたいと思いました。

登壇者のみなさま、スタッフのみなさま、スポンサーの企業さま、本当にお疲れ様でした ＆ ありがとうございました。

*1:セッション一覧にはセッションごとのパーマネントリンクが設定されていないみたいで、API実装がかっこよさそうなのに、直接のリンク貼れないのがちょっと残念。。

*2:各セッションの資料が公開されたら、できるだけ拾って追記したいと思います。

Flutter/Dartに入門してみる 環境準備編(1)

7月からしばらくお休みをいただいたので、宣言的 UI によるスマートフォンアプリの開発を理解したいと思い、Flutter に入門してみることにしました。

アプリ開発は iOS, Android とも過去に少しだけ入門的なものを少しだけ触ったことがあるだけで、無に等しい状態なので、道のりは長いですが楽しみです。

まずは開発環境のセットアップからメモしてみます。

(2023/7/9追記)

Java のバージョンを当初 defaut-java で入る 11 にしていたのですが、後ほど入れる Windows 側とバージョンを合わせたいため LTS の 17 に変更しました。

方針

作るものは最小限にしたいので、ターゲットは当面 Android のみ、半年ほど前に買ったスマートフォンの Pixel6a 上で動くことをターゲットにします。

手元にある Windows10 + WSL2 (Ubuntu22.04.2) 上で開発環境を作ります。

コードは WSL2 の Linux 上の Vim で Terminal 経由で書き、Windows 上のエミュレーターと実機で確認できるようにします。

標準的な構成ではないので少し遠回りになるのですが、比較的慣れている環境でコードを書いてみたいのと、統合開発環境のメニューなどであまり隠蔽されていない、素の状態で進めた方が本質の理解が進むと思ったからです。

事前準備

Microsoft Store から WSL2 に Ubuntu 22.04 を入れます。

OS 入れた後はあらかじめ用意している dotfiles で適度に実施、Windows Terminal から Java と Vim が一旦使える状態にします。

Java は以下で openjdk-17 を入れておきます。

$ sudo apt update && sudo apt install openjdk-17-jdk -y
...
$ java --version
openjdk 17.0.7 2023-04-18
OpenJDK Runtime Environment (build 17.0.7+7-Ubuntu-0ubuntu122.04.2)
OpenJDK 64-Bit Server VM (build 17.0.7+7-Ubuntu-0ubuntu122.04.2, mixed mode, sharing)

ベースの準備が整ったら Terminal から一旦抜けて cmd でコマンドプロンプトを開いて、念のため作った環境のバックアップを取っておきます。

> wsl -l -v
  NAME            STATE           VERSION
* Ubuntu-20.04    Stopped         2
  Ubuntu-22.04    Running         2
> wsl -t Ubuntu-22.04
> wsl -l -v
  NAME            STATE           VERSION
* Ubuntu-20.04    Stopped         2
  Ubuntu-22.04    Stopped         2
> wsl --export Ubuntu-22.04 C:\tmp\Ubuntu-22.04.tar

手元の環境だとファイルサイズは 5GB 程度になりました。

WSL2 上のセットアップ

基本的には以下の公式の手順に従って進める形になります。

docs.flutter.dev

Flutter SDK のインストール

あまり覚えるものを増やしたくないので snap を使ったインストールは行わず ${HOME}/dev 配下にマニュアルで入れます。

Android Studio のインストール

Android Studio は全部は使わないので、コマンドラインツールだけを入れます。

developer.android.com

ここの下の方にある「Command line tools only」の Linux のリンクをクリックして、規約に同意した上で URL を入手して、Linux 上から curl でダウンロードします。

インストール先など含めてこんな感じです。ここでは platform-tools だけ入れておきます。

$ mkdir -p ~/Android/SDK/cmdline-tools
$ curl https://dl.google.com/android/repository/commandlinetools-linux-xxxxxxxx_latest.zip -o latest.zip
$ unzip latest.zip
$ mv cmdline-tools ~/Android/SDK/cmdline-tools/latest
$ rm -rf latest.zip
$ export ANDROID_HOME=$HOME/Android/SDK
$ export PATH=$PATH:$ANDROID_HOME/cmdline-tools/latest/bin
$ sdkmanager --list
[=======================================] 100% Computing updates...
$ sdkmanager --update
[===                                    ] 10% Computing updates...
Updating:
...
$ sdkmanager --install "platform-tools"
...

入れた後の flutter doctor では Android SDK を flutter からは認識しなかったので、公式の手順にある以下を実行すると認識してもらえました。

$ flutter config --android-studio-dir=$HOME/Android/SDK

インストール後の確認

最終的にはこんな感じになりました。

$ flutter doctor -v
[✓] Flutter (Channel stable, 3.10.5, on Ubuntu 22.04.2 LTS 5.15.90.1-microsoft-standard-WSL2, locale C.UTF-8)
    • Flutter version 3.10.5 on channel stable at /home/msfukui/dev/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 796c8ef792 (3 weeks ago), 2023-06-13 15:51:02 -0700
    • Engine revision 45f6e00911
    • Dart version 3.0.5
    • DevTools version 2.23.1

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at /home/msfukui/Android/SDK
    • Platform android-33, build-tools 30.0.3
    • ANDROID_HOME = /home/msfukui/Android/SDK
    • Java binary at: /usr/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.19+7-post-Ubuntu-0ubuntu122.04.1)
    • All Android licenses accepted.

[✗] Chrome - develop for the web (Cannot find Chrome executable at google-chrome)
    ! Cannot find Chrome. Try setting CHROME_EXECUTABLE to a Chrome executable.

[✗] Linux toolchain - develop for Linux desktop
    ✗ clang++ is required for Linux development.
      It is likely available from your distribution (e.g.: apt install clang), or can be downloaded from https://releases.llvm.org/
    ✗ CMake is required for Linux development.
      It is likely available from your distribution (e.g.: apt install cmake), or can be downloaded from
      https://cmake.org/download/
    ✗ ninja is required for Linux development.
      It is likely available from your distribution (e.g.: apt install ninja-build), or can be downloaded from
      https://github.com/ninja-build/ninja/releases
    • pkg-config version 0.29.2
    ✗ GTK 3.0 development libraries are required for Linux development.
      They are likely available from your distribution (e.g.: apt install libgtk-3-dev)

[!] Android Studio (not installed)
    • Android Studio not found; download from https://developer.android.com/studio/index.html
      (or visit https://flutter.dev/docs/get-started/install/linux#android-setup for detailed instructions).

[✓] Connected device (1 available)
    • Linux (desktop) • linux • linux-x64 • Ubuntu 22.04.2 LTS 5.15.90.1-microsoft-standard-WSL2

[✓] Network resources
    • All expected network resources are available.

! Doctor found issues in 3 categories.

実機を使った動作確認

ここまでで一旦、サンプルのプロジェクトを作成して、実機にワイヤレスで接続して動作確認を行ってみます。

実機への接続準備

以下の Android Studio のマニュアルをもとに実機の「開発者オプション」を有効にします。

一度有効にすると二度目は実施しなくてもよいみたいです。

developer.android.com

続いて以下のページをもとにワイヤレスで接続するのですが、ここちょっとわかりにくいです。。

developer.android.com

こんな流れになります。

  • 「システム」の「開発者向けオプション」を選択して「ワイヤレスデバッグ」をタップして有効にします。

  • 「ペア設定コードによるデバイスのペア設定」をタップして IP, ポート番号, ペア設定コードを表示します。

  • Terminal 側で adb でペアリングを実施します。

$ adb pair 192.168.10.114:36059
Enter pairing code: ******
Successfully paired to 192.168.10.114:36059 [guid=adb-2B031JEGR13357-xR5Wml]
  • 実機に表示されている IP, ポート番号（これは先ほど入力したポート番号とは別のポートです）で adb connect します。
$ adb connect 192.168.10.114:39067
connected to 192.168.10.114:39067
  • 接続出来たら flutter から認識できているか確認します。実機の情報が表示されたらOKです。
$ flutter devices
2 connected devices:

Pixel 6a (mobile) • 192.168.10.114:39067 • android-arm64 • Android 13 (API 33)
Linux (desktop)   • linux                • linux-x64     • Ubuntu 22.04.2 LTS 5.15.90.1-microsoft-standard-WSL2

サンプルのプロジェクト作成と実行

次に、適当なディレクトリで flutter create でプロジェクトを作成します。ここでは myapp プロジェクトを作っています。

$ flutter create myapp
Creating project myapp...
Resolving dependencies in myapp... (1.3s)
Got dependencies in myapp.
Wrote 129 files.

All done!
You can find general documentation for Flutter at: https://docs.flutter.dev/
Detailed API documentation is available at: https://api.flutter.dev/
If you prefer video documentation, consider: https://www.youtube.com/c/flutterdev

In order to run your application, type:

  $ cd myapp
  $ flutter run

Your application code is in myapp/lib/main.dart.

移動してとりあえずアプリを実機で実行してみます。 フォアグラウンドで動作するのでプロンプトが戻ってこなくなる点には注意です。 （実行後に 'd' で動作させたままデタッチできますが。。）

$ cd myapp
$ flutter run -d 1
Launching lib/main.dart on Pixel 6a in debug mode...
Running Gradle task 'assembleDebug'...                             50.0s
✓  Built build/app/outputs/flutter-apk/app-debug.apk.
Installing build/app/outputs/flutter-apk/app-debug.apk...          24.1s
Syncing files to device Pixel 6a...                                 81ms

Flutter run key commands.
r Hot reload. 🔥🔥🔥
R Hot restart.
h List all available interactive commands.
d Detach (terminate "flutter run" but leave application running).
c Clear the screen
q Quit (terminate the application on the device).

A Dart VM Service on Pixel 6a is available at: http://127.0.0.1:44739/********=/
The Flutter DevTools debugger and profiler on Pixel 6a is available at:
http://127.0.0.1:9100?uri=http://127.0.0.1:44739/********=/

実機にデモアプリが表示されたらOKです。

'+' ボタンを押すと真ん中中央の数字がカウントアップされるデモアプリになっています。

動いてよかった。。

切断する際は、 'q' で終えるか 'd' でデタッチした上で、 adb disconnect します。

$ adb disconnect
disconnected everything

実機の「ワイヤレスデバッグの使用」をオフにするのも忘れずに実施しておきます。

次回は Windows のセットアップとエミュレーターとの接続、 Vim の設定回りについて書きたいと思います。

参考情報

セットアップにあたって参照した記事になります。とても参考になりました。ありがとうございます。

qiita.com

blog.cosnomi.com