TOPICS 発行年月日 2025年06月 PRINT LENGTH 396 ISBN 978-4-8144-0114-7 原書 The Engineering Executive's Primer FORMAT Print エンジニアリングマネージャーまでの立場なら、同僚や上司など、社内に相談できる相手やアドバイスを求める相手はたくさんいます。しかし、エンジニアリング組織の責任者に就くと、社内に相談できる相手はほとんどいなくなります。エンジニアリング組織の責任者には、高い学習曲線が待ち受けています。意欲を持ってその立場に就いた多くの人が、それに心を折られ、1年半も経たないうちに挫折してしまいます。 本書では、エンジニアリング組織を統括する立場に就くと直面するさまざまな課題 ―エンジニアとCEOの双方に向けたエンジニアリングの測定、全体の人員計画、拡大する組織を横断する効果的なコミュニケー
優れたアイデアやデザインがあっても、それだけではソフトウェアプロジェクトを成功させることはできません。プロジェクトを円滑に進めるためには、ステークホルダーの理解と支持を得て、チームが協力できる環境を作ることが重要です。本書では、そのために不可欠で効果的なコミュニケーションの方法を解説します。具体的な例やパターンを通じて、適切にメッセージを伝えるためのドキュメントや図の作成方法を紹介します。 まず、ソフトウェアアーキテクチャの視覚表現を活用し、受け手にわかりやすくメッセージを伝える方法を解説します。次に、書面・口頭・非言語コミュニケーションの技法を用いて、相手に意図が正しく伝わるように工夫する方法を紹介します。また、ナレッジマネジメントを強化し、チームや組織の集合的な知識を最適化することで、生産性と革新性を向上させる手法についても解説します。さらに、アーキテクチャに関する重要な意思決定を的確
高速化したインメモリDB「Redis 8.0」正式リリース。AGPLv3対応によりオープンソースに復帰 インメモリデータベースとして知られるRedisの最新版「Redis 8.0」正式リリースが発表されました。 Redis 8.0では性能とスケーラビリティの向上、そしてAGPLv3ライセンスが追加されたことによるオープンソースへの復帰などが主なトピックとなります。 Redis 8 is GA today. It's fast, loaded with new features, comes with the tools in Redis Stack included, and it's open source. Read more here: https://t.co/YQktVjiiqm pic.twitter.com/EPOkOpaJRB — Redis (@Redisinc) May
Notionは全てのオブジェクトをブロック構造で管理してるので、AIリーダブルではないんですよね。その複雑さをUIで完璧に隠蔽しているのが美しかったしデファクトとなった所以だと思ってるけど、なんとAI時代と相性が悪かった。 https://t.co/zZvTnKtJvF — いけぴ / Takahiro Ikeuchi (@iktakahiro) April 26, 2025 なんとなく、あれ、最近のNotionってなんか使いにくい？と感じている人が増えてきているようなのだけど、じつはAI時代においてNotionの強みが打ち消されてしまってきているという話だと思っているので、その解説記事を書く。 最初に結論なぜNotionはAI 時代の勝者とならないのか、という問いに最初に答えると、次のようになる。 NotionのBlock構造がAIへの知識供給の妨げになっているから 成果物とドキュメント
マイクロソフトがVSCodeフォークエディタ上での自社拡張をブロックマイクロソフトは、CursorやWindsurfなどのフォークエディタで自社開発のVSCode拡張機能（C++やC#など）の使用を制限しました。 Has the VSCode C/C++ Extension been blocked? · Issue #2976 · getcursor/cursorWhile coding just now I got this msg: The C/C++ extension may be used only with Microsoft Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps, Team Foundation Server, and success…GitHubgetcursor著者は
AWS東京リージョンで約1時間続いた障害、原因は主電源と二次電源が遮断されたことが原因。AWSが明らかに 一昨日（2025年4月15日）、Amazon Web Services（AWS）の東京リージョン（AP-NORTHEAST-1リージョン）のアベイラビリティゾーン（apne1-az4）において日本時間午後4時40分頃から約1時間続いた障害は、主電源と二次電源が遮断されたことが原因だとAWSが明らかにしました。 4つのアベイラビリティゾーンの1つで障害発生 AWS東京リージョンは、「アベイラビリティゾーン」と呼ばれる独立した4つのデータセンターを備えています。 各アベイラビリティゾーンはそれぞれが独自の電源とインターネットへの接続を備えつつ、高速なネットワークで相互に接続されています。これにより、万が一あるアベイラビリティゾーンが自然災害や障害などで使用不能になったとしても、その影響を他
ソフトウェアの脆弱性に対して固有の番号を付与する「CVE」（Common Vulnerabilities and Exposures）プログラムを実行するための新たな非営利団体「CVE Foundation」の発足が発表されました。 CVEはソフトウェア脆弱性に番号を付与する ソフトウェアに関する脆弱性の情報は、以前はソフトウェアベンダやセキュリティベンダがそれぞれ独自に名称や識別子を付けていました。この状況はユーザーやシステム開発者にとってセキュリティ対策を行う際の情報整理を困難にしていました。 そこで発足したのが、ソフトウェアの脆弱性について固有の番号を付与する「CVE」（Common Vulnerabilities and Exposures）プログラムです。 ソフトウェアが社会基盤として重要な位置を占めるようになった現在、CVEはグローバルなIT業界におけるソフトウェア脆弱性情報の
Cybersecurity Newsは4月14日(現地時間)、「SSL Certificate Validity Reduced to 47 Days After Apple Proposal」において、SSL/TLS証明書の最大有効期間が47日に短縮されると報じた。 SSL/TLS証明書の最大有効期間は改訂を繰り返し徐々に短くなっている。現在の最大有効期間は398日だが、Appleが漏洩した場合の影響を軽減するためとして47日への短縮を提案(SC-081v3)し、関係機関およびコンシューマーの賛成多数で承認されたことがわかった。 SSL Certificate Validity Reduced to 47 Days After Apple Proposal 提案(SC-081v3)の概要と投票結果 Appleが提出した動議の内容や、投票の詳細は「Voting Period Begins:
お疲れさまです。とーちです。 Amazon Q DeveloperのIDEとCLIで言語サポートが拡張されたというアップデートがありました。サポートされた言語の中には日本語も含まれています！これは待望のアップデートではないでしょうか。 今回はさっそくAmazon Q Developerの日本語サポートを試してみたので、その結果をシェアしたいと思います。おさらいも兼ねて、インストールから実際の使用感まで詳しく見ていきましょう。 Amazon Q Developer IDEのインストール まずはIDEのほうから入れてみましょう。私はVSCodeを普段使っているのでVSCodeの手順で説明しますが、他にも以下のようなIDEに対応しています。 Visual Studio JetBrains IDE Eclipse VSCodeでのインストール手順は非常に簡単です。以下のURLを開き、「Instal
本ガイドラインは、世の中のシステム開発プロジェクトのために無償で提供致します。 ただし、掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとします。 また、掲載している情報は予告なく変更することがございますので、あらかじめご了承下さい。 はじめに Terraformはインフラを宣言的にコード管理するツールであるが、特に大規模なシステムでは扱うリソース数が増え、必然的にTerraformコードも複雑化する傾向にある。Terraformの可読性が低下すると、作業効率の低下だけではなく影響度が大きいミスを誘発する懸念がある。 また、Terraformは活発に機能開発が継続されており新しい機能／記述方法もリリース毎に追加されている。これは嬉しい反面、新規開発者が悩むポイントも増えたと言える。関連して、チームやプロジェクトごとに設計方針
Google Cloudは、日本時間で今日（2025年4月10日）未明に開幕したイベント「Google Cloud Next 2025」において、複数のAIエージェントを連携させたマルチエージェントシステムを実現する「Agent2Agentプロトコル」（A2A）を発表しました。 Agent2Agentプロトコルを用いることで、異なるベンダーやフレームワークによって構築されたエージェント同士がセキュリティを保ちつつコミュニケーションや情報交換を行って連携できるようになります。これにより開発者はさまざまなプラットフォームやアプリケーションを横断して稼働するマルチエージェントシステムが実現できるようになります。 MCPを補完するプロトコルによるAIエージェント同士の協力を実現 Agent2Agentプロトコルは、Anthropicが提唱したAIモデルとサービスの連携を行うためのプロトコルである「
Google Cloudは、日本時間で今日（2025年4月10日）未明に開幕した「Google Cloud Next 2025」において、AIエージェントの開発を容易にするフレームワーク「Agent Development Kit」をオープンソースとして公開することを発表しました。 使用するAIモデルとしてGoogleのGeminiだけでなく、Google Cloudが提供するモデルカタログであるVertex AIのModel Gardenからアクセス可能なAnthropic、Meta、Mistral AI、AI21 Labs、CAMB.AI、Qodo などが提供する200以上のモデルから選択可能（ただしGeminiとVertex AIに最適化されていると説明されています）。 Model Context Protocol（MCP）もサポートしており、データとエージェント間の安全な接続を実現
こんにちは、FIXERの村上滉樹です！ 皆さま、Terraform のバージョン管理では、どのツールを使っていますか？ 私は Terraform をベータ版から利用してきた経緯もあり、長らく tfenv を愛用していましたが、つい先日 tenv に移行しました！ tfenv → tenv に移行した理由2025年3月時点、tfenv の最終更新は2022年7月15日となっており、約3年間更新が止まっています。現状の機能で十分利用できるものの、この長期間の更新停止は懸念材料になりました。特に脆弱性対策やHashiCorpによる破壊的変更に対応できるかといった将来的なリスクを考慮し、代替ツールを検討するに至りました。 ▼ tfenv - GitHub https://github.com/tfutils/tfenv ▼ tenv - GitHub https://github.com/tofu
先日起きた tj-actions や reviewdog のセキュリティインシデントのレポートを読みました。 その内容を個人的な検証結果や感想を挟みつつかいつまんで書きたいと思います。 詳細は原文を読んでください。 なお、侵害された repository 及び tag は全て修正され、盗まれた Personal Access Token (PAT) も revoke されているはずです。 攻撃の流れ tj-actions/changed-files が侵害されるまでに複数の PAT の流出及びリポジトリの侵害が連鎖的に起こっています。 つまり tj-actions/changed-files が直接的にいきなり侵害されたというより、複数のリポジトリをいわば踏み台のようにして侵害したという感じでしょうか。 攻撃者は PAT が盗まれたりした GitHub Account とは別に複数の Gi
Amazon Web Services（AWS）は、すべてのリージョンとアベイラビリティゾーンの地理的な位置情報を明示したと発表しました。 これまでAWSのリージョンは、例えば「米国西部 (オレゴン) リージョン」「欧州 (アイルランド) リージョン」「アジアパシフィック (東京) リージョン」などと名称に地域や国、都市の名前などが含まれており、それぞれに「us-east-1」「eu-west-1」「ap-northeast-1」などのコードも割り当てられています。 またアベイラビリティゾーンについては、例えば東京リージョンのアベイラビリティーゾン1は「apne1-az1」、大阪リージョンのアベイラビリティゾーン1は「apne3-az1」などのコードが割り当てられています。 これらの名称やコードから、基本的にはリージョンとそれを構成するアベイラビリティゾーンがどこにあるのかは分かると思いま
今日3月31日は、マルウェアやハードウェアの故障、人為的なミスなどからのデータ保護の必要性を喚起する「World Backup Day」（世界バックアップデー）です。 世界バックアップデーは、いくつかのバックアップ製品やサービスを提供しているベンダが推進する日なのですが、普段は見過ごされがちなデータのバックアップについて再認識するのに、こうした日を活用するのは悪くない試みではないかと思います。 過去にPublickeyではバックアップに失敗したことで悲惨な結果となった事象についていくつか記事にしてきました。 GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット アトラシアン、JiraやConfluenceのサービス障害が1週間以上続く。原因は、保守スクリプトの実行ミスによるユーザーデータの消去。消去
Building load test infrastructure is tricky and poses many questions. How can we identify performance regressions in newly deployed builds, given the overhead of spinning up test clients? To gather the most representative results, should we load test at our peak hours or when there’s a lull? How do we incentivize engineers to invest time in load testing, especially when environment setup is time c
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く