なぜ MVVM + FRP は Elm Architecture に勝てないのか - dely Tech Blog
こんにちは、delyでクラシルiOSアプリ開発を担当している稲見 (@inamiy)です。 この記事は「dely #2 Advent Calendar 2020」の25日目の記事です。 dely #1 Advent Calendar 2020 dely #2 Advent Calendar 2020 昨日は、delyのSREチームのjoooee0000(高山)さんによる delyのSREチームがオンコールトレーニングを導入する3つの理由 の記事でした。 オンコール対応できるエンジニア、強くてカッコいい・・・ 私の方からは、メリークリスマス🎄🎅🔔 にふさわしい Elm Architecture による unidirectional なプレゼントをお届けします🎁 (2020/12/26 EDIT: タイトルを「なぜ MVVM は Elm Architecture に勝てないのか」から「
コスト効率の悪いLambdaアプリケーションの性質に関する考察 - ゆううきブログ
概要 Lambdaは100msの実行時間単位でオンデマンドに課金されるため、立ち上げっぱなしのEC2インスタンスよりも、料金が安くなる可能性があることが一般に知られている。 しかし、以下の性質を満たすアプリケーションでは、EC2インスタンス上に構築したケースと比較して、Lambda上に構築したほうがコスト効率が悪くなるのではないかと考察してみた。 Lambda functionの実行時間のうち、ネットワークI/O時間が支配的である Lambda functionの実行終了を同期的に待たなければならない 複数のレコードをLambda functionの引数に渡すことができない Lambdaの基本コスト構造 まず、Lambdaのコスト構造を把握する。 Lambdaの料金表[1]によると、「functionに対する合計リクエスト数」と「functionの合計実行時間」に応じて料金が発生する。 後
Repositoryの後ろにネットワーク越しのシステムがあることの是非からRedux的世界へ - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
twitterで言ってたことを少し修正してまとめ。MVVM + Layered Architectureの文脈です。 最近、Repositoyとして抽象化しておけばそのデータがメモリ上にあるかそれともDB上にあるかネットワーク越しにあるか意識しなくていい、というのは嘘だと思ってる。パフォーマンスの観点除いても。 というのは、リポジトリが「非同期クエリ」を受け付け始めると、ReadStackの複雑性が跳ね上がるというのがあるからなんだけど、そもそもRepositoryへのクエリは必ず非同期であるというインターフェースにすればこれは問題にならないのかな リポジトリを基本非同期に設計してもいいんだけど、そうすると同期的な表示を求めてくるUIプラットフォームと相性悪くなるんだよな たとえばMVVMで考えると、モデルのイベントを購読して、イベント来たらクエリ投げてモデル以下にある状態を読み出してきて
マイクロサービスはもう十分 | プロダクト・サービス | POSTD
モノリスとして管理するには複雑すぎるというシステムでない限り、マイクロサービスは検討さえしなくていい。ソフトウェアシステムの大多数は、単一のモノリシックアプリケーションとして構築されるべきである。そのモノリス内のモジュール性が良好になるよう注意を払う必要はあるが、別個のサービスに分けようとしてはいけない。要旨 モノリスとして管理するには複雑すぎるというシステムでない限り、マイクロサービスは検討さえしなくていい。ソフトウェアシステムの大多数は、単一のモノリシックアプリケーションとして構築されるべきである。そのモノリス内のモジュール性が良好になるよう注意を払う必要はあるが、別個のサービスに分けようとしてはいけない。 – Martin Fowler 明確に構造化されたモノリスを構築できない時、なぜマイクロサービスがその答えだと思うのか。 Simon Brown 始めに マイクロサービスの利点と欠
例えば OSFA な API をやめる - @kyanny's blog
OSFA == one-size-fits-all 単一の API で全てをカバーするのをやめたらどうか、ということ。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight @kenn 最近はRESTfulなエンドポイントは完全に後方互換なまま、クライアントごとにオーケストレーション層(radical versionin)を設けるという方向にシフトしようとしている。詳しくは http://t.co/zODm7mFr5B— Tatsuhiko Miyagawa (@miyagawa) February 28, 2014 この話のポイントとはちょっとずれてる && Podcast 聴いてないのですが。 Quipper プラットフォームで内部的に利用されている API も、 /v1 というパスの下にはえててごく一部のエンドポイントだけ /v2 がある、み
はてなで大規模サービスのインフラを学んだ - ゆううきブログ
中〜大規模サービスのインフラの様子を知りたいアプリケーションエンジニア向けに、もともとアプリケーションコードを書いていた視点から、個人的な体験をベースにはてなで大規模サービスのインフラを学んだ過程や学んだ内容の一部を紹介します。 Webアプリケーションのブラックボックス Webアプリケーションフレームワークの向こう側 なぜ複数のサーバが必要なのか 突然のWebサービス3層構成 リバースプロキシ アプリケーション データベース その他のコンポーネント キャッシュは麻薬 飛び道具としてのKVS/NoSQL 非同期処理 バッチ処理 Mackerelの場合 参考 まとめ Webアプリケーションのブラックボックス 今年もはてなインターンの時期が近づいてきた。 毎年ではないけど、はてなインターンでは「インフラ講義」というのをやっている。 今年はインフラ講義の講師としてアサインされたのでちょうど何を話そ
James Lewis/Martin Fowlerの"Microservices"日本語訳 - 自由課題
はじめに 本記事はMartin Fowler氏のBlog記事を日本語訳したものです。 なお、訳は2014/11/09時点のもので、オリジナル記事中のコラムは訳せていません。コラムの訳に関しては、暇や反応を見ながらぼちぼちやろうと思います。 訳に対する指摘・ご意見などありましたらtwitter(@kimito_k)でお願いします。 補足 Martin Fowler氏に連絡をとったところ、主著者はJames Lewisであるとのことでしたのでタイトルを変更しました。(2014/11/13) Microservices "マイクロサービスアーキテクチャ"という専門用語は、ソフトウェアアプリケーションを独立して配置可能なサービスの組み合わせ(suite)として設計する特定の方法を指すものとして、ここ数年で急速に認知されています。このアーキテクチャスタイルに対する正確な定義はありませんが、ビジネス遂
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RxJSを活用したAngularアプリの状態管理設計 by adwd