病みつきエンジニアブログ

機械学習、Python、Scala、JavaScript、などなど

.gitignore作るなら、giboを使おう

最近技術研修でJavaやってます。

で、.classとかをコミットしてしまう人が居て、そこは.gitignoreをちゃんと設定すべき、です。

で、「ちゃんと.gitignoreを作る」って結構面倒くさいです。例えば、Macだったら .DS_Store を.gitignoreするべきだし、Javaだったら *.class とか、Eclipseまで手をだすと bin とか。

そこで、 gibo というソフトウェアが超おすすめです!

できること

$ gibo Java

とやると、

### https://raw.github.com/github/gitignore/master/Java.gitignore

*.class

# Mobile Tools for Java (J2ME)
.mtj.tmp/

# Package Files #
*.jar
*.war
*.ear

という文字列が作られます。これが何を表してるかというと、githubが考える、Javaについての.gitignoreのベストプラクティス」ということ。なので結構信頼性高いよね、という感じあります。

で、さらに「 Macの.DS_Storeも無視したい 」「 Vimで作られるスワップファイルとかも無視したい 」「 Eclipseのも無視したい 」とか思った時は、

$ gibo Java OSX Vim Eclipse

という感じで指定できます。

で、giboがするのは、ターミナル上に文字列を表示するだけなので、

$ gibo Java OSX Vim Eclipse > .gitignore

とかにすると、giboが生成した文字列を、.gitignoreファイルに保存できます

インストール方法

Macでhomebrew使ってるんだったら

$ brew install gibo

で終わり。

追記

gitignoreを生成するgiboとgiを比較 - nFact

gi(gitignore.io)という、似たようなツールとの比較。詳細。

giはgiboより使えるものが増えているメリットがありつつ、ネットワークアクセスに依存してるのが辛いっぽい(多分、curl のラッパーにすぎないから。giのラッパーがありそう)

文章読むとき、選択しながら読む人いるよね?

これ俺のことなんだけど。

ときどきはてなスター見ると、文章の変なところ選択して、はてなスターが付けている人がいる。

これって、多分、選択しながら文章読んでて、うっかりはてなスターつけちゃった人なんじゃないかと思うわけですよ。

ニューラルネットによる単語のベクトル表現の学習 〜 Twitterのデータでword2vecしてみた

最近にわかにword2vecが流行っています。ので、乗っかってみました的記事です。

理論に関してはあまり詳しくしらないので、印象だけで語っているかもしれません。何かありましたらTwitterかコメント等でご指摘いただけますと幸いです。

ちなみに、失敗した話が多いです

word2vecと単語のベクトル表現

word2vecは、機械学習の分野で使われる、ニューラルネットというモデルを使ったツール/ライブラリです*1。名前の通り、wordをvectorにします。vectorにする、というのは、ベクトル表現を獲得するということで、意味(みたいなもの)の獲得というか、素性の獲得というか。

単語のベクトル表現の獲得自体は、別にword2vecにしかないわけではありません。言い換えると、昔からあります。LDAを使って単語のトピック分布のようなものを学習したり(vingowでやりました)。余談ですが、この方法で、スパム単語の獲得を今度やろうと考えています。

しかしword2vecで面白いのが、単語の演算が(精度高く)できることです。例えば「king-man+woman」をベクトル演算してみると、「女性でいうところのking」つまり「queen」が出てきますよ、と*2

単語のベクトル表現を1段落で大雑把に正当化すると、「ある単語は、ある文脈で出やすいはずだ、共起してるはずだ」ということだと理解しています。例えば「初音ミク最高!!!」「ミクはニコ動でブレイク」といった文章から、ミクは「最高」で「ニコ動」という素性が推測できたり、「ミクはボカロ」「KAITOはボカロ」といった文章から、ミクもKAITOも「ボカロ」という素性が大きい、と推測できたり(結局は、どう共起するか、ということ)。

このあたりのお話は、海野さんによるこちらのslideshareが詳しいです。

Statistical Semantic入門 ~分布仮説からword2vecまで~

ということで、実験に移ります。

コーパス

