Eventual Consistencyまでの一貫性図解大全 - Qiita
TL;DR; Eventual Consistencyとか言いながらどうせもっとまともな一貫性実装してることはよくあるんだからみんな適切な名前を使おうぜ。 なぜこの記事を書くのか NoSQLの文脈においてスケーラビリティとのトレードオフでEventual Consistencyという用語は結構な頻度で出てくる。 ACIDに対抗してBASE(Basicaly Avalilable, Soft state, Eventual consistency)なんて言葉が出てきたり、CAP定理の中のAとPだと言ってみたり、分散システムのスケーラビリティを高めるために人類は一貫性を諦めることに余念がない。 その一方で、諦められた一貫性に関しては雑な分類論で語られる事が多く実はもっと適切な言葉があるのに「Eventual Consistencyです」なんて言われる事が良くある。そこで、この記事では過去に並行
プロトタイプを使って要件をまとめるときに気をつけるべきこと
JoeはUX/CXコンサルタントとして長年のキャリアがあり、現在はUXに関する書籍、講演などを多数手がけるUXの伝道師です。 「要件を決めた時に想像していた仕様と違う」 開発チームのほとんどが、プロジェクトの中でも最悪のタイミングで、このような発言を聞くはめになります。大抵、このようなことが起きると、開発者は自分を正当化しようと怒り出します。正確に要件を定義していなかったとステークホルダーを叱責するのです。 これはもっともな怒りではあります。しかし、同時にこの状況の責任は私たち開発側にもあることも事実です。 私たちは認識のズレを埋めるため、要件に必要なことをステークホルダーに伝えてきれていません。この記事では、開発の現場で起きがちなことについて話していきます。 要件をまとめることの背景にある厳しい事実 要件が決められるのは、大抵ステークホルダーとのミーティングのときです。ステークホルダーは
日本企業では「能力不足」よりも「態度の悪さ」のほうが問題になる。
「日本の雇用終了」という書籍がある。 タイトルだけを見ると、インターネット民は「日本の雇用はヤバい」とも読みそうなのだが、そのような本ではない。 この本を一言で言えば「クビにした会社と、クビにされた社員の紛争」の調停事例を扱った研究書籍である。 内容としては、国の出先機関である都道府県労働局が行った「あっせん」という紛争調停の事例を延々と紹介、考察している。 あっせんとは 当事者の間に学識経験者である第三者が入り、双方の主張の要点を確かめ、場合によっては、両者が採るべき具体的なあっせん案を提示するなど、紛争当事者間の調整を行い、話合いを促進することにより、紛争の円満な解決を図る制度です。 （埼玉労働局） そして、一見退屈そうな本なのだが、これが読み出すと結構面白い。 なにせ、事例がリアルで豊富なのだ。 もちろん当事者同士は真剣であり、面白がっては良いものではないのだが、「経営者」と「労働者
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
