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

以下斜め読んだ内容

pseudo translation of useful posts, book reviews, remarks,etc. twitter: feeddict

Nick Pettit「Paul Irish一問一答」

斜め読み

Treehouse Blog 2012.10.24のエントリ

Treehouse Friends: Paul Irish - Treehouse Blog

  • 聞き手が教育系スタートアップの人
  • html5 boilerplate始めたきっかけの話とか
    • 条件付きコメントを使ってる理由とか
  • yeomanの話とか
  • なんだかフロントエンド開発の敷居が上がり続けてる件とか
  • web業界以前の話(wordの差込印刷作った奴偉い、とか)
  • アドバイスとか

通り一遍を訊いててinformative

以下斜め読んだ内容

以下一問一答

  • Q:自己紹介、やってること
  • A:
    • chromeチームのdeveloper adovocateというポジションが仕事
    • developer adovocateとして色々やる
    • 一言でいうと、人の心を掴むコンテンツ作りの現場を改善してくれるもの全般
    • chromeの機能は豊富
    • 便利機能などを学ぶのを手伝う。
    • 例えばdeveloper toolを使いこなそうとしてる人を助ける
    • chromeチームでの仕事のまえからオープンソースの世界で色々プロジェクト続けてる
    • フロントエンド開発の改善、ウェブサイト/ウェブアプリの改善のために開発者が知っておくべきこと
    • こうした知識・ノウハウの習得支援するプロジェクト
  • Q:色々なプロジェクトを進めてる動機
    • 自分(=nick)も常用してるModernizr, HTML5 Boilerplate
    • jqueryチームのメンバーも継続
    • フロントエンド開発ツールの開発もやってる
  • A:
    • 一つは人助けから得られる満足感から
    • あとは自分の記憶力の悪さを補うものが欲しかったから
      • 書き出しておかないと忘れる
      • meqia queriesやviewportの使い方を調べるとする。得た知識やノウハウをいつでも使える状態にしておきたい
    • html5 boilerplateはそうやってできた
      • ネットや本で調べた知識・ノウハウをストックしてる
      • 自分が必要としたもので、自分がとても助かってる
      • 転じて、自分以外の人にも役立ってる
    • webはみんなが凄いものを作れる場所であって欲しい
    • こういう気持ちが自分がやってることの動機にもなってる
    • webがもっと強力なプラットフォームになっていくプロセスに自分が貢献できることに満足感を得てる
  • Q:必要としてるノウハウ・知識は色々なタイプがあるから、プロジェクトも色々な形をとってる?
  • A:そうできるからそうやってる
  • Q:色々なプロジェクトに割くリソースの配分。バランス
  • A:
    • 時間管理は得意じゃない
    • workflowly使ってる
      • WorkFlowy - Organize your brain.
      • いいツール
      • リストのネストができる強力なto doリストアプリ
      • 4半期に分けて、プライオリティ設定して、ひたすら試行錯誤
    • 少し長めの期間を視野にいれとくのは大事
    • 日単位だと、別のことに気が向いたり、新しいことを試したくなったり、とやってしまうのはありがち
    • ある程度経って振り返ったら、諸々の脱線が本当にやっとかないといけないことにデカいダメージ与えてる、ってもありがち
    • 自分は時間管理がとても下手くそだが頑張ってる
  • Q:生まれとか経歴とか
  • A:
    • Massachusetts西部、Connecticut出身。要はNew England出身
    • 音楽やってた。マーチングバンドでチューバ吹いてた。高校では演劇とバンド
    • ネットで最初に作ったのは音楽ブログ。2004年くらい。
    • 音楽ブログでは古参で、最初の50番目以内に入っててそこそこPVあった
    • ブログのデザインを変えたり色々試したりしてた
    • フィードバックもたくさんもらえる状況にあった
    • フロントエンド開発はとても楽しい、と思った最初の時
  • Q:いつ頃からwebやテクノロジーに関心を持ちだした?
  • A:
    • フルタイムで働き出した頃
    • 遊びでウェブサイト作ってた頃、ie4が出た
    • msはクールなマーケティングやってて、DHTMLが出てきた頃
    • msは全米の映画館を貸切にして開発者を招待し、ポップコーン、Tシャツ、win95のOSディスクを無料で配ってた
    • msは映画館でie4でできることを披露し、それがとてもすごかった
    • ものすごい数の機能が登場してて、「凄いクールだ」と感動してた
    • 実はその自分の熱は一旦冷めて、大学進学したが、進学した後にその熱はぶり返した
  • Q:webとテクノロジーの勉強のために進学した?
  • A:
    • 学位はtechnical communicationsで取った
    • web開発全般を学べる大学があれば、と当時思ってた
    • フロントエンド開発は大変でキツイ
    • フロントエンド開発のために洗練された教育プログラムがあったらな、と思ってた
    • 実際には自分が受けた教育は、コンピュータサイエンス、数学、経営、コミュニケーションだった
  • Q:
    • technical communicationsという学位は自分のキャリアに役立ってる
    • 自分(=nick)は教育系会社の人なので訊きたい所
  • A:
    • ある。現状、CSの学位のご利益はデカい
    • 5年前の時点でコンピュータサイエンスがweb開発に役立ってるとは言えなかった
    • 現在は違う。クライアントサイドでは、ロジックに溢れてる
    • jqueryで書き、物事がよくなってく。。tranlateをしてる、より大きなアプリのコードを書いてる
  • Q:相当複雑なものになりつつある
  • A:
    • 文房具会社でマーケティング的なことをやってた
    • 文房具会社は結婚式招待状や出産報告とかを作ってた
    • つまりweb成分ゼロ
    • 自分はwordで差し込み印刷用のファイル作りファックスを一斉送信に使った
    • 差込印刷を送信する顧客むけにカスタマイズすることもやってた
    • こうしたカスタマイズを可能にするロジックがwordにはあった。word偉い
    • その後配置換えになってEC部門へ。よい機会になった
    • 自力で開発できるものを持ってたほうがいいと思う
    • 自分の場合は音楽ブログ
    • 更に、ブログじゃなくてもいいけどweb上に自分の場所を持ってたほうがいい
    • ブログ書くのはいいこと。学んでることをブログに書くのはとてもスマートなこと
    • 色々繰り返したり試したり遊んだりできる場所を持ってるのはいいこと
    • 例えばcss3の新機能が登場したとき
      • デモ作る、色々調べる、codepenにポストする
      • デモ・調べもの・ポスト等々を奨励し、フィードバックをくれるコミュニティがたくさんあり
      • コミュニティに参加して、調べ物したり、話ししたり、プロフェッショナルな開発を探求したりできる
      • 自分はそうやってきた、物事すすめるスマートなやり方だった
  • Q:ちなみに最初のブログはworpress?
  • A:yes
  • Q:
    • 当時ブログ作って書くくらいにまでフロントエンド開発のどこに魅力を感じたのか。
    • ruby開発でも、php開発とかでもなくフロントエンドなわけ
  • A:
    • インターフェース開発であるから
    • インタラクションの仕方を決めることができる
    • ユーザやお客からフィードバックをもらうことができる
    • ユーザやお客の心に届くものを作ってる
    • ユーザやお客がマウスカーソルを走らせる場所を作ってる
    • インタラクションのあり方、UXのクオリティをコントロールする立場にある
    • レスポンスを高速化させる仕事、堅牢なインフラを作る仕事も開発にはある
    • だが、UIに自分はとても魅力を感じてる
  • Q:すぐに達成感を得られるってこと?
  • A:
    • 素早い達成感、自分が作ったものへのフィードバックサイクル
    • ユーザを喜ばせるものを作れる
    • 使った技術がまずければ反感も買うことだってある
  • Q:
    • 次はhtml5boilerplate
    • デザイン・開発初心者にとっても役立ち、内容充実してる
    • プロジェクトが始まったきっかけ
  • A:
    • 前職の頃。Bostonのweb制作・開発の会社
    • プロジェクトをこなすなかで、自分のコードを何度もコピペしてることに気付いた
    • テンプレ化したほうが過去のプロジェクトのコードを漁る手間がスキップできる、と判断
    • 次々プロジェクトこなすときに必要だったものが出発点
    • しばらくしたらDivya Manianもプロジェクトに参加してくれた
    • v1.0をリリースでは、他の人も役立つを思ってくれるテクニックを盛り込んだ
    • 最近まで、インラインでドキュメントつけてた
      • インラインのドキュメントにそのテクニックの由来するサイトの情報載せた
      • そのテクニックが大事なものかどうか見る側が判断しやすくなってる
      • 教育ツールとしてhtml5 boilerplateは機能してる
      • (補足)インラインコメントはv4.0リリース時に削除
      • テクニックがhtml5 boilerplateに掲載されてるのかもわかる仕組みになってる
    • githubにソースをホストしてる
    • 公開後github経由でたくさんフィードバックもらった
      • ここはこう調整するともっと良くなり、opera9.6のバグのよい説明にもなる、とか
    • html5 boilerplatesのトピックごとに色々ディスカッションが生まれてる
    • ディスカッションの成果が盛り込まれてる
    • ディスカッションには、優れたフロントエンドエンジニアも参加してる
    • 更新履歴、議論、過去の問題等々を辿れる
    • コミットログは詳しく書いてる。変更の根拠がわかる

