並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 53件

新着順 人気順

cleanarchitectureの検索結果1 - 40 件 / 53件

  • クリーンアーキテクチャ完全に理解した

    clean_architecture.md 2020/5/31追記: 自分用のメモに書いていたつもりだったのですが、たくさんのスターを頂けてとても嬉しいです。 と同時に、書きかけで中途半端な状態のドキュメントをご覧いただくことになっており、大変心苦しく思っています。 このドキュメントを完成させるために、今後以下のような更新を予定しています。 TODO部分を埋める 書籍を基にした理論・原則パートと、実装例パートを分割 現在は4層のレイヤそれぞれごとに原則の確認→実装時の課題リスト→実装例という構成ですが、同じリポジトリへの言及箇所がバラバラになってしまう問題がありました。更新後は、実装時の課題リストを全て洗い出した後にまとめて実装を確認する構成とする予定です。 2021/1/22追記: パートの分割と、クリーンアーキテクチャという概念の定義について追記を行いました。大部分の実装例パートを中心

      クリーンアーキテクチャ完全に理解した
    • ソースコードで理解するクリーンアーキテクチャ - Sansan Tech Blog

      はじめに こんにちは。プロダクト開発部の荒川です。 これまで最年少を謳っていましたが、ついに新卒の子にその座を奪われてしまいました。とても残念です。 さて今回のテーマは、皆さんお馴染みクリーンアーキテクチャ(Clean Architecture)です。 クリーンアーキテクチャは一時期流行し、その流れに乗って私もある程度の理解はしていました。 しかし、それはあくまでも感覚的な理解であって、他人に説明や良さを語れるレベルまで自分の中で落としこめていませんでした。 そこでより具体性のあるソースコードを読み込むことで、アーキテクチャへの理解を深めたいと思います。 クリーンアーキテクチャとは? クリーンアーキテクチャの定義や解説に関しては、ネット上にいくらでも公開されているので、このエントリでは詳しく話しません。 私自身が勉強に使った書籍やサイトを記事末尾の「参照」に掲載しているので、そちらを参考に

        ソースコードで理解するクリーンアーキテクチャ - Sansan Tech Blog
      • ご主人様、小難しいDDDやクリーンアーキテクチャはお忘れになって、”削除しやすい設計”から始められてはいかが? - Qiita

        ご主人様、小難しいDDDやクリーンアーキテクチャはお忘れになって、”削除しやすい設計”から始められてはいかが?LaravelDDD設計アーキテクチャCleanArchitecture ある日夢の中で設計に詳しい悪役令嬢が現れてこんなことを言い放ったので、考察してみましたという設定のポエムです。 問題提起 ドメイン駆動設計、オニオンアーキテクチャ、クリーンアーキテクチャといった考え方はもちろん重要なものの、僕は難しく考えずに「削除しやすいように機能を作る」のが第一歩として重要ではないかと考えています。 本記事では「削除しやすい設計」について持論を展開してみます。 ※議論のスコープはWebサービスに限定し、例示としてPHPのフレームワークであるLaravelを用います 削除しやすいことがなぜ重要か 一度開発した機能は、それで終わりではなく、改修、改善を繰り返し、そして場合によっては仕様が廃止さ

          ご主人様、小難しいDDDやクリーンアーキテクチャはお忘れになって、”削除しやすい設計”から始められてはいかが? - Qiita
        • 私がC#の勉強のために必ずクローンしているGitHubリポジトリを紹介します - Alternative Architecture DOJO

          こんにちは。MLBお兄さんこと松村です。 今回は私がPCに必ずgit cloneしているC#系のGitHubリポジトリを紹介します。 どういったリポジトリであるか、リポジトリをクローンしている目的も併せて書いてみます。 とりあえず詳細はいいから、どんなリポジトリがあるか知りたい方はこちらをご覧ください。 gist.github.com それでは列挙していきます。(アルファベット順です) 常にクローンするもの dotnet-presentations/aspnetcore-app-workshop github.com ASP.NET Core 2.2でSPAのWebアプリケーションを作るワークショップです。 dotnet-presentations/aspnetcore-concepts-workshop github.com 前述の dotnet-presentations/aspnet

            私がC#の勉強のために必ずクローンしているGitHubリポジトリを紹介します - Alternative Architecture DOJO
          • 継続的ドキュメンテーション: Github DiscussionsとADRのすすめ - LIFULL Creators Blog

            こんにちは。テクノロジー本部のyoshikawaです。好きなW3C Recommendation は RDF 1.1 Concepts and Abstract Syntax です。 会議やチャットでのやり取りの決定事項・議事録、アプリケーションや機能の設計書・仕様書、READMEなどなど... LIFULLの開発現場においては、ソースコード以外にもこのように様々な文書の管理・蓄積(=ドキュメンテーション)を実施しています。 多くの開発者・メンバーがドキュメンテーションの重要性やその恩恵は理解はしているものの、なかなかうまく情報の蓄積・管理ができない、 その結果、本質的ではない調査に時間を取られてしまいDeveloper Experienceが下落してしまう。 このような課題を抱えているプロジェクトやチームは世の開発現場において少なからず存在すると思います。 LIFULLの開発現場にもこの

              継続的ドキュメンテーション: Github DiscussionsとADRのすすめ - LIFULL Creators Blog
            • マイクロサービスでチームを分離したくないマン - まっちゅーのチラ裏

              コンウェイの法則とかで、マイクロサービス=組織 という話になることが多いなと感じる。 正解の場合もあるし、不正解の場合もあると思っていて、個人的には小さいチームでもマイクロサービスをやるメリットは技術的にも組織的にもあると思う。 そのメリットを無視してすぐ組織の話に持っていきたくないので、基本分離したくないマンとしての主張を書いておく 技術観点でのメリット いまさら語るまでもないけど、 ドメイン境界の分離 デプロイ独立性 リソースの最適配分 障害の局所化(サーキットブレーカー等) このうち、ドメイン境界の分離だけはモジュラモノリスで対応可能だが、あとの3つにはマイクロサービスが必須。(もっとあるかも) この3つが必要なのにモノリス or モジュラモノリス で進める判断をするということはシステムの表現力を落とすことに直結する。 もちろん、複雑度は増すし難易度も増す。熟練のサーバーサイドエンジ

                マイクロサービスでチームを分離したくないマン - まっちゅーのチラ裏
              • 和田 卓人さん(t_wadaさん)に「予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント」を社内で講演いただきました! | Wantedly Engineer Blog

                こんにちは、ウォンテッドリーDev Branch VPoE 室長の髙橋です。 ウォンテッドリーの開発組織であるDev Branchでは、外部から有識者を招いて勉強会を開催したり、技術顧問として知見を取り入れるなど、プロダクト開発により強い組織となるためにさまざまな施策を行っています。 今回、「テスト書いてないとかお前それ @t_wada の前でも同じ事言えんの」 でおなじみのt_wadaさん(和田 卓人さん、以下和田さん)に「予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント」をウォンテッドリー向けにカスタマイズして講演いただきました。 このストーリーでは、今回の講演の経緯から社内の反応・Q&Aまで、講演に関する詳細をご紹介いたします。 社内講演のきっかけ事の発端は、弊社のVPoEである要(X : @nory_kaname)より、外部エンジニアを招いて勉強会を開催する旨の問いかけ

                  和田 卓人さん(t_wadaさん)に「予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント」を社内で講演いただきました! | Wantedly Engineer Blog
                • ヤフーのクリエイターが読んでいる技術・デザイン書 〜 技術活動費用補助制度のデータから見る興味関心

                  ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、Developer Relations アドボケイトの山本です。 ヤフーにはエンジニアやデザイナーといったクリエイターの活動を支援する制度「My Polaris」があり、その中の1つにクリエイターが常に自身の技術力向上を図れるよう学習活動を支援するための「技術活動費用補助制度」というものがあります。 本記事ではこの制度の紹介と、この制度の活用状況のデータを集計してヤフーのクリエイターの興味関心を可視化します。 技術活動費用補助制度とは? 冒頭でも触れましたが、エンジニアやデザイナーといったクリエイターの学習活動を支援する制度で、半年間で6万円を上限に、書籍、アプリ、デバイスなどの購入、セミナーや勉強会への参加、英語学習

                    ヤフーのクリエイターが読んでいる技術・デザイン書 〜 技術活動費用補助制度のデータから見る興味関心
                  • RDBの主キー、UUID使った方がいいの?(DDD, CleanArchitecture対応)

                    結論 お手軽モノリスならAutoIncrementが効率的だしこれでいいよ アプリケーション側で主キーを生成したい場合はLUIDを作る必要があるよ。GUIDで大は小を兼ねよう 主キーでGUIDを使うならULIDよりもUUIDv7がおすすめだよ ただし分散されているエンジンによってはUUIDv4の方が効率的になる場合もあるよ 主キーは原則公開しない方がいいよ UUIDv7やULIDはユニーク性を持ったInstant(timestamp)としても使えるよ 分散されたシステムでは厳密な時系列性を担保することはできないよ、あきらめてロックをかけつつ連番を一か所で生成しよう RDBのPrimary Key(主キー)とは? MySQL、PostgresQLなどのRDBでは各レコードを識別するために一意な値を必要とします。これをPrimary Key(主キー)と呼びます。別のカラムにUNIQUEなInd

                      RDBの主キー、UUID使った方がいいの?(DDD, CleanArchitecture対応)
                    • 社内勉強会でOOPとCleanArchitectureとDDDを勉強し始めたというお話

                      BASE, Inc. で社内勉強会を開くときに考えた、僕らの学習アプローチと勉強会設計について話しました。

                        社内勉強会でOOPとCleanArchitectureとDDDを勉強し始めたというお話
                      • Clean Architecture の勘所は『鎖国』だ。 - Qiita

                        ■ クリーンアーキテクチャって難しい。 クリーンアーキテクチャって難しいですよね。 この有名な同心円状の図、何度見てもよくわかりません。右下にある矢印もよくわかりません。 様々な記事を見ても、やっぱり分かるような分からないような... プロダクトに COM 通信が必要になったので勇んでクリーンアーキテクチャを採用したはいいものの、 どうにも理解しきれず泣きながら必死に試行錯誤をしていたところ、 ふと クリーンアーキテクチャは『鎖国』に例えると分かりやすい という事に気が付きました。 本記事では初心者なりにその言語化にチャレンジしてみたいと思います。 ※ なお考え方そのものに着目するため、コードは全く取り扱いません。その点ご了承ください。 またクリーンアーキテクチャは、表面的なメリット(ユニットテストしやすい等) だけを見て批判されてしまうことも有るようです。 その辺りについても少し触れてみ

                          Clean Architecture の勘所は『鎖国』だ。 - Qiita
                        • モノリスなRailsにモジュラーモノリスを導入した話 - hacomono TECH BLOG

                          こんにちは、プラットフォームチーム所属のまこたすです。 昨今、様々な場で「モジュラーモノリスを導入した」という話を目にするようになってきました。弊社でも昨年からモジュラーモノリスの試験導入を進めており、社内でノウハウが徐々に溜まってきたため、今回 技術ブログ で なぜ導入したのかと知見の共有 をさせていただけたらと思います。 想定読者 モノリスなアプリケーションの分割を検討している Railsへのモジュラーモノリスの導入を検討している 話さないこと チーム体制がどうあるべきかという観点の話 以下アーキテクチャについての詳細 モノリスアーキテクチャ モジュラーアーキテクチャ 背景 今回「モジュラーモノリスを導入した」というタイトルですが、最初に検討・導入に至るまでの背景について触れたいと思います。 hacomonoという組織・サービスの成長 hacomonoというサービスはリリースから現在に

                            モノリスなRailsにモジュラーモノリスを導入した話 - hacomono TECH BLOG
                          • めっちゃ需要あるのにAndroidエンジニアが足りてないらしいから魅力とか紹介する回(配信用カンペ) - Qiita

                            自己紹介 バーチャル幼女プログラマーのきりみんちゃんです フリーランスのAndroidアプリ開発エンジニアをやってます YouTubeチャンネル(音量注意):https://www.youtube.com/channel/UCqN87Ye4TNLB04EFhxJ0L5w 今日のおはなし Androidエンジニアが足りてないらしいよ!! 需要はめっちゃあって観測範囲だとわりとどこの会社もAndroidエンジニア探してる印象 特に足りてないのはわりと勉強会とかブログとかで積極的にアウトプットしたりするような意欲の高いタイプの人 当分はかなり需要が供給を上回る感じなので転職有利だと思うし、やる気があれば新人でも育ててもらえるかもしれない 今だとお給料も高めだと思う 原因考察 開発されるアプリの規模や要求される品質は上がり続けてて需要は増えている ぶっちゃけあんまり若い層が育っていないような 勉強

                              めっちゃ需要あるのにAndroidエンジニアが足りてないらしいから魅力とか紹介する回(配信用カンペ) - Qiita
                            • GolangらしいPackage構成を考える/thinking about Golang-like package architecture

                              DesignOneGo#6 のLT発表資料です Webアプリケーション設計からGolangらしいPackage構成を考えたものです。 CleanArchitectureを参考に考えた独自設計を元に - レイヤーでのPackage構成 - レイヤー×Re-ducks思想を織り交ぜたPackage構成 について考察しています。 P.S. 簡易的に作成したものなので、 今後この内容を詳しくした設計サンプル資料を作成したい...!

                                GolangらしいPackage構成を考える/thinking about Golang-like package architecture
                              • 再考 - ドメインサービス  - まっちゅーのチラ裏

                                自分が大規模システムで組むアーキテクチャは基本的にはCleanArchitectureを踏襲しているが、その中の構成要素であるドメインサービスだけは少し独自(?)の解釈をしていて、書籍などでよく見る ビジネスロジックを持つが、状態をもたない 複数の集約にまたがる処理を書く場所 という責務の他に、外部システムへの委譲処理だったり、共通UseCaseのような責務も持たせている。 これは、自分が「xxService」という命名にトラウマがあり(何でも置き場になりがち)、単なるServiceだとコントローラやらプレゼンターやら、どこから呼ばれても違和感がない様に見えてしまうから、とりあえずDomeinServiceへ寄せている経緯がある。 ※ここで語るのは、あくまで大規模想定で、小さいシステムならこんな事を意識する必要はないはず。 ※あくまで自分の考えで、一般的ではない可能性があることをご了承くだ

                                  再考 - ドメインサービス  - まっちゅーのチラ裏
                                • ノーコードAI開発ツールNode-AIの紹介 - NTT Communications Engineers' Blog

                                  はじめに 初めまして!イノベーションセンターでノーコードAI開発ツール「Node-AI」のプロダクトオーナーやXAI・因果分析の研究をしております、切通恵介(@kirikei)です。 Node-AIは2021年10月11日にリリースされたNTT Communicationsの内製開発サービスで、その名の通りブラウザ上からノーコードでAIモデルを開発できるサービスで、製造業のお客様を中心に異常検知やプラント運転支援などの様々な領域で活用されています。(ニュースリリースはこちらやこちらやこちら) いつもはサービスの営業的な紹介をすることが多いのですが、今回はEngineer's Blogでの執筆ということで、エンジニアの方向けの技術、プロダクトマネジメント、チームビルディング、スクラムなどの様々な観点でお伝えできればと考えています。とはいえ、Node-AIに関しては詳細に書きたいことが山ほどあ

                                    ノーコードAI開発ツールNode-AIの紹介 - NTT Communications Engineers' Blog
                                  • 1年前までプログラミング初心者だった人間が爆速でアプリリリースしたのでノウハウをまとめてみた - Qiita

                                    目次 -対象者 -簡単な自己紹介 -アプリ紹介 -開発テーマ -アイデア出し -市場調査 -アプリ開発で意識した事 -開発過程 -デザイン -工数期間 -技術的に意識した事 -開発環境 -ライブラリ -ライブラリ管理ツール -CI/CDツール -ソースコード管理 -タスク管理 -アーキテクチャ -運用 -参考書籍 -個人開発参考リンク -最後に -(余談)今まで作成したアプリ紹介 対象者 アプリ開発に興味がある方 エンジニアを目指したい方 駆け出しエンジニアの方 簡単な自己紹介 今年1月から未経験としてエンジニア採用して頂き、開発会社で働いています。 プログラミング自体は2018年1月から本格的に開始し、それまではずっと営業をしてました。 当時のパソコンスキルは完全素人です。Youtube視聴とWord以外本当に使った事が無く、ファイルの意味も分かりませんでした。 そんな自分がアプリ開発を

                                      1年前までプログラミング初心者だった人間が爆速でアプリリリースしたのでノウハウをまとめてみた - Qiita
                                    • 環境のモダン化で、サービスに集中して開発ができている話

                                      ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは。ヤフーでワイキューを開発している石井、松本です。 今回はワイキューの開発の流れを追いながら、ヤフーのもつプラットフォームを利用した開発スタイルの紹介をします。 ワイキューとは? 賞金山分け型のエンタメライブ番組です。毎日21時から配信しており、全問正解した人で賞金を山分けできます。 問題のジャンルが幅広いのが特徴で、クイズだけでなく、間違い探しや多数決などもあり、 毎晩芸能人や YouTuber などをゲストに呼んでワイワイ楽しい番組を作っています。 ワイキューを取り巻く技術 そんなワイキューですが、いろいろな技術を組み合わせてサービス提供しています。 (カッコ内は利用している特徴的な技術やフレームワーク) 数千ユーザ

                                        環境のモダン化で、サービスに集中して開発ができている話
                                      • ミラティブ エンジニアチーム四季報(創刊号) - Mirrativ Tech Blog

                                        こんにちは Mirrativ CTOの夏です。 現在、ミラティブでは事業部単位でチームや目標を管理しており、エンジニアが所属するチームとして以下の6つがあります。今回はこのうち、エンジニアチームについて、2019年度に行ってきた取り組みの振り返りをしたいと思います。 ライブプラットフォームチーム ユーザの定着を追う マーケ連携チーム ユーザの新規獲得を追う エモモチーム 3Dアバターであるエモモを使った新体験の創出・基礎体験の向上を追う ストリーミング改善チーム モバイル端末でのライブストリーミングの配信・視聴の品質改善を追う インフラチーム クラウド上での安定したインフラ基盤の設計・構築を追う エンジニアチーム お問い合わせ調査、不具合・障害の再発防止、開発体験の向上を追う AI技術部 コミュニティやストリーミングとAI活用の可能性を追う 毎週定例で振り返りを行っており、Confluen

                                          ミラティブ エンジニアチーム四季報(創刊号) - Mirrativ Tech Blog
                                        • 【SES】ドナドナされる時の面談時に地雷案件をなるべく避けるための確認ポイント7選(iOS/Androidアプリ開発) - Qiita

                                          私は、客先常駐でアプリを開発、保守するのをメインに5年ほどお仕事してきました。 iOSとAndroidのどちらかを担当して、機能やスケジュールの提案をしつつ、もくもくと開発していることが多いエンジニアです。 常駐のため、現場が変わるごとに面談があり(法律なんか知らん)、その度にやばそうな雰囲気の出てる案件は基本的に避けるようにしています。 現場に入る前の面談で、これを確認すれば、地雷案件を少し回避できるポイントがなんとなくわかってきたので、メモっておきます。 ※あくまで個人的な指標であって、なんの根拠もないです!! 保守案件の場合は、アプリのストア評価を確認 保守案件で、ストアの評価が低いアプリは可能な限り参画を回避します。 理由は、 ストアの評価が低いものは、内部の品質が基本的に低い 新たな開発はできずに、既存バグの修正に追われて疲弊する ただのバグ修正ではスキルがつきにくい クソコード

                                            【SES】ドナドナされる時の面談時に地雷案件をなるべく避けるための確認ポイント7選(iOS/Androidアプリ開発) - Qiita
                                          • サーバーサイド未経験の大学生が4日でGolang×CleanArchitectureのAPIを構築した話 - Qiita

                                            【追記:2019/9/17】 記事で誤りがあった部分を修正いたしました。 またサンプルも正しいものに修正しておりますので、是非ご確認ください。 【追記:2019/9/10】 コメントでもご指摘を頂いておりますが、一部誤った内容が含まれております。 すぐに修正に取り掛かりますが、内容の修正まで今しばらくお待ち頂けますようお願いいたします。🙇‍♂️ また、今回多くの方に誤った内容をお伝えしてしまったこと、深くお詫び致します。 (多くのいいねを頂いており、ストックに登録して頂いている方もいらっしゃると思いますので、非公開にせず修正又は内容の削除で対応致します。) 先日インターンでソシャゲ用のAPIを作った時に、サーバーサイド未経験ながらGolang&クリーンアーキテクチャ(的な)のAPIを構築しました。 特にインターンで用意されていた内容というわけではなく、個人の課題としてクリーンアーキテクチ

                                              サーバーサイド未経験の大学生が4日でGolang×CleanArchitectureのAPIを構築した話 - Qiita
                                            • 技術スペックを大公開〜no plan株式会社〜2023年からの取り組み - Qiita

                                              これはno plan inc.の Advent Calendar 2022の3日目の記事です。 どうも〜!no plan株式会社 代表のおかむーです。 この記事では弊社の2023年からの取り組み技術スペックについて書かせていただきます。 (この記事は2022年12月時点でのことなので、時代の流れによっては異なることが予想されますので、そのつもりで見ていただければと思います) no plan株式会社の創業メンバー 元面白法人カヤック アプリエンジニア: おかむー(@okamu_ro) 元面白法人カヤック サーバーサイドエンジニア: セリヌンティウス(@_serununtius) のエンジニア2名で起業した会社になります。 現在はフリーランスエンジニアさん10~15名程度でやっています!! no plan株式会社について no plan株式会社は、ブロックチェーン技術、Webサイト開発、ネイテ

                                                技術スペックを大公開〜no plan株式会社〜2023年からの取り組み - Qiita
                                              • Earthlyでコンテナ時代のビルド環境を味わう - Runner in the High

                                                【これはUnipos Advent Calendar 2021の2日目の記事です】 つい最近、EarthlyというDockerコンテナベースのビルドツールで、自分の開発しているGoのアプリケーションのMakefile/Dockerfile/docker-compose.yamlを置き換えたのでそれを記事にしてみる。 Earthlyとは github.com めちゃくちゃ雑に言うとDockerイメージをベースにしたビルドツール。 できることとしてはGoogleが作っているBazelに近い*1が、書き味はMakefile+Dockerfileに近く*2、独特の文法が少ない雰囲気。当然、言語やフレームワークに依存しない。まるでローカル環境でビルドをしているかのようにシームレスにコンテナ環境でビルドを実行できる。 Earthlyは書き味こそDockerfileと似ているが、Dockerイメージを作

                                                  Earthlyでコンテナ時代のビルド環境を味わう - Runner in the High
                                                • Serverless Microservices - Saga Transaction - Qiita

                                                  CloudNativeがここまで進化するとインスタンスの仮想化技術をベースとしたシステムなど使いたくなくなってしまいます。 私は新たにシステムを構築する際、必ずServerless Firstの考え方で設計をしていきます。 その中でAWS Lambda、Amazon DynamoDBを中心にMicroservicesの設計をしていくのですが、 ACIDの部分をどう対処するかが一番悩むところです。 今回はServeice間のTransactionに関する話を自分なりに整理していきたいと思います。 図1 Saga Design Pattern Sagaは複数のサービスにまたがるトランザクションを実装するためのマイクロサービスアーキテクチャパターンです。 複数のマイクロサービス間でデータ一貫性を実現するもので、Sagaには2つのパターンがあります。 1. Choreography-based S

                                                    Serverless Microservices - Saga Transaction - Qiita
                                                  • PythonでDI+モックを使いながら、Clean Architectureでアプリケーションを構築する - Qiita

                                                    PythonでDI+モックを使いながら、Clean Architectureでアプリケーションを構築するPythonFlaskDIPython3CleanArchitecture 業務でPythonを使ってウェブアプリケーションを実装する際、レイヤー毎に関心の分離を行いながら開発するために、Clean Architectureを導入することになりました。 チームメンバーへのナレッジ共有を兼ねて、漸進的型付けとDependency Injectionを用いながら、テスタビリティの伴ったアプリケーションを開発するためのプラクティスをまとめました。 今回はPythonを用いたサンプルを目的としているため、Clean Architectureの解説は簡易に済ませます。 (The Clean Architectureより引用) Clean Architectureはロバート・C・マーティンによって2

                                                      PythonでDI+モックを使いながら、Clean Architectureでアプリケーションを構築する - Qiita
                                                    • Clean Architecture for React:Archived Technologies

                                                      本書では、Clean Architecture の観点から、React や Redux で構築されたアプリケーションの設計をとらえなおし、また、ときには新たな設計の提案を行います。 いままでは Clean Architecture があまり取り入れられてこなかった Web フロントエンド領域に対して、この手法を適用することを目指します。 本書が、React アプリケーション設計のその一歩先に到るための一助になれば幸いです。 試し読み:https://note.com/imamori/n/n5a7ebdbd4260 また、BOOTH でも販売しています。下記のページから購入できます。 BOOTH:https://archived-tech.booth.pm/items/2399644 英語版:https://www.amazon.co.jp/dp/B09FG94392 目次: 第1章 Cle

                                                        Clean Architecture for React:Archived Technologies
                                                      • GoのDIツールwireで知っておくと良いこと - Carpe Diem

                                                        概要 christina04.hatenablog.com こういった設計のようにレイヤ間の依存関係を抽象化していると、DIの初期化処理が段々冗長になっていきます。 google/wireはそういったDIの初期化を自動的にやってくれるコード生成ツールです。 今回はwireを使う上で知っていると便利なところをまとめます。 環境 golang 1.13.5 wire 0.4.0 wireの使い方知らない人 以下のチュートリアルが非常に分かりやすいので一度やってみてください。 github.com 実務で知っておくと良いポイント Injectorの用意の手順 小さい依存関係であれば頭の中で把握できてサクッとかけますが、巨大なリポジトリになってくると何が何に依存しているか分からなくなってきます。 そういった場合まず最終的に用意するInjectorを生成するProviderだけwire.Buildす

                                                          GoのDIツールwireで知っておくと良いこと - Carpe Diem
                                                        • フロントエンドでClean Architectureを適用してみる(+サンプルコード) - Qiita

                                                          ここ数年でClean Architectureはおなじみのアーキテクトとして親しまれるようになりました。 とりわけ単体テストを書く習慣が根付いているバックエンドで重点的に取り入れられているように見受けられますが、フロントエンドにおいても同様にClean Architectureを導入し、メリットを享受できます。 今回はフロントエンドにClean Architectureを導入する手順を、実際にコードを追いながら紹介していきます。 実際のコード 実際に書いたコードはこちらのGithubに公開しています。データを外部から取得するフローを表現するために、node.jsで実装されたモックサーバーも用意しました。 https://github.com/t-tiger/React-CleanArchitecture-Example 前提知識 Clean Architectureでおなじみの図と共に前提

                                                            フロントエンドでClean Architectureを適用してみる(+サンプルコード) - Qiita
                                                          • 今年はクリぼっちが本当に少ない / Flutter - Qiita

                                                            今年はクリぼっちが本当に少ない / Flutter 今年もやってまいりました!!クリスマス! この記事でわかること Flutterでアプリを作りましたので、その技術内容と悩み 恋をすることの素晴らしさ クリスマスの考察 この3つを中心に書いていければなと思います。 私の周りでクリぼっちが減った!? 最近、私の周りでは幸せ報告が後を絶えません。 いわゆる結婚ラッシュってやつでしょうか。 結婚しましたー(例のシンデレラの人) 結婚したぷるぷる!(大学の先輩) 結婚しました〜(インスタグラム多数) 付き合った報告(思い切って恋をしてみました!) しかもそれだけでなく、恋をした効果なのか 結婚(シンデレラ) → 勇気を出してデザインのフリーランスになれた! 結婚(大学の先輩) → CEOでめちゃめちゃ稼ぐ 付き合った報告 → CTOになれた! など恋をしつつも自分にコミットできている方が今年は多い

                                                              今年はクリぼっちが本当に少ない / Flutter - Qiita
                                                            • Clean Architecture for React:Archived Technologies

                                                              本書では、Clean Architecture の観点から、React や Redux で構築されたアプリケーションの設計をとらえなおし、また、ときには新たな設計の提案を行います。 いままでは Clean Architecture があまり取り入れられてこなかった Web フロントエンド領域に対して、この手法を適用することを目指します。 本書が、React アプリケーション設計のその一歩先に到るための一助になれば幸いです。 試し読み:https://note.com/imamori/n/n5a7ebdbd4260 また、BOOTH でも販売しています。下記のページから購入できます。 BOOTH:https://archived-tech.booth.pm/items/2399644 英語版:https://www.amazon.co.jp/dp/B09FG94392 目次: 第1章 Cle

                                                                Clean Architecture for React:Archived Technologies
                                                              • ベルリンでScala Meetupを開催しました! - Unipos engineer blog

                                                                こんにちは! Fringeのエンジニアの藤野です。 今回ベルリンでScala Meetupを開催しましたので、開催レポートとベルリンのScala事情について紹介します。 開催するまでの経緯 そもそもなんでベルリンで開催?という疑問を持つ方もいるかもしれませんが、実は今年の2月にFringeの子会社であるUniposがベルリンでドイツ支社を立ち上げました! 私もそのタイミングで2月から現地で働いています。 ピアボーナス「Unipos」ドイツの有力メガベンチャーで試験導入開始 〜同時にベルリンに支社を設立しヨーロッパへ進出〜 | News | Journal | Fringe | Be an Explorer ベルリンではMeetupが盛んに行われており、様々なテーマのMeetupがベルリン各地で頻繁に行われています。 参加者はMeetupアプリを通して定期的にイベント情報を取得し、興味のある

                                                                  ベルリンでScala Meetupを開催しました! - Unipos engineer blog
                                                                • FlutterアプリをCleanArchitecture + TDDで書く1(概要とユースケース実装)

                                                                  Flutter最高ですよね。こんなUI部品ないかな?と思って調べると大体標準SDKで用意されている...。 そんなFlutterでネイティブアプリをテスト駆動で書いてみます。 環境 Flutter 2.0.3 • channel stable Tools • Dart 2.12.2 アーキテクチャ CleanArchitectureを採用しました。責務分けが明確で、あまり考えなくても書けるので...。ファイル数は増えますが・・・ TDDですので、リファクタリングのタイミングで設計を都度行いますが、基本方針としCleanArchitectureに沿って書いていきます。 CleanArchitectureの書籍の下図に沿ってつくりたいと思います。(書籍ではWebシステムの具体的な例として扱っているものですが...) ところで、TDDとDartは相性がいい気がします。テストで大量のモックができま

                                                                    FlutterアプリをCleanArchitecture + TDDで書く1(概要とユースケース実装)
                                                                  • 4月中ば以降の業務委託の案件を探しています(Android or バックエンド) - みんからきりまで

                                                                    2020/03/16最終更新 こんにちは。@kiriminというものです。 4月半ば~5月くらいからのお仕事を探しています。 興味も持っていただいた方はtwitter @kirimin へのDM、または minkarakirimade@gmail.com までご連絡ください。 誰 だいたいのプロフィール、出来ること、やりたいことなどはここに書いてあります。 portfolio.forkwell.com 29歳のAndroidエンジニアです。 7年ほどフリーランスとして様々な企業でAndroidアプリの開発を行ってきました。 プログラマとして特別高度なことが出来るわけでないですが、WebサービスのクライアントなどオーソドックスなAndroidアプリを工数見積もりや技術選定、クラス設計の部分から早くきちんと実装出来ます。 以前はアプリのアーキテクチャ設計に興味が強く、MVPやCleanArch

                                                                      4月中ば以降の業務委託の案件を探しています(Android or バックエンド) - みんからきりまで
                                                                    • Kotlin+LibGDXで作ったゲームをSpring-boot上でも動かしJPAで永続化する - Qiita

                                                                      はじめに ブラウザゲームやソシャゲでは、ローカルの端末で遊んで操作結果をサーバに送信します。 このとき、サーバに単にクリアしたなどのゲーム結果を送るとチートし放題となってしまいますので、暗号化だったり逐一通信することでそれを防ぎます。 ですが、これはチートとのいたちごっこになったり、逐一通信することでユーザの体感速度が著しく落ちます。 そこで「ローカルで動かしたゲームの操作だけ送るが、ゲームのアルゴリズムをサーバと共通にし、サーバ側で再現することでデータの不整合を防ぐ」ことを考えてみます。 ソースはここに置いておきます まずは Kotlin + LibGDX でゲームを作る まずゲームを作ります。できました。 ゲームは何度も使ってるファイアーエムブレムのクローンです。(クローンと言ってもSDキャラのアニメとか作ってないので動かして戦闘ができるだけですが。) 環境はたまたまKotlinを勉強

                                                                        Kotlin+LibGDXで作ったゲームをSpring-boot上でも動かしJPAで永続化する - Qiita
                                                                      • スマホアプリ開発で採用している技術 - エムスリーテックブログ

                                                                        【マルチデバイスチーム ブログリレー1日目】 イントロダクション こんにちは、エンジニアリンググループ・マルチデバイスチーム(以下「マルデバ」)の星野です。 エムスリーのエンジニアリンググループは、サービス開発を行う「事業チーム」と、各事業チームを横断してサポート/開発する「横断チーム」とに分かれております。私が所属するマルデバは「横断チーム」に位置し、各サービスの iOS / Android アプリ(およびそのBFF)の開発を専門に行なっており、私は主にこの後に紹介する m3.com アプリ、Web 講演会アプリ、m3.com CAREER アプリの開発を行っています。 今日から6日間「マルチデバイスチーム ブログリレー」と題し、マルデバメンバーでリレー形式でテックブログを執筆し、マルデバがどのような開発をしているのか・どんなチームなのか・どんなメンバーがいるのかなど、ご紹介できればと思

                                                                          スマホアプリ開発で採用している技術 - エムスリーテックブログ
                                                                        • [覚書] Micro Frontends 📚

                                                                          Micro Frontends とは?🤔 皆さん、Micro Fronends(以下、MFE)をご存知でしょうか。説明をざっくりしますと、Microservicesの考え方をフロントエンドまで拡張した考え方です。Microservicesは、バックエンド側で適用される事例をよく耳にしますが、フロントエンドでの適用事例は、あまり聞いたことがありません。 従来、Webサービス開発ではモノリスな構成からスタートします。そこから、規模が拡大するにつれて様々な理由により、フロントエンドとバックエンドの分離、バックエンドのMicroservices化が行われます。 [翻訳記事]マイクロフロントエンド Microservices化によって、Scalability、Agility、Independency、Availabilityの大幅な向上が期待できます。しかし、依然フロントエンドはモノリスなままです

                                                                            [覚書] Micro Frontends 📚
                                                                          • 予約APIのマイクロサービス化とgRPCゲートウェイの置き方 - Retty Tech Blog

                                                                            本記事はRettyマイクロサービス強化月間の四つ目の記事です. engineer.retty.me RettyのtoB開発チームでエンジニアをしています鈴木です. 社会人エンジニアも早いことに1年が経ってしまい, “ピチピチエンジニア” の称号と権利を失ってしまいました. 今年は “深みと勢いのエンジニア” として活動しています. ピチピチエンジニアとして投稿した以前の記事では, その時おすすめの焼き芋を紹介したので今回も最近おすすめのお店としてMEARIを載せます. retty.me 今まで実家の焼き鳥が一番美味しいと思っていた自分に衝撃を与えたお店です. 早速本題に入りますが, RettyのtoB開発チームではtoC開発チームと同様にPHPで作られた大きいモノリスからGoで書かれたマイクロサービスへの移行が進んでいます. 現在, Rettyにおけるとても重要なシステムである予約APIの

                                                                              予約APIのマイクロサービス化とgRPCゲートウェイの置き方 - Retty Tech Blog
                                                                            • 世界一わかりやすいClean Architecture - DroidKaigiバージョン

                                                                              DroidKaigiで登壇予定であったバージョンです。こちらの原稿を文章にしたブログと動画がありますのであわせて御覧ください。 https://www.nuits.jp/entry/easiest-clean-architecture-2019-09 https://youtu.be/pbCRHAM5NG0Read less

                                                                                世界一わかりやすいClean Architecture - DroidKaigiバージョン
                                                                              • iOSエンジニアはMVVM・RxSwiftをやるべき?キャリアパスから解説する - IT業界で気づいたことをこっそり書くブログ

                                                                                タイトルは釣りです。 本当に書きたいのは エンジニアはスキルの陳腐化やコモディティ化とどう戦っていくべきか です。 クソ面倒くさい話を書きます。 死ぬほど長いです。 モチベーション 免責事項 MVVMとは? MVC, MVVMはどこから来たのか? RxSwiftとは何なのか? 関数型言語・オブザーバーパターンはなんか良いやつなの? なぜMVVMをやりたいのか、真のメリットは? iOSアプリ開発で自動テストは必要なのか? iOS MVVMは一過性の流行なのか? 1.MVVM+RxSwiftで慣れた人は、MVVM+RxSwiftが書きやすい 2.RxSwiftが向いているプロジェクト、MVVMが向いているプロジェクトがある MVVMは無くならない 副次的に起こるRxSwift+MVVMの必要性、そして避けられないコモディティ化 じゃあMVVMやRxSwiftを勉強しなくていいのか? クソみたい

                                                                                  iOSエンジニアはMVVM・RxSwiftをやるべき?キャリアパスから解説する - IT業界で気づいたことをこっそり書くブログ
                                                                                • GitHub - jasontaylordev/CleanArchitecture: Clean Architecture Solution Template for ASP.NET Core

                                                                                  You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                                                                                    GitHub - jasontaylordev/CleanArchitecture: Clean Architecture Solution Template for ASP.NET Core