2025年の目標

今年も目標を設定して取り組んでいこうと思います｡

昨年は定性的な目標がいくつかあったので､定量的に測れる目標を据えるようにします｡

目標を設定するに当たり思ったこと

今年でITエンジニアを始めて一年になるので､今後を見据えて飛躍できるようにしたい｡なんなら現職を始めるときに3カ年計画を立てたのでもうすぐその期間の半分が終わるので､ゴールを見越した動きを取っていきたいですね｡

あと､子どもが生まれてから時間を作れない､時間が足りない気持ちに囚われていました｡そんなときに愛聴しているポッドキャストのひまプロのかいちさんが同時期に子どもが生まれてもキャッチアップに励んでいるのを聞いて､私もできる限りやれることをやっていきたいと刺激を受けました｡

何でもかんでもはできないけれど､方向性を絞って､時間を有効活用して頑張れればと思います｡

今年の目標

30冊読書する

昨年の20冊目標未達成でしたが､1.5倍に目標をアップさせました｡

去年の反省として熟読してばかりでインデックスを付ける読書をすることが少なかったことがありました｡今年は速読と熟読を織り交ぜて多めに読書できればと思います｡

あと､技術書ばっかり読んでたから小説とかビジネス書も読みたいですね｡

GOを習得する

毎年新しい言語を1つ習得しよう､と達人プログラマーにありました｡それに習ってGOを学び始めようと思います｡

もともと低レイヤに興味があって色々知識習得を進めている段階なので､相乗効果を狙ってます｡あとはRustも興味あったけど初手Rustは難しいってことだったので間にGOを挟む感じです｡

低レイヤ〜SRE領域を学ぶ

マーケやってた身として､ポテンシャル採用の30代半ばの未経験ITエンジニアが生き残っていくためにどうしたらいいか考えて､強みを持つことが必要と結論になりました｡

それで低レイヤからSREを習得して開発を加速させる人材を目指します｡

ブログ60記事

アウトプット習慣は引き続き維持したいなーと思います｡

アウトプットついでに知らない領域のキャッチアップ（AIとか）ができたら..と目論んでます｡

毎日振り返りをする

結構前に100日連続日記やブログでアウトプットしていた時期があって､そこで鍛えられた言語化力とか自己観察力みたいな部分が今も生きているので､今こそ改めて日記みたいな振り返りをしていくことにしました｡

アウトプット先はIphoneのメモ帳あたりで気軽にね｡

英語学習を続ける

Duolingoを意図せず年間有料会員にしてしまったことから､昨年の10月ぐらいからずっと平日朝夕にDuolingoをやる習慣が続いています｡

英語が読めると英語媒体からキャッチアップできるようになるのでITエンジニア的には効果高いんですよね｡英語学習は今年も細く長く続けていきます｡

やらないこと

2024年はずーっとコードを書かないことを恐れていてモヤモヤしていたんですが､時間が限られているので無理やりコードを書くことはせずにインプット中心になるならそれでいいと思うようになってきました｡

なので､コードを書かないことは恐れません｡

あとはフロントエンドの学習も基本的にやらないことを決めました｡仕事を通じて視野が広がって考えてみるとフロントエンドは変遷が速いし､職場ではフロントエンドは分業が確立されているので触れる機会も少ないしで無理にキャッチアップしなくていいと思うようになりました｡

なので､フロントエンドの学習をしません｡していないことを恐れません｡

まとめ

以上です｡

書いたこと以外にもプライベートの身の振り方とかちょっとした目標を立てています｡全部達成できるように頑張るぞ｡

2024年の振り返り

2024年の振り返りです｡

↓の記事で2024年の目標を決めていたのでその振り返りを中心にやっていきます｡

2024年の目標 - 自転車とプログラミング

エンジニアに転職する

これは達成できました｡おかげさまでエンジニアとして働いています｡

職業エンジニアとして軌道に乗る

これはどうなんでしょう？？

未経験で半年くらいしか経過していないので技術も経験も足りていないことに痛感する日々ですね｡仕事しててわからんことが多いです｡

自社開発企業の先行開発部門なのでプロダクトに関わる多くの業務を捌く必要があり､開発をしたりしなかったりしています｡このあたりはもっとコードかけるようになって､周囲から技術的な信頼を勝ち取らないとやりたい仕事だけをやるサイクルにはまだ乗れないなと思ってます｡

今はまだ便利屋みたいな立ち位置ですが2025年こそはというところ｡

円満な家庭を築く

