主に技術的なことを書くブログ

浅めにマークアップ＆フロントエンドの技術的なことをメモしていましたが、ざっくばらんに書いています。

リアルフロントエンド勉強会 vol.2

Sass / SCSS Compass bower Grunt フロントエンド勉強会

f:id:nakagaw:20141127151933j:plain

前回に続いて、第2回リアルフロントエンド勉強会を行いました。

  • 第1部「攻めすぎコーディング環境をつくろう」
  • 第2部「発表プレゼン」
  • 懇親鍋

という流れで行いました。集まった参加者は4人。

第1部「攻めすぎコーディング環境をつくろう」

workshop/20141115 at master · real-frontend/workshop

今回作成したベースファイルはGitHubに上がってますので、クローンしたディレクトリで下記のコマンドをうちます。

npm install

package.jsonにリストアップされている、Gruntプラグイン関連のファイルがインストールされます。（※うまくいかないときはsudoつける）

bower install

※今回は、grunt-bower-taskを使っているのでbower installは飛ばしてOK。

bowerとは、フロントエンド関連のファイルが上がっている大きいリポジトリみたいなもので、bower.JSONのリストから追加するパッケージを指定してコマンドをうつとbower_componentsディレクトリが生成され、そこに各パッケージがインストールされます。

今回は_libというディレクトリも作成し、そこには主要ファイルのみインストールするようにしています。（bower_componentsをあえて残しているのは後から他のファイルを参照する可能性もあるため）

Twitter社が作ったフロントエンド用のパッケージマネージャです。Javaで言う Maven、 Rubyで言うgem、Perlで言うcpanのようなものです。
引用元："Bower入門(基礎編) - from scratch
grunt init

というコマンドをうつと、htdocsディレクトリと、以下に_dev（開発用ディレクトリ）と、release（リリース用ディレクトリ）が生成されます。

_libから必要なファイルをコピー（gruntfile.coffeeで自動化した方が楽かも）します。

ここで、やっと

grunt

をうって、htdocs/_dev以下のファイルで開発開始。

ローカルサーバー起動、_scss、_coffeeディレクトリ以下のファイルを監視、編集されたら、それぞれhtdocs/_dev以下のcss、jsディレクトリにコンパイルして、ブラウザがライブリロードされます。（詳細は、gruntfile.coffeeを紐解いてください）

開発が完了したら、最終的に下記のコマンドをうちます。

grunt release

すると、htdocs/release以下に必要最低限のディレクトリとファイル構成でミニファイ＆コンパイルされます。

すごい！かっこいい！

参考："Bower入門(基礎編) - from scratch
参考："HTML5 Boilerplate, Initializrをこれから使う人が押さえるべき5つの原則 | ゆっくりと…

「攻めすぎコーディング環境」については、基本的には、Gruntを使ったもろもろの自動化で、まだ理解できないことも多々ありますけど、開発スタートラインに立つまでの作業コストをかなり下げれる、というところが肝なので、gruntfile.js（今回は.coffeeですけど）ファイルを紐解いて随時カスタマイズさえできれば、完璧に理解するよりはその分、他のところの理解に注力したほうが良いかな、と思っています。

例えるなら、サッカーするためにすごい良い芝生を育てているようなものなので、それでサッカーまったくしてないとか、本末転倒じゃないですか。

ということで、Sass/Compassを軽くさわってみることになりました。

Sass(SCSS)/Compassとは

今回勉強会でやるまで、「SASS」「SCSS」「Compass」という3つのワードと、それぞれの意味やできることの切り分けがよくわかっていなかったのですが、だいぶわかりました。

今回の勉強会で作成した環境を元にこねくり回したファイルの、htdocs/dev/files/scss以下の構成をみてもらうと、アンダースコアの付いているSCSSファイルが3つあります（開発時に編集するのはこの_がついているSCSSファイルです）。

JsPractice/005/htdocs/dev/files/scss

それぞれの役割は

_global_var.scss
Sassの変数を書く

_layout.scss
全体のレイアウトに関わるCSSを書く

_parts.scss
パーツやモジュールに関わるCSSを書く

となっていますが、これに関しては、まだベストプラクティスではありません。

ちなみに_がついているSCSSファイルのことをSassのパーシャルファイルと呼ぶらしいですが、実際に読み込むときには、アンダースコアと拡張子は省略することが出来ます。

