はてなブックマーク

来週、学生たちに向けて『AI時代に学ぶ意味』というテーマで講演を行う予定で、その要点をここにまとめておく。 AI時代に学ぶ意味 概ね、理由は以下のとおり。 良い質問をするために知識が必要 AIの出力を評価する 抽象的なアドバイスを活用する これらを実行するためには、一定の知識とスキルが必要である。 スキルを身につけるためには基礎知識があるうえで経験が必要であり、そのサイクルがまさに学びなのである。 そのため、AIが普及したとしても、人が学ぶことの重要性は変わらない。 その前提を踏まえたうえで、各ポイントについて説明する。 良い質問をするために知識が必要 AIに質問する際には、質問の意味を理解している必要がある。 そして質問するにはまず、自分の無知の状態を認識しなければならない。 無知には5段階のレベルがあって、自分がどの状態にあるのか理解する必要がある。 これをFive Orders of

最近、1on1で同じ話を何度かしたので、ここに整理して残しておく。 生成AI・LLMが当たり前になりつつある今、「これから自分のキャリアをどう築けばいいかわからない」という相談を受けることが増えた。 新卒から自分と同世代*1まで、悩みの種類は違っても不安の根っこは似ている。 そのときにセットで話すことが多いのが、能力の伸ばし方とキャリアの積み上げ方だ。 能力の成長ステップは、こちらの資料に詳しくまとめている。 speakerdeck.com この記事では、主にキャリアをどう築くか、に絞って書く。 キャリアの築き方：土台を広げ、実績を積む キャリアは、積み木を積み上げていくようなものだ。 細く高く積むと、ちょっとした揺れで簡単に崩れる。たとえば、一時的な特需に合わせて実績の高さだけを優先して積むと、環境が変わった瞬間に吹き飛ぶ。 だからこそ重要なのは、土台（基礎）を広く、強くすることだ。 土

5W1H（Why/What/Who/When/Where/How）は、日常のコミュニケーションやプロジェクトの設計・開発に有効な普遍の型です。 さらに、AI（LLM・エージェント）とのやり取りでも威力を発揮します。 過去にもテキストコミュニケーションのコツとしてSBIモデルコミュニケーションを紹介しましたが、5W1HはSBIモデルにも通じます。 そこで自分の登壇資料でも度々紹介している5W1Hに注目し、各要素の意味と役割、Why→What→制約→Howの順で書く理由を解説します。 引用元：問題を解決するために必要な習慣 / developer-lifehack p.76 1. 5W1Hとは 5W1Hは有名なフレームワークなのでご存じの方も多いと思います。 5W1H = Why / What / Who / When / Where / How の6つの項目からなり、情報の抜け漏れを防ぎ、議

サービスが成長するにつれてデータベースは肥大化する。 肥大化したデータベースは最初は良かった設計も、パフォーマンスの低下やメンテナンスが難しくなる。 もちろん、そうならないように最初から設計を工夫することもできるが、サービスの成長に伴い要件が変化することも多い。 そうなると全ての変更を予見することは難しいため、データベースのリファクタリングは必要不可欠だ。 実際にAIを利用したソフトウェア開発が主流になっていきつつある昨今はよりデータベースの成長速度は加速している。 だからこそ、データベースリファクタリングは重要であり、AIが台頭して来た時代でも変わらず必要なスキルである。 そこで今回は実際にサービスの成長と共にデータベースをリファクタリングする際の戦略と実践的な手法について解説する。 なお、AI時代でもデータベースの技術が重要であることは変わらない話はこちらを参照されたい。 データベース

ソフトウェアエンジニアとして仕事を通じて成長するコツを書く。 前回、やや抽象的な話を書いたので、今日は実際に自分がやってきて 効いた具体的 な方法を紹介する。 soudai.hatenablog.com 若手やこれから伸びたいエンジニアに届けば嬉しい。 目の前の「知らない」と向き合う 仕事をしていれば「知らない」は日々出てくる。ミーティングで出た用語、ログに出てくるオプション、ドキュメントに書かれている概念……。 それを放置せず、すぐ軽く調べて日報やメモに残す習慣をつけるだけで、1〜2ヶ月後の地力が大きく変わる。 特に自分の職責に直接関係しそうなキーワードは深掘りしたい。 Linuxコマンドを知らなければまず man を読む。試しに打つ。挙動を確かめる。 自分が普段使っているコマンドのオプションや、ツールの公式ドキュメントを「最初から最後まで」通して読んだことはあるだろうか。もし無いなら、

