リュックサックを新調した話

その他

リュックサックが欲しくなった

大学生3年の頃に、BERMASの42cmのブリーフケースを買って以来重宝している。単体で1.5kg弱あるんだけど、その変わり生地が非常に硬く、型もしっかりしている上、おまけにショルダーベルトまであるので非常に使い勝手がいい。ポケットなどについてはリンク先を見てください。

大きな収納スペースが2つあるので、コミケのときは買った同人誌を一方のスペースに片っぱしから放り込むのに使い、もう一方に500mlペットボトルを2〜3本格納したりできるし、旅行のときは1泊程度であれば着替えやPCを入れたまま行動しつつサイズによってはお土産を格納できるくらいの容量があり、それでいて型崩れなども特にないので非常に便利に使っている（正確にはマチを広げるためのファスナーを一度修理したことがあるんだけど、実用上は必ずしも必要ない場所のファスナーなので、かなり頑丈です）

[バーマス ファンクション] BERMAS FUNCTION ブリーフ42 2層EX 60135-10 ブラック

[バーマス ファンクション] BERMAS FUNCTION ブリーフ42 2層EX 60135-10 ブラック

が、いかんせん日常の通勤に使うには単体1.5kgは重い上、ポケットの数や頑丈さもオーバースペック気味。なので、軽く散歩するときや通勤時は、高校生の頃に買った小さなショルダーバックを使うようにしていた。とはいえ、このショルダーバックは、当時地元のイトーヨーカドーで4千円くらいで買ったもの + 結構酷使してきているので、いい加減に生地の痛みが激しくなってきてしまった。PCなどを入れると形が崩れる上、内容量もMacBook Air 13などを入れるとそれだけでいっぱいになってしまう程度のサイズ感。おまけにショルダーバックということで歩いたときの斜め掛けが微妙な感じがあったので、新たな鞄をさがすことにした。

紆余曲折

探すに当たって設定した条件は以下の通り。

  1. リュックサック型であること
  2. 容量は大きくなくていい（大容量の用途には最初に述べた42cmのブリーフケースで十分だし、それで入らない荷物は私の日々の生活では扱わないし、必要になったら巨大なリュックサックを買えば良い）
  3. それなりに頑丈であること

リュックサックを選んだのは、運用上、両手を開けたいため、かつ片方の肩にばかり負担をかけたくなかったから。 容量は、日常使いのものなのでそんなに大きくなくていい。 頑丈さは、まあ、そりゃ求める。まして今使っているものが型崩れを起こした果てのものだから。

秋葉原のヨドバシカメラでのんびり探していたのだが、結構難航した。頑丈なリュックサックを求めると概して大きなものになってしまうか、見た目がビジネス向けすぎてダサいもののどちらかになってしまう。かといって小さいものを求めると、作りが雑だったり、見た目がいいものは本当に携帯と充電器とハンカチと財布とかしか入らないようなサイズになる。もしくはビジネスマン向けのダサい感じ。悩ましい。

邂逅

結局、今日も収穫は見つからないのか、やはり上野あたりでいろいろ店を回った方が良いのかと失意にくれかけた瞬間に、Timbuk2のQ BACKPACKを発見した。掘り出し物だ。棚の一番下の段の奥の方に眠っていた。容量はそこそこでお大きすぎないが小さすぎでもない、ポケットの数もまあそれなり。それでいて作りがしっかりしている。マチはそこまで太くないので嵩張らないし、背負ってもバックパックが後方に盛大に突き出すような不恰好な感じにはなりにくい。デザインも悪くない。いい。値段も8千円前後なので、失敗してもそれほどダメージは負わない価格。売り場の同価格帯の製品に比べると、1万円を超えていてもいい感じの作りをしているので、お得感はある（実際、メーカー希望小売価格だと1万円をはみ出ている）

というわけで、これのディアボロ（赤系）を買ってきましたとさ。他の色が無かったから詳細な比較検討はできなかったんだけど、割とカジュアル用途の鞄まで黒単色にはしたくなかったし、深いワインレッドでそこまで派手ではなかったこと、他の色がそこまで好みのトーンでもなかったので、結局置いてあった色でいいだろと判断。とはいえ、Martini Olive Surf Stripe（明るい緑）あたりは実は気になっていた。でも結構色が明るいので、そのうち飽きそう。 カーボンフルサイクルツイル（カーキ系だけど灰色に近い？）は、もっと緑・茶系だったらいいと思った（でも違う感じ）。てなわけで消去法でディアボロ（赤系）を選びましたとさ。

