ネットワーク越しリトライ考 - その手の平は尻もつかめるさ
ここ最近では何らかのインターネットサービスを構築・運用するにあたって、ネットワーク越しのリトライを考えることは避けられなくなりつつあります。 micro services のようなアーキテクチャを採用している場合はサービス間のメッセージのやり取りはまず失敗する前提 (つまりリトライをする前提) で組む必要がありますし、たくさんのクライアントがいてそのクライアントが定期的に何かを処理してセントラルにデータを送ってくる IoT のようなシステムを構築する時もその処理のリトライをよく考える必要があります。 というわけで「ネットワーク越しのリトライ」についてここ最近考えていることをざっくりと書き留めるものであります。 前提 リトライをする側をクライアント、リトライを試みられる側をサーバと呼称します リトライにおいて、サーバおよびネットワークはクライアントよりも弱者です クライアントはリトライをコン
Smart UI パターンが再評価される世界 - id:onk のはてなブログ
設計ナイト2020 を受けて、今どんなアーキテクチャを選ぶべきかという話をしたくなったのだ。 kichijojipm.connpass.com 設計ナイトで高ぶった結果1時間コースの発表資料が完成したので供養場所を探しています。聞いてくれ！！！— Takafumi ONAKA (@onk) 2020年11月1日 お前誰よ 2000年代前半に SI 2000年代後半にブログ、SNS 2010年代にソーシャルゲーム 2020年代に UGC サービス をやってきた人間。数百万〜数億行のデータ、月間数千万〜数十億 imp 程度を主戦場にしています。 今日の話 DDD と PofEAA から学ぶパターン/アンチパターン Rails によって発見された、密結合で速く走れるソフトウェア 今求められているアーキテクチャ 昂ぶって 15,000 字ぐらい書いてしまった。 DDD と PofEAA から学ぶパ
ウェブフロントエンドの設計力を高めるためにアプリケーションの構造を捉えてみる話 - kubell Creator's Note
こんにちはー。 フロントエンド開発部の火村(ひむら/id:eiel)です。前回までは id:cw-himura で記事を書いていましたが、個人アカウントに切り替わりました。 よろしくおねがいします。 以前はサーバーサイド開発部に所属していましたが、2019年6月ぐらいからフロントエンドチームにヘルプとして無期限レンタル移籍中です。 主な担当している業務は「難しいバグ対応」と「これからChatworkのウェブフロントエンドをどうするかを考える」です。 昨日は期待の新人であるレオくんの入社して3ヶ月の熱烈な想いでした。アツいです。 さて、今回のお題は「レガシーフロントエンド脱却への挑戦」と雑に上から投げられたのですが、未来のことを考える作業をしているので書きやすいネタがありません。 あってもオチがつきません。 ということで、設計に役立つかもしれない話をラフに書くことにしました。 アプリケーショ
OpenAPIでAPIドキュメントを初めて作るときに読む資料
OpenAPIを使ってAPIドキュメントを初めて作るときに参考になった資料をまとめました。 最初に読む資料 Swagger ではない OpenAPI Specification 3.0 による API サーバー開発 OpenAPIとはなんぞや？すこし前に話題になったSwaggerとの違いは？どのように書いていけば良い？などをざっくり頭に入れられる資料です。 スキーマファースト開発のためのOpenAPI（Swagger）設計規約 ざっくり記法が分かる記事です。OpenAPIはyamlファイルでの記述が基本ですが、後述する Stoplight Stadio というGUIエディターを使うと、比較的楽に作成管理ができます。 エラーレスポンス OpenAPIというよりAPIそのもののエラーレスポンスの設計思想についてです。 REST API Error Handling Best Practices
マイクロサービス設計原則: 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
Microservices分割大全 - kawasima
Microserviceの分割の仕方について語られているものを収集します。 microservices.ioのサイトに載っている分割パターンは4つ。ただし「自己完結型サービス」と「チームごとのサービス」は、直交していないので大きくは「ビジネスケイパビリティでの分割」と「サブドメインでの分割」の2つ。 ビジネスケイパビリティでの分割 https://microservices.io/patterns/decomposition/decompose-by-business-capability.html 現在の業務機能にしたがってサービスを分割する。 したがって、コンウェイの法則にしたがった分割とされる。 サブドメインでの分割 https://microservices.io/patterns/decomposition/decompose-by-subdomain.html DDDのサブドメ
可変データ構造をRDBに保存する方法について
質問をすることでしか得られない、回答やアドバイスがある。15分調べてもわからないことは、質問しよう！新規登録して質問してみよう
履歴テーブルについて - 一休.com Developers Blog
この記事は一休.com アドベントカレンダーの25日目の記事です。 レストラン事業部エンジニアのid:ninjinkunです。 一休.com及び一休.comレストランはユーザー向けのシステムだけではなく、店舗や一休内の管理者向けの業務システムという性格も持っています。 業務システム経験の無かった自分が一休に転職して最初に驚いたのが、DBに履歴を保持するための履歴テーブルが大量にあることでした。 そこから履歴テーブルの存在に興味と疑問を持ち、社内外のエンジニアと履歴テーブルについて議論してきました。このエントリではそれらの議論をまとめた結果について書いていきます。 履歴テーブルのパターン まず以下の図をご覧ください。 込み入った図かつ事例が一休特化で恐縮ですが、左上の起点から始まって、右のオレンジの部分が最終的な実装パターンです。 図にあるとおり、たいていのユースケースでは以下の3パターンの
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
3. 2 Agenda 1. 自己紹介 2. RDBMSで履歴データを扱う スナップショットデータモデル トランザクション時間データモデル 有効時間データモデル バイテンポラルデータモデル 3. Javaからバイテンポラルモデルを容易に扱うReladomoの紹介 hashtag: #ccc_g3 4. 3 自己紹介 趣味：ドラム演奏 JavaOneコミュニティバンド Null Pointersで演奏経験あり（日本人初） Tech Lead @ FOLIO 伊藤 博志 Eclipse Collections：共同プロジェクトリード兼コミッター Reladomo：コントリビューター OpenJDK：コントリビューター JJUG CCC、Java Day Tokyo、JavaOne San Francisco登壇 2017年5月17日に株式会社FOLIO入社。 hashtag:
オブジェクトベースなUIデザインに取り組むための心構え｜usagimaru ⌘ Satori Maru｜note
オブジェクトベースなUIデザインの考え方が近頃注目されてきています。デザイナーとしてこれと向き合うに当たって、私なりに解釈した事柄を記しておこうと思います。 オブジェクトベースのUIとはUIデザインにオブジェクト指向の設計論を導入したものをオブジェクトベースのUI、Object-Oriented User Interfaces= OOUI などと呼ぶようです。オブジェクト指向UI、オブジェクト指向ユーザーインターフェイスと呼ぶこともあるかもしれません。そのほかにも OOUX という表記も見られますが、ここでは一貫した呼び名を定めておきたいため、便宜上 OOUI と呼ぶことにします。 私たちが普段目にするGUIは元来OOUIの思想に基づいていると考えられるのですが、中にはとても機能指向的（タスクベース）な設計で構築されたGUIが多くみられるため、特にオブジェクト指向的であるものを強調・区別す
予約 - kawasima
限定販売など多くのトラフィックが一斉に集中する場合は、整理券を配り順番に予約・販売システムに流す。それ以外のリクエストは入り口で待たせるか503を返す。
ページネーション - kawasima
基本はオフセットベースで実装することになるが、カーソルベースの方が性能的には有利なので、カーソルベースページネーションにできないかは常に検討する。
イミュータブルデータモデル - kawasima
CRUDのうちUPDATEがもっともシステムを複雑化する。更新には複雑なルールが伴うからだ。業務的に複雑なルールが存在するのは仕方ないこともあるが、システム、設計で複雑さを更に増さないようにしたい。UPDATEに着目し、その発生をできるだけ削ることによって複雑さをおさえるためには、まずデータモデルをそのように設計しておかなけれなならない。このイミュータブルデータモデルは、それを手助けする手法で、手順に沿って実施すればある程度のスキルのバラつきも吸収できるように組み立てられている。
27. 論理削除とは何か？どのような解法があるのか？ w/ twada | fukabori.fm
話したネタ 論理削除とはそもそも何か？ 物理削除とは？ なぜ、論理削除が生まれてくるのか？ SQLアンチパターン 幻の第26章「とりあえず削除フラグ」 理由1: 心理的なハードルの高さ、怖さがある 理由2: 削除したデータを検索対象に入れたい場合がある 理由3: ログとしての用途 理由4: 誤操作をすぐに戻したい アンチパターンとは何か？ なぜ、論理削除はアンチパターンとして捉えられるのか？ 全てのSQL文のWHERE句に削除フラグが必ず入る LIMIT 1などが蔓延していく 論理削除に気づくきっかけは何か？ テーブル設計や、規約から気づく 論理削除というアンチパターンをどのように解いていくか？ 論理削除という概念は世の中にまずなく、お客様は論理削除という言葉を使っていない 要件をどのように設計すればいいのか？ ORMの論理削除プラグインはあまり良くない 状態遷移として捉える方法 Soft
プログラマの抱いている名前についての誤謬
パトリック・ミッケンジー（Patrick McKenzie）さんのブログ・エントリ、 “Falsehoods Programmers Believe About Names” の日本語訳です。翻訳の公開を快諾してくださったミッケンジーさんに感謝します。 公開: 2012-02-22 Posted on June 17, 2010 by Patrick きょう、ジョン・グレアム゠カミング（John Graham-Cumming）が、正しくない文字が含まれているといって彼のラスト・ネームを受け付けないコンピュータ・システムへの不満の記事を書いていた。もちろん彼の名前に「正しくない」ところなどない。当人の申し出たものが当人を識別するものとしては相応しいのであって、定義からして名前とはそういうものである。このことにジョンは当然ながらいらだったし、そうなるのもきわめて正当なことだ。定義からすれば事実
サロゲートキーと「とりあえずID」の違い - 設計者の発言
サロゲートキー（代理キー）は慎重になされる限り、有用なテクニックである。いっぽう、すべてのテーブルに機械的にIDを置く「とりあえずID（IDリクワイアド）」の設計スタイルでは、複雑なデータ要件を扱った途端にひどい目にあう（とくに保守担当者が）。両者の違いをしっかり理解しておこう。 何でもいいのだが、ここでは生産管理システムで見かけそうなシンプルなモデルを使って説明しよう（図１）。「作業区・品目」は、それぞれの作業区で生産可能な品目の組み合わせと、その品目を扱った際の生産性（時間あたり生産数）の管理簿である。 ＜図１＞ [工程]工程id,工程名,扱い単位 ＋ ￣￣￣ ｜ 001 切削 個 ｜ 002 加工 ｍ ｜ └―∈[作業区]工程id,行番,作業区名,標準生産性 ＋ ￣￣￣￣￣￣ ｜ 001 01 切削１号 1000/hr ｜ 001 02 切削２号 2
ソシオメディア | OOUI デザインの準備運動
OOUI（オブジェクト指向ユーザーインターフェース）デザインに慣れるための準備運動をいくつか考えてみました。 これらの準備運動は、UIの大まかな構造に関する話が主で、以下をなんとなく知っている状態の方が対象です。 名詞と動詞で捉える 名詞→動詞で構成する アプリケーションをタスクや機能の羅列と捉えるのではなく、オブジェクト（名詞、もの、関心の対象、概念と言い換えても良いです）を並べユーザーに提示し、そこにアクションが付随するという世界観ですので、人によってはアプリケーション像（コンピュータ像）の転換が必要です。 それぞれの準備運動はオブジェクトを探すことを重視したものになっています。好きなものから選んでやってみましょう。 1. ラフスケッチ いくつかのユーザー要件をもとに、オブジェクトを意識しながら、UIのラフスケッチを描いてみましょう。制限時間は20分です。 これは学校の教員が使うための
アプリケーションにおける権限設計の課題 - kenfdev’s blog
日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR（長すぎて読みたくない） 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能
ソシオメディア | OOUI – オブジェクトベースのUIモデリング
最近、OOUX という言葉を見聞きしました。これはオブジェクト指向の利用者体験（Object-Oriented User Experience）のことで、いくつかの記事を読んだところ、アプリケーション設計において画面とデータを対応づける際にオブジェクトを手掛かりにするという方法論のようです。つまり OOUX は「オブジェクトベースのUIモデリング」と言い換えることができそうです。そうすると実は以前からそのようなデザイン手法はあり、「OOUI（オブジェクト指向ユーザーインターフェース）」と呼ばれていたのです。最近になって OOUX という言葉が使われるのは、OOUI のことを知らなかったか、もしくは流行語である「UX」を用いた方がかっこいいと考えたからではないでしょうか。 「オブジェクトベースのUIモデリング」というデザイン手法は、GUI アプリケーションをデザインする際の基本的なテクニック
ドメイン駆動設計とOOUXで迎える2019年 - Qiita
概要 DDDが、デザイン界隈で注目されだした「OOUX」という設計手法を吸収合併すると皆んながハッピーになるはず、という主にはUI設計のお話です。 OOUXとは Object-Oriented User eXperience の略で、端的に言うと、UIを設計する際「（ユーザのアクションでなく）オブジェクト視点で設計するとより直観的なUIが作れるよ」という手法 1です。考え方自体はOOPが提唱された時代から（OOUIという呼び名で）あったようなのですが 2、UX界隈では2016年頃から話題にのぼるようになりました。 このアドベントを見ている方はほぼエンジニアだと思うので、UI設計者の進化についての、個人的な解釈・経験に基づく乱暴な説明（下記1〜３）から始め、それをDDDでさらに進化できる！という私の思いの丈（4）を語り、この場を借りてDDUXという言葉を提唱したいと思います 3。 UX以前の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
