--- name: Heritage colors: primary: "#1A1C1E" secondary: "#6C7278" tertiary: "#B8422E" neutral: "#F7F5F2" typography: h1: fontFamily: Public Sans fontSize: 3rem body-md: fontFamily: Public Sans fontSize: 1rem label-caps: fontFamily: Space Grotesk fontSize: 0.75rem rounded: sm: 4px md: 8px spacing: sm: 8px md: 16px --- ## Overview Architectural Minimalism meets Journalistic Gravitas. The UI evokes
コーディングエージェントの普及にともない、エージェントをリモートで動作させるための専用開発環境——リモートサンドボックスが注目されています。ここでいうサンドボックスとは、プロジェクトやエージェントごとに気軽に生成・破棄できるリモートVMのことで、exe.dev、Sprites、Docker Sandbox などのサービス・ツールが登場しています。 本記事ではこれらのリモートサンドボックスの用途を整理し、exe.dev・Sprites・Docker Sandboxの3つを比較します。 なぜ専用の開発環境が必要なのかコーディングエージェントをリモートで走らせる環境として、これまで一般的だった選択肢を列挙すると以下のようになります。 Mac miniやRaspberry Piを買って自宅サーバーを立てるVPS（Hetzner、さくらVPSなど）を契約するDevin、Claude Code on
amazonの出したIDE「kiro」がめちゃくちゃ未来だったのでClaude Codeユーザーの人はみんな一度試してみてほしい どうもこんにちは、昨日AmazonがVS CodeベースのIDEである「kiro」をリリースしました この分野ではcursorやWindsurf、アドオンですがClaude Codeなど様々な選択肢があります そんな中であえてAmazonが出してきたIDEのコンセプトは Vibe coding ……ではなく、 Viable Code だそうです 細かい説明は公式HPを見てもらうとして、他との違いは 「仕様書駆動開発」 を明確に打ち出している点です AIとのコーディングは難しい 特にClaude Codeを弄り倒している人なら常々感じてると思いますが、AIに適切な指示を与えて適切な作業をしてもらうのは非常に難しいです それを解決しようとみんな「sowで書いて」だっ
VS Code の GitHub Copilot が MCP クライアントとして動作する仕組みが追加されたので、Copilot から気軽に自社製品の質問ができたら、快適ではないだろうか？考えた。 そこで、ハルシネーションをできるだけ少なくし、かつ安価で自社製品ドキュメントへの質問ができる仕組みを作ってみることにした。ちなみに LLM 系の知識はほぼ無い。 できあがった Sora Document MCP (Local) GitHub Copilot + Sora Document MCP デモ まぁまぁの速度で、質の高い回答を箇条書きで返してくれるようにはなった。 仕組みについて自社製品のドキュメントは Sphinx というフレームワークをを利用しており、reStucturedText (以降 rst) というマニアックなもので書かれている。この rst を LangChain と Uns
社内勉強会向け 新作(2025/12/06 ) →https://speakerdeck.com/watany/its-only-the-end-of-special-time
この記事は以前 エンジニアと人生 というオンラインコミュニティで執筆し技術書典で頒布した本の中の、私の執筆した章をリライトしたものです。 無料公開の背景 本は有料で販売していたのでこの記事も有料記事にしようかとも思っていましたが、最近個人開発をネタにした特に中身のない記事を有料で買ってしまい後悔している友人を見かけて、そういうのにうんざりしていたので無料で公開することにしました。 個人開発云々いうなら中身のない情報商材じゃなくて自分のサービスで稼げよな！ ということで。でも投げ銭はありがたくいただくのでいいと思ったらバッジしてください！ 【追記】 上記に対して「有料記事がダメって事？」という反応を頂きました。書き方が悪く申し訳ありません。 有料でノウハウなどを販売する事は良いと思います！そしてそれでサービスの運営費を賄えるなら嬉しい事です。 なんならサービスに関する事ならこの記事の"データ
機能を書くならバックログにまず機能だけが書かれたロードマップから見ていきましょう。時系列に沿って、どんな機能を追加するのか並んでいます。 残念ながら、多くの場合、機能開発が遅延したり、差し込み案件が発生したりして、以下のようになってしまいます。 こうなると、もうこのロードマップは信頼できません。過去の実装がここまで遅延していると、次に取り掛かる機能がいつリリースされるのか分からず、どれの優先度がもっとも高いのかも判断するのが難しくなってしまいます。 こういった「機能」に近いものは、縦長のプロダクトバックログの形式で並べ、ユーザーストーリーに分解して見積もったものを上から順番に実施していくほうがスッキリします。 では、ロードマップがなぜ必要なのかプロダクトバックログはとても良いものですが、プロダクトの中期的・長期的な未来を構想するには少し見づらくなります。特に、会社の中で中期的・長期的な方針
個人的に「Webサービスの公開前チェックリスト」を作っていたのですが、けっこう育ってきたので公開します。このリストは、過去に自分がミスしたときや、情報収集する中で「明日は我が身…」と思ったときなどに個人的にメモしてきたものをまとめた内容になります。 セキュリティ 認証に関わるCookieの属性 HttpOnly属性が設定されていること XSSの緩和策（あくまでも緩和） SameSite属性がLaxもしくはStrictになっていること 主にCSRF対策のため。Laxの場合、GETリクエストで更新処理を行っているエンドポイントがないか合わせて確認 Secure属性が設定されていること HTTPS通信でのみCookieが送られるように Domain属性が適切に設定されていること サブドメインにもCookieが送られる設定の場合、他のサブドメインのサイトに脆弱性があるとそこからインシデントに繋がる
私たちソフトウェアエンジニアは、コード品質についてしばしば論ずるけれども、ではコード品質の良し悪しがどれほどビジネスに影響するのかと問われると、回答に窮する。只々、「コード品質が悪いと変更により多くの時間がかかります」だとか、「欠陥の修正に追われて開発時間が奪われます」だとか、個人の経験やエンジニア的一般論に頼った定性的な説明に終始するしかない。ソフトウェアを繰り返し変更する頻度が高いほど、コード品質が開発時間に影響を与えるのは確かにそのとおりだと思えるが、はたしてそれは、どれほどのインパクトなのだろうか。 2022年の研究論文 "Code Red: The Business Impact of Code Quality – A Quantitative Study of 39 Proprietary Production Codebases" では、コード品質がビジネスに与えるインパクト
There’s No Such Thing as Clean CodeのHacker Newsコメント経由でコードやシステム設計・最適化についての良いコメントを見つけた。どうやらHacker Newsで何度も引用されているらしいが日本語で言及された記事が見つからなかったので取り上げてみる。 コメントは2016年のSandi MetzのThe Wrong Abstractionに関するもので、発言者のcurun1rいわく「私は設計の優先順位をこの順序で学習することで、優れた開発者になれた」。*1 4つの基準と優先順位のガイドライン 状態 > 結合 > 複雑性 > コード量 私は状態 (state)、結合 (coupling)、複雑性 (complexity)、コード量 (code) の順に削減することでコードを最適化する。 コードがよりステートレスになるなら、結合を増やすこともいとわない 結
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
