並び順

ブックマーク数

期間指定

  • から
  • まで

81 - 120 件 / 4028件

新着順 人気順

設計の検索結果81 - 120 件 / 4028件

  • 「設計」で大事なのはこれだった!半年間で40本レビューして分かった 5つのポイント - Link and Motivation Developers' Blog

    以下は去年の弊社のQiita アドベントカレンダーに投稿したものです。 qiita.com これはなに? はじめまして。リンクアンドモチベーションの伊藤です。 主にバックエンドの開発を担当しており、最近はタイトルにあるように新規機能開発や既存機能改善に関わる多くの設計に「レビュワー」として携ってきました。 この記事では私がレビュワーとして開発の「設計」に関わってきた中で、 スムーズにステークホルダーの認識が揃ったな 議論がより深まった上で決定できたな と感じた設計におけるポイントをまとめてみました。 「設計でなにをしたらいいか迷っている方」 「コーディングだけじゃなくもう少し上流工程に入りたいと思っている方」 の参考になれば幸いです。 そもそも設計って? この記事では特に「基本設計」について触れていきたいと思います。 実装よりも上流の過程についてはこの記事などを参照ください。 唐突ですが設

      「設計」で大事なのはこれだった!半年間で40本レビューして分かった 5つのポイント - Link and Motivation Developers' Blog
    • マイクロサービス設計原則: SOLIDではなくIDEALS

      キーポイント For object-oriented design we follow the SOLID principles. For microservice design we propose developers follow the “IDEALS”: interface segregation, deployability (is on you), event-driven, availability over consistency, loose-coupling, and single responsibility. Interface segregation tells us that different types of clients (e.g., mobile apps, web apps, CLI programs) should be able to inte

        マイクロサービス設計原則: SOLIDではなくIDEALS
      • ふつうのプログラマのふつうの設計

        普通のプログラマの普通の設計 2022-01-26 本編(雑談)の前振りスライドです。 https://modeling-how-to-learn.connpass.com/event/231669/

          ふつうのプログラマのふつうの設計
        • ドメイン駆動設計に関する何か - 日々常々

          2020-03-13追記: 「ドメイン駆動設計」のハードルを上げる意図はありません。そもそもそんな特殊技能でもないと思っています。「ドメイン駆動設計が合っているか」を測る材料になるかも?くらいの気持ちで読んでいただけると幸いです。 何度目か知りませんがDDDがまたブームを迎えているようで。DDD難民と言う言葉が出た頃を思うと感慨深いですね。実際難民になったわけではないので肌感覚で知らないのが残念なところですが、これはどうでもいい。 DDD、日本語ではドメイン駆動設計となりますが、DDDを冠していてもドメインが語られることは少ないようです。 数ある書籍もドメインモデリングの話ではなく、ドメインモデルをいかに実装に落とし込むかにフォーカスしていると感じています。 これはこれで仕方ないと言うか、ドメインの話って広く語れないんですよね。 ドメインは領域で境界があって範囲が限定されています。特定ドメ

            ドメイン駆動設計に関する何か - 日々常々
          • 先生「意味が分かんないです」…シンセサイザーを設計してしまった中学1年生が話題に|まいどなニュース

              先生「意味が分かんないです」…シンセサイザーを設計してしまった中学1年生が話題に|まいどなニュース
            • リモートワークの設計と運用 / または Discord + VSCode LiveShare がいいぞという話 - mizchi's blog

              この記事読んで自分のリモートワーク経験からどうやるのが今一番良いだろうか、という話をずっと考えていたので、書き出してみました。 リモートワークをする人必読。組織パフォーマンスを左右する「デジタル心理的安全」とは? | 未来を変えるプロジェクト by iX(アイエックス) 自分自身はフルタイムリモートとフリーランスでのリモートの2つの経験があります。 次の会社が申請すればリモート可というスタイルなのですが、自分がリモートワークする場合、働く環境に期待しているのはこういうことだ、というのを事前に宣言しておく目的もあります。 フルリモートではなく、部分的なリモートを想定しています。 リモートワークに期待すること リモートワークは、基本的には「うまく運用すれば効率が下がらない」というものです。リモートワークで効率が上がることもありますが、基本的にはある種の福利厚生、雇用競争力のためと割り切ったほう

                リモートワークの設計と運用 / または Discord + VSCode LiveShare がいいぞという話 - mizchi's blog
              • AWSでサーバーレス設計を考える時の手引き書 - Qiita

                はじめに サーバーレスに触れて数年が立ちました。 そろそろ人にある程度説明ができるレベルの知識と経験が備わったような気もするので、年末なのでまとめてみました。 サーバーレス気になっているけれども、という人に少しでもためになればいいなーと思います。 サーバーレス基礎 皆さん、サーバーレス設計という話を聞いたことはあるでしょうか? まずサーバーレスについて説明しますが、世の中にはたくさん解説記事があるのでそちらも適宜参照ください。 サーバーレスでも実際にはサーバーは存在する サーバーレスとは開発者がサーバーのことを意識しなくてもよい、ということ Function as a serviceに代表されるように、あるプログラムの実行環境を提供するが、プログラムの動作環境は開発者は意識する必要はない、というイメージ 恐らく、AWS Lambdaが一番理解しやすいと思います。 AWS Lambdaではプ

                  AWSでサーバーレス設計を考える時の手引き書 - Qiita
                • 安藤忠雄設計の子どもたちのための図書館への子供反応「なんでこんなん作ったん?」を巡る賛否

                  SIVA @sivaprod 大量のリプいただき個々にはとてもお返事差し上げられませんがとりあえず「上の本は全部固定されたダミーだから安全ですよ」と「安藤忠雄が寄贈した建物なんだから安藤忠雄が好き放題やって当然」って書いて寄こしたひととは友達にはなれそうにないなあとだけ。 2022-03-27 12:00:50 異邦人 @Narodovlastiye 「子どもの為の図書館」などと言いながら、手に取れない位置に固定されている本について「これどうやって取るの」「何でこんなん作ったの」と、子どもに指摘される「図書館」とは一体何なのか。本をオブジェにし、図書館という施設が一体何の為にあるのか分からない施設。 www3.nhk.or.jp/lnews/kobe/202… 2022-03-26 22:50:53 リンク NHK NEWS WEB 神戸市に子どものための図書館「こども本の森 神戸」オープ

                    安藤忠雄設計の子どもたちのための図書館への子供反応「なんでこんなん作ったん?」を巡る賛否
                  • 最強データベース(RDB)設計とは?アンチパターンの見極め方法も - FLEXY(フレキシー)

                    ※2020年6月に公開された記事です。 日本PostgreSQLユーザ会の理事を務める合同会社Have Fun Techを起業した曽根壮大(@soudai1025)と申します。元株式会社オミカレ副社長兼CTOです。直近では、『失敗から学ぶ RDBの正しい歩き方』を執筆しました。 今回はデータベースをテーマとして、魅力やMySQLとPostgreSQLの違い、アンチパターンの見極めなどの基礎知識に加え、勉強法などもご紹介します。 RDB関連の求人検索はこちら データベースを学ぶ魅力をエンジニア目線で考察 1.知識の費用対効果が高い エンジニアがデータベースを学ぶ利点という観点から言うと、データベースの特徴は寿命が長いことと私は考えています。 Webアプリケーションの界隈では1年単位でバージョンアップしたり流行っている言語が変わってしまうことがザラにありますが、データベースは10年、20年とい

                      最強データベース(RDB)設計とは?アンチパターンの見極め方法も - FLEXY(フレキシー)
                    • チームで機能設計するためのPlantUML標準化 | フューチャー技術ブログ

                      はじめに現在所属しているプロジェクトではWebAPIやバッチ処理の設計の一環としてPlantUMLを利用しています。効率よく品質高くアウトプットを出すためには、プログラミング言語に対してコーディング規約があるように、UMLに対してもチームで設計するにあたり一定のルールを決める必要があります。 そこでプロジェクト内のPlantUMLを使用するうえでのガイドラインやルールをまとめる機会があり、せっかくなのでそれを記事化します。 記事のゴール シーケンス図設計におけるPlantUMLの標準化 必要最低限のルールだけに絞ってチーム設計の生産性と品質を上げる 記事の前提 ルールの想定の利用シーン: チームで大量生産する業務機能の処理フローを表現するために使う場合を想定。 また、この記事に記載されているルールはRDBを中心的に使用したAPI処理やバッチ処理等を念頭に置き決められたものです。 ルールの想

                        チームで機能設計するためのPlantUML標準化 | フューチャー技術ブログ
                      • AWSでの法令に則ったログ設計及び実装/分析 - Adwaysエンジニアブログ

                        エージェンシー事業でリードアプリケーションエンジニアを行なっている大窄 直樹 (おおさこ)です. AWSのログ, サーバーのログってたくさん種類があって難しいですよね... 同じようなログがたくさんあるので, 何を取れば良いのかとか どのくらいの期間保持すれば良いのかとか またその後の, ログの実装や, 分析方法する方法も難しいですよね... 今回AWSに構築した商用アプリケーションのログを整備する機会があったので, このことについて書こうかなと思います. 概要 本題に入る前の準備 今回ログ実装するアーキテクチャ ログに関する法令 ログの取得箇所 設計 保管するログの決定 インフラのログ OSのログ アプリケーションのログ ログの保管 保管場所について 保管期間について バケット構造 アプリケーション, OSのログの転送 実装 アプリケーション, OSのログをfluentbitを用いてS3

                          AWSでの法令に則ったログ設計及び実装/分析 - Adwaysエンジニアブログ
                        • LiDARスキャナで部屋を3D化してBlenderでツーバイ材DIYの設計したらうまくできました|鷲羽宗一郎

                          引っ越しに伴い、洗面所の空間活用について検討していました。ドラム式洗濯機の上の空間をうまく使いたいところですが、幅に余裕がなく既製のラックを導入できず困っていました。ないなら作ればいい、ということでDIYを画策。机や棚のようなモノとは違って空間を相手にするので、どう設計したものかと思い悩んだのち行き着いたのは「部屋の3Dスキャン」と「CADソフトによるレイアウト検討」でした。ググってみても事例が見つからなかったので、ここに残しておきます。 iPhone12 ProのLiDARスキャナで部屋を3D化 自分が保有している iPhone 12 Pro Max には『LiDARスキャナ』が搭載されているので、これを使えないかということで見つけたのが「3d Scanner App」。すぐに試したところ、期待した通り空間をスキャンでき、上の写真のテクスチャ付き3Dモデルを作り出すことができました。とり

                            LiDARスキャナで部屋を3D化してBlenderでツーバイ材DIYの設計したらうまくできました|鷲羽宗一郎
                          • GitHub - Katsukiniwa/awesome-software-design-ja: 日本語でのソフトウェア開発・設計に関する記事や書籍をまとめたリポジトリです

                            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.

                              GitHub - Katsukiniwa/awesome-software-design-ja: 日本語でのソフトウェア開発・設計に関する記事や書籍をまとめたリポジトリです
                            • レッドブルが「世界最速」FPVドローンRBD1開発、パイロットみずから設計。時速300km超のF1マシンにぴたりと追尾する映像公開 | テクノエッジ TechnoEdge

                              ガジェット全般、サイエンス、宇宙、音楽、モータースポーツetc... 電気・ネットワーク技術者。実績媒体Engadget日本版, Autoblog日本版, Forbes JAPAN他 エクストリームスポーツを効果的にマーケティングに取り込んできたエナジードリンクのレッドブルが新たに公開したのは、レッドブル・レーシングのF1マシンを世界最速のカメラ搭載ドローンでぴったり追跡する空撮映像です。 F1世界選手権の2024年シーズンは今週末に開幕します。昨シーズンはレッドブル・レーシングF1チームのマックス・フェルスタッペン選手が圧倒的な強さを見せつけて世界チャンピオンの座を防衛し、先頃行われたシーズン前の合同テストでも、圧倒的な安定感とスピードを誇示していました。 そんな自動車レースの頂点に立つレッドブルのF1マシンと世界チャンピオンを追いかけ回すドローンパイロットとして選ばれたのは、Dutch

                                レッドブルが「世界最速」FPVドローンRBD1開発、パイロットみずから設計。時速300km超のF1マシンにぴたりと追尾する映像公開 | テクノエッジ TechnoEdge
                              • 建築設計会社に一人情シスとしてSaaSを導入した話

                                概要 普段はソフトウェアエンジニアとして活動していますが、訳あってITとは全く関係ない建設業界の社内システムを作った時の話をします。古い体質と言われる建設業界ですが、高齢化により若者が定着しない、IT化の遅れから労働生産性が悪いといった問題が、そのまま「人手不足」「3Kイメージ」に繋がっています。 本記事では、全くシステム導入が進んでいないとある建築設計会社の情報システムを担当し、どんなSaaSを組み合わせて社内システムを構築したかを紹介します。紹介するSaaSは一例であり、全ての会社に当てはまるわけではないので、あくまで参考としていただきたいです。 導入したSaaS Microsoft 365 コアとなるグループウェアとしては、Microsoft 365を使用しています。通常のIT・ソフトウェア業界ではGoogleのグループウェアが多いですが、建築の会社では以下の理由でMicrosoft

                                  建築設計会社に一人情シスとしてSaaSを導入した話
                                • DarkModeのデザインを中心とした色彩設計の考え方 - くらげだらけ

                                  こんにちは、くだくらげです。最近ははじめてのUIデザインという本を共著で書きました。 おかげさまでたくさんの人に読んでいただいて、コメントをもらえたりして嬉しいです。ありがとうございます! PEAKSさんから出版しており購入できますので、よろしければ手にとってみていただけると嬉しいです。 peaks.cc 概要 WWDC 2019で新しく発表されたiOS13でOSレベルでのDarkMode設定が搭載されることになりました。MacOSの方は以前より追加されていましたが、iOSではなかったので個別のアプリが各々対応していました。 今回、iOSにもDarkMode設定が標準搭載されたことによって、iOSアプリのダークモード対応が必然的に迫られることになって来るのではないかと思っています。 ダークモードを好んで使う人は一定数存在していて、かく言う私もダークモードを好んで使っています。目に優しいだっ

                                    DarkModeのデザインを中心とした色彩設計の考え方 - くらげだらけ
                                  • これだけは知っておきたいクラス設計の基礎知識

                                    JJUG CCC 2023 Spring 発表資料(ステップアップセッション)。 私がクラス設計をするときに重視している考え方とやり方を紹介。 主な内容 ・クラス設計のスキル 3段階 ・クラス設計の技能を習得するシナリオ ・7つの基礎知識 ① 入出力と計算判断 ② プログラムの中核と周辺 ③ モジュラー性 ④ データ抽象 ⑤ カプセル化 ⑥ 契約プログラミング ⑦ 不変(イミュータブル)

                                      これだけは知っておきたいクラス設計の基礎知識
                                    • ドメイン駆動設計の正体

                                      はじめに "ドメイン駆動設計は当たり前のことを言っているだけ" "ドメイン駆動設計はただのオブジェクト指向プログラミング" "ドメイン駆動設計はより良いアーキテクチャだ" "軽量DDDはアンチパターンだ" このようなドメイン駆動設計に関する言及を聞いたことがあるでしょうか? ドメイン駆動設計に言及する記事や書籍は多くありますが、それぞれ着目する側面が異なったり色々なコンテキストから言及されています。 おそらくそれが原因でドメイン駆動設計が何であるかをぼやけさせ、正体のわかりにくい概念になっているように思えます。 そこで今回は色々な観点から整理し、ドメイン駆動設計とは何であるのか、その正体を考えていきます。 ドメイン駆動設計の基本的概念について ドメイン駆動設計はEric Evansが出版した「Domain-Driven Design」という書籍がルーツになっています。 ドメイン駆動設計を一

                                        ドメイン駆動設計の正体
                                      • 「Rustでやると知らないうちに詰む設計」を避けるためのTipsを集めてみる

                                        とりあえず、よく言われてるやつから埋めていこうと思う。 構造体にライフタイムを持たせない 構造体にライフタイムを持たせるのは「基本的に」避けよ、というのが重要なのは間違いないのだけど、これをもう少し実践的な内容にしたい。ちょっと考えてみたけど、こういうのはどうだろうか。 ある関数呼び出しの中でしか絶対に使わない。returnするまでにその構造体のデータは全て破棄される。static変数に退避させることもできない。アロケーションもその関数が面倒を見る。そういう一蓮托生できる関数呼び出しに心当たりはあるか? ある→ 構造体にライフタイムを持たせてもよい。 ない→ ライフタイム禁止。 そう考えてみると、DIとかReduxとかとも通じるところがあるかもしれない。「つべこべ言ってないで全部の責務を一番外側に持っていく」という決断ができるときは構造体ライフタイムが選択肢に入る。

                                          「Rustでやると知らないうちに詰む設計」を避けるためのTipsを集めてみる
                                        • コンテナ運用におけるログ基盤設計のベストプラクティス - Qiita

                                          課題 数年前と比較すると、GKEやECSを始めとするコンテナ実行環境でのアプリケーション運用を行うサービスはかなり増えてきた印象があります。 コンテナを運用する上では、アプリケーションのイベントを追跡する上でログをどう扱うかが課題になります。今までのように古いログを定期的にローテートして別のストレージに転送するといった手法はクラウドネイティブなアーキテクチャには最適とは言えません。 アプリケーション開発の方法論として、Twelve Factor App ではログをイベントストリームとして扱うためのガイドラインが示されていますが、近年のWebアプリケーションではシステムを疎結合に連携するマイクロサービスという考え方が主流になりつつあります。 アプリケーションログはサービスごとにフォーマットを整形した上で、ログ収集サービスに配送。必要に応じてリアルタイム分析や異常データの通知、そしてデータの可

                                            コンテナ運用におけるログ基盤設計のベストプラクティス - Qiita
                                          • ソフトウェア設計の言語化スキルを磨くこと|qsona

                                            たとえば設計について議論するときや、コードレビューで指摘をするときに、「なぜその設計が良いと思うのか?」について言語化するのが上手だと、確実に良いことがあります。 言語化が上手にできるかが一つの壁なのではないか、と感じることもあります。後輩を育てたりチームをリードするような立場になると、特に必要性を感じるのではないかなと。 自分も、うまく言語化できたことですんなり議論を進められていると感じることは多いですし、逆に直感的な良さを言語化できなかったことで直感に反する方向に進んでしまい、結果よくなかったというような苦い経験もあります。 前提: ソフトウェア設計の良さは静的には決まらない良い設計・良いコードとは何なのか。という質問に一言で答えるなら、「保守性が高い」ことだと思います。つまり、今後の変更・拡張を、高速にバグが少なく行えるような状態が良い設計・良いコードです。(一般的にはこれで70%く

                                              ソフトウェア設計の言語化スキルを磨くこと|qsona
                                            • ソフトウェア設計の学び方を考える

                                              ソフトウェア設計の学び方を考えるソフトウェア設計の 学び方を考える 2019年6月23日 ギルドワークス 増田 亨 DevLOVE X(10周年記念イベント) アジェンダ 1. 設計という課題 2. ソフトウェア設計の品質 3. 学習と成長 4. 設計の初歩を学ぶ 5. 設計の中級者への道 6. 設計の上級者への挑戦 2019/6/23 2 ソフトウェア設計という課題 2019/6/23 3 複雑さとの戦い 構成要素の数 構成要素間の関係 拡張と変更の繰り返し 2019/6/23 4 人間の知的能力の限界 構成要素の数 構成要素間の関係 拡張と変更の繰り返し 2019/6/23 5 ソフトウェア設計の品質 2019/6/23 6 構造と秩序 2019/6/23 7 時間とともに劣化する構造と秩序 2019/6/23 8 時間とともに進化する構造と秩序 2019/6/23 9 ソフトウェア設

                                                ソフトウェア設計の学び方を考える
                                              • アーキテクチャ設計における垂直思考と水平思考 - kawasima

                                                このADRをレビューするにあたっては、コンテキストのセクションもよくよく議論すべきで、意思決定が妥当かだけ見ても、「実はコンテキストに誤りやあやふやなところがありA案よりもB案の方が良かった…」みたいなことが発生するし、十分にコンテキストが理解されていない第3者や有識者をまじえてのレビューでは、レビューアに意思決定の構造を理解してもらいにくい、ということもある。

                                                  アーキテクチャ設計における垂直思考と水平思考 - kawasima
                                                • ソフトウェア設計・アーキテクチャの学び方 - Qiita

                                                  はじめに この記事はHow to Learn Software Design and Architecture | The Full-stack Software Design & Architecture Mapを翻訳したものです。 翻訳がおかしい箇所などあればご指摘頂けるとありがたいです。 元記事の著者: Khalil Stemmler(@stemmlerjs) 設計、アーキテクチャ、フロントエンド、ブロックチェーンに興味ある方是非Twitter(@show_clements)フォローしていただけると嬉しいです! 設計に関する記事 ソフトウェアデザインとアーキテクチャは、DevOpsやUXデザインのように、コンピューティングの領域の中でも独自の研究分野となっています。ここでは、クリーンコードからマイクロカーネルまで、ソフトウェアデザインとアーキテクチャの幅広さを説明するマップを紹介しま

                                                    ソフトウェア設計・アーキテクチャの学び方 - Qiita
                                                  • 設計の学び方:自分流のススメ

                                                    BPStudy#178〜成長し続け、変更を楽に安全にできるソフトウェア設計とは 株式会社ビープラウドが主催するIT勉強会  2022年6月30日 設計を学ぶのは自分のため 「正しい」学び方があるわけではない 設計の学びに特定の到達点はない 何を学ぶのか 設計の学び方 上達する:練習して変化する 成長する:時間をかけて変化する ひらめき:突発的に変化する

                                                      設計の学び方:自分流のススメ
                                                    • 設計要件をギッチギチに詰めたValueObjectで低凝集クラスを爆殺する - Qiita

                                                      /// <summary>契約金額</summary> public class ContractAmount { public int AmountIncludingTax; public decimal SalesTaxRate; } 当然データの入れ物(以後データクラスと呼称)だけでなく、税込み金額を計算するロジックが必要です。ここであまり設計を考えないと、この手の演算ロジックはデータクラスとは別のクラスに実装されることが多いです。以下のようにControllerに実装されることが多いのではないでしょうか。 /// <summary>契約コントローラー</summary> public class ContractController { private ContractAmount _contractAmount; /// <summary>税込金額を計算する。</summary>

                                                        設計要件をギッチギチに詰めたValueObjectで低凝集クラスを爆殺する - Qiita
                                                      • マイクロソフト、半導体を自社設計へ サーバーやPCに=関係筋

                                                        米マイクロソフトが、クラウドサービス向けのサーバーとパソコンの「サーフェス」に、自社で設計・開発したCPU(中央演算処理装置)を搭載する計画を進めていることが分かった。写真はニューヨークで2015年に撮影(2020年 ロイター/Mike Segar) [18日 ロイター] - 米マイクロソフトが、クラウドサービス向けのサーバーとパソコンの「サーフェス」に、自社で設計・開発したCPU(中央演算処理装置)を搭載する計画を進めていることが分かった。事情に詳しい関係者が明らかにした。

                                                          マイクロソフト、半導体を自社設計へ サーバーやPCに=関係筋
                                                        • 24時間365日動き続けるデータシステムの設計手法 : 「データ指向アプリケーションデザイン」実践編

                                                          「データ指向アプリケーションデザイン」をベースに、24時間365日動き続けるデータシステムを実装する際に必要となる技術や考え方を紹介します。 この資料は、2023年大阪大学大学院 情報科学科 マルテメディア工学特別講義で使われた資料を一般用に修正して公開しています。 参考: 「30分でわかるデータベースデザイン」https://speakerdeck.com/xerial/30fen-dewakarudetazhi-xiang-apurikesiyondezain-data-engineering-study-number-18

                                                            24時間365日動き続けるデータシステムの設計手法 : 「データ指向アプリケーションデザイン」実践編
                                                          • 実践! Typescript で DDD - マイクロサービス設計のすすめ - Leverages Tech Blog

                                                            対象読者 マイクロサービス化を検討しており、実際に作る場合の構成を参考にしたい。 ドメイン駆動設計について、基本的な用語の知識がある。 TypeScript を多少触ったことがある。理解がある。 はじめに こんにちは。エンジニアの吉村です。 現在、弊社が運営する teratail というサービスに携わっており、CakePHP で動作しているモノリシックな既存サービスをマイクロサービスに移行するというプロジェクトを進行中です。 この記事では、実務を通して得た知見として、マイクロサービス化によりどんな恩恵があるのか、具体的にどのような構成で実装をしているのかについてご紹介します。 TL;DR マイクロサービスのバックエンドサービスの実装に焦点を絞って、ドメイン駆動設計 + オニオンアーキテクチャをベースに設計をしました。 本記事では、具体的に「ユーザ新規登録処理」の実装をする場合を例にとり、実

                                                              実践! Typescript で DDD - マイクロサービス設計のすすめ - Leverages Tech Blog
                                                            • 宣言的UIはReact Hooksで完成に至り、現代的設計論が必須の時代になる - Qiita

                                                              この記事は、ある程度以上の規模のGUI開発において、React Hooks以後の宣言的UIにより、大規模開発に用いられる設計論に完全に対応できるようになり「ビジネスロジックの変更や追加」に対応するコストを低く保つこと(技術的負債の抑制)ができるようになったことを解説するものです。 技術的負債の抑制には、技術的負債の原因となりがちな「広範囲の密結合」と「適切な疎結合を保つ仕組みの欠如」が欠かせません。それをカバーするのが、大規模開発をクリーンに行える設計論(ここでは「現代的な設計論」とよぶもの)です。クリーンアーキテクチャなんかでGUIによく適用されるHumble Object Patternのようにプレゼンテーションとビューを分離する必然性が無くなるでしょう。 ポイントは ある程度以上の規模で開発するなら設計論をうまく使い設計しないと、技術的負債を抱え込む(ビジネスロジックの変更や追加に対

                                                                宣言的UIはReact Hooksで完成に至り、現代的設計論が必須の時代になる - Qiita
                                                              • AWSのネットワーク設計をしくじって復旧に苦労した話

                                                                2019年8月2日、インフラストラクチャエンジニアやネットワークエンジニア向けの勉強会「インフラ・ネットワークエンジニア勉強会」がアイスタイル株式会社で開催されました。同会では、AWSに関するインフラ・ネットワーク視点の話や、オンプレ環境の話など、過去の事例を共有。6人のエンジニアが成功・失敗談をシェアしました。「ネットワークしくじり先生」に登壇したのは、kaga氏。講演資料はこちら ネットワークしくじり先生 kaga氏:それでは、「ネットワーク設計アンチパターン」という話をさせていただきます……と思ったんですけれども、ちょっとタイトルが堅いので「ネットワークしくじり先生」に、ちょっとやさしい雰囲気に変えたので、肩の力を抜いて聞いていただければなと思います。よろしくお願いします。 (会場拍手) 自己紹介です。kagaといいます。もともとQAを5年やって、サーバサイドを3年やって、今はインフ

                                                                  AWSのネットワーク設計をしくじって復旧に苦労した話
                                                                • 実践:はじめてのWebAPI設計 - Qiita

                                                                  はじめに この記事はAPIの基本的な実装方法を丁寧に解説します。基礎を学びたい方、今更聞けないような知識の振り返りを求める方の役に立つことを願っています。もう十分理解できている!という方は、目次から実装にとんでみてください。 具体的にはHTTPと呼ばれる通信方法を利用した、シンプルな本の貸し出しシステムの土台を考えます。要件の各ステップで、設計の基本原則やベストプラクティスについても触れながら、より実践的な知見を共有できればいいなと思います。 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています!興味をお持ちいただける方は、こちらまで。 基本用語 Webに関する基礎知識の解説記事はQiitaに豊富にあったので、要点を抑えつつリンクをまとめました。 WebAPI Web

                                                                    実践:はじめてのWebAPI設計 - Qiita
                                                                  • 欧州にて「バッテリーを容易に取り外して交換できる製品設計」をメーカーに義務付けへ。携帯型ゲーム機も対象との報道 - AUTOMATON

                                                                    🔋 Greener batteries ♻️ More recycling 🚯 Less pollution The Council has adopted today new rules that will, for the first time ever, cover the whole life cycle of batteries. The goal is to make batteries sustainable while keeping the sector competitive. 👇 — EU Council (@EUCouncil) July 10, 2023 今回欧州評議会が採択した新たな規制は、バッテリーの製造からリサイクルまでのライフサイクル全体を見直し、循環型経済を促進することを目的にしているという。そのなかで、家電製品などに搭載されるバッテリーについて、

                                                                      欧州にて「バッテリーを容易に取り外して交換できる製品設計」をメーカーに義務付けへ。携帯型ゲーム機も対象との報道 - AUTOMATON
                                                                    • UI改善のためにエンジニアに仕様を構造化してもらったら再設計がめちゃくちゃ捗った話|鈴木 健一 / PLAID & Ex.STANDARD

                                                                      この記事はPLAID Advent Calendar 9日目の記事ですUI改善の前提理解、うまくできていますか?皆さんはこれまで着手してこなかった既存画面のデザイン改善をする時、どのように進めているでしょうか。 自分がプレイドで所属しているreBAISUというチームでは、タタキとして定義したスタイルガイドを旧来の画面に適用しながらUI改善する取り組みをしています。 取り組み方として、改善対象となる画面の仕様を理解しながら課題を見つけ、解決策を検討していく流れになるのですが、この仕様理解が難しいと感じていまして。 なんとか前提理解を促せる方法はないものかと検討した結果、対象画面の構成要素をひとつずつ紐解いていく方法で理解していく「デザインの逆行分析」という方法をとっていました。 デザインの逆行分析とは「リバースエンジニアリング」とも呼ばれる手法で、その考えをデザインでも応用しようというもので

                                                                        UI改善のためにエンジニアに仕様を構造化してもらったら再設計がめちゃくちゃ捗った話|鈴木 健一 / PLAID & Ex.STANDARD
                                                                      • 「運用組織」の考え方と設計 〜 運用組織論 2021 / 20210310-ssmjp-operation-organization

                                                                        ssmjp ssmonline #8 "第三回はたのさん祭 オンライン"( https://ssmjp.connpass.com/event/206074/ )での発表資料です。 (運用設計ラボ合同会社 波田野裕一)

                                                                          「運用組織」の考え方と設計 〜 運用組織論 2021 / 20210310-ssmjp-operation-organization
                                                                        • 超入門!テーブル設計をデータモデリングから考えよう

                                                                          基本から学ぶ テーブル設計 超入門! 〜データモデリングとテーブル設計の基本を学ぼう〜 https://modeling-how-to-learn.connpass.com/event/242944/ にてお話した際のプレゼン資料です。 入門者に向けて、テーブルを設計する上でモデリングすると良いよという話をしました。(熟練者は、そうだよねーっておさらいするか、そこは別の考え方があるんじゃないなどを呟いて貰えればといった内容です) モデリングして設計する際に、色々なモデルがあります。その中で、データモデルは静的な要素が強いモデルなので、モデリング全般を考えた際に、入門者にとって捉えやすいのではと考えています。 テーブルを設計する上で、データモデリングをしてデータモデルを作ることで、より良いテーブル構造を考えやすくなります。 #テーブル設計 #モデリング #データモデル #RDRA #概念モデ

                                                                            超入門!テーブル設計をデータモデリングから考えよう
                                                                          • 【入門】基本設計

                                                                            はじめに プロジェクトマネジメントの仕事をする際に、お客さんに提案ベースの要件定義や設計をする機会が増えてきたので、私の経験に基づいて基本設計の具体的なプロセスや考え方について、整理していきます。 以前投稿した記事の続きですが、未読でもこの記事を理解できるようになっています。 この記事の対象者 基本設計の思考プロセスを学びたい人 ビジネスサイドの要件をエンジニアサイドのシステムに落とし込む流れを学びたい人 ビジネスサイドとエンジニアサイドのコミュニケーション能力を向上させたい人 具体的な事例を通して基本設計を学びたい人 前提 紹介する内容はあくまで一例であり、プロジェクトやチームの状況に応じて調整が必要です 自分の経験に基づいた内容を言語化しています プロジェクト規模は10名から20名のシステム開発を想定しています(大規模なプロジェクトを想定していません) システム開発の全体像 今回は下記

                                                                              【入門】基本設計
                                                                            • 設計書には何を書くべきなのか - terurouメモ

                                                                              設計とは、 要求(やりたいこと)をヒアリングする 要求を要件(何を満たさないといけないのか)に落とし込む 要件を実現するために考えられる手段を洗い出す 手段の検証を行う 検証結果を元に、どの手段を使うかを選定する 選定した手段を合意する(一部要件を満たさない事項がある場合は、代替策や妥協ラインについても合意する) 合意内容を元に、実装や設定に落とし込む をやることである。画面設計や機能設計のように、3-5の検証/選定が薄くなったり曖昧になったりするものはあるが、一般化するとこの流れになる。 設計書には、上記の設計でやってきたことを順番に書いていけばよい。これを文章構成のテンプレに落としていくと、 要求 要件 方式 対応案(いわゆる比較表で書いていくのが楽) 検証結果 選定・合意結果(合意した代替策や妥協ラインについても記載する) 詳細設計(どういう実装にするとか、パラメーターにするとか、細

                                                                                設計書には何を書くべきなのか - terurouメモ
                                                                              • オブジェクト指向プログラミングを学ぶための推薦図書 - ソフトウェア設計を考える

                                                                                オブジェクト指向プログラミングを学ぶ オブジェクト指向プログラミングという言葉は、広い意味で使われている。 オブジェクト指向プログラミングをキーワードにすべての情報をかき集めて理解するというアプローチは現実には無理。 目に付いた重要そうなところを見繕って集めてみても、たぶん混乱するだけ。 この記事では、オブジェクト指向プログラミングのいろいろなアプローチの中で、 クラスを使って独自の「型」を定義するプログラミングスタイル 関連するデータとロジックをまとめて、小さな入れ物に格納する「カプセル化」を重視するプログラミングスタイル を学ぶための参考図書を紹介したい。 型とカプセル化に重点を置く設計スタイルがわかってくると、それとは異なるスタイル、異なる力点を置くアプローチとの違いが具体的にわかるようになってくる。*1 *2 まずは、オブジェクト指向プログラミングの中で、型・クラス・カプセル化に力

                                                                                  オブジェクト指向プログラミングを学ぶための推薦図書 - ソフトウェア設計を考える
                                                                                • ぼく「嫌な予感がするから警告いっぱい出したれ」データ削除は三重確認設計に→??「なんかデータ消えたんですけど?」

                                                                                  ワープくん🤡 @warpbtn ぼく「なんか嫌な予感がするから警告いっぱい出したれ」 『このデータを削除すると復活できませんが本当に削除しますか?YES/NO』 『あなたは削除データが復活できないことを確認しました。YES/NO』 『以下の入力欄にDELETEと入力して削除を実行』 ???「なんかデータ消えたんですけど?」 2020-03-12 11:13:24

                                                                                    ぼく「嫌な予感がするから警告いっぱい出したれ」データ削除は三重確認設計に→??「なんかデータ消えたんですけど?」