関連リソース Agent Design Pattern Catalogue: A Collection of Architectural Patterns for Foundation Model based Agents 【論文紹介】LLMベースのAIエージェントのデザインパターン18選 基盤モデルを用いたAIエージェントの設計パターン The Landscape of Emerging AI Agent Architectures for Reasoning, Planning, and Tool Calling: A Survey The Landscape of Emerging AI Agent Architectures for Reasoning, Planning, and Tool Calling: A Survey は、「AIエージェントのアーキテクチャ」について、シン
簡易DBをフルスクラッチで実装して得た学び
☀️ はじめに 最近 「Database Design and Implementation」 という技術書を読みました。 本書は、一般的なDBMSについての設計パターンを概説しつつ、その一つのパターンをJavaで実装するというものです。 しかし、ただJavaのサンプルをそのまま動かすのでは味気ないので、今回は Go で書き直しています。 実装する機能はごくシンプルに絞っていますが、実際に自作することで「DBMSが内部で何をしているのか」が肌感覚でわかり、非常に勉強になりました。（まだ一部実装しきれていない部分はありますが...） 📝 実装した内容 この書籍では、DBMSの設計における複数の実装パターンを解説したうえで、そのうちの1つを実際に作るという構成になっています。おかげで、シンプルなDB機能を一通り体験しながら理解を深めることができました。今回実装した機能の一部を挙げると、次のと
『改訂新版 良いコード／悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方』で学ぶコードの”価値観” - Magnolia Tech
改訂新版 良いコード／悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方 作者:仙塲 大也技術評論社Amazon 本書の冒頭に悪いコードの例として「連番命名」という、メソッド名を単なる連番で命名する手法が出てくる。メソッドの目的や振る舞いと関係なく、単に「method001、method002、method003...」と連番で名前を付ける手法のことを指す。 環境上の制約でこのような命名をしている場所でも、意外と中に居る人たちは環境に最適化され会話は案外成立しているものだったりする。 それに「命名の妥当性」で設計内容がレビュアーや、発注者からリジェクトされるリスクを負うより、単なる連番にしてしまう方が合理的な場合もあるのだろう。 ミノ駆動さん（仙場大也さん）著の『良いコード／悪いコードで学ぶ設計入門』が早くも改訂され『改訂新版 良いコード／悪いコードで学ぶ設計入門 ―保守
この記事は毎週必ず記事がでるテックブログ Loglass Tech Blog Sprint の72週目の記事です！ 2年間連続達成まで残り34週となりました！ はじめに ソフトウェアエンジニアの福土（@ryoya_cre8or）です。 ふと社内のSlackで「ポリモーフィズムを使っているときに、冗長になるコードをジェネリクスを使うことで綺麗にまとめる事ができる」と呟いたところ、「ジェネリクスもポリモーフィズムの1種だよ」とツッコミをいただき、それを機にポリモーフィズムの概念について整理したいと思っていたので、年末年始にオリャっとまとめちゃいます。 実は共変性・反変性の概念を理解する上でもポリモーフィズムの概念を整理することはすごく良かったので、そこまで記事を書き切りたかったのですが息が足りず... 続きは次回とし本記事ではポリモーフィズムが何なのかについてまとめています。 ポリモーフィズム
Netflixで2億3800万人の会員を管理するということ
Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
コレから建てる「家にお金をかけたくない人」が建築費3000万前後で建てようと思ってる場合は優先度を間違わないで欲しい話→有益な情報が集まる
まつ/住宅設計/茨城 @RyotaMatsuyama1 コレから建てる、 『家にお金をかけたくない人』 建築費3,000万前後（なんならそれ以下）で建てようと思ってる人は優先度を間違わないで欲しいの。 最優先は、 ・許容応力度計算の耐震等級3 ・断熱は断熱等級6（HEAT20 G2） ・気密はC値1以下（できれば0.5以下） ・樹脂サッシペア（できればトリプル） ・全棟気密測定の会社 ・メンテしやすい1種換気or考えられたその他換気 ・太陽光発電5kw以上（蓄電池はできれば） ・オール電化（こだわりガスは全然OK） ・メンテが少ない外装 ・メンテが少ない白蟻対策 2024-12-30 20:50:57 まつ/住宅設計/茨城 @RyotaMatsuyama1 をやった上で、 ・制振ダンパー ・カッコいい外観デザイン ・奇抜すぎない間取り ・その他好みの内装材 ・考えられた空調計画 をやろうぜ
ハードウェア記述言語で遊ぼう！
はじめに こんにちはみみです。 この記事は UEC Advent Calendar 2024の 19 日目の記事です。 書いているのは 2025 年です。（遅れてすいませんでした） 昨日は、Kanaru さんの Minecraft で始める論理設計学 でした。今回は、これの内容を ハードウェア 記述言語の Veryl を使って実装してみる、という話です。 Veryl もといハードウェア記述言語について ハードウェア記述言語とは ハードウェア記述言語（HDL）とは、デジタル回路などのハードウェアの構成を記述するための言語です（そのまま）。 例えば、みなさんの馴染みのある AND ゲートや OR ゲートを以下のように記述することができるんです。
アーキテクチャ設計の民主化とADR(Architectural Decision Records)による意思決定の未来 - Facilitating Software Architecture の読書感想文 - じゃあ、おうちで学べる
年末年始の慌ただしい時期に、数ある選択肢の中からこちらの記事をお読みいただき、誠にありがとうございます。 人生を定期的に振り返ることには、本書で取り上げられているADR（Architecture Decision Records）に通じる素晴らしさがあります。過去の決定とその背景を記録し、将来の自分や他者が参照できる形で残すことは、個人の成長にとって貴重な資産となります。そんな観点から今年を振り返ってみると、2024年は私自身にとって大きな試練と変化の年でした。 印象的だったのは、ある時期に突然、技術に対する興味や情熱が完全に失われてしまったことです。それは技術分野に限らず、仕事全般や私生活にも波及し、何をするにも意欲が湧かない、深い無気力状態に陥ってしまいました。 しかし、この困難な時期を経て、いくつかの意味のある変化が生まれました。私は以前から技術書の書評を書いていましたが、これは主に
「ドメイン駆動設計をはじめよう」の感想
1章 事業活動を分析する この章は事業活動を理解するためのドメイン駆動設計の考え方とやり方が解説されています。 感想 ドメイン駆動設計は事業活動と構造を理解するところから始まります。 理想的には設計者や開発者が業務全体を完全に理解したうえで設計や開発を進めることが望ましいです。 しかし、現実としては設計者や開発者がすべての業務を完全に理解することは極めて難しいです。 そこで重要となるのがコミュニケーションとなります。 業務エキスパートと密にコミュニケーションをとり、本来の意図を漏れなく汲み取ることがなにより重要になると思います。（どのようにくみ取るかは次章で解説されています。） この辺りはSIerとして参画する場合に特に必要とされると思います。 いかにステークホルダーを巻き込みながら業務エキスパートとの信頼関係を築けるかが、プロジェクトの成功を左右すると言っても過言ではないと思います。 2
初めに モチベーション 私はこれまでドメイン駆動設計で設計されたシステムの開発案件に参画した経験はありますが、1からドメイン駆動設計で設計での設計を行った経験がありませんでした。そのため個人でシステムを開発している際に設計に悩むことがあり、自身で1からドメイン駆動設計ベースの設計ができるようになることを目指して学習を進め、その過程で得た知見をまとめています。 特に以下のような点に焦点を当てています。 ドメイン駆動設計の理論をTypeScriptのコードベースで理解する 既存のドメイン駆動設計システムを理解するだけでなく、新規設計ができるようになるための知識の整理 ドメイン駆動設計(DDD)とは ドメインとは「システムが対象とする業務領域」のことです。 例えば不動産管理システムを例にすると、物件、オーナー、入居者などがドメインとなります。 ドメイン駆動設計の本質は、このような現場の業務知識や
実践セキュリティ監視基盤構築
本書では情報セキュリティ対策の一環であるセキュリティ監視を実現するための方法として、セキュリティ監視の基盤を自分で構築するために必要となる実践的な設計・実装方法について紹介します。セキュリティ監視基盤を内製する方だけでなく、既製ソフトウェア・サービスを利用して基盤構築しようとしている方にも参考になれば幸いです。
リソース名に規則性を持たせたい こんにちは、のんピ(@non____97)です。 皆さんはAWSのリソース名に規則性を持たせたいと思ったことはありますか? 私はあります。 AWSを使っている中で「命名規則を設定した方がいい」もしくは「設定しなければならない」場面があります。 利用し始めはリソース数や管理、使用するメンバーが少なくなんとかなることもあります。しかし、規模が大きくなってくると、命名規則が設定されておらず無秩序にリソース名が設定されていると、オペレーションミスが発生したり、構成を把握するのに時間がかかったりします。 そんな命名規則を設定するのにあたって参考になるのが以下記事です。 こちらの記事をベースに命名規則を改めて考えてみた時に、考慮が必要な内容をまとめてみました。 以降、AWSリソースの命名規則についてまとめた基本設計書の例を紹介します。 記載した内容に対する一言コメントは
AI技術を活用して除雪を行うロボット除雪機が大雪前に何とか間に合った...→毎日の雪かきが重労働となっている地域での生活が一変するのではと称賛の嵐
yuta suito @yutasuito NPUで動くロボット除雪機が大雪前に間に合いました☃️パイロン置いてスイッチ入れると自動で雪を端に寄せます。毎日の除雪時間が1/3に💨💨💨 #raspberrypi pic.x.com/WR3WZ3cKye 2024-12-27 11:24:09
個人的技術書大賞2024 - Qiita
O'Reillyサブスクリプションで読むことができる今年発行された書籍の中から、これは良いんじゃないかな、と感じたものを紹介します。 Balancing Coupling in Software Design 『[ドメイン駆動設計をはじめよう』原著者のVlad Khononovさんの最新作で、ソフトウェアにおいて結合とは何かを一冊まるまる使って掘り下げた本です。 ソフトウェアにおける結合というと、その指標として50年以上前に提唱された構造化設計時代の結合強度が用いられがちです。本書ではこれについて解説をしつつも、新たな現代における結合強度の基準を提案しています。(元ネタはMichael NygardのUncouplingを統合したものでもあるのですが…) それから開発の辛みは結合強度だけでなく、「距離」「変動性」も影響してくるため、これらのバランスをとるのが重要であるといい、以下公式を導き
テストコードの保守性を高めるPlaywrightのPage Object Model入門 〜Percy連携までの実践的アプローチ〜 | DevelopersIO
情報システム室の進地＠日比谷です。 E2Eテストにおいて、テストコードの保守性は重要な課題の一つです。この記事では、PlaywrightでのPage Object Modelの実装方法と、Visual Regression TestingツールのPercyとの連携について、実践的なアプローチをご紹介します。 なぜPage Object Modelが必要か テストコードの保守性の課題 まず、Page Object Modelを使用しない一般的なテストコードを見てみましょう。 test('ログインテスト', async ({ page }) => { await page.goto('https://example.com/login'); await page.fill('#email', 'test@example.com'); await page.fill('#password', '
今Rails 8アプリを作るなら何も足さないバニラ味にしよう（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: 37signals Dev — A vanilla Rails stack is plenty 原文公開日: 2024/12/20 原著者: Jorge Manrubia -- 37signalsの首席エンジニアです 日本語タイトルは内容に即したものにしました。 今の世の中で、Railsアプリを新しく作るゆとりに恵まれているならば、バニラアプリとして作る1、すなわち依存関係を何も足さないのが、私たちからのオススメです。 Rubyの依存関係は、よほどの理由がない限りRailsに追加しない。 Railsで生成したGemfileは、極力手つかずのままにしておく。 JavaScriptの依存関係をRailsに追加するのは、Ruby依存関係の場合以上に慎重に検討する。 Reactなどのフロントエンドフレームワークも、それらにJSONを送り込
さくらインターネットではこれからのクラウドをつくるインフラエンジニアを募集しています - Hateburo: kazeburo hatenablog
ひとつ前の記事では主にソフトウェア開発のポジションを紹介しました。 kazeburo.hatenablog.com クラウドの開発、GPUを活用した生成AIクラウドサービスの実現にはソフトウェア開発のエンジニアだけではなく、サーバやネットワークの設計開発と運用、石狩をはじめとするデータセンターでの運用を行うエンジニアも結集して取り組むことが必須です。 この記事ではさくらインターネットのインフラを支えるエンジニアのインタビュー記事やオープンしているポジションを紹介します クラウド基盤 「さくらのVPS」「さくらのクラウド」のインフラを担当する基盤ユニットのメンバーのインタビュー。 sakumaga.sakura.ad.jp sakumaga.sakura.ad.jp 基盤ユニットでは仮想化ホストとなるサーバ、ネットワーク機器、ストレージなどのクラウドの基盤の設計、開発、運用を行います。 ww
午前中に読み始めたら午後には設計が上達してしまった！ - 『Tidy First?』を読んだ - Mitsuyuki.Shiiba
私の目標は、読者が午前中に本書を読み始めたら、午後には設計が上達していることだ。 本当にそのとおりだった。読んでる途中で既に自分の設計に対する考えが良い方向に変わってると感じた。とても良かった。おすすめです。 『Tidy First?』 をいただいて読んだ。昨日（2024年12月25日）発売。英語版が2023年11月28日発売だから、たった1年で日本語版が出たということだな。うれしい！はやい！ありがたい！ ソフトウェア設計に焦点を当てたシリーズの最初の1冊ということで、サブタイトルに「個人で実践する経験主義的ソフトウェア設計」とあるように、1人でできる種類のソフトウェア設計について書かれている。続刊ではチームについての話になる予定のようで、それも今から楽しみ。 2周読んだ なんとなく2周読もうと思ってそうした。 1周目は細かい部分は気にせずにざーっと1,2時間くらいで読んだ。全体的にどうい
突然ですが皆様は、稼働済みサービスのDBからテーブルカラムを削除されたりすること、ありますでしょうか？ 基本的に削除はまずやらないのではと思います。えっやらないの？ と思われた方もいらっしゃるかもしれませんが、きっとこの記事を読めばなぜ多くの方がカラム削除を避けるのかわかることでしょう。 とはいえ、そうして使わないカラムがテーブルに溜まっていくとやがて新規加入メンバーがコードにキャッチアップする妨げとなるレベルにまで溜まってきたりします。いつかは大掃除のときがくるわけです。DBは寿命長いですからね。そうしたときに実際どのような手順でカラムを削除するのか見ていきましょう。エムスリーエンジニアリンググループUnit1（製薬プロモーション）・Unit9（治験臨床研究支援）チームエンジニアの三浦 [記事一覧 ]が、最近実際にやった作業から知見をお届けします。 長いので3行で 考え方 1. そのカ
和倉温泉・加賀屋が新たな拠点旅館の建設を決定！デザインは隈研吾氏で2026年度冬に開業へ「真・RYOKAN」計画が始動 | TBS NEWS DIG
能登半島地震以降、休業が続いている和倉温泉の加賀屋が、新たな拠点となる旅館の建設を発表しました。デザインは世界的建築家の隈研吾氏が担当し、2026年度の開業を目指します。日本一のおもてなしで知られる加賀…
「改訂新版 良いコード/悪いコードで学ぶ設計入門」を使ったリファクタリングの事例 - Findy Tech Blog
こんにちは！ファインディのプロダクト開発部でエンジニアをしているham (@hamchance0215)とEND（@aiandrox）です。 この記事はFindy Advent Calendar 2024 25日目の記事ということで、2人で共同執筆しています。 adventar.org この記事について ファインディでは日頃からお世話になっている皆さんに感謝の気持ちを込めて「Findyユーザー感謝祭 2024」を12/19に開催しました。 イベント中に、参加者の一人であるミノ駆動(@MinoDriven)さんが12/25発売の著書「改訂新版 良いコード/悪いコードで学ぶ設計入門」を参加者4名にプレゼントしてくださいました！ じゃんけんで勝った4名が書籍をゲットするルールであり、hamとENDがじゃんけんの強さを発揮して書籍をゲットし、なんやかんやあってこの記事を書くことになりました。 さら
3年でバックエンドエンジニアが5倍に増えても破綻しなかったアーキテクチャ そして、これから / Software architecture that scales even with a 5x increase in backend engineers in 3 years
2024/12/24 に開催された「【アーキテクチャと組織の変遷】スピードとスケーラビリティの両立-基盤刷新・モジュラモノリスの行先-」の登壇資料です。 https://findy-tools.connpass.com/event/338716/ # スライド内に記載したURL 組織の立ち上げ…
この記事は株式会社カオナビ Advent Calendar 2024の23日目の記事です。 Jotai は、Reactで使えるステート管理ライブラリとしては、現状筆者が最も好んでいるものです。その理由は単純で、ステート管理アーキテクチャとして優れていると思うからです。Recoilが現役のころは同じ理由でRecoilを好んでいました。 Jotaiは2023年1月にv2がリリースされました。非同期処理の扱いがv2はそれより前と異なっており、簡単に言うとJotaiのコアから非同期処理（Promise）に対する特別扱いが排除されました。これにより、コアのAPIをReactから切り離すことができたとされています。JotaiはReactから使われることが多いとはいえ、以下のスライドでもJotaiが「Reactに依存しないライブラリ」として評価されていることからも分かるように、このような特徴は技術の普及
エンジニアの成長に技術力は必要条件であって十分条件ではない - 文系新卒エンジニアが大規模開発から得た技術以外の3つの成長 - Speee DEVELOPER BLOG
※この記事は、2024 Speee Advent Calendar 23日目の記事です。 昨日の記事はこちら tech.speee.jp はじめに こんにちは、SpeeeのDX事業部でHousiiというサービスのアプリケーション開発をしている24新卒の北田です。大学では法学部で文系の出身でしたが、現在はReactとRailsを使用したフルスタック開発に携わっています。 入社から半年が経ったあたりで、私はサービス開始以来最大規模の新規開発のリードという機会を任されることになりました。このプロジェクトを通じて、私は「エンジニアの成長に必要なのは技術力だけではない」ということを強く実感しました。 そこで、この記事では、以下の3つの観点から、エンジニアの技術以外の成長について共有させていただきたいと思っています。 事業視点での判断力：機能を「作る」前に「判断する」ことの重要性 技術的な判断力と実装
GitHubのfoostan/crkbdレポジトリのスター数も順調に伸びており、この1年間で2k弱増えて6kに届きそうです。ありがたい限りです。 数字だけ見ると順調ではあるもののリリース後にいくつかのトラブルがありました。今後同じ問題を踏まないように自分自身や同じ活動をしている方々に向けてまとめておきます。 パーツの在庫不足Corne v4ではよりコンパクトに収めるために自作キーボードでよく使われているPJ320Aではなくmid-mountなパーツを使っています。 もともと使っていたパーツはST-0277D00-052-142でしたが、このパーツがJLCPCBで扱われなくなり、Elecrow等でも入荷できないことからパーツの変更を余儀なくされました。mid-mountなTRRSコネクタのパーツはいくつか選択肢はありましたが射出成形の専用ケースを修正するわけにはいかないので使えるパーツはかな
こんにちは。バクラク申請・経費精算 ネイティブアプリエンジニアのchocoyamaです。 最近妻が身近な金継ぎ師を探しているので、もし身近な金継ぎ師がいらっしゃる方はご紹介いただけると嬉しいです。 この記事はLayerXテックアドカレ2024の23日目の記事です。 今回の記事では私たちモバイルアプリチームが実装アーキテクチャをどのように決定・運用しているのかをご紹介したいと思います。 前提情報 現在バクラクのモバイルアプリチームは、社員3名 + インターン生1名といったエンジニア構成でFlutter製のネイティブアプリ開発を行っています。 このアプリはフォームを中心としたプロダクトで、今年9月にストアリリースを行いました。 bakuraku.jp アプリの規模感としては、実装ボリュームがとても大きく、クライアント側でカバーすべき機能の膨大さから、私個人の経験としても過去最大レベルに複雑度の
ritou です。 もう23日ですが、Digital Identity技術勉強会 #iddance Advent Calendar 2024 10日目の記事です。 最近パスキー関連の記事などを書いている中、いわゆるログイン機能について様々な捉え方があることを改めて感じています。 ユーザー目線ではなかなか難しいことはありつつも、開発者目線でログイン機能を設計する際には共通認識を持つことが重要です。今回はアカウントリカバリー付きのログインフローを設計する際の考え方を整理してみます。 キーワード この説明におけるキーワードとなる処理は次の3つです。 当人認証: いわゆる認証処理。サービス登録済みのユーザーを識別し、検証する。 パスワード認証、パスキー認証、メール/SMS OTP、TOTPなど個々の認証方式で実現できる部分。ソーシャルログインも同様。 身元確認: ユーザーが主張した属性情報の検証。
こんにちは。決済プロダクトでQAエンジニアをしているrenです。freee QA Advent Calendar2024の23日目です。 今回は、決済プロダクト開発にテストアーキテクチャを設計した事例について紹介します。 テストアーキテクチャとは テストアーキテクチャによって解決したい課題 テストアーキテクチャ設計のステップ 1. この振る舞いを担保するためには、どのようなテストが必要だろうか？という問いを立てる 2. 抽象化して考えるための概念を学ぶ 3. テストアーキテクチャを描き、議論する テストアーキテクチャ設計のインパクト 実装改善に関する気づき テストの構造とソフトウェアの構造に関する気づき 自分たちのテスト活動の課題に関する気づき チーム開発の支援を通じた工数上のインパクト テストアーキテクチャがもたらす価値 今後の展望 [appendix]今回設計したテストアーキテクチャの
PHPカンファレンス 2024での登壇資料です。 https://fortee.jp/phpcon-2024/proposal/ac2fa6f2-588f-4faa-a0e2-35e4d8d9f808
この記事は、LIFULL Advent Calendar 2024 21日目の記事になります。 はじめに LIFULLでは、技術負債解消のためにレガシーなコンポーネントをいわゆるCleanArchitecture(以降CA)に置き換えるという取り組みをやっています。 内製ソフトウェアアーキテクチャでレガシーシステムを刷新し技術的負債を削減するまでにやったこと クリーンアーキテクチャで構築したプロダクトが2年経過してみて現状どうなっているかを紹介 新卒エンジニアがリファクタを突貫したClean Architectureプロジェクトの舞台裏 CAはいくつかのレイヤに別れていますが、LIFULLではCAのEnitityをドメイン駆動設計(DDD)で言うところのドメインモデルで実装しています。 この記事は、前に読んでいた関数型ドメインモデリングの「型によるドメインモデリング」がこの実装に応用できる
私たちは、中小規模システムにおけるイベントソーシングの可能性に着目し、 2022年4月から社内でイベントソーシングフレームワークの開発と運用をしています。 現在では、社内システムや受託システムを含む5つ以上のシステムにイベントソーシングを導入しています。 本セッションでは、イベントソーシングを用い…
SNSなど、ユーザー名をURLに含めているサービスは色々ある。このZennもそうだ。ただ、考えることが多い。例えば以下の点だ。 システムで使いたい文字列をユーザー名に使われる可能性があるので、ユーザー名に使えない膨大な文字列のリストを管理する必要がある 実装に失敗すると、一部のユーザーだけ特別扱いするルーティングを独自実装する必要が出かねない 簡単な対応策としては /user/{ユーザー名} のようなURLの規則にすること これを採用しているサービスもあるが、見た目がダサいからか、あまり好まれていない印象がある ということで、現実的な解決策として @user_name みたいな@始まりのURLにする方法がある。 自分が知る限り、最初にこれをやったのはMediumだが、Mediumは現在サブドメインにするルールになったようで、いつの間にかこの形式を辞めてしまった。 実はTwitter（現X）
はじめに この記事はLipersInSlums Advent Calendar 2024 「スラムで年収をあげる〜だが僅かばかりの友の他は、皆、スラム民を嘲った。資格取得で年収アップに挑むなどと〜」の大遅刻組の記事である。シモンは泣いていい。 筆者がプログラミングを初めた頃はインターネットの検索技術は発達しておらず、良質なコンテンツにたどり着くには一苦労だった。そのため、何か新しいことを学ぶのに最初に手を取るのは技術書であった。 今では検索技術は高度に発達し、必要な情報は検索すればたちまち手に入る用になった。しかしながらそれらの断片的な知識群を体系化し、習得するのは未だ難しい。体系的に知識を習得する上で技術書は未だ最も有力な候補となる。 この記事では主にジュニア(?)エンジニア向けに、読むとプログラミングに必要な比較的陳腐化しにくい様々な知識が体系的に身に付いて役に立つお得な技術書を簡単に
AIの進化に伴い、エージェント（Agent）という概念がますます注目されています。この記事では、Anthropicが提供するAI「Claude」の研究内容を元に、エージェントを構築する際に効果的な設計パターンや手法を分かりやすく解説します。「エージェント」という言葉が難しく感じられる方にも、「どうやってAIがもっと賢く、実用的に働けるのか？」という視点で楽しく理解できるようお伝えしますね。✨ 目次エージェントとは何か？ エージェントを使うべきタイミングと注意点 5つの主要ワークフロー 高度な「エージェント」の特長と使い所 エージェント構築の成功法則 まとめ 1. エージェントとは何か？エージェントの基本的なイメージ エージェントとは「特定のタスクを自主的に計画・実行するAIシステム」です。簡単に言えば、「AIがあなたの指示を理解して、自分で考えてタスクを遂行する存在」です。 Anthrop
デザインシステムを拡張し、プロダクト開発の共通基盤を目指す - freee Developers Hub
統合UX基盤というチームでエンジニアをしているtakumiです。freee Developers Advent Calendar 2024の20日目は、現在社内向けに開発を進めている新しいUIライブラリ「標準UI」について、その特徴や開発過程を紹介していきます。 デザインシステムの浸透と新たな課題 freeeでは2018年からデザインシステム「vibes」を開発・運用してきました。最近ではOSSとして公開し、アクセシビリティをはじめとするフロントエンド開発のノウハウを広く共有できるようになりました。以前の記事「デザインシステム "Vibes" の育てかた」でも詳しく解説していますが、vibesの導入により、ボタンやフォームといった個々のUIコンポーネントのデザインは標準化され、一定の成果を上げることができました。 しかし、アプリケーションの規模が拡大し開発チームが増えていく中で、新たな課題
アーキテクチャを設計するといふこと | ドクセル
アーキテクチャを設計すると いふこと Forkwell Library #77 Dec 19, 2024 Takeshi Yonekubo
キーワード：alt 属性, 代替テキスト, マシンリーダビリティ, Web アクセシビリティ, 支援技術, スクリーンリーダー この文書は、2024年12月17日に私 @debiru_R によって記述されました。私は2000年頃より HTML, CSS を研究し始めましたが、2013年頃から MDN Web Docs（旧 Mozilla Developer Network）の日本語訳コントリビューターも務めており、MDN Web Docs や Wikipedia といった各種 Web コンテンツの HTML 関連の記事の整備に従事しています。 代替テキスト、特に alt 属性値について言及していますが、私の理解が不足している箇所があるかもしれません。内容に誤りや不適切な点があると判断された方は @debiru_R までお知らせいただけると幸いです。 余談ですが、この文書自体および本文中の空
はじめに LITALICO の @katzumi です。 2020 年に LITALICO へ Join して以来、ずっとレセプト業務の開発に携わってきました。 レセプト業務は複雑なドメインゆえミスが許されず、さらに３年に一度の大きな報酬改定があり、ロジックが大幅に変わります。 その改定作業は情報公開から実装完了までの期間が約 3 ヶ月と短いです。また、年々複雑化するシステムに対応する必要があります。 その複雑な業務に立ち向かった内容を過去にも以下の内容で開発業務の記事を書いていました。 今年 2024 年は法改正の年になっており、取り組みの結果、その後どうなったのか？を振り返っていきます。 今回も壮絶だった法改正 私自身の大規模法改正の経験が今回で 2 回目となります。 チーム構成としては私ともう一名を除いて前回の 2021 年度法改正を経験したメンバーがいませんでした。前回は 3 種類
クレジットカードの不正検知システムを3日で設計し、3週間で本番リリースした話 - LLMで加速するソフトウェア開発 - LayerX エンジニアブログ
はじめに 背景：クレジットカード不正検知システムとは 3日でDesign Doc 2本、ADR 5本を執筆 3週間で開発し、本番環境にリリース LLM活用による効率化のポイント 目的・要件の整理 要件を満たす技術的オプションの洗い出し・技術調査 PoC実装 ドキュメントの執筆・技術選定 本実装 学び おわりに はじめに 新規プロダクトやプロジェクトの立ち上げにおいて、どれだけ意思決定を明確化し、設計を固めることができるかは、後々の開発効率や品質に大きな影響を与えます。一方で、最初が肝心だからといって調査や設計に何か月も費やす余裕は、多くの企業にはありません。できる限り早く設計を確立し、実装を開始して価値を生み出すことが求められます。 LayerXのバクラク事業では、法人向けのクレジットカード「バクラクビジネスカード」を提供しています。サービス開始時から不正利用を検知する仕組みを導入していま
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
2025年の年始に読み直したいAIエージェントの設計原則とか実装パターン集
ポリモーフィズムが1種類しかないと思ってたエンジニアの備忘録
TypeScriptで実践するドメイン駆動設計（DDD）
AWSリソースの命名規則を考えてみた (2024年版) | DevelopersIO
DBテーブルのカラムを削除するときにやること・考えること - エムスリーテックブログ
DNSにおける委任の構造が大きく変わる!? IETFの「deleg WG」が最近熱いらしい。再設計を目指し、慎重な議論【Internet Week 2024】
Jotai v2を使いこなすために実は必須級な“async sometimes”パターンの解説
2024年のキーボード活動の振り返り｜foostan
CursorとDesign Docで実現する漸進的なアーキテクチャ改善 - LayerX エンジニアブログ
当人認証、身元確認、クレデンシャル設定を組み合わせた "詰みにくい" ログイン機能の設計
テストアーキテクチャの実践 - freee Developers Hub
責務を分離するための例外設計 - PHPカンファレンス 2024
TypeScriptで『関数型ドメインモデリング』をやってみよう - Qiita
２年間の実運用を経て振り返るイベントソーシングの実際
ユーザー名をURLに含めるなら@始まりにするとよさそう
読むとお得なソフトウェアエンジニアリングの技術書一覧
Claudeが提案するエージェント構築：簡単で効果的な設計のベストプラクティス｜Kyutaro
alt 属性完全解説 - Master of Alternative Text
アーキテクチャレベルで依存性を逆転させたら最高だった話