週末にやった感じ、GithubのCopilot Agentがかなり良かったので感想を書く。 前提 今回作ったツールで似たようなやつはいっぱいあって、llm ってやつが便利なんだけどPythonだし、重厚過ぎてちょっとしたことに入れるにはハードルが高いし、Serverには入れにくい。 ってことでGolangが良いなって思ってシンプルなやつを作った。 その際にGithubにCopilot AgentがGAになったので、こいつをvibe codingのメインで開発してみた。 ちなみに普段からRoo CodeやClaude Codeなんかも触っているのでvibe codingやAI Agentの活用には慣れている。 結論 業務で使うならCopilot Agentがかなり良い印象。 ClineやRoo Codeでやってたことは置き換わりそうな印象がある。 特にCopilotのAgentタイプだけでは

表題のとおり、PostgreSQL Contributorになりました。 グローバルでの貢献が認められたということで、素直に嬉しいです。 コントリビュータに名前が載ることになりました！ https://t.co/vzqCPmRQV0— そーだい@初代ALF (@soudai1025) 2025年1月28日 PostgreSQL: Contributor Profiles 認められた貢献 PostgreSQLのコミュニティでは、今までコードやドキュメントに対する直接的な貢献が評価されていました。 しかし今回はPostgreSQLのコミュニティに対する貢献が評価された結果となっています。 私は、コードやドキュメントに対する貢献はほとんどしていませんが、PostgreSQLのコミュニティに対しては以下のような行動をしてきました。 PostgreSQLユーザ会の運営*1 PostgreSQLの勉強

今年の振り返りをまとめる。 アウトプットについて 昨年がこちら。 ブログ 10本 登壇 37回 商業誌書いた PostgreSQLカンファレンスやった PostgreSQLアンカンファレンスをやった 今年の結果がこちら。 ブログ 15本 登壇 36回 続・商業誌書いた PostgreSQLカンファレンスやった PostgreSQLアンカンファレンスをやった 荻窪.なにかっていう読書会を始めた 登壇一覧 1月 PHPカンファレンス北海道 参加 登壇してないけどuzullaさんのbansen出た サブスレ忘年会 LTした OSC大阪登壇 他DBからPostgreSQLに移行する時に気をつけること Mackerel Drinkup パネルディスカッションした CARTAに3️⃣回くらい飲みに行ってた。 2月 広島長期滞在 YAPC::hirosima前夜祭登壇 キャッシュバスターズ YAPC::

はじめに Googleカレンダーのような時間枠を扱うシステムを設計する際、開始・終了時刻を管理するロジックは容易ではない。 しかし、PostgreSQLには 範囲型 があり、この機能を活用することで、開始時刻（begin_at）と終了時刻（end_at）を1つのカラムで扱えるようになる。 そこで本稿では、範囲型を用いた設計と、その利点を紹介する。 時間枠を扱う難しさ まず前提として時間枠の扱いがなぜ難しいかを紹介する。 ソフトウェアデザインでやっている連載、実戦データベースリファクタリングの 【12】厄介な時間枠に向き合う でも紹介したが、時間の範囲を比較するときが難しい。 範囲の重なりには以下の種類がある。 包含：範囲Aが範囲Bを完全に含む 重複：範囲Aと範囲Bに共通点がある 隣接：範囲Aと範囲Bが隣り合う 時間枠の扱いはSQLに限らず、プログラミングの題材として難易度が高い。 特に重複

