パフォーマンスチューニングのために普段からできること/Performance Tuning: Daily Practices
2025年はソフトウェアの作り方が大きく変わった年として記憶されるだろう。自分にとっても特に印象に残る一年だった。仕事で2025年のアウトプットをまとめる機会があったので、記録として残しておくため、せっかくなので久しぶりにブログエントリを書くことにした。年内に仕上げたかったが、いろいろあって年始になってしまった。ブログを書くブランクが長いとこうなる。 なお、当たり前ではあるが、このブログエントリは 100% 私が書いており、記述にも構成にも AI は関与していない。 1月 年末年始は義実家で過ごして考え事をすることが多い。そして、2024年末の考え事はやや暗いムードだったように思う。当時はコーディングエージェントがメキメキと力を伸ばし、人間がプログラミングする領域が削り取られ始めていた。人間がコードを書くことはもうなくなるのだろうか、俺はコーディングが大好きなんだけどな……とモヤモヤしなが
はじめに このオンラインブックは執筆中です。完成版ではありません。フィードバックフォーム この本には一冊の本に盛り込むにはやや欲張りな内容を詰め込みました。本書では、C言語で書かれたソースコードをアセンブリ言語に変換するプログラム、つまりCコンパイラを作成します。コンパイラそのものもCを使って開発します。当面の目標はセルフホスト、すなわち自作コンパイラでそれ自身のソースコードをコンパイルできるようにすることです。 この本では、コンパイラの説明の難易度が急に上がりすぎないように、様々なトピックを本書全体を通じて次第に掘り下げていくという形で説明することにしました。その理由は次のとおりです。 コンパイラは、構文解析、中間パス、コード生成といった複数のステージに概念的に分割することができます。よくある教科書的アプローチでは、それぞれのトピックについて章を立てて解説を行うことになりますが、そのよう
はじめに前職で技術顧問として そーだいさん にJOINしていただいていた際、私はデータベース設計から仕事の進め方相談まで、本当にお世話になりました。 そーだいさんは「ガタイも(物理的に)声も大きくて、ちょっと圧倒されるな……!」というものでしたが、実際にお話ししてみると、その中身は驚くほど優しく、そして本当にロジカルで誠実な方でした。 その圧倒的な「言語化能力」で、技術的な課題はもちろん、エンジニアとしての振る舞いや問題解決の考え方を、誰にでもわかる言葉で解きほぐしてくれます。 今回は、私が定期的に読み返し、1on1などの場でも「まずこれを読んで!」と周囲に布教している、そーだいさんの発信をいくつか紹介したいと思います。 1. 仕事を進めるうえでのマインドセット1-1. Howだけ考えると複雑さを導入して仕事が増える 「偽の進捗」の連鎖によるリソース枯渇の防止 手段に没頭して手順書の保守や
RDBの信頼性とNoSQLのスケーラビリティを兼ね備えたNewSQL。何が新しく、しくみはどうなっているのか。各製品の特長を深堀りしながら徹底解説!ユースケースを通じて、NewSQLの使い所がわかる! 目次 第1章 序 論 ――なぜいまNewSQLが注目されているのか 1.1 RDB vs NoSQLの対立と「解決策」としてのNewSQLの登場 1.2 NewSQLがいま注目されている理由 ――RDBとNoSQLのいいとこどり 1.3 NewSQLの登場 1.3.1 障害とは何か 1.3.2 中央集権的コーディネータの不在 column 結果整合性 1.4 NewSQLの課題 1.5 代表的なNewSQL製品 1.5.1 Google Cloud Spanner 1.5.2 TiDB 1.5.3 YugabyteDB 1.5.4 CockroachDB 1.5.5 Amazon Auror
はじめに 私は現在AWS上のWEBシステムのインフラ維持管理を担当しています システムのタイムアウト設計は地味な領域ではありますが、設計に不備があるとシステム障害に直結する、非常に重要なポイントの一つだと考えています 一方で、直近の業務を通じてこの領域は専門外の方には理解しづらいものであるものの、アプリケーション担当者の方々にも内容を把握していただくことが不可欠だと改めて実感しました。そこで、この機会に自身の知見を整理する意味も込めて、本記事へまとめることにしました 該当条件(主に本投稿を確認頂きたい方) タイムアウト設計未経験で、設計のポイントを確認したい方 タイムアウト設計ポイントは把握しているが、なぜそのような設定にする必要があるのかを確認したい方
生成AIの登場により、ソフトウェア開発のあり方は劇的に変化しました。次々と新しいツールが登場し、これまでの常識が覆される中で、急速に進化するAIにどう対応していくか―本書は現場の開発者に向けて書かれた実践的なガイドです。著者は多様なAIツールを徹底的に検証し、コード生成、UI/UXデザイン、コードレビュー、テスト、ドキュメント作成など、開発工程全体におけるAI活用の可能性と限界を明らかにしています。また、将来のツール評価に役立つ指針も提示し、進化し続けるAI時代を生き抜くエンジニア、デザイナー、プロダクトマネージャーにとって必携の一冊となっています。 訳者まえがき はじめに 1章 コード生成とオートコンプリート 1.1 コード生成ツールの種類 1.2 ユースケース 1.3 ブラウザベースのツール 1.3.1 ChatGPT 1.3.2 Google Gemini 1.4 IDEベースのツー
Rails Tokyo Meetup 02 登壇資料。
この記事は CyberAgent Developers Advent Calendar 2025 の17日目の記事です。 こんにちは!ハノイ開発センターに所属しているminhquangです。普段はAI事業本部の協業リテールメディアカンパニーで、小売企業様向けアプリ開発のバックエンド開発を担当しています。 CyberAgentではエンジニア一人あたり200ドルの開発AIエージェント費用サポートが全社展開されました。私のチームでも半年ほど前からCursorやClaude CodeやCodexなどのAIツールを導入しています。導入後、チーム全体のコミット数が導入前の約2倍になり、AIエージェントによる生産性向上の効果が数字としても表れています。 一方で、コード量が倍増したことにより、レビュー負荷も跳ね上がりました。それに対し、エンジニアのレビューに割く工数を2倍にするような対応はしづらいので、こ
Control Plane部の小森 (@littleforest12)です。 こちらはキャディ株式会社のアドベントカレンダーの16日目の記事です。 最近、社内でこれまでの中では比較的大規模な開発プロジェクトのリードアーキテクトを拝命しまして、奔走しています。 プロジェクトはようやく立ち上がってきたところですが、アーキテクトとしての考えをメンバー向けに発信しようと書きはじめたことを、せっかくなのでTech Blogにしたためたいと思います。 背景 私たちは「製造業AIデータプラットフォーム CADDi」としてプロダクトを展開しており、プラットフォームの一部としてCADDi DrawerやCADDi Quoteといったアプリケーションを提供しています。 もちろん、これらは開発から運用まですべてが内製です。 通常は、各アプリケーションやプラットフォーム横断で、おおむね4〜8名程度のチームに分かれ
ここ数年、「シフトレフト」という言葉を耳にする機会が増えました。 テスト、QA、セキュリティ、運用―― 何かにつけて「シフトレフトしよう」という言葉が使われます。 一方で、正直なところずっと違和感もありました。 話を聞いていると、人によって指しているものが違います。 テストを早く書くことを指す人もいれば、 QAを設計段階から巻き込むことだと言う人もいる。 レビュー工程を前倒しすることだ、という説明を聞いたこともあります。 どれも間違ってはいないと思うのですが、どれもしっくりこなかったです。 なぜなら自分自身は、 ウォーターフォールでもアジャイルでも、 シフトレフトという言葉を意識せずに、同じようなことをずっとやってきたからだと気づきました。 しかも、そのやり方で 「大きく炎上した」「後工程で破綻した」 という経験はほとんどありませんでした。 最近になって気づいたのは、 自分が自然にやってい
この記事は一休.com Advent Calendar 2025の13日目の記事です。 宿泊開発チームでエンジニアをしている @kosuke1012 です。 本記事では、予約処理の中で必要な在庫引当、カード決済などの各処理について、予約処理全体として成功/失敗の結果整合を実現するための実装パターンを紹介します。 背景 現在、一休.com の宿泊予約のシステムでは、予約部分のリニューアルを進めています。 予約リニューアルプロジェクトの全体感もどこかで是非説明したいのですが、アドベントカレンダーの期日も迫ってきているため、 リニューアルの中で取り組んだ、予約処理の結果整合を実現するための実装について書いてみたいと思います。 用語 この記事内での用語の定義をしておきます。 この記事の中で「トランザクション」と言った際には、予約処理全体を指すことにしたいと思います。 また、「カード決済」「在庫引当
はじめまして。流しのアーキテクトを生業としている、株式会社ウルフチーフの川島(@kawasima)です。私はSIerで20年、主にアーキテクトとしてさまざまなプロジェクトに関わってきました。現在は独立し、データモデリングを中心に、多くの企業の設計や技術者育成を支援しています。 数多くの現場を渡り歩く中で、プロジェクトを停滞させる「ある共通項」が見えてきました。それが、技術的負債に伴って静かに蓄積する「クラフト」です。本稿ではこの「クラフト」の正体を突き止め、パターンごとの対処法を具体的に紐解いていきます。 メンテナンスコストを増加させる「クラフト」 クラフトは計画的なリファクタリングによってのみ解消できる なぜクラフトが溜まる? 欠けているのは「整えるフェーズ」 【ケーススタディ】 技術的負債に伴って発生するクラフトの4分類と対処法 【1】混在:異なる概念が同じ場所に置かれる 【2】分散:
はじめに 「今年読んで良かった本」という記事を書こうとしている自分に、ふと気づく。また書くのか。毎年書いている。誰に頼まれたわけでもないのに、12月になると決まってこの作業を始めてしまう。習慣なのか、義務感なのか、それとも単なる自己顕示欲なのか。たぶん、全部だ。 100冊近く読んだ、と書こうとして手が止まる。この数字を出した瞬間、どこかで「すごいですね」と言われたい自分がいる。同時に、「いや、冊数なんて意味ないですから」と予防線を張りたがっている自分もいる。めんどくさい人間だ。でも正直に言えば、100冊読んだことより、1冊を血肉にできた人のほうがよほど偉いと本気で思っている。思っているのに、冊数を書いてしまう。そういう矛盾を抱えたまま、この文章を書いている。 AIに聞けば答えは返ってくる。2025年はそういう年だった。コードを書いてもらい、設計を相談し、ドキュメントを要約させた。便利だ。本
最近、1on1で同じ話を何度かしたので、ここに整理して残しておく。 生成AI・LLMが当たり前になりつつある今、「これから自分のキャリアをどう築けばいいかわからない」という相談を受けることが増えた。 新卒から自分と同世代*1まで、悩みの種類は違っても不安の根っこは似ている。 そのときにセットで話すことが多いのが、能力の伸ばし方とキャリアの積み上げ方だ。 能力の成長ステップは、こちらの資料に詳しくまとめている。 speakerdeck.com この記事では、主にキャリアをどう築くか、に絞って書く。 キャリアの築き方:土台を広げ、実績を積む キャリアは、積み木を積み上げていくようなものだ。 細く高く積むと、ちょっとした揺れで簡単に崩れる。たとえば、一時的な特需に合わせて実績の高さだけを優先して積むと、環境が変わった瞬間に吹き飛ぶ。 だからこそ重要なのは、土台(基礎)を広く、強くすることだ。 土
AIは開発者の役割を刷新し、ソフトウェア開発の方法を大きく変えつつあります。プログラマーはコードを書く作業から、AIと協働するワークフローへと移行しています。自然言語で指示してAIにコードを生成させる「バイブコーディング」は、革新的である一方、リスクもあります。本書は、GitHub CopilotやOpenAI CodexといったAIツールを活用し、目標設定、コード検証、統合の戦略や注意点を解説し、急速に進化する環境で開発者が生き残るための知見を共有します。 日本の読者のみなさんへ はじめに Ⅰ部 基礎 1章 序論:バイブコーディングとは何か? 1.1 AIコーディングの範囲:バイブコーディングからAI支援エンジニアリングまで 1.1.1 バイブコーディングのアプローチ:会話によるコーディング 1.1.2 AI支援エンジニアリングのアプローチ:AIパートナーとの構造 1.1.3 異なる考え
npm史上最悪のサプライチェーン攻撃「Shai-Hulud 2.0」。正規パッケージのメンテナー認証情報を盗み、悪意あるバージョンをnpmに公開するという手口で、11月21日から急速に拡散しました。 この記事では2つのことを解説します: 自分が被害にあっていないか確認する方法 今後の被害を防ぐ多層防御アプローチ *この記事と同じ内容を動画でも解説していますので、動画の方が好きな方は下記からどうぞ 被害確認 - あなたは大丈夫か? Shai-Hulud 2.0は11月21日から急速に拡散しました。この日以降にnpm installを実行した人は、感染の可能性があります。 チェック1: GitHubアカウントの確認(ブラウザで完結) 確認ポイント1: 見覚えのないリポジトリ まずGitHubで自分のリポジトリ一覧を確認。 Shai-Huludは感染したアカウントにランダムな名前のパブリックリポ
「Ruby on Railsのテーブル設計とトランザクション処理 LT Night」で話した内容のフォローアップです。主に懇親会で id:kamipo さんから現地でもらった質問を受けての補足となります。 speakerdeck.com 図中のオレンジ枠と緑枠のトランザクションを分けているのはなぜ? ログレコードが保存できてイベントレコードが保存できないことなんてなくない? 説明がスッポリ抜けていたのですが、ASPからwebhookを受けて諸々の処理をする部分は非同期処理になっているのでそもそもライフサイクルごと分かれていたのでした。つまり、webhookを受けたタイミングでログレコードを記録してからキューイングし、それを非同期的にイベント処理をするので必然的にトランザクションが分かれる。 それはそうとして、イベントを扱う処理中に不慮のクラッシュが発生した時にロギングが巻き込まれると後の調
転職・求人情報サイトのtype エンジニアtype ITニュース t-wadaが説く、今あえて“自分の手”でコードを書く理由「バイブコーディングは、エンジニアのためのものではない」 2025.11.28 ITニュース 和田卓人プログラミングAI 「バイブコーディング(Vibe Coding)」の熱狂は、プロフェッショナルなエンジニアにとって何を意味するのだろうか。その答えの一つが、2025年10月30日に開催された「AI駆動開発カンファレンス 2025」にて明かされた。 答えの主は、テスト駆動開発(TDD)の第一人者・t-wadaこと和田卓人さん。「AI時代のソフトウェア開発を考える」と題した講演の中で、「バイブコーディングはエンジニアのためのものではない」と指摘した。 果たして、その言葉の真意とは。和田さんの考えを聞いていくと、AI全盛の時代にエンジニアが果たすべき役割と、自らの手を動か
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く