タグ

2020年10月23日のブックマーク (11件)

  • Railsで考えるドメイン駆動設計のコアドメイン

    銀座Rails#26の登壇資料です https://ginza-rails.connpass.com/event/189892/

    Railsで考えるドメイン駆動設計のコアドメイン
  • React / Redux を実務で使うということは

    注意 この記事に書いてあることは古い情報になっている可能性があります 最近ReduxToolkit周りの進化がめざましく、更に追加されたReduxのドキュメントの項目がかなりわかりやすく書かれているため、基的にこちらを推奨します 既にRTKなどの概要を知っているひとは特に Tutorials > Redux Essentials のセクションを読んでほしいです こんにちは、すずです Reactを使い始めて2年半経ち、その間に3つのサービス(SPA)を立ち上げてきました その経験から、 React や Redux を実務でしっかり使ってく上でのノウハウを紹介していきます (この記事ではある程度ReactやReduxの記事・ドキュメントを読んだ初学者を対象としています) 序 フロントエンド、モノを作ったはいいものの、「変更しづらい」「スケールしない」「この作りではパフォーマンスが出ない」って

    React / Redux を実務で使うということは
  • フロントエンド開発環境の継続的なリファクタリング | MEDLEY Developer Portal

    2020-10-20フロントエンド開発環境の継続的なリファクタリングこんにちは、第二開発グループエンジニアの西村です。主にCLINICSの開発を担当しています。 はじめにCLINICS は電子カルテ、オンライン診療、予約システム、患者アプリなどを含む統合アプリです。CLINICS がローンチしてから現在に至るまで常に新機能開発と定常改善が行われており、開発環境のメンテナンスは後手になりがちでした。今回はそういった状況を改善すべく、開発環境のメンテナンス、リファクタリングを行った過程から得られたプラクティスについて紹介していこうと思います。 モチベーションプロダクトの新規開発時に行われる技術選定は非常に難しく、業務要件やチーム状況など総合的に考慮してその時点でのベストな選択をする必要があります。 しかし、選択した技術で長期運用をしていくうちに、メンテナンスが行き届かなくなったコードやライブラ

    フロントエンド開発環境の継続的なリファクタリング | MEDLEY Developer Portal
  • The Service Mesh Manifesto

    The only service mesh small and fast enough for edge workloads

    The Service Mesh Manifesto
  • サービスメッシュとは | Red Hat

    オープンソース・プロジェクトIstio を始めとするサービスメッシュは、アプリケーションのさまざまな部分が互いにデータをどのように共有するかを制御する方法です。サービスメッシュはアプリケーションに直接組み込まれた専用インフラストラクチャ層であり、この点は同様に通信を管理するその他のシステムとは異なります。このインフラストラクチャ層は、アプリケーションの各種の部分の間の通信状況を文書化するため、通信を最適化し、アプリケーションを拡張するときのダウンタイムを防止することが容易になります。 アプリケーションの各部分は「サービス」と呼ばれ、他のサービスを利用してユーザーに必要なものを提供します。オンライン小売アプリのユーザーが何かを購入しようとする場合、商品の在庫があるかどうかを知る必要があります。そこで、企業のインベントリー・データベースと通信するサービスは商品の Web ページと通信する必

    サービスメッシュとは | Red Hat
  • サービスメッシュの比較Istio vs. Linkerd vs. Envoy (前半)

    今回は、3つのサービスメッシュの比較をしていきたいと思います。長い記事なので2回に分けてお送りします。今回はトラフィック管理、セキュリティ、ロギング面での比較をします。 簡単に言えば、サービスメッシュは、プラットフォームで実行されているアプリケーションのネットワーク機能を処理するものです。 Kubernetesテクノロジーとして成熟するにつれて、サービスメッシュが話題になり、トラフィック管理、セキュリティ、観測性などの分野に関連する課題を解決するためにさまざまな製品が開発されています。こういった内容をしっかりと理解するには、徹底的なサービスメッシュ比較をしてみると分かりやすいです。 この記事では、3つのサービスメッシュを比較してみたいと思います。まず、サービスメッシュスペースの最大手、Istioです。2017年5月にGoogle、IBM、Lyftによってオープンソース化され、その後多くの

  • 運用視点なMyISAMとInnoDBと。 – LexTech

    MySQL5.5からトランザクション処理ができるInnoDBがデフォルトストレージとなりましたし、とりあえずInnoDBにしとこうという風潮から、ストレージがInnoDBであることも多いのですが、実は蓋を開けて見るとまだまだMyISAMで動いているサービスがたくさんあります。今回は運用面から見た両者の違いをみてみたいと思います。 同じMySQLですが、InnoDBの運用とMyISAMの運用は注意するポイントが違います。 ロック方式 一番大きい違いはロック方式の違いでしょうか。InnoDBは行ロック方式(*1)、MyISAMはテーブルロック方式です。データをINSERTやUPDATEする時はセマフォ制御のためロックされますが、その時の挙動が違います。 たとえばUPDATEのクエリを投げると、MyISAMの場合は対象テーブル全体がロックされ、その後のクエリが”詰まり”ます。なので重いクエリを発

  • 再考 - ドメインサービス  - まっちゅーのチラ裏

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

    再考 - ドメインサービス  - まっちゅーのチラ裏
  • GoのテストをCIで簡単に並列実行する | おそらくはそれさえも平凡な日々

    https://github.com/Songmu/gotesplit gotesplitというかなり便利なツールを書いた。Goのテストをいい感じのサブセットに分割して、それを実行するものです。このアプローチで、社内のテストを15分から3分くらいまでに短縮しました。 これを使えばCI環境での高速なテストの並列実行を簡単に実現できます。 実例 CircleCIGitHub Actions上で簡単に導入できます。 CircleCIの場合 parallelism: 5 docker: - image: golang:1.15.3 steps: - checkout - run: command: | curl -sfL raw.githubusercontent.com/Songmu/gotesplit/main/install.sh | sh -s bin/gotesplit ./... -

    GoのテストをCIで簡単に並列実行する | おそらくはそれさえも平凡な日々
  • テスト、正常系から書くか異常系から書くか - hitode909の日記

    今週は同僚と毎日長時間ペアプロしていた。 おもしろかったのが、同僚のテストの書き進め方で、一番複雑な正常系のテストをちゃんと書いてから、その複雑なテストをもとに、いろんな条件を削っていって異常系のテストを作っていく、というところ。 僕は逆で、入力が空なら何も起きない、とか、一番簡単な異常系のテストを書いて、そこだけ通るのを確認して、よしよし、と進めていって、メソッド来の動きは最後に確認して終わる。 変な進め方だな〜(主観)と思って眺めていたけど、たしかに正常系のテストが通っていれば、あとはバリデーションまわりのチェックとか、例外となる場合のチェックをすれば終わりで、異常系のテストがすごい速さで書かれていておもしろかった。 …という話をしたら、チームメンバーたちは正常系のテストから書きはじめるという人が多くて、正しくことを確認してから、1個ずつ前提となる条件を外してみて試す、と聞いて、同値

    テスト、正常系から書くか異常系から書くか - hitode909の日記
  • スタディサプリENGLISHの基盤をECSからEKSに移行しました | Recruit Tech Blog

    こんにちは、スタディサプリ ENGLISH SREグループの大島です。 オンライン英語学習サービスであるスタディサプリ ENGLISHは2015年10月のリリース1)当時は英語サプリという名前でリリースしていましたから5年が経ち、おかげさまでサービスを拡充させることができています。リリース当初からインフラにはコンテナを採用し、長い間AWSのコンテナオーケストレーションサービスのAmazon Elastic Container Service(以下、ECS)で運用してきましたが、この度ECSからAmazon Elastic Kubernetes Service(以下、EKS)に移行しました。 今回の記事では、その歴史の変遷となぜEKSにしたのかというところを書いていきたいと思います。 コンテナと歩んできた5年間 まず、ECSからEKSに移行しようと思ったきっかけの前に、インフラの歴史を少し振

    スタディサプリENGLISHの基盤をECSからEKSに移行しました | Recruit Tech Blog