サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
内部的にはGoogle Identity Platform +NextAuth による認証、 マルチロール制御、通知、DTO検証などを組み込み、 App Router特有の問題が浮き彫りになるような構成になっています。 📂 リポジトリ: Systemguide: docs/README.md Frontend playbook: frontend/docs/README.md Checklists: docs/checklists.md App Routerの“自由さ”をどう設計で制御するか 実際に運用して分かった課題は、大きく3つです。 1. 境界のあいまいさ server専用コード（handlerやrepositoryなど）がclientコンポーネント側に漏れる。 2. Server Actionのスパゲッティ化 Actionがランダムなpage.tsxに散らばり、 機能とルー
本ガイドラインは、世の中のシステム開発プロジェクトのために無償で提供する。 ただし、掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社（以下、フューチャー）は一切の責務を負わないものとする。 また、掲載している情報は予告なく変更する場合があるため、あらかじめご了承いただきたい。 免責事項: 有志で作成したドキュメントである フューチャーには多様なプロジェクトが存在し、それぞれの状況に合わせて工夫された開発プロセスや高度な開発支援環境が存在する。本ガイドラインはフューチャーの全ての部署／プロジェクトで適用されているわけではなく、有志が観点を持ち寄って新たに整理したものである相容れない部分があればその領域を書き換えて利用することを想定しているプロジェクト固有の背景や要件への配慮は、ガイドライン利用者が最終的に判断すること本ガイドラインに必ず従うことは求めて
iOSDC Japan 2025の登壇資料です！ #iosdc #a https://fortee.jp/iosdc-japan-2025/proposal/c06d6589-0bb2-4ac4-9648-d6d187a53154
Feature-Sliced Designというフロントエンドアーキテクチャ設計方法論をプロジェクトに導入してみたところ、 個人的には良いと感じているので、どのような設計方法論なのか、具体的にどのような部分が良いと感じたかを紹介していきたいと思います。 Feature-Sliced Designとは？ Feature-Sliced Designは、フロントエンドアプリケーションを対象としたアーキテクチャ設計方法論です。公式サイトでは、「コードを整理するためのルールと規約の集大成」と記載されています。 Feature-Sliced Designの設計方法論 Feature-Sliced Designでは、プロジェクトはLayerで構成され、各LayerはSliceで構成され、各SliceはSegmentで構成されます。 Layer Feature-Sliced Designの第一階層をLay
ゲームの仕様書を初めて作成する人のための足掛かりのスライド ▼以下のスライドを一つにまとめました ・ゲームの仕様書を書こう１ 仕様書作成の分業とリストの作成 https://www.slideshare.net/ChizuruSugimoto/ss-173331109 ・ゲームの仕様書を書こう２ 仕様書に記載する機能内容 https://www.slideshare.net/ChizuruSugimoto/ss-173332578 ・ゲームの仕様書を書こう３ 仕様書に記載するデータと画面 https://www.slideshare.net/ChizuruSugimoto/ss-173333150 ・ゲームの仕様書を書こう４ 仕様書作成で楽をするconfluenceの活用 https://www.slideshare.net/ChizuruSugimoto/confluence-17333
あの演出はそういう名前だったのか！ 「明日から使える！海外文献に頻出するLevel Design用語の紹介」で13用語を学ぼう［CEDEC 2024］ ライター：わさび 2024年8月21日，ゲーム開発者向けカンファレンス「CEDEC 2024」で，ゲームデザイナーの知久 温氏によるセッション「明日から使える！海外文献に頻出するLevel Design用語の紹介」が行われた。本セッションは開発者向けに行われたものではあるが，実例を交えてやさしめに解説されていたため，「あのゲームで使われていた演出はこういう名前だったのか！」と，ゲーマー目線でも楽しめる内容だった。レベルデザイナーの目線で見るゲームの世界をのぞいてみません？ 知久氏は，ハクスラSTGや対戦TPSといったジャンルでレベルデザイン業務を経験した実績を持つフリーのゲームデザイナー。副業としてゲーム開発の研究家としても活動している
［GDC 2016］プラチナゲームズ稲葉敦志氏が語る，アクションゲーム作りの本質に基づいた“世界で戦えるゲーム”の制作手法とは 編集部：aueki GDC 2016で，プラチナゲームズ エグゼクティブクリエイティブプロデューサー稲葉敦志氏による「Action Games Without Borders: Making Platinum-Quality Games For The World」と題した講演が行われた。国境を越えたアクションゲーム作りに関するノウハウを紹介する内容で，稲葉氏自身も「社内でも話しことがないようなこと」を語っていた。一線で働くアクションゲームデザイナーがどのような考え方でゲームを作っているのか，講演の内容をまとめてみたい。 まず，稲葉氏は「アクションゲームとはなにか？」という部分から話を切り出した。いわく，「アウトプットに反応する行為の集合」だそうで，ゲームが出力し
このように、REST の設計原則に従ってAPI を構築することで、ほとんどのAPI 設計は直感的に、かつ問題なく行うことができます。 デザインパターンの紹介 ここからが本題です。大抵の場合、上の例で示したようなAPI 設計で十分です。 ただ、複雑な要件では、上のような典型的なAPI 設計のみでは良いAPIを設計するための4つの特性を満たせないことがあり、そのような場合のためにデザインパターンが有効です。 カスタムメソッド 概要 カスタムメソッドは、標準的な CRUD 操作（作成、読み取り、更新、削除）では対応できない特定の操作が必要になる場合に便利です。例えば、メールの送信や即時の文書翻訳など、通常のcreate や update メソッドでは処理が難しい操作がこれに該当します。 参考までに、以下にGoogle が出しているカスタムメソッドの記事を示します。 実装例 以下は、カ
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design2022年3月号「そろそろはじめるテスト駆動開発」より 今回、Software Design2022年3月号 第2特集「そろそろはじめるテスト駆動開発JavaScriptでテストファーストに挑戦」の第1章「保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像」を本サイトに掲載します。第2章以降については、本誌『Software Design2022年3月号』電子版（Gihyo Digital Publishing、AmazonKindle）をご購読いただければ幸いです。 第1章では、混同されることの多い自動テスト関係の概念を、自動テスト、テストファースト、テスト駆動開発の3つの段階に分け、それぞれの効果や注意点を説明します。ソフ
はじめに 皆さんこんにちは、株式会社エムアイ・ラボのエンジニアです！ 今回はソフトウェア設計のSOLID原則について学習したので、弊社のメインの開発言語であるTypeScriptのサンプルコードを使って共有できればと思います。SOLID原則は、オブジェクト思考プログラミングにおいて、ソフトウェアがメンテナンスしやすく、拡張や変更に強いソフトウェア設計を行うための原則です。SOLID原則にはSOLIDの頭文字をそれぞれとった、５つの原則があります。 単一責任の原則（Single Responsibility Principle） 単一責任の原則とは、クラスが一つの機能や責任を持つべきで、クラスが変更される理由は一つであるべきというです。 クラスが一つの機能や責任のみを持つようにすることにより、コードは再利用可能でテストが容易になります。 単一責任の原則を遵守している例 以下のBirdクラ
エージェンシー事業でリードデータエンジニアを行なっている大窄 直樹 (おおさこ)です.AWSのログ, サーバーのログってたくさん種類があって難しいですよね... 同じようなログがたくさんあるので, 何を取れば良いのかとか どのくらいの期間保持すれば良いのかとか またその後の, ログの実装や, 分析方法する方法も難しいですよね... 今回AWSに構築した商用アプリケーションのログを整備する機会があったので, このことについて書こうかなと思います. 概要本題に入る前の準備 今回ログ実装するアーキテクチャ ログに関する法令 ログの取得箇所 設計 保管するログの決定 インフラのログ OSのログ アプリケーションのログ ログの保管 保管場所について 保管期間について バケット構造 アプリケーション, OSのログの転送 実装 アプリケーション, OSのログをfluentbitを用いてS3にログ転送
「Amazonでさえサーバレスやマイクロサービスを理解できない」とDHH氏が主張する一方で、「進化可能なアーキテクチャこそ重要」とAmazonのVogels博士Ruby onRailsの作者として知られるDavid Heinemeier Hansson（DHH）氏が自身のブログに5月4日付けで投稿した記事「EvenAmazon can't make sense of serverless or microservices」（Amazonでさえサーバレスやマイクロサービスを理解できない）が話題になっています。 これはAmazon Prime Videoの技術部門が3月に自社ブログに投稿した記事「Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%」（Prime Videoの音声映像監視サービスにおけるスケールアップと90％のコスト削減の実現）で紹介された、AWSLambdaのサーバレスで作られたPrime Videoの監視サービス
2022年10月1日に開催された #postdev での発表です
SIerのインハウスデザイナーとして働いてるんだけど、うちの会社の業務フローがクソすぎてストレスが溜まっている。 あの、PMのみなさん、ていうか我が社の開発標準つくってるみなさん。 外部設計とか機能設計とか、「設計」ってついてる工程にデザイナーをアサインしてください。 デザインって「設計」っていう意味なので。 別に、知識マウントとか偉ぶってるとかでもなんでもないです。 外部設計も機能設計も社内のエンジニアがエクセルで作っているけど、なんでデザイナーを呼んでくれないんですか？ あなたたちがやってるそれ、デザインですよね？ そのくせエンジニアは、自分が設計書を作っていても「デザイン」をしているという自覚は全くない。 それどころか「自分にはセンスが無いから〜！」と変にデザイナーを持ち上げてくるんだけど、あなたたちのやってることもデザインですよ。 なのに、自分たちだけですっかり外部設計とか機能設計
増田亨さんによる「設計の考え方とやり方」勉強会 書き起こし4ページ目です。最初からお読み頂く場合は、こちらから御覧ください。 資料増田さんの講演資料 質疑応答モデル なぜこの場を作ったのか 書き起こしリンク パート1「良い設計を目指す」 パート2「設計スタイルの選択とクラス設計のスタイル」 パート3「テーブル設計のスタイル」 パート4「開発のやり方と設計スキルと補足資料」（本記事） パート5「質疑応答」 目次 開発のやり方 開発のやり方の分かれ道 組み立て思考の開発のやり方 変化しやすい構造を作る とっとと作る 設計スキルを身につける 設計スキル 設計スキルアップの行動計画 まとめ 補足資料 開発のやり方 開発のやり方の分かれ道 簡単に言うと、目的の固定から出発する分解思考の開発のやり方がかつての潮流でした。タスク分解して、工程分解して分業体制にして、その結果実際に作っている人間の後半の
1990年代にオブジェクト指向分析・設計の方法論がめちゃ流行ったことがあります。 ただ、そのブームが終わって、後続となるような方法論が流行ることはありませんでした。 で、なぜなのか考えていたのですけど、オブジェクト指向方法論のウリは分析段階で出てきたオブジェクト(といいつつクラス)がコードにそのまま引き継がれるというものでした。ようするにオブジェクト指向方法論というのはコードのスケッチを書いて詳細化していくというものだったのです。 しかしながらこれは、スケッチとして書いた分析・設計が間違っていればコードも間違うわけで、強くウォーターフォールの性質をもつものでした。 結局のところスケッチの妥当性というのはコードを書かないと検証ができません。分析・設計段階で見出されたクラスが妥当かというのは、コード書かなければわからなかったのです。逆に、コードを書けば妥当かどうかわかります。であれば、最初から
#asken_dev「設計の考え方とやり方」勉強会 https://asken.connpass.com/event/254709/ ・良い設計は悪い設計より変更が楽で安全である ・ドメインモデル方式のクラス設計 ・イミュータブル方式のテーブル設計 ・設計スキルの身につけかた ・設計の…
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サーバーレスパターン - アーキテクトのためのパターンカタログ