また計測できない目標が来てしまった｡｡｡

自分でもこんなもん目標に据えるもんじゃないなーと12月頭に目標を振り返って思いました｡去年目標設定したときは前職をやめるかエンジニアになるか揺れていたり､家族が増えることがわかったりと気持ちを新たにする意図もあって目標にしたんでしょうねえ｡

子どもが生まれてからは妻が家庭を､私が仕事（収入）を､と役割分担している状況になっているのですが､妻が家庭を支えてくれているので私も仕事できているので､自分の時間よりも家族の時間にコミットすることを第一に動いています｡自分のことは最後に夜な夜な取り組む感じに変わりましたね｡

円満な家庭を築くって目標は一発のアクションと言うよりも日々の積み重ねを家族がどう捉えてくれるかで達成できるかどうかが変わってくることだと思います｡ITエンジニアより先に夫であり父であることを忘れずにこれからもやっていこうと思います｡

書籍を最低20冊読む

これは未達成でした｡だいたい17冊くらいだったかと思います｡

結構重めの書籍を多く読んでいたのと､すべての本をしっかり取り組みすぎていたかなーというのが反省｡

だいたい本を読むときはメモを書きつつ､あとで発信するためとかにまとめをしたりするんですが､その工程が結構時間がかかってしまって本の進みが遅い｡本を読むのが目的ではなくて､内容理解が目的なので良いのですが｡

現状としては技術書を読むためのベースの知識が足りてないので､何を読むにも時間がかかってる感じがしています｡これが前提知識が着いてくるとペースを上げられるし､よいサイクルに入るので､そういうレベルを目指します｡

それはそれとして､軽めに育児本､ビジネス書を併読して読書の使い分けができるといいなーと言うのが2025年の目標ですね｡

ブログ記事を120回投稿する

2024年は57回で未達成でした｡

前半はいいペースでブログを書いてたんですが､可処分時間が減った中で業務に必要な知識をみにつけることを優先して､年の後半はインプット中心になりました｡やむなしかな｡

目標外のところで

コードをもっと書いていきたい

2024年の取り組みは､結果としては未達成ばっかりだったので不満が残る結果になってしまいましたが､ITエンジニアになってキャッチアップの読書に取り組んでいたので取り組みの方向性は良かったかなと思います｡

転職して子どもも生まれたことを踏まえて､もっと時間を有効活用して結果を残していく必要がありますね｡

今がインプット中心になってしまっていてコードを久しく書いていないので､2025年は書いていきたいですねえ｡

抽象化と実装､どこまで学ぶか

基本情報を受けてから技術的な視野が広がったので､これまでよりも低レイヤな領域を学ぶことを少し前から始めた｡

ちょうど最近Xで「ネットワークのXXXも知らんのかって言われるけど､低レイヤをやる必要はない､際限ないから業務で使う技術に集中しろ」みたいなポストを見かけてちょっと考えることがあった｡（元ポストが見つからないので意図が違うかも､私がそう受け取ったということで）

業務で使う技術に限らず「どう動いているか」はある程度知っておいた方が最終的な実装にも影響があるんじゃないかと思うんですよね｡

私とかは業務で作っているのがユーザー環境で動くソフトウェアだから､OSがどう動くかとかCPUやメモリがどう処理しているかってことも守備範囲に入ると思う｡そのうえで実際にユーザー環境で動作させるツール類を触っていきたい｡

あと､個人的な興味としてRubyがどう動くか知りたいっていうのも大きい｡「なぜ動くか」がわかったうえで使っていきたいと考えている｡C言語でどう実装されているのか､C言語はどう動くのか､そういった水準でRubyを理解したい｡そう思うと自然と低レイヤを知っていく動機ができていた｡

そもそも､技術に関してはレイヤのコンテンツごとに「何も知らない（一部のコマンドだけ知ってる）」「インターフェースを知ってる」「仕様を知ってる」「実装がわかる」って感じにレベルが分かれるんじゃないかと思う｡ 当然､私が学んだとしても専門に低レイヤ研究してた人にはかなわない､仕様を知っていて実装は知らないってレベル感に落ち着く｡

WEBアプリケーションはアプリケーションより下のレイヤにおいてブラウザがおおきなインターフェースになっているので概念が圧縮されていて､学ぶ必要性が薄いのかも？このあたりは個人の興味と担っている業務次第だと思う｡

オライリーの「コンピュータシステムの理論と実装」を最近読んでいて､これはNAND回路から始まり､テトリスが動かす環境をハンズオンで作っていく書籍でごりごりの低レイヤ本だ｡

