はてなブックマーク

AIコーディングの進化に伴い、特に2026年に入ってから、プログラミングに対する自分の見方がかなり変わってきました。現時点で考えていることを、いったん記録として残しておきます。あとで振り返ったら面白いと思うので。 なお、この記事はAIによる「てにをは修正」「タイポ修正」などの校正は入っていますが、内容そのものはすべて自分で書いています。 初めてのプログラミングは面白くなかった Hello World を初めて書いたのは大学1年生のプログラミングの授業でした。SNSを見ていると「小学生から書いていました」という人も結構いますが、私はそういうタイプではありません。 大学の授業で最初に学んだ言語は Java。最初はマジでわからなかったです。そもそもプログラミング以前に、PATHを通すための環境変数の設定で詰まりました。MacとWindowsを両方使っていたこともあり、特にWindowsの設定画面

はじめに これまで、エンジニアリングマネジメントに関する本を何冊か翻訳してきました。どれも学びが多く、実践につながる内容です。 一方で、翻訳しながらずっと感じていたこともあります。 日本の現場にはそのまま当てはめにくい 理解はできるけれど、個人的にはあまり共感できず採用しづらい 要点は有用。だが、そこに至るまでがやや冗長で、時間がないマネージャーは読み切りにくい 私自身のN=1ではありますが、共感した部分や実践して有用だった部分を軸にして、もっと手早く読める形でまとめたいと思いました。自分自身がすべてできているわけではありませんが、そこは棚に上げつつ、こうするとうまくいく、あるいはうまくいったものを現時点でのスナップショットとして残しておきたいと思っています。 本書で作りたいもの 目指しているのは、エンジニアリングマネージャーになったばかりの人が、最初に短時間で読めて「だいたいこれぐらいや

はじめに BentoMLによるLLM Inference Handbookという、LLMの推論をまとめたハンドブックがある。本記事ではハンドブックや他の情報も参照しつつ、自分のメモ用としてLM推論に関する技術をまとめていく。 LLMの推論と内部理解の必要性 LLM推論とは、GPT-4、Llama 4、DeepSeek-V3などの学習済みLLMを使用して、ユーザーの入力から意味のある出力を生成することを指している。その推論には、たくさんの技術が抽象化・隠蔽されている。APIを利用している場合は、ほぼ意識せず活用できる。しかし、APIを何らかの理由で利用できない場合や、Open WeightなLLMを利用したい場合はこれらの技術を理解する必要がある。 実際、最適化されていない設定では、GPU時間で10倍のコストがかかることもある。ユーザー面であっても、最適化がされていなければ、応答速度が遅くな

はじめに Heroku社が提唱した「12-Factor App」は、クラウドネイティブなアプリケーション開発のベストプラクティスをまとめたものです。これをAIエージェント開発に応用して、dexhorthy氏がまとめたものが「12 Factor Agents」です。 この12 Factor Agentsを読んでみて、かなり学びがあったので、この記事では12 Factorの概要を簡単にまとめておきます。 なお、自分用にまとめて補足や所感を追加しているので、詳細はぜひ原文を参照してください。また、この記事は50%を人が書いて、50%をAIが補完しています。 12 Factor Agents の背景 「AIエージェントを作ろう！」 そう思って意気揚々とLangChainやCrewAIなどのフレームワークを使い始めた開発者は多いのではないでしょうか。 最初は順調に進みます。デモは動くし、簡単なタスク

ここ2-3年は別の場所に書いていたが、他の方のふりかえりポストを読んで「いいな」と思ったので、年越しする前に久々にこちらで記事を書いてみる。思いつくままに雑多に。 2024年 本業面は、0から組成してきたチームの活動が徐々にアウトプットとして可視化されてきた。来年はアウトカムにつながる年になりそうでとても楽しい。（こちらはあまり書けないのでさっくり） サイドワーク面では、書籍を2冊出せたのが非常に大きかったと思う。エンジニアリングマネジメントの考え方や手法は本当に色々あるので、参考材料が日本語で読めるようになるだけでも、結構大きなことなのではと考えている。今後も続けていきたい活動の一つ。（なお、生成AIの力によって、母国語で海外の情報を取り入れるケースが確実に増えてくる。ただ、人によって手が入った日本語の情報は現時点ではまだ価値が高いので、まだ数年は今の状態が続くのでは、と思う。） サイド

2023/3/11(土) に「Docs for Developers: An Engineer’s Field Guide to Technical Writing」の翻訳書籍である「ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング」が日本能率協会マネジメントセンター(JMAM)社より刊行されます。 今回、JMAM社に許可をいただいて書籍のあとがきを公開できることになりました！本記事では以下に、あとがきを先行掲載します。 あとがき 「ドキュメントを書いておけば良かった」 「ドキュメントは書いてあったけど、2年前に更新が止まっている」 開発の中でこう思ったことは、何らかの形でプロダクトやシステム開発に携われている方であれば、少なくとも一度はあるのではないでしょうか。 たとえば、「設計上の意思決定の経緯が残っておらず、加えたい変更の影響範囲が分からなくて困