html5 boilerplates
>|||

|

  • Q:
    • html5 boilerplatesをDLしてファイル開いても「何これ?」となる初心者向けに
    • ファイル見た人が最初に目にするIEのconditonal commentsから
  • A:
    • conditional comment。洗練さとかセクシーさとかの対極
      • 使いたくない。マークアップはミニマルにしたい
      • そんな衝動は自分も持ってる
      • cssハックで済まそう、とか
    • ie対策はまだ必要
      • ie6-7は無視出来るくらいシェア落とした
      • ie8はまだシェアもってる
    • css実装にバグがあって対処しないといけないケースは、開発現場で目にする
    • cssハックはドキュメントされない
    • cssハックでブラウザのcss実装のバグに対応するのは、後々面倒に
      • 自分の書いたマークアップcssをチームメンバーにちゃんと理解してもらう場面
      • チーム間のコミュニケーションの効率を落とす
    • conditional commentsはある意味ファーストクラスの手法
      • ベンダが提供してる
      • ie7だけ、ie8だけ,等々。ieだけに適用されるスタイルを書くために提供されてる
    • vender specificなスタイルを書くのを出来るだけ避けたいとみんなcss書いてる
      • 明示的に高さと幅を指定してるときは、vender specificスタイルを回避するのが動機にある
      • vender specificなスタイルを書かざる得ない場面は出てくる
        • そんなときにconditional commentsは役立つ
  • Q:一番お気に入りの思う機能
  • A:
    • protocol relativeなurl記法。プロトコル部分を抜いたURLの書き方
    • "//ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js"
    • ajaxian,stackoverflowにも載ってた
    • httpsでもhttpでもどっちでも読込できる
    • この機能知らない人から「typo:httpが抜けてる」とpull requestもらったことあり
    • ページがhttpのときにhttpsのリソース読むと、オーバーヘッドが少しある。
    • ローカルでサーバ立てずにフロントエンド開発してるとプロトコル部分を「file://」と解釈されてしまうのが注意点
      • ローカルでサーバー立てて開発すれば解決
  • Q:ここ数年でフロントエンド開発で起きてること。仕事が複雑になってきた。いい傾向 or not?
  • A:
    • 2つのことがここ数年で起こってる
    • 1つは、レガシーなブラウザが視界から消えた
      • ie6死亡、ie7はシェア1%
      • ie8はシェア持ってるが、ブラウザの性能アップした
      • レガシーなブラウザへの対策がフロントエンド開発で悩みの種だった
    • もう1つは、沢山の新機能が登場した
      • 過去3年で沢山の機能がブラウザに追加されてる
      • 追加された新機能をどう使うか、組み込んでいくかに、頭を使ってる状態
      • 例えばcss transition
        • css transionを実務で使う時、非対応ブラウザ向けにfallbackも実装する
        • 自分はfallbackしたほうが良い派
        • フォールバックとして何を提供するかを決めるのは、少し大変
        • 例えばcss transionを使ったサイト作ったとして
          • modernizrで非対応ブラウザ検出して、非対応ブラウザ向けにjqueryでアニメーション実装、とか
          • 常にやるべきことじゃない
        • だからhtml5 pleaseというサイト作った
  • Q:フォールバックシナリオの安全牌ある?
  • A:
    • polyfillを旧いブラウザに送りつけるのは好きじゃないが
    • 常にこうしたほうがいい、というのはない。いつも複雑で込み入ってる
    • かつては、「あらゆるブラウザで見た目を揃える」、「機能が足りないブラウザにはテキストだけ表示」とかあった
    • いろんなデバイスがあってサイトの見え方も複数ある状況も生まれて、状況をさらに複雑にしてる
    • 一つは気にしないこと
      • 「border radiuscss transionサポートしてない?」「大丈夫。ささいな機能強化だ」
    • 使いたい機能を使えるブラウザにユーザが乗り換えるように働きかけていく
      • 乗り換えてくれれば、フロントエンド開発の苦しみは減る
      • 高い乗り換え率を弾きだした場面も過去にあった。ブラウザの高速化は乗り換えを大幅に促進した
  • Q:
    • フロントエンド開発の敷居がぐっと上がってる
    • 今は、フロントエンド開発が沢山のステップを経るようになってる
    • いくつものツールをつなぎあわせて開発するのは面食らうね、ブログに書いてたのを読んだ
    • 今後シンプルになっていくべきか
    • なんかオールインワンなものが出てくるべきか
    • 全く別のかたちになるか
  • A:そこでYeoman
    • Addy Osmaniらと最近やってるプロジェクト
    • すぐれたwebアプリのビルドに必要なツールは沢山ある
    • たくさんあるツールをまとめる役割を果たすのがyeoman
    • yeomanが対象とするツールは色々
    • 大抵のフロントエンド開発で必須になるツールセットのベースラインを打ち出す
    • このベースラインは受け入れられつつある、と感じてる
    • 多くの人がエディタとかソース管理といった開発環境について同僚と話しをしていない
    • 自分は話をするのが好きだし、同僚の開発してる所を眺めるのが好き
      • 仕事の効率があがったり、快適になったりする
      • 隣に座って「今のどうやってやったの」とかやってる。みんなこういう時間をもっと持ったほうがいい
  • Q:なんだかよくわからないけど、使えればOKという人もいるが、そうでない人もいる
  • A:良い質問
    • Nicolas Gallagher
    • html5 boilerplateのプロジェクトリードやってる
    • boilerplateはみんなのベースラインになるようにしてくべき、とnicholasは考えてる
    • webアプリ、webサイトのベースライン
    • 安定したプロジェクトになったのは、余計なものを足さず、今取り組んでる問題とは別の問題を解こうとしたりしてないから
    • jquery初期からよくみかける話
    • jqueryの勉強とjsの勉強を同時にやるべき?js勉強してからjquery勉強したほうがいい?
    • 「実際にjqueryとjsを同時に学んでる」と、いつも自分は答えてる
    • 勉強を始めた人は、Math,String,Arrayのメソッドはjqueryいくら勉強してもわからない
    • でも、込み入ったDOMの操作の諸々を延々学びたいとも思ってないはず
  • ツールを使うことは一種の上手な勉強のやり方と考えてる
    • html5 boilerplateを使ってると、色々ドキュメントを読むことになる
    • ドキュメントを読みながら、「なんでこうなってる?」とか分からないことが出てくるはず
    • でも、わからないことが出てきても、boilerplateを使うことはできる
    • ある時、わからないことについて勉強したいけど、ストレスなく勉強したいと思うかもしれない
    • 勉強したいと思った時にツールがある
  • 仕組みを理解するのは大事だと思う
    • 自分の場合だと、ブラウザの仕組みについて深く理解したいと今思ってて、ブラウザは本当に複雑だな、と思ってる
    • かといって、「みんなぶれウザの仕組みを深く理解すべき」と説いて回る気持ちはない
    • 現時点でのブラウザへの通り一遍の理解でOKでいいと思う
    • 要はバランス
    • 自分が使ってるツールの仕組みについて深く理解してることは、ツールを使う場面でもとても役立つ
    • でも、仕組みが全くわからなくてもツールを使っていいはず
  • Q:そろそろまとめに。なんかアドバイス
  • A:
    • 振り返ると、jqueryIRCに参加したのは自分にとって変化のきっかけになった
    • もちろん、IRCは超オタク臭い
    • IRCに参加し、IRCでアクティブに活動し、jquery開発に参加し、jqueryチームにも参加し、jqueryプロジェクに長いこと参加し続けてる
    • それもこれもIRCに参加してIRCで色々教えたり助けたりしたのがきっかけ
    • フロントエンド開発で人助け
      • そこから学べることはとても大きい。実際に自分がそうだった
      • 自分はオススメしたい
    • jquery書いてる人たちのグループに出会い、js書いてる人たちに出会い、20人くらいのグループを作っていった
    • IRCで今自分がやってることを話をして、競争みたいなものも中にはあったが、協力して沢山のこと、プロジェクトをやった
      • movethewebforward.orgとかhtml5pleaseとかはそういうプロジェクトからのアウトプット
      • 自分以外の人たち劣等感を感じることなく、お互いに助け合うソーシャルなコミュニティに参加すると、自分に力をくれる
    • 学んでるときに楽しむことができるが大事
    • 学びながらデモを作ったり実験をすれば、クールな機能・使ってみたい機能についての経験値が増える
      • 自信を持って上司を説得して使いたい機能を実戦投下できる
        • 「なぜこれを使わないとダメ?その根拠は?」
        • 「OK。自分はちゃんと使ったことがあります。懸念されるようなものではありませんし、バッチリ動きます」
  • Q:要するに、とにかく手を動かしてクールなことをやってみる、それをシェアする、でOK?
  • A:Yes