コーパスは、表題の通り、Twitterのツイートです。ただし、

  • 形態素解析の辞書は、vingowのタグも含む(つまり"初音ミク"のような新語がコーパスにあったりします)
  • 検索ワードは "。,!,?+-\n+-笑+-「+-」+-w+-w+-(+-(+-http+-https+exclude:retweets"
  • URL投稿やリツイートを含まない
  • 「(」「「」「w」「#」あたりを含むと形態素解析失敗しそうなので、含まない*3
  • 10単語以下のツイートも文章として崩壊してそうなので、含まない
  • 半角・全角は正規化(ア1→ア1)
  • 132万1252ツイート、174MB

だいたいこんな感じです。

f:id:yamitzky:20140311222046p:plain

実験プログラム

yamitzky/word2vec-japanese-twitter · GitHub

プログラムは、github上にアップロードしてあります(ツイートのデータはDBからダンプしているので、取得プログラムはありません)。

また、実験結果のモデルファイルも置いてあります。余談ですが、モデルデータであれば著作権法上も大丈夫であると考えています(参考)。

また、あんちべさんによる自然言語処理の最新手法"word2vec"で艦これ加賀さんから乳を引いてみる - あんちべ!の記事を参考にしています。ありがとうございます。

実験1:とりあえず実験

例えば、各単語に似ている単語を出してみます。左から順に近いですが、

akb:nmb ske hkt 48 乃木坂 exile 東海 hy 集い 背番号
ミク:ザク 初音 誕生 レミオロメン 米津 杏子 sug happybirthday lat グフ
北海道:名古屋 京都 新潟 仙台 長野 大阪 札幌 長崎 東京 神戸
スルー:無視 補導 放置 拒否 敬遠 削除 退会 ブロック 解除 解放

など、なんか良さそうです。しかし、全然ダメなのもあって、

スク水:似非 赤ずきん 純潔 トランクス 革靴 紺 壷 剣士 カーディガン 赤毛
しょこたん:兼ね合い ひれ伏す デール 木製 atsushi 松たか子 gu ストライプ 島田 念願

あと、リア充に関しては「ハゲ」が一番近いという結果が出たのですが、定性的な解釈をお待ちしております

リア充:ハゲ ナルシスト 腐女子 ババア ニート イケメン キモオタ 帝京 リスニング 反則

「近い単語」をどう解釈できるかで言うと、「それを素性ベクトルで表現した時、距離が近そうか」ということだと思います。つまり、似た要素を持っているか。必ずしも、直感的な「意味」を表すかはわからない、と思います。

また、ここらへんのダメな理由は、だいたい出現頻度の少なさ(コーパス性質)で理由付けできる気はします。逆に、出現が多い単語(≒ツイッターでよくつぶやかれる単語)ほど、精度が高くなりそうです。

次に単語の演算をしてみます。A-B+Cは、単語のアナロジー「BにおけるAは、Cにおける何か」を表します。

良かったものとしては、

akb-東京+大阪:nmb hkt ske 乃木坂 jump spyair しょこたん 48 立見 exile
彼氏-男+女:彼女 友達 弟 恋人 知り合い お父さん お母さん リア充 旦那 誰々

こちらもひどいものはひどくて(というか、酷いのがほとんど)、

日本-東京+ロンドン:戦車 自国 国々 国外 世論 在り方 有数 ウイグル 最高峰 従来

Twitterでよくつぶやかれそうな場所に関するものでも、このように失敗するのはちょっと残念でしたが、そういう共起の仕方をしないのかもしれません*4

実験2:コーパスの量の変更

コーパス量が減ると、どう失敗していくか、というのを確認したかったです。ツイート数を、10万ツイートに絞ります。ファイルサイズはだいたい12MBです。

すると、

akb:ワンピース 司令 唯一 ed 雄 王様 パーカー 沢 ガ ガラス
ミク:たった 前半 丸 ラブライブ 級 プレミアム 講座 23 発売 誕生
北海道:長野 rad ギリ みなさん 後藤 夕食 ジル ゲリラ 大阪 セガ

など、結構ダメですね!

僕の最初の状態とかまさにこれで、コーパスの量が少ないと、まともに動きません*5。特に、これはコーパス性質によっても変わると思います(後述)。もう少し厳密に言うと、ほしい情報についてのコーパスの量が少ないと、まともに動かないのではないかと予想しています(後述)。

逆に、もっとデータ量が増えたら、もっと有意義かもしれません。今後に期待!

その他の実験:

window、sizeなどを変えてみたのですが、それほど大きな変更ないように感じました。ただし、sizeは少なすぎるとダメです。windowは多すぎるとダメです。このあたりを気をつけていただければ大丈夫かな、と。

気になる方は、モデルファイルを突っ込んであるので、試してみてください(ちゃんと評価をやろうと思ってたけど、あ、コーパスの時点でこりゃダメそうだなと思って諦めました)。言語によっても違いますので、このあたり、誰かがちゃんと定量的に見てくださると非常にありがたいです。

あとは、例えば体言を原形にするとか、単語を単語+品詞にするとか、コーパスづくりのところで工夫できるかな、と思います(やってないし多分やらない)

雑感

雑感としては、コーパスについてもっとちゃんと考えるべきだったなと思います。

という意見があったりして(というか私が不勉強でそういう意識を全く持てていなかった)、それを実感した構図です。

で、この場合だとどういうことかというと、「艦これのベクトル表現獲得」だったら「艦これスレコーパス」は妥当だし、「英辞郎データ」を使えば「日英翻訳」ができるだろう、と。じゃあ、「ツイートコーパス」だと何ができるの?という話です。

これに関して、明確な答えは出てないんですが、広く取ってきたツイートというのは「一般人の評判を反映してるかも」とか「新語の意味がわかるかも」とか、そういったあたりの情報が取り出せるかもな、ということです。そうはいっても、「広く浅く」なコーパスでできることってほぼないですね、word2vecの場合*6

また、コーパスに関してもう一つ感じるのが、ドメインを絞っている方が、より少ないコーパスで動きそうだ、と思います。あんちべさんの艦これのデータは6.5MBくらいしかないのですが、艦娘*7に関する素性はよく獲得できています(逆に一般名詞はひょっとしたら弱い、かも)。

これらを注意点としてまとめるなら、先にどういう情報を知りたいか決めてからコーパスを作ると、もっと有意になると思います。例えば評判を反映したいなら、トヨタなら「車」「中古」「道路」「タイヤ」をトラックワードにしてコーパスを作れば、そういう評判の素性獲得が、もっと少ないコーパスでできるかもしれません(本当に例えばですけど、商品を「満足度」の素性で比較できるかも、とか)。

(追記) [Mikolov+ 2013]でも指摘されていますが、単語のベクトル表現は自然言語処理のアプリケーション(応用)に非常に役に立つだろう、と言及されています(符号としての単語だったものが、素性の塊として扱えるので、夢広がります)。そういう用途でword2vecはそもそも使えると思いますが、そういう用途だとTwitterコーパスは少し不適切だと思います的エクスキューズを書いておきます。

参考文献

追記

データ量を182万ツイートまで増やして、ちょっと遊んでみました。

腐女子-女+男:プルート ホモ 貧乳 ヲタク 語感 腐男子 ブス 巨乳 根暗 清楚
北海道-雪+海:福岡 長野 沖縄 住ん 東京 札幌 名古屋 宮城 青森 仙台
リア充:サイテー 爆発 腐女子 ブサメン テメー 三角関係 ブス 君達 ぱみ 四散
カップル:続く 別れる 女 コーギー ♡」 長く line 男 ~♡」 未読
おっぱい:お尻 乳首 マイスター アナル 乳 揉む 揉み 貧乳 胸 巨乳
宇宙:異世界 異次元 未来 能楽 呪術 情報化 ロボット 形而下 機械 陽電子
イケメン:男前 美人 ブス 惚れる 色白 イケボ 変態 病弱 ブサメン ナルシスト
g-a+貧乳:巨乳 触手 非力 古参 低身長 もてる ?????! 上と下 三角形 獣
魚-海+空:卵 出汁 用水路 粥 味噌汁 肉 しるし 箸 皮 カッチカチ
ボカロ:アーティスト アニソン 洋楽 邦楽 レゲエ バンド カップリング 特撮 イラストレーター
おっぱい-女+男:お尻 乳首 アナル マイスター 貧乳 乳 揉む 巨乳 胸 揉み
妊娠-女+男:フリーズ 気絶 ズキズキ 解散 入院 幻滅 発症 悪化 接近 発狂
寒い-北海道+沖縄:暑い さむい 暖かい 眠たい 積もる はやい あったかい 寒かっ ねむい 忙しい

リア充はサイテーです。各位参考にしてください。

*1:補足:「手法だ」という風に書いてしまっていたのですが、論文では手法名として明記されておりません。また、オリジナル実装とgensimの実装がありますので、単一のツールを指す名詞として表現するのも、少し違和感があります

*2:これ、LSAでもできるみたいですね

*3:「は文分割に影響があったため外していました。しかし現在は、文を分割していないので、使用するべきでした

*4:ツイート文中には、「日本が金メダル」「イギリスが金メダル」「東京に遊びに来た」はあっても「イギリスのロンドン」とかそういう表現がないから、とか、そんな感じの予想です

*5:この原因、最初はコーパスのロードの仕方が間違ってたのかと思いましたが、おそらくコーパスの量の問題でした

*6:逆に、Wikipediaコーパスとした時に取れない情報があるはずなんです。その差分が、Twitterコーパスの強みかなと思います。アイディアを募集しています。

*7:かんむすめって読むんですかこれ?

教師なしLDAでTwitterのスパム判別をしてみる(予備実験編)

※普通は「教師なしLDA」という言い方はしないです

モチベーション

元々は、TwitterからURLつきのツイートを取りたかった。某ニュースアプリがTwitter上で(?)話題になっているニュース記事を(法的な是非があるとはいえ)配信しており、そんな感じのマイニングがしたかった。

ただ、普通に「http,https」でTwitter上で検索すると、量が膨大だった。加えて、ほとんどがスパム。なーにが「このサイトすごすぎwwwww」じゃ。

f:id:yamitzky:20140216225341p:plain

ということで、検索の段階でスパミーなキーワードを取り除き、純度の高いURL投稿マイニングをしたいわけだが、キーワードは既知なものには限らない。例えば「無料」とか「アフィリエイト」とかがスパムなのはそうなんだけど、「パズドラ」とか「魔法石」とか、未知のキーワードとか出てきた時に対応できない。

そこで、教師なし学習のアプローチを使って、スパムなキーワードを抽出する、ということを目的として、実験を行った。

モデル

モデルは、latent Dirichlet allocation(以下、LDA)[1]を使った。LDA自体の説明は、星の数ほどあるので、ここではほぼ行わない。

LDAでは、「文書には潜在的なトピックがある。潜在的なトピックは、単語を生成する」というような生成過程を踏む。逆に言うと、「ある文書に、ある単語が出やすいのは、そこに潜在的なトピックがあるからだ」とも言える。

具体的な例を出すと、「無料レポート:インフォゼロのアフィリエイトで月収40万円と月9万円の不労所得を構築した方法」というツイートは、その背後に「スパム」というトピックが存在するからだ、とする。逆に言うと、「スパム」というトピックを持つ文書は、「アフィリエイト」みたいな単語を生成しやすいはず。

ちなみに、LDAを使って得られるものは、簡潔に2つある。「文書ごとのトピック分布」と「トピックごとの単語分布」だ。

「とりあえずLDA」を使って学習してみて、スパムなトピックが学習できるか、そして、そのトピックから特徴的な単語を炙り出せるか、を確かめる。今回は予備実験として、トピックの出方を確認してみて、スパムなトピックが決定づけられそうかを見てみる。

前処理

各ツイートを、MeCabを使ったりして次のように単語分割した。

無料レポート:インフォゼロのアフィリエイトで月収40万円と月9万円の不労所得を構築した方法 http://t.co/****** #followmejp #goen

が元のツイートだとした場合、

無料 レポート : インフォゼロ の アフィリエイト で 月収 4 0 万 円 と 月 9 万 円 の 不労所得 を 構築 し た 方法 example.com #followmejp #goen

つまり、「通常の単語」+「URLを展開してドメイン部を取り出したもの」+「ハッシュタグ」を、文書=単語列とした(語順は関係ないのだが、先にURLとハッシュタグを除いてから形態素解析しているので、形態素解析が失敗している可能性あり)。

実験設定

プログラムは、自分で実装したLDA使ってもよかったんだけど、多分遅いので、GibbsLDA++を使った。実験設定は以下。

  • 文書数:50,919ぐらい
  • トピック数:100
  • 学習回数:20,000
  • α:50 / トピック数
  • β:0.1

注意点として、

  • トピック数は少なすぎるとうまくいかない
  • 学習回数は多すぎるかも(多すぎて困ることはない。perplexityの確認はしていない)
  • α、βはデフォルトのパラメータ

LDAとツイート収集以外のソースは、全てgithub上に置いた

実験結果

結果はgithub上に置いた。これは、トピックごとの単語分布\phiのうち、頻出上位30件を書いたもの。

多分、そもそもスパムが多すぎて、トピックがスパムばっかなんだけど、特徴的なものもいくつか。

例えば、30番目のトピックは、

で を 自動 ツイッター bit.ly フォロワー 方法 収入 万

ということで、スパムっぽいトピック。45番目とか51番目とかのトピックは、

に bit.ly 裏 と 無限 ワザ 4 手 アイテム 最強

~ bit.ly の を で た 報酬 ん アフィリエイト

と、bit.lyみたいな短縮URLは、スパムっぽい傾向があることがつかめる。

逆に、42番目のトピックを見ると、

bit.ly → 無料 プレ #ニュース ソチ 五輪 ( #スポーツ 「

と、ソチの話題にも関わらず、bit.lyとか、「無料」とか、キーワードの誤爆が出てきそう。

また、

まし fb.me 写真 し 投稿 新しい Facebook

(@ 4sq.com ) 店 pic ]: [ ))

 r.gnavi.co.jp   の … goo.gl  店 。 な : 味 ランチ

