ECMA262のIteration protocolsで遅延評価するIteratorを作る - saneyuki_s log
これは何？ ECMA262 6th以降にはiteration protocols（と呼ぶべきもの）が導入されている、というのは皆さんもちろんご存知のとおりだと思います。これを使ってIterator<T>.next()が呼ばれるまでmap()などを実行しない（lazy evaluationする）Iteratorを作ってみようという話です。Rustのstd::iter::IteratorとかC#のLINQとかが似たような挙動をしますよね。 今後、巨大なオブジェクトやリストに対してのIteratorが提供・出現した場合、毎回のように即時評価でfor-ofしたりArray.from()するなどは現実的ではないでしょう。以下のように書くことも出来ますが、 /** * @template T, U * @param {Iterable<T>} src * @param {function(T):U}
RxJSで副作用を扱うにはどうするか - Schedulerを交えて - saneyuki_s log
Rx.Scheduler RxにはSchedulerと呼ばれる主要概念がある. 値がpushで飛んでくるというRxのインパクトの後ろに隠れがちなSchedulerではあるが, これにより, 処理系のスレッドモデル（並行性）と時間軸にまつわるタイミングの制御を統一的に扱えるようにしている. 後続へのoperatorへの値の送出タイミングの制御, Observableの処理スレッドの指定, タイマーのモックへの差し替えなどがSchedulerによって実現されている. さてJavaScriptの場合, 原則的には単一スレッドの世界になる. Javaや.NETの場合とは違い, RxのSchdulerの役割は回り続けるイベントループ抽象となる. 永久に回り続けるイベントループの中で, どの時点で処理をdispatachするかがSchedulerの役目だ. JavaScriptの世界にはメモリ空間を共
option-tにPromiseへのキャストメソッドを用意したりなど - saneyuki_s log
自作RustスタイルECMAScript用Option型ライブラリoption-tをいろいろアップデートしたので、リリースノートがてら書く。ご存知ない方はこちらをどうぞ。要はOption<T>/Maybe型だ。 Promiseへのキャストメソッドを用意した ECMA 262の文化には、すでにMaybeもどきの標準仕様が存在する。ご存知Promiseだ。 だが、Promiseは非同期前提の操作になるので、同期的に実行するAPI群との親和性が良いとは言えず、かといって全てをPromiseにするほどでもない場合のために、わざわざこんなライブラリを作ったというのは前に書いた通り。 でも、今の世の中、どこかしらの関数がPromiseを返すじゃん？そこに上手く混ぜられるととっても楽じゃん？ てなわけでcast用メソッドとしてOptionT.asPromise()を追加した。これにより、スムーズにPro
RxJSのObservableのHotとColdの実装を眺めた - saneyuki_s log
更新情報 UTC+9:00, 2015/03/29, 3:30くらいに、サンプルコードとかロジックの説明とかを修正した UTC+9:00, 2015/03/29, 14:30くらいに、gistにした（エラッタの修正履歴を残すため）
Option/Maybeとかで解決していることを、さながらgolangのようにES6のdestructuring assignmentで解決する - saneyuki_s log
ES6から使えるようになるdestructuring assignmentを使って、タプル的に返して受け取れば、複数の値を楽に受け取れるので、エラーハンドリング的なものが楽にできるようになりますよね！という話です。先日書いたライブラリで解決・緩和しようとしていた問題に対する別のアプローチ。 今更言うまでもない、おそらく常識的なテクニックの話なんですが、みんなES6の話をしているのに、こういう使い方の話をロクにしていないので「こういう話しようぜ！」と喧嘩を売る意味で書きました。 let fn = function () { return [ true, // 関数が正常処理できたか or 値の有無とか 100, // 実際の値 ]; }; let [ok, val] = fn(); if (!ok) { return; // 正常処理できていない, 値が特になかったので帰る } まあ、まんま
ES5の範囲でOption<T>型を表すライブラリ、option-t を作った - saneyuki_s log
動機 初期状態で未選択なラジオボタンがあるようなフォームを作っている場合、ラジオボタンに対応するモデルの値を「この値は未選択である」というのをJSで表現するのは結構面倒くさい。チェックボックスであれば, booleanのどちらかで状態が確定するが、ラジオボタンだと取りうる値は複数になるし、初期状態で選択されているか否かの問題が発生する。選択されていない状態を専用にフラグとして持つのは気持ち悪いが、かといって、未選択の状態を-1や9999ないしnull、undefinedで表現するのは危うい。コードを書いた本人しかわからない。 RustやScalaなどのようにOption<T>/Maybeがある言語なら、こんなまどろっこしい思いはせずに、明示的に値の有無を表現できる。 というわけで、ないなら作ってしまえば良いじゃないメソッドで作った。 Option<T>型について 私が説明するよりもわかりや
CSSのcanvasとviewportとposition:fixedとpinch zoom - saneyuki_s log
specを元にした概念の整理 間違いあったら教えて欲しい CSS 2.1におけるviewport CSS 2.1におけるviewportを説明するにあたり、以下のterminologyが必要となる canvas For instance, user agents rendering to a screen generally impose a minimum width and choose an initial width based on the dimensions of the viewport. viewport User agents for continuous media generally offer users a viewport (a window or other viewing area on the screen) through which users co
Fluxとはなんだったのか + misc at 2014 - saneyuki_s log
はじめに VirtualDom - なぜ仮想DOMという概念が俺達の魂を震えさせるのか - Qiita を読んでいる前提で話を進めます。 結局”Flux”なんだったのよ 詳細については過去に自分が覚え書きを書いたのでそっちを読んでいただけると良いと思うけど、あれは 「MVCの変形亜種に、オブザーバーパターンを乗せ、データを単一方向に流すことを規定した」ものに、Facebookが命名したものでしかない。極端に目新しいものでもない。その最大の功績はアーキテクチャそのものではなく、「試行錯誤を踏む中で誰もが一度はやっていたであろう似たようなことを上手く実践法則としてまとめた上で、共通認識としての名前をつけた」こと。概念に名前をつけて共有することで、事前説明が簡略化され、本質的な問題に取り組む時間が増える。これをFacebookのブランド力でねじ伏せるように広めたことこそが重要かつ評価すべきポイン
Rustプログラミングにおけるデバッグ入門 - saneyuki_s log
これはRust Language Advent Calendar 2014の第1日目となります。 尚、本情報はRust 0.13.0-nightly@fac5a0767時点の情報を基にしております。 現実においてプログラムを書くにあたりデバッグを行わないということはありません。ですので、通常、我々はデバッグ技法というものを習得しなければなりません。 デバッガ RustではDWARF形式のデバッグシンボルを出力できるため gdb lldb といったツールの使用が可能です。WinおよびLinuxではgdbを使えばいいでしょう。OSXでは、個人的にはlldbを使えばいいと思います（尚、gdb向けの拡張スクリプトもrustリポジトリの中には存在しています） また、DWARF形式のシンボルを用いた各種ツールチェインも使用が可能となっていますが、各種バグには注意を配る必要があるかもしれません。 log
Fluxの枠にURLルーティングを収める試行 - saneyuki_s log
JSer.info 200回記念祭の懇親会でざっくりアイディアだけ話していた記憶（酔っ払っていたので正確には覚えていない）なんだけど、実際に必要になったので試しに作ってみたという話。 モチベーション Fluxパターンを用いた設計を行なっている場合というのは往々にしてSingle Page Applicationであるので、URLに基づくルーティングを要しない、純然たるアプリケーションなケースが多い。だが、アプリケーションの性質によっては、パーマネントリンク的な機能の再現をしたいことがあり、ルーティング機構が欲しかったりする。 で、そういう場合については語られてる事例をあんまり見かけなかったので、作ってみた。 デザイン Storeに基本ロジックを閉じ込めるのは変わらない URLに基づく履歴情報は、ユーザーインターフェースの一種と捉える。ので、Viewと考える 使ったライブラリ 基本要件として
Virtual DOMのアルゴリズムが知りたくてvirtual-domのコードを読んだ話 - saneyuki_s log
Reactの登場以来気になっていた、Virtual DOMアプローチの具体的な差分抽出手法について、virtual-domを読んで確認してみた。 Reactをいきなり読むのは面倒くさかった・ミニマムな実装から読みたかったというのが、こっちを選択した理由。Reactのアルゴリズムが参考にされているものの、Reactには存在する特定の最適化が入ってないかもしれないので、あくまでもReact系のVirtual DOMを実装するには最低限何が必要かを知る程度のものと判断してほしい。 virtual-domについて ReactのVirtual DOM部分だけを切り出して再利用可能な形で再実装したライブラリ。elm-htmlとかMercuryといった箇所でvDOMインフラとして既に使われているので、まったくの趣味プロダクトという訳でもなくなっている。 README.md中での触れられている通り、Vir
JS界隈にIDLもしくはd.tsを併記・同梱する文化が根付いてほしい - saneyuki_s log
前置き 最近、ウェッブフロントエンドエンジニアらしく各種JavaScriptのライブラリを眺めて、調査・選定しているのだけれども、その過程を通じたこととして、多くのライブラリが、ドキュメントのAPIの説明が貧弱すぎる。 jQueryのドキュメントが腐っているというのは既に広く知られた事実であると思うし、そうでないならば積極的に既知の事実として腐っている事を広めて行くべきであると強く思うが、jQueryに限らずとも、ドキュメントが満足な形で整理されていないのをひしひしと感じる。 この手のものでよくドキュメント化されている部類だと感じるBackbone.jsですら、仮引数の名称と定義のみしか書かれておらず、肝心の引数が備えるべきメンバや、引数の型情報が明示的に記述されていない。そのため、APIを俯瞰し、自分の欲しい情報がどこに詰まっているのか・どのように取得できるのか・DOM標準もしくはECM
ServoのDOMバインディングの話 - saneyuki_s log
Servoのリポジトリ内にDOMバインディングのデザイン覚え書きを投入したので、現時点での設計について、そろそろ日本語で説明しておく（英語版は結構前からServoのWikiに書いています）。 この記事の中で使うSpiderMonkey API用語は、結構古いものだったりするので、そこに注意（ServoはFirefox 17とかその辺りのSpiderMonkeyを使ってる）。 ブラウザにおけるDOMバインディングとは この分野については、エデンの園でおきたこと - steps to phantasienという名記事があるので参照されたし。WebKit Chromium port時代のBlinkの話だけど、だいたいどのブラウザでも似たような問題を抱えていて、それぞれ微妙に異なるアプローチで解決している。 改めて私の言葉で要約してみると、「現代の実用的なブラウザエンジンというものは、自身の保有す
ES6の前にES5のベストプラクティスを改めて考えたい - saneyuki_s log
歴史認識 だいたい以下のような流れだと認識している。 IE8以前を含むECMAScript 3暗黒時代があった この時代をベースにベストプラクティスが構築 + HTML5ブームが発生した 暗黒時代なんで結構つらいし、IE9じゃないとECMAScript 5使えないし、結局辛い CoffeeScriptを筆頭としたaltJS一派に救いを求めた（結局Coffeeは一過性のカフェインだったわけだけど） 気がついたらECMAScript 6が来そうになっていた ES6でのsyntaxの拡張・標準ライブラリの増強はカッコいい 気がついたらES5当たり前、ES6も使えそうな世界が来そうになっていた（希望的観測が多分に含まれているのは暗黙の了解と化している） ES6、altJSの次のナウい世界として注目を集める だいたいこんな感じで、ECMAScript 5を用いたベストプラクティス的な物が存在しない、
見つけた便利MV**ライブラリを紹介するときにjQueryをスケープゴートにするのをいい加減に止めろ - saneyuki_s log
オレオレMV**フレームワークを紹介する際にjQueryを引合いに出して語る事案が多く、そこで語られるjQuery批判が的外れもいいところなのが散見されるので書きました。 Abstract MV**便利フレームワーク・ライブラリを紹介するときに、jQueryの一番イケてない書き方を引き合いに出して比較して「こんなにすごいんです」と紹介するのは不毛極まりないのでいい加減に止めろ jQueryで書いたコードがひどいのは、クライアントサイドWeb（あえてこう書く）が過去10年近くにわたって設計を軽視してきた結果であり、その根本が変わらない限り、問題は変わらない jQueryエンジニアをdisりながら、Angularエンジニアを産み出すとかギャグじゃないの？ 私個人のjQueryに対する見解 だいたい同意する意見： jQueryについての私見 - mizchi's blog mizchi / いか
Promiseはコールバックに対する聖杯ではない - saneyuki_s log
ES6ならびにDOM4にPromiseが投入されることとなり、すっかりJavaScriptでよく陥るコールバック地獄に対する至高の解決策のように扱われているPromiseだが、万能の解・聖杯ではない。 たぶん誰かが既に似たようなこと書いてると思うけど、とりあえず自分の思考の整理に書く。 Promiseといえば以下のようにコールバックによるコードの無限ネストを解決するものとして扱われることが多い。 var p = new Promise(); p.then(function () { ... }).then(function () { ... }) だが、これはコールバックをPromiseというラッパーを用いてネストしない形に変換しただけに他ならず、Promiseの利点ではない。適当なラッパー関数を作って解決しているのと大差はない。 本質的にはPromiseとは将来的などこかの時点になれば値
軽量オブザーバJSライブラリのrev.2をリリースした - saneyuki_s log
いわゆるリリースノート（宣伝とも言う）です。 少し前にこのブログで書いた、JS向けオブザーバパターンライブラリのrev.2をリリースしました。 Release · saneyuki/observer-js · GitHub リリース概要 TypeScript用型定義ファイルを追加 ObserverSubject.destory()を追加 ObserverSubject.removeAll() -> ObserverSubject.removeTopic()に名前変更 Support IE6~8 First stable release 必要最低限のAPIセットが揃ったと考えたので、とりあえずstable releaseです。「とりあえずこれさえあればなんとかなるだろう」というAPIだけ載せました。将来的にIE6~8サポートは優先的に必ず削除する予定ですが、本バージョンのマイナーバージョンア
JS用のオブザーバーライブラリを作った - saneyuki_s log
超単機能オブザーバーJSライブラリを作った。 saneyuki/observer-js 動機 既存の有名MVCライブラリのどれもが気軽に使える規模・サイズじゃなかったのと、フレームワークというほど大きなものが欲しかった訳じゃなくて、本当に単機能なものが欲しかったので、車輪の再発明した。 ビューのライフサイクルも完全に自分で定義する前提で、好きなライブラリと自由に同居できるように構築。APIはXPCOMのnsIObserverServiceとDOM EventListenerを参考にしています。 機能的には、これでほぼ完成で、あとはバグ取りとか、legacy IE向けにES3ブランチ作ったり、逆にES6 Map, Setを使うためのブランチを作ったり、テストを書き直したり、設計上余力があればパフォーマンス改善とかやる予定です。将来的にはWeb Workers向けのアダプタも作成したい。 今後
Servo Architecture vol.1: ConstellationとPipeline - saneyuki_s log
第三回Servo Readingの成果として、最初はServoのCompositorの話を書くつもりだったんだけど、いきなりCompositorの話を出してもややこしいので、まずはConstellationとPipelineの話をしようと思う。 ブラウザエンジンと一口に言っても、よく知られている通り、その仕事は多岐に渡る。リソースの読み込み、画像のデコード、HTML/CSSのパース、描画ツリーの構築、DOMの構築、JSの実行、結果の出力etc。こうして並べてみるとわかるようにその仕事は多岐に渡る。ましてや最近はOSの抽象層みたいな事もやり始めたので、どんどんと管制対象は増えていくばかり。そうした処理を管制する役割の箇所をServoではConstellationと呼ぶ。最初はengineと呼ばれていたまさにエンジンの中央部分だ。どういったわけかリネームされて今の名前になったわけだけど、ECM
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fluxアーキテクチャの覚え書きを書いた - saneyuki_s log
