#cto_sushiでChangeLogやIssueを追う技術、reftest、GitHubスパムなどについて話してきた。(この中に現在CTOはいなかった気がします)

ログ: #cto_sushi - Togetterまとめ

久々に :sushi: を食べるSushiイベントだった気がします。

クリップボード API - kyo_ago

  • クリップボードAPIを使ってキレイにコピーさせるには
  • コピーする瞬間にDOMを入れ替えて、コピー後に戻す
  • 普通にやると表示がガタつく
  • requestAnimationFrameを使って入れ替えると綺麗にできる
  • Clipboard API+DOMの入れ替え、DOM Range+requestAnimationFrameについて

クライアントサイドのパフォーマンスメトリクス - Jxck

詳細: graphite, grafana, sitespeed.io, diamond で継続 Web パフォーマンスモニタリング - Qiita

  • Sitespeed.ioがすごい
  • 本物のブラウザを仮想環境で動かしてTiming APIなどを元にしたメトリクスを取れる
  • リアルなリクエスト/レスポンス/レンダリングの情報が得られる
  • サーバのレスポンスなどはある程度枯れた計測方法があるけど、クライアントからのデータはまだまだ発見の余地がある
  • 時系列データベースのGraphiteにデータを保存
  • Grafana
  • Dockerも用意されててセットアップが簡単
  • 継続的にクライアントとサーバのメトリクスをとっておくことと
    • Grafanaに両方を同時に表示して、どういうことが起こっているのかをクライアントとサーバ両面から見ることがｄけいる。

契約プログラミング - Jxck

詳細: ES7.decorator で契約プログラミング(design by contract) - Qiita

  • ECMAScriptに提案されてるDecoratorを使って契約プログラミング
  • D言語では言語機能として契約プログラミングができる
  • JavaScriptでも@contractというDecoratorを実装して事前条件、事後条件、不変条件のチェックをできないか
  • @contract(Rule)のようにDecorator関数には引数を渡すことができる
  • これを使ってルールを定義して使う

Issueを読む技術 : ChangeLogの追い方 - azu

スライド: われわれは、いかにして変更点を追うか

われわれは、いかにして変更点を追うかという発表をしました。

最近ずっと考えているIssueを読む技術 · Issue #66 · efcl/efcl.github.ioの一部を取り出したもので、どうやってChangeLogからより深く、正しい情報を得ていくかについての内容となってます。

自分はJSer.infoという情報のサイトもやってるのもあってChangeLogを正しく追う必要がありよくChangeLogを見ています。 その中でのChangeLogからIssue/Pull Reuqest、コミットと深掘りしていく方法や、追いやすいChangeLogについて書いた内容になっています。

  • ChangeLogの追い方
  • ChangeLogの書き方

の2編からなっていて、一番言いたかったのは追いやすいChangeLogがわかると、読みやすいChangeLogを書くことができるのではないかという話でした。 ChangeLogもそれ単体ではなくIssue、Pull Request、コミットとそれぞれが上手く繋がるような仕組みになっているとより機能すると思います。

io.jsとES6 - 会長

  • V8はまだES6に最適化されてない
  • io.jsのコードはかなりハック的な書き方がされてる
    • パフォーマンスのため
  • 単純にclassやlet、constなど使ってもパフォーマンスが得られない場合がある

isomorphic

DDD

test

  • 扱うブラウザの中でPhantomJSがもっとレガシーなブラウザになってるのでは
  • Xvfbがなくていいのはメリットだけど、Sitespeed.ioみたいに今は実ブラウザを動かしたほうがいいのでは

TypeScript

おわり