[ティンバック2] TIMBUK2 Q BACKPACK 396-3-6061 ディアブロ (ディアブロ)

[ティンバック2] TIMBUK2 Q BACKPACK 396-3-6061 ディアブロ (ディアブロ)

使い勝手どうよ

買ってみてだいたい3週間くらい使ってるんですが、マチが細い割に結構いろんなものを投げ込めるので重宝してます

option-tにPromiseへのキャストメソッドを用意したりなど

ECMAScript javascript

自作RustスタイルECMAScript用Option型ライブラリoption-tをいろいろアップデートしたので、リリースノートがてら書く。ご存知ない方はこちらをどうぞ。要はOption<T>/Maybe型だ。

Promiseへのキャストメソッドを用意した

ECMA 262の文化には、すでにMaybeもどきの標準仕様が存在する。ご存知Promiseだ。

だが、Promiseは非同期前提の操作になるので、同期的に実行するAPI群との親和性が良いとは言えず、かといって全てをPromiseにするほどでもない場合のために、わざわざこんなライブラリを作ったというのは前に書いた通り。

でも、今の世の中、どこかしらの関数がPromiseを返すじゃん？そこに上手く混ぜられるととっても楽じゃん？　てなわけでcast用メソッドとしてOptionT.asPromise()を追加した。これにより、スムーズにPromiseと混ぜることができ、非常に最高な気分になれる。

こんな感じ。XHRを投げつつ、別のフラグの有無を確認し、両方が成功した場合に〜みたいなケースに有用になりました。

var option = new OptionT.Some();
var xhr = new Promise();

Promise.all([
  option.asPromise(),
  xhr,
]).then((tuple)=>{
  var responce = tuple[1];
  ...
});

ちなみに、Promise<T> -> Option<T>の変換は、非同期から同期への変換なんで無理ですやってない。

いろいろメソッドを追加した

追加しました。前よりも楽に書けるようになったと思います、どんなの使えるかはgithubのissue一覧かCHANGELOG.mdをみてください。

ここで注意点がひとつ. Option<T>.mapOr()とOption<T>.mapOrElse()については、unstable APIという区分にしてある。理由は、取りうる仮引数の順序が、「デフォルト値生成」 -> 「map関数」の順序になっているため、直感に反するのではないかというのが理由。元のRustのstd::optionのAPIが微妙っちゃ微妙なので、Rustの動向を無視してもいいのだが、ちょうど今のタイミングで、Rust側でも似たようなissueが立っていて、できることならもう少し様子見したいというところ。なのでunstableという区分にはしている。

まあ、変更するとしても仮引数の順序を入れ替えるだけで、挙動としては変わらないのと、そういう破壊的変更するときはsemver的にメジャーバージョン上げるので、使うのをためらうほどではないかもしれない。ただし、今の所はNODE_ENV = 'production'時以外は``console.warn()でうるさく警告出してるので気をつけて下さい。

一応フィードバックありましたらお知らせください。

Option/Maybeとかで解決していることを、さながらgolangのようにES6のdestructuring assignmentで解決する

ECMAScript

ES6から使えるようになるdestructuring assignmentを使って、タプル的に返して受け取れば、複数の値を楽に受け取れるので、エラーハンドリング的なものが楽にできるようになりますよね！という話です。先日書いたライブラリで解決・緩和しようとしていた問題に対する別のアプローチ。

今更言うまでもない、おそらく常識的なテクニックの話なんですが、みんなES6の話をしているのに、こういう使い方の話をロクにしていないので「こういう話しようぜ！」と喧嘩を売る意味で書きました。

let fn = function () {
  return [
    true, // 関数が正常処理できたか or 値の有無とか
    100, // 実際の値 
  ];
};

let [ok, val] = fn();
if (!ok) {
  return; // 正常処理できていない, 値が特になかったので帰る
}

まあ、まんまgolangのmultiple resultsなんだけど。

golangのmultiple resultは、手続き型の枠内で、Maybeとか入れずにMaybeで解決しようとしていた問題に（過程は知らないが結果として）取り組んだアプローチとして、ああなるし、よくできているなあと思う次第です。

ES5の範囲でOption<T>型を表すライブラリ、option-t を作った

ECMAScript javascript

動機

