Aggregator

2013年1月12日（土） 、ベルサール半蔵門で開催したCSS Nite LP, Disk 26「CSS Preprocessor Shootout」のフォローアップとして、 木村 哲朗さん（まぼろし） 、西畑 一馬さん（まぼろし） の『CodeKitで始める次世代Web制作』のスライドなどを公開します。

• スライド
• 音声

メッセージ、補足

「CodeKitで始める次世代Web制作」と題してお話しさせていただいたまぼろしの木村と西畑です。

制作環境に関する最初のセッションということで、CSSプリプロセッサをまだ触ったことのない方でも簡単に始められるように、なるべく分かりやすくお届けしたつもりですがいかがでしたでしょうか。CodeKitの簡単さや高機能性はもちろんですが、それ以上にこのセッションで私どもが込めた「まずはやってみよう！」というメッセージが皆様に伝わっていれば幸いです。

以下、フォローします。

• デモファイルのダウンロード

デモで使用したファイルをダウンロードできます。 CodeKitを使ってみたい方も黒い画面で使いたい方も、このファイルを練習にご利用ください。

おさらい

西畑がCodeKitやComapssについていくつか記事を書いています。

• フレームワークの登録・利用について

"Video Tutorials"のなかの"Frameworks"をご覧ください。 また、他の動画も大変参考になるので是非ご覧ください。

Q. Windows用でCodeKitのようなツールはないのか

CodeKitのようにいろいろなコンパイルができるものだと"LiveReload"というツールがあります。ただし、まだアルファ版であることにご注意ください。

またこもりさんのセッションで紹介のあった"Mixture"というツールは、クロスプラットフォームでのリリースを予定しており、今からチェックしておいて損はないでしょう。

現状、Windowsでは利用するプリプロセッサごとにGUIツールを利用するか、黒い画面で環境を構築する方が良いかもしれません。なお、それぞれのツールについては他の登壇者から紹介されていますのでここでは割愛いたします。

Q. CodeKitを導入するデメリット･リスクについて

CodeKitを導入するデメリットとリスクは、ずばりコンパイルやビルドをCodeKitに依存してしまうことです。特にLESSの出力先設定やJSの結合などの設定は、CodeKitを利用している人同士でないと共有が難しく、外部の制作者と共同で作業する場合などには注意が必要です。

また、利用するCSSプリプロセッサのバージョンがCodeKitに依存してしまう点もデメリットの１つでしょう。SassなどがバージョンアップしてもCodeKitに最新バージョンが内包されるまでは利用できません。

しかし、CodeKitのコンパイラを外部コンパイラに変更することで対応可能です。 方法は弊社 小林がブログに書いていますので参考にしてください。

CodeKitを利用するかしないかに関わらず、コンパイルやビルドといった行程を制作に持ち込む場合、その手法について制作者同士での意識共有は必須です。

また、さとうさんからCodeKitでStylus+nibを利用する方法についてフォローアップをいただきました。Stylus+nibに興味をもたれた方はこちらの方法を試してみて下さい。

CodeKitでStylus+nibを利用する方法

nib自体は単にmixin定義が書かれた複数の.stylファイル集なので、npmなどコマンドラインでインストールしなくても、ローカルの.stylファイルと同じ場所にファイルをコピーすれば利用できます。

1. GitHubのnibリポジトリ https://github.com/visionmedia/nib/ からZIPをダウンロード
2. ダウンロードされた「nib-master.zip」を解凍して展開
3. 展開後の「nib-master/lib/nib」をコピー
4. 自分の.stylファイルがあるディレクトリにコピー
5. 自分の.stylファイル内で「@import 'nib';」と記述

上記のような手順で利用できます。ぜひお試しください。

• サンプルファイル構成

ビデオ

2013年1月12日（土） 、ベルサール半蔵門で開催したCSS Nite LP, Disk 26「CSS Preprocessor Shootout」のフォローアップとして、 たにぐち まことさん（エイチツーオースペース） の『新世代エディタで作る、プリプロセッサー環境構築術』のスライドなどを公開します。

• スライド
• 音声

メッセージ、補足

「新世代エディタで作る、プリプロセッサー環境構築術」を担当した H2O SPACE たにぐちです。

私のセッションでは、Coda 2と Sublime Text 2をご紹介しました。なかなか、使い慣れたエディタから乗り換えるのはパワーがいりますが、乗り換えることでより作業の効率が良くなったり、今後の技術の進歩にも柔軟についていけるようになります。