2023/1/11-13 に渡って行われたRegional Scrum Gathering℠ Tokyo 2023 （以下、RSGT2023）のクロージングキーノートに登壇してきたので、そこに至るまでのbehind the scenes的な話や、登壇して思ったこと、などを書いておきたいと思います。 当日の登壇資料はこちらです。動画は後日公開される予定とのことです。なお、資料の内容については、本記事内で言及しません。むしろ裏側で起きていたこと、考えていたことを書いておこうかと思います。 さて、では本ポストの本編です。 登壇半年前（夏頃） 登壇資料冒頭でも言及していますが、miholovesqさんから休日の昼間にDMがやってくるところから、登壇のきっかけは始まります。 いただいた当時は、めちゃくちゃ大変そうという気持ちと、受けたみたいという気持ちの両方がありました。個人の人生経験上、ちょっとチ

2022年昨今のEngineering Management(EM)界隈を見ていて、1つトレンドもしくは兆しがあるなぁ、と思っていることがあります。端的に言ってしまえば、EMを専門職種として切り出して、人（や組織）のマネジメントに専念させるパターンが出てきている、ということです。 もちろん、以前からこのような形態をとられている企業もあると思います。しかし、おそらくは専門性を高めている社員がキャリアラダーの1つとして、プレイングマネージャー的にマネジメントに携わるケースが多いのではないでしょうか。 プレイングマネージャーとして人のマネジメントに関わることの問題点は、2点あると考えています。ひとつは、プレイングしている内容（開発者であれば技術的なこと、デザイナーであればデザイン的なこと）と、人（と組織）に向き合う内容とのいずれにも注力できずに、どちらも中途半端な状態になるということです。結果と

はじめに 去年によく聴いてたPodcastの記事を書いており、本記事はその2021年度版。 去年までは、基本 Tech系ポッドキャストだったけど、今年は違うジャンルも聴いてた。以下では、少なくとも5-6エピソードは聴いたなってのものについて1-2行の感想をつつけて書いていく。(2-3エピソードだけ聴いたってのもあるけど、書き始めると多くなるので省略) ポッドキャスト列挙、コメントつけて 以降は順番適当に書いていく。 agileradio アジャイル開発に関するトピックを中心に語られるポッドキャスト。Scrurm Fest Sapporo などアジャイル全般のイベントを扱っている。 ココナッツテック 最近の技術記事をトピックとして、30分程度で雑談的に話しているポッドキャスト。全然拾えてない技術記事ネタもキャッチアップできるのがありがたい。 セキュリティのアレ 昨今のセキュリティ界隈のトピッ

はじめに 話題となっていた書籍である Engineers in VOYAGE を読み終えたので、その簡単な書評を書く。 書評 結論から述べると、本書籍で多く触れられるWeb技術に関わる技術者だけでなく、普段は上流工程から技術やプロジェクトマネジメントに携わっているエンタープライズな技術者にも本書籍を読んで欲しいとおもった。なぜかと言うと、通常であれば隠蔽されていて見えないエンジニアの考えや努力が、生々しく記載されており、エンタープライズ領域でも有用である知見が多く記載されているからだ。 レガシーシステムとの戦い たとえば、Voyage Marketing社におけるECナビでの、経済産業省の述べる2025年の崖への戦いの知見が1つの例だ。1200を超えるテーブルを持つオンプレシステムに対して、いかに泥臭く改善を進めたか、書籍で説明されている。具体的な取り組みとしては、オンプレからクラウドへの

はじめに コードコンプリートなどで有名な、スティーブ・マコネル氏のMore Effective Agile の和訳版を読んだので、その簡単な書評とメモを書く。 書評 非常に現実目線のアジャイル書籍。アジャイルの書籍は、アジャイルを当然のことながら推している人によって書かれている書籍が多いが、この書籍は完全に傾倒するのではなく、実際にソフトウェア開発に応用してみた経験から書かれている。そのため、読んでいると、「あぁ、たしかにこれあったな」「ここは悩むところだった」という点についてうなずきながら読める。 悩むところの一例をあげると、完了の定義(Definition of Done)ってどうすればいいんだろうってのがある。本書では、次のような具体例を載せているので、「このぐらいの粒度で決めていくのか」と現実に応用する場合に非常に参考になる。 - コードレビューを通過している - 静的コード解析を