モジュール化したシステムを最終的に組み合わせて形にするらしい｡このモジュールというのが抽象化（モジュールが何をするか）と実装（モジュールがどう動くか）においてはキーになっていて､「モジュールの抽象化のみを考え､実装については完全に無視できる」としている｡モジュール化した機能を持ってくるなら､インターフェースに習熟すれば使えてしまうということになる｡コンピュータサイエンスの鉄則らしい｡

冒頭のポストもこの鉄則に準じた考え方だと思う｡ とはいえ世に出回っているツール､ライブラリの類は特定目的に使うためのモジュールではないから､応用的に使うためには仕様の理解が必要ではなかろうか｡

PostgreSQL Conference Japan 2024 ã«å‚åŠ ã—ã¾ã—ãŸï¼ˆï¼‹ãƒ‡ãƒ¼ã‚¿ãƒ™ãƒ¼ã‚¹ã‚’å­¦ã¶ãƒ¢ãƒãƒ™ãƒ¼ã‚·ãƒ§ãƒ³ï¼‰

12/6に開催されたPostgreSQLのカンファレンスに会社の同僚と行ってきましたので､「なんでDBなんだ」てところも含めたレポートです｡

この記事はフィヨルドブートキャンプ Part 2 Advent Calendar 2024の15日目の記事です。

当初はエンジニアになったので普段を振り返ってあれやこれや書こうかとも思いましたが､ネタ被り著しいので直近の話題ということでPostgreSQLに触れていきたいと思います｡

まず自己紹介

2023年12月にFJORD BOOT CAMP（フィヨルドブートキャンプ）を卒業後､Railsを使った自社開発企業に就職しました｡

エンジニアになってからはプロダクトを触ったり､他部署のヘルプに行ったり､LT会を開催したり､インフラやDevOps周りを見たりして､今は簡単な機能追加をさせてもらったりしています｡FBCで鍛えてもらったのでなんとかやっていけてます｡

経費で受けさせてもらった基本情報や業務を通じて視野が広がったので､インフラや低レイヤよりなことに興味を持っています｡

なぜデータベースなのか

アプリにはどうやってもデータベースがついてくるのですが､フィヨルドブートキャンプではER図を書いて正規化は学習して､標準SQLはなんとなく書ける状態だけれども実務に足るデータベースの知識もSQLの知識もなくて､自分の中でブラックボックス化していたことに危機感が湧きました｡

Railsでもモデルを書けば大体ActiveRecord経由でデータベースにデータを永続化させるわけで､データベースはだいたい使うんですよね｡

ただ､抽象化されて気にしなくて良い風になっているだけ｡アプリケーションの一部としてデータベースが存在するのでこれは知らなきゃいかんな､となりました｡

Rails 8.0のSolidもモチベーションに

ついで程度ですが､Rails8.0でデータベースを使った機能が追加されたこともモチベーションになりました｡

Solidってやつですね｡データベースをインメモリDBのように使用することでアプリが依存するミドルウェアを減らして実装をシンプルにしてくれます｡

TechRachoさんの記事にリポジトリの和訳が掲載されてますので､ご存じない方はぜひこの機会にどうぞ｡

techracho.bpsinc.jp

私がSolidを知ったときに「Solidの嬉しいポイント」というのがいまいちピンと来なかったんですよ｡で､結構調べてようやく掴めてくるという｡そういうのはあまり良くないなと思ったのも学ぶきっかけでした｡

データベースの学習って難しい

SQLを学んで､ER図とか正規化がつかめるようになるのがフィヨルドブートキャンプのカリキュラムでした｡あとはさらっとPostgreSQLにふれるプラクティスがあったくらいかな｡

いまならFBCがこのプラクティスにしていた理由もわかる気がするんですが､データベースって奥が深い｡さっきカリキュラムとして挙がっていたSQLやER図だけでなくて論理設計や物理設計みたいな話も分野としてあるし､PaaSを使っちゃえば実装をそんな知らなくても抽象化されたインターフェース越しにデータベースをいじることができる｡

学ぶことが多くて､未経験者には沼､RDBMS自体に種類があって教材が分散してしまっているので学習するのは難しい領域だと思います｡

私も職場で相談したときには「まずは標準SQLから入ってみては」とアドバイスもらって､それ系の技術書を何冊か読んだ段階でカンファレンスを迎えました｡

PostgreSQL Conference Japan 2024