初期状態で未選択なラジオボタンがあるようなフォームを作っている場合、ラジオボタンに対応するモデルの値を「この値は未選択である」というのをJSで表現するのは結構面倒くさい。チェックボックスであれば, booleanのどちらかで状態が確定するが、ラジオボタンだと取りうる値は複数になるし、初期状態で選択されているか否かの問題が発生する。選択されていない状態を専用にフラグとして持つのは気持ち悪いが、かといって、未選択の状態を-1や9999ないしnull、undefinedで表現するのは危うい。コードを書いた本人しかわからない。

RustやScalaなどのようにOption<T>/Maybeがある言語なら、こんなまどろっこしい思いはせずに、明示的に値の有無を表現できる。 というわけで、ないなら作ってしまえば良いじゃないメソッドで作った。

Option<T>型について

私が説明するよりもわかりやすいであろう先行の説明があるので、それを紹介する。

作ったもの

元々、仕事で書くコードの為に作ったものなので、もしかしたら会社のgithubアカウントの方に移管するかもしれない。

設計思想

  • Option<T> をECMA262 5thの範囲内で実装する
  • APIモデルについては、Rustのstd::optionをベースとした
  • 詩的な名前は思い浮かばなかったので質実剛健な名前にした
    • あまり文学的な名前にしても後で忘れる。
  • 主対象環境は、TypeScriptおよび生のES5

使い方

こんな感じ

var OptionT = require('option-t');

// `Some<T>`
var some = new OptionT.Some(1);
console.log(some.isSome); // true
console.log(some.unwrap()); // 1

// `None`
var none = new OptionT.None();
console.log(none.isSome); // false
console.log(none.unwrap()); // this will throw `Error`.

おなじみのmap(), flatMap()の他に、値を取り出す為のunwrap()、デストラクタ代わりのdrop()あたりを実装している。最終的には、Rustのstd::optionのAPIのほとんどを実装したいところ。

Some<T>とNoneのインスタンスがOption<T>であることを、どう表現するか？

これが一番悩んだ。最初はOptionTypeのような一つのオブジェクトを用意し、コンストラクタに渡す引数がundefinedか否かを確認するようにしていたんだけど、「正常系でundefinedを返すケースでも、暗黙的にNoneに変換されてしまう」ため、断念して、結局別個のオブジェクトを作る事になった（ OptionTypeについては移行期間中のため、deprecated扱い）

ここで、それぞれのオブジェクトがOption<T>であることを表現する為に、Option<T>というインターフェースを用意して、TypeScript向けにはそれぞれがOption<T>を実装していると見せることにした。

一方、生のJS向けにはOptionTというオブジェクトをプロトタイプチェーンの祖先に突っ込んで（基底クラスに突っ込んで）、option instanceof OptionTで確認できるようにした。が、これについてはあくまでも型システムにインターフェースを所持しない環境向けであり、TypeScriptのようにインターフェースが普通に使える環境には露出させていない。

Promise<T>をMaybeモナドのように使うのではダメだったか

2015年の我々には、モナドと非同期コンテナを混ぜ込んだ、Promise<T>という共通インターフェースがある. これを使うのも考えたが、少なくともES5にはawaitに相当する仕組みが無く, Promise<T>では値を同期的に取り扱うことができないので止めた。RxなどのObservable<T>についても同様。同期的に扱えるコンテナが欲しかった

なぜES5? ES6でもbabelでも良いじゃん？

ES5で十分に書ける範囲の内容なので、transpilerは（要らないと）判断した. そのうち気が向いたらTypeScriptやbabelに移行するかもしれないけどね。

browserifyありきなんですが

browserifyありきですね

先行事例

作った後に気がついたんだけど、極めて類似の先行事例にopty (npm)があった。こちらはRustのAPIモデルをベースにTypeScriptで書いたもの。

先にこっちに気がついていればoptyを使う可能性もあったけれど、テストコードが無かったのと、JSONシリアライズ時の表現が特に記述されていなかったのと、RustのそれよりもAPIが（無駄に）増えていたので、音楽性の問題で当面は別個に開発するつもり。将来的には、あっちに合流して大統合してもいいかなとは感じる

まとめ

感想お待ちしております

CSSのcanvasとviewportとposition:fixedとpinch zoom

css browser
  • 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 consult a document.

When the viewport is smaller than the area of the canvas on which the document is rendered, the user agent should offer a scrolling mechanism.

initial containing block

The containing block in which the root element lives is a rectangle called the initial containing block. For continuous media, it has the dimensions of the viewport and is anchored at the canvas origin; it is the page area for paged media. The 'direction' property of the initial containing block is the same as for the root element.

  • ブラウザ（=screen mediaのUA）のスクロールバーを伴った描画領域 = viewport
  • レイアウトはcanvasに描画される
  • initial containing block（デフォルトのcanvas領域）のサイズはviewportの幅と高さに依存する.

