Polymer と Web Components の違い9選（もとい Polymer の便利機能）
違い、または付加機能 色々な周辺事情で、勢力を広げつつある Polymer さん。（つい最近、それに加担したような気もする） 「どこまでが Web Components で、どこからが Polymer なのか」を理解するためにもPolymerの機能をメモる。Polymer は色々なことを便利にしてくれるライブラリであり、差分を言い出すとキリがないので主要なポイントだけ。 <template> が自動で Shadow DOM に放り込まれる Shadow DOM内の <link> をインラインの <style> に展開 repeat のサポート {{interpolate}} のサポート <element> のかわりを <polymer-element> としてサポート on-click とかイベントハンドラの宣言 this.$ による idが付加された要素のコレクション observe に
フロントエンドチューニングの箇条殴り書き
普段気をつけてるよリスト "モバイルで、WebViewとブラウザのコンパチで、特にセオリー化されていないデザインモジュールのなか、装飾画像もふんだんに使うぞ系サービス開発" の文脈における、パフォーマンス確保のため気をつけてるよリスト。 よく、パフォーマンス「向上」とか「確保」とか申しますが、メンテナンスコストなどと天秤にかけて、「必要十分」のラインを狙うのが重要だと思う次第。 画像リソース 画像リソースを揃えるときのセオリ。圧縮率とか最適化とか細かいチューニングはあれど、大雑把に下記を守る。そしてImage Optim（or 相当の処理）。 JPEGはプログレッシブで画質60くらい（オレ目安） PNGは差し支えない範囲で色数をきちんと削る 50px未満のサムネイルは@2.0xなリソースにしない 案外、Androidあわせの@1.5xや@1.0xでも大丈夫なことすらある GIFアニメを入れ
ぼくが実際に運用していたGitブランチモデルについて
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
続・mod_pagespeedの各Filterと設定について ハブろぐ - havelog.ayumusato.com
mod_pagespeedがサーバーから出力されるファイルを最適化する apacheモジュールのmod_pagespeedは、Page Speedアドオンで、検査しているような項目について、HTML・CSS・JSなどを最適化してくれます。例えば、冗長なインラインのCSSを外部ファイルにしたり、逆に短く小さいサイズの外部CSSをインラインにしてリクエストを節約したり、JavaScriptのminify処理をしたりします。 基本的には、クライアントサイドの体感速度と、転送量の抑制につながる、フロントエンドに関連する最適化です。フロントの実装コストを、ある程度サーバーが吸収してくれます。 CentOSへのインストールについては、関連記事の「さくらのVPSにGoogleのmod_pagespeed入れてみた」も併せてご覧ください。 実際に、どんな感じになるのかをソースコードで見るなら、「mod_p
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