いずれのエディタもお試し期間がありますので、是非1度でも使ってみましょう。

アンケートで頂いた質問に回答します。

Q. Subversionに対応したエディタはありませんか？

Coda 2は、Subversionと Gitのクライアント機能を内蔵しています。また、Sublime Text 2には有償ですが Packageがあります。http://wbond.net/sublime_packages/svn

Q. 制作の現場では Macが多いのでしょうか？　Mac向けエディタが多かったようです

Vimや Sublime Text 2はマルチプラットフォームのエディタです。ただ、Macは確実にシェアを伸ばしていることは確かです。もし、まだ Macをきちんと使ったことがないという場合には、ぜひ1台は手に入れて触っておくと良いでしょう。

セッション中に紹介した、URL一覧です。

• CSS Nite in Ginza, Vol.56 (1) 「コーディングを 3倍速くする！ Vim入門」
• テキストブック（パブー）
• Coda 2
• Emmet
• Emmet Plugin for Coda
• CSS Nite in Ginza, Vol.65 「Coda 2特集」
• Sublime Text 2
• Sublime Package Control
• Recommended Sublime Text 2 Packages for Web Developers.
• hayaku
• CSSが速くかけるようになるSublime Text2 パッケージ Hayakuで、世界が変わるらしい

なお「Codaでつくる WEbサイト制作入門」をパブーで販売中です。

ありがとうございました。

ビデオ

　入札運用型広告はインハウスで運用した方がいいと以前のエントリーで書いた。ブランド統合的にインハウスないしハウスエージェンシーでの運用がお奨めだ。リスティング広告をインハウス運用して、またアウトソースに戻してしまうケースもあるが、それは導入方法が悪かったからだ。ディレクションできるスキルを獲得できないで、作業に埋没してしまうと何も得る事のないまま、また完全アウトソースに戻すことになる。それでは意味がない。

　そもそも「運用」とは何を「運用」するのかというと、事業部から預かった広告投資用の金を、求められる広告パフォーマンスに変換して返すという「運用」である。期待値を上回るパフォーマンスにして返して初めて「成果を出した」ことになる。

　この際、売り手の論理で出来た「枠」を買うことももちろんあるだろうが、基本的に買い手が自在に入札するモデルを十分に活用することが前提だ。何故かというと、入札型であれば、買い付けてみて、期待されるパフォーマンスがとれない場合、すぐにでも止めることが出来るからだ。株を買って、株価が下がれば、場合によっては損切りしてでも売ってしまい、その分を他の株に投資して取り返すことを当然やるだろう。
　広告の運用も株式の運用と考え方は同じだ。

従来の「枠」もの広告は、契約上買ってしまうと、途中でパフォーマンスが悪いことが分かっても「止めます」という訳にはいかない。（当然です。）
　いくらPDCAを廻すとか言っても、「枠」を買ってしまう投資より、１配信づつを丁寧に入札するスキルを高めることが効果的だ。
　そのためには、日々、リアルタイムの運用経過を共有し、知見を高めることだ。

　事前に決めたバイイングプランで最後まで突っ走る時代ではない。反応はリアルタイムで把握できる。ユーザーレスポンスを見ながら、最も効果的かつ効率的なハンドリングをする時代なのだ。
　リアルタイムでデータが把握できるのに、リアルタイムで手が打てないのでは意味がない。PDCAサイクルはもう極限まで短いものになっている。「一定のパフォーマンスが得られなければ中断して他の手段にしてみる、または期待以上のパフォーマンスがあれば追加予算を投入して、もっと押す。」という考え方にならなければだめだ。

　「広告枠を買う」のではなく、「広告パフォーマンスを買う」のであり、そのためには自分自身でダイレクトに入札することで、いつでも「Go or Stop」を自在にコントロールするのが当然のこととなるだろう。
　代理店に発注してしまうモデルはマージンを取られるからどうこうではない、代理店のマージンは当然あってしかるべきものだ。「枠」の投資成績が良ければ、代理店から「枠」を買うので良い。代理店にマージンを下げさせるのが効率の良い買い付け方なのではない。そもそも買い付け額とその配分を、買っている本人が自分で自在にコントロールした方がよいのだ。
　

　「運用型広告」の「運用」とは、金融の「運用」と近い感覚のものである。もちろんかかるコストはＰＬ上の費用ではあるが、だからと言って予定されたものは使ってしまうものとか、予備資金は全くないというのでは「運用」にならない。

