js経由でcss keyframeアニメーションを使う
- jeremy kahnはこれをcssプリレンダリングと命名してる
- 命名としてわかりにくい
- 「CSSのアニメーションのパフォーマンスについて、長きに渡り研究を重ねて来たJeremy Kahnがたどり着いた一つの解答。CSSプリレンダリングと名付けた手法について詳しく解説。」と書かれてるのを読んでもよくわからなかったのでメモ
- 割とシンプルな話
jeremyの記事
- 60 FPS or Bust: Dynamically Prerendering CSS Animations - Jeremy Kahn's Dev Blog
- 書いてる内容
- requestanimationframeは関係ない
- jsライブラリRekapiを使って色々楽をする
- style生成
- polyfill
やってること
cssのkeyframeアニメーションやるならこんなスタイルを書く。
.stylie {
-moz-animation-name: stylie-transform-keyframes;
-moz-animation-duration: 2000ms;
-moz-animation-delay: 0ms;
-moz-animation-fill-mode: forwards;
-moz-animation-iteration-count: infinite;
-ms-animation-name: stylie-transform-keyframes;
-ms-animation-duration: 2000ms;
-ms-animation-delay: 0ms;
-ms-animation-fill-mode: forwards;
-ms-animation-iteration-count: infinite;
-o-animation-name: stylie-transform-keyframes;
-o-animation-duration: 2000ms;
-o-animation-delay: 0ms;
-o-animation-fill-mode: forwards;
-o-animation-iteration-count: infinite;
-webkit-animation-name: stylie-transform-keyframes;
-webkit-animation-duration: 2000ms;
-webkit-animation-delay: 0ms;
-webkit-animation-fill-mode: forwards;
-webkit-animation-iteration-count: infinite;
animation-name: stylie-transform-keyframes;
animation-duration: 2000ms;
animation-delay: 0ms;
animation-fill-mode: forwards;
animation-iteration-count: infinite;
}
@-moz-keyframes stylie-transform-keyframes {
0% {-moz-transform:translateX(0px) translateY(0px);}
100% {-moz-transform:translateX(400px) translateY(0px);}
}
@-ms-keyframes stylie-transform-keyframes {
0% {-ms-transform:translateX(0px) translateY(0px);}
100% {-ms-transform:translateX(400px) translateY(0px);}
}
@-o-keyframes stylie-transform-keyframes {
0% {-o-transform:translateX(0px) translateY(0px);}
100% {-o-transform:translateX(400px) translateY(0px);}
}
@-webkit-keyframes stylie-transform-keyframes {
0% {-webkit-transform:translateX(0px) translateY(0px);}
100% {-webkit-transform:translateX(400px) translateY(0px);}
}
@keyframes stylie-transform-keyframes {
0% {transform:translateX(0px) translateY(0px);}
100% {transform:translateX(400px) translateY(0px);}
}
スタイルのリストを生成する手間を軽減するのがrekapi
-
- Rekapi - A keyframe animation library for the web
- polyfillにもなってる
- keyframeアニメーション非サポートブラウザ向けにはピュアjsアニメーションを用意してくれる。
ソーシャルプラグインのlazyload
- 調べたり試したことのまとめ
- とりあえずfb,twitter,g+だけ
- コピペ用コード並べた
やりたいこと
- 画像でみかける遅延読み込み、オンデマンドでの読み込み
- それをlikeboxとか、tweetボタンとかでもやりたい
- techcrunchのトップとかでやってるあれ
- １ページの中に100個くらいボタンある
$(".lazy-share-widget .platform").length //->90- ボタンのある所にカーソル持ってくまで、ボタンがロードされないようになってる
- mashableのトップは全然違う
- layzyload関係ない
- あれはサーバ側であらかじめページにボタンを埋め込んでる
- だからtweet数とかlike数とかの数値がかなりずれる
- 割り切り型の手法
- そもそもfb/tw/g+へhttpリクエスト出さない
- CDNもつかって速さに挑戦してる
- 「この辺までスクロールしたら表示」とか「カーソルこの辺まで来たらロード」ロードとか
- 出来るだけhttpリクエストを減らす、というより、小出しにしたい
- 初回ページロードだけでなく、ajaxとかpjaxにも対応
##ライブラリはあるにはあるが。。。
Socialite.js- 機能が足りない感じ
- ボタンだけとか
- ソーシャルプラグイン側の仕様にがっつり追従できるのか、不安
- 実際`socialite.js`は最近開発されてない
- プラグインのSDK
##ライブラリ（SDK）の読み込み
- とりあえず何度も読みに行かない
plusone.js、`widgets.js`、`all.js`を何度もリクエストしないFB、twttr、gapiオブジェクトの有無を判定すればOK
# jQuery + coffeescriptで # twitter if !twttr? jQuery.getScript "//platform.twitter.com/widgets.js" else console.log "OK" # facebook if !FB? jQuery.getScript "//connect.facebook.net/ja_JP/all.js" else console.log "OK" # google+ if !gapi? jQuery.getScript "//connect.facebook.net/ja_JP/all.js" else console.log "OK"
プラグラインの初期化
- SDKが入ったjsを読み込んだ後の話
- 初期化？
- 初期化の設定でプラグインのロード（レンダリング）だけはオフにしたい
- facebook、google+はAPIがサポートしてるのでシンプルにできる
- fb
xfbml:falseをFB.init({..option.})のオプションに指定
- G+
parsetags:"explicit"をwindow.___gcfgプロパティにセット
- fb
- twitterはアカン
widgets.js読み込みおわったらページ内の全てのソーシャルプラグインのレンダリングが始まる- developer toolsのnetworkタブは凄いことに
- 引数無しの
twttr.widgets.load()が必ず走ってしまう - ページ全体の全てのplaceholder（=プラグイン埋め込み予定地）でプラグインのロードが始まる
- twitterはアカンが回避方法は一応。。
- 初期化のタイミングは気にしとく
- SDKを非同期読み込みするから
FBオブジェクトがないのにFB.init()とかやってしまわない- とはいえ気にしないといけないのはfacebookだけ
- facebook sdkもそんなに大変じゃない
window.fbAsyncInit= fucntion(){....}の....でFB.init(...)書く- こう書けば安全に
FB.init()できる
# g+ window.___gcfg = parsetags:"explicit" # レンダリング＝手動に lang:"ja" # ローカライズ #facebook window.fbAsyncInit = -> FB.init( xfbml:false ) # g+の___gcfgプロパティに設定できるオプションの話 # https://developers.google.com/+/web/+1button/?hl=ja # # FB.init(options)のoptions一覧はここ # https://developers.facebook.com/docs/reference/javascript/FB.init/
twitter sdk読み込み直後の自動レンダリングを回避する
- g+やfbのと違って一手間必要
twttr.widegets.load(arg)はこんな動きtwttr.widgets.load()はプレースホルダがなければ空振りする- プレースホルダーかの条件
- a要素か、blockquote要素
- それぞれ決まったclass名がついてる
//cssセレクタで書くとこんな感じ "a.twitter-share-button" "a.twitter-mention-button" "a.twitter-hashtag-button" "a.twitter-follow-button" "a.twitter-timeline" "blockquote.twitter-tweet" /* http://platform.twitter.com/widgets.js の後ろのほうに書いてある */
引数なし、ありを比較するとこんな感じ
# プラグインをロードする箇所を明示してる場合
twttr.widgets.load document.getElementById(".share")[0]
# twttr.widgets.load()ただするだけだとこんな感じになる
selector = "a.twitter-share-button"
selector += ",a.twitter-mention-button"
selector += ",a.twitter-hashtag-button"
selector += ",a.twitter-follow-button"
selector += ",a.twitter-timeline"
selector += ",blockquote.twitter-tweet"
jQuery(selector).each ->
twttr.widgets.load @
- プレーホルダーとして検出されないようにするやり方１
- スニペットをちょっとだけ直す（class名かえとく）
<!--スニペットで、twitter-tweetになってるとこを、no-twitter-tweetにしといて、.load()する直前にclass名かえとく--> <blockquote class="no-twitter-tweet"> <p>なんでや！ 家入さん無関係やろ！ RT <a href="https://twitter.com/fukuyuki">@fukuyuki</a>: 今回のロリポップの大量ハッキング騒動で最も特筆するべきことは、この騒動の中、創業者である家入さんは「ネットも電気もお金もない砂漠の真ん中で一週間生活する」というバーニングマンというイベントに参加していたことだと思う。</p> ― やまもといちろう (@kirik) <a href="https://twitter.com/kirik/statuses/373370555464183808">August 30, 2013</a> </blockquote>
- その２
- ボタンをオンザフライで生成するメソッドを使う
twttr.widgets.createShareButton()とか
//.share内部にボタンが挿入される
twttr.widgets.createShareButton(
"http://hatena.ne.jp"
document.getElementById(".share")[0]
->
console.log "buttonできた"
return
count:"horizontal"
text:"Hatena"
lang:"ja"
)
オンデマンドでプラグインをロード
- sdkロード、sdk初期化が終わったあとの話
- スクロールしたタイミング
- ajaxやら、history api経由とかコンテンツ持って来たあととか
- ここからはfacebook,g+,twitterはだいたい同じ
- ロード用のメソッドにプレースホルダーのdomノード渡すだけ
### 引数に渡すdomノードは placeholderそのものじゃなくて placeholderの親要素でok ### jQuery(.social).each -> #g+ gapi.plusone.go @ #twitter twttr.widgets.load @ #facebook FB.XFBML.parse @
- あとはイベント発火のタイミングとかであれこれ指定したらいい
「フレンチ・レズビアンたちの本音」（エル・ジャポン7月号）
特に印象に残った箇所
「視線からすべては始まる。問題は、男性が第一歩を踏み出すものという異性愛者のメンタリティーのなかで育てられたから、ふたりのうちどちらが動くまで、感情を抑えなくちゃならないこと」とベアトリスは説明する。
- ユニークな状況に置かれてる人たちの内省がこなれた言葉に落とし込まれてるのを読むのは楽しい
- 「視線からすべては始まる」というフレーズがスッと出てくる感じ
- フェミニストだとこうはいかない
- コミットしてる主義主張にがんじがらめのフレーズしか出てこないから
- 「視線からすべては始まる」というフレーズがスッと出てくる感じ
- 記事自体はelle本家ウェブサイト上でのチャットでの議論をベースにしてる
- 同族嫌悪的な話題、権利云々の話とかも当然ある
- が他所でも読める話なので印象には残らなかった
- 【ELLE】エル・ジャポン7月号｜エル・オンライン
- 「elle」と「marie claire」をずっと読んでると、ブロガーが雑誌に登場するプレーヤーの１人としてどんどん役割を与えられていく（どんどん大きくなることはあり得ないが）流れがどんどんくっきりしてくのが面白い
- パリコレとかの呼ばれてファッションスナップにもたまに登場し始めたのが3-4年前くらいだと思ったが、その頃と比べるとプレゼンスが増してる
- 「vogue」はテキスト成分が圧倒的に少ないのでそういう変化を感じないが
- この辺を分析してる記事とか本読みたい
- 「elle」と「marie claire」をずっと読んでると、ブロガーが雑誌に登場するプレーヤーの１人としてどんどん役割を与えられていく（どんどん大きくなることはあり得ないが）流れがどんどんくっきりしてくのが面白い
思い出した話
- ちょっと前、並木橋のスーパーで買い物したときのこと。
- スーパーに女性二人組がエスカレータで上ってきたとき、ちょうど自分は買い物を終えて下りエスカレーターで彼女らとすれ違った
- エレベータは二人並べない狭いやつなので前後した上ってきた
- 上に立つ女性は下の段の子の方を向いてるので表情はわからない
- 下側の子は上の子に向けて嬉しさに溢れた視線を向けてて、いい顔してるな、と思って通り過ぎた
- と同時になんか妙な違和感を感じたが、その場でわからなかった
- 店を出て数分経ってから「カップルか」と納得した
思い出した動画
- vocal参加してるMary Lanbertの所が好き
- 「And I can't change, Even if I tried, Even if I wanted to...」と力強く唄う箇所
- PVが歌詞の世界観を忠実に表現してるので見ればどんな曲かはわかるかと
- id:TomoMachiさんがざっくり歌詞を訳してる
Open Web Platform Daily DigestのRSS
便利だが。。。
野良rss
http://webplatformdaily-org.ap01.aws.af.cm/feed
- 冒頭の所は削って、日付入ってるとこだけにしてる
- かなり適当
- appfog使ってみた
- appfogはdashboardだけ超重い
- herokuにしようかと思ったが見送った
- /usr/bin/heroku以外にheroku toolbelt入れるやり方がすぐに分からなかった
- 「 brew install heroku-toolbelt」はしてみて「$HOME/homebrew/bin/heroku」になってるが、公式配布のものと同じ挙動してくれるのか（警告とか肝心なときに出たりしないか）把握できなかったのでパス
- cronはnode-cron。
- 1日1回.mdファイル読みに行ってる
- 調べたら有るのかもしれないが、appfogにheroku shceduler相当のものがあるかわからかった
- コマンドラインツール「af」も「af login」「af push」「af update」しか使ってない
- markdownパーサはnode-markdown
- markdown（npm install markdown）は使わなかた
- なぜか今回パースしたいmdファイルでうまく動かなかった
- rss生成はnode-rss
- validationサービス通るrss作ってくれて手軽
公式rss
- そのうちできるよ。とのこと
- simevidas/webplatformdaily-site · GitHub
Pat Shaughnessy「rubymotionクリエータに一問一答（前編）」
rubysource 2012.2.13のエントリ
RubySource | Getting To Know RubyMotion With Laurent SansonettiRubySource
- id:naoyaさんのエントリ経由で知った
- 長編で二部構成になってる
- プルリクエストもらえそうなビルドシステム（rubyで書いた）だけオープンソース
- プリリクエスト期待薄だと実体験が教えるコンパイラとランタイムはクローズドにし、プロジェクトの資金にもなってる、とか
- それぞれ違う理由でrubymotionからrequireとevalを削ったこととか、
以下斜め読んだ内容
はじめに
- 2012.4以来rubyコミュニティの心を掴んだrubymotion
- 初めてiosプラットフォームでrubyで書けるようになった
- 古式ゆかしいobjective-cもxcodeも一から勉強しなくてよくなった
- rubyとコマンドラインツールがそれに取って代わった
- インタビュー前編；ベーシック
- インタビュー後編：テクニカル
初のrubymotionカンファレンス
- Q：RubyMotion#INSPECT2013の話から
- A：
- リリース後半年したら閃いた。rubymotion小規模イベント
- 最近bubbleconfにスピーカとして呼ばれたので話をしてきた
- 動画ある
- スタートアップ向けカンファレンス
- rubymotion立ち上げる前に自分が抱いた恐れや不安とかをしゃべってきた
- Nihn Buiがオーガナイザ。周りに助けられた切り盛りしてた。
- 俺もやってみたい、となった
- Q：カンファレンス立ち上げるなんて大変そう
- A：
- Nihnほど大掛かりじゃないし
- 150人くらいの規模でよかった
- はじめはrubymotionユーザの多いアメリカでやろうかと思ってた
- 最初のカンファレンスは自分に特別なものとなるはず、と色々考えた
- ホーム（＝ベルギー）でやることにした
- Q：なんでベルギー開催？
- A：
- 負担がより少ない
- できるだけ小さくやりたかった
- 顔を見ながら話したりハックできる場所にしたかった
- カネ目当てじゃない。今回は赤字になるはず
- 楽しむために、rubymotionの宣伝のためにやる
- 実はミニツアー付きカンファレンス
- チョコレート工場とビール工場見学ツアー。Brusselsらしいもの
- スピーカの数のリストは大きくなった。が、持ち時間は30分。間の時間もゆったり取った
- 会場は１つだけ。全員そこで登壇
- rubymotionコミュで有名なスピーカーもいる
- 37signalsのNick Quaranto
- HerokuのMatt Thompson
- 知名度高くないがrubymotionコミュで凄い仕事してる人たちもスピーカに参加してくれてる
- いいカンファレンスになるはず
rubymotionのはじまり
- Q：Appleで働いてたらしいけど
- A：
- Q：rubymotionのスタッフ
- A：
そもそもrubymotionとは
- Q：rubymotionnとは。。。
- A：
- 要は、rubyでios開発するためのツールチェーン
- objective-cランタイム上のruby実装
- iosコアフレームワークの上に構築
- rubymotionのobject model実装
- objectvie-cランタイムを使ってる
- 例えばrubymotionでエンジニアがクラス、オブジェクト、メソッドを作ったとする
- そのときに実際にはobjective-cのオブジェクト、クラス、メソッドを触ってる
- rubyからのブリッジとかミドルウェアは存在しない
- エンジニアは全てのios apiにダイレクトにアクセスしてる
- Q：objective-cでの開発と全く同じシステムを使ってる？
- A：
- YES
- objective-cランタイムは実際には、小規模なcライブラリ
- ios開発者は自由にこのライブラリを利用できる
- rubymotionで自分がやってることはまさにそれ
- rubymotionアプリは、objective-cアプリと同じ流儀でランタイムAPIを叩く
- rubymotionではiosのcoreframeworksを使ってネイティブのクラスを実装してる
- 例えばrubymotionのStringクラス
- FoundationフレームワークのNSMutableStringのサブクラスとして実装されてる
- Stringクラスは普段rubyを書いてるのと同じ感覚。違いはほぼゼロ
- rubymotionが裏側でobjective-cでstringを操作してるのと同じ状態を作ってる
- どういうことか
- 例えばrubyでstringを作る。
- このstringがobjective-c apiに渡される。変換とか挟まない
- rubymotionのオブジェクトモデルでは、objective-cのランタイムを使う
- rubymotionのクラス実装にはFoundationフレームワークを使う
- Q：
- rubyのString#upcaseに相当するものがobjective-cには無い
- 実装しないといけなかったはず
- A：
- Q：それ以外のrubymotionの構成要素
- A：
- Q：デバイスのobjective-cランタイム上でrubymotionランタイムが走る？
- A：
- YES
- オブジェクトモデルはobjective-cランタイム使う
- rubymotionランタイムがある。1MBくらい。静的にリンクされる
- rubymotionのランタイムではネイティブにあるクラスだけでなく、ネイティブにない機能も実装した
- 例１．objective-cには、mixinという概念がない
- 実装した
- 例２。あるクラスへインスタンス変数を動的にセットすることがobjective-cではできない
- そのためにworkaround入れた
rubymotion v.s. MRI
- Q：rubymotionがベースにしてるrubyのバージョン
- A：
- Q：rubyエンジニアがrubymotion始めるにあたり、気を付けるべき違いは？
- A：まずrequireが無い
- Q：じゃあrubymotionでのライブラリの読み込み方法は？
- A：
- rubymotionでは静的にコンパイルされる
- コンパイル時に必要なファイルをコンパイラに伝える必要がある
- ランタイム時にモジュール読込むとかしない
- Q：cで言うinclude、あるいはMakefileみたいな話し
- A：
- YES
- 最近ビルドシステムはどんどん賢くなってる
- rubymotionでは新規プロジェクト作ると「app.」ディレクトリができる
- 「.app」以下にrbファイル作ってく
- 作法としては、1クラス1ファイルがオススメ
- ビルドシステムは.app以下の全てのrbファイルを読込んで、依存関係を調べる
- 例。クラスFooが定義されたファイル、クラスBarが定義されたファイル、BarはFooを継承してる、とする
- ビルドシステムは継承関係検知して、FooをコンパイルしてからBarをコンパイルする
- ランタイム上ではクラスFooがクラスBarより先に生成される
- こんなわけで通常はrequireがいらない
- Q：依存関係の検知は全自動？
- A：
- やらなかったこと
- コンパイラへのヒント的なものとしてrequireを実装する
- こういう選択肢はあり得たがやらなかった。筋悪いと思う
- そもそもrequireはKernelクラスのメソッド。引数渡して使うもの
- requireはキーワードじゃないし、基本型扱いする必要がない
- requireには定義済みのstringを渡すことができる
- こんなrequireの挙動にrubymotionのコンパイラは対処しないといけない
- この手のエッジケースに対応するのはいい考えだと思わない
- rubymotionのビルドシステムはコードをパースし依存関係を検知しようとする
- rubymotionでrequire使うと例外がスローされる
- requireを別にすれば、rubyとrubymotionの違いはとても小さい
- あとevalも無い
- evalサポートはインタプリタ同梱するのと同じ
- インタプリタ同梱のアプリをリリースすることにつながる
- やらなかったこと
- Q：インタプリタ同梱はapple的にNGでは？
- A：
- Q：evalを外すことでrubymotionは大丈夫ですとappleに伝えてる、と
- A：
- あと、ハードウェア性能は低いので、ランタイム時にコードをevalするのはいい考えだと思わない
- Q：Kernel#eval以外、instance_evalとかclass_evalとかは？
- A：
- サポートしてる。それ以外のeval系メソッドは動く、はず
- メタプログラミングに使われる類のものは全部いける
- Q：requireとevalがないだけであとはMRIと同じ？
- A：
- まとめるとこんな感じ
- require無し。ビルドシステムあるから
- evalは動かない
- Proc#bindingは削除された
- FixnumとFloatでは、演算子オーバーライドできない
- まとめるとこんな感じ
rubymotinはオープンソースでない件
- Q：rubymotionはオープンソース？プロプライエタリ？
- Q：rubymotionがお客に提供できるコア技術はコンパイラ？
- A；
- Q：rubymotionはrailsのようにはいかない。サクっと直したり機能足したりとかできる領域じゃない、と
- A：
- Q：この仕組みでやりたいことを自分のペースでやれてる、と
- A：YES。というか、自分にはこれが唯一のやり方だった
今後
- Q：rubymotionの今後
- A：
- いいにくい部分
- rubymotionは急速に成長してる
- リリースしてから８ヶ月しか経ってない
- 現時点で、色々な選択肢が見えてきた。重要な機能追加、等々
- リソースは有限。決めて行かないといけない
- ツールチェーンの改善。これは多分今後やると言えそうなこと。
- コマンドラインベースしかない。これで大抵のユーザは使えてる
- IDEラブな人たちもいる。いまJetBrainsと一緒に仕事してる
- RubyMineのrubymotionサポートは良い感じになってる
- RubyMIne内部でrubymotionのデバッグができる
- このまま一緒に仕事続けたら、rubymotionユーザのためのIDEが作れるかも、と思ってる
- ios以外のプラットフォームもサポートしてほしいというリクエストは沢山もらってる
後編
Bruce Lawson「以後operaはwebkitとv8にします」
Opera Developer News 2012.2.12のエントリ
Opera Developer News - 300 million users and move to WebKit
以下斜め読んだ内容
- operaユーザ数：3億人突破
- レンダリングエンジン：webkit/v8に変更
- 投入時期：スマホが最初
- お披露目：Barcelonaのカンファレンス
- 影響：ユーザはゼロ。開発者は少々
- 音声データ：webmとh.246両方をサポートが安全。source要素で両方ソースに書く。canPlayType()使って判定
- winow.object：廃止。ブラウザ判定では使えない。ていうかmodernizrとかその辺使え
- operaアドオン：変換ツール出す予定
- 昔話
- opera起源の便利機能：タブブラウザ、スピードダイアル、ページ読込のためのデータ圧縮
- （補足）「ページ読込のためのデータ圧縮」が他のブラウザでどう使われてるのかが？？
- 転向理由：
- 正式にwebkitチームに参加
- [webkit-dev] Opera and WebKit
- 以後パッチ送って貢献
- コメント欄
Nick Pettit「Paul Irish一問一答」
Treehouse Blog 2012.10.24のエントリ
Treehouse Friends: Paul Irish - Treehouse Blog
- 聞き手が教育系スタートアップの人
- html5 boilerplate始めたきっかけの話とか
- 条件付きコメントを使ってる理由とか
- yeomanの話とか
- なんだかフロントエンド開発の敷居が上がり続けてる件とか
- web業界以前の話（wordの差込印刷作った奴偉い、とか）
- アドバイスとか
通り一遍を訊いててinformative
以下斜め読んだ内容
- Paul Irish。誰？
- google chrome developer relationsチームの人
- 色々プロジェクト手がけたり参加したり
- インタビューのポイント
- どんどん複雑になってるフロントエンド開発
- キャリアパス
- html5 boilerplace
- などなど
- インタビュー動画あります
以下一問一答
- Q：自己紹介、やってること
- A：
- Q：色々なプロジェクトを進めてる動機
- A：
- 一つは人助けから得られる満足感から
- あとは自分の記憶力の悪さを補うものが欲しかったから
- 書き出しておかないと忘れる
- meqia queriesやviewportの使い方を調べるとする。得た知識やノウハウをいつでも使える状態にしておきたい
- html5 boilerplateはそうやってできた
- ネットや本で調べた知識・ノウハウをストックしてる
- 自分が必要としたもので、自分がとても助かってる
- 転じて、自分以外の人にも役立ってる
- webはみんなが凄いものを作れる場所であって欲しい
- こういう気持ちが自分がやってることの動機にもなってる
- webがもっと強力なプラットフォームになっていくプロセスに自分が貢献できることに満足感を得てる
- Q：必要としてるノウハウ・知識は色々なタイプがあるから、プロジェクトも色々な形をとってる？
- A：そうできるからそうやってる
- Q：色々なプロジェクトに割くリソースの配分。バランス
- A：
- 時間管理は得意じゃない
- workflowly使ってる
- WorkFlowy - Organize your brain.
- いいツール
- リストのネストができる強力なto doリストアプリ
- ４半期に分けて、プライオリティ設定して、ひたすら試行錯誤
- 少し長めの期間を視野にいれとくのは大事
- 日単位だと、別のことに気が向いたり、新しいことを試したくなったり、とやってしまうのはありがち
- ある程度経って振り返ったら、諸々の脱線が本当にやっとかないといけないことにデカいダメージ与えてる、ってもありがち
- 自分は時間管理がとても下手くそだが頑張ってる
- Q：生まれとか経歴とか
- A：
- Massachusetts西部、Connecticut出身。要はNew England出身
- 音楽やってた。マーチングバンドでチューバ吹いてた。高校では演劇とバンド
- ネットで最初に作ったのは音楽ブログ。2004年くらい。
- 音楽ブログでは古参で、最初の５０番目以内に入っててそこそこ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の学位のご利益はデカい
- ５年前の時点でコンピュータサイエンスがweb開発に役立ってるとは言えなかった
- 現在は違う。クライアントサイドでは、ロジックに溢れてる
- jqueryで書き、物事がよくなってく。。tranlateをしてる、より大きなアプリのコードを書いてる
- Q：相当複雑なものになりつつある
- A：
- 文房具会社でマーケティング的なことをやってた
- 文房具会社は結婚式招待状や出産報告とかを作ってた
- つまりweb成分ゼロ
- 自分はwordで差し込み印刷用のファイル作りファックスを一斉送信に使った
- 差込印刷を送信する顧客むけにカスタマイズすることもやってた
- こうしたカスタマイズを可能にするロジックがwordにはあった。word偉い
- その後配置換えになってEC部門へ。よい機会になった
- 自力で開発できるものを持ってたほうがいいと思う
- 自分の場合は音楽ブログ
- 更に、ブログじゃなくてもいいけどweb上に自分の場所を持ってたほうがいい
- ブログ書くのはいいこと。学んでることをブログに書くのはとてもスマートなこと
- 色々繰り返したり試したり遊んだりできる場所を持ってるのはいいこと
- 例えばcss3の新機能が登場したとき
- デモ作る、色々調べる、codepenにポストする
- デモ・調べもの・ポスト等々を奨励し、フィードバックをくれるコミュニティがたくさんあり
- コミュニティに参加して、調べ物したり、話ししたり、プロフェッショナルな開発を探求したりできる
- 自分はそうやってきた、物事すすめるスマートなやり方だった
- Q：ちなみに最初のブログはworpress？
- A：yes
- Q：
- A：
- インターフェース開発であるから
- インタラクションの仕方を決めることができる
- ユーザやお客からフィードバックをもらうことができる
- ユーザやお客の心に届くものを作ってる
- ユーザやお客がマウスカーソルを走らせる場所を作ってる
- インタラクションのあり方、UXのクオリティをコントロールする立場にある
- レスポンスを高速化させる仕事、堅牢なインフラを作る仕事も開発にはある
- だが、UIに自分はとても魅力を感じてる
- Q：すぐに達成感を得られるってこと？
- A：
- 素早い達成感、自分が作ったものへのフィードバックサイクル
- ユーザを喜ばせるものを作れる
- 使った技術がまずければ反感も買うことだってある
- Q：
- 次はhtml5boilerplate
- デザイン・開発初心者にとっても役立ち、内容充実してる
- プロジェクトが始まったきっかけ
- A：
- 前職の頃。Bostonのweb制作・開発の会社
- プロジェクトをこなすなかで、自分のコードを何度もコピペしてることに気付いた
- テンプレ化したほうが過去のプロジェクトのコードを漁る手間がスキップできる、と判断
- 次々プロジェクトこなすときに必要だったものが出発点
- しばらくしたらDivya Manianもプロジェクトに参加してくれた
- v1.0をリリースでは、他の人も役立つを思ってくれるテクニックを盛り込んだ
- 最近まで、インラインでドキュメントつけてた
- githubにソースをホストしてる
- 公開後github経由でたくさんフィードバックもらった
- ここはこう調整するともっと良くなり、opera9.6のバグのよい説明にもなる、とか
- html5 boilerplatesのトピックごとに色々ディスカッションが生まれてる
- ディスカッションの成果が盛り込まれてる
- ディスカッションには、優れたフロントエンドエンジニアも参加してる
- 更新履歴、議論、過去の問題等々を辿れる
- コミットログは詳しく書いてる。変更の根拠がわかる
html5 boilerplates
>|||
|
- Q：
- html5 boilerplatesをDLしてファイル開いても「何これ？」となる初心者向けに
- ファイル見た人が最初に目にするIEのconditonal commentsから
- A：
- conditional comment。洗練さとかセクシーさとかの対極
- ie対策はまだ必要
- ie6-7は無視出来るくらいシェア落とした
- ie8はまだシェアもってる
- 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：
- ２つのことがここ数年で起こってる
- １つは、レガシーなブラウザが視界から消えた
- ie6死亡、ie7はシェア1%
- ie8はシェア持ってるが、ブラウザの性能アップした
- レガシーなブラウザへの対策がフロントエンド開発で悩みの種だった
- もう１つは、沢山の新機能が登場した
- 過去3年で沢山の機能がブラウザに追加されてる
- 追加された新機能をどう使うか、組み込んでいくかに、頭を使ってる状態
- 例えばcss transition
- css transionを実務で使う時、非対応ブラウザ向けにfallbackも実装する
- 自分はfallbackしたほうが良い派
- フォールバックとして何を提供するかを決めるのは、少し大変
- 例えばcss transionを使ったサイト作ったとして
- modernizrで非対応ブラウザ検出して、非対応ブラウザ向けにjqueryでアニメーション実装、とか
- 常にやるべきことじゃない
- だからhtml5 pleaseというサイト作った
- HTML5 Please - Use the new and shiny responsibly
- フォールバック、クロスブラウザ対応のためのガイド
- polyfillの使いどころとかを機能別に羅列
- Q：フォールバックシナリオの安全牌ある？
- A:
- polyfillを旧いブラウザに送りつけるのは好きじゃないが
- 常にこうしたほうがいい、というのはない。いつも複雑で込み入ってる
- かつては、「あらゆるブラウザで見た目を揃える」、「機能が足りないブラウザにはテキストだけ表示」とかあった
- いろんなデバイスがあってサイトの見え方も複数ある状況も生まれて、状況をさらに複雑にしてる
- 一つは気にしないこと
- 使いたい機能を使えるブラウザにユーザが乗り換えるように働きかけていく
- 乗り換えてくれれば、フロントエンド開発の苦しみは減る
- 高い乗り換え率を弾きだした場面も過去にあった。ブラウザの高速化は乗り換えを大幅に促進した
- 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：
- 振り返ると、jqueryのIRCに参加したのは自分にとって変化のきっかけになった
- もちろん、IRCは超オタク臭い
- IRCに参加し、IRCでアクティブに活動し、jquery開発に参加し、jqueryチームにも参加し、jqueryプロジェクに長いこと参加し続けてる
- それもこれもIRCに参加してIRCで色々教えたり助けたりしたのがきっかけ
- フロントエンド開発で人助け
- そこから学べることはとても大きい。実際に自分がそうだった
- 自分はオススメしたい
- jquery書いてる人たちのグループに出会い、js書いてる人たちに出会い、20人くらいのグループを作っていった
- IRCで今自分がやってることを話をして、競争みたいなものも中にはあったが、協力して沢山のこと、プロジェクトをやった
- movethewebforward.orgとかhtml5pleaseとかはそういうプロジェクトからのアウトプット
- 自分以外の人たち劣等感を感じることなく、お互いに助け合うソーシャルなコミュニティに参加すると、自分に力をくれる
- 学んでるときに楽しむことができるが大事
- 学びながらデモを作ったり実験をすれば、クールな機能・使ってみたい機能についての経験値が増える
- 自信を持って上司を説得して使いたい機能を実戦投下できる
- 「なぜこれを使わないとダメ？その根拠は？」
- 「OK。自分はちゃんと使ったことがあります。懸念されるようなものではありませんし、バッチリ動きます」
- 自信を持って上司を説得して使いたい機能を実戦投下できる
- Q：要するに、とにかく手を動かしてクールなことをやってみる、それをシェアする、でOK？
- A：Yes
