Rx.js, Immutable.js について - mizchi's blog
自分はImmutable.jsとRxをなぜ採用しなかったか、自分の考えを整理するために書き出してみる。 僕の理解が及んでいない無知のゆえのアレもあると思うので間違っていたら罵倒ブコメお願いします。 Immutalbe(.js) 扱う対象をイミュータブルにするのはたぶん間違いなく正しい。正しいが、現時点のエコシステムにおいてその必要性を示せてない。具体的に言うと、Immutable.jsの110kbのオーバーヘッドの配信負荷、読み込み負荷、開発者の学習コストを支払ったとき、それに見合う価値を提示できているのか？にまだ疑問が残る。 PureなJSでも、ただ単に目的のデータを作るだけなら、ほとんどのケースで組み込みのarray.mapとObject.assign(またはそのポリフィル)で代用できる。(勿論生成したオブジェクトに副作用を加えないことが前提になるが) あと型がない環境でImmutab
最小最速で作るaltjs - mizchi's blog
最近、というか昨日からTypedCoffeeScriptの開発再開してAST 気分が盛り上がってるので、簡単なチュートリアルでも。 この記事でやること ASTの取得 ASTの生成 JavaScript の出力 やらないこと 構文解析 準備 適当にプロジェクト作ります。 $ mkdir tinyaltjs $ cd tinyaltjs $ npm init # 色々聞かれるけどEnter 連打で良い $ npm install escodegen esprima prettyjson --save esprima はJavaScript のコードをASTに変換。 escodegen は AST から JavaScript を生成。どっちもConstellationさん製 escodegenはConstellationさん製で、彼はesprimaにもコミットしてます。この界隈に来ると基本的に彼
Promise時代のJavaScriptの関数の処理/提供 - mizchi's blog
最近自分で非同期前提のプラグイン書くときはThenableな感じで書いてることが多い。 Thenableってのはどういうことかというと、typescirptのes6-promises では次のように定義してある。 interface Thenable<R> { then<U>(onFulfilled: (value: R) => Thenable<U>, onRejected: (error: any) => Thenable<U>): Thenable<U>; then<U>(onFulfilled: (value: R) => Thenable<U>, onRejected?: (error: any) => U): Thenable<U>; then<U>(onFulfilled: (value: R) => U, onRejected: (error: any) => Thenab
エンジニア Mac アプリ 環境 おすすめ - mizchi's blog
Macで捗るオススメのアプリひたすら書いてくわ : IT速報 が余りにも消化不良だったので書く。 (タイトル考えるの面倒臭かったのでワードサラダ風) homebrew入れる brewfileをつくる brew bundle おわり 以下、最近作った ~/brewfile です。デスクトップアプリもbrew caskから突っ込む。 もういろんなサイト巡ってアプリを入れて回る時代は終わったんだよ、爺さん tap phinze/homebrew-cask || true tap homebrew/versions|| true update || true install brew-cask || true install git || true install hg || true install ag || true install gist || true install gibo ||
技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog
元糞コードマイスターとしては、生産性については思うところある。 技術的到達深度が深い人じゃないとそもそもかけないコードってのももちろん存在して、その前提で10倍とか100倍になりうる話をする。 そもそもマイナスになる人がいるって話。 隠しパラメータをモデル化 エンジニアA:「週に10の成果を出して3の負債を生む人」を考える。この人は開発を止めてリファクタリングをすれば10-3 = 7の技術的負債を返却できるとする。 ここで正確には成果10には* aの係数が掛かっている。これはプロジェクト開始時1.0で、技術的負債が貯まるほど0に近づいて行く 次に、エンジニアB:「週に15の成果を出して10の負債を生む人」を考える(これにも係数aがかかる)。この人は見た目上は上の人の1.5倍速く成果を出しているように観測できるが、負債もたまりやすい。リファクタしても綺麗になりにくい。 これは割とエンジニアに
軽量でパワフルなデータバインディングMVVM, vue.jsで遊んでみた - mizchi's blog
Vue.jsは軽量なMVVMライブラリ。 vue.js http://vuejs.org/ 使ってみた感じ、かなり手触りがよいので、紹介する。 概要 handlebars風のテンプレートを書いて、DOMを展開する。普通のテンプレートエンジンと違い、$dataアクセッサを通じて値を書き換えることで、テンプレート展開後も値が同期する(!!!)。 一言で言うと軽量Angular。コード読んだ感じ、内部的にもAngularから大量にコードを持ってきた痕跡がある。$watchとdirective定義がキモなのは同じ。 とはいっても、軽量なのは使う側のAPI側だけで、内部実装はそれなりに重い。APIを軽量にすることで、Angularのデメリットである学習コスト部分を限りなく削ることを目標にしているんじゃないだろうか。 大雑把な使い方 テンプレートを書く。対応するデータ構造を書く。{foo: 'bar'
なぜクライアントJavaScriptの単体テストを書くのが難しいか、考えてみた - mizchi's blog
ってsinonのスタブ漏れを探しながら何度目かわからない感じにキレてた。 とにかく仕事でJSのテスト書くのが辛いので考えてみる。比較的JSのテストに慣れてる自分ですら辛いのだから、世界はもっと辛いに間違いない。サーバーサイドのnode.jsの話ではない。 JavaScriptで完結しない 構造がHTMLの構造と密結合している。装飾や位置、表示/非表示はCSSによって制御されている。 クライアントJSはHTMLと密結合しており、CSSからビューは影響を受ける。それらがネットワークの結果を受け非同期に振る舞いを帰る。その最終的な値を取得するのが難しい。 もちろんサーバーサイドだってDBやネットワークという外部リソースを扱うが、モックの手法が確立しているし、局所的な複雑度は、JSの方がはるかに多い。 言語仕様が貧弱 mochaやjsmineはrspecを真似てるけど、本質的にJavaScript
ソースコード上の主語は誰か、という話 - mizchi's blog
ふとTwitterで投げたらリプライたくさんきた これ素朴な質問なんだけど、ソースコードで英語でコメント書くとき、守護はIなのかWeなのかコードそのもので受動態で書くのか、どっちなの— 性格は糞 (@mizchi) 2013, 9月 23 @mizchi 一行目は主語無し（命令形）、長い説明をつける場合は 1.言い訳がましいコメントは I を主語に 2. 誰かと合意済みの事柄は We を主語に 3. 仕様に沿う振る舞いに変更する場合は It should be ~ などコード自体が主語であるように、と書いてる— Kensuke Nagae (@kyanny) 2013, 9月 23 @mizchi "add …": このコードは…を足します、"added …" このコードは…で足されました、"adding …" このコードは…を足しています— 中村氏 (@r7kamura) 2013, 9
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