Googleが何らかの特許を取得したからといって必ずしもその特許に書かれている仕組みを今利用しているとは限らないとGoogleのマット・カッツ氏は、SEOに取り組むウェブマスターに注意を促した。しかし特許はGoogleが目指す検索を理解するうえで非常に優れた学習教材であることも事実だ。

- Googleが取得した特許を学ぶことに価値はあるのか？ -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM

2013年1月12日（土）、ベルサール半蔵門で開催したCSS Nite LP, Disk 26「CSS Preprocessor Shootout」のすべてのセッションのフォローアップ（スライド、音声）を公開しました。

• フォローアップ（1） 『CSSの設計』高津戸 壮さん
• フォローアップ（2）『パフォーマンスから考えるSass/Compassの導入・運用』石本 光司さん
• フォローアップ（3）『LESS is MORE: CSSプリプロセッサをシンプルに使う』谷 拓樹さん（サイバーエージェント）
• フォローアップ（4）『Stylusが目指す“CSSプリプロセッサ”』佐藤 歩さん
• フォローアップ（5）『CodeKitで始める次世代Web制作』木村 哲朗さん 、西畑 一馬さん
• フォローアップ（6）『新世代エディタで作る、プリプロセッサー環境構築術』たにぐち まことさん
• フォローアップ（7）『環境に合わせて快適コンパイル生活』こもり まさあきさん
• フォローアップ（8）『GREEを支える技術フロントエンド版』山田 あかねさん
• フォローアップ（9）『毎日の料理のためのSass』池田 拓司さん
• フォローアップ（10）『CSSプリプロセッサーの登場・発展から考えるCSSデザインの過去・現在・未来』小久保 浩大郎さん、高津戸 壮さん、小山田 晃浩さん

2013年1月12日（土） 、ベルサール半蔵門で開催したCSS Nite LP, Disk 26「CSS Preprocessor Shootout」のフォローアップとして、小久保 浩大郎さん（Google）、高津戸 壮さん（ピクセルグリッド）、小山田 晃浩さん（ピクセルグリッド）の『CSSプリプロセッサーの登場・発展から考えるCSSデザインの過去・現在・未来』のスライドなどを公開します。

• スライド
• 音声

メッセージ、補足

「CSSプリプロセッサ の登場・発展から考えるCSSデザインの過去・現在・未来」と題して最後のセッションを担当した小久保です。参加された皆様、長時間お疲れ様でした。長いイベントの最後ということで、具体的なテクニックではなく意味や意義について考えてみるセッションにしてみましたがいかがでしたでしょうか。個人的にもテクニカルな解説は過去にやっているので、今回は改めて別の視点から考えてみるいいきっかけになりました。セッションでも述べたとおり、およそほとんどの技術は、何らかの問題に対する解決として生まれてきています。今 CSS プリプロセッサを使うことは、決して無駄ではなく将来にも役立つ未来の先取りなんだ、というふうに思って取り組んでいただければ幸いです。

• スライド内で紹介した Tab Atkins Jr. のブログエントリー

今回のセッションは概念的な内容でしたが、再利用可能な Sass ライブラリを構築する際の問題とその解決について書いた記事があるので紹介しておきます。今回のセッションの内容とは逆に、細かくて具体的なテクニックの話ですが、ライブラリが大きくなってくると必ず出てくる問題かと思います。記事を書いたあとで気がついたのですが、全く同様のテクニックを Sass の共同開発者である Chris Epstein 自身も薦めていました。そのことも記事中に追記してあります。

• Sass で Singleton を実現し、安心してクラスを再利用する
• Sass 3.2 からは placeholder selector を使おう

2013年1月12日（土） 、ベルサール半蔵門で開催したCSS Nite LP, Disk 26「CSS Preprocessor Shootout」のフォローアップとして、山田 あかね（グリー）の『GREEを支える技術フロントエンド版』のスライドなどを公開します。

• スライド
• 音声

メッセージ、補足

• Sass vs Less
• 疎結合

グリーの山田あかねです。このたびはご参加いただきましてありがとうございました。

GREEの高速化にあたりSassで行っていることを中心にご紹介させていただきました。Sassでできることはもっとたくさんあるため、是非皆様も実際に触ってみて、楽しさを実感していただければ幸いです。

アンケートでいくつかご意見・ご質問をいただきましたので、回答させていただきます。

Q: ファイルの管理は基本的にローカル＋Gitなのでしょうか？複数人でファイルを同時に触るさいに気を付けていることがあれば教えてほしいです。

