並び順

ブックマーク数

期間指定

  • から
  • まで

81 - 120 件 / 474件

新着順 人気順

"Clean Architecture"の検索結果81 - 120 件 / 474件

  • こんなに辛いことになるから、最初にがんばろう / 辛い開発状況をどうにかするためにやった13のこと

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

      こんなに辛いことになるから、最初にがんばろう / 辛い開発状況をどうにかするためにやった13のこと
    • リーダブルアーキテクチャ - usecaseにおける時間軸と抽象度の統一 - Qiita

      はじめに Clean Architectureやレイヤードアーキテクチャでは、どのようにレイヤーを定義するかついては言及されています。 そのような中usecase(レイヤードアーキテクチャではApplication層)をどのように実装するべきかについての議論は少ないです。 しかし私はリーダブルなアーキテクチャを実現するために、一番大切なことはusecaseを適切に実装することであると考えています。 そこでusecaseを実装する上で起こりがちな抽象度の問題を例に、リーダブルなアーキテクチャを考えいていきたいと思います。 サンプル 1:1のチャットアプリでUserとWorkerが存在して会話ができるアプリを例にあげます。 以下の図では青い背景はinfraの関数実行、緑色の背景はdomainの関数実行、赤い背景はusecaseの関数実行を示しています。 usecaseのCreateChat関数

        リーダブルアーキテクチャ - usecaseにおける時間軸と抽象度の統一 - Qiita
      • 元Googleエンジニアのメンターによる講義を公開 ──トヨタ自動車が実践する「Flutter」研修の内容とは? - TECH PLAY Magazine

        Googleが開発したモバイルアプリ用のフレームワークであり、SDK(Software Development Kit)であるFlutter。トヨタ自動車では、自動車のコックピットのUX/UI設計・開発フローの一部で、同ツールを採用している。今回の「TOYOTA Developers Night」では、GoogleやYouTubeで活躍した講師を招いて実施しているFlutterの研修プログラムや成果を紹介した。 ■登壇者プロフィール 関沢 省吾 氏 トヨタ自動車株式会社 コネクティッドカンパニー コネクティッド先行開発部 デジタルコクピットソフト開発室 グループ長 名古屋大学大学院を修了後、2007年にトヨタへ入社。Lexus LFAをはじめ、各種車両の電子プラットフォーム開発や、TOYOTA LQのAIエージェント開発へ従事。2020年より現職。 Tim Mansfield氏 itali

          元Googleエンジニアのメンターによる講義を公開 ──トヨタ自動車が実践する「Flutter」研修の内容とは? - TECH PLAY Magazine
        • GoとKinesis Data Firehoseで非同期の検索基盤を構築─モノリス化した「カオナビ」はアーキテクチャ改善にどう取り組み始めたか - はてなニュース

          社員の個性・才能を発掘し、戦略人事を加速させるタレントマネジメントシステム「カオナビ」を提供する株式会社カオナビでは、SaaS移行にあわせてクラウドを全面的に採用し、インフラの自動化などにAWSのマネージドサービスを積極活用しています。とはいえ10年近い運用で、サービス開発におけるシステムのモノリス化が課題となってきました。 こういった全社的な課題は、2020年からCTOを務める松下雅和(@matsukaz)さんを中心にCTO室で対応しています。モノリスなシステムは、全体のモジュラモノリス化を前提に、とくにボトルネックとなる検索処理を非同期の基盤サービスとして切り出しています。 この検索基盤の設計と実装を通して、カオナビはシステムのアーキテクチャ改善をどのように進めようとしているのか。非同期である必要性や、デプロイの工夫、開発組織の文化まで含めて、CTO室の千葉峻秀さんとインフラグループの

            GoとKinesis Data Firehoseで非同期の検索基盤を構築─モノリス化した「カオナビ」はアーキテクチャ改善にどう取り組み始めたか - はてなニュース
          • Vuex + DDD のアーキテクチャを考える - Techtouch Developers Blog

            フロントエンドエンジニアの国定です。 この記事では、TypeScript + Vue.js で開発しているフロントエンドに今年からドメイン駆動設計(DDD)を取り入れ始め、ひとまず設計が落ち着いてきたのでその経緯とアーキテクチャについて解説します。 課題 アーキテクチャ Domain Service Store(Vuex) UI(Vue.js) 軽量DDDに陥らないために まとめ 課題 Vuex(Store)の責務は、エラー判定などのドメインロジック・データの永続化・API の呼び出しなど、State 管理のほかにも多岐にわたっています。UI の改善や機能追加など変化の多いフロントエンドでは開発が進むにつれ Vue + Vuex のあちこちに同じ処理が散在してしまいます。 テックタッチでもメンテナンスを繰り返す度にコードの複雑さが増し、機能追加や修正に時間がかかるようになってきました。去年

              Vuex + DDD のアーキテクチャを考える - Techtouch Developers Blog
            • プログラミング独学1年目の私に教えてあげたい書籍リスト

              はじめに 今回の記事では、私がプログラマー活動や情報発信を継続する上で、「最初の1年間で読むべきだった」と思う技術書を簡潔にまとめる。今回の記事は情報量が非常に多いので、全部を確認するのは不可能だ。そのため、流し読みして興味が湧いた書籍や情報にアクセスするように使ってほしい。 これからWebプログラマーになる人、プログラミング初心者やWebプログラマー1年目の参考になれば非常に幸いである。 1年目の私に教えてあげたい書籍とのリストは次の通りである。 【プログラマー関連】 リーダブルコード プリンシプル オブ プログラミング プログラマーは世界をどう見ているのか IT用語図鑑[エンジニア編] 開発・Web制作で知っておきたい頻出キーワード256 Web技術が これ1冊でしっかりわかる教科書 Webを支える技術 達人プログラマー Clean Architechture オブジェクト指向でなぜつ

                プログラミング独学1年目の私に教えてあげたい書籍リスト
              • なぜDependency Injectionなのか? ~関心の分離と疎結合~

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

                  なぜDependency Injectionなのか? ~関心の分離と疎結合~
                • Clean Architecture の勘所は『鎖国』だ。 - Qiita

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

                    Clean Architecture の勘所は『鎖国』だ。 - Qiita
                  • Goのテストに使える手作りモックパターン - Money Forward Developers Blog

                    こんにちは。 京都開発拠点でGoエンジニアをしています @yoskeoka です。 Goを中心技術として性能改善やプロダクト間を横断するような機能の設計、実装を行うKTAチーム (京都開発本部 テクニカルアーキテクトチーム) 所属です。 突然ですが、皆さんはGoでテストを書いているでしょうか。 我々はテストを書くことが中長期的なスピードアップに繋がると信じて日々テストを書くようにしています。 KTAではGoの実装をする際にClean Architectureの考えに基づいたpackage分けを行っていますが、packageを分けたり、インターフェースを定義したりとしていくと、テストを書くのが難しい部分というのが出てきます。 そんな場合に使えるモック作りテクニックを今回は紹介したいと思います。 Clean Architectureはテストしやすくなると言うが Clean Architectu

                      Goのテストに使える手作りモックパターン - Money Forward Developers Blog
                    • 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アーキテクチャのレイヤーとのマッピング レイヤー内・レイヤー間:独

                        Clean Architectureを採用したBackend For Frontendの開発とこれまでの所感 - LIFULL Creators Blog
                      • Clean Architecture on Frontend

                        Alex Bespoyasov Posted on Sep 1, 2021 • Updated on May 12, 2022 • Originally published at bespoyasov.me Not very long ago I gave a talk about the clean architecture on frontend. In this post I'm outlining that talk and expanding it a bit. I'll put links here to all sorts of useful stuff that will come in handy as you read: The Public Talk Slides for the Talk The source code for the application we'

                          Clean Architecture on Frontend
                        • 非エンジニアサイドに技術的負債や設計を説明するノウハウ - Qiita

                          こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2022 、10日目の記事です。 これはなに? ろくに設計せずにシステム開発を進めると技術的負債が蓄積し、変更が難しくなってしまいます。 しかし設計を推進しようにも、周囲が設計is何を知らないと、なかなか理解を得られません。特にビジネス側や経営側はプログラムの内部構造を知らないわけですから、輪をかけて説得が困難です。 この記事は、ビジネス側や経営側など、非エンジニアサイドに対して技術的負債や設計を分かりやすく説明するための例えや手法をまとめたものです。 私が非エンジニアサイドへ説明するとき実際に活用しているもので、聞き手からも「分かりやすい」と好評を得ております。 この記事のゴール 以下を知ることがこの記事のゴールです。 技術的負債や設計について、非エンジニアサイドに理解を促すノウハウ ユ

                            非エンジニアサイドに技術的負債や設計を説明するノウハウ - Qiita
                          • Lambdaのテスト領域に関する技術共有会を開催しました | DevelopersIO

                            はじめに CX事業本部の佐藤智樹です。 今回は先月中頃に実施したLambdaのテスト領域に関する技術共有会の資料と当日にいただいた意見を紹介します。技術共有会自体はお客様含め5人ほどで実施予定でしたが、社内の方を誘ったところ15人程と大人数でディスカッションしながら知識を深めました。有意義な時間となったのでブログで共有します。 本記事はLambdaに対してどのようなテストをすべきか、Lambdaでこれからテストを書くがどうやれば良いか悩んでいる方などは参考になるかと思います。いくつか紹介するテストパターンのメリット/デメリットもあげるので、テスト選定の上で参考にしてください。 例となる題材がなければ抽象的な話ばかりになり分かりづらくなるので、今回は以下のIoTデータ収集システムをベースにどうテストを書いていくか検討します。IoTデバイスからきたデータをRDSに保存するシステムです。色々書い

                              Lambdaのテスト領域に関する技術共有会を開催しました | DevelopersIO
                            • goquを駆使してgoでSQL構築も構造体マッピングもRDBテストもやる - エムスリーテックブログ

                              【Unit4 ブログリレー6日目】 こんにちは、エムスリーエンジニアリンググループの福林 (@fukubaya) です。 最近まで開発していたm3ラウンジでは、goからRDBを利用していました。 m3ラウンジでは、SQLの組みやすさやテストのしやすさの観点で検討した結果、goquを採用しましたので、 そこで得られた知見とその実装例を紹介します。 これから試してみる方(と将来m3ラウンジの開発に新たに入ることになったメンバー)の参考になるように、サンプルコードも説明も多くなってしまいかなり長いです。 お時間ある時にお読みいただければ。 名古屋城は、日本の城のひとつ。尾張国愛知郡名古屋(現在の愛知県名古屋市中区本丸・北区名城)にある。本文には特に関係ありません。 m3ラウンジ goqu 実例 modelの構造体 mapper mapperの実装 goquのSQLの結果から構造体へのマッピング

                                goquを駆使してgoでSQL構築も構造体マッピングもRDBテストもやる - エムスリーテックブログ
                              • SOLID原則をまとめてみた Part1 ~SOLID原則とはなんぞや編~ - ecbeing labs(イーシービーイング・ラボ)

                                はじめに SOLID原則とは どうしてSOLID原則が生まれたのか ダメなソフトウェア設計の4つの原因 Rigidity-剛性 Fragility-脆弱性 Immobility-不動性 Viscosity-粘性 本当の原因 どんな変更が設計をダメにするのか おわりに&次回記事に続く… はじめに はじめましてorこんにちは! ecbeing2年目、R&D部門所属のいかちゃんです。 これまでは、Dockerの記事やスクラムに関する所感記事、JavaScriptライブラリに関する記事を書きました。 blog.ecbeing.tech そして今回…というより本シリーズでは、泣く子も黙る『Clean Architecture』本を参考に…。 https://www.amazon.co.jp/dp/B07FSBHS2Vwww.amazon.co.jp ソフトウェア設計の5つの原則として名高い「SOLI

                                  SOLID原則をまとめてみた Part1 ~SOLID原則とはなんぞや編~ - ecbeing labs(イーシービーイング・ラボ)
                                • RESTful APIをシュッと作る技術 - PythonとFastAPIでバックエンドを5時間ちょいで作ってみた - Lean Baseball

                                  久々に開発ネタです. 大晦日ハッカソン2019 #大晦日ハッカソンで, 野球のデータをシュッと見るためのDashboardを作る(理由は後ほど). そんなDashboardのBackend APIをシュッと開発する. を目標に立て現在進行系でやってるのですが, 午後の進捗その2 Docker化が特に滞りなく完了. API Docも見れるとかFast API強すぎぃ 昨日の夕方から開発してたAPIはアッサリ1st Ver.できたので, 大晦日の買い物終わったらフロントエンドを除夜の鐘が鳴るまでになんとかするぞ #大晦日ハッカソン pic.twitter.com/wWMiSvQDKu— Shinichi Nakagawa (@shinyorke) 2019年12月31日 Backendを昨日(12/30)の18:00から着手して(実質作業時間)約5時間ちょいで完成させてしまいました. 本年最後

                                    RESTful APIをシュッと作る技術 - PythonとFastAPIでバックエンドを5時間ちょいで作ってみた - Lean Baseball
                                  • フロントエンドで長持ちするプロダクトを開発するための心構え

                                    こんにちは、クレスウェア株式会社の奥野賢太郎 ( @okunokentaro ) です。今年もよろしくお願いします。 今回は、Reactでのクリーンアーキテクチャの採用の是非についてTwitterにつぶやいたところ、思いの外Likeが集まったため、まとめて閲覧できるようにツイートをまとめつつ、簡単に補足しようかと思います。 リアクションのもととなった記事 Webフロントエンドの開発効率を高く保つための考え方 @adwdさんのこの記事に感銘を受けて、Twitterでちらほら感想をつぶやいたところLikeやRTが予想外に集まりました。それが下記のツイートです。 筆者がツイートしたもの 補足 筆者は、元記事で言及されている『「悪い方が良い」原則と僕の体験談』や『質とスピード(2020秋100分拡大版)』は確認済みであり、『 Clean Architecture 達人に学ぶソフトウェアの構造と設計

                                      フロントエンドで長持ちするプロダクトを開発するための心構え
                                    • Firebase をフロントエンドから適切に隠蔽するための「Hooks Injection パターン」 - JX通信社エンジニアブログ

                                      取締役の小笠原(@yamitzky)です。 JX通信社では、React 製のフロントエンドでも Clean Architecture で設計するなど、なるべく特定のバックエンドに依存しない設計を心がけたりもするのですが、一方で Firebase をラップした react-firebase-hooks などの「便利な Hooks」を使って開発スピードを加速したい、という課題を持っていました。 そして先日、次の記事が話題になっていました。まさに「どう Firebase を隠蔽するか」と「どう Firebase を活用するか」を両立する悩みです。 blog.ojisan.io 結論を言うと「Hooks そのものを注入する」のが筋が良いのではないか と思っています。個人的に「Hooks Injection パターン」と名付けたこの方法をご紹介したいと思います。 今回の記事の完成形はソースコードを公

                                        Firebase をフロントエンドから適切に隠蔽するための「Hooks Injection パターン」 - JX通信社エンジニアブログ
                                      • 事業とプロダクトで転職先を選んだら一致する技術スタックがほぼ0個だった話|sys1yagi

                                        Ubie(ユビー)株式会社でソフトウェアエンジニアをしている八木(@sys1yagi)です。Ubieに入社してすでに1年8ヶ月くらい経ってますが(2019年4月入社)、入社エントリを書いていなかったので書きます。 【特にこんな人に読んでほしい】 ・Ubieに興味があるけど、技術スタック全然違うしな〜って思ってる人 ・キャリアとか転職とか皆どういう観点で考えてるんだろと気になる人これまでのキャリアソフトウェアエンジニアになって2021年でちょうど15年になります。Ubieに入社する2019年までは10年間ほどAndroidアプリケーションエンジニアをしていました。クックパッドのAndroid版をスクラッチしたり、新規事業のAndroid部分を担当したり(当時は一つのクックパッドアプリケーション内で複数事業の機能が入ってました)、新規事業がMBOして独立する際に技術部長を兼任しつつAndroi

                                          事業とプロダクトで転職先を選んだら一致する技術スタックがほぼ0個だった話|sys1yagi
                                        • WEBフロントエンドにおけるソフトウェア設計の考察 / Consideration of software design in WEB front end

                                          概要 ・現代Webフロントエンドにおける難しさは何によってもたらされるのか ・Webフロントエンドと「ドメイン」の関係について ・Webフロントエンドを「設計」することについて ・Webフロントエンドにおけるアーキテクチャ考察 参考資料(スライドにも記載) ・エリック・エヴァンスのドメイン駆動設計 ・Eric Evans(著)今関 剛(監訳)和智 右桂、牧野祐子(訳) ・Clean Architecture 達人に学ぶソフトウェアの構造と設計 ・Robert C. Martin(著)角 征典、高木 正弘(訳) ・未来を作った人々 - ゼロックス・パロアルト研究所とコンピュータエイジの黎明 ・Michael Hiltzik(著)エ・ビスコム・テック・ラボ(監訳)鴨沢眞夫(訳) ・オブジェクト指向のハードコア ・https://www.zerobase.jp/salon/2019/05/25/

                                            WEBフロントエンドにおけるソフトウェア設計の考察 / Consideration of software design in WEB front end
                                          • 達人出版会

                                            探検! Python Flask Robert Picard, 濱野 司(訳) BareMetalで遊ぶ Raspberry Pi 西永俊文 なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 Jesse Storimer, 島田浩二(翻訳), 角谷信太郎(翻訳) 知る、読む、使う! オープンソースライセンス 可知豊 きつねさんでもわかるLLVM 柏木餅子, 風薬 デザインディレクション・ブック 橋本 陽夫 現場のプロがやさしく書いたWebサイトの分析・改善の教科書【改訂3版 GA4対応】 小川 卓 解釈可能なAI Ajay Thampi(著), 松田晃一(翻訳) PowerPoint 目指せ達人 基本&活用術 Office 2021 & Microsoft 365対応 PowerPoint基本&活用術編集部 ランサムウェア対策 実践ガイド 田中啓介, 山重徹 TODによるサステナ

                                              達人出版会
                                            • GoのDIライブラリgoogle/wireの使い方 - 一休.com Developers Blog

                                              こんにちは。宿泊事業本部の宇都宮です。この記事では、GoのDIライブラリgoogle/wireの使い方を紹介します。 この記事は一休.com Advent Calendar 2019の9日目の記事です。 DIとは GoのDIライブラリ wireの使い方 Providerのエラーハンドリング Injectorのカスタマイズ Provider Set インタフェースのバインド 構造体のフィールドを参照する 細かな注意点 値とポインタの違いに注意 go runするときはwire_gen.goも一緒に おわりに DIとは DI(Dependency Injection, 依存性の注入)とは、あるオブジェクトが依存しているオブジェクトを自ら用意するのではなく、外部から渡してもらう(外部から注入する)というデザインパターンです。 例として、以下のように、監督の名前を渡すとその監督の映画を全てリストにし

                                                GoのDIライブラリgoogle/wireの使い方 - 一休.com Developers Blog
                                              • 既存のシステム設計手法ではつらいので、数理的システム設計という手法をつくった #agileto2019 - うさぎ組

                                                現代のソフトウェアシステムにおけるシステムアーキテクチャ設計手法や、それらをとりまく各種手法は素晴しい。だけど、わたしはまだまだもっと理想にちかづきたい。 そんな思いから課題をみつめて、自分なりに設計手法をつくってみました。 いまはこれを数理的システム設計とよんでいます。まだαバージョンくらいです。 いままでも、これについては筑波で2度勉強会をしており、今回はAgile Tour Osaka 2019で講演してきました。 アジャイル システム設計 Meetup - connpass システム設計ハンズオン勉強会 -リジェクトすえなみチャンス暑気払い- - connpass Agile Tour Osaka 2019 × miniPLoP 2019年11月9日(大阪府) - こくちーずプロ で、今回はたぶんはじめてスライドを公開しました。 スライドにある通りですが、基本的には僕の経験のみの話

                                                  既存のシステム設計手法ではつらいので、数理的システム設計という手法をつくった #agileto2019 - うさぎ組
                                                • Mirrativのバックエンド開発におけるMySQLとの向き合い方 - Mirrativ Tech Blog

                                                  こんにちは、バックエンドエンジニアのmakinoです。先日、LINE LIVEさんとの共催イベントにて「Mirrativを支えるバックエンド開発 ~MySQLとの向き合い方~」というテーマでLTをしました。 connpass.com speakerdeck.com 今回はLTの内容から一部抜粋して、Mirrativのバックエンド開発において遭遇したMySQLに関する問題と、その対策について紹介します。 問題 その1 データ量/QPSの増加に伴って、非効率なクエリが顕在化した サービス初期の段階ではデータ量が少なかったり、ユーザーのアクティビティが少ないために問題がなかったクエリも、サービスの成長に伴ってデータ量・QPSが増加したことによって、MySQLに負荷をかけてしまうことがありました。 具体例を以下にいくつか示します。 数千件レコードのfilesort 適切なindexが利用できればM

                                                    Mirrativのバックエンド開発におけるMySQLとの向き合い方 - Mirrativ Tech Blog
                                                  • Don't Use Frameworks :: Victor's Blog — Ramblings of a Software Professional

                                                    Stop using frameworks for everything. Just stop. You don’t need a framework to write good code and deliver products. Don’t get me wrong, frameworks are useful, but they are all-consuming and hide the application. So if you shouldn’t depend on frameworks what should you do instead? Clean architecture. More specifically, there are some patterns you can follow to better architect your application and

                                                    • ドメイン駆動設計による運行管理システムのアーキテクチャの最適化 - TIER IV Tech Blog

                                                      こんにちは。ティアフォーでWebサービス開発を担当している池谷です。 世の中はコロナで自粛モードが続いていますが、ティアフォーではリモートワークを活用し日々の業務に柔軟に取り組んでいます。 さて、私の所属するWebチームでは、オープンソースの自動運転OS「Autoware」を利用した多種多様なサービスを開発しています。その中でも代表的なサービスに「FMS」という運行管理サービスがあります。今回は、当サービスを開発してきた振り返りとして、主にドメイン駆動設計によるアーキテクチャの最適化に纏わるトピックについてお話したいと思います。 What's FMS? ティアフォーのFMSの注目機能 オンデマンド配車モデル 巡回走行モデル ベストプラクティスを求めて FMS開発における試行錯誤 浮上していた課題 開発手法のアプローチ ドメイン駆動設計 モデリングの実践 設計・実装面のアプローチ クリーンア

                                                        ドメイン駆動設計による運行管理システムのアーキテクチャの最適化 - TIER IV Tech Blog
                                                      • ソフトウェアエンジニアをしていて影響を受けた5冊(+α)

                                                        他の方の記事ですが、読んでいておもしろかったです。記事に出ている本はClean ArchitectureとTDD、LeanとDevOpsの科学くらいしか読んだことなかったです。 また自分も書くことで、他の方も記事を書くようになり、ついでに他の方の記事を読んでみるなどしたいなと思ったので書いてみます。 私はソフトウェアエンジニアとしてのキャリアはまだ7年くらい[1]なので短い方ですが、約7年間の中で読んで印象に残ったものを紹介します。 計算機プログラムの構造と解釈 Scala関数型デザイン&プログラミング Effective Java Programming Rust 実践ドメイン駆動設計 なお、この記事ならびに本のリストは誰かの役に立つことは想定しておらず、単に自分が読んで影響を受けているなあと感じる本をまとめています。つまり自己満足です。 加えてこの手の記事を書く際には、一応筆者のプロフ

                                                          ソフトウェアエンジニアをしていて影響を受けた5冊(+α)
                                                        • 9つのチームロールでチームワークを強化する / ベルビンチームロール - mtx2s’s blog

                                                          スティーブ・マコネル(Steve McConnell)の著書『More Effective Agile』の第6章で、「ベルビンのチームロール理論」なるものが紹介されている。そこに、「Plant」や「Shaper」「Resource Investigator」など、聞き慣れない9つのロール名が並ぶ。チーム内でこれらのロールのバランスが取れていることと、チームのパフォーマンスの間には、高い相関があるそうだ。 そう言われると興味を持つ。ベルビンチームロールとはどのようなものだろうか。しかし残念なことに、同書からはほとんど情報を得られない。書かれているのは、先の9つのロールそれぞれに関する短い説明文と、次の引用にある記述ぐらいだ。 この理論では、チームにおいて人々がどのように行動するか、人々がどれくらい協力して作業を行うと考えられるか、そして各役割の候補者をどのように選択するかを評価する。 202

                                                            9つのチームロールでチームワークを強化する / ベルビンチームロール - mtx2s’s blog
                                                          • TypeScriptでクリーンアーキテクチャを実践する

                                                            概要 本記事は、スクラムを管理するアプリケーションをクリーンアーキテクチャの考え方で実装し、WebからもCLIからも動かせるようにしたという実践を紹介するものです。学習のための個人開発で作成したサンプルアプリケーションの設計と実装を適宜紹介することで、クリーンアーキテクチャに対する理解を深めることが目的です。 モチベーション なぜ現代の開発現場で定着しているクリーンアーキテクチャのアプリを手元で実装してみようと思ったかというと、私自身Webエンジニアとして働く中で、クリーンアーキテクチャの実践例は入出力をWebに限定したものばかりだったからです。 しかし、「詳細に依存せず抽象に依存すること」と唱えるクリーンアーキテクチャにとって、Webはただの詳細です。そこで、入力元、出力先を問わないアプリケーションはどのような書き味になるのか、自分で確かめてみたくなりました。 例えば、「ドメイン層は独立

                                                              TypeScriptでクリーンアーキテクチャを実践する
                                                            • Clean Architecture: クライアントアプリの「中心」とは何か / 20200121 the center of the client #ios_ca

                                                              iOS Clean Architecture勉強会 sponsored by Sansan - connpass https://connpass.com/event/158269/ の発表資料です。 ## 参考資料 Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ) | Robert C.Martin, 角 征典, 高木 正弘 | 工学 | Kindleストア | Amazon https://www.amazon.co.jp/dp/B07FSBHS2V マイクロサービスとクライアント: 