viewportが1000pxの場合にhtml要素のwidthを100000pxにしたらどうなるのか？については、overflowプロパティによって定義されていて、

UAs must apply the 'overflow' property set on the root element to the viewport. When the root element is an HTML "HTML" element or an XHTML "html" element, and that element has an HTML "BODY" element or an XHTML "body" element as a child, user agents must instead apply the 'overflow' property from the first such child element to the viewport, if the value on the root element is 'visible'. The 'visible' value when used for the viewport must be interpreted as 'auto'. The element from which the value is propagated must have a used value for 'overflow' of 'visible'.

のように,

  • root要素のoverflowプロパティがviewportに対しても適用される
  • viewportのoverflowプロパティがvisibleである場合、autoとして解釈されるので、スクロール機能の有無はUA依存となる

position:fixedの挙動

In the case of handheld, projection, screen, tty, and tv media types, the box is fixed with respect to the viewport and does not move when scrolled.

For other elements, if the element's position is 'relative' or 'static', the containing block is formed by the content edge of the nearest ancestor box that is a block container or which establishes a formatting context.

要は、対象のボックスがviewportに対しての固定座標に配置されるということ.

CSS Device Adoptationでの拡張

CSS Device Adaptationでは、meta[name="viewport"]でのviewportサイズの指定を可能にしたiOS Safariなどの実装を追認を行う形で仕様が策定されており、ここでは、initial viewportとacutual viewportの二種類が定義されることになった。

initial viewport

This refers to the viewport before any UA or author styles have overridden the viewport given by the window or viewing area of the UA. Note that the initial viewport size will change with the size of the window or viewing area.

actual viewport

This is the viewport you get after the cascaded viewport descriptors, and the following constraining procedure have been applied.

たとえば、meta[name="viewport"][content="width=device-width"]を指定した場合は以下のようになる

  1. initial viewportがブラウザのウィンドウサイズや描画領域に基づき決定される

  2. UAスタイルおよびユーザースタイルによるmeta[name="viewport"]や@viewportの計算が行われる

    1. meta要素によるwidth=device-widthは@viewport { width: 100vw; }として取り扱われる
    2. ここでの100vwは1で計算されたものが取り扱われる
    3. width: 100vw;はmax-widthとmin-widthにマップされる
    4. 3でマップされた結果を元に、actual viewportの幅を計算する

  3. 計算の結果、deviceの幅=ウィンドウの幅を自身の幅としたactual viewportが算出される

  4. actual viewportを元にinitial containg blockを再度計算する

ここでもUAスタイルがあるために、仮にviewportの指定が行われていない場合は、従来のサイトとの互換性のために、モバイルブラウザでは自動的にviewportの横幅が1000px前後に設定されたりするようになる。

デスクトップブラウザについては@viewportのUAスタイルを持たないと解釈すればいいのだろうが、dbaronによるissue表記があるので、完全に定義が確定しているわけではないのだろう。

では、メディアクエリはどこで計算されるのか？ それは以下のように定義されている:

  1. Cascade all @viewport rules using the initial viewport size for values and evaluations which rely on viewport size
  2. Compute the actual viewport from the cascaded viewport descriptors
  3. Cascade all other rules using the actual viewport size

つまり、viewportの計算が全て終わらないとmedia queryをはじめとした計算は起こらない

zoom

ズームについては、まず、CSSOM Viewにて二種類のズームがあることが述べられている：

There are two kinds of zoom, page zoom which affects the size of the initial viewport, and pinch zoom which acts like a magnifying glass and does not affect the initial viewport or actual viewport.

この詳細についてはCSSOM View側では「CSS Device Adaptationを参照」とあるのだが、CSS Device Adaptationには明確なterminologyが設定されているわけではなく、断片的に文章中に記述されているだけである。

When the actual viewport cannot fit inside the window or viewing area, either because the actual viewport is larger than the initial viewport or the zoom factor causes only parts of the actual viewport to be visible, the UA should offer a scrolling or panning mechanism.

This is a magnifying glass type of zoom. Interactively changing the zoom factor from the initial zoom factor does not affect the size of the initial or the actual viewport.

position:fixedとpinch zoomを組み合わせるとどうなるのか

今までに述べた内容をまとめると、

  • viewportはブラウザ（=screen mediaのUA）のスクロールバーを伴った描画領域
  • position: fixedは、対象のボックスをviewportに対する固定座標に配置する
  • pinch zoomはactual viewportに影響を与えない