ようやくカンファレンスの話に入ります｡先に書いてしまいますが､SQLから学習初めてPostgreSQLのキャッチアップができていなかったので話は1/3もわからなかったのが正直なところ｡とはいえ､なんとかまとめてみます｡

午前中はキーノートとしてAWSに所属されているコミッタの方が講演されていました｡AWSの話は控えめ｡ お二方とも業務としてPostgreSQLにコミットされてるとのことでした｡

ちなみに､キーノートは動画で公開されてます｡

www.youtube.com

【K1】PostgreSQL 17とPostgreSQL開発最前線

キーノート第一弾はコミッターの澤田さんによるものでした｡

PostgreSQL17での機能追加とちょっとだけPostgreSQL18にかかわる話がありました｡

• vacuumが性能向上してアップデート
• 増分バックアップに対応｡増分したバックアップファイルをあとから結合可能｡
• PostgreSQLコミュニティの取り組み

どこかで説明があったのですがVacuumはRubyでいうところのGCみたいなものということでイメージがつきました｡

特にDBのパフォーマンスにあたってはメモリをどう活用するか､の話になる部分が大きいと思うのでこの性能向上はすごいな､と｡DBの違いとか発展は全然知らなかったのでPostgreSQLの進歩すげーて感心してました｡

【K2】AWS and the PostgreSQL community

澤田さんと同じく AWS の PostgreSQL Commiter のミカエルさんの発表でした。

• PostgreSQLのコミュニティ紹介の際にカンファレンスを開催したJapanメンバーに拍手するよう促していたのが印象的｡PostgreSQLコミュニティの雰囲気を表していたと思った
• PostgreSQLのコードベースが現在110万行ぐらい｡年間3〜4万行増えているらしい｡でかい｡

どこかでPostgreSQLの機能追加はすべてコミッターのチェックの上で行われると聞いたことがあります｡100万行のオーバーだと影響を考慮する範囲も広いし､大変ですね｡

【T1】Explain EXPLAIN：EXPLAIN を使ったPostgreSQLのクエリ最適化の基本と実践

PostgreSQLのクエリ実行計画を読み取って最適化しよう､そのやり方を解説いただきました｡ スライドはすでに公開中です｡

speakerdeck.com

PostgreSQLがクエリを受け取って結果を返すまでの内部処理の解説があったんですが､別の講演でも同箇所の解説が出てきたのでかなり重要なポイントだと伝わりました｡

EXPLAINで表示されるのがクエリの実行計画と呼ばれるやつで､この中にクエリがどのように実行するのか書いてある（インデックスをスキャンするのか､テーブルを丸ごとスキャンするのかなど）｡なので､これを読み解くことでクエリ改善の糸口がわかる､ということになる｡

プランナーが作成する実行計画は､インデックスの有無､統計情報の内容から､大体は効率を考慮して複数の実行計画から絞り込みが行われる｡いい感じのインデックスと最新の統計情報を与えてあげてプランナーが最適な実行計画を立てるのを支援するのがいいんだと理解しました｡

【T3】PostgreSQL でインデックスはどう使われるのか

検索を高速化させるインデックスの使い方を学びました｡

• 演算子族､演算子クラスの概念をここで知りました｡演算子クラスがマッチしていることがインデックスが使われるかどうかの判定に使われています｡
• こちらの講演でもクエリのリクエストからクエリ結果をレスポンスするまでの内部処理が解説されてました｡

【T4】基礎から学ぶ PostgreSQL のバックアップ ―基本機能と運用設計

ちょうどバックアップに限って若干調べたことがあったので非常に楽しみにしてました｡

• バックアップの種類からPostgreSQLのお作法まで
• 17で追加された増分バックアップの解説

Theチュートリアルって感じに初心者フレンドリーな内容でとっても勉強になりました｡ 配布された冊子と講演に使われたスライドの内容がだいぶ違っていたので､スライドの公開を心から待っているところです｡

その他

会場でPostgreSQLの参考書（電子書籍）買いました｡影響受けやすいタイプです｡

［改訂3版］内部構造から学ぶPostgreSQL―設計・運用計画の鉄則 Software Design plus

æ–‡æ³•ã§ã¯ãªãæ§‹é€ ã§æ¡ä»¶åˆ†å²ã‚’è§£æ¶ˆã™ã‚‹ （良いコード悪いコードで学ぶ設計入門 ちょい感想）

大層なタイトルを付けましたが､大した話ではありません｡