理想と現実の狭間で / Ideal and Reality of microservices from the client-side - Speaker Deck https://speakerdeck.com/qsona/ideal-and-realit

                                                                Clean Architecture: クライアントアプリの「中心」とは何か / 20200121 the center of the client #ios_ca
                                                              • Go言語によるクリーンアーキテクチャの実装例紹介

                                                                はじめに CastingONEでバックエンドエンジニアをやっている清水です。 この記事ではクリーンアーキテクチャについて学んだけど具体的にどのように実装すれば良いのかという悩みがあったので実装例をまとめてみた記事になります。 クリーンアーキテクチャで実装されたサンプル実装のうちGitHubのスター数が多いリポジトリをピックアップして、設計内容を紹介していきます。 具体的にどこにどんな実装をするべきなのかも含めて紹介していきます。 処理を一部省略して紹介するため実際の処理内容を確認したい場合はGitHubでご確認お願いします。 クリーンアーキテクチャとは クリーンアーキテクチャは、ソフトウェア設計の原則を適用して、依存性の方向性を逆転させ、ビジネスロジックから詳細(フレームワークやデータベース)を分離するアーキテクチャパターンです。これにより、テストしやすく、メンテナンス性が高く、柔軟性のあ

                                                                  Go言語によるクリーンアーキテクチャの実装例紹介
                                                                • FlutterとFirebaseで開発した 英語の瞬間翻訳トレーニングアプリ Lala の技術 - Qiita

                                                                  どうも、shoheiです。 株式会社Neverの代表です。 今回はFlutterとFirebaseで開発した英語の瞬間翻訳トレーニングアプリ Lala の技術を紹介します。 アプリはこちらからダウンロードできます(無料でご利用できます)。 ・iOS https://apps.apple.com/jp/app/id1493691416 ・Android https://play.google.com/store/apps/details?id=com.gmail.hukusuke1007.lala 目次 概要 開発期間 設計 主な機能 UI/UXデザイン ユーザーレビュー マーケティング その他 終わりに 概要 まずはLalaの概要を紹介します。アプリストアの情報をそのまま掲載します。 Lalaは英語の会話力向上を目的とした瞬間翻訳トレーニングアプリです。 次々と出題される文章を瞬間的に翻訳

                                                                    FlutterとFirebaseで開発した 英語の瞬間翻訳トレーニングアプリ Lala の技術 - Qiita
                                                                  • PHP中級者がソフトウェア開発の理解を深めるためのオススメ書籍 約30冊(2020年版) — A Day in Serenity (Reloaded) — PHP, CodeIgniter, FuelPHP, Linux or something

                                                                    去年末(2019/12)にオススメ書籍をまとめてみたことがあったので、それを少し更新して公開します。 上にある書籍がよりオススメというわけではないです。 対象者は「PHP中級者」です。中級者が何かは難しいですが、初心者、初級者では決してないとは言えます。 改めて一覧にしてみると、かなり偏っているかも知れません(笑 こういうのはコンテキストというのがあるため、それが合わないと「お前は何を薦めているのだ?」となるでしょうね。 キーワードは、「モデリング」「オブジェクト指向プログラミング」「TDD」「デザインパターン」「DDD」「チーム開発」「アジャイルソフトウェア開発」「スクラム」でしょうか。 PHP中級者のイメージ たぶん、PHP中級者であれば、PHPに関することはPHPマニュアルなどを調べて解決できるでしょう。PHPのオープンソースプロジェクトに貢献しており、自分でプロジェクトを持っている

                                                                    • 達人出版会

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

                                                                        達人出版会
                                                                      • エンジニア組織のキャリア戦略とスタンスとして大事にすべきこと

                                                                        こんにちは、株式会社エウレカでCTOをしている kaneshin です。 この記事は CTOA Advent Calendar 2020 の21日目の記事です。エンジニア組織におけるキャリア設計について、今までの私の経験を踏まえて考察してきたスキルの礎の部分について、いろいろな方にお話しする機会が増えたこともあり、今年の締め括りとしてエンジニア組織のキャリア戦略について一本書こうと思い、本記事を書いています。 はじめに株式会社エウレカは、恋活・婚活マッチングアプリ「Pairs」の運用とオンライン結婚相談所「Pairsエンゲージ」の展開をしています。私は2012年にエンジニアとして入社し、当時ローンチしたばかりのPairsチームへの配属となりました。(Pairsは以下「ペアーズ」と表記します) 入社当時は出会い系と同じ括りとして認識されていたペアーズですが、今ではこのようなクリエイティブを世

                                                                          エンジニア組織のキャリア戦略とスタンスとして大事にすべきこと
                                                                        • ウェブフロントに見る clean architecture の一例

                                                                          最初に: clean architecture は誤解されている 『Clean Architecture 達人に学ぶソフトウェアの構造と設計』(以下『Clean Architecture』)を読んだことがありますか?例の同心円の図しか知らないという人も多いでしょう。 画像出典: Robert C. Martin 「The Clean Architecture」 さて、ここでクイズです。「Clean architecture とは、 controllers や use cases、entities というクラスを作って繋げるアーキテクチャのことだ、○か×か」。どっちでしょうか? → → → 正解は×です。 あの同心円は、あくまで clean architecture の一例として『Clean Acrhitecture』で紹介されたものです。 そう、clean architecture とはア

                                                                            ウェブフロントに見る clean architecture の一例
                                                                          • リファクタリングに関する何か - 日々常々

                                                                            リファクタリングの話をするとき、焦点が合ってないなーと感じることがたまにあるのでざっくり描いてみた。 自分のために描いたものなので、なんか違うなーって思ったらご自身で描いてみるといいと思います。レッツモデリング。 破線は依存、実線は変換。長方形は名前などで明確に識別可能なもの、角丸は様々なものを包含する活動。雲は思いです。 描いた時の経緯と言うか 該当ツイート: リファクタリングって常時やるものなんですよね。もちろん「よーしやるぞー」って感じで行うものもあるんですけど、それは深呼吸的な。 とは言え。やったことがない、やってはいけない文化(動いているコードに触ってはいけない)に染められてしまっている、そのような方に「無意識にやれ!」と言っても、何の意味もないので言いません。むしろ害悪ですらある。 該当ツイート: 無意識にやるようになって、ようやく「リファクタリング」がカタログ化される前の「偉

                                                                              リファクタリングに関する何か - 日々常々
                                                                            • ADOP (Application Domain Others Pattern)

                                                                              TL;DR ADOP はヘキサゴナルアーキテクチャの実装パターンとして考えられます。 パターンという名前はそれに由来します。 あえて名付けた理由はこぼれ話をご確認いただけると幸いです。 ADOP の概要 ADOP (Application Domain Others Pattern) は中長期的に運用可能なコードへ誘導するアプリケーションアーキテクチャパターンです。 ADOP は次の特徴があります。 最小限のルールである 指針が明確である 特定の技術スタックに縛られない テスタビリティが確保される これらの特徴は、コードを自然と中長期的に運用可能なコードへ導きます。 まず、簡単にそれぞれがどういった意味を成すのかを確認してきましょう。 最小限のルールである どれほど完璧な作戦であっても、その実行が不可能であれば何の意味もありません。 プログラミングにおいてもそれは同じことで、制約を守るため

                                                                                ADOP (Application Domain Others Pattern)
                                                                              • Clean Architecture考察 - ROXX開発者ブログ

                                                                                この記事は個人ブログの内容がソースです。 kami-programming.com そもそもなぜクリーンアーキテクチャーを考察するのか DRY原則やSOLID原則などが浸透している昨今ですが、実際の開発現場のソースコードを読み込んでみると必ずしもこれらの原則に則していない場合は多いのではないでしょうか。 そして、そういった開発環境でいざコーディングをしていくと、以下のような問題に直面するのではないでしょうか。 あるバグの修正をしたのだが、同じロジックが他の場所でも書かれていたようで重複箇所のバグは依然としてバグったままだった。 あるクラスを変更したが、依存性の方向性や範囲が把握しきれておらず、変更の影響で新たなバグを生んでしまった。 ビジネスロジックの変更を迫られたが、同じロジックが重複しすぎており修正範囲を特定するだけで一苦労。 想定外の値の入力があり、バグが発生してしまった。 これらは

                                                                                  Clean Architecture考察 - ROXX開発者ブログ
                                                                                • 2019年ふりかえり - しゅみは人間の分析です

                                                                                  同人誌を生産する生活 同人誌制作が生活の中心だった。妻が同人活動を始め、それに振り回された一年といえる。妻はもともと絵を描く人だったが、ある日突然漫画も描くようになった。配偶者とはいえ、ひとの趣味なので始めは放置していた。だが、どうも雲行きが怪しい。スケジュールが破綻していたのだ。新刊が落ちるかもしれない、そんな状況で2019年を迎えた。年末年始の休暇をすべて費やし、私はスケジュール管理とアシスタントをすることになった。妻は1日に4ページの作画をこなし、私がベタとトーンを塗る。正月も休むことなく作業をし、締切前日には当然のように徹夜をした。 同人誌を作るのは文化祭の準備と似ている。あらゆる手段を使って完成させ、イベントで頒布しないといけない。本を用意できたら対面販売の喜びが得られる。インターネットで得られるただの数字とは違って、目の前の人が本を買ってくれるのだ。狭いスペースに何時間もいるの

                                                                                    2019年ふりかえり - しゅみは人間の分析です