とか、ドメイン名とトピックが結構関係するというのも、狙い通り。

あと、意外だったのが、stopwordsがスパムトピックの上位に残ってしまっている。本来なら、stopwordのトピックが作られてほしかった。ここらへんは、ツイートという性質の問題かもしれない。

【追記】実験その2

コメント欄でid:Kesinにぐぅ正論なアドバイスをいただいたので、再実験した。

前処理として、語彙を「名詞(おそらく記号含む)」「動詞(原形)」とハッシュタグ、URLのみに制限した。すなわち、

無料レポート:インフォゼロのアフィリエイトで月収40万円と月9万円の不労所得を構築した方法 http://t.co/****** #followmejp #goen

が元のツイートだとした場合、

無料 レポート : インフォゼロ アフィリエイト 月収 4 0 万 円 月 9 万 円 不労所得 構築 する 方法 example.com #followmejp #goen

となる。

【追記】実験結果その2

結果はgithub上に置いた

登録 ポイント 獲得 中 小遣い ギフト 券 キャンペーン

] [ 楽天 a.r10.to #RakutenIchiba ゚ 送料 #ダイエット

♡ bit.ly 女性 完全 , 4 限定 友達 ここ 今

する フォロー 方法 ツイッター bit.ly アカウント 自動 つぶやき

ここらへんなど、スパムっぽいトピックは同様に出現している。特に顕著なのが、定性的な解釈がしやすくなったことだ。マイニングで定性的に確認したいという場合は特に、ちゃんとstopwordsが取り除かれるようにしたほうがいいかもしれない。

ただ、単語分布を素性として扱うと考えると、どっちがいいのかは今のところわからないので、後々の検証の余地がある。

結論

以上から、スパムなトピックは学習できてるっぽい(ここはそんなにかっちりした結論はいらない)。

Future work

今後やろうと考えているのは、

  • ツイートのスパム分類(寄り道)
  • スパムキーワードの学習(本丸)

あとは、biterm topic model[2]みたいな、短文向けのトピックモデルも提案されているので(※読んだことない)、こちらを使ってみるのも面白いかもしれない(けど、あまり興味ないので、誰か!)

モチベーション2

ビジネス的要件で、何かを判別しましょう、機械学習しましょう、とすると、結構教師あり学習でーSVMでーみたいな流れになるような気がする。もしくはRandom Forestでー、みたいな。

この理由は、使いやすくて、使われてきたから、だと思う(違ったらごめんなさい)。

でも、LDAみたいな教師なし学習・生成モデルも結構簡単に実験できる。ので、カジュアルに使ってみても面白いんじゃないかなーと思ったり。

参考文献

  • [1] Blei, David M., Andrew Y. Ng, and Michael I. Jordan. "Latent dirichlet allocation." the Journal of machine Learning research 3 (2003): 993-1022.(PDF)
  • [2] Yan, Xiaohui, et al. "A biterm topic model for short texts." Proceedings of the 22nd international conference on World Wide Web. International World Wide Web Conferences Steering Committee, 2013.(PDF)

OpenBLASを使うと、multiprocessingが使えない?

numpy/scipyは、別に全ての演算がpythonで実装されているわけではなくて、内部的にはBLASとかを呼び出している(多分)。で、普通だったらATLASのようなBLAS実装が使われると思うんだけど、それだと遅いからOpenBLASみたいなBLAS実装を使いたかったりする。(参考:Atsushi TATSUMA Web Page » OpenBLAS を使った Numpy/Scipy のビルド)

で、確かにOpenBLASによって一部の行列演算が早くなる。なぜかというとマルチコアの力を使ってくれるから。

しかし困ったことに

import scipy.sparse.linalg

しただけで、multiprocessingを使った並列処理ができなくなってしまった。コア数とかは

import multiprocessing
multiprocessing.cpu_count() # 16

みたいな感じでマルチコア風なんだけど、実際に動かしてみると、1つのCPUの中で並列処理することになる。調べてみると、OpenBLASはmultiprocessingを使えなくしてしまう、みたいな記述がいくつか見つかる。

openblas uses openmp for parallization. that does not work well when you are forking like python multiprocessing does.

I don't think it can be solved besides disabling parallelization in either openblas or python.

Bug #1186274 “openblas, multiprocessing and numpy freeze python...” : Bugs : “openblas” package : Ubuntu

とか

Using OpenBLAS can give speedups in some scikit-learn modules, but it doesn’t play nicely with joblib/multiprocessing, so using it is not recommended unless you know what you’re doing.

Installing scikit-learn — scikit-learn 0.14 documentation

ということで、一長一短・・・かなあ。ひえええ

2014年のJavascriptやCSS、最も楽しみな5つのテクノロジーは、asm.jsと、、、

Web platform: five technologies to look forward to in 2014

上記の記事にて、「ウェブプラットフォームで待ち遠しい5つのテクノロジー」が紹介されています。

  1. asm.js: near-native performance on the web
  2. ParallelJS: parallelized JavaScript code
  3. ECMAScript 6 (ES6): evolving the language, uniting the community
  4. Web Components: a standard infrastructure for widgets
  5. CSS Grid Layout: native-like GUI layout

と、5つのテクノロジーが挙げられています。「asm.js」「ECMAScript 6」「Web Components」あたりは聞いたことがあったのですが、「ParallelJS」「CSS Grid Layout」っていうのは初耳でした。

詳しい紹介は上記記事にて(英語で)載っていますので、簡単に紹介します。

1. asm.js

asm.js が公式サイトで、Mozillaの支援で開発されています。目的としては「高速なJavascript」といった感じです。ゲームであったり、いわゆるソフトウェア的なものであったりを、「Javascriptで書かれているけれども高速に動く」ようなものを作れます(作りたいです)。

よく、コンパイル型の言語(Cだったり)は高速だと言われます。例えば、その一つの理由として、コンパイル時に型が解決されることがあげられます(静的型付け)。一方でJavascriptはコンパイル型でなく、型の指定もしません。しかし変数を作った時点で型というのはだいたい決まっています。そこで、Javascriptの言語仕様に制約を与えて、型指定ができるようにしましょう、他にもいろいろ最適化できるようにしましょう、というのがasm.jsの基本的な考え方だと思います。

var bmi = weight / (height * height); // 普通にJavascript
var bmi = weight / (height * height) | 0; // int bmi;
var bmi = +(weight / (height * height)); // double bmi;

後2行は、型変換時によくあるイディオムで、旧来のJavascriptの仕様です。このような旧来の仕様を使って、asm.jsの仕様は作られています。そのため「Javascriptのsubset」であると言われます。

ただ、asm.jsは人間が書くものという感じはあまりしません。x|0 じゃなくて int x と書きたいものです。そのため、別の言語で作って(例えばC)、Emscriptenなどで"コンパイル"などして使います。使いどころは難しいですが、ゲームやOSから実行するソフトウェアなどが、それに該当するのかなあという感じです。Webアプリの場合はDOM操作やネットワークが重さの原因なので、Webアプリのための銀の弾丸ではありません。ゲームデモとか見るとすごいです。

2. ParallelJS

ParallelJS: data parallelism for JavaScript

こちらの記事ですが、次のようなブコメがついています。

ECMAScriptへの並行・並列機能の導入について。配列操作の並列実行についての条件の簡単な解説有り。データの並列化およびタスクの並列化。

b:id:saneyuki_s:20131224

記事を読むと、ECMAScript 7、ECMAScript 8へ追加したい言語仕様として捉えられているようです。そのための低レベルAPIとして、SIMDAPIとかがECMAScriptの仕様としてあるようです

こちらもasm.jsと似ていて「Javascriptの高速化」で、でもこれが有効なのはゲームとかOS寄りかなあという印象です。間違ってたらごめんなさい!

3. ECMAScript 6

ECMAScriptとは、Javascriptの元となっているような言語仕様です。逆に、JavascriptECMAScriptの「方言」と言われるようです(ECMAScript - Wikipedia)。ECMAScript 6は現在策定中の仕様ですが、まだ全然使えないというわけではなく、一部は実装されています(Mozilla における ECMAScript 6 のサポート - JavaScript | MDN)。

なぜこれが大事なのかというと、Javascriptが「言語として進歩する」からです。ちょっとだけ似たような話ですが、JavaなどもJava 8として言語仕様が進歩しましたね。

まだES 6は策定中で、ブラウザーに実装されているとは言いがたいですが、Google製のTraceurなどを使えば、ES6準拠で書いて、それを既存のブラウザ上で動かすことができます(年の瀬なのでGoogle作ったソフトのリポジトリ(github.com/google)まとめてみた! - 病みつきエンジニアブログ)。

4. Web Components

あなたの知らない超絶便利なWeb開発を叶える仕様Web Componentsとは~Google I/O 2013まとめレポート (1/3) - @IT

Web Component概要

こちらはあまり知らないので記事紹介です! 簡単な概念としては、要素を「ウィジェット化」して、セマンティックにしましょう、みたいな感じです。

例えばカレンダーを作った時、旧来の方法だと、それっぽいtableを作って、それっぽいJSコードを書いたりします。しかし本当にやりたいのは「カレンダー」をhtml中にコーディングすることです。そこで、「カレンダーを表す要素」を定義してしまって、埋め込みましょう、というような。

Web Components普及の夜明け!?Polymer.jsを試してみた。 | OpenWebにて、コードが紹介されています。

5. CSS Grid Layout

あまりにも知らないのでWeb platform: five technologies to look forward to in 2014を参考にしていただきたいのですが、グリッドレイアウトがCSSの仕様として策定されていて、「IEはサポート済み、Chrome/Firefoxは2014にはサポート」といった感じらしいです。

「なぜこれがExcitingなのか」の理由として、「CSS Grid Layout will eliminate that gap.」と書かれています。ここでいうgapは「Web(HTML/CSS)とネイティブ(iOSAndroid)の差」のことです。確かにAndroidのレイアウトは、Grid Layoutっぽい配置で書くし、レスポンシブになってとても良いんですよね。この考え方がCSSで一般的になるのは、確かに楽しみだなーと感じました。

Web platform: five technologies to look forward to in 2014に、サポート状況や使い方へのリンクがあるので、ぜひご覧ください!