サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
この記事は DeNA 20 新卒 Advent Calendar 2020 19日目の記事です。 はじめに MySQLやPostgreSQLに代表されるRDBMSではトランザクションと呼ばれる仕組みが提供されています。多くのWebアプリケーションエンジニアはこのトランザクションを駆使してDBとやりとりをするロジックを組み立てることになります。 しかし不整合を起こしたくない処理があるからといって闇雲にトランザクションを張ったり、トランザクションが張られているからと安心してアプリケーション側で闇雲にロジックを組み立ててしまうと思わぬバグを生むことになってしまいます。 このエントリでは、「トランザクションを張っておけば大丈夫」という考え方は危険な場合もあるということを、ありがちな実装例を交えて紹介していきます。 並列に処理されるトランザクション そもそも、トランザクションは全て直列に処理されるわ
関連リソース 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エージェントのアーキテクチャ」について、シン
最近、少々複雑な権限機能の開発を担当している中で、対応方針を悩んでいたことがありました。 権限機能というものは取り扱いが難しく、影響範囲が広いにも関わらず、対応漏れや考慮不足があると情報漏洩に繋がってしまいます。 また、機能拡張をしてく中でも対応漏れを起こさないようにする必要があるなど、考えることも多く頭を悩ませておりました。 そこで、認可処理の設計のベストプラクティスやDDDの実装パターンに認可処理を組み込む方法など、色々と調べていたのですが、その中でいくつか知見を得られたのでまとめようと思います！ 権限と認可 権限と切っては切れない関係にあるのが認可です。 権限はある操作を実行できる権利を指します。 それに対して、認可は操作を実行する許可を出すため仕組みのことを指します。 例えば、ブログ投稿サービスで考えてみると、以下のような感じです。 権限: 投稿者はポストを編集できる。 認可: ユ
PoEAA を通して DDD の半分を理解する マーティン・ファウラーの PoEAA を読んでから、DDD のことを考え続けている。今まで DDD の話題はあえて避けてきた。分厚く難解な書籍、増えるコード量、教祖とその信徒たち（MV）、全てをその視点から解釈しようとする試み、少しでも間違えたら求められる自己批判、無知な者に対する SNS 上のオルグ、いつまでも出てこない総括、それでも信じるものは救われる。「一匹の亡霊がIT界隈を徘徊してる。DDDという亡霊が...」 まあ早まらないでほしい。何も DDD こき下ろそうというわけではない。自分の実力不足が主な原因と思い、深入りする前から「わからないもの」と決めつけていた DDD は、PoEAA というライトに照らされてその姿を私の前に姿を表し始めた。それは亡霊ではなく、確固たる手触りのある実体（Entity）だったのである。 PoEAA は
今回はアプリケーションアーキテクチャを学ぶ最初の一歩として、「MVC」や「3 層アーキテクチャ」などの基本的な用語の意味や関係性を整理する「改めて整理するアプリケーション設計の基本」。ここで大嶋氏が登壇。次に、ビジネスロジックの実装方法について紹介します。前回はこちらから。 ビジネスロジックの実装の2つのパターン大嶋勇樹氏：ここまでの流れは、「そもそも3層アーキテクチャって何だっけ？」というところから、特に「真ん中のビジネスロジックって何だっけ？」と（いう話）、「例えば、このあたりがビジネスロジックだよね」と（いう話）。（そして）「ビジネスロジックの中には、ドメインロジックとユースケースの2種類があると考えるとわかりやすいですよ」というところまで話してきました。 ドメインロジックは、システム都合ではないコアなルールみたいなもので、ユースケースは処理の流れを実現することです。これを踏まえて次
この記事は一休.com Advent Calendar 2025の13日目の記事です。 宿泊開発チームでエンジニアをしている @kosuke1012 です。 本記事では、予約処理の中で必要な在庫引当、カード決済などの各処理について、予約処理全体として成功/失敗の結果整合を実現するための実装パターンを紹介します。 背景 現在、一休.com の宿泊予約のシステムでは、予約部分のリニューアルを進めています。 予約リニューアルプロジェクトの全体感もどこかで是非説明したいのですが、アドベントカレンダーの期日も迫ってきているため、 リニューアルの中で取り組んだ、予約処理の結果整合を実現するための実装について書いてみたいと思います。 用語 この記事内での用語の定義をしておきます。 この記事の中で「トランザクション」と言った際には、予約処理全体を指すことにしたいと思います。 また、「カード決済」「在庫引当
この連載について AIやデータ分析の分野では、毎日のように新しい技術やサービスが登場している。その中にはビジネスに役立つものも、根底をひっくり返すほどのものも存在する。本連載では、ITサービス企業・日本TCSの「AIラボ」で所長を務める三澤瑠花氏が、データ分析や生成AIの分野で注目されている最新論文や企業発表をビジネス視点から紹介する。 生成AIの導入が進む中、多くの企業が直面している課題が「RAG」の最適化です。RAGとは、大規模言語モデル（LLM）に外部データベースからの情報を組み合わせることで、より正確で最新の情報を含む回答を生成する技術です。 LLMが学習している内容は汎用的な情報であるため、例えば自社の社則の内容に即した回答を得られません。「ChatGPT」などにはファイル添付機能をアップロードして明示的に社則を提示し、回答を得る方法もありますが、もしLLMに指示や質問した内容に
AWS におけるマルチテナント SaaS の実装パターン ~ サーバーレス編 - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWSSaaS 開発・運用に携わるみなさん、こんにちは。AWS で SaaS に特化した技術支援を行なっているパートナーソリューションアーキテクトの櫻谷です。 これまでコンテナサービスを活用したマルチテナント SaaS の構成例 (Amazon ECS 編 / Amazon EKS 編) についてご紹介してきた本連載ですが、最終回となる今回は、サーバーレスサービスによるアーキテクチャパターンを取り上げます。サーバーレスは、クラウドやモダンアプリケーション開発の文脈でコンテナとともに注目されることが多い技術ですが、SaaS との相性の良さはまだあまり知られていません。この記事では、まずサーバーレスの性質を改めて理解し、それが SaaS 実装にまつわる課題に対してどのようにアプローチできるかを確認します。その後、AWS が提供するサーバーレスサービスを活用したリファレンスアーキテクチャの中身を深掘り
こんにちは。スタディサプリの小中新規開発チームで Web エンジニアをしている @YutaUra です。 去年の４月に新卒で入社をしまして約 1 年が経ちました。インターン生時代にもブログを書いているのでご興味あれば合わせてご覧ください。 GraphQL と Persisted Query スタディサプリ小中講座ではデータ通信に GraphQL を採用しています。 GraphQL を利用することで、クライアントはスキーマに定義された範囲で自由にデータを取得することができます。 query GetUser { user { name age } } また、 GraphQL はデータのグラフ構造に基づいて関連する複数のデータを一度に取得することができます。 query GetUser { user { name age posts { title content } } } GraphQL の
並行処理で実装するのが難しいならStep FunctionsのMapステートを使えばいいじゃない – Amazon SESを使った大量メール送信の実装パターン比較 – 並行処理は難しい AWS SESなどを使用して大量のメールを送信する場合、1通ずつ送信していると時間がかかってしまいます。そういった時に、例えば以下のような並行処理で実装することが考えられます。 import boto3 from concurrent.futures import ThreadPoolExecutor def send_email(email_data): ses_client = boto3.client('ses') try: response = ses_client.send_email( Source=email_data['from'], Destination={ 'ToAddresses':
はじめにDartはインスタンス生成の手法に幅があり、様々な表現を選択することができます。 この記事ではどういった表現があるのかを整理し、普段どのような狙いや考えを持って表現選択をしているのかを可能な限り言語化して示します。 紹介するのはあくまで自身が正しいと考えている内容であり、Dartの公式が提唱する言葉の表現や意図とは異なっている内容もありますので、注意してください。基本は公式ドキュメントの情報を信用しましょう。 「公式ドキュメントを読んで言語表現の意図を理解したものの、実際に現場レベルではどういう意図や狙いを含めて使っているのか？」を知りたい方に向けて、自身の経験知をサンプルとして、何かしらの気づきや参考となるヒントを共有できればと思いこの内容を書きました。 目次はじめにDartのインスタンス生成パターン1. Default Constructors2. Private Constr
Rustで値の文字列表現を返すにあたって、 String を直接返すのではなく Display を実装するのが一般的です。この派生パターンとして以下の4つのパターンを紹介します。 基本: 文字列化を実装したいとき 文字列化をインターフェースに含めたいとき カスタム文字列化 カスタム文字列化をインターフェースに含めたいとき 基本: 文字列化を実装したいとき Displayを実装すると、文字列化できるようになります。 println!, format! などのフォーマット処理から呼べるようになるほか、 .to_string() というヘルパ関数が使えるようになります。 以下はプログラミング言語処理系において、「変数」をあらわす構造体に文字列化を実装する例です。 Playground pub struct Var(String); impl std::fmt::Display for Var {
AWS におけるマルチテナント SaaS の実装パターン ~ Amazon Elastic Container Service (Amazon ECS) 編 - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWSSaaS 開発・運用に携わるみなさん、こんにちは。AWS で SaaS に特化した技術支援を行なっているパートナーソリューションアーキテクトの櫻谷です。 本連載では、これからマルチテナント SaaS を AWS 上に構築しようと考えている方向けに、いますぐ参照できるサンプル実装を紹介していきます。SaaS とはビジネモデルであり、特定のテクノロジースタックやアーキテクチャに縛られるものではありません。ソリューションの性質やドメイン、目指すべき顧客体験によって、最適な構成は異なります。そのため、AWS は、主要なテクノロジースタック別に、SaaS 開発のベストプラクティスに沿った以下のサンプル実装を公開しています。 Amazon ECS SaaS リファレンスアーキテクチャ Amazon EKS SaaS リファレンスアーキテクチャ サーバーレス SaaS リファレンスアーキテクチャ これら
こんにちは、スマートバンクでアプリエンジニアをしている ロクネム です。 みなさんはSwiftUIでViewを実装する際に、”余白” をどのように実装していますか？ SwiftUIにおける余白の表現方法はいくつか存在しており、どの方法を用いても同じレイアウトを実装することが可能です。 しかし、一見同じに見えても意図しない余白が生まれてしまっていたり、変更に弱いレイアウトとなってしまったりするケースが存在しています。 本記事では、SwiftUIにおいて余白を表現する上でどのような実装方法を選択するのが適切であるかについて、具体例を3つほど挙げながら説明します。 要素間の余白の表現 配置によって生じる余白の表現 要素外側の余白の表現 まとめ 要素間の余白の表現 まず、Textが縦に3つ並んだレイアウトについて考えてみます。 1つ目と2つ目のTextは16pt、2つ目と3つ目のTextは8ptの
導入：Reactのchildren Reactのchildrenを使うことで、子要素をwrapするような子要素を記述することが出来る。railsのviewで言えばyieldみたいなもの。 const SomeLabel = ({children}) => { return <div>{children}</div> } // 呼び出し側 <SomeLabel> // 子要素の拡張に対して、`SomeLabel`は関心を持たなくて良い。 <SomeDecoration>Hello</SomeDecoration> <SomeLabel> これを覚えるとだいぶReactをきれいに書きやすくなるイメージがある。 本題：複数の子要素を柔軟に扱いたいときにどう考えるか？ 例えば何かtitle, author,bodyを貰って記事を表示するような<Post>を考える。
こんにちは、アライアンス事業部のきだぱんです。肌寒くなってきて、お鍋が美味しい季節になってきました。「お鍋×冬」の組み合わせも最高！！なのですが、それに負けないくらい「GitLab×AWS」も最高なので、今回はお鍋の話題ではなくAWSでのGitLab活用について見ていきたいと思います。本記事はクラスメソッド DevOps・セキュリティ Advent Calendar 2023とGitLab Advent Calendar 2023の12/11記事になります！ こんにちは、こんばんは。アライアンス事業部のきだぱんです。 今年も残りわずか… 12月に入りました。アドベントカレンダーの季節です！ 本記事はクラスメソッド DevOps・セキュリティ Advent Calendar 2023とGitLab Advent Calendar 2023の12/11記事になります！ - GitLab Adv
2022年4月9日〜11日に開催されているPHPerKaigi 2022で配信されるトークのスライドです。 サンプルコードはGitHubのzonuexe/phperkaigi-psr15にあります。 また、2年前にPHPerKaigiで作った「ゴルフ場」は、まさにPSR-7とPSR-15を使ったアプリケーション例になってます。 https://github.com/phppg/phperkaigi-golf い...
Amazon SageMaker におけるカスタムコンテナ実装パターン詳説 〜推論編〜 | Amazon Web ServicesAmazon Web Services ブログ Amazon SageMaker におけるカスタムコンテナ実装パターン詳説 〜推論編〜 みなさんこんにちは！AWS Japan のソリューションアーキテクトの辻です。このブログでは、Amazon SageMaker のカスタムコンテナの実装方法の選択肢が多すぎて、自分たちのユースケースにどれが向いているのか分からない！、という意見にお答えして、カスタムコンテナの実装方法のパターンを整理・解説しています。 SageMaker ではカスタムコンテナが利用可能な場面はいくつかあるのですが、このブログではホスティングによる推論 (SageMaker Endpoint) で利用する場合について説明します。学習編もこちらで公開しているので、是非一読ください。 はじめに このブログは、既に SageMaker の概要を知っている方を対象としています。Sag
2020 年は Azure App Service にとってはネットワーク周りの新機能やアップデートが非常に多い年になりました。そろそろ今年も終わりなので App Service の定石アーキテクチャをアップデートする良い機会です。 まずは今年のネットワーク関連アップデートについておさらいしておきます。Regional VNET Integration はプレビューの時から使ってきたので、最近 GA したという気が個人的にはしていません。 GA Regional VNET Integration (NSG / Route Table) Private Link (Private Endpoint) NAT Gateway Hybrid Connection for Linux App Service Premium V3 / VMSS Worker Preview Azure Functi
はじめに アドベントカレンダーで書いた認可のベストプラクティスの記事が結構反応を頂けたのですが、最終的な結論が ユースケースによる という投げやりなまとめになってしまっていたのが少し気になっていました。 そこで、ユースケース別の実装パターンをより詳しく解説しようと思い、Kotlin Fest 2024にプロポーザルを出しました。 が、力及ばずお見送りとなってしまいました。 そんな中、Kotlin Festのスポンサーとしてログラスがブースを出展することになり、採択されなかったプロポーザルを紹介する 「ボツポーザル」 が企画されました。 ブースにお越しいただいた方々にスムーズに説明できるようにプロポーザルの内容を詳しく書き起こしています。 特に、前回の記事で詳しく触れられなかったユースケース別のKotlinでの実装方法や、DDDにおける認可の扱いについて調査したので、それらについて解説してい
概要 以前、「ドメイン駆動設計入門」という本に掲載されている、戦術的 DDD の内容を C#から Go に置き換えることで戦術的 DDD を学んでいました。 いろいろ、実装してみて戦術的 DDD のミニマムな実装（エンティティ、値オブジェクトなど）において「Go と DDD の相性が悪くて不向きなのでは」という考えが生まれたので、理由を記述していきます。 自分自身は凄腕 Gopher でもなければ、大規模サービスに DDD を導入した経験もないので、考察の浅い意見が含まれている可能性があります。 ぜひ、コメントにてご指摘のほどお願いします。 理由 先に結論を書くと、 「DDD で守りたい原則を Go の言語仕様で守ってくれる部分が少なく人の目で守らなければならないことが多い」 に尽きると考えています。 具体的な理由を記述します。 理由 1 「言語が用意しているコンストラクタがない」 DDD
さまざまな情報を学習して概ね適切な回答を得られる言語生成AIは、業務効率化や生産性向上に寄与する技術として注目を集めています。 しかし、企業が自社の業務に生成AIを活用するには、独自のノウハウや社内情報を組み合わせていく必要があります。これを実現するアプローチの一つとして、RAG（Retrieval-Augmented Generation：検索拡張生成）に注目が集まっています。大規模言語生成AIモデルと組み合わせてRAGを適切に利用すれば、自社固有のマニュアルやドキュメントを生かし、より精度の高いを得ることが期待できるからです。 本ブックレットは、ITmedia エンタープライズの人気連載「AI ビジネスのプロ 三澤博士がチェック 今週の注目論文」から、RAGの最新動向を紹介します。
はじめに JPYCは、USDCと同様にEIP-2612 (permit)やEIP-3009 (Authorization系)といった規格を実装しており、さまざまな決済機能があります。 しかし、これらの機能を実際の決済システム（ECサイト、POSレジ、サブスクリプション）に組み込む際の課題の1つとして、「オフチェーンで管理される決済ID（例：order_123）と、ブロックチェーン上で実行されるトランザクションの紐付け方法」という問題です。 この記事は、JPYC決済の導入を考えている開発者に向けて 「どの注文に対する支払いだったのか？」ということをブロックチェーン上で追えるようにするための具体的なパターンをいくつか解説します。 JPYCの機能だけで開発できるパターンは詳しく、そしてPermit2やAccount Abstraction(AA)、CREATE2など応用的な方法は紹介程度にサクッ
サマリー ドメインモデルには以下の種類がありそう 🧠 業務知識: 知識レベル 🏃 業務フロー: オペレーションレベル 🧠業務知識（知識レベル）について、以下のような分類ができそう 業務手順の知識: プロセスモデル 業務資源情報の知識: リソースモデル 属性・値の知識: プロパティモデル 意思決定・制約条件の知識: ポリシーモデル 🏃業務フロー（オペレーションレベル）について、以下の構成要素がありそう 業務連鎖: ワークフローモデル 業務イベント: イベントモデル ※ 「ビジネスルール」は上記全てに付随するイメージ 上記はどんな文脈でも抜け漏れなく分析できるフレームとは思わないが、以下に参考にならないか 人間が業務領域を理解したいときの、ver.0.1の定規として AIがコード設計するときの、プロンプトに書いておくモデル分類の指示として コード例もあります！ 🖕 ビジネスプロセスの
DDDにおける認可の扱いとKotlinにおける実装パターン / authorization-for-ddd-and-kotlin-implement-pattern
言語実装パターン ―コンパイラ技術によるテキスト処理から言語実装まで 作者: Terence Parr,中田育男,伊藤真浩出版社/メーカー: オライリージャパン発売日: 2011/12/24メディア: 大型本購入: 5人 クリック: 333回この商品を含むブログ (13件) を見る 「言語実装」と聞くとコンパイラの本かと思いますが、本書は「言語アプリケーション」を実装するための本です。言語アプリケーションには設定ファイルの読み取り、データの読み取り、コード生成、コード変換器、インタプリタなど、入力ファイルを処理・解析したり、変換したりするアプリケーションが含まれます。 このようなアプリケーションはだいたい同じような構成になり、以下のような要素を組み合わせて実装することになりますが、各要素の実装パターンが数種類紹介されていて、メリット・デメリットを考慮して適切なものを選択できるようになってい
2023年9月19日アニメーション,Vue,Vue Router以下のようにシームレスな（繋ぎ目のない）画面遷移を実装するとしたら、どのように実装しますか？それぞれのカードをクリックするとカードが拡大され、そのコンテンツ全体が見れるようになります。 この実装はカード一覧ページと、コンテンツ全体が見れるページの2ページで構成されていて、画面遷移の処理を工夫することで、シームレスな見せ方をしています。 シームレスな画面遷移は、要素同士の関連性を強調したり、アプリへの没入感を高めるなどのメリットがありますが、実装難易度が高く、コードのメンテナビリティが下がりやすいというデメリットもあります。 本記事では、このようなシームレスな画面遷移を実装する難しさを説明してから、Vue.js を使った実際のコードを交えながらその実装方法について解説します。 シームレスな画面遷移アニメーションの難しさ #シーム
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
