並び順

ブックマーク数

期間指定

  • から
  • まで

41 - 80 件 / 460件

新着順 人気順

"Clean Architecture"の検索結果41 - 80 件 / 460件

  • Software Design連載 2021年8月号 Python製のレガシー&大規模システムをどうリファクタリングするか - MonotaRO Tech Blog

    Software Design連載開始 ※ (2021/09/02 08:55) 「Pythonを用いて開発を始めたのが2003年」を「Pythonを用いて開発を始めたのが2002年」に修正 こんにちは。金谷です。 このたび、モノタロウにおけるPython大規模開発に関する取り組みを、技術評論社様で発刊されている Software Design に連載させていただくことになりました。 モノタロウがPythonを用いて開発を始めたのが2002年。2021年の現在もPythonを用いた開発が続けられています。 事業の成長に伴い、関連するシステムやエンジニアの数も増え続けていくなかで、いかに安定的に価値を提供し続けられるのか。 モノタロウにおける取り組みを、開発や運用周りを通してご紹介していきます。 本記事の初出は、 Software Design2021年8月号「Pythonモダン化計画(第1

      Software Design連載 2021年8月号 Python製のレガシー&大規模システムをどうリファクタリングするか - MonotaRO Tech Blog
    • デザインパターン〜とかアーキテクチャ〜〜とか・・・に行く途中の話

      こんにちは、NE会社で働いておりますきんじょう(@o0h_)がお送りします。 弊社ではPHPを用いてアプリケーション開発を行っています(Ruby, Go, Javaも領域によっては利用しております) さて、つい先日のことですが、社内にいるメンバーから「デザインパターンについて、勉強してみてるんだけど・・・」「ちょっとついていくのが難しくて」「どうしたらいいですかね?それとも、先にやっておくべきことが他にありますか?」なんて雑談をしました。 なるほど、コレは頻出質問になりそうだな・・・という気持ちにもなったので、今回はこの場を借りて「デザインパターン[1]、その前に〜個人的に思ったことをツラツラと〜」でお届けしていきたいと思います。 「デザインパターンを(から)勉強してみる」ことの、オススメ/オススメナイ いちおう、今回は「リーダブルコードくらいは読んでいる」「デザインパターンの勉強をしてい

        デザインパターン〜とかアーキテクチャ〜〜とか・・・に行く途中の話
      • マイクロサービスにクリーンアーキテクチャを採用する上で考えたこと | メルカリエンジニアリング

        Merpay Advent Calendar 2019 の19日目は、Backendエンジニアチームの @toshinao がお送りします。 新しくマイクロサービスを立ち上げる機会があり、クリーンアーキテクチャをベースにしました。クリーンアーキテクチャはバックエンド・フロントエンド・アプリなど様々な場所で採用されています。ただ、確固たる方法というのは無く、みな試行錯誤しているのでは無いでしょうか。この記事では、クリーンアーキテクチャを取り入れる上で考えたことを紹介したいと思います。 マイクロサービスを作ったことがない人や、今までいくつか作ってきたけどより良い設計について考えている人の助けになれば幸いです。 はじめに メルペイのバックエンドは主にGoとGoogle Cloud Platform(GCP)で開発を行っていますが、各マイクロサービスをどう実装していくかは概ね各チームに委ねられてい

          マイクロサービスにクリーンアーキテクチャを採用する上で考えたこと | メルカリエンジニアリング
        • クリーンアーキテクチャなんてものはない(クリーンアーキテクチャーの読み方)

          すでに何人かの人がクリーンアーキテクチャなんてないよ、って話はしていてイマサラだと思うんですが。 あえてブログの記事に残そうかなと思って書いてみます。 最近、改めてクリーンアーキテクチャ本を読んだり、原文を読んだり、 ここ数ヶ月ツイート色々な人のを観測したり社内で話したりしていて 考えがまとまってきたので、自分の言葉で整理してみたくなった。 「へー、クリーンアーキテクチャっていうソフトウェアアーキテクチャがあるんだー」という微妙な誤解?をちょっとでも減らす一助になればという感じです。あと、本の読み進め方のヒントにもなるかも 先に結論 クリーンアーキテクチャというのはアンクルボブの書いた本。 ソフトウェアアーキテクチャのことではない。 the クリーンアーキテクチャというブログ記事はただのソフトウェアアーキテクチャの例(そして本の一部分)だが、独り歩きしている クリーンアーキテクチャというソ

            クリーンアーキテクチャなんてものはない(クリーンアーキテクチャーの読み方)
          • 有名企業のエンジニア向け研修資料まとめ - Qiita

            はじめに 今回は有名企業の公開されているエンジニア新人研修資料をまとめました。 昨今、新人向けの研修資料を公開する企業が増えています。 またクオリティーがかなり高いものが多く、初級者~中級者でも学びがある資料となっています。 資料の作り方も勉強になるので「勉強会で登壇している人」「企業の研修担当の人」にも有益な資料になっています。 この記事の主な対象者 有名企業の研修資料を網羅的に見たい人 エンジニア初級~中級者の人 独学で学習をしている人 研修資料の作成を今後していきたい人 ミクシィ まずはじめに紹介するのは、毎年新人向けの研修資料を公開している株式会社ミクシィです。 ミクシィの研修資料で公開されている内容は、 Git研修 データベース研修 設計・テスト研修 コンテナ研修 iOSアプリ開発研修 Androidアプリ開発研修 フロントエンド研修 ゲーム開発研修 Flutter研修 AI研修

              有名企業のエンジニア向け研修資料まとめ - Qiita
            • 新入社員に向けて私が3年間で読んだ技術書を紹介する - Qiita

              はじめに 今回は私が3年間で読んだ技術書をひたすら紹介します。 私は2021年4月に新卒でSIerに就職し、2024年4月でエンジニア4年目となりました。 そんな私の入社時のスキル感はどうだったかというと... 非情報系学部卒の理系 学部4年生の時に研究室で少しPythonを触ったことがある程度 HTTP?なにそれ? でした。 こんな感じでほぼゼロからのスタートでしたが、3年間でどのくらいのスキル感になったかというと、ざっくりと 基本的に一人称で開発業務ができる 小規模のシステム開発なら技術選定やアーキテクチャの検討も可能 某(若手向け)技術コンテストで入賞経験あり OSSコントリビューション経験あり IT関連の資格7つ取得 くらいには成長することができました。 これから紹介する技術書を読むだけでこのくらいのスキル感になれますという話ではなく、当然日々の業務であったり、その他のインプット/

                新入社員に向けて私が3年間で読んだ技術書を紹介する - Qiita
              • 「自動テストとテスト駆動開発、その全体像」を執筆しました(Software Design 2022年3月号) - t-wadaのブログ

                【更新】寄稿した記事が Web に公開されました 技術評論社様のご厚意により、 Software Design 2022年3月号に寄稿した「自動テストとテスト駆動開発、その全体像」が gihyo.jp にて公開されました。誠にありがとうございます! gihyo.jp はじめに 2022年2月18日発売の Software Design 2022年3月号 にて、第2特集「そろそろはじめるテスト駆動開発」の第1章「自動テストとテスト駆動開発、その全体像」を執筆いたしました。第1章では、混同されることの多い自動テスト関係の概念を自動テスト、テストファースト、テスト駆動開発(TDD: Test-Driven Development)の3つの段階に分け、それぞれの効果や注意点を包括的に整理整頓しています。 ソフトウェアデザイン 2022年3月号 作者:大竹 章裕,瀬戸口 聡,庄司 勝哉,光成 滋生,

                  「自動テストとテスト駆動開発、その全体像」を執筆しました(Software Design 2022年3月号) - t-wadaのブログ
                • ドメイン駆動設計からオブジェクト指向、そしてアジャイル開発まで。関連書籍練り歩きのススメ

                  本記事はドメイン駆動設計(DDD) Advent Calendar 2021 25日目の記事です。 「もっとビジネス変化に耐えられる設計を目指したい」「ただデータをやりとりするだけなのに複雑化してしまうのを防ぎたい」 様々な動機からドメイン駆動設計に入門しようとする方がいると思います。 自分もエンジニアとして働きはじめて、「どうしてすぐに変更しにくくなってしまうのか」「より柔軟な設計にするにはどうすればよいか」と悩むことが多くなり、良い設計手法を探って出会ったのがドメイン駆動設計でした。 最初はドメイン駆動設計関連の本ばかりを読んでいたのですが、途中から「これってドメイン駆動設計というよりはオブジェクト指向の話では?」とオブジェクト指向に興味を移し、さらに「より変化に強いプロダクト開発するにはチームから変化させないとまずいのでは?」とアジャイル開発に興味が移りました。 本記事では、ドメイン

                    ドメイン駆動設計からオブジェクト指向、そしてアジャイル開発まで。関連書籍練り歩きのススメ
                  • 私が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
                    • 【Webエンジニアど素人から3年生ぐらいになるまでに読むと良い本】を段階的にまとめた - Qiita

                      これってなんなの? 【ど素人状態=社会人になって初めてプログラミングを勉強したぜ!(特に新卒)】〜【Webエンジニアの3年生ぐらい】になるまでに読むと良い本まとめです。「どんな目的で学ぶか?」*「いつぐらいまでに読むといいか?」を段階的にまとめました。「これだけ読めばいい!」と、そんな簡単な話ではありませんが、「今いるレベルより少し上の人がどんなジャンルのことを学んでんだろ?」という方の参考になれば嬉しいです。過去の自分に向けてでもあります、自戒。これからWebエンジニアになる人、なって間もない人の参考になれば幸いですm(__)m ※続編 【Webエンジニアど素人】が【3〜4年生】くらいになったら読むといい本を目的別にまとめた ”Webエンジニアど素人から3年生ぐらいになるまでに読むと良い本”の段階的まとめ(一部外部記事あり) ど素人の方々が手を動かしながら1〜6ヶ月以内に学ぼう! ◆どの

                        【Webエンジニアど素人から3年生ぐらいになるまでに読むと良い本】を段階的にまとめた - Qiita
                      • テックリードがどんな活動したらよいのか考えて行動してみた話 - ZOZO TECH BLOG

                        2022年6月に、Androidテックリードになった いわたん です。最近、某モンスターを育てたり図鑑を埋めたりするゲームで社内大会をやったらフルボッコにされて涙目でした。悔しくて最近は不思議な力でクラフトしたり空飛んだりして王国を救うゲームやってます。 今回はAndroidテックリードとして1年間やってみた施策の紹介と、それぞれの成果や反省点を紹介したいと思います。これからテックリードになろうとしている方やテックリードをしている方の参考になったり、こんな施策もいいよというアドバイスをもらえたら幸いです。 ZOZOのテックリードの役割と責任 実施した施策 テックリード1on1 読書会 歴史的経緯があるアプリのアーキテクチャ整理へのアプローチ ネーミングセンスを鍛える会の取り組み 案件への関わり方 横断的なコードレビュー 横断的に使う機能の実装 まとめ 最後に ZOZOのテックリードの役割と

                          テックリードがどんな活動したらよいのか考えて行動してみた話 - ZOZO TECH BLOG
                        • ソフトウェアのアーキテクチャについて - threecourse’s blog

                          最近、小〜中規模のプログラムを保守性高く記述するにはどうすればよいかが気になっていて、 ソフトウェアのアーキテクチャについて調べていました。 本を読んでみる 以下の本を浅めに読み通してみました。どの本もそれぞれ学ぶべき点があって興味深かったです。 .NETのエンタープライズアプリケーションアーキテクチャ第2版 https://www.amazon.co.jp/dp/B00ZQZ8JNE C#での設計の話。ドメイン駆動設計など、設計に関わるトピックが広く触れられていて良い。 Adaptive Code C#実践開発手法 第2版 https://www.amazon.co.jp/dp/B07DJ2BL4Y C#での実装の話。SOLID原則を中心に、実装に関わるトピックが広く触れられていて良い。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 https://www.a

                            ソフトウェアのアーキテクチャについて - threecourse’s blog
                          • クリーンアーキテクチャの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では同様の質問がかなり盛り上がっている

                              クリーンアーキテクチャのUsecaseはなぜControllerへ値を返すのではなくOutput PortとしてPresenterを呼び出すのか - Runner in the High
                            • Go(Echo), Gorm, Mysql, Docker, Swaggerで、クリーンアーキテクチャなAPIサーバーを作ったメモ

                              自分の本業は10年物のMVCプロジェクトなのでClean Architecture忘れがちです。 なので、慣れてるGoでパッとClean Architectureの復習を行ってみました(2年前にPythonでやった事はあるんだけど・・・)。 このスクラップでは単語とか作りどころとかを整理するのですが、また後でRustで作ってそっちは前例がほぼないので記事にします。 Go + Clean Architectureは結構記事あるんですが、Swaggerつけたしたのと自分なりに納得いくディレクトリ構成にオリジナリティを出しました。ちなみにgo-swagger使うと本当は凄く楽に作れるのですが(ついでにフロントはopenapi-generator)、今回はClean Architectureを理解するのが主目的なので、サーバーは手書きでopenapiのyamlも1から自作しました。 ↑ postに

                                Go(Echo), Gorm, Mysql, Docker, Swaggerで、クリーンアーキテクチャなAPIサーバーを作ったメモ
                              • 事業を支える技術選定 / Engineering Decision Making Process For Business - Speaker Deck

                                Transcript 事業を支える技術選定 コネヒトマルシェオンライン「事業を支えるWeb開発」@itosho 1 自己紹介 ▪伊藤 翔 @itosho ・コネヒト株式会社 執行役員CTO ・Backend Engineer / PHP, Go ・stand.fm はじめました ・https://stand.fm/channels/5ec2e733f654bbcab4c123a2 Follow me! 今日のテーマ「技術選定」 4 何故、技術選定は難しいのか? ▪正解がない ・判断軸が多岐に渡り、会社の状況によっても変わる ・イデオロギーが対立しやすいトピックであり、合意形成が難しい 難しいからこそ向き合う価値がある ▪今日話すこと ・技術選定をするにあたり、どうやって意思決定をしているか ・正解がないトピックなので一つの考えとして聞いてください ※話のトピック的に、何かを「選ぶ」ので必然

                                  事業を支える技術選定 / Engineering Decision Making Process For Business - Speaker Deck
                                • Clean Architectureにおいてバリデーションはどこでやるべきか

                                  クリーンアーキテクチャで web アプリケーションを作る際に、バリデーションはどのレイヤの責務なのか?と悩むことが多いため、それについての考察を行ってみる。 あと、バリデーションについて書いてたはずがドメインロジックとアプリケーションロジックの違いについても結構言及せざるを得ない感じになったので、そのへんの話もしてみる。 結論から言うと バリデーションはどのレイヤの責務なのか?という問い自体が間違いであり、レイヤごとにそのレイヤの責務となるバリデーションを行うべき、というのが今のところの結論。 バリデーションという単語は意味があまりに広い。「意図していないもの/ことを防ぐ」ことはすべてバリデーションと呼ばれている節がある。そのことにより、バリデーションというのはあたかも唯一つの責務であるかのように錯覚しがちだが、そうではない。クリーンアーキテクチャではレイヤによって責務を分担しているが、同

                                    Clean Architectureにおいてバリデーションはどこでやるべきか
                                  • 「青銀行の勘定系をFirebase前提で構築できるか?」 - たなかこういちの開発ノート

                                    Firebaseについて、事前知識 Firebaseとは、以下のような機能群を「Serverless」の文脈でバンドルしたものである。「Serverless」として、これらの統合管理コンソールの出来栄えが秀逸。 - Firestore ... Document-oriented KVS - Cloud Functions ... AWSのLambda - Cloud Storage ... AWSのS3 - Hosting ... Web Assetsのデプロイ先の提供、CDN展開サポート - Authentication ... ユーザー管理・統合認証サービスの提供 - Cloud Messaging ... iOS/Android/Web(JS)クライアントアプリへの統合プッシュ通知サービス - その他 いうまでもなく「Serverless」とは「サーバー運用・管理レス」の意味。まさに

                                      「青銀行の勘定系をFirebase前提で構築できるか?」 - たなかこういちの開発ノート
                                    • 継続的ドキュメンテーション: 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
                                      • Flutterアプリにおける、過不足ない設計の考察🎅

                                        Photo by Hush Naidoo Jade Photography on Unsplash「一般的なモバイルアプリ」の設計全般において、特に何に気を付ける必要があるか、あるいは逆にあまり気にしてなくても良いのではと思うことなどを述べていきます。 (…のつもりでしたが、後者含めると1記事に収めるの困難で、最後にさらっと触れつつ別記事で手厚く書きたいところです🤔) ここでの「一般的なモバイルアプリ」は規模観点では以下程度のイメージですが、それを超えるような規模でも通ずる内容も多いと思っています。 コード量: 数万〜十数万行実装者: 一桁人種類としては(スマホ向けの)クライアントアプリコードであり、以下などではないです。 パッケージ・ライブラリではないサーバーサイドではないこの種類によって適切な組み方はけっこう変わり、アプリコードは依存関係の末端側(基本的に依存される側にはならない)な

                                          Flutterアプリにおける、過不足ない設計の考察🎅
                                        • Goはクリーンアーキテクチャの思想を活かせるか? DMMのゲームプラットフォームにGo言語を選んだ理由

                                          DMM GroupのGoの勉強会「DMM.go」。DMM Groupのエンジニアが現場で培った技術やトレンドについて発表していきます。 2回目の開催となる今回登壇するのは、合同会社EXNOA プラットフォーム開発本部の PFシステム部に所属する岡崎翔悟氏。「Goとクリーンアーキテクチャ」の内容で、実際の現場にいるからわかるGoの開発やクリーンアーキテクチャについて話していきます。関連資料はこちら。 合同会社EXNOAとは 岡崎翔悟氏:今回「Goとクリーンアーキテクチャ」と題しまして、EXNOAの岡崎が発表いたします。 「EXNOAって何だ?」と思われた方が多数いらっしゃると思うので、まずはそちらの説明から。DMM GAMESは2020年4月10日付でEXNOAに社名を変更しました。ただし、一般作品のブランド名として「DMM GAMES」は残っています。一般作品の「DMM GAMES」とR1

                                            Goはクリーンアーキテクチャの思想を活かせるか? DMMのゲームプラットフォームにGo言語を選んだ理由
                                          • AWS Lambdaによる進化的アーキテクチャの構築 | Amazon Web Services

                                            Amazon Web Services ブログ AWS Lambdaによる進化的アーキテクチャの構築 この投稿は、メディアとエンターテインメントのプリンシパルソリューションアーキテクトであるLuca Mezzaliraによって書かれました。 俊敏性により、必要に応じてワークロードを迅速に進化させ、新機能を追加したり、新しいインフラストラクチャを導入したりできます。コードベースでアジリティを実現するための主な特徴は、疎結合コンポーネントと強力なカプセル化です。 疎結合は、テストカバレッジを改善し、一貫したリファクタリングを作成するのに役立ちます。カプセル化を使用すると、実装ロジックを明らかにすることなく、サービスとのやり取りに必要なものだけを公開できます。 進化的なアーキテクチャは、設計の俊敏性を実現するのに役立ちます。「進化的アーキテクチャの構築」という本の中で、このアーキテクチャは「複数

                                              AWS Lambdaによる進化的アーキテクチャの構築 | Amazon Web Services
                                            • 現実世界の事象から学ぶSOLID原則

                                              # Object-Oriented Conference 2024 https://fortee.jp/oocon-2024/proposal/e1eb34cf-78ef-43f6-8a03-bb26c996cb62 概要 オブジェクト指向プログラミング (OOP) のコーディング慣例として広く採用される、SOLIDの原則。 コードの保守性、拡張性、再利用性を語る上では共通言語としても使用される一方で、初学者にとっては決して理解のしやすいものではありません。 これらの原則が抽象的であり、実際のコードにどのように適用されるか・適用した際に得られるメリットを理解するのが難しいことが理解を困難にする一因です。 しかし一度理解すると、SOLID原則が現実世界のありとあらゆる場所で適用されていることに気が付くはずです。 「clean architecture 達人に学ぶソフトウェアの構造と設計」にお

                                                現実世界の事象から学ぶSOLID原則
                                              • DDDでプロダクト開発をしたので振り返ってみた - JMDC TECH BLOG

                                                みなさん、こんにちは!プロダクト開発部の吉川(@yoshiyu0922)です。 現在、JMDCが保有している医療ビッグデータを活用して生活者や医療に新しい価値を提供する新規プロダクト開発チームのバックエンドを担当しております。 以前に新規プロダクト開発で採用している技術や設計についてこちらの記事で紹介しましたが、Go x GraphQL x DDDでプロダクト開発をしています。今回はプロダクトの開発が一区切りしてこれからリリースするということで、開発してみて良かったことやこうすれば良かったことを振り返りをしました。振り返りの内容は主にDDDに関することです。 DDDとは DDDとは「Domain-Driven Design」の略語でドメイン駆動設計と呼ばれるソフトウェア開発手法の一つです。問題を解決しようとする領域(ドメイン)をモデリングによってソフトウェアの設計や実装に反映させることで、

                                                  DDDでプロダクト開発をしたので振り返ってみた - JMDC TECH BLOG
                                                • ドメイン駆動設計の比類なきパワーでRailsレガシーコードなど大爆殺したるわあああ!!! - Qiita

                                                  この記事は クラウドワークスアドベントカレンダー2019 12日目の記事です。 概要 こんにちは、怒り駆動リファクタリングを生業としている @MinoDriven です。 弊社リファクタリング専門チーム「バグハンター」で現在実施中のリファクタリング設計について紹介致します。 ドメイン駆動設計 を用い、Railsレガシーコードに対しViewとControllerを ActiveRecord非依存 に変更する設計です。 状況 弊社ブログの過去エントリにあるように、弊社サービスcrowdworks.jpはサービスインから8年経過し、 30万行 を超えるモノリシックRailsアプリになっています。 開発生産性が低下してきています 。 生産性低下の課題を解決しようにも、大規模な上に複雑かつ密結合な構造になっており、 マイクロサービスへの移行も、リプレイスも困難な制約 があります。 そこで半年前にリフ

                                                    ドメイン駆動設計の比類なきパワーでRailsレガシーコードなど大爆殺したるわあああ!!! - Qiita
                                                  • React で作る中規模 SPA のレイヤードアーキテクチャ - GiXo Ltd.

                                                    TAG : Advent Calendar | Firebase | Firestore | React | Refeed | TypeScript | トチカチ | フロントエンド AUTHOR :   ギックス POSTED :  2020.12.23 08:25 この記事は GiXo アドベントカレンダー の 23 日目の記事です。 昨日は、少人数の開発で Kubernetes を活用するための設計戦略 でした。 MLOps Div. の堀越です。本記事では、React と TypeScript で SPA の実装を行う際に採用しているレイヤードアーキテクチャについてご紹介します。 レイヤードアーキテクチャというとクリーンアーキテクチャや DDD が有名ですが、弊チームフロントエンド の場合はクリーンアーキテクチャから SPA にマッチする箇所を部分的に取り入れた簡易版のレイヤードア

                                                      React で作る中規模 SPA のレイヤードアーキテクチャ - GiXo Ltd.
                                                    • 人の作ったWebアプリケーションのコードを見るときに注目しているところ - Runner in the High

                                                      普段見ているものをなんとなく書き出してみた。 インターフェイス あえてやってないとか、レイヤ的にやる必要がないというケースもある。しかし、ある程度の規模のソフトウェアには大抵インターフェイスが現れる。インターフェイスがないコードはユニットテストもないことが多い。したがって、インターフェイスが現れないコードは責務分離が行われてない可能性を感じたりする。 言語機能上インターフェイスがない動的型付け言語の場合には、ダックタイピングを意識したコードが書かれているかをチェックする。ダックタイピングでなくとも、例えばRubyだったら抽象クラスと実装クラスの分離が行われているかを見たりする。 バリデーションロジック すべてのバリデーションが、フレームワークの機能で実装されてたりしないかをチェックする。MVCとかクリーンアーキテクチャ的な実装であれば、それぞれのレイヤでどういうバリデーションをしているのか

                                                        人の作ったWebアプリケーションのコードを見るときに注目しているところ - Runner in the High
                                                      • Rust についてカジュアル面談で頻繁に訊かれる質問と、それに対する個人的な回答 - CADDi Tech Blog

                                                        エンジニアリングマネージャーの村上 (@mura_mi) です。採用関連で面談に出ることが多いのですが、大体7割くらいの確率で 「なんで Rust 使ってるのですか?」「Rust 使っててどうですか」と聞かれるので先回りして書いておこうと思った記事です。 なんで Rust を選んだの Rust をエンジニアリングチームの武器の中心に据える意思決定がされたのは私の入社前ですが、伝え聞いている話しと自分の解釈を混ぜ合わせた話を書きます。 「データ指向アプリケーションを堅牢に作るのに必要な型システムを求めたこと」と、「キャディがもともと C++ の会社だったこと」の2つが、キャディが Rust を使っていることの背景にあったのだと理解しています。 後述しますが、キャディが 原価計算システム やサプライチェーン・マネジメントシステム を Rust を使って開発しはじめたのは、2019年の中頃だった

                                                          Rust についてカジュアル面談で頻繁に訊かれる質問と、それに対する個人的な回答 - CADDi Tech Blog
                                                        • Laravel大規模開発入門!MVC分離のFatModel問題に対する責任分離と依存管理、その設計と考え方について|ハイクラス転職・求人情報サイト AMBI(アンビ)

                                                          Laravel大規模開発入門!MVC分離のFatModel問題に対する責任分離と依存管理、その設計と考え方について ナイル株式会社メディアテクノロジー事業本部の工藤さんにMVC分離のFatModel問題に対する責任分離と依存管理、その設計と考え方について解説いただきました。 こんにちは、ナイル株式会社メディアテクノロジー事業本部で開発マネージャをしています工藤@ta99toです。 今回は大規模で複雑度の高い開発をMVCフレームワークベースで構築する際に僕が課題と捉えているポイントやその具体的な解決手法について解説させていただきたいと思います。 「MVC以上の責任分離イメージがつかないよ!」 「DDDとかクリーンとかオニオンとかあのへんの設計パターンの導入モチベーションが不明」 「どうやっても最終的には複雑になって追加開発や修正開発が怖い状態になっちゃう」 ↑このような悩みを持った方に対して

                                                            Laravel大規模開発入門!MVC分離のFatModel問題に対する責任分離と依存管理、その設計と考え方について|ハイクラス転職・求人情報サイト AMBI(アンビ)
                                                          • 達人出版会

                                                            探検! Python Flask Robert Picard, 濱野 司(訳) BareMetalで遊ぶ Raspberry Pi 西永俊文 なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 Jesse Storimer, 島田浩二(翻訳), 角谷信太郎(翻訳) 知る、読む、使う! オープンソースライセンス 可知豊 きつねさんでもわかるLLVM 柏木餅子, 風薬 R/RStudioでやさしく学ぶプログラミングとデータ分析 掌田津耶乃 データサイエンティストのための特徴量エンジニアリング Soledad Galli(著), 松田晃一(訳) 実践力をアップする Pythonによるアルゴリズムの教科書 クジラ飛行机 スッキリわかるサーブレット&JSP入門 第4版 国本 大悟(著), 株式会社フレアリンク(監修) 徹底攻略 基本情報技術者教科書 令和6年度 株式会社わくわくスタディワール

                                                              達人出版会
                                                            • Clean Architectureなにもわからないけど実例を晒して人類に貢献したい - エムスリーテックブログ

                                                              こんにちは、エムスリーエンジニアリンググループの福林 (@fukubaya) です。 これまでは、中村の記事で宣言した 「医師版Stack Overflow」(12/16に正式名称Docpediaとしてリリースされました) の技術的チャレンジの 記事を続けて書いていたのですが、今回はここで宣言しなかったClean Architectureについて書きます。 浪江駅(なみええき)は、福島県双葉郡浪江町にある、東日本旅客鉄道(JR東日本)常磐線の駅。本文には特に関係ありません。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ) 作者:Robert C.Martin,角 征典,高木 正弘出版社/メーカー: ドワンゴ発売日: 2018/08/01メディア: Kindle版 なぜ書くのか 参考にできる実例を増やしたい Tech Blogはそのままドキュメ

                                                                Clean Architectureなにもわからないけど実例を晒して人類に貢献したい - エムスリーテックブログ
                                                              • ヤフーのクリエイターが読んでいる技術・デザイン書 〜 技術活動費用補助制度のデータから見る興味関心

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

                                                                  ヤフーのクリエイターが読んでいる技術・デザイン書 〜 技術活動費用補助制度のデータから見る興味関心
                                                                • 機械学習APIでWebサイトの改善点を提案するサービスを作った話 - Qiita

                                                                  まえがき アクセシビリティーの観点からWebサイトを診断し、AIプラットフォームを利用して得た情報をもとにベストプラクティスを提案してくれるオープンソースのWebサービス「Visible」を開発しました。 WebサイトURL: https://visi.dev GitHubリポジトリ(Starください!): https://github.com/visible/visible GoogleのLighthouseなど、Webサイトの診断を行ってくれるサービスは以前からありましたが、診断だけではなく改善点の提案も行う新しいサービスになっています。また、アクセシビリティーに関する理解を深めてもらえるように工夫をした設計にしていたり、コマンドライン版ではスタンドアロンで実行可能なようになっています。 2020年度の「独創的アイデアと卓越した技術を持つ小中高生クリエータ支援プログラム」未踏ジュニアに

                                                                    機械学習APIでWebサイトの改善点を提案するサービスを作った話 - Qiita
                                                                  • 各社のエンジニア研修で探る、新人エンジニアに必要な技術と駆け出しエンジニアの成長論 - このすみノート

                                                                    新人研修の内容を検討しているのですが、それにあたり各社の新人研修を調査しました。 なお本記事は、@gcchaan氏のGitHub Gistにある「研修資料まとめ」を参考に作成しております。 @gcchaan氏の「研修資料まとめ」はとても素晴らしいまとめで、これを見ると各社がどのように新人エンジニアを育成しているのか見てとれたり、新人エンジニアがどのような研修を経て成長していくのか垣間見えます。 DMM.com(2019) DMM.comの研修で紹介されている技術書 GMOペパボ(2019) LINE(2018) Spee(2016) Wantedly(2019) ウエディングパーク(2019) エムスリー(2018) 研修概要 KAYAC(2017) クックパッド(2016) GREE(2014) ぐるなび(2017) LEMPについて サイバーエージェント(2019) エンジニア研修がど

                                                                      各社のエンジニア研修で探る、新人エンジニアに必要な技術と駆け出しエンジニアの成長論 - このすみノート
                                                                    • あえてGo言語でClean Architectureを学ぶ

                                                                      はじめに 最近巷で話題のGoらしさって話があると思いますが、 ここはあえてGoらしからぬClean ArchitectureをGoで学んでいこうという記事です。 対象 Go言語をある程度読めて、Clean Architectureに興味がある方 注意 ここでいうClean Architectureとは、依存性のルールに従った円を指しています。 Clean Architectureを採用しましょうって話ではありません。 各言語には思想があるので、その言語らしい書き方に沿うべきだと思っています。 ざっくりとしたアーキテクチャの目的 システムの関心の分離を行い、選択肢を残す(決定を遅らせる)ことが目的です。 またユースケースを中心として開発するため、フレームワークやツールに依存しません。 Clean Architectureとは Robert Martin がブログで提唱したアーキテクチャの解説

                                                                        あえてGo言語でClean Architectureを学ぶ
                                                                      • Slim Framework と Docker を使って本格的にアプリを作ってみよう|技術ブログ|北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ

                                                                        Slim Framework と Docker を使って本格的にアプリを作ってみよう はじめに Web アプリケーションの開発をするにあたっては勉強しなければならないことは多く、どう勉強すれば良いかはなかなか難しい問題です。初心者向けの解説は比較的たくさんあるのでとりあえずやってみるくらいは何とかなるものの、実戦的な開発がどうなっているかという総合的な話は実務を経験しないとわからないことが多いことでしょう。 ということで、本記事では最近流行の Docker と、そこそこ名前は見かける PHP のマイクロフレームワークの Slim Framework を使って実戦的な Web アプリの開発をしてみる(開発環境を作ってみる)こととします。実装的には、ドメイン実装としてユーザー登録、ログイン、ユーザー情報取得の3つのAPIを実装するところまでを取り扱います。また、静的解析を最大限活用してユニット

                                                                          Slim Framework と Docker を使って本格的にアプリを作ってみよう|技術ブログ|北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
                                                                        • Clean Architecture on Frontend (翻訳) - Qiita

                                                                          こちらはDEV Communityに2021年9月2日に投稿され、現在反響を巻き起こしているフロントエンドにおけるクリーンアーキテクチャの実装についてのAlexさんの記事になります(原文はこちら)(twitterにて翻訳掲載許可取得済み)。 かなり大ボリュームな超大作記事となっておりますが、Reactなどを使ったフロントエンドプロジェクトのディレクトリー構成やファイルごとの責務の切り分けのベストプラクティスなどの決定版といえるものがまだまだ出てこない中で、個人的にまさに待ち侘びていたような内容の記事かと思い、是非日本のフロントエンドコミュニティでも知見が共有されればと思いました。 それでは以下、本文です。 *翻訳は大部分をDeepL翻訳によって行っていますが、適宜修正してあります。 少し前に、私はフロントエンドにおけるクリーンアーキテクチャについての講演を行いました。この記事では、その講演

                                                                            Clean Architecture on Frontend (翻訳) - Qiita
                                                                          • 【プログラマー必見】情報収集で絶対に役立つIT企業の公式ブログ 30選

                                                                            はじめに 今回の記事では個人の独断と偏見でプログラマー向けに必ず確認しておきたいIT企業の公式ブログを共有する。なお、今回の記事で紹介している公式ブログはあくまで一例に過ぎない。 AppBrew 文章が易しく初心者でも読みやすい 主に業務効率化を中心に書かれている 実務・プログラミングのイメージができない初心者や新人には非常にオススメ ABEJA Tech Blog 主に保守・運用を中心に発信している ドローン・機械学習に興味があるならオススメ 専門用語が多めなので理解に苦労する可能性が高い UUUMエンジニアブログ あの有名なクリエイター(YouTuber)を数多く輩出している会社「UUUM」の公式ブログ Rails・PHP・インフラ(AWS、Dockerなど)の情報が多い 技術記事が非常に読みやすく、画像とソースコードを使って的確に技術ややっていることを説明している Wantedly

                                                                              【プログラマー必見】情報収集で絶対に役立つIT企業の公式ブログ 30選
                                                                            • なぜDependency Injectionなのか? ~関心の分離と疎結合~

                                                                              本稿は「アーキテクチャを突き詰める Online Conference」における発表「なぜDependency Injectionなのか? ~関心の分離と疎結合~」の登壇原稿となります。 発表時の動画アーカイブは後日公開されたタイミングでリンクを追加いたします。 また、本稿のサンプルコードとPower PointはGitHubで公開しています。 「CC BY-SA 4.0」で公開していますので、気に入っていただけたら営利目的含め、ライセンスの範囲で自由に利用していただいて問題ありません。 https://github.com/nuitsjp/WhyDependencyInjection というわけで、本稿の目指すゴールはこちら。 今日は、この場にいる皆さんが「なぜDependency Injectionを利用するのか?」ということを、理解いただくのが本日のゴールとなります。 というわけで本

                                                                                なぜDependency Injectionなのか? ~関心の分離と疎結合~
                                                                              • こんなに辛いことになるから、最初にがんばろう / 辛い開発状況をどうにかするためにやった13のこと

                                                                                こんにちは!sugitaniと申します。 これまで有名芸能人と通話ができる(かもしれない)ライブ配信アプリとか、オリジナルマンガの配信サービスとか、コメントが横に流れるライブ配信システムとかを作ってきました。(SUGARは今も作業してます) 最近ご縁がありましてUUUMの子会社で、簡単に有料フォロワー向けの投稿が行えるFOLLOW MEを主に開発していて、NFTでデジタルトレーディングカード(※)を売り買いすることができるHABETをIndieSquare社さんと協業で運営しているNUNW株式会社(5月にFOROから社名変更)に入社し半年くらい経っています。最近CTOに任命していただきました! ※NFTについては思うことがある開発者の皆様が多いと思っていますが、自分がどう思っているかは後述します 少し前に「スタートアップがまともなわけ無いから入るな」というインタビュー記事を書いて頂いたんで

                                                                                  こんなに辛いことになるから、最初にがんばろう / 辛い開発状況をどうにかするためにやった13のこと
                                                                                • 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対応)