サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
中東情勢
saneyukis.hatenablog.com
自作RustスタイルECMAScript用Option型ライブラリoption-tをいろいろアップデートしたので、リリースノートがてら書く。ご存知ない方はこちらをどうぞ。要はOption<T>/Maybe型だ。 Promiseへのキャストメソッドを用意した ECMA 262の文化には、すでにMaybeもどきの標準仕様が存在する。ご存知Promiseだ。 だが、Promiseは非同期前提の操作になるので、同期的に実行するAPI群との親和性が良いとは言えず、かといって全てをPromiseにするほどでもない場合のために、わざわざこんなライブラリを作ったというのは前に書いた通り。 でも、今の世の中、どこかしらの関数がPromiseを返すじゃん?そこに上手く混ぜられるととっても楽じゃん? てなわけでcast用メソッドとしてOptionT.asPromise()を追加した。これにより、スムーズにPro
更新情報 UTC+9:00, 2015/03/29, 3:30くらいに、サンプルコードとかロジックの説明とかを修正した UTC+9:00, 2015/03/29, 14:30くらいに、gistにした(エラッタの修正履歴を残すため)
ES6から使えるようになるdestructuring assignmentを使って、タプル的に返して受け取れば、複数の値を楽に受け取れるので、エラーハンドリング的なものが楽にできるようになりますよね!という話です。先日書いたライブラリで解決・緩和しようとしていた問題に対する別のアプローチ。 今更言うまでもない、おそらく常識的なテクニックの話なんですが、みんなES6の話をしているのに、こういう使い方の話をロクにしていないので「こういう話しようぜ!」と喧嘩を売る意味で書きました。 let fn = function () { return [ true, // 関数が正常処理できたか or 値の有無とか 100, // 実際の値 ]; }; let [ok, val] = fn(); if (!ok) { return; // 正常処理できていない, 値が特になかったので帰る } まあ、まんま
動機 初期状態で未選択なラジオボタンがあるようなフォームを作っている場合、ラジオボタンに対応するモデルの値を「この値は未選択である」というのをJSで表現するのは結構面倒くさい。チェックボックスであれば, booleanのどちらかで状態が確定するが、ラジオボタンだと取りうる値は複数になるし、初期状態で選択されているか否かの問題が発生する。選択されていない状態を専用にフラグとして持つのは気持ち悪いが、かといって、未選択の状態を-1や9999ないしnull、undefinedで表現するのは危うい。コードを書いた本人しかわからない。 RustやScalaなどのようにOption<T>/Maybeがある言語なら、こんなまどろっこしい思いはせずに、明示的に値の有無を表現できる。 というわけで、ないなら作ってしまえば良いじゃないメソッドで作った。 Option<T>型について 私が説明するよりもわかりや
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
はじめに VirtualDom - なぜ仮想DOMという概念が俺達の魂を震えさせるのか - Qiita を読んでいる前提で話を進めます。 結局”Flux”なんだったのよ 詳細については過去に自分が覚え書きを書いたのでそっちを読んでいただけると良いと思うけど、あれは 「MVCの変形亜種に、オブザーバーパターンを乗せ、データを単一方向に流すことを規定した」ものに、Facebookが命名したものでしかない。極端に目新しいものでもない。その最大の功績はアーキテクチャそのものではなく、「試行錯誤を踏む中で誰もが一度はやっていたであろう似たようなことを上手く実践法則としてまとめた上で、共通認識としての名前をつけた」こと。概念に名前をつけて共有することで、事前説明が簡略化され、本質的な問題に取り組む時間が増える。これをFacebookのブランド力でねじ伏せるように広めたことこそが重要かつ評価すべきポイン
これは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
JSer.info 200回記念祭の懇親会でざっくりアイディアだけ話していた記憶(酔っ払っていたので正確には覚えていない)なんだけど、実際に必要になったので試しに作ってみたという話。 モチベーション Fluxパターンを用いた設計を行なっている場合というのは往々にしてSingle Page Applicationであるので、URLに基づくルーティングを要しない、純然たるアプリケーションなケースが多い。だが、アプリケーションの性質によっては、パーマネントリンク的な機能の再現をしたいことがあり、ルーティング機構が欲しかったりする。 で、そういう場合については語られてる事例をあんまり見かけなかったので、作ってみた。 デザイン Storeに基本ロジックを閉じ込めるのは変わらない URLに基づく履歴情報は、ユーザーインターフェースの一種と捉える。ので、Viewと考える 使ったライブラリ 基本要件として
どこに書いたか忘れそうなので備忘でgist貼付ける Facebook提唱のFluxのメモ:http://facebook.github.io/react ...
この間、virtual DOM読んだついでにReactも読んでみた。 役に立つ話を書くつもりは一切無くて、感想だけ。 React.js 定数だけのファイルとか(まさに*hな感じ)、デザインや使い方について書かれたコメントなど、全般的にC++に類似するstaticなコードの流儀で書かれている。 イケイケな「動的言語最高!」って言わんばかりのJSのコードではなく、明らかにC++の巨大プロジェクトなどに近い。Mozillaの中のJSとか、XPCOMな箇所で少し古いものとかにデジャブを感じる。 もっとも、巨大かつ基盤になるようなプロジェクトはこうせざるを得ないし、小手先のreadable性に頼らずに真っ当に巨大ソフトウェア開発してる趣が個人的な心象は最高に良い。 ただし、本来静的解析フェーズで片付けるべき箇所もカバレッジのためにテストを記述している箇所が有り、ちょっとそこはイケてないと感じるかもし
Reactの登場以来気になっていた、Virtual DOMアプローチの具体的な差分抽出手法について、virtual-domを読んで確認してみた。 Reactをいきなり読むのは面倒くさかった・ミニマムな実装から読みたかったというのが、こっちを選択した理由。Reactのアルゴリズムが参考にされているものの、Reactには存在する特定の最適化が入ってないかもしれないので、あくまでもReact系のVirtual DOMを実装するには最低限何が必要かを知る程度のものと判断してほしい。 virtual-domについて ReactのVirtual DOM部分だけを切り出して再利用可能な形で再実装したライブラリ。elm-htmlとかMercuryといった箇所でvDOMインフラとして既に使われているので、まったくの趣味プロダクトという訳でもなくなっている。 README.md中での触れられている通り、Vir
Servoの現況概説的なおはなし - snyk_s logの方を未だに参照されてる人がなんか多いみたいなので。 Servo parallelism from Tetsuharu OHZEKI スライド自体は先日のブラウザエンジン先端観測会で使ったものそのものなんだけど、2014年Q2現在の現状としてはこっちの方が正確です。
前職ではWindowsを使ってWebフロントエンドエンジニアをやっていたんだけど、そのときに自分の開発機に入れていたツール群とかを徐々に忘れてしまいそうだったのでメモを兼ねて書いてみる。Web系=OSXということでノウハウがどれもWin向きではないということで困っている人がいると思いますし、そういう人のお役に万が一でも立てれば幸いです。 背景 自分の当時の背景はこんな感じ。こういう基準・背景でコードを書いてた。 自分は、もっぱらクライアントサイドでJSを書いてた モバイルよりもレスポンシブデザイン向けにコードを書く方が多かった 全てをコマンドラインとかエディタで済ますのが好きではない ツールは概ね好き勝手に入れて問題なかった 入れてたもの (OfficeとかAdobe CSは除く) エディタ:Vim Vimで問題ない人間なので。IDE性とかも特に求めてないので、プラグインとかも自動補完とs
前置き 最近、ウェッブフロントエンドエンジニアらしく各種JavaScriptのライブラリを眺めて、調査・選定しているのだけれども、その過程を通じたこととして、多くのライブラリが、ドキュメントのAPIの説明が貧弱すぎる。 jQueryのドキュメントが腐っているというのは既に広く知られた事実であると思うし、そうでないならば積極的に既知の事実として腐っている事を広めて行くべきであると強く思うが、jQueryに限らずとも、ドキュメントが満足な形で整理されていないのをひしひしと感じる。 この手のものでよくドキュメント化されている部類だと感じるBackbone.jsですら、仮引数の名称と定義のみしか書かれておらず、肝心の引数が備えるべきメンバや、引数の型情報が明示的に記述されていない。そのため、APIを俯瞰し、自分の欲しい情報がどこに詰まっているのか・どのように取得できるのか・DOM標準もしくはECM
Servoのリポジトリ内にDOMバインディングのデザイン覚え書きを投入したので、現時点での設計について、そろそろ日本語で説明しておく(英語版は結構前からServoのWikiに書いています)。 この記事の中で使うSpiderMonkey API用語は、結構古いものだったりするので、そこに注意(ServoはFirefox 17とかその辺りのSpiderMonkeyを使ってる)。 ブラウザにおけるDOMバインディングとは この分野については、エデンの園でおきたこと - steps to phantasienという名記事があるので参照されたし。WebKit Chromium port時代のBlinkの話だけど、だいたいどのブラウザでも似たような問題を抱えていて、それぞれ微妙に異なるアプローチで解決している。 改めて私の言葉で要約してみると、「現代の実用的なブラウザエンジンというものは、自身の保有す
Custom Elements W3C Editor's Draft 18 June 2014を元に書いた。 昔、関連仕様のどこかで今回と似た話を見た記憶が有るんだけど、どこにあったか忘れたので、改めて自分の解釈として書いてみる。 Custom Elementで既存の要素を拡張する Web ComponentsのCustom Elementは独自の要素を定義することができるのだけど、新要素の導入以外にも、実際には既存の要素を拡張するという使い方ができる。 ElementRegistrationOptionsの、extendsプロパティというのがそう。 specの例では以下のようにp要素を拡張している(引用): document.registerElement('x-foo', { prototype: Object.create(HTMLParagraphElement.prototype
Rust v.0.11pre時点での情報です。 Rustにおけるムーブセマンティクス だいたいC++のそれと同じものと理解してるんだけど、おさらいとして。 Rustの言語セマンティクスの一つに、メモリの所有権(Ownership)というものがある。これは「このメモリ領域を自身のもの所有しているものは常に一つ(ユニーク)になる」というもので、これが保証されると、特定のメモリの領域は、所有する変数ひいては所有するタスクが決定されるようになる。原則として、各タスクごとの単位でしか、その所有権の貸し借り(borrowing)ができないため、タスクAから他の非同期に動作するタスクBの所有するメモリ領域の変更は不可能になる。タスクAからタスクBに向けてデータを送信した場合、データの所有権ごと送信されるので、結果としてデータ競合が発生しないことが保証される(もちろんArc<T>とか使ったり、生ポインタを
やります http://atnd.org/events/52121 本当に中身を観測するだけの会です 好奇心を満たすのが第一目的 いつやるの 7月上旬 どうしてやるの 色んなところでブラウザエンジンの中身を話す人が増えてきたけれども、「効率的なWebアプリを作る」という文脈の話ばかりで、個人的に物足りない そういう目的で話されるケースばかりなので、ちょっとディープさに欠ける HTML5 Rocksのブラウザ内部の話 は、もはや入り口に過ぎない。最早何も語っていないに等しい。 「HTML5ブーム」は来たけれども、ブラウザエンジン好きが増えた印象は無いし、そっちにフォーカスした会は殆ど無い ブラウザエンジンの内部にフォーカスする数少ないひとつであるGecko勉強会は、Geckoにとタイトルに冠しているので、Gecko以外の話をしていいものか迷った 実装者のひとりであるConstさんによる、CS
この記事はRust 0.10を基準に書かれている 前提 Rustの基本として、明示的にmutを付けて値の変更を可能にした(mutableにした)データ以外は変更することができない(デフォルトimmutableの原則とでも呼ぶべきかな)。これを構造体に適用した場合、構造体のフィールドのmutabilityは、フィールドを保持する構造体のそれを引き継ぐ。つまり、親のmutabilityを子は引き継ぐという原則がある。 なので、こういう感じのコード(疑似コードです)はコンパイルエラーになる。 let bar = Bar { bar: Hoge { hoge: 0 }, barbar: 0, }; // `bar`はimmutable bar.barbar = 1; // `bar.hoge`は`bar`のmutabilityを継承するので変更できない bar.hoge.hoge = 1; まあ詳
自分が技術文書を翻訳するときに気をつけている(こだわっている)こととして、「訳語をむやみに作らない」というものがある。 Rustのドキュメントを読んでいると非常に色んな独自の用語が出てくる。arm, owned, borrowed, box, lifetime, etc...... 典型的な物はcrateだろう。 このcrateという概念は一般的に言うところのモジュールに相当するものなのだけれども、Rust的にはファイル単位をモジュール単位と(用語・暗黙的了解で)みなす節があり、それらをまとめてパッケージとして固めたものをcrateと呼称している。 これから率直に訳語を作るのであれば、木箱ないしはクレートになるのだけれども、どうもしっくりこない。モジュールと訳してしまっては pub mod barなどの点でちょっと不整合が起きる。技術文書の翻訳シーンではよく出くわす光景だと思う。 私の技術
歴史認識 だいたい以下のような流れだと認識している。 IE8以前を含むECMAScript 3暗黒時代があった この時代をベースにベストプラクティスが構築 + HTML5ブームが発生した 暗黒時代なんで結構つらいし、IE9じゃないとECMAScript 5使えないし、結局辛い CoffeeScriptを筆頭としたaltJS一派に救いを求めた(結局Coffeeは一過性のカフェインだったわけだけど) 気がついたらECMAScript 6が来そうになっていた ES6でのsyntaxの拡張・標準ライブラリの増強はカッコいい 気がついたらES5当たり前、ES6も使えそうな世界が来そうになっていた(希望的観測が多分に含まれているのは暗黙の了解と化している) ES6、altJSの次のナウい世界として注目を集める だいたいこんな感じで、ECMAScript 5を用いたベストプラクティス的な物が存在しない、
オレオレMV**フレームワークを紹介する際にjQueryを引合いに出して語る事案が多く、そこで語られるjQuery批判が的外れもいいところなのが散見されるので書きました。 Abstract MV**便利フレームワーク・ライブラリを紹介するときに、jQueryの一番イケてない書き方を引き合いに出して比較して「こんなにすごいんです」と紹介するのは不毛極まりないのでいい加減に止めろ jQueryで書いたコードがひどいのは、クライアントサイドWeb(あえてこう書く)が過去10年近くにわたって設計を軽視してきた結果であり、その根本が変わらない限り、問題は変わらない jQueryエンジニアをdisりながら、Angularエンジニアを産み出すとかギャグじゃないの? 私個人のjQueryに対する見解 だいたい同意する意見: jQueryについての私見 - mizchi's blog mizchi / いか
ES6ならびにDOM4にPromiseが投入されることとなり、すっかりJavaScriptでよく陥るコールバック地獄に対する至高の解決策のように扱われているPromiseだが、万能の解・聖杯ではない。 たぶん誰かが既に似たようなこと書いてると思うけど、とりあえず自分の思考の整理に書く。 Promiseといえば以下のようにコールバックによるコードの無限ネストを解決するものとして扱われることが多い。 var p = new Promise(); p.then(function () { ... }).then(function () { ... }) だが、これはコールバックをPromiseというラッパーを用いてネストしない形に変換しただけに他ならず、Promiseの利点ではない。適当なラッパー関数を作って解決しているのと大差はない。 本質的にはPromiseとは将来的などこかの時点になれば値
昨日のNightly 29でプライベートウィンドウで"Undo close tab"が使えなくなってるなーと思ったら、bug 956826 が原因っぽい。というわけでコメントしたんだけど、備忘録代わりに日本語でも書こうかなと。Twitterだとかなり文章長くなるし。 この挙動の変更について、「そうは言ってもChromiumはやってないしなあ」とあるけど、ここについてはChromiumが明らかに間違っている(というよりも、オプション画面やタブの挙動など、1.0未満のベータ時代に骨子が決まったと思われるChromiumの挙動は全体的にコンセプトワークであって、ほかのソフトウェアが安易に従うには筋が悪い、参考にするには警戒すべき)。 人間が間違えてタブを閉じてしまった場合に復元する手段が無いのは、undoの無いテキストエディタのようなもので、基本的にはコンピュータのソフトウェアとしてゴミだ。まし
この記事はFirefox Advent Calender 2013の24日目の投稿です。 先日開催されたGecko勉強会 2で「Geckoは何者か Geckoはどこへ行くのか 非同期編」という題で、ブラウザがページを処理するにあたってどのような処理をしているのか、および、ここ数年で直面した課題と対応策について、ざっくりと話させていただきました。 本当は、発表したネタを丸まるここに書くつもりだったんですが、縁あって、勉強会でお話しさせていただいたので、その解説を。 Gecko勉強会2の資料 from saneyuki snyk 補足解説 ブラウザの処理の詳細について ブラウザがページを処理するにあたってどのような手続きを踏んでいるのかについては、ブラウザのしくみ: 最新ウェブブラウザの内部構造 - HTML5 Rocks という名記事が存在しています。GeckoとWebKitを参照した上で、
表題の通り、冬コミ(C85、コミックマーケット85)の三日目に、Rust Samurai名義で、Rustについての同人誌「Rust Dojo」を頒布します。 内容および執筆者は以下の通りです。 次元(@dim7th)「Rust 入門」 makoto_kato(@makoto_kato)「RustでのTCP/IPネットワークアプリケーション」 KENZ(@KENZ_gelsoft)「wxRustで始めるGUIプログラミング」 さねゆき(@saneyuki_s)「Introduction to Servo」 Rust Dojoでは、Rustの概要、Rustを用いたTCP/IPアプリケーションの作成方法、wxWidgetsのラッパーライブラリであるwxRustを用いたGUIアプリケーションの記述、そしてRustで記述されたブラウザエンジンServoの解説、と、各人が思い思いにRustについて書い
この記事はWeb Accessibility Advent Calendar 2013のゲリラ投稿です。何か書いてみようかなーと色々思案し、ネタを思いついたところで投稿しようとしてアドベントカレンダーのページを開いたら全部枠が埋まっていたので何日目とか関係なく仕方なくゲリラ投稿します。 さて、Web Accessibilityということで非常に悩んだ物の、ブラウザエンジニアもどきを自称する私としては、本稿ではブラウザの空間ナビゲーションについて語ろうと思っています。 What is 空間ナビゲーション? キーボードを用いてページ中のフォーカスを移動する機能です。それだったらタブキーで出来るじゃねーかと思う方も沢山いらっしゃるかもしれませんが、矢印キーでフォーカスを移動できる機能です。 空間ナビゲーション - Opera Wikiの記述を引用してみましょう。 空間ナビゲーションとは、レンダリ
この記事は某JavaScript Advent Calendar 2013の2日目ではありませんし、ECMAScript Advent Calendar 2013のn日目でもありません(そんなものは本稿執筆時点で存在していない事を確認しています)。単に締め切りのある原稿を書いていて、疲れてしまって好き勝手に文章を書きたかったので、好き勝手に書いているだけです。 接頭辞にES6とつけるべきかDOMとつけるべきか迷うのですが、unwrappingされてるPromiseの話です. WHATWG DOM Standardからもそれが直接参照されてますし、ES6 Promiseあたりと呼んでおくのが妥当でしょうか。 何がいいのか ECMAScriptとDOMの大合同コンセンサスが出るなどすっかりECMAScriptのためのDOM感が増しつつ有る今日この頃ですが、この幸せな点は何と言っても標準化された
第7回くらいのServo Readingで話したことをざっくりまとめた。誰がどれを話したかはmangleしてあるので御容赦を。 個人的にざっくりとTwitterなどなどをクロールして得た感想だけど、GoはCompiled Pythonともいうべき立ち位置な気がする。PythonとかPerlとかRubyとかシェルスクリプトとか以上C未満な箇所を、JavaやScalaよりももっとスマートに置き換える、そういう意味での「システム」開発言語。 対する?Rustは、カーネルとかブラウザエンジンとかゲームエンジンとか、ハードウェアに近いエリアの計算機資源をがしがしと叩きまくるための言語。C/C++の面倒くさい因習やエクストリームな部分をうまく隠蔽しつつ、時々必要になったらunsafeブロックで例外的に許容する。その安全性の担保として、コンパイラを使った静的チェックをCPUとメモリにものを言わせてブイブ
次のページ
このページを最初にブックマークしてみませんか?
『saneyuki_s log』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く