日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR（長すぎて読みたくない） 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能
クリーンアーキテクチャ完全に理解した
clean_architecture.md 2020/5/31追記: 自分用のメモに書いていたつもりだったのですが、たくさんのスターを頂けてとても嬉しいです。 と同時に、書きかけで中途半端な状態のドキュメントをご覧いただくことになっており、大変心苦しく思っています。 このドキュメントを完成させるために、今後以下のような更新を予定しています。 TODO部分を埋める 書籍を基にした理論・原則パートと、実装例パートを分割 現在は4層のレイヤそれぞれごとに原則の確認→実装時の課題リスト→実装例という構成ですが、同じリポジトリへの言及箇所がバラバラになってしまう問題がありました。更新後は、実装時の課題リストを全て洗い出した後にまとめて実装を確認する構成とする予定です。 2021/1/22追記: パートの分割と、クリーンアーキテクチャという概念の定義について追記を行いました。大部分の実装例パートを中心
システムの複雑さはどこから来るのか – Out of the tar pitを読む - Uzabase for Engineers
Uzabase Saas Product Divisionフェローの矢野です。 この記事は、Rich Hickey（プログラミング言語Clojure作者）のプレゼンテーションSimple Made Easyへと繋がっていく、Ben MoseleyとPeter Marksによる「Out of the tar pit」というシステム設計について論じた論文の内容について説明したもので、ユーザベースのSaas Productでのテック発表の一つとしてプレゼンしたものを、ブログとして再度まとめたものです。プレゼン自体は25分くらいでしたので、おそらくこの記事の方がプレゼンよりも詳しいと思います。 ソフトウェア危機 ソフトウェアは本質的に複雑 ソフトウェアの複雑さはどこから来るのか？ 複雑さは、別の複雑さを産む 複雑さを分類する 本当に必要な複雑さと、そうでないものがある どうやって複雑さを扱うのか
ソフトウェア設計について、YAGNIやSOLIDなど多くの原則・法則があることが知られていますが、その解釈にはぶれが存在することが多いです。そこで、特に有名なものあるいは有用と感じることが多いものをいくつかピックアップして、その解釈やトレードオフについてまとめてみました。 注意としては、SOLIDが入ってることからわかる通り、主にOOPに関する文脈になります。また、各原則の定義については概ね知っている前提で書いているのであまり初学者向けの記事ではないかもしれませんのでご承知おきください。 YAGNI（You ain't gonna need it.） YAGNIは、予測による実装が実際に役立つことは少ないという経験則から生まれた原則です。 一般にオーバーエンジニアリングが利益をもたらすケースは限定的で、どちらかというとプロジェクトに害を与えることが多いとされています。YAGNIは日々状況の
Atomic Designをやめてディレクトリ構造を見直した話｜食べログ フロントエンドエンジニアブログ
こんにちは。フロントエンドチームの金野と申します。 食べログでは現在、React+TypeScriptでフロントエンドのリプレースを進めています。 以前の記事で、食べログではAtomic Designをどのように取り入れているかの紹介をしました。 しかし、最近のリプレース作業では、Atomic Designとは異なるディレクトリ構造を採用しています。 今回の記事では、「なぜAtomic Designをやめたのか」という理由と、「どのようなディレクトリ構造にしたのか」を紹介します。 Atomic Designを導入したねらいと導入した結果 上記の記事で言及した通り、当初Atomic Designを導入したねらいは以下になります。 1. コンポーネントの責務がより明確になる 2. 見た目の粒度だけでなく、ロジックの責務も明確にできる 3. 「ドメインが入るか／入らないか」。「抽象的か／そうでな
はじめに Markdownって便利ですよね？ README.md、PR や Issue の本文やコメント、Qiita や Zenn はもちろん、Google Docs や Trello や Notion や Jupyter Notebook でも使えるみたいです。もっといろいろな文書を Markdown で書ければいいのになあ、あらゆる文書のソースコードを Markdown にできればいいのになあ。 さあ、Markdown の可能性を広げましょう！ 本記事では「スライド」と「(電子)書籍」をMarkdownで書く方法をご紹介したいと思います。もちろん、VSCodeでMarkdownを効率よく便利に書いていくためのチップスもご紹介していきますよ。 ご参考スライド VS Code Conference Japan 2021 で発表した際の以下スライドもご参照ください。 もちろんこのスライドもV
IBM-J テレコン英会話小冊子（PDF配布用）
テレコン英会話小冊子 Practical Expressions for Conference Calls - BETTER ENGLISH WITH US! - Table of Contents テレコンへの心構え (1) テレコンのはじまり (3) テレコンでの決まり文句 (11) 質問やお願いをする (25) 具体的な説明例 (33) ウェブカンファレンス表現 (37) テレコンの終わり (51) 間違えやすい単語 (55) 英語らしく発音しよう (61) 略語 (63) (1) テレコンへの心構え <会議前> 日本側の status を確実に把握しておく。 質問されて 「I don’t know」 では失礼だし、相手に「本当にテレコンで Push するような問題 なの？」と思われる。配布された資料があるときは事前に目を通 し、最新の内容を把握しておく。 事前に日本側のコン
ミラティブのサーバサイドをGo + Clean Architectureに再設計した話 - Mirrativ Tech Blog
こんにちは、テックリードの夏です。 今年4月にCTOからテックリードに肩書が変わり、ガリガリコードを書くようになりました。 背景については、こちらをご覧ください。 www.wantedly.com 普段はプロダクト側の機能開発と、サーバ側の基盤開発を半々ぐらいの割合で仕事しています。 一口にサーバ側の基盤開発といっても定義が曖昧なのですが、基本的にはこんな感じのタスクをやっています。 インフラコストの最適化 不正なアクセスからの防御 障害の再発防止 新技術の導入やアーキテクチャの整備 今回はこのうち「新技術の導入やアーキテクチャの整備」の中で、サーバサイドをGo + Clean Architectureで再設計したことについてお話したいと思います。 背景 ミラティブは2015年春頃に開発が始まり、同年8月にサービスがリリースされ、2020年8月で5周年を迎えました。 その過程で組織やプロダ
こんにちは、よしこです。 この記事は 2020年に立ち上げたWebフロントエンド構成の振り返り の「Stateのアーキテクチャ」項の詳細記事です。単体でも読めますが、よければ元記事もあわせてどうぞ！ この記事では、今わたしが開発・運用しているアプリケーションのState戦略についてご紹介していきます。 全体像 アプリケーションに存在する状態（State）を以下の3種類に分類し、それぞれのやり方で管理しています。 サーバーデータのキャッシュ Global State Local State 1. サーバーデータのキャッシュ 「SPAで管理する必要のあるGlobal Stateって、そのうちほとんどがサーバーデータのキャッシュだよね。それを取り除けたら、管理する必要のあるGlobal Stateってすごく小さくなるんじゃない？」という主張を私が認識しはじめたのが2020年の初旬でした。おそらく
クリーンアーキテクチャのUsecaseはなぜControllerへ値を返すのではなくOutput PortとしてPresenterを呼び出すのか - Runner in the High
何を言っているのかと言うと、みんな大好きクリーンアーキテクチャの右下に図示されているFlow of Controlのこと。 黒線が引かれているということは、つまりUsecaseの中でOutput Portのインターフェイスを持つPresenterの関数なりが最終的に実行されるということである。 ここで湧き上がってくる疑念は「UsecaseがPresenterを呼び出さなくてもControllerに返り値とかで値を返して、Controller経由でPresenterに渡して実行しても同じなんじゃないの？」である。つまりOutput Portというインターフェイスそのものを撤廃してControllerにPresenterを使わせるアイデアである。たしかに、仮にこの方針で行ったとしても依存の方向が壊されることはない。 Software Engineeringでは同様の質問がかなり盛り上がっている
モダンフロントエンドで始めるつらくないReactディレクトリ構成 - RAKUS Developers Blog | ラクス エンジニアブログ
はじめに こんにちは、ラクスフロントエンド開発課の斉藤です。 記事タイトルはReact開発者なら知る人ぞ知るりあクト！ TypeScriptで始めるつらくないReact開発のパロディです。とてもわかりやすい入門書なのでReact初学者の方には学びの第一歩として自信を持ってオススメできます！ さて今回は、モダンなフロントエンド技術を採用したうえで、極力シンプルで開発体験を損なわないようなディレクトリ構成を考えてみたので共有したく記事にしました。現在実際に運用しているのですが、今のところ大きな問題も無くチームからの不満も上がっていません。しかし、個人的に微妙な部分もあるのでそちらの紹介も行いたいと思います。 今回、構成を考えるにあたって重視したポイントは以下の3点です。 新しく参入するメンバーでもすぐに理解できるシンプルな構成にしたい テストやリファクタしやすい構成にしたい できればルールが厳
【Atomic Designに懐疑的なあなたへ】改めて考えたい React / Next.js のデザインパターン
フロントエンド開発は一般的に複雑性との戦いです。放ったらかしにしておくとますます複雑になり、変更するのが難しくなります。これまでにも、このような複雑さをどうにかして制御しようとして、Atomic Designをはじめとした様々な設計手法（デザインパターン）が考えられてきました。 しかし、React / Next.js を使ってチーム開発を行う際に、現状のデザインパターンでの運用では「どうもうまくいかないな」と思う場面に多々遭遇しました。そのような経験を踏まえて、「コンポーネントをどのように設計するか」「どのようにディレクトリを分けるか」を徹底的に考え、新しいデザインパターン「Tree Design」にまとめました。 Tree Design はまだまだ仮説段階です。今後弊社チームで運用していく中でブラッシュアップする予定です。しかし、他のフロントエンド開発チームがデザインパターンを再考する際
こんにちは、delyコマース事業部エンジニアの小川です。 先月11月に入社し、エキサイティングな毎日を過ごしています。 この記事はdely Advent Calendar 2019 - Qiitaの24日目の記事です。 昨日はSREの松嶋さんが「AWS RunCommandを使ってEC2上に監視ダッシュボードをサクッと作る（Ansible+Terraform+Grafana編）」という記事を書いてくれましたので是非そちらも読んでみてください！ tech.dely.jp コマース事業部では、現在「事業開発」と「ソフトウェア開発」がほぼ同時に進行しており、プロジェクトにおける確定要素と不確定要素が複雑に絡み合っています。 スピード重視でゴリゴリ実装していくのも興奮しますが、変化に耐えづらい実装をしてしまうと、その後の開発スピードに影響していまい、事業のスピードが落ちるなんて事にもなりかねません
DMM meetupは、多種多様な生命が彩るジャングルのように毎回個性豊かなさまざまなテーマを題材に、共に学び、遊び、楽しめるイベントです。今回はオンラインサロン事業に焦点をあて、事業部メンバーが課題と取り組みについて話しました。大門弘明氏からは、React NativeからSwiftへの移行について発表がありました。 React Nativeの負債化でアプリのSwift化が決定 大門弘明氏：それでは「React Nativeで書かれたアプリをSwiftで書き直しています」の発表を始めます。 まずは自己紹介をします。名前は大門と申します。2014年に新卒で合同会社DMM.comに入社して、iOSエンジニアとしてオンラインサロン事業部でお仕事をしています。 本日お話しすることですが、つらい気持ちの話と、アプリ設計の紹介を少ししようと思っています。僕にとってReact Nativeはつらい。
今年も GitHub のトレンドで 2021 年の JavaScript/TypeScript を振り返ります。去年の記事はこちらです。 — GitHub のトレンドで振り返る 2020 年の JavaScript | WEB EGG 集計方法 GitHub トレンドは過去の履歴を公式に提供していないため、非公式に集計されたデータを利用しています。 データソースはlarsbijl/trending_archiveを使用 去年はxiaobaiha/github-trending-historyを利用したが今年のデータは無かったので変更 日ごとにまとめた markdown になっており、remark で AST→ データ化しました 集計期間は 2021/01/01 から 2021/12/15 まで 対象言語はJavaScriptとTypeScriptのみ 集計後のデータはこちらのスプレッドシー
Mackerel のフロントエンド "React化" プロジェクトを支える技術と設計 - Hatena Developer Blog
こんにちは, Mackerel 開発チーム アプリケーションエンジニアの id:susisu です. 現在 Mackerel では, Web コンソール画面の開発に使用しているフレームワークを, これまで使用してきた AngularJS から React へ移行することを中心とした, フロントエンド開発の刷新プロジェクトを行っています. このプロジェクトの立ち上げについては以前 Hatena Engineer Seminar で発表しましたが, そこでは時間の都合もあり, 技術的側面についてはあまり深く掘り下げることは出来ませんでした. ということでこの記事では, より技術的な面にフォーカスしてプロジェクトの内容をご紹介できればと思います. "React化" プロジェクトについて Mackerel の開発は 2014 年ごろから始まりましたが, フロントエンドのフレームワークとしては当初か
フロントエンドを Vue.js から React にリプレイスしたお話 (前編) - NTT Communications Engineers' Blog
はじめての方、はじめまして。久しぶりの方、お久しぶりです。 イノベーションセンターの何縫ねの。(@nenoMake)です。 普段の業務ではソフトウェアエンジニアとして Node-AI という WEB アプリケーションの開発をしています。 パブリックな活動としては、好きな言語である C# 関係の OSS 開発や技術ブログの投稿、登壇などをしています。 ですが、今回は C# ではなくフロントエンドのお話をします...! この記事では今まで Vue.js 2.x で開発されていた Node-AI の WEB フロントを完全に捨て去り、React にリプレイスしたお話をつらつらとしていきます。 まずは前編ということで、リプレイスプロジェクト発足時の課題感からはじめ、プロジェクトの進め方や選定技術などについてお話しします。 後編には内部の設計などのより技術的なお話をしたいと思います。では前編スタート
Clean Architectureなにもわからないけど実例を晒して人類に貢献したい - エムスリーテックブログ
こんにちは、エムスリーエンジニアリンググループの福林 (@fukubaya) です。 これまでは、中村の記事で宣言した 「医師版Stack Overflow」(12/16に正式名称Docpediaとしてリリースされました) の技術的チャレンジの 記事を続けて書いていたのですが、今回はここで宣言しなかったClean Architectureについて書きます。 浪江駅（なみええき）は、福島県双葉郡浪江町にある、東日本旅客鉄道（JR東日本）常磐線の駅。本文には特に関係ありません。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ) 作者:Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ,角 征典,高木 正弘出版社/メーカー: ドワンゴ発売日: 2018/08/01メディア: Kindle版 なぜ書くのか 参考にできる実例を増やしたい Tech Blogはそのままドキュメ
David Bryant Copelandさんが書いた、Railsについてのこだわりの詰まった本。 takahasimさんも『Sustainable Web Development with Ruby on Rails』はRails使ってるなら絶対面白いと思うと言っていたように、面白い。これまでRailsを使ってきた中で、楽しいこともつらいことも沢山あったんだろう。そういうことが感じ取れるような話が展開されている。 幾つかの気になった話題を拾い上げて、自分の感想を述べていきたい。気になる話題は100個ぐらいあるが、がんばって10個ぐらいに留めたい。 Don’t Create Custom Actions, Create More Resources Railsが提供する7種類のアクション名以外使うな、必要なら新しくリソースをつくれ、という主張。つまりDHHはどのようにRailsのコントロー
まえがき アクセシビリティーの観点からWebサイトを診断し、AIプラットフォームを利用して得た情報をもとにベストプラクティスを提案してくれるオープンソースのWebサービス「Visible」を開発しました。 WebサイトURL: https://visi.dev GitHubリポジトリ（Starください！）: https://github.com/visible/visible GoogleのLighthouseなど、Webサイトの診断を行ってくれるサービスは以前からありましたが、診断だけではなく改善点の提案も行う新しいサービスになっています。また、アクセシビリティーに関する理解を深めてもらえるように工夫をした設計にしていたり、コマンドライン版ではスタンドアロンで実行可能なようになっています。 2020年度の「独創的アイデアと卓越した技術を持つ小中高生クリエータ支援プログラム」未踏ジュニアに
はじめに 最近巷で話題のGoらしさって話があると思いますが、 ここはあえてGoらしからぬClean ArchitectureをGoで学んでいこうという記事です。 対象 Go言語をある程度読めて、Clean Architectureに興味がある方 注意 ここでいうClean Architectureとは、依存性のルールに従った円を指しています。 Clean Architectureを採用しましょうって話ではありません。 各言語には思想があるので、その言語らしい書き方に沿うべきだと思っています。 ざっくりとしたアーキテクチャの目的 システムの関心の分離を行い、選択肢を残す(決定を遅らせる)ことが目的です。 またユースケースを中心として開発するため、フレームワークやツールに依存しません。 Clean Architectureとは Robert Martin がブログで提唱したアーキテクチャの解説
DIP(依存性逆転の原則)を守っていない話
一昨日くらいに 「DIP してもどうせ辛くなるよね」的なことを適当にツイートしたら引用 RT や RT 後言及やエアリプで言及された上に「こいつは設計を何も理解しとらん」みたいなことを言われた。「俺は本当に何も理解していないのか？」と不安になったので、自分の考えをちゃんと書いておこうと思った。先に自分の立場を言うと、なんたらアーキテクチャとか SOLID 原則は有用だし自分も使うが、それを厳守しようとは思っていないと言う立場だ。 DIP とはなんだったか DIP(依存性逆転の原則)は SOLID 原則の一つで、一言で言うと「抽象に依存させると依存関係が逆転する」といったものだ。何のことやらという風になるので例だけ挙げると、UserRepository と UserService があってこのように定義すると class UserRepository { get() { return dat
【Redux-Toolkit】Reactの状態管理ライブラリ基礎学習 ~第二部~ - RAKUS Developers Blog | ラクス エンジニアブログ
こんにちは！ラクス入社1年目のkoki_matsuraです。 本日は、Redux-Toolkitの基本的な状態管理や仕組みをTodoアプリ作成を通して、ご紹介させていただきます。 こちらの記事は「Reactの状態管理ライブラリ基礎学習」の2部目です。 前回の「Redux編」を読んでいない方は下記のリンクからお読みいただけると嬉しいです。 Reduxの仕組みを知ることでよりRedux-Toolkitの使いやすさが理解できると思います。 tech-blog.rakus.co.jp Reactの状態管理ライブラリを勉強している方、状態管理ライブラリについて簡単に知りたい方などのお役に立てればなと書かせていただきました。 アジェンダは以下の通りです。 Redux-Toolkitとは 概要 構成図 Todoアプリ作成 仕様説明 プロジェクト作成 初期設定 ディレクトリ構成 Todo型の定義 Slic
はじめにmicroCMSの大西です。microCMSには2022年の5月に入社しました。普段は開発本部長として組織的な業務、エンジニアのサポート、開発全体の大まかなタスクの方向性を決めといった業務を行なっています。 microCMSでは昨年中盤以降にWebフロントエンドの設計パターンを刷新しました。採用した設計パターンはクリーンアーキテクチャです。 2回に分けて大西と森茂（フロントエンドテックリード）がmicroCMSのWebフロントエンドの設計パターンについて紹介します。 前提としてmicroCMSのフロントエンドはReact、状態管理にはuseState/useContextを使用しています。APIのキャッシュにReact Query（TanStack Query）を使用しています。比較的素朴な設計になっています。 背景と課題microCMSはサービス開始から数年が経過しており、バック
■ クリーンアーキテクチャって難しい。 クリーンアーキテクチャって難しいですよね。 この有名な同心円状の図、何度見てもよくわかりません。右下にある矢印もよくわかりません。 様々な記事を見ても、やっぱり分かるような分からないような... プロダクトに COM 通信が必要になったので勇んでクリーンアーキテクチャを採用したはいいものの、 どうにも理解しきれず泣きながら必死に試行錯誤をしていたところ、 ふと クリーンアーキテクチャは『鎖国』に例えると分かりやすい という事に気が付きました。 本記事では初心者なりにその言語化にチャレンジしてみたいと思います。 ※ なお考え方そのものに着目するため、コードは全く取り扱いません。その点ご了承ください。 またクリーンアーキテクチャは、表面的なメリット(ユニットテストしやすい等) だけを見て批判されてしまうことも有るようです。 その辺りについても少し触れてみ
React Componentの実装ルールを決めてみた - Money Forward Developers Blog
こんにちは。 経費精算サービス「マネーフォワード クラウド経費」の開発チームでフロントエンドエンジニアをしている坂本です。 クラウド経費ではJSのライブラリとしてReactを採用しているのですが、最近クラウド経費で React Component を実装する際のルールをまとめたので、その話を書こうと思います。 なぜルールをまとめようと思ったのか Componentの分割ルールとしてAtomic Design、スタイルの管理としてstyled-components、GraphQL用のライブラリとしてApollo Clientを導入し実装を進めています。 昨年の10月までは挙げた３つとも使用していなかったので、試行錯誤しながら進めています。 チームメンバーの各々が試行錯誤しながら実装を進めていくので、最近はチーム内で認識の齟齬や持っている情報に差が出るようになりました。 そこで一旦現状を整理し
Clean Architectureを採用したBackend For Frontendの開発とこれまでの所感 - LIFULL Creators Blog
こんにちは。テクノロジー本部のyoshikawaです。好きなLinux DistributionはManjaro Linuxです。 今回はレガシー化が進むLIFULLのメインサービスの開発効率の向上とコードベースの健全性の確保をすべく、Clean Architectureを採用しバックエンドを刷新している取り組みについて紹介させていただきます。 なお、Clean Architecture自体の説明および解説は本記事では行いません。 背景：歴史あるバックエンドの刷新 アプローチ：新たなアーキテクチャと共創 採用したアーキテクチャ・技術 Clean Architectureを採用した理由 TypeScriptを採用した理由 LoopBackを採用した理由 Clean Architectureの実践 レイヤー分け：例の図と新BFFアーキテクチャのレイヤーとのマッピング レイヤー内・レイヤー間：独
ゲーム開発 に所謂なアプリケーション設計パターンをおいそれと適用するのは難しい - @hadashiA
アドベントカレンダーでもなんでもない記事 0日目です。 Unityで長らくゲーム開発をやっているけれど、Web界隈などで色々と発達しているアプリケーション設計パターンをおいそれと持ち込めば良いわけではないと感じているので、それについて考えてみようと思う。 ここでいう設計パターンていうのは、たとえばUIとかをつくるフレームワークの競争で発達してきた MVC派生 や ReactとかのElmアーキテクチャに影響を受けたものたち、はたまた、Webサーバ(HTTPサーバ) を書くときに 「良し」とされている 、DDD的な考え方の上での、抽象レイヤと実装レイヤの分け方を教条化するクリーンアーキテキクチャとかなんかそういうの。 追記: ゲームでも「ドメインロジックとプレゼンテーションの分離」はした方が良いと思っている。全体としては狭義でのMVPとかは自分もやってる。 こういった者達は、先人のアイデアや言
はじめに CastingONEでバックエンドエンジニアをやっている清水です。 この記事ではクリーンアーキテクチャについて学んだけど具体的にどのように実装すれば良いのかという悩みがあったので実装例をまとめてみた記事になります。 クリーンアーキテクチャで実装されたサンプル実装のうちGitHubのスター数が多いリポジトリをピックアップして、設計内容を紹介していきます。 具体的にどこにどんな実装をするべきなのかも含めて紹介していきます。 処理を一部省略して紹介するため実際の処理内容を確認したい場合はGitHubでご確認お願いします。 クリーンアーキテクチャとは クリーンアーキテクチャは、ソフトウェア設計の原則を適用して、依存性の方向性を逆転させ、ビジネスロジックから詳細（フレームワークやデータベース）を分離するアーキテクチャパターンです。これにより、テストしやすく、メンテナンス性が高く、柔軟性のあ
こんにちは。ミラティブUnityエンジニアの菅谷(tetsujp84)です。 今回はミラティブのライブゲーム開発で行ったアウトゲームの設計について紹介します。 以前アウトゲーム設計に関してXでポストしたらレスポンスをいただけたのでできるだけ丁寧に解説してみました。こんな話も聞きたいよというのがあったら是非教えてください。 よくありそうなソシャゲアウトゲームの設計について今更記事化してるんだけどどれだけ需要あるんだろう。MVPの概念とかクリーンアーキテクチャライクな知識って業界的な浸透率どんなもんなんだ。— 鉄 -TETSU- (@tetsujp84) 2023年8月28日 アウトゲームについて ゲーム開発者にとっては馴染み深いと思いますが、ゲームにはインゲームと呼ばれる部分とアウトゲームと呼ばれる部分に別れます。インゲームはゲーム体験のコアでキャラクターを操作したり、アクションがあったりと
C#でテキストエディタエンジンをフルスクラッチで実装してWebAssemblyで動かした話 - Qiita
デモ 以下のリンクから試せます。 https://crash.jp/apps/crash-editor/ 未圧縮版（5MB） https://crash.jp/apps/crash-editor-br/ Brotli圧縮版（2.1MB） 環境によっては表示まで数秒かかります。二回目以降はキャッシュから読み込まれるので、表示に時間はかかりません。 キャッシュはブラウザの開発ツールから削除可能です。以下はChromeの場合。 開発ツール > Applicationタブ > Cache > Cache Storage ※デモを何度か上げなおしているので、エラーになる場合にはキャッシュを削除してみてください 動作環境 WebAssemblyに対応したブラウザが必要ですが、最近のブラウザであればまず問題ないです。 自分で確認した環境 Windows 10 Pro, Chrome/新Edge/Fire
今回はアプリケーションアーキテクチャを学ぶ最初の一歩として、「MVC」や「3 層アーキテクチャ」などの基本的な用語の意味や関係性を整理する「改めて整理するアプリケーション設計の基本」。ここで大嶋氏が登壇。まずは本セッションの内容について説明します。 大嶋氏の自己紹介 大嶋勇樹氏：では、「改めて整理するアプリケーション設計の基本」ということでお話しします。（スライドを示して）最初に私の自己紹介ですが、名前は大嶋勇樹と申します。最近はよく“しまさん”とか“しまちゃん”とか、そんなふうに呼ばれることが多いです。 キャリアは新卒で都内のあるIT企業に入って、その後フリーランスエンジニアとして独立して、今は会社を設立していろいろしています。今は実務に就き始めぐらいのエンジニアの方のスキルアップのサポートで、研修や勉強会、あと最近は「Udemy」講座をいくつか作ったりしています。 今日の発表に関連する
この記事は、ドワンゴ Advent Calendar 2020の4日目の記事です。 N予備校Androidチームでは、およそ2年かけて、Javaで書かれたコードのほとんどをKotlinに書き換えました。この記事では、コードをKotlinに書き換える上で必要だったことをまとめていきます。 Kotlin化に技術はそこまで必要ではない そもそもKotlin化をすることにそこまでの技術力は必要ないです。JavaとKotlinの互換性が高いので、Kotlin化によってコードが壊れることは少ないですし、以下のように文法にも大きな変化はないので、読めないコードが生まれることもありません。 Javaで作成したFragment public class SimpleFragment extends Fragment { @Override public View onCreateView(LayoutInf
こんにちは。クックパッド事業本部 買物サービス開発部の藤坂（@yujif_）です。 2020年10月にクックパッド iOS アプリで「買い物機能」をリリースしました。今回はこの新機能の開発にあたって考えたことや取り組みについてご紹介します。 買い物機能とは レシピから買い物へ 買い物からレシピへ 実は SwiftUI で作られている 技術選定の背景 1. 本番で早く検証し、サービス開発の効率を上げたい 実生活の中で使って発見を増やす UI の「作って壊し」をやりやすく 2. SwiftUI のリスクを抑えつつ導入できる見込みがあった クックパッド iOS アプリでは 2メジャーバージョンをサポート 機能・画面単位で切り分けやすいアーキテクチャ 【方針】View 層のみで SwiftUI を部分的に導入する 実装 既存のVIPER アーキテクチャへの SwiftUI の組み込み UIView
React Hook FormとZodを組み合わせて利用する｜食べログ フロントエンドエンジニアブログ
こんにちは。食べログ フロントエンドチームの原田です。 現在担当しているプロジェクトで、React Hook FormとZodを組み合わせて利用する機会があったので、今回はReact Hook Formの基本的な使い方からスキーマバリデーションをZodに任せる方法を紹介をしたいと思います。 React Hook FormとはReact Hook Form は「高性能で柔軟かつ拡張可能な使いやすいフォームバリデーションライブラリ」をテーマに掲げた入力フォームの管理に特化した React 向けのライブラリです。 なぜReact Hook Formを利用したか今回のプロジェクトでは複雑なフォームを組む必要があり、フォームの状態管理を任せられる点や、パフォーマンス面、ドキュメントや検索でヒットする情報の多さからReact Hook Formを利用することを決めました。 基本的な使い方まずはReac
この記事は個人ブログの内容がソースです。 kami-programming.com そもそもなぜクリーンアーキテクチャーを考察するのか DRY原則やSOLID原則などが浸透している昨今ですが、実際の開発現場のソースコードを読み込んでみると必ずしもこれらの原則に則していない場合は多いのではないでしょうか。 そして、そういった開発環境でいざコーディングをしていくと、以下のような問題に直面するのではないでしょうか。 あるバグの修正をしたのだが、同じロジックが他の場所でも書かれていたようで重複箇所のバグは依然としてバグったままだった。 あるクラスを変更したが、依存性の方向性や範囲が把握しきれておらず、変更の影響で新たなバグを生んでしまった。 ビジネスロジックの変更を迫られたが、同じロジックが重複しすぎており修正範囲を特定するだけで一苦労。 想定外の値の入力があり、バグが発生してしまった。 これらは
Unityを利用した大規模なゲーム開発にクリーンアーキテクチャを採用した話 - WonderPlanet Developers’ Blog
こんにちは、タノシムスタジオテックリードの吉谷です。タノシムスタジオでは2011年ごろからクライアントアプリケーションの開発にUnityを利用し始め、いろいろ試行錯誤をつづけた結果、現在ではクリーンアーキテクチャの考え方を取り入れています。 今回は、Unityを利用したゲーム開発にクリーンアーキテクチャを適用した例として、導入理由、具体的な構成、実際に感じたメリット、デメリットなどを紹介したいと思います。 クリーンアーキテクチャとは クリーンアーキテクチャはRobert C. Martin氏が自身のブログにて発表した、すべてのソフトウェアアーキテクチャが守るべき考え方やアプローチがまとめられた概念です。以下のような同心円状の図で説明されることが多いかと思います。 出典： The Clean Architecture クリーンアーキテクチャの説明自体は、検索していただければ優れた記事や書籍な
レガシーなフロントエンド環境をリプレースするためにチームでやっていること｜食べログ フロントエンドエンジニアブログ
はじめに はじめまして！食べログFE（フロントエンド）チームの金野と申します。 普段は、食べログフロントエンドの設計・開発や、新規事業・食べログテイクアウトの技術サポートなどを行っています。 食べログテイクアウトについては、Nuxt.js + TypeScriptの開発について記事を書いているので、興味がある方はぜひ御覧ください。 さて、以前の記事でご紹介したように、食べログFEチームではレガシーシステムのリプレースをReact/TypeScriptで行っています。 今回は、新しいシステムについてもう少し詳しい技術スタックや、どのようなプロセスで開発しているのかを紹介します。 開発効率化のための取り組みリプレースのお仕事はただひたすら実装するだけではありません。 「壊れにくいアプリケーション」「メンテナビリティが高いアプリケーション」にするために、アーキテクチャや採用する周辺技術について、
弁護士ドットコムライブラリーのフロントエンドのアーキテクチャ（Next.js + TypeScript） - パンダのプログラミングブログ
弁護士ドットコムライブラリーのフロントエンドのアーキテクチャを紹介します この記事は弁護士ドットコム Advent Calendar 2020、2日目の記事です。2020年12月に執筆された記事です。 私は弁護士ドットコムライブラリーというサービスを開発しています。これは法律書籍をネットで読める弁護士向けのサブスクリプションサービスです。 フロントエンドの採用技術はNext.js + TypeScriptで、要件定義から設計、実装は私が担当し、現在も運用しています。 この記事では、2020年5月にリリースしてから半年間、Next.jsで上記サービスを運用した知見の中から、フロントエンドでのアーキテクチャについてご紹介します。 弁護士ドットコムライブラリーの特徴は以下の通りです。 画面数は10画面ほどの中規模アプリケーション（OOUIの考え方を取り入れたら画面数が減りました） 基本的にバック
「Android Meetup」は、to C向けサービスを提供するGMOペパボ株式会社、株式会社ZOZOテクノロジーズ、株式会社サイバーエージェンがAndroid開発事情や、直近の取り組みについて発表をするイベントです。GMOペパボ株式会社の伊藤氏は、「minne byGMOペパボ」アプリケーション開発におけるアーキテクチャ選定について発表しました。 ハンドメイドマーケット「minne」アプリを担当 伊藤拓海氏（以下、伊藤）：「中～大規模アプリのminneはどうアーキテクチャを選定したか」ということで、GMOペパボの伊藤が発表したいと思います。よろしくお願いします。 まず軽く自己紹介します。伊藤といいます。よろしくお願いします。GMOペパボではパートナー（GMOインターネットグループに置ける従業員の呼称）同士をあだ名で呼び合う風習があります。僕は名前が拓海なので「tick-taku」と呼ば
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アプリケーションにおける権限設計の課題 - kenfdev’s blog
ソフトウェア設計についての原則や法則についてまとめてみた
VSCode + Markdownでスライドや書籍も書いちゃおう！ - Qiita
「3種類」で管理するReactのState戦略
~OSSから学ぶ~ MVCフレームワークの保守性がモリモリ上がるクラス設計 - dely Tech Blog
僕にとってReact Nativeは“つらい” DMMが負債脱却のために取り組んだSwift化
GitHubのトレンドで振り返る2021年のJavaScript/TypeScript
『Sustainable Web Development with Ruby on Rails』を読んだ
機械学習APIでWebサイトの改善点を提案するサービスを作った話 - Qiita
あえてGo言語でClean Architectureを学ぶ
microCMSのWebフロントエンドにクリーンアーキテクチャを採用した話【前編】
Clean Architecture の勘所は『鎖国』だ。 - Qiita
Go言語によるクリーンアーキテクチャの実装例紹介
ミラティブでのアウトゲーム設計の紹介 - Mirrativ Tech Blog
“1つの独立して動く要素”の内部を整理し直す 「改めて整理するアプリケーション設計の基本」で伝えたいこと
AndroidアプリのKotlin化をやり切るための腕力 - ドワンゴ教育サービス開発者ブログ
SwiftUI を活用した「レシピ」×「買い物」の新機能開発 - クックパッド開発者ブログ
Clean Architecture考察 - ROXX開発者ブログ
「minne」はなぜ「MVVM＋UseCase＋Repository」なのか 3つのアーキテクチャを選んだ5つの理由