読者です 読者をやめる 読者になる 読者になる

hiromitsuuuuu.log();

to see more to see.

2015/2/21 Frontrend Conference 参加メモ

Dev 勉強会レポ

Frontrend Conferenceに参加してきたのでメモ。JS,CSSの2トラックだったから選びやすかった。基調講演 > JS > JS > JS(LT) > CSS > JS > クロージング の順で聞いてきた。講演者もだけど聞きにきてるほうもフロントエンドオールスター感あった...楽しかった!

Frontrend Conference - A conference for front-end developer(2015年2月21日開催)

Pragmatic Front-end Developer: From Artisan to Expert

スライド:http://d.pr/f/11iuK

遅れていったので後半だけ(´・ω・`)最近どこのクラスタもプロトタイピングとコミュニケーションの重要性を説いている気がするなぁと思った。

CSSの品質,スタイルガイド
  • CSSLINTは純粋なコードスタイルチェッカーではないがスタイルチェックの目的でも使える
  • 自動チェックが行えるかどうかが重要。貴重なコーディング、コードレビューの時間をコードスタイルのチェックに費やさない為に自動化する
  • Website Style Guide Resources
  • airbnb/javascript · GitHub
  • プロトタイプの開発を加速させるのも役割
  • ブラウザ上の動く成果物を元に議論をする
  • 人は実際に見えるもの、動く物に対しての意見は言いやすい
  • いかに早く議論の元となるプロトタイプを作れるかがキモ
変化に対して寛容に
  • エスカレーターはプログレッシブエンハンスメントの良い例。普段は自動的に動いているが、故障して止まった場合も最低限階段としてフォールバックされ機能する。エレベーターは壊れてしまえばただの箱。
  • Webは常に変化し続ける環境である。プラットフォームではなく連続(Continuum)。
  • プロダクトに責任を持つ
  • ある一つだけの技術だけで解決できる物ではない
  • ツールは開発者の利便性にフォーカスが当たっている
  • 継続し続けることに気を配る
  • Webの利用者の多くは単純にWebを消費したいだけ
パフォーマンス
フロントエンジニアの意識
  • できないと言わない。オプションを提示する
  • 様々な専門性をミックスできるのが強い
  • 専門性をチームで発揮できる = 自分以外の分野についても知っている
  • 壊れ窓の中で仕事をしない
  • 十分がいつなのかを知る
  • 知識を増やす為の時間を定常的に設ける

[JS] Reactive Programming in JavaScript

最近よく聞くリアクティブプログラミングについて。そもそも何か?という概念中心。ちょっとハードル高かった(/ω\)まうすむーぶしたらデータがうわーって流れてくるよー的な←

[JS] Introduction to React

こちらも最近よく耳にするReactについて。Reactに入門するにはとてもわかりやすかった!

  • facebookが作ったViewに特化したライブラリ(notフレームワーク
  • ステートレス(状態を持たせない)なコンポーネント設計がキモ。その手段としてVirtualDOM、JSXというシンタックスがある
  • Reactの良さは規模が大きくなった時に管理できる仕組みである点
  • Backboneみたく自分でハンドリングできるのはいいけど、規模が大きくなると辛くなってくる→Angular, Vueへの2way bindingの流れ
  • BackboneやAngularが駄目な訳じゃない。規模によって適切な技術選択を。
  • 小さなアプリケーションを素早く作る為のツールではない。APIを受け取ってリストをレンダリングするならAngularでやった方が数行で素早く作れる
  • 面倒さ(制約がある)はあるがメンテナンス性/再利用性が得られる
React
  • コンポーネントは自分自身が持っているデータを更新しない(状態変化しない)
  • ルートだけ状態を持つ。子は自身の変更を親に伝え、親がデータを更新する(サーバサイドと同じ考え方→変更を受け、DBの情報を更新して再度HTMLを構築する仕組み)
  • 子のデータは親から貰う(JSXのprops)。子は親から貰ったデータでViewを再描画する。
  • 都度全子コンポーネントを更描画していたら速度が出ないので、差分を計算して必要な部分だけ更新する。ViualDOMの概念。
  • 局所的に見れば面倒だが、大規模になれば有用
  • 制限を課すことでテスト可能、メンテナンス可能、再利用可能に
  • 簡単な設計の割には速度が出る
  • JSXはテンプレートに分けられない。JSの中にバーチャルDOMが入ってるのでデザイナーと連携する時に辛そうと言われる※デザイナーのスキルによる
  • 一人React.js Advent Calendar 2014 - Qiitaがおすすめ
Flow
  • 静的な型チェッカー(facebookが作ってるReactファミリーのひとつ)
  • 明示的に型指定しなくてもいい感じに推論してくれる、すごく高機能なLintみたいなもの
  • JSXがサポートされている
  • 型指定が入っているとJSとしては実行できないのでコンパイルが必要
  • strip-typesしたときに変な空白が生まれるのがちょっと微妙 -> babelはその辺りきちんと詰めてくれるのでおすすめ
サーバーサイドレンダリングについて

LT

ドラ娘ではなくドラガジェットが動作してて和んだ。

[CSS] Inline layout

テキストと画像の位置関係について。画像下の余白問題、過去ハマって時間かかったから知っておきたかった(´;ω;`)わかりやすかった!

  • 画像下の余白問題
    • 1emはフォントサイズの高さのこと。leadingは含まない。
    • 文字はベースラインで揃うようになっている。
    • baselineが画像の下端。デフォルト値。
    • centralは行の高さの半分に揃えられる
    • display:blockにしたほうが良い
  • イコン画像の縦位置調整
    • vertical-align: middleが一番いい
    • 日本語の文字は密度が上に詰っているので(ベースラインが違う)ので、アイコンが下寄りに見えてしまう。微調整するのがいい。
    • 余白も含めて、アイコンのサイズを決めちゃうと楽
  • アイコンを飛び出させる
    • text-indentで位置をずらす
    • イコン画像がデカくて行の高さを拡大しちゃう時は、アイコン画像に上下のネガティブマージンを設定して、CSS上の高さを縮める。

[JS] JavaScriptテストの疑問、お答えします。

テストの話だけど、何でも目的がだいじ、手段ドリブンじゃだめ。ってことにフォーカスされていた印象。

JavaScriptテストの疑問、お答えします #frontrendJS

  • まずは個人でやってみて費用対効果を予測する
  • テスト技術はテストをしないと身に付かない(個人のスキルに依存する)
  • UIのテストはどこを検証すべきか不安なところをテストするという目的を設定する
  • E2Eテストはコードの品質に依存しない。けどコストは下がらない。
  • テストを書く目的が大事。誰の不安感を解消する為のテストなのか?
  • JS Deferredのドキュメントはよかったので参考に
  • 投資をすることでどんな効果が得られるのかがはっきりしていないと形骸化しやすい
  • 個人的にはassertから入れるのがおすすめ
  • E2EテストはProtractorが強い(https://github.com/yahoo/preceptor
  • testemはコードカバレッジが取りにくい
  • Phantomは再現性が微妙(phantomjsというレガシーブラウザ対応問題)
  • テストを書く技術を伝えることは難しくない。しかし、どこが不安かを認識する技術を伝えることは非常に難しい
  • 技術的な問題より文化的な問題のほうが大きい

Styling Atom (Editor)

Atomのスタイリングがどういう構成になっているか、知るセッション。プレゼンまでAtomで構成されててすごかった。
一番衝撃的だったのが未来の話で、光度メディアクエリを使って環境光の変化によりテーマを変える構想をしてるってこと。暗めのテーマで作業してる際に、ブラインドが開いて画面の反射でモヤモヤしないように!