マルチスレッド・プログラミングの目的はパフォーマンス向上 マルチスレッド処理の目的を、ツリー状に図解してみた。マルチスレッドの目的であるパフォーマンスの向上を詳しく分類すると、レスポンス・タイムとスループットの向上の2つに分類することができる。 マルチスレッド・プログラミングを行う目的と手段 マルチスレッドで実現するパフォーマンス向上は、レスポンス・タイムの向上とスループットの向上に分けることができる。 以下では、レスポンス・タイム向上とスループット向上について、それぞれ詳しく見ていく。 ■レスポンス・タイムの向上 マルチスレッド・プログラミングでパフォーマンスを向上できる効果の高いパターンが、レスポンス・タイムの向上である。レスポンス・タイムとは、処理のリクエストを出してから、最初の反応が返ってくるまでの時間である。例えば、マウスをクリックしてから、その反応を画面上で認識できるまでの時間
難解なマルチスレッド・プログラミングを基礎から解説。まずはその動作原理を理解し、活用すべき場面を見極める。 連載目次 シングルスレッドとマルチスレッド コンピュータのプログラムは、基本的に1行ずつコードが実行されながら動作する。通常、分岐やループがあっても、プログラム全体は1つの流れになっている。このような一連のプログラムの流れを「スレッド」(Thread:「糸」などの意味)と呼び、1つのスレッドだけからなるプログラムを「シングルスレッドなプログラム」という。たいていのプログラミングでは1つの処理の流れを記述するが、このようなプログラムはシングルスレッドなプログラムに該当する。 一方、プログラムによっては、処理効率を上げるなどの目的で、複数の処理を並行して行うことができる。つまり、1つのプログラムで複数のスレッドを同時に実行することができるのである。このようなプログラムを「マルチスレッド・
I'm trying to brush up on my design pattern skills, and I'm curious what are the differences between these patterns? All of them seem like they are the same thing - encapsulate the database logic for a specific entity so the calling code has no knowledge of the underlying persistence layer. From my brief research all of them typically implement your standard CRUD methods and abstract away the data
カケハシの医薬品発注管理最適化領域の新規事業の開発を担当している木村です。今回は新しいサービスを構築する上で行った技術選定と実践方法の話をします。 技術選定に関しては、インフラ関連やライブラリなど選定した技術は多岐にわたるのですが、その中でも「なぜバックエンドでTypeScriptを導入したか」を中心にお話します。2つのチームでの技術選定に関わり、どちらもTypeScriptを導入するに至りました。2022/03時点では社内の5つのサービスでバックエンドTypeScriptが採用されていることを観測しています。 実践方法に関しては、技術選定の過程で明らかになったシステム特性に対するアプローチを紹介します。 全社的な技術選定方法 カケハシではビジネスドメインで開発チームを分割し、開発チームが自走化できるように組織がデザインされています。技術選定についても開発チームに裁量があります。 技術選定
この記事では、CQRSの入門として、軽量CQRS、別名クエリモデルについて解説します。 DDDの参照系処理で発生する課題 解決策 CQRSのメリット、デメリット 実装時の注意事項 部分的導入について なぜQueryServiceの定義がUseCase層なのか 整合性をどうやって担保するのか よくある誤解 データソースを分ける必要があるのか イベントソーシングとの関係 過去資料との繋がり もっと詳しく知りたい方は 現場での導入で困ったら DDDの参照系処理で発生する課題 DDDで定義されている実装パターンを使っていると、基本的には永続化層との入出力はRepositoryを使うことになります。 更新系の処理ではEntityやValueObjectでドメインの知識を表現し、Repositoryを使って集約単位で永続化するという構成をとると、非常にメンテナンス性の良いものになります。 参考過去記事
JSConf JP 2021 で登壇した資料です #jsconfjp #jsconfjp_b Links: [Active Recordから考える次の10年を見据えた技術選定](https://speakerdeck.com/yasaichi/architecture-decision-for-the-next-10-years-at-pixta) [GraphQL を活用したスキーマ駆動開発の実践](https://speakerdeck.com/qsona/schema-driven-development-with-graphql) [GraphQL を利用したアーキテクチャの勘所 / Architecture practices with GraphQL - Speaker Deck](https://speakerdeck.com/qsona/architecture-pract
初めまして、qsona (tw) と申します。Ruby on Rails Advent Calendar 2016 6日目の記事になります。 Rails歴は10ヶ月で、もちろんAdvent Calendarへの参戦も初です。 全体的に生意気な内容と思いますが、 じゃんじゃんマサカリ投げてください お手柔らかにお願いします。 はじめに 環境 JSONを返すAPIで、データベースはRDBを想定してます。 あんまり関係ないですが一応、Rails5 (api mode) + MySQLを想定しています。 マイクロサービスとしてのバックエンドに使う技術スタックの必要な要件 マイクロサービスの良いところは、サービスごとに合った別々の技術が使えるということです。 とはいえ、一般的な組織であれば、学習コストの面などから、ファーストチョイスとなる言語があり、普通の要件に対してはその言語を使う、ということにな
技術開発本部の qsona です。 先日、 ぎんざRuby会議01 というミートアップが開かれました。これは、弊社の技術顧問のwillnetさんを含む3人の方によって運営されている Ginza.rb というコミュニティの50回目を記念して開かれたものです。 このミートアップにCFPを投稿し、採択いただきました。かなりの高倍率の中、目にとどめていただけたこと、また普段お世話になっているコミュニティの節目の会での発表の機会を頂けるということで、非常に有り難いことでした。 発表資料以下がその発表資料です。また、引用した文献をこの下に列挙したので、適宜ご参照ください。 引用文献p3 マイクロサービス時代に捧ぐ、Railsでの中規模APIサーバ開発のための技術構成 — qsona (Qiita) p27 step-by-step BFF — Yosuke Furukawa (Speaker Deck
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く