例えば次のようなテーブルがあったとする。 -- PostgreSQL CREATE TABLE history ( id SERIAL PRIMARY KEY, user_id INTEGER NOT null, data TEXT, created_at TIMESTAMP NOT null DEFAULT CURRENT_TIMESTAMP ); -- MySQL CREATE TABLE history ( id INT AUTO_INCREMENT PRIMARY KEY, user_id INT NOT null, data TEXT, created_at DATETIME NOT null DEFAULT CURRENT_TIMESTAMP ); INSERT INTO history (user_id, data, created_at) VALUES (1, 'First

失敗から学べることがアジャイルの本質。 最近学んだのでホテルの朝食ビュッフェからアジャイル開発を伝授する。 ビックバンリリースを避ける バイキング形式であるあるなのだけど、初手で取りすぎて後から食べようと思ったデザートなどの余力が残せない。 また多めに取った唐揚げが思ったのと違って箸が進まない。 このようなことを防ぐため、バッチサイズは小さくする必要がある。つまり1品1~2口程度の量に抑えて気になるメニューをピックアップしていくと良い。 美味しいなと思ったら2～3周とイテレーションを回せばよいのだ。 小さく始める。これはアジャイルの基本であり、バイキング形式の朝食の基本。 優先順位をつける 食べたいものは何か、を最初に知るためにもまず広く、深くIssue（品）を見て回ることが重要。 ドメインを知り、解くべきIssueに優先順位をつけるのだ。 つまり実行よりも計画が先。 計画をした上で小さく

これは元々社内ブログの記事なんだけど、テキストコミュニケーションについていろんなところで話すことが多いのでここに残す。 結論 背景をしっかり整えてから本題を説明するようにしよう 省略しない お互いのスコープやフォーカスを最初に整理する 仮説と事実をちゃんと分けて明記して条件を整える お互いの知っていること、知りたいこと、わかってないことをちゃんと分けて整理する ボール交換が3往復以上したら同期的なコミュニケーションとして15分くらいとってすぐ会話する 要約 ローコンテキストなコミュニケーションをしよう！ 意外とみんな 相手の背景 を知らない レスポンスで貰いたいものを明確にしよう！ 参考資料 リモートワークにおけるファシリテーションの方法論[増補版]_COPILOT 部下や上司へのフィードバックに有効な「SBIモデル」とは？ - 株式会社インヴィニオ 説明 SBIモデル SBIモデルとは

X*1で反響があったので記事にする。 もし、自分がプログラマー人生をやり直すときに1冊だけ本を読ませることができるなら、やっぱこの本を自分に勧める。 今はWebでも読めるのでみんなにも読んでほしいな。https://t.co/6ueWEWUB3J pic.twitter.com/c468Szbm8S— そーだい@初代ALF (@soudai1025) 2024年11月12日 この本、素晴らしいことがたくさん書いてあるんだけど、その中でも大切にしていることを紹介する。 理想の役割の帽子を被る 「プログラマが知るべき97のこと」という本がある。 実はこれはWebで公開されていて、全部読むことができる。 ここには世界中のプログラマが人生において大事なことを紹介してくれる。 その中で一つ、自分がとても大事にしていることを紹介する。 xn--97-273ae6a4irb6e2hsoiozc2g4b8

来週で40歳にあるので30代の振り返りとしてこれを書く。 そんな30代を全力で走ってきた中で、これは30代でやってよかったな。 もっと早くやってもよかったな。というようなことを書く。 最初に行っとくと一般的にやったほうが良いということは基本的にやったほうがいい。 そういうのも含めて実際にやってみた経験も書く。 習慣を作れるようになる これは本当にやったほうがいい。 身につけるのであれば、早ければ早いほどほどいい。 もう少し具体的に話すと自分がやりたいことを実現していくためには習慣にできるとよい。 なんでも習慣にできると強くて、自分はどうやったら習慣になるんだろう？ってところを理解して上手くハックして習慣化していけると自分のやりたいことがどんどん実現できるようになる。 運動習慣 これも早ければ早いほど良いと思うが、朝か夜の散歩くらいからでもよいからやったほういい。 コロナ禍をきっかけに自分は

リンケージのCTOになって2年が経ったので振り返って3年目について書く。 前回 soudai.hatenablog.com やってきたこと 1年目は開発組織の立て直しと社内の新規事業の開発 2年目の前半は採用と後半は既存事業のリプレース 3年目は採用と組織の向き直りとビルドアップ 1年目 開発組織の立て直しと新規事業の開発の両方を同時にやるってことでなかなかハードだったが仲間に恵まれ無事リリースできた。 その時から開発しているFEMCLEは今もガンガン成長していて、今後はリンケージの柱となる事業の一つ。 ちゃんとローンチできて良かった。 femcle.linkage-inc.co.jp 仲間に恵まれた、という点でいえば採用がうまく行っているのがめちゃめちゃ大きい。 リンケージはPHP界隈で最強のチームだ、と言っても過言じゃないと思っている。 何よりも素晴らしいのは平均レベルの高さ、それ故に

PHPカンファレンス小田原(以下 ぺちこん小田原)に行ってきた。 このブログはその熱量の高さを思い出しながら、小田原駅前のスタバで書いてる。 カンファレンスで話をしたこと 懇親会キーノートで内省を勝ち取る、そのためには具象と抽象を往復して具象化の引き出しと抽象化の概念の理解を深めようという話をした。 そのために日報や週報からふりかえりし、能力を獲得していく。という話。 でもこれ、カンファレンスに参加すること自体が具象と抽象のスキルを強く獲得するチャンスだなって思ったので、感想と合わせて書く。 ちなみに文章中に出てくる経験学習モデルの話はスライドで説明している。 speakerdeck.com 経験という具象を疑似体験として聴く カンファレンスに行くと色んなセッションを聴くことができる。 もちろんぺちこん小田原でも最高だった。 至極のセッションの中で自分の中のベストトークを選ぶとしたらたつき

PHPカンファレンス関西懇親会で若者に「俺だってソフトウェアエンジニアの才能が無いかも…と悩んだことあるよ」って話をした。 そんな悩みを持っていたのは自分が25 ~ 26歳くらいの頃で自分はエンジニアとしてスタートが遅かった（異業種転職組）から、技術力の無さを痛感しながらも、それを才能の理由にしようとしていた。 続けるために必要なのは才能ではない 悩んでいるとき、飲み会で当時の同僚で先輩の @maepon さんに相談した*1ところ、次のことを言われた。 自分が「才能ないかも」と言ったあとに帰ってきた言葉は「もし、お前に才能が無かったとして、じゃあお前はどうするんの？そのifの中に実装があるの？何も無いんだったらそのifについて考える時間は無駄じゃん。必要なくない？」って感じ。 確かに才能が無かったとして、じゃあソフトウェアエンジニアを辞めて別の仕事したいってのがあるなら考えればいいけど、当

とにかくめちゃめちゃ色々やってきました。 以下、参考リンクです。 前夜祭 キャッシュバスターズの元ネタ 今日の登壇資料です。 #yapcjapan https://t.co/TelTiEzsO4— そーだい@初代ALF (@soudai1025) 2024年2月9日 ゲストトーク 明日の登壇資料です。 #yapcjapan https://t.co/Wxx9MBzIO9— そーだい@初代ALF (@soudai1025) 2024年2月9日 スライドの中で出てくるリンクはSpeakerDeckに行くと概要欄に書いてある。 LTの元ネタ 第一話 ゴッドテーブルの倒し方 #yapcjapan https://t.co/CJHYB28NxF— そーだい@初代ALF (@soudai1025) 2024年2月10日 第二話 UIの重力 #yapcjapan https://t.co/DcUuqgl

質問されることが多いのでPostgreSQL初学者が運用を行うためにしっておく知識に必要な内容をまとめる。 PostgreSQLの基本的なアーキテクチャ PostgreSQLのアーキテクチャを知らないと自分がやっている作業が危険な作業かどうかわからないし、パラメータの意味もわからない。 そこで以下のリンクを読むと良い。 富士通が後述の資料を参考にまとめたのだろうなと思われる記事。 非常によくまとまっているのでわかりやすい。 www.fujitsu.com もっと細かく知りたいならPostgreSQL Internalsがおすすめ。 富士通の資料と重複するところがあるがこっちが本家。 Githubで管理されているので誤字脱字などあったら気軽にPRを出してほしい。 www.postgresqlinternals.org PostgreSQL Internalsが少し古いので最新事情で知りたい場

PHPerKaigi 2024の登壇資料のほうが図面がわかりやすいので記載する。 ※2024/06/25 追記 speakerdeck.com どうもキャッシュバスターズ、 id:Soudai です。 Cache（以下、キャッシュ）は特定の場面に置いて劇的な効果を発揮し、様々な問題を解決する反面、新たなコンポートやミドルウェアが追加され、複雑性が上がり、運用のレベルが上がるため、扱いに注意する必要があります。 キャッシュを活用することで、パフォーマンスの改善や負荷軽減が行われ、コンピュータリソースの最適化によるサーバコストの削減や、レスポンスの改善によるユーザエクスペリエンスの改善がされます。 反面、その劇的な効果に毒され安易に多用すると、サービスが強くキャッシュに依存してしまい、非常に壊れやすくなり、運用が難しくなってしまいます。これをWeb界隈では「キャッシュは麻薬」と比喩されて、戒め

日本PostgreSQLユーザ会（以下、JPUG）から来ました @soudai1025 です。 この記事は PostgreSQL Advent Calendar 2023 シリーズ 1 の 5 日目の記事です。 www.postgresql.jp PostgreSQLユーザ会って？ JPUGはNPO法人です。 目的もちゃんと明記されています。 本会は日本におけるPostgreSQLの普及と発展を主な目的とします。具体的には以下の活動を行います。 1. PostgreSQLの研究開発および普及促進 2. PostgreSQLに関する情報の公開 3. 会員相互および外部との技術的・人間的交流 www.postgresql.jp NPO法人だと何が違うの？ １番大きなところはお金の管理を透明性を持って管理していることです。 後述する活動費を協賛会員様*1の協賛会費から捻出して管理しています。 ど