少し前に「良いコード/悪いコードで学ぶ設計入門」という本を読みました｡設計と言われても特にイメージのわかないレベル感でしたが､読み終わることにはタイトルみたいなことがなんとなくイメージできるようになりました｡

それがまあ､タイトルみたいな考え方になります｡文法レベルよりもレイヤを上げて､構造でもって可読性を探訪するような取り組みが設計なのかなと｡

if文で考えてみるとわかりやすい｡ 条件分岐を重ねてネストしていってもプログラムの分岐処理はもちろん構築できる｡ただ､ネストしたコードが読みやすいかは別の話｡

では､return を使ってネストを浅くしたりとか､そもそもダックタイピングみたいな仕組みを使って条件分岐をそもそも書かないみたいなアプローチが可能です｡なが〜い条件分岐の文を読んていくよりも､このアプローチで拘置するとだいぶ人間が読み取りやすくなります｡

Rubyだとダックタイピングの概念があって､クラスやオブジェクト指向の話になると必ずといっていいほど登場してくるのであまり重要視していなかったのですが､この本ではJavaが使われているので言語の部分は比較することができて､それもあってダックタイピングの利点ってこういうことか､と理解が深まりました｡

ダックタイピングばかり出しちゃいましたがデザインパターンとかも同様ですね｡

買ってよかった M2 MacBook Air

M4 MacBookが発表された状況で今更ですがM2 MacBook Airを買いました。

もともと2018年モデルのintel Macを使っていたのですが、ブラウザとIDE開いてDockerを動かすとメモリが枯渇してしまって動作がもっさりしていたのでなんとかしたいと思っていました。

とはいえ、M3もM4モデルも過剰スペックと感じていたところ、「M2であと〇〇年戦える」みたいな書き込みを見たのでM2で十分かなとなりました。

スペックは↓のとおりです。

スペック

• モデル：M2 MacBook Air 2022
• メモリ：16GB
• SSD：512GB

その他仕様は純正の通り。

認定整備済製品を買った

あまり新品を購入することにこだわりはなく、一つ前に使っていたMacBookもヤフオクで買った中古品でした。

そのころは「プログラミングするぞ、できるだけ安く」みたいな気持ちがあってのことだったのですが、ある程度わかるようになってきた今となってはトラブルがあってもめんどくさいのでヤフオクは除外。

色々しらべたところ認定整備済製品がAppleにはあることがわかり、認定整備済製品から希望に合致したモデルをちょっと安く（15％オフくらい？）で買いました。

届いた実機を見ても中古とはわからないレベルの美品で、バッテリーも交換されているそうなので私としては満足できるものでした。

使用感

M2に移行して今のところサクサクに動いています。 前機ではファンがフル稼働しながら動作がもっさりって具合だったので、M2は静かにサクサク動いて感動的なレベルです。

まだ重い処理や並行作業をしていないので、この辺りは様子見していく感じになります。

è·å ´ã§LT会を開催して登壇しました

職場でLT会を企画して開催しました。 社内だと初めてのことだったようで「噂のLT会とはなんぞや」ってな感じで30人くらいが視聴してくれました。

なぜ開催したか 職場は20年くらい歴史のあるソフトウェア開発の会社なんですが、SE寄りな志向が強いんですかね。

職人気質に自分の技能を高めていく志向が強いというか、あまりオープンにしていく空気があまりなかったわりに、若い年代の人の「LT会ってどう？」と聞くとだいたいノリのよい回答をもらえたので「いっちょやったるか」と開催することにしました。

企画から開催まで意外と時間がかかってしまって3〜4ヶ月くらいかかりました。この間、別のイベントを担当したりもしてたのでLT会は落ち着いたらやろうってな感じで温めてきました。

そうやって時間が経つ間に「なぜLT会をやるのか」みたいな部分を改めて考えたりすることもあり。。。。

そもそもはこの職場に爪痕を残していくぜーみたいな下心もありつつ、今後の業務を回しやすくするための取り組みとして考えてました。まあ、当初は上に書いたように周囲の同僚に歓迎されたし登壇したいという声もあって渡りに船でもありましたが。

LT会みたいな活動をボトムアップで草の根的に続けていけば、文化として浸透していくと思うんですよね。ゆくゆくシニアでもジュニアでも技術を語り、自己開示を通じてチームビルディングが捗る組織にならんかなーと企んでます。

夢は壮大にいきたいもんですな。

ちなみに登壇内容はRails 8.0 Betaの話とSolid系のgemについてのさらっとした紹介でした。