A: ローカル+Gitにくわえ、エンタープライズ版のGithubを活用しています。Gitはおのおのの開発者で分散して開発できるのが魅力ですが、実際にリリースをする際にはSubversionのように中央集中型の管理をおこなうメリットも大きいため、Githubを使いながら両方の良さを取り入れて開発しています。

Gitを使えば、複数人でファイルを触る際にも「ブランチを切る」というかたちで、同時進行で異なる機能の開発が可能になります。個人的に、Gitを使ってしまうと、もう以前の開発スタイルに戻れなくなるほど便利だと思います。

少し古い記事になりますが、グリーの開発フローについての記事も参考にしていただければと思います。http://labs.gree.jp/blog/2011/05/3528/

Q: 使っているmixin群とかを見てみたいです。

A: 全て公開することはできませんが、一部ご紹介させていただきます。webkitにしか対応していないプロパティに対して、compassのexperimentalを読み込むようなことをmixinでやってたりします。

// デバイスを傾けたときの文字の大きさ調整
@mixin text-size-adjust($val:none) {
@include experimental(text-size-adjust, $val,
not -moz, -webkit, not -o, not -ms, -khtml, not official
);
}

// タップハイライトカラー
@mixin tap-highlight-color($color) {
$color: none;
@include experimental(tap-highlight-color, $color,
not -moz, -webkit, not -o, not -ms, -khtml, not official
);
}

// ボタンのスタイル
// ボタンの色関連：文字色・背景ハイライト色・背景シャドウ色・枠線色・枠線トップ色・枠線ボトム色・テキストシャドウ色・ボックスシャドウ色・内側のボックスシャドウ色の順に指定
@mixin button-colors
(
$color1: $button-text-color,
$color2: $button-top-bgcolor,
$color3: $button-bottom-bgcolor,
$color4: $button-line-color,
$color5: $button-top-line-color,
$color6: $button-bottom-line-color,
$color7: $button-text-shadow-color,
$color8: $button-box-shadow-color,
$color9: $button-box-shadow-inset-color,
$text-shadow-y: 1px
) {
border: 1px solid $color4;
border-top-color: $color5;
border-bottom-color: $color6;
color: $color1;
text-shadow: 0 $text-shadow-y 0 $color7;
@include background-image(linear-gradient($color2, $color3));
@include box-shadow-mix(0,1px,1px,$color8,0,1px,0,$color9);
}

このようなかたちで、mixinの中でも別のmixinをincludeして使っているものもあります。 デザインに秩序がある場合、特に仕組み化しやすいのではないかと思います。

Q: 変数の方面なども是非おうかがいしたいです。

A: 最初はLessやSassの機能を試してみたい好奇心で、色を変数化して、亜種の色を演算で表現したりもしていました。しかし実際にやってみてわかったのですが、デザインの方向性がしっかり固まっていないうちに色を変数にするとかえってややこしくなるという印象です。

それでも色を変数にするメリットは大きいです。たとえばトーン＆マナーを保ちながら、カラースキームだけをがらっと変更したいようなときなどです。キーカラー、アクセントカラーなどを変数化しておけば、たった数個の変数の値を変えるだけでサイトの印象をがらっと変更できます。

また、レスポンシブに設計したいときには幅やグリッドのしきたりに対して変数をつけておくと運用しやすいかと思いますが、こちらもやはりデザインルールがしっかりしていないとかえってややこしくなってしまうと思います。プリプロセッサを使う使わないに関係なく、設計をしたり、長持ちする仕組みをつくるためにはデザイナーとのコミュニケーションは欠かせないと考えております。

以上、回答とさせていただきます。

ありがとうございます。

2013年1月12日（土） 、ベルサール半蔵門で開催したCSS Nite LP, Disk 26「CSS Preprocessor Shootout」のフォローアップとして、佐藤 歩さん（サイバーエージェント） の『Stylusが目指す“CSSプリプロセッサ”』のスライドなどを公開します。

• スライド
• 音声

メッセージ、補足

「Stylusが目指すCSSプリプロセッサ」を紹介させていただいた、さとう歩（@ahomu）です。当日はご清聴いただきありがとうございました。

CSSプリプロセッサ3連チャンの最後ということで、Stylus自体に加えてプリプロセッサとCSSの関わりの概念的な領域も紹介してみました。

コミュニティによる支持においては、やはりSassが有力なように感じますが、どのCSSプリプロセッサを利用するとしても、今回ご紹介したプリプロセッサとCSSの問題にちゃんと向き合うことはマストだと思います。ご参考になれば幸いです。 　 以下、実行環境や、機能文法などについて改めてフォローします。 　