main.scss
「Author's custom styles」というコメントのところで各パーシャルファイルを読み込んでいます。

normalize.scss
ブラウザのデフォルトをあわせるcss

参考；"なぜリセットではなく Normalize.css を使うのか

SassとSCSSファイルの違いについて

CSSにはできないけどSassならできることは、主に以下の4つです。Sassの4つの特徴として見てもらえればいいかと思います。

1.セレクタの入れ子
2.セレクタの継承
3.変数
4.Mixin

引用元："CSSの常識が変わる！「Compass」の基礎から応用まで！ | 株式会社LIG

とあるように、Sassはこれら4つのことを可能にしてくれる機能で、SCSSはそれを書く文法やファイルという認識を勝手に決めてしまった方が理解しやすい気がします。

ここで変にSassとSCSSの2種類の文法で書けて、Sassの文法を使いたければ、ファイルの拡張子を.sassに、とかいう話が出てくると、「SassがSCSSでSCSSがSassで〜」と、とても混乱します。

SassにはSASS記法（拡張子を.sassにする）とSCSS記法（拡張子を.scssにする）の違いがある。もともと、SassはSASS記法を採用していたが、Sass 3.0からCSSの記述の仕方に近いSCSS（Sassy CSS）記法でも記述できるようになった。
引用元："爆捗！ WordPressテーマ作成ショートカット（3）：CSSコーディングで泣かないためのSassの基礎知識と10の利点 (1/3) - ＠IT

イメージ的にいうと、SASS記法のほうが、パッと見わかりにくいので、あまり普及しなかったけど、SCSS記法ができてからは、かなりわかりやすくなって、けっこう普及しはじめた、という感じのような気がします。

参考："Sass、そしてSassy CSS (SCSS)

Compassとは

Sassだけでも、式や関数・変数・制御構文・ループが使えて、かなり高機能で使いこなせるか微妙なところなのですが、それにさらに機能追加できるプラグインみたいなものが「Compass」と理解しています。

例えば、

@import "compass";

div {
    @include box-shadow( 0 0 10px #a82f34);
}

と書くと、moz-とかweb-kitとかがついたり、CSS3がクロスブラウザ対応でコンパイルされます。

他にもCSSスプライト自動生成できたり、いろいろ便利な機能があるみたいですが、それは各自で自習、ということになりました。

参考："CSSの常識が変わる！「Compass」の基礎から応用まで！ | 株式会社LIG

最後にTips

Sassで関数とかが入り組んでくると、書いた本人以外まったくわからないCSSとかが大量に発生することが想定されます。そこで、コメントが必須になってくるのですが、下記のような違いがありますので、使い分けて読みやすいコードを書きましょう。

// コメント

SASSファイルでのみ表示されるので、わかりにくいところはこれでコメントする。

/* コメント */

コンパイルしても出るので、公式のコメントはこれで書く。

第2部「発表プレゼン」

今回から勉強会とは別に、自分が調べたことや、最近感じていることや、なんか発表したいことがあったら各自で準備して発表するような時間をつくってみました。

個人的に、「プレゼン力」はこれからけっこう重要なスキルだと思っているので、そういうのを特別なことじゃなくて、さくっと日常的にやるような感じにしていきたいと思っています。

1.はじめてのSVGアニメーション by sukceson

SVGをつかって、うさぎのイラストを描画するデモを見せて軽く説明してもらいました。以外と簡単だけと動かないブラウザがあったりとか、重さとか、やっぱりまだ課題が多いみたいです。

2. UIデザイナー不要論について by nakagaw

少し前にプチ炎上した「UIデザイナー不要説について」関連が、自分なりに最近考えていることと近い話だったので、交えて言うつもりだったけど、結局何が言いたいのかわからなくなって、プレゼンってむずかしいと思いました。

一応、発表資料を貼ってみます。

これからのWebデザイナーは、スマートフォンがメインになってきて装飾的なデザインの領域が狭くなってくるし、ウェブに縛られない広告全般やるか、ウェブに絞ってUI全般に関わっていくかどちらかの路線を想定しておかないと、かなりキツくなってくると感じていて、そういうことを言いたかったんですけど、下手に資料とかにまとめだすとなんかUIデザインのプロセス論みたいな話になってしまいました（汗）

懇親鍋

水炊きをおいしくいただきました。 場所を提供してくださったod-&tkppp家ありがとうございました。