となるのだが、pinch zoomをした場合に、Android BrowserやiOS Safariでは常にUAの描画領域の枠の固定位置にposition: fixedが配置されるのは、仕様上正確なのかどうか分かり難い…… pinch zoomではviewportに影響を与えないとあるが、zoomをしている以上は、UAとして表示している領域としてのviewportの横幅は相対比で小さくなっているはず。ちなみにW3C Bugzillaでは特に何も見つからず……

pinch zoomとpostion: fixedへの各UAの対応

IE11 Mobileや最近のChromiumでは、この問題に対して、「pinch zoomを行っても、position: fixedを常にUAとして表示している領域に配置しないようにした」（私の知りうる限り、Firefoxも修正を検討中である）

どのような変更を行ったのかはChromiumの変更を開設したスライドがわかりやすい。

このスライドでは、viewportとされるものは正確には、

  • visual viewport: UAとして表示している領域という意味でのviewport
  • layout viewport: レイアウト計算に用いられるviewport

の二種類が存在するとしている（正確には、この二種類が存在しているとすることで、問題を解決することに成功した）。

pinch zoomの存在しなかった時代（CSS 2.1での定義）では両者は統一して扱われるものであったのだが、モバイルブラウザ（およびUIとしてのpinch zoom）の登場により、分割して扱う必要が出てきた。しかし、現行のCSS Device Adaptationではそこにまで踏み込んだ定義がされていないために話がややこしくなっている。いや、この一件に限らず、CSS Device Adaptationは出来がいいspecとは思えないですけどね……

ちなみにWindow.scrollX/Yやwindow.innerWidth/Heightなどのviewportのスクロールに絡む座標は、Chrome Beta for Android 40.0.2214.69で確認したところ、visual viewportを基準に算出されるようになる。まあそうするしかないですよねcompat的にも。なので、

The innerWidth attribute must return the viewport width including the size of a rendered scroll bar (if any), or zero if there is no viewport.

The scrollX attribute attribute must return the x-coordinate, relative to the initial containing block origin, of the left of the viewport, or zero if there is no viewport.

以上の定義中にある"viewport"は, visual viewport。ややこしい。

まとめ

図にするとこんな感じ。仕様+実装を元に、viewportというものは、このような概念であると解釈が出来る。

尚、visual viewportとlayout viewportという単語は、Chromiumのスライドのやつが都合がいいから使ってるだけね。 

   +---------------------+----------+
   |                     |          |
   |  *--------*         |          |
   |  |        |         |          |
   |  |  visual viewport |          |
   |  |        |         |          |
   |  |        |         |          |
   |  |        |         |          |
   |  *--------*         |          |
   |                     |          |
   |                     |          |
   |   layout viewport   |          |
   |                     |          |
   |                     |          |
   +---------------------+          |
   |                                |
   |       canvas                   |
   |                                |
   +--------------------------------+

  • directionがltrの場合, 左上からactual viewportが始まる
  • layout viewport = actual viewport
  • layout viewportはinitial contaning blockの大きさを決める
  • visual viewportはpinch zoomなどにより虫眼鏡のようにサイズが 可変したり、スクロールしたりする
    • overflow:hiddenがviewportに適用される場合はinitial containg blockを超えて動けない
    • Window.scrollX/Y, Window.innerWidth/Heightなどのスクロール関係値は、visual viewportを元に算出されていると解釈できる
  • IE11 Mobileや最近のChromiumを除く従来の実装では、position:fixedはvisual viewportを元にレイアウトされていると考えられる

2014年やったこと（物書き業編）

log

MozillaのLevel 3 Committerになった

だいたい三月ぐらいに。

Mozillaにはコミッタにアクセス権限がレベル形式で設定されていて、レベルに応じてパッチをlandできるリポジトリに制限がある。Core ProductsであるFirefoxなどのリポジトリ（mozilla-central/inbound/fx-teamには）に投入するには、Level 3が必要。Githubに置かれてるリポジトリは、ものによって微妙に異なるけど、概ね、この規約に基づいている。

アクセスレベルが足りない場合は、パッチのレビューが終わった時点で、だれかコミット権を持っている人にlandingを頼む必要がある。が、自分からアクティブにメンターを探さないといけないわけではなくて、だいたいは該当bugにcheckin-neededフラグを立てておけば、モジュールオーナーだったりが見つけ次第landしてくれる。