実行環境

• LiveReload
• CodeKit

黒い画面のプレッシャーが全体通して強いイベントではありましたが、「まず始める」という意味では、ツール系セッションで紹介されていたGUIのソフトウェアがおすすめです。

自身は Grunt http://gruntjs.com/ というコマンドラインツールで、他のビルドプロセスと統合して自動化し、プロジェクト内でもpackage.jsonをベースに環境を共有しています。

機能・構文

• Stylus
• Try Stylus

公式のドキュメントや、セッション中でも紹介したTry Stylusのサンプルコードをみてもらうのが一番確実です（コードサンプルとして簡単に読めます）

• enja-oss/stylus ? GitHub

私も参加しているenja-ossという翻訳コミュニティで、Stylusのドキュメント和訳が進んでいるため、こちらをチェックして頂くのも良いと思います。（始まったばかりですが、じきに内容が充実してくるはずです）

透過的mixinと柔軟性

　 透過的なmixinが、機能の利用を明示しないという点が逆にどうなのよ、ちゃんと区別できたほうがいいんじゃな？というご意見もあったようです。私も明示的なインターフェースは大好きなので、少なからず共感するところです。

そんなときもStylusは柔軟なので、mixinも「border-radius(3px);」のように書ける選択肢があります。ちょっとLESSのmixinに似ている記法です。また、変数の冒頭に書く記号（$）は付けてもよいし、付けなくてもよかったりします。

StylusでCSSから最も距離を取ったSyntaxを選ぶと、（明示的mixin・プレフィックスつき変数・CSS文法の記号を省略）以下のようになります。

　border-radius(n)
  　-webkit-border-radius n
  　-moz-border-radius n
  　border-radius n
　
　$radius-length = 5px
　
　form input[type=button]
  　border-radius($radius-length)

このあたりも好みに合わせて、「ちょうどよく」なれるStylusであることを、頭の片隅に留めていただければ幸いです。

CSSファイルのimportはできる？

こちら、アンケートで頂いた質問ですが、できます！.cssも.stylも@importで読み込んで、コンパイル時には1ファイルに結合されるようにできます。

2013年1月12日（土） 、ベルサール半蔵門で開催したCSS Nite LP, Disk 26「CSS Preprocessor Shootout」のフォローアップとして、石本 光司さん（サイバーエージェント） の『パフォーマンスから考えるSass/Compassの導入・運用』のスライドなどを公開します。

• スライド
• 音声

メッセージ、補足

Sassについてのセッション担当の石本です。

Sass+Compassは非常に高機能なCSSプリプロセッサーですが、だからといってその機能すべて使用・理解しようとすると大変なので、あくまで問題を解決するツールとして考え、必要になったら（なにか問題に直面したら）使用・勉強するといったスタンスで向き合っていけば良いと思います。事実、私も使ってない機能はいっぱいあります。

また、今回のイベントでSassが主流かのような印象を持たれた方も多いと思います。だからといってSassさえ出来てればよいのかというとそうでもないように思えます。時が立てば、またLessが盛り返してくるかもしれないし、全く別のあたらしいCSSに関する技術が出てくるかもしれません。そういった時に、食わず嫌いせずにどんどんそれらを取り込む姿勢（それが黒い画面を使うものだとしても）が今後重要だと考えます。

変化に対応できる柔軟な人材が求めらているなと感じたイベントでした。講演者としても大変勉強になった一日でした。ありがとうございました。

以下、フォローです。

Compassについて

スライドで紹介した、CSS Spriteのmixinの詳細な解説です。

パフォーマンスからみるSass/Compass 第2回：CompassによるCSS Sprite | MOL

私が作成したmixinはRetina対応した独自のものなので、普通にCSS Spriteする分にはもっと簡単に使えます。

CompassでCSSスプライト[to-R]

スプライト画像のレイアウトに関しては$icon-layoutで変更可能です。

Sprite layouts | Compass Documentation

StyleDoccoについて

StyleDoccoの詳しい使い方に関しては下記を参考にしてください。

CSSプリプロセッサでスタイルガイド - inkdesign

｢styleDocco｣の導入とgrunt.jsでの自動化のメモ | Mnemoniqs Web Designer Blog

StyleDocco自体のスタイルは変更できるのか？

個人的には要望は出しているのですが、今のところできないようです。

Ruby製の別のスタイルガイドKSSではできますが、StyleDoccoよりも導入の敷居は高いです。

スタイルガイドジェネレータの KSS が良さそう - text.funenPlaCanen.com