はてなブックマーク

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

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

bind operator proposalとは? ECMAScriptへの新しい文法の提案の1つ。 obj::func()と書けばfunc.call(obj)になる ::obj.method と書けば obj.method.bind(obj)になる という新しい文法を提案している。 babelですでに実装されており、熱烈なサポーターもいるが、 TC39 stageは未だに0。 (TC39のstageについてはazuさんのECMAScriptとは何か？に詳しい) もう一方の期待の新星 async/await が着々とstageを上げているなか、何故bind operator proposalは一向に進まないのか。 本記事は主に、その理由として挙げられている下記のgithub issuesの流れをまとめたものである。 What's keeping this from Stage 1 - is

Titaniumのアドベントカレンダー 2016の2日目。 今日は、私が1年ほど前に作って、使い続けているTitanium開発を爆速にするツールを 紹介させてください。 要約 faster-titaniumは、Titaniumアプリを再ビルドすることなく即座にJavaScriptを差し替えることのできるツールで、インストールもコマンド一発。これで自分とその周囲の開発生産性は相当上がった。 内部技術はいろいろ難しいが、みんな使って、エラーを出して、いいものにしていこう。 いまのところiOSだけだけど技術的にAndroidは可能だし、実際手元ではAndroidでもうまくやれる感じだ。誰かそこまでやるの手伝って... 背景 Titaniumは原理的に、JavaScript部分だけ差し替えれば、長いビルドは要らないはずだ。 例えば類似技術のReact Nativeでは、Cmd + R だけでJav

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

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? A Glimpse Into The Future With React Native For Web という記事を読み、react-native-webというプロジェクトを知りました。 本記事では、この技術の概要と自分の意見を書きます。 react-native-webの概要 より抽象化されたViewでWebアプリを書ける React Nativeで書いたコードはiOS、Androidに対応する。 このコードがそのままWebで動くとよいのでは？という発想で作られたライブラリ。 *「ReactはもともとWebの技術じゃないか」*というな

Nodeプロジェクトのpackage.jsonには、browserというフィールドを設定することができます。 browserフィールドは、そのプロジェクトをブラウザ等のJSで使ってもらうための仕組みです。 この仕様は、browser field specに定義されています。 入門編では、この役割と基本的な機能について紹介します。 実践編では、 bundlerごとの解釈の違いと、それを回避する方法を説明します。 bundler とは このbrowser fieldを理解するには、まずbundlerについて理解する必要があります。 browser field specにはbundlerという用語が定義されていて、そこには A tool which takes a plain javascript package and creates client usable files. It may i

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

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

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

gulpでないと面倒な事象に行き当たり、どうしてもgruntからgulpに 乗り換える必要がでてきた。 しかしgruntファイルが肥大化しているので、全部書き換えるのも面倒だ。 最初はGruntfileの他にgulpfileも用意して併用すればいいかと考えたが、 gruntのタスクABCとgulpのタスクXYZを一緒に使いたかった。 この場合 grunt内でgulpを呼び出す gulp内でgruntを呼び出す の2択があるが、既存のフローがgruntだという理由で今回は1を選択。 grunt内でgulpを呼び出す gulpfile側は