タグ

ブックマーク / qiita.com/shinout (6)

  • ドキュメント指向DBの論理的側面と物理的制約 - DDDと絡めて - Qiita

    この記事のモチベーション RDB(Relational DataBase)の歴史は長く、ノウハウも蓄積されている。 関係代数という学問もあるなどアカデミックにも研究されており、 国家資格である「データベーススペシャリスト」も、ほとんどこのRDBのことを扱うなど、 RDBは一定の体系が確立した技術と言える。 一方で、2010年ごろより広まったNoSQL、特にドキュメント指向DBに関しては、 当然ながらRDBに比べると未成熟な段階であろう。 また主観だが、NoSQLは、スケーラビリティといった物理的側面にfocusが当たることが多かったのではと思う。 一方で、論理的側面 = モデリング に関して、および物理的側面と論理的側面のトレードオフの関係について、 議論されつくされているとは言えない。 稿では、DDD(ドメイン駆動設計)というプログラミングの論理的側面の手法を、 各DBがいかに扱えるか

    ドキュメント指向DBの論理的側面と物理的制約 - DDDと絡めて - Qiita
    efcl
    efcl 2017/10/04
    ドキュメント指向DBとDDD
  • クライアント主権時代にJSのモデルはどう共有すればいいのか - Qiita

    SPA、スマートフォンアプリの隆盛。時代はクライアントサイドに主権が移ってきている。 これからの時代はクライアントサイドにロジックを持たねばならぬだろう。 一方サーバーは、「ユーザー1人でも完結するサービス」に限れば、 DOA(Data Oriented Architecture)的な立ち位置のもの(≒mBaaSとか)と、BFF(Backend for Frontend)的な立ち位置のものがあればよくなる。 モデル定義がダブる いままでモデルはサーバーのものだった。 クライアントでは「JSON」というデータになってやってきて、 それをなんとなく成形して表示してた。 でも来るべきクライアント主権時代においては、 やっぱりクライアントでもJSONじゃなくてドメインモデルを扱いたい。 そうするとサーバー/クライアントの2つの環境でモデル定義を書かなくてはならないではないか。 多くのサービスは実は

    クライアント主権時代にJSのモデルはどう共有すればいいのか - Qiita
    efcl
    efcl 2017/01/16
    JavaScriptのモデル
  • 実践UniversalJS 繰り返し処理の分離 - Qiita

    ブラウザAPIに依存した複雑なJSの処理から、ロジックを抽出し分離する方法を、事例を通して紹介します。 今回の事例は、繰り返し処理を伴うロジックの分離にgeneratorが有効であった例になります。 はじめに少し Universal ≠ SSR について Universal JSの興味関心は、SSR(サーバーサイドレンダリング)に限りません。 より汎用なロジックの移植可能性がテーマです。例えば markdown文字列の構文解析 deep copy テスト http client ランダムに文字列を出力 と、プラットフォームに依存しないべきロジックすべてが守備範囲になります。 しかし、Universal JSへの関心が薄い層がライブラリを作ると、 たとえばmarkdown"ファイル"の構文解析ライブラリができあがります。「ファイル」は物質世界の登場人物で、この時点でNodeJSでしか利用でき

    実践UniversalJS 繰り返し処理の分離 - Qiita
    efcl
    efcl 2016/09/07
    Isomorphic/UniversalJSについて
  • ReduxでReducerとInitialStateを分けるためのbetterCombineReducers - Qiita

    要約 ReduxのReducerは、特にcombineReducersを使うときには初期状態を含むように書く必要がある。それでは数学的に美しくないし、実際に都合の悪いケースもある。そこで、初期状態を別途与えることができるbetterCombineReducersを提案したい。それは下記に公開されており、利用することもできる。 GitHub: shinout/better-combine-reducers 導入 ReduxとDFA(決定性有限オートマトン) Reducerの定義を見て欲しい。 Reducerは、StateとActionから、新しいStateを返す。 このようなシンプルで美しい設計は、離散数学の一分野である決定性有限オートマトン(DFA)にそのヒントを得ていると考えられる。その中で出てくる「状態遷移関数」こそがReducerだ。 DFAの考え方に従えば、状態機械というのは 状態

    ReduxでReducerとInitialStateを分けるためのbetterCombineReducers - Qiita
    efcl
    efcl 2016/08/10
    state管理に置いて、関数は初期stateを知るべきではないのではという話 初期状態が毎回異なるため、初期状態は関数ではなく外から与えられるものという話
  • package.json の browser field 実践編 - Qiita

    package.json の browser field 入門編 では、package.jsonのbrowser fieldの役割と機能について紹介しました。 編では、この機能のbundlerごとの実装の違いと、それを回避する方法を説明します。 ここで取り上げる実装の違いとはずばりpathの解決方法です。 ./から記述するかどうか .jsを記述するかどうか mainとの対応関係 この3つの要素が絡んできます。 なお、パス解決のresolverを指定できる系もあるようですが、ここでは各々のbundlerがデフォルトで用意しているresolverについて論じています。 (なぜなら、resolverを外部が指定しなければ意図通りbundleされないというのは、利用者にとってはbundleされないのとほぼ同義です) 調査したbundlerは以下です。 browserify webpack Rea

    package.json の browser field 実践編 - Qiita
    efcl
    efcl 2016/08/03
    package.jsonの"browser" fieldの解釈の違いについて。 Browserify、webpack、React Native Packagerの比較
  • npm shrinkwrapを運用で使うためのコツ - Qiita

    npm shrinkwrap とは? npm shrinkwrapは、Node.jsプロジェクトの依存モジュールのバージョンを固定するコマンドです。 使い方についてはこちらの記事が参考になります。 今回は、npm shrinkwrapをより安定して使うためのコツを記載しました。 1. CIを活用し、テストしたバージョンで固定しリリース npm shrinkwrapコマンドではnpm-shrinkwrap.jsonというファイルが生成されます。 継続的インテグレーションのサービスを活用し、そこでテストしたバージョンで固定するとよいでしょう。 CIでのフローとすれば以下になると思います。 npm updateで、可能な限り新しいバージョンを利用 テスト (npm test) npm shrinkwrap npm-shrinkwrap.jsonを追加しコミット、別tagや別branchとしてpu

    npm shrinkwrapを運用で使うためのコツ - Qiita
    efcl
    efcl 2016/07/21
    npm v2/v3のshrinkwrapについて。 色々バグがあるという話。 productionに絞ってshrinkwrapする方法
  • 1