はじめに 自分が fukabori.fm を配信しているのもあるけど、インプットソースとしてポッドキャストをよく聴いている。この記事では、聴いてるポッドキャストをサクサク紹介していきたいと思う。 基本はTech系ポッドキャスト。たまに、違ったのをちょいちょいぐらい。 実際に以下で書いてないポッドキャストもあるけど、少なくとも5エピソードは聴いたかな、ってものを紹介していく。 ポッドキャスト列挙、コメントつけて 以降は A-Z 順で、自分のPodcastクライアント(Podcast Addict)でSubscribeしているものを順番に。 ajito.fm suzukenさんが主宰しているポッドキャスト。VOYAGE CTOの makoga さんがよく登場する。技術的に濃いネタから、組織的なネタまで幅広い。 すごく印象に残っているepは ajitofm 29: Chiki Chiki Mon

はじめに コロナウィルス(COVID-19)でリモートワークの頻度が増加している人も多いと思う。そうなると、必然的にリモート会議の数も増える。ここで課題として上がってくるのが、リモート会議に対する姿勢、また練度だ。 リモートワークを多用して、リモート会議に慣れているチームもあれば、もともとオフサイト出社がメインでリモート会議に慣れていないチームもある。前者の慣れているチームであれば、スムースに適応できると思うが、後者の不慣れなメンバが多い部署・チームは、もっと効果的なやり方に気づいていない可能性もあると思う。(この場合、前者のメンバはストレスを溜めることにもつながる…。たとえば、一方的に音質の悪いリモート会議を想像して欲しい) そこで、この記事では自身の5-6年のリモート会議経験や、見聞きした情報から良いと思っているプラクティスを紹介していく。それによって、少しでもより効果的なリモート会議

WebRTCも誕生から5年以上経っており、Web上の記事も多く増えてきた。WebRTCには、大きくMedia ChannelとData Channelがあるが、後者のData Channelの日本語記事は非常に少ない。 日本語の記事の中では、@udonchan氏の記事が最も正確に書かれているが、2014年から時間が経ったこともあり、やや変更が加わっている部分(e.g. SCTPのPPIDは57まで定義されている点など)もある。その他の日本語記事は、やや記述が不正確なところもあるので、あまりオススメしない。 本記事では、WebRTC Data Channelについて知っておいた方が良いこと、および一次情報への参照をまとめておこうと思う。(本記事自体は、主観がそれなりに含まれるので、参考程度にしつつあとは一次情報や実機で確かめてもらえれば) W3C APIについて 仕様は以下の2つが役立つ。

本記事は、WebRTCをエンタープライズで利用したいと考えている人（例えば情シスの人）向けに、WebRTCの技術的な内容をいくつかまとめた記事。 エンタープライズ向けWebRTCの外堀が埋まってきている 社内向けなどの施策で、たとえば先進的な技術をつかったコスト削減を狙う担当者はそれなりにいると思う。WebRTCは、そこで目をつけられる技術の1つだ。（典型的なケースでは、既存のWebビデオ会議などのリプレース候補など） 新技術を導入するとなると、当然のことながら観点の1つとしてセキュリティに目がいく。すなわち、社内で「WebRTCは安全に使えるのだろうか？」と考えるということだ。たとえば、「音声・映像のトラフィックが暗号化されていたとしても、インターネットに出るのは怖い」、と偉い人が言うかもしれない。これに対する一定の回答はあるので、本記事前半で紹介する。 また、WebRTC登場初期時は、

はじめに WebRTCの通信形態は大きく分けて、暗号化を解く/メディアを解釈するサーバを介するもの と 介さないもの、の2種類がある。 暗号化を解く or メディアを解釈する サーバを介さないもの P2P TURN経由 暗号化を解く or メディアを解釈する サーバを介するもの MCU経由★ SFU経由★ (VoIP-WebRTC Gatewayなどもあるが、ここでは取り上げない) どれが必要になるかは、WebRTCを利用するアプリケーションのユースケースに依存するので、一概に何が1番良いというものはない。 本記事では、上記のうち、★をつけているメディアサーバ(SFU/MCU)の現状(2016年)について記載する。WebRTCを使う上で、特にMCUやSFUに興味がある方には参考になれば幸いだ。 もし、記載で誤っている点などがあれば @iwashi86 までメンション/DMをいただきたい。

はじめに Linuxの各種ディストリビューションには、UpstartやSystemdがデフォルトでインストールされていることが多い。 たとえば、Ubuntuでは14系ではUpstartが標準装備されているし、15系以降ではSystemdが標準装備になる。 UpstartもSystemdのどちらも、管理するプロセスが死んだときに、死んだプロセスを再起動する仕組みを備えている。 たとえば、Upstartであればrespawnというキーワードを仕込んでおけば、再起動する動作をしてくれる。 具体的な設定なこんな感じ： description "サービスの説明とか" author "名前と連絡先" start on runlevel [2345] stop on runlevel [016] chdir /hogehoge/ exec foorbar respawn 本題：なぜmonitが必要なのか

