ServoのDOMバインディングの話 - saneyuki_s log
Servoのリポジトリ内にDOMバインディングのデザイン覚え書きを投入したので、現時点での設計について、そろそろ日本語で説明しておく（英語版は結構前からServoのWikiに書いています）。 この記事の中で使うSpiderMonkey API用語は、結構古いものだったりするので、そこに注意（ServoはFirefox 17とかその辺りのSpiderMonkeyを使ってる）。 ブラウザにおけるDOMバインディングとは この分野については、エデンの園でおきたこと - steps to phantasienという名記事があるので参照されたし。WebKit Chromium port時代のBlinkの話だけど、だいたいどのブラウザでも似たような問題を抱えていて、それぞれ微妙に異なるアプローチで解決している。 改めて私の言葉で要約してみると、「現代の実用的なブラウザエンジンというものは、自身の保有す
Web ComponentsとHTMLのセマンティクスと自分の将来予測 - saneyuki_s log
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
Servoの夢 - saneyuki_s log
Rustについて、自分としては流行ってくれなくてもいいというか、別に流行ること自体は本当にどうでもよくて、言語自体の完成とServoが形になってくれさえすればそれでいいと思っている。Rust Samuraiなんてイベントやってるけれども、個人的に普及させる気がないと常々言っているのはこれが理由。 もちろん流行ることによるメリットはあって、処理系自体の改良に携わる人数の増加や、有為なツール群が出てきやすくなる土台ができるのでコミュニティにとっては重要なのだけど、個人的には二の次で、自分の第一目標はServoなんだな。 Mozillaという名前を聞いただけで抵抗感を感じる人がいるのは知っているし（それこそ泥舟のように避ける人も知ってる）、今も昔もMozillaの動きに「胡散臭さ」が伴うのは周知の通りだし、本当にハンドリングが下手だなと思うときもあるけれども、それでも、出してくる技術はイカれてて
Rust言語で遊ぶにあたって大切なこと - saneyuki_s log
とるべき基本的なスタンス 用語が一定しない Rustの公式リファレンス・チュートリアルでの名称と、開発陣のブログやTwitterでの名称が違うのはざらです。諦めましょう。たとえば、~はチュートリアルではOwned Boxと書かれていますが、owned pointerとかunique pointerとか色々別の呼び名で呼ばれます。考えるな感じろ。 構文の変更を気にしてはいけない Rust 1.0のリリースを14年内に予定していたはずなので、言語の思想・セマンティクスに関わる重大な変更は基本的に入ってこないようになっていますが、それでも、0.9のリリースノートで分かる通り、細かい変更は大量に入ってきています。細部を気にしたら負けです。「どういう変更なのか」の大枠だけを掴めば問題有りません。考えるな感じろ。 Twitterでつぶやく時はハッシュタグをつける #rustlangというハッシュタグを
Rustで値のmoveが起こる場合 - saneyuki_s log
Rust v.0.11pre時点での情報です。 Rustにおけるムーブセマンティクス だいたいC++のそれと同じものと理解してるんだけど、おさらいとして。 Rustの言語セマンティクスの一つに、メモリの所有権（Ownership）というものがある。これは「このメモリ領域を自身のもの所有しているものは常に一つ（ユニーク）になる」というもので、これが保証されると、特定のメモリの領域は、所有する変数ひいては所有するタスクが決定されるようになる。原則として、各タスクごとの単位でしか、その所有権の貸し借り（borrowing）ができないため、タスクAから他の非同期に動作するタスクBの所有するメモリ領域の変更は不可能になる。タスクAからタスクBに向けてデータを送信した場合、データの所有権ごと送信されるので、結果としてデータ競合が発生しないことが保証される（もちろんArc<T>とか使ったり、生ポインタを
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を用いたベストプラクティス的な物が存在しない、
モバイルWebでH.264がデファクトスタンダードになった件について思ったこと - saneyuki_s log
Mozilla が H.264 をサポートへ、webM 一本化を断念 - Engadget Japanese Mozilla の H.264 サポートについてのメモ - hogehoge @teramako この記事、Twitterとかはてブを見ると結構衝撃的に受け入れられたみたいだけど、engadgetが記事にする数日前にCNETが似たような記事を書いていたし、更にその数日前には「OSプラットフォームに組み込まれたコーデックを使う為にMPAPIというAPIを用意するのはどうだろうか？」という大元の議論の存在も知っていたので、engadget の記事についてはさほど衝撃ではなかった。 engadetの記事については「現時点においては」若干の語弊が含まれる。Mozillaは確かにH.264をサポートするとは言ったけど、現時点ではあくまでもモバイル分野に限る話でありデスクトップ版の Firef
「Firefox 開発停止」の誤解 - saneyuki_s log
Firefoxのシェアについての話を追記した。 Mozilla Fluxも書いてた。 Firefoxの延長サポート案へのリンクを脚注に追加した。 Firefox with Bingの話を脚注として追加した。 書きあがって公開する頃には Mozilla Flux あたりがこれよりもマトモでわかりやすい反論記事書いてくれてるはずなんだけど、とりあえず書く。 以下のような記事が注目を集めている。 Firefox faces uncertain future as Google deal apparently ends | ZDNet Firefoxがピンチ シェア低下、人材流出、Google契約打ち切りで【湯川】 : TechWave で、これらに加えてどこかの2chまとめブログとかが「Firefox 開発停止！」みたいな見出しつけて編集したものだから、Twitter を「Firefox 開発
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