自分は2012年ごろにLevel 1は取っていて、Mozillaのビルドサーバーとテストインフラを使えるようにはなっていたんだけど、（レビューをもらっても）landが自由にできないので結構苦労する時があった。複数人が現在進行形で触っている領域へのパッチなどの場合、こちらのパッチが先にレビュー完了しているのに、checking-neededに気付かれずに、他の人のパッチがlandされた結果、conflictを解消して再度やり直したり……　まあダルいよね。

というわけで、Level 3 Committerを取りました。これで自由に（もちろんr+済みの）パッチをlandできるようになりました。Level 1のときはtry-serverを使えるだけだったのでコミッタと名乗るのにちょっと抵抗があったけれども、これで胸を張ってコミッタと名乗れるようになりました。

Servo関係

色々プルリクを投げた。

一番わかりやすいあたりだと、SpiderMonkeyのGCとの統合周りのデザインについてのドキュメントを書いたり、DOMまわりの細々とした変更を行ったり。主にscript関係をいじっていた感じ。結果、DOM bindingに関する知見がそれなりに増えた。

Servoのissue, pull requestは全部（流し読み含めて）目を通しているので、ほとんどのコードに何が入ってるのか大きいトピックは知っているけど、細かくコードレベルでは結構微妙。なので、2015年の抱負としては、もっと色々やっていきたい

Servoのpeerになったり、script以下のreviewer業始めたり

Githubの仕様上、issueを閉じるには権限が必要で、閉じられなくて困ってた旨をircで愚痴ってたら、peer権限もらった。モジュールオーナーというわけではないけれども、編集権限持ちです。ある種のコミッタ業（Servoの場合はpull requestをbotが自動でマージするので、コミッタ権限がそこまで重要ではないのだけれども）。

それと、主にscript以下のreviewer業も始めることになりました。とりあえずgood-first-bug級の簡単なパッチについては問題なくレビューできる感じだったり（たぶん）

余暇としてのコミッタ業

やっぱり、それなりに難しい。issueとか見忘れるとすぐに溜まる。ここらへん、もう少しなんとかうまくやれんかなというのが来年のチャレンジになりそう。

コミュニティ的な何か

Mozilla Japan様に会場を毎回お世話になった（ありがとうございます）。

Rust Language関係

Rust Samuraiをやったりした。

コミュニティ運営業は個人的にそこまで重点を置いていないのと、そろそろ言語の構文とかコンセプトじゃなくて、何ができるかとかやったほうがいい気はしているので、来年もコミュニティ業やるかのモチベーションは微妙だったり。

ブラウザエンジン先端観測会

自分の問題意識として「ド濃密な会が少ない」というのがあって、少ないならば自分でやるしかないメソッドでやった。

幸いにして好評だった模様で、次回開催について聞かれるものの、これが結構難しい…　理由は

  • 半年スパンでポンポンとエンジンが面白いことを幾つもやるわけではない
    • やっていても、とっつきやすい題材ではない。
  • speakerを探すのが大変

な辺り。前者に関しては、「わかるやつだけわかればいい」を突き進めればいいんだけど、それでも後者は難しい問題だったり。

他に面倒臭いのはマッチングなんだけど、長くなるので今回は省略する。

LL Diverに出た

縁あって、LL Diverの「帰ってきただめ自慢」のRust枠で登壇しました（資料）。

言語そのものとしては、当時はまだ1.0のリリース時期も見えなかったのと、マルチパラダイム志向でだいたいの機能を持っていたのと、常に変更し続けるスタイルなので悪いところがあってもそのうち直る可能性が非常に高いので、特にダメ自慢するところはないだろうと踏んで、主にエコシステムをダメ自慢することに。まあ、処理系が開発中でマイルストーンしか出てない言語なんで、エコシステムもへったくれもないわけですが；

その後、codegenについてはparallelに動作するようになってきたり、cargoがRust界デフォルトになってきたり、シングルスレッド性能も一部ベンチだとC++と同等を示す程度になってきましたが、相変わらずライブラリだけは少ない。ここらへんは1.0リリース後に期待したいところ。FFI bindingだけならば割と簡単にかけるので結構すぐに揃う気はする。フルRustはその後でしょうな。

2015年に向けて

通年としては

  • もう少しServo業うまくやりたい
  • 論文とかもちょくちょく読んでいきたい

短期的には

  • Rust 1.0リリース記念会は、たぶん、やります
  • ブラウザエンジン先端観測会 vol.2も、やり方変えれば目処立ちそう

みたいな、そんな感じ。