WebRTCで用いられる要素技術の一つとして、TrickleICEがある。本ポストではTrickleICEについてわかりやすく解説する。 イメージを掴んでもらえるよう平易説明するので、正確さを重視される場合は、RFCを参照いただきたい。 本記事のサマリ：TrickleICEとは？ TrickleICEを一言で表すと、 「ICEの候補をインクリメンタルに探して、 見つかったICE候補を接続先ピアと交換して、 すぐに接続を試行する仕組み」 である。 以下に、背景を含め詳細を解説する。 最低限のおさらい（STUN/TURN) WebRTCで通信をするブラウザは、NAT配下に隠れていることが多い。 そのため、ブラウザ間で直接通信するためには、プライベートアドレスではなく、 グローバルアドレスの情報を利用する必要があり、何らかの仕組みを活用する必要がある。 その仕組みとして用意されているのが、STU

Ubuntuではiptablesを永続保持（再起動しても動くように）するにはちょっと工夫が必要。 色々な方法があるみたいだが、サクッとできる方法として iptables-persistentを使う方法がある。 本記事ではそれの簡単な紹介。 進め方 全体の流れとしては、 iptablesにルール追加 iptables-persistentのインストール となる。 1. iptablesにルール追加 まず先にiptablesに必要なルールを入れておく。 簡単な例だと、特定のIPからだけSSHを許可したければ

記事一覧 Jul 27, 2025 スクラムフェス大阪2025に登壇してきた Jul 20, 2025 LLM推論に関する技術メモ Jul 13, 2025 「うーん、よくわからない。」という回答は情報価値が高い Jul 6, 2025 12 Factor Agents まとめ Dec 31, 2024 2024 ふりかえり Apr 9, 2023 オンライン版のTOEIC(IP)で990点を取れたので準備したことや受けてわかったことのメモ Mar 9, 2023 あとがき公開「エンジニアのためのドキュメントライティング」 Jan 21, 2023 RSGT 2023のクロージングキーノートで登壇してきた Nov 22, 2022 色々試して行き着いた読書方法 Oct 24, 2022 EMのトレンド？もしくはその兆し (2022年) Dec 31, 2021 2021 ふりかえり Dec

この記事は::..: glen.nu :.: ramblings :.: on code review :.::の意訳記事です。@9len氏の許可を受けて投稿しています。誤り・修正などがありましたら、@iwashi86までご連絡いただけますと幸いです。 This article originally appeared in English at :..:: GLEN D SANFORD :.: RAMBLINGS :.: ON CODE REVIEW ::..: and has been translated with @9len’s permission for posting to this blog in Japanese. この記事は2014年3月に書いている。Twitterでユーザ検索チームを私が率いていたころの話だ。この記事は、コードレビューに関するセオリー・アプローチを体系化

はじめに WebRTCは様々なブラウザでサポートが進んでいる。これらの対応状況について世の中に多くの情報があるが、アップデートされていない情報も多いため、最新の情報を追うのはなかなか骨が折れる。そこで、本記事では2016年3末時点での対応状況をまとめていく。 本記事を読むと得られるもの・得られないもの 得られるもの 2016年3末時点での各ブラウザにおけるWebRTCの対応状況 得られないもの ソースコードレベルの実装詳細 対象読者 WebRTCに関わっているエンジニア、WebRTCの動向に興味がある人 WebRTCを多少なりとも知っている人 では本題に進む。 Google Chrome WebRTCの提唱をはじめたGoogleだけあって、WebRTCの黎明期から様々な機能を提供している。現在も活発に開発が進んでおり、Chrome/FirefoxにおけるWebRTCのマイルストーンの記事に

はじめに 以前の記事にて、SlackにおけるWebRTCの利用についての解析結果を掲載した。 前回の記事は、Slackが1:1の通話において、どのようにしてWebRTCを利用しているかという点にフォーカスしており、 SlackはTURNを強制的に利用し、Janus経由でエンドツーエンドの音声接続を提供していることを明らかにした。 本記事の概要 本記事では、引き続きSlackの音声通話機能についての解析を述べる。 本記事の主なスコープは、Slack音声通話機能の多人数会議(マルチパーティコール)の解析である。 本記事を全て読むと、Slackにおける多人数会議のアーキテクチャ、およびWebRTCの利用技術を理解できる。 対象読者 なお、前回同様にWebRTCの基礎知識を持った人を想定して記事を書くので、基礎的な知識の解説は実施しない。必要な場合は、前回同様にHTML5 Expert.jpの解説