CSS Radar | Little Books For Front End Developers

ウェブデベロッパのための英語

はじめに

ウェブ界隈で仕事をしているとどうしても逃れられないのが英語。
ウェブが英語圏を中心に生み出されたからという理由だけではない。インターネットの共通言語が英語なのだ。

ここでは英語を話すことができるようになる魔法の教材を売ったりはしない。
英語を読むためのちょっとしたコツを共有する。

断っておくが、私は英語を留学することで話すことができるようになり、読むことも、書くことも、最近では翻訳すること、逐次であれば通訳もある程度であればできるが、ものすごく高いTOIECのスコアを誇るとか、誰でも知ってる進学校を卒業したとか、よもやアメリカの有名大学を卒業したということもない。もちろん、教育学部を卒業し、英語を毎日教えているということもない。
ここで紹介するのはあくまでも私の経験から得たコツ。

はじめの一歩

わかる単語だけで文章を読んでしまう。そしてわからない単語は辞書を引く。
多くの人はわからない単語をがあるから、とそこで一旦読むことをとめてしまう。

まずは文章の流れを追うこと。意味が分かるかは二の次でいい。

Many years ago the great British explorer George Mallory, who was to die on Mount Everest, was asked why did he want to climb it. He said, “Because it is there.”
Well, space is there, and we’re going to climb it, and the moon and the planets are there, and new hopes for knowledge and peace are there. And, therefore, as we set sail we ask God’s blessing on the most hazardous and dangerous and greatest adventure on which man has ever embarked.

これはJohn F Kennedyが1932年、9月12日にRice Universityで演説したあの有名な『Moon Speach』の一節。

まずは辞書なしにどれくらい理解できるか読んでみてほしい。

そして、簡単にすぐに引ける辞書を用意する。

私はGoogle ChromeのExtensionである英辞郎 on the WEB Proを利用している。選択した単語を右クリックから英辞郎 on the WEBの検索をしてくれる便利なツール。Pro版は月額課金なので気をつけてほしい。
Pro版の詳しい説明はこちらから

80/20の法則

大まかに言って20%くらいの単語の意味が理解できれば大体何を言っているのかわかり始める。

ではその20%の見分け方について。

日本語もそうだが、英語にももちろん文章構造がある。
文章構造をミクロで見るとすべては1文。つまり文の始まりからピリオドまでがその範囲になる。
人は単語だけでは情報を理解することができない。
1000014という数字だけみて、国会議事堂の郵便番号だとピンとこないのと同じことだ。

まずは文そのものを見るくせをつける。
その1文を全体で見渡して文における主人公とそのアクションを見つけ出す。
シンプルな文章であれば必ずその2つが存在する。
受験的な英語ではそれらを巧妙に隠したりするが、実際の文章はそれほどややこしい構造にはなっていない。

Many years ago the great British explorer George Mallory, who was to die on Mount Everest, was asked why did he want to climb it.
He said, “Because it is there.”

ここでは2つの文を例にしてみてみよう。(それぞれの文にはつながりがあるので)

この2文における主人公はGeorge Mallory。
そして彼のアクションはsaid, “Because it is there.”

George Malloryが誰であろうと、なぜならそこにあるから、と言ったことがわかる。

実はこの文章は短い割にすこしややこしくて主人公はどうやらメインのアクション以前にそこにたどり着くために必要なサブアクションがあるらしい。主人公とそのアクションだけで意味をなさない場合は、そのアクションを引き起こすためのきっかけが必要になる。

今回でいうと、was asked why did he want to climb itがそれにあたる。細かく言うと、was askedがサブアクション。何かを聞かれたわけで、その何かがその後に続いている。

何故彼はそれに登るのか、と聞かれた様子をつかんだだろうか？

それってなんだ。とその前を見てみると、Mount Everestという著名な山があるしそれ以外にモノは文章に出てこないので、it == Mount Everestであることがわかるだろう。

あとの単語はわからなくてもいいし、調べる必要もない。

文章にして書くと非常に長いプロセスのように思うかもしれないが実際にはそれほどかからない。ある程度文章を読むことに(日本語でも、英語でも)慣れていればこの2文なら30秒もかからないでそこまでたどり着くだろう。

森を見て、木を見ない

知っている単語の数は多ければ多いほど調べるという時間を削減できるから英語を読むのにあたっては知らないよりは知っておいたほうがいい。
しかし、単語だけを無用に覚えるのはよくない。

生きている文章の中で単語を覚える癖を付けるといいだろう。
実際に読んでいる文章ごと単語を覚えてしまうということだ。

日本語とは違って英語はルールが多い。
ペアや3単語1チームとかで意味を生むことが多い。だから文章で単語を覚えてしまった方が効率的だ。よく言うところの熟語と呼ばれるやつだ(私はなんでもかんでも熟語としてそれを覚えようとするのはよろしくないと思っている)。

単語の意味もgetという単語を調べたときの辞書に書いてある意味すべてをおぼえてるのではなく、getという単語がもつそのものの意味を理解するようにする。
原義にフォーカスして単語を覚えるというのは私だけが提唱している方法論ではなく、語源中心英単語辞典という辞典が発売されていることからも一般的な手法であることがわかる。
原義を理解することで熟語とよばれる単語達チームの達も自然に意味が分かるようになってくる。(だから熟語として覚えるのはあまり意味がない)
英語も漢字と同じくパーツで意味がわかることが多い。語源を中心に単語を覚えていくとこのパーツを見破ることができるようになる。
この方式の感覚をつかむとボキャブラリが飛躍的に増える。

単語だけに捕われず文章全体でどういう意味になるのかを理解するようにする。単語も意味だけに捕われず、単語が持つ方向性を理解するようにする。

木を見て、森を見ずは英語においても落とし穴で、その反対に解決がある。

ならうより慣れろ

1日1記事。長さは関係ない。
とにかく読むことだけが英語を読めるようになる最終的なコツ。

続けるためには2つの要素が必要だ。
1つはなんであれ読むだけの価値があること。
もう１つは内容をある程度知っていること。

ウェブデベロップメントの世界で生きている人にとってこの2点を満たすのは難しいことではない。プロフェッショナルな文章で毎日のようにすばらしい記事を提供しているメディアが非常に多く、特にチュートリアル系の記事だと見たことがあるスニペットが大部分を占めるのである程度は内容が理解できるはず。

ほんの一例ながら上記の3メディアは非常にわかりやすい単語で書かれており、文法チェックも通しているので変な部分で悩まなくても済む。
この3メディアをRSSに入れておけば確実に毎日何かしら自分の役に立つ情報を得ることもできる。
Twitterは文にならない場合も多いし、制限による特殊な表現、そして会話的な文体が多いのでそれほどおすすめはできない。

私が毎日読んでいる記事達はフロントエンドデベロッパのためのフィードで大部分を共有している。
メディアによっては科学技術書のような体裁で書かれている記事もあるが、大抵は平易な単語、文章で書かれているのでどのフィードもおすすめできる。

もちろん私が運営しているCSS Radar Newsletterは毎週10以上の記事を紹介しているから、週末に届くこのメールで紹介されている記事を次の週の間に読んでいけば毎日何かしら読めることになる。
辞書で引いてもわからなかった文の解釈などあればNewsletterで紹介している記事であればすべて読んでいるので気軽に聞いてほしい。

読み続けるためのツール

ウェブでもiPhoneでもiPadでも記事を読みやすい形式に変換し、オフラインでも記事を読むことを可能にするこの3ツールのうち1つは有料版を手元に持っておくことをおすすめする。
慣れるまではデスクトップのブラウザ上で辞書へのアクセスが簡単にできる環境で記事を読むほうがいいだろう。
私はすべての有料版を試したが最終的にはReadabilityを利用している。

Vim

2011-12-25 12:58:27 +0900

はじめに

Vimにおける設定ファイルである.vimrc。
私のGoogleサーチによる他者の知の結晶とも言える.vimrcはgithubにあるので、参考になれば。

.vimrc

Vimで覚えるべきポイントは大きく分けて3つ。コマンド、プラグイン、そして設定。
この記事ではその3つにVimについての情報源を追加した4つを軸にしつつ、時系列でエントリを追記する形をとることにする。
なお、プラグインを追加する際、設定も同時に行う場合が多いがその場合はプラグインのエントリに記述する。また同様に覚えたコマンドをより簡単に呼び出すための設定もコマンドのエントリに記述する。

私のVimに対するアプローチは、Ruby on RailsとjQueryのコアメンバであるYehuda Katz氏の記事、Everyone Who Tried to Convince Me to use Vim was Wrongと同じで、始めからVimのやり方に合わせるのではなくマウスを使ったって、Control + Sで保存したって、別にかまわないと思っている。

私にとってVimはフィロソフィーではなく、あくまでもツールである。
便利に使えるからこそのツールでエンドユーザはその壮大な設計思想など気にする必要はない。自分のペースで自分らしく使いこなす事が真の効率化なのだから。

コマンド

ファイルを分割ウィンドウで開く

高度なテキストエディタには必ずと言っていいほど存在するファイルを上下、あるいは左右で分割して表示する方法。
私はCSSファイルは同じ記述は繰り返さないように最大の努力をしているが、HTMLファイルは同じような記述で書けるように最大限の努力をしている。
そんな際に重宝するのがこのコマンド。

ctrl-w s こちらは現在のファイルを左右に分割
ctrl-w v こちらは現在のファイルを上下に分割

HTML + CSSの組み合わせは大体の場合セットで開いていた方が何かと便利。そんな際は

:sp FILENAME FILENAMEを新しく左右に分割されたウィンドウにロード
:vp FILENAME FILENAMEを新しく上下に分割されたウィンドウにロード

最近はワイドなモニターが主流なので、左右で分割しても苦にならないだろうが、私は昔の人間なので上下に開くことが多い。

開く方法を紹介したからには、閉じる方法も紹介しよう。

:on は現在選択されているウィンドウのみを残して、他のウィンドウを閉じる
:q は現在選択されちえるウィンドウを閉じる

コマンドが多いなと感じる事だろうが、sはsplitの略で、vはvertical splitの略、onはonlyの略で、qはquitなので、覚えやすいはずだ。

行をソートする

:'<,'>!sort

選択行をアルファベット順に並べ替える。

まず、ソートしたい行を選択
: をタイプすると、:'<,'>'と表示される
!sortとタイプ = :'<,'>!sort

何が便利かというと、私はCSSのプロパティをアルファベット順に並べ替える(IEハックは除外するが、ここは手作業)ので重宝している。

:'<,'>!sort -u

とすると、ユニークな行だけ、つまり重複行を削除することも可能。

私の環境では日本語に置けるソートは上手く行かないが、ユニーク行を残すことはできた。

バッファにあるファイルを全部タブで開く

:tab ball

プラグイン

snipMate

色々あって利用してこなかったsnipMateに挑戦中。オリジナルのsnipMateは更新が止まっている様子なので、こちらのforkをおすすめされた。
snipMateはTextMateのスニペット機能を模したプラグイン。特定のキーワードとtabで登録したスニペットが呼び出せる。

MatchTag

MatchTagはNotePad++で使えたあの便利なHTMLタグを選ぶとセットになっているタグをハイライトしてくれるプラグイン。ずーとこれだけが気になっていたけれど、これで完璧。HTMLを生業にしている人は必携。

Prefixr

CSS3をクロスブラウザで適応するにはブラウザプリフィックス(-o-や、-webkit-など)を記述する必要がある。
Nettus+にて作成されたPrefixrというウェブツールはW3Cで現時点で発表されている記述やどのブラウザプリフィックス付きの記述1つを書いておけばボタン1つで全プリフィックスに変換してくれる強力なツール。
そのAPIを利用してvimのプラグインにしたのがこれ。

変換したい値を選択して:Prefixrとコマンドを叩けばウェブツールと同じことができる。
Vimから離れずに強力なツールが利用できるので非常に時短。

Tabular.vim

Tabular.vimは=や、:のような決まった文字を基点にツラを合わせるためのプラグイン。
読みやすいコードを目指すあまり、書いている最中でもツラを合わせないと気が済まない人には必携だ。

例えば、

#selector {
	display: inline-block;
	*display: inline;
	margin-right: 4px;
	zoom: 1;
	letter-spacing: normal;
	word-spacing: normal;
	vertical-align: top;
}

のようなCSSを

:Tab\:

とすると

#selector {
	display        : inline-block;
	*display       : inline;
	margin-right   : 4px;
	zoom           : 1;
	letter-spacing : normal;
	word-spacing   : normal;
	vertical-align : top;
}

このようになる。(環境によっては再現されない可能性がある、そんな際はBitstream Vera Sans Monoをインストールすれば見られるようになる。日本語Fontではないがプログラマ向Fontとして有名なので持っていて損はしないだろう)

nnoremap <leader>tab :Tab /:\zs

.vimrcには、上記のマッピングを追記した。例とは異なるツラの揃え方だが私はこちらのほうが好み。

godlygeek/tabular - GitHub

Gundo

Gundo.vimはVimの編集履歴のツリーをバージョンコントロールしたように見せてくれるプラグイン。
単にツリーを表示するだけではなく、そのundoの状態もプレビュできる強力なツール。

実際に動作している様を見た方が便利さがわかるので、見てみてほしい (via Vimcast)。

Pathogen

vim-pathogenはVimのプラグインをGitのsubmoduleで管理することができるプラグイン。
Vimのプラグイン管理は非常に面倒な作業の1つ。gitの使い方を覚えなければならないところが慣れるまでは大変かもしれないが、それだけの価値はある。

プラグイン(fugitive)を追加

git submodule add http://github.com/tpope/vim-fugitive.git bundle/fugitive  
# git submoduleでfugitiveをbundle/fugitiveに追加  
git submodule update --init  
# submoduleを登録して、アップデート

プラグインを削除

rm -r -f 削除するプラグインのディレクトリ (例: bundle/fugitive)  
# .gitmodulesをエディタで開いて、削除するsubmoduleの該当行を削除する  
git rm -r 削除するプラグインのディレクトリ (最後のスラッシュはいれない)  
git submodule sync

プラグインをアップデート

git submodule foreach git pull origin master

なお、pathogenを利用するためには、.vimrcに

call pathogen#runtime_append_all_bundles()
call pathogen#helptags()

と追加する必要がある。この行はfiletypeの設定以前に呼び出す必要があるため、.vimrcの最初の行に追加することをおすすめする。

tpope/vim-pathogen - GitHub

設定

タブをFirefoxのように操る

Control + Tabで次のタブへ
Control + Shift + Tabで前のタブへ
Control + tで新しいタブを作る

" keymap Firefox like tab move {
nmap <C-S-tab> :tabprevious<CR>
nmap <C-tab> :tabnext<CR>
map <C-S-tab> :tabprevious<CR>
map <C-tab> :tabnext<CR>
imap <C-S-tab> <Esc>:tabprevious<CR>i
imap <C-tab> <Esc>:tabnext<CR>i
nmap <C-t> :tabnew<CR>
imap <C-t> <Esc>:tabnew<CR>
" }

参考リンク

John Anderson ( sontek ) - Turning Vim into a modern Python IDE / VimをPython IDEとして使うための設定。Python使いではなくても参考になる(英語)
Vim Toolbox, 2010 Edition :: phly, boy, phly / 10年ほどVimを利用しているというMatthew Weier O’Phinney氏のVimについての記事(英語)
Coming Home to Vim / Steve Losh / 様々なテキストエディタからVimに落ち着いた経緯と細かい設定の解説がおすすめ(英語)
Vim Recipes / 基本から応用まで非常にシンプルでミニマムなフォーマットで丁寧に解説してくれる (英語)
Vimcasts - free screencasts about the text editor Vim / Vimのチュートリアルビデオキャスト。基本のコマンドからプラグインまで詳しく解説している(英語)
Smash Into Vim by PeepCode / Vimのチュートリアルビデオ。基本をわかりやすく解説パート1 $12 (英語)
Smash Into Vim II by PeepCode / Vimのチュートリアルビデオ。基本をわかりやすく解説パート2 $12 (英語)

Elsewhere

cssradar@twitter / 1日5件以内のウェブデザイン情報をつぶやきます
CSS Radar Newsletter / CSS Radarニュースレター。Twitterまとめ + α
Google + / どんな風に使っていくかアイデア募集中

Jekyll

Jekyllとは

Amazon S3にて静的ファイルによるウェブサイトを構築できるようになり、Amazon Web Serviceが日本リージョンを追加したことで、これからJekyllのような静的ファイルジェネレータを使ったブログが日本でも増えるのではないか。

Jekyllといえば、このCSS Radarも今年1月からwordpressを離れ、Jekyllを使ってブログを構築している。
(残念ながらまだAmazon S3でのホストはしていない)

Amazon Web Service勉強会でもJekyllとAmazon S3についての発表があった。(usteam)
そこで、今回はRubyでもコマンドラインでも初心者である私でもつくれるようになったJekyllについて紹介しよう。

開発環境の準備

JekyllはRubyで作成されているので当然ながらRubyが必要。
Rubyの導入については、ウェブデザイナのためのRubyを参考にしてほしい。

Rubyの準備ができたら、

gem install jekyll

*パーミッションがどうのというエラーがでたら、sudo gem install jekyllとすればインストールできるはず。

CSS RadarではHTMLやら、CSSなどのソースコードの表示もあるので、Pygmentsを使ってシンタックスハイライトを行っている。
Homebrewを使っているならインストールは簡単。

brew install pip && pip install pygments

としてから、Homebrewでは実行ファイルにsymlinkがつかないそうで下記を実行してsymlinkをつくる

ln -s /usr/local/Cellar/python/2.7/bin/pygmentize /usr/local/bin/pygmentize

基本フォルダ/ファイル構造と記事の作成

基本フォルダとファイルの準備

.  
|-- _config.yml (設定ファイル)  
|-- _layouts (テンプレートフォルダ)  
|   |-- default.html  
|   -- post.html  
|-- _posts (記事フォルダ、.textileか.markdownで記述)  
|   |-- 2007-10-29-why-every-programmer-should-play-nethack.textile  
|   -- 2009-04-26-barcamp-boston-4-roundup.textile  
|-- _site (HTML生成先フォルダ)  
-- index.html

アンダーバーから始まる、_layouts、_posts、_siteの3つのフォルダが必須のフォルダになる。
手前から、テンプレート保管、記事、生成先フォルダという役割がある。
_config.ymlはサイト全体に影響する設定ファイル。

必須になるのはたったこれだけというシンプル設計もJekyllの魅力の1つ。

記事の作成

Jekyllでは、記事の作成は.markdownまたは.textileという軽量マークアップ言語の文法で記述されたプレーンテキストファイルで行う。
$YEAR-$MONTH-$DATE-$TITLE.$FORMATという形式で、_postsフォルダに格納されたファイルをJekyllがプロセスしてくれる。

例えば、2011年5月14日に作成したウェブデザイナのためのRuby入門という記事なら、2011-05-22-ruby-for-designer.markdownというファイル名になる。
URLに入るタイトル名はアルファベットにしておいた方が無難だろう。2バイト文字を利用できるかは試してみた事はない。

---
layout: post
category: tool 
title: Jekyllを使ってブログをつくろう
date: 2011-06-11 13:39:28
---

記事のファイルの先頭にはYAML front matterと呼ばれる設定部分が必要になる。
今回の記事のYAML front matterが上記。
layoutでは、_layoutsに作成したテンプレート定義ファイルを設定し、
categoryにはカテゴリ、titleにはもちろんタイトル、そしてdateには更新日を記述することができる。
ここで必須になるのは、layoutとtitleの2ヶ所のみとなり、YAML front matterで設定した項目は、記事であればその記事内のテンプレート定義ファイル内の変数として利用することが可能。

テンプレートの作成

それではテンプレートの作成について見てみよう。

テンプレート定義ファイルは何の変哲もないHTMLで記述される。例外は記事ファイル内のYAML front matterに記述するlayoutの部分で利用するテンプレート名をこちらも同じく、

---
layout: post
---

というようにYAML front matterとして記述するという点と、後述するLiquidというテンプレートエンジンを利用して記事部分のレンダリングなどを行ったりするという点が異なる。　　

wordpressでもそうだが、この手のテンプレファイル系は実際にファイル自体を見た方が早い。
私が公開しているJekyll用テーマファイル、the_minimumの記事用レイアウトファイルを見ながら、次項を読んでほしい。

Liquidについて

Liquidは非常にシンプルなテンプレートエンジンで、これまでwordpressに慣れてきた場合は少し物足りなく感じるかもしれないがその代わり覚えるのは簡単。 Liquidで利用できるタグについてはこちらを参考に、
またJekyllで利用できるLiquidの拡張タグについてはこちら。

先ほどのthe_minimumのpost.htmlを見ながらLiquidテンプレートタグで必須になるもタグと、便利なタグについて紹介しよう。

{{ page.title }} <!-- 記事のYAML front matterでtitleに設定した値を取得 -->
{{ content }} <!-- 記事本文を取得 -->

必須になるのは上記2つというやはりシンプル設計。

<!-- インクルード -->
{% include header.html %} <!--
includeフォルダ内のheader.htmlファイルをインクルードする -->

<!-- ページネーション -->
{% if page.previous %}
<li class="before left"><a rel="prev" href="{{ page.previous.url }}" class="btn" title="View {{ page.previous.title }}">Before</a></li>
{% endif %}
{% if page.next %}
<li class="next right"><a rel="next" href="{{ page.next.url }}" class="btn" title="View {{ page.next.title }}">Next</a></li>
{% endif %}

インクルードはメンテナンスのために覚えておきたいタグで、
オフィシャルページにもあまり説明のないページネーションについてはもっともシンプルな例ながら利用できるタグについてはほぼ網羅しているので、カスタマイズする際の参考になれば。

_config.ymlの設定

ここで利用できる値はほぼ無限にあるもののまずはオフィシャルを参考にしてほしい。 https://github.com/mojombo/jekyll/wiki/Configuration

_config.ymlは非常に強力でオフィシャルで使えるとしている設定以外にも自由に設定を拡張できる。
こちらについても、the_minimumのファイルを参考にしてほしい。

_config.ymlで設定した値はテンプレートファイル内で、

site.項目

のように呼び出す事ができる。例えば、the_minimumで設定したGoogle Analytics用IDを格納するgaを呼び出す場合は、

site.ga

というように呼び出す事が可能。
コンスタントに利用する値、他には例えばサイトのURLやサイト自体のタイトルなどを設定しておくと管理が非常に楽になるはずだ。

ページの作り方

wordpressでは単一ページを作成しaboutページなどを作成してきたという人もいることだろう。
Jekyllでも単一ページを作成することが可能。

ページの作成方法についてもやはりシンプル設計でトップページにあたる部分index.html(トップページも単一ページ)と同じ階層にhtmlファイルを設置すればOK。
こちらはCSS Radarのファイルを覗いてみてほしい。

404ページ
バックナンバページ
少しトリッキーながらフィードファイルも生成できる atom.xml

基本以外のフォルダについて

Jekyllでは\_layouts、\_posts、_siteのみが必須のフォルダと先ほど書いたが、Liquidの説明部分で書いたようにインクルードファイルを格納する、_includeフォルダや、Jekyllに拡張機能を追加するための、_pluginsフォルダを作成することができる。アンダーバーがフォルダ名の頭にある場合、Jekyllはそれらをシステムファイルとして扱い、プロセスの際にそれらフォルダも見に行くようになっている。

アンダーバーがついていないフォルダはJekyllとしては何の処理もしないが、きちんと\_siteフォルダへ移動してくれる。
なので、CSSやJavascript、そして画像などを格納するフォルダをそれぞれ、style、script、imageというようにしてファイルを格納しておこう。

ローカル環境でプレビュー

このチュートリアル中に新たにデザインを作成しJekyll用にコーディングを完成するのは難しいと思うので、ここから先はすでに作成した私のthe_minimumをダウンロードしてから実践して見てほしい。

Jekyllではコマンドラインを利用してファイルの生成を行う。そう、デザイナには不可解な黒い画面。
黒い画面とはいえ使うコマンドは片手で数えられる程度なので問題ないし、コピペできるように記述するので是非試してみてほしい。

それではthe_minimumのダウンロードは終わっただろうか？
ターミナルを開いてthe_minimumをダウンロードしたフォルダに移動してほしい。移動はcd。

jekyll --server --auto

--serverオプションはプレビュー環境用のサーバを立ち上げ、
--autoオプションはローカルファイルが保存されるたびにファイル生成を行うオプション。

このコマンドをターミナルにて実行したら、

http://localhost:4000/

をブラウザで見るとJekyllをローカル環境で動作させた結果を見る事ができる。

Jekyllは非常に強力なのにシンプルでインクルードなど便利な機能もついてくるので使い方を工夫すればすばらしいプロトタイプ作成ツールにもなるのではないかと思って、ベースとなるテンプレートを鋭意作成中。話は少しそれたが思っていた以上に簡単だったのではないだろうか？

サーバへのアップロード

サーバへのアップロードはとても簡単。
FTPを使って、\_site内に生成されたファイル群をアップロードすればOK。

私は面倒くさがりなのでrakeを使ってrsyncでサーバとローカルファイルの同期をとっている。 rake rsync:live とするだけで指定のローカルフォルダとサーバの同期がとれるようにしてある。

rakeを使って自動化する

コマンドラインに苦手意識を持っている人も多いだろうが、rakeやant、makeのようなビルドツールは様々なタスクを自動化してくれる便利ツール。
Jekyllはrubyによって書かれているので、rakeを使っていつも行うタスクを幾つか自動化しているので紹介しよう。

新しい記事を書く / rake post:new["title","category"]

Jekyllではファイル名もルールに従って記述する必要があったり、YAML front matterの設定を毎回しなければならなかったりする。

rake post:new["title","category"]

とするだけで、titleからファイル名と記事のタイトルを生成しついでにカテゴリ名をcategoryから生成してくれる。
titleの方はURLの一部になるだけあって日本語は利用できない。結果、記事のタイトルは生成後に日本語に差し替える必要はある。

namespace :post do
  desc "Given a title as an argument, create a new post file"
  task :new, [:title, :category] do |t, args|
    filename = "#{Time.now.strftime('%Y-%m-%d')}-#{args.title.gsub(/\s/, '-').downcase}.markdown"
    path = File.join("_posts", filename)
    if File.exist? path; raise RuntimeError.new("Won't clobber #{path}"); end
    File.open(path, 'w') do |file|
      file.write <<-EOS
---
layout: post
category: #{args.category}
title: #{args.title}
date: #{Time.now.strftime('%Y-%m-%d %k:%M:%S')}
---
EOS
    end
    puts "Now open #{path} in an editor."
  end
end

Jekyllをローカル環境でプレビュー / rake preview

jekyll --auto --serverと毎回必ずタイプするのは面倒なので。

rake preview

desc "Launch preview environment"
task :preview do
  system "jekyll --auto --server"
end

rsyncを使ってサーバと同期を取る / rake rsync:live

Jekyllは静的なファイルを\_siteディレクトリに生成してくれる。
このディレクトリを丸ごとFTPでアップロードすればサイトの更新ができるというシンプルな設計。
でもどう考えても毎回FTPを使うのは面倒なので、rsyncを使ってサーバとローカルの同期を取ってしまおう。

rake rsync:dryrunはテスト用で実際には何もサーバには同期されないがどのファイルが同期されるかをチェックするためにある。
初めてrsyncする場合、正しく設定ができているのかを含めて実際のサーバ側のファイル達には影響なく実行できるのでまずはこちらでテストを。

rake rsync:live

テストが終わって無事が確認できたらこのコマンドでサーバへのアップロードが完了する。
設定の際は利用しているサーバにsshしたりするので、自分が管理者ではない場合はレンタルサーバ側に設定などを確認してほしい。

namespace :rsync do
  desc "--dry-run rsync"
    task :dryrun do
      system('rsync _site/ -ave ssh --dry-run --delete ユーザ名@ドメイン名:ディレクトリ/')
    end
  desc "rsync"
    task :live do
      system('rsync _site/ -ave ssh --delete ユーザ名@ドメイン名:ディレクトリ/')
    end
end

Elsewhere

cssradar@twitter / 1日5件以内のウェブデザイン情報をつぶやきます
CSS Radar Newsletter / CSS Radarニュースレター。Twitterまとめ + α
Google + / どんな風に使っていくかアイデア募集中

ウェブデザイナのためのRuby

Rubyはウェブデザイナに優しい

CSS Radarと名がついている割にはCSSの話があまりないなと最近になって気がついたけれど、誰も気にしちゃいないだろう。
今回はCSSやデザインからはほど遠いように思えるRubyについて。
前にも書いた気がするが私は極度の面倒くさがり。とにかく楽をするためなら、どんな苦労もいとわない。 Rubyにチャレンジしている真っ最中ながら、色々な新しい概念に触れ、色々な新しいワザを覚え、少しずつながら面倒なことを楽にすることもでき始めてきた。そこでRubyを少しだけ使い倒す方法を紹介しようと思い立った。

たまにはPhotoshopを離れて(私はあまり使いませんが)、新しいことに挑戦してみませんか？

* 私はRuby初心者ですので間違っている記述や、もっと簡単にできるのに、という部分が多々あるでしょう。そんな際は是非メールをください。
なお今回の記事はMac OSXでの話で、Windowsについてはまったく触れませんが、基本的な概念は同じです。

Rubyのインストール

Mac OS XにはRubyが標準でインストールされている。でも最新版ではなく、まれに最新版でないと動作しないプログラムもあるので最新版をインストールしておく必要がある。

MacにおけるRubyの管理は、RVM - Ruby Version Managerがおすすめ。
RVMを利用するためにはgitが必須になる。gitのインストールについてはこちらを参照してほしい。

RVMのインストール方法

ターミナルを開いて、

sudo bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)

~/.bash_profile か ~/.bashrcに

[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm" # This loads RVM into a shell session.

を追加(上記ファイルがない場合は、作成して追加)
では、RVMが正しく動作するかを確認しよう。

type rvm | head -1

とターミナルで実行してみる。

rvm is a function

と返事が返ってきたら成功。成功したらまたターミナルにて

source ~/.rvm/scripts/rvm

と実行しておこう。

rvm install 1.9.2-head

とすればruby 1.9.2-headのバージョンをインストールできる。
ちなみにRVMでインストールできるバージョンは

rvm list known

とすればリストが表示されるので表示されたパッケージをrvm installの後に記述すればそのパッケージをインストールできる。

なおRVMではバージョンごとにgemのパッケージを管理するためさっきまで使えたはずのgemがないとエラーが出る、なんて事態に遭遇したら、

ruby -v

として現在利用しているrubyのバージョンを確認してみよう。

rvm --default use 1.9.2 # とすると、1.9.2をデフォルトで利用しはじめ
rvm use system # システムにインストールされているRubyと
rvm default # デフォルト設定したRubyを切り替えることも可能

詳しくはhttps://rvm.beginrescueend.com/(英語)

Ruby Gem

RubyにはGemと呼ばれるパッケージマネージャがある。1.9系以降からはRubyの標準機能となったそうだ。
MacではGemも標準でインストールされていたと思うが記憶が確かではないので確認してほしい。

sudo gem update --system

とするとアップデートできるので試してみてほしい。

パッケージマネージャってなんだ、という点についてはUbuntuを使っていた私にはすんなり理解できたが、そうでもない人が多いのでMacでいうところの、macportやfink、homebrewみたいなライブラリ集積地みたいなものだと覚えておけばいいはず。 *Homebrewについては、こちらの記事で紹介したので参考にしてほしい。

gem install PACKAGENAME

としてパッケージをインストールできる。
例えば、

gem install rake

とすると、Ruby版make(ビルドツール)であるrakeをインストールできる。

ウェブデザイナにおすすめのパッケージ

CSS Sprite

CSSスプライトはパフォーマンス向上のためには必須になるテクニックだが、作成するのも、管理するのも、メンテナンスするのもとても面倒。ある特定のディレクトリに画像を入れて自動でスプライト画像を作成しCSSもあわせて作ってくれたら。を叶えるプログラムがRubyにある。

merbjedi / sprite

インストール

rmagickgemが必要になるのでまずはこのgemをインストール。

gem install rmagick #私はこのコマンドではエラーになったので、下記を実行してから再度チャレンジした

# エラーになった場合は
sudo brew install libxml2
sudo brew install ImageMagick
# を実行してから、上記を実行してほしい。なお、homebrewを利用している場合の例

そしてspriteのgemをインストール

gem sources -a http://gemcutter.org
gem install sprite

使い方

public/
  images/
    sprites/
      black-icons/
        stop.png
        go.png
        back.png
        forward.png

      weather/
        sunny.gif
        rainy.gif
        cloudy.gif

というようなディレクトリ構造を例とすると、 publicにて

sprite

というコマンドを実行すると

public/
  stylesheets/
    sprites.css
  images/
    sprites/
      black-icons.png
      weather.png

というファイルを生成する。

.sprites.blue-stars-small {
  background: url('/images/icons/blue-stars/small.png') no-repeat 0px 0px;
  width: 12px;
  height: 6px;
}
.sprites.blue-stars-medium {
  background: url('/images/icons/blue-stars/medium.png') no-repeat 0px 6px;
  width: 30px;
  height: 15px;
}
.sprites.blue-stars-large {
  background: url('/images/icons/blue-stars/large.png') no-repeat 0px 21px;
  width: 60px;
  height: 30px;
}
.sprites.blue-stars-xlarge {
  background: url('/images/icons/blue-stars/xlarge.png') no-repeat 0px 96px;
  width: 100px;
  height: 75px;
}

というようなスタイルを書き出してくれる。
sassのmixinも利用できるようで設定も変更できる。

詳しくはこちら(英語)。

SASS/LESS

LESSは今ではnode.jsプロジェクトとして生まれ変わったが最新版ではないものの、gemからインストールはできる。 SASSについては先日1年ぶりほどのアップデートがありアクティブにRubyプロジェクトとして成長している。

ちなみにSASSではLemonadeというパッケージを利用してCSS Spriteの自動化を行うこともできる。

LESSについての説明はLESS: CSSをよりシンプルに、パワフルにを参考にしてほしい。

インストール

gem install less #LESS
gem install sass #SASS

Juicer

リクエスト回数を減らすためには、CSS/JSの呼び出しは最小にしておく必要がある。
が、CSSもJSもメンテナンス性を考えればたくさんのファイルになってしまうのが常。
この矛盾を解決するためのプログラムがJuicer。

Juicerは、YUI Compressorを利用してCSS/JSを圧縮した上で、CSSであれば@importを使ってファイルを結合してくれ、JSであれば、

/**
 * @depends prototype.js
 * @depends widgets/lightbox.js
 */

というコメントを使ってファイルの結合を行うことが可能。
CSSはmaster.cssというファイルに@importのみを記述してJSもmaster.jsというファイルにコメント文だけ記述している。

実行すると、それぞれmaster.min.css、master.min.jsというファイルを書き出してくれる。

使い方はとても簡単。

juicer merge --force master.css # CSS --forceはmaster.min.cssが存在しても上書きを強制
juicer merge -i --force master.js #JS -iはエラーを無視して圧縮/結合を実行するオプション

ついでに、

h1 { background: url(/somepath/someimage.png?embed=true); }
/* ?embed=trueを追加する */

とすると、画像をdata-urlに変換してくれる。

juicer merge --force master.css --embed-images data_uri

のように実行すればOK。

インストール

gem install juicer # Juicerをインストール
juicer install yui_compressor # YUI compressorをインストール
juicer install closure_compiler # Google Closure Compilerをインストール
juicer install jslint # JsLintをインストール

CSS Redundancy Checker

何年か前にウェブツールとして同名のツールがあり、ある日使えなくなってしまった。 CSS Redundancy Checkerは、あるHTML郡で使われていないスタイルルールをリストアップしてくれるという強力なツール。
フロントエンドデベロッパのタスクのほとんどはIteration、日本語にすると反復することが多く、その反復がよりよいモノを生み出すための最も大事な原動力となる。
しかしその副産物として使っていないスタイルルールであふれかえって、何を消したらまずいのかもはやわからない状態になってしまう。
その問題を解決するのがこのツールというわけだ。

使い方

ruby css-redundancy-checker.rb [CSSファイル名] [HTMLファイルディレクトリ または URLを一行ずつ記述した.txt]

とするだけ。CSSを分割して管理している場合はJuicerで結合してから実行するといいだろう。もちろんある特定のCSSファイルをチェックしたい場合は個別に指定すればOK。

インストール

sudo gem install hpricot # hpricotをインストール、必須
svn checkout http://css-redundancy-checker.googlecode.com/svn/trunk/ css-redundancy-checker
# svnをインストールしていない場合は、sudo brew install svnとしてから

css-redundancy-checker.rbという名前の通りこのスクリプトは単純な1ファイル。
なので実行する際はインストールしたディレクトリに移動してから実行する必要がある。

Rake

Rakeはそれ自体ではなにもしないが非常に強力なツール。
ビルドツールとして誕生したRakeのはずだが、私はビルドツールがなんのことかも完璧には理解できない。
要するに、A)の次はB)を実行し、C)を実行するのは、A)を実行する必要がある。
というなプロセスをrubyを使って行うことができる。いわばエディタなどにあるマクロみたいな存在。

ここまで紹介してきたツール群はもちろんのこと、Rakeを使って

OptiPNGを使ってPNG画像の最適化
JPEGtranを使ってJPEG画像の最適化 (Macへのインストール方法は、こちらを参照(英語))
spriteを使ってスプライト画像/CSSを作成
juicerを使って、CSS/JSの圧縮/結合
htmlcompressorを使ってHTMLの最適化

このプロセスをrake taskとして作成すれば、rake タスク名とするだけで一気に終了できる。

rsyncやftpなども合わせるとファイルアップロードまで自動化できる。

Rakeのチュートリアル

などが参考になるだろう。もちろん全部英語の文書なので、CSS Radarの癖にRakeの詳しい説明を知りたい方は、Twitter@cssradarにてリクエストしてほしい。
私も覚えたてなので全部の質問には答えることができるかわからないが。

まとめ

ウェブデザイナ/フロントエンドデベロッパのタスクは多岐に渡る。
Adobe Suitesを使いこなし、HTML/CSS/JSを駆使し、ユーザビリティ/アクセシビリティに考慮し、行動心理学を応用しつつ、ウェブサイトをユーザに届ける。
その上、プログラマの領分であるはずのRubyにまで手を出す。
それもすべて時間を生み出すための技術。
その時間がよりよいサイトを生み出すための原動力だから。
新しいことへの出会いはいつだってインスピレーションへ続く近道だと信じているので、是非チャレンジしてほしい。
もし今回紹介しなかった便利なスクリプトなどご存知でしたら、是非教えてください。

Elsewhere

cssradar@twitter / 1日5件以内のウェブデザイン情報をつぶやきます
CSS Radar Newsletter / CSS Radarニュースレター。Twitterまとめ + α
Google + / どんな風に使っていくかアイデア募集中

インブラウザデザイン

2011-10-29 22:37:19

インブラウザデザインとは

長い間、Adobe Photoshopはウェブデザインのデファクトアプリとして君臨してきた。もちろん今も私のMac MiniにCS4がインストールされている。

しかし、個人プロジェクトはもちろんすでに会社のプロジェクトでも私はPhotoshopを卒業しつつある。

ブラウザとお気に入りのエディタ。そしてCSS3があればPhotoshopを使わなくてもデザインができる。

Hardboiled Web Designの作者であるAndy ClarkeはI don’t care about Responsive Web Designにて、

Today, anything that’s fixed and unresponsive isn’t web design, it’s something else. If you don’t embrace the inherent fluidity of the web, you’re not a web designer, you’re something else. Web design is responsive design, Responsive Web Design is web design, done right.

とすら書いているが、レスポンシブウェブデザインはPhotoshopで作ることはとても難しい。レスポンシブデザインこそが、紙的な発想から離れることができなかったウェブデザインの新しい時代の旗手。

ブラウザでデザインをするということ。
その際の実際のプロセスと便利なツール、そして注意点について紹介しよう。

インブラウザデザインのプロセス

アイデアの集約と大まかなレイアウトの決定

ワイヤフレームは、ブラウザでデザインを行う際には確実に必要なプロセス。
Photoshopでのデザインであればワイヤフレームの有効性はPhotoshopの習熟度によっては低くなることもあるかもしれないが、今回はそうはいかない。
ワイヤフレームだって、スタティックな画像じゃないかと思うかも知れないし、それは事実だ。

それでも以前書いたように、ワイヤフレームはアイデアを形にする最初のステップであり、要素がどこにどんな風に配置されるのかを集約しレイアウトするのにはぴったりのツールだ。

このステップで利用するツール

Balsamiq

ベースになるHTMLとCSSの作成

このステップは基礎になるHTMLを作っていく。CSSリセットやベースのCSSそしてヘッダやフッタ、ボディになる部分を作成する。

自分でよく使うテンプレートを持っておくことで大幅に時間を短縮できる部分だ。
私はHTML5 BoilerplateにグリッドやOOCSSのモジュールを組み込むカスタマイズを施し、よく利用するCSSのスタイルをLESSのミックスインとして用意している。

このステップで利用するツール

レイアウト

まずはグリッドを決めてしまう。
Photoshopでのステップだとグリッドを使ったりガイドを使ったりするのがこのステップ。この時点でグリッドがレスポンシブデザインに対応しているとあとで楽に作業ができる。
もちろん慣れないうちは大変だし、リデザインの場合はそうもいかないこともあるだろう。

Griddle.itを使って簡単にCSSでガイドを作成する方法を紹介しよう。

Griddle.itは

http://griddle.it/[全体幅]-[コラム数]-[ガターサイズ]

という指定で、グリッド画像を生成してくれる。例えば、こちらを開いてみてほしい。幅960px 12コラム 30pxのガター
さらにバーティカルリズム用ガイドになる横線のグリッドも追加できる。幅960px 12コラム 30pxのガター + 30pxの横線グリッド
ここまで設計したデザインはなかなか日本では見かけないが基礎が強固であればあるほど、表層のデザインは自由度が増すので、是非。

自動で画像を生成してくれるのでグリッドパターンが確定したら、

body {
  background: url(http://griddle.it/960-12-30) repeat-y center top;
}

背景画像に読み込んでしまえばOK。

レスポンシブデザインに対応したいという方は私のおすすめフレームワークLess Frameworkを利用してベース(グリッドの部分だけ利用するのがおすすめ)のCSSを作成し、Less Frameworkに対応した実際にグリッドがウィンドウのサイズに合わせて変更されるこのJavaScriptを組み込むと楽にできる。

すでに自分のレスポンシブデザインのベースがあるという場合はGriddle.itを利用して、media queriesで呼び出す画像を切り替えればOK。

開発時にJSを呼び出しても問題ないという場合には、 The Heads-Up Gridがおすすめだ。縦横のグリッドを自由に設定できる上にウィンドウサイズを検知してレスポンシブウェブデザイン用にサイズを変更してくれる。

また、HTML5 Boilerplateをベースに選択していて、Less Frameworkなどを組み込むのが面倒な場合はAndy Clerkeの320 and upを利用するといいだろう。(モバイルファーストという概念で作られているので、若干注意が必要)

さらに、レスポンシブウェブデザインでは現在のウィンドウの幅がどのサイズにあたるのかわかりづらいとちょっと面倒なので、 Window Size bookmarklet to test/debug CSS3 Media Queriesのブックマークレットを利用すれば、ウィンドウサイズを知らせてくれるので非常に便利。

ちなみにこの後のステップではCSSやHTMLを保存し、ブラウザをリフレッシュして変更を確認し〜を繰り返す。より時短を目指すため、Live.jsを活用することをおすすめする。
このJavaScriptはファイルの保存を検知してブラウザのリロードを行わず、変更を反映するという夢のようなツール。
ブラウザでデザインしていなくて、コーディングしている時にかなり役に立つ強力なJavaScript。

JSを追加したりプロダクション用に削除したりと面倒だなと感じたら、
LiveReloadというMac用のアプリがおすすめだ。ブラウザの拡張機能とこのアプリさえあれば、監視するフォルダを登録したらファイルを保存したらブラウザをリロードしてくれる。
ついでに、LESSやSASSなどを利用していても自動的にCSSに変換してくれる強力なアプリ。

このステップで利用するツール

Griddle.it
Window Size bookmarklet to test/debug CSS3 Media Queries
The Heads-Up Grid
Live.js
LiveReload (Macのみ)
Less Framework + Less Grid (Less Framework利用時)
320 and up (HTML5 Boilerplate利用時)

残りのステップは、デザインしていくだけ

コンテンツなしにデザインすることができないのはPhotoshopであろうと、ブラウザでのデザインでも同じ。だが、画像素材や原稿がまだの場合は想定している画像のサイズや原稿の分量などを伝えるというステップもあってもいいかも知れない。 (実際に私の職場では非常によくある)

フレキシビリティこそがブラウザでデザインすることのもっとも優れた点なので活用していこう。

ダミー画像の生成なら、lorempixumが数あるダミー生成ツールのなかでももっとも優れている。
グレーを始めとする単色だけでなく、サイズの指定はもちろん、画像のジャンルの指定すらできる優れものだ。

プロトタイプとして素材の提供者にブラウザで確認してもらうには十分こと足りるだろう。
日本語では海外のようなLorem Ipsumテキストがないのでどうしてもダミー原稿が欲しい場合は、私はダミーテキストジェネレータを利用している。

インブラウザデザインをより加速するオンラインツール達

CSS3を活用してブラウザでデザインしていく上で欠かすことのできないツール群を紹介しよう。

CSS3 Please! The Cross-Browser CSS3 Rule Generator

Paul Irish氏によるCSS3 Please!はCSS3のプロパティを実際に値を変え、その効果を確認しながら簡単にコピペすることができるウェブツール。
border-radius、box-shadow、linear-gradient、rgba、transform、transitionなど、ブラウザプリフィックス付きで非常に便利。

NoisePNG - Generate noisy PNG-images with alpha-transparency

NoisePNGはその名の通りノイズを生成してPNGとしてダウンロードできるウェブツール。
生成されるPNGはノイズの部分だけで色はRGBで指定して利用できるので非常に拡張性が高い。
その上、http://noisepng.com/100-80-5-monochrome.pngというURLで実際のデザインに簡単に組み込める。

Grained.org - Online grained gradient image generator

こちらも先ほどのNoisePNGに近いサービスだが、こちらはノイズの入ったグラデーション画像をマウスのドラッグで生成できる。

Patternify - CSS Pattern Generator

こちらはノイズではなく規則性のあるパターンを生成してくれるサービス。最大10pxx10pxのキャンバスと色、透明度も選択できるので使い慣れてくると色々なパターンを作成できる。
作成したパターンはデモ用のdata-url形式でコピーするかPNGをダウンロードできる。またパターンはURLを生成することも可能なので作ったパターンを保存することも可能。

Ultimate CSS Gradient Generator - ColorZilla.com

CSS Gradient生成ツールのデファクトスタンダード。前述のCSS3 Please!でもグラデーションは作成できるが、こちらはPhotoshopと同じようなGUIでの生成が可能。
画像からCSSを生成することもできる。

Css3 drop shadow generator

こちらはDrop ShadowをプレビューしながらCSSを生成できるツール。やはりCSS3 Please!でも同様の機能は提供されているが、こちらのほうが私には視覚的に理解しやすいし数字ではなくスライダーを動かしながら調整できるところが便利。

Prefixr

ブラウザプリフィックスをタイプするのは面倒。
このPrefixrではブラウザプリフィックスの内1つでも入力すると全ブラウザのプリフィックスとそれに対応したシンタックスを補完してくれる。
なんとAPIすら提供しているので、Vimではすでにエディタ内からこのツールが利用できる。 (mr-szymanski/prefixr - GitHub)

それぞれのサービスは他に類似サービスが沢山あるが、実際に使ってみて1番使い勝手のよいものをピックアップした。
どれも自信を持っておすすめできるので試してみてほしい。

インブラウザデザインの注意点

CSS3はIE6-8では使えないプロパティもある。全てをブラウザでデザインすることは不可能だ。
テキスチャやCSS3では表現しづらいデザインももちろんある。
Photoshopを絶対に使ってはならないということではない。
ブラウザでデザインすることはPhotoshopでページすべてのデザインを行うよりもフレキシブルだということ、そして現時点でそれを行うことが以前に比べれば格段に簡単になったことが大切な部分だと思ってほしい。

Photoshopでページすべてのデザインをしていると、カラースキームを変更するのは大変。
Photoshopでページすべてのデザインをしていると、フォントを変更するのは大変。
Photoshopでページすべてのデザインをしていると、要素の配置1つを動かしても大変。
レイヤーの管理は崩壊しちょっとした変更の依頼もストレスになる。
もちろん、先に書いたレスポンシブウェブデザインの実現も相当な時間がかかる。

インブラウザデザインではこういった部分でPhotoshopより優れている。
Photoshopがインブラウザデザインより優れている部分ももちろんある。
(私にとっては十分だが)Pixelmatorも、レイヤースタイルに対応したAcornもPhotoshopがデファクトになってきた強力な機能やユーザビリティにはまだ少し距離がある。
ここで最も大切なことはPhotoshopでのデザインプロセスにも疑問を投げかける時代が来たということ。

よりプロダクティブになることがウェブデザイナのタスクの1つでそうすることでより優れた問題解決を提案できる。作ることそのものよりどうやって問題を解決するべきか、を考える時間を作り出していくことが大切なこと。

ブラウザでデザインすること。
このプロセス、ツールセットにバージョンをつけるとしたら、1.0RCといったところだろう。
CS5.5になるほどイテレーションを繰り返しすばらしいプロダクトを提供してきたAdobe Photoshopと比べればまだまだ始まったばかり。
このプロセス/ツールセットのバージョンアップを行うのはウェブデザイナたちの役割だ。

参考リンク

Elsewhere

cssradar@twitter / 1日5件以内のウェブデザイン情報をつぶやきます
CSS Radar Newsletter / CSS Radarニュースレター。Twitterまとめ + α
Google + / どんな風に使っていくかアイデア募集中

パフォーマンス最適化

パフォーマンス最適化の意味

ハードウェアの値段が下がりネットの接続環境も高速化していく。ブラウザも高速化を競い合っている。
それでもなお、GoogleもYahoo!、FacebookもTwitterもページのロード時間を短縮するテクニックを生み出している。

なぜだろうか？

もちろんカスタマの満足度を上げ、終局的には売り上げに貢献するからだ。

GoogleもYahoo!も世界で1位2位を争うほどすばらしいデータセンタを所有しているのだから早くて当たり前。なんて思っていないだろうか？ページのロード時間の80%はフロントエンドで最適化できる。バックエンドが重要ではないとは言わないが我々フロントエンドデベロッパのもっとも大切なタスクの1つがページの最適化。

ページのロード時間で失うモノ

サイト最適化ファームのStrangeloopがMashable!に寄稿した記事、Why Websites Are Slow & Why Speed Really Matters [INFOGRAPHIC] によると、

1秒のロード時間の増加で、

7%のコンバージョン
11%のPV
16%のカスタマ満足度

を失うとある。

さらに、3秒待たされると57%のカスタマはサイトから離脱しそのうち80%のユーザはそのサイトへ戻ってこず、そのうち50%がネガティブな経験を他の人にも共有する。
もっと加えると平均的にユーザは実際のロード時間より15%ほど追加でロードにかかっていると感じ、人にその話をする場合、実際のロード時間より35%遅いと伝えている。

3クリックルールにはもう意味がないかも知れないが3秒ルールは実際に存在する。

Steve Soudersの教え

元Yahoo!のパフォーマンス担当責任者であり、現在はGoogleで働くSteve SoudersのハイパフォーマンスWebサイトはこのトピックの中で確実に読んでおくべき本。彼が作り出した14のルールはYahoo!のYSlowのチェック項目にもなっているので見たことがあるはずだ。
GoogleのPageSpeedでも近しいチェック項目を持っているのでそれぞれの項目が何を意味して、それがどうしてページロード時間の最適化につながるかについて覚えておくことをおすすめする。

最適化チェックツール

Yahoo! YSlow for Firebug
Page Speed

先ほどもその名前が出てきたがこの2つは絶対に必要なブラウザ拡張。Firefox+Firebugでも利用できるが今では両方ともChromeでも動作する。Page Speedはオンラインバージョンも公開されモバイルでもチェックができる。
GTmetrix

こちらはYSlowとPage Speedを同時にチェックするオンラインツール。ブックマークレットも配布されている。
loads.in

せっかく最適化しても結果をコンスタントなテスト環境でチェックできなければ意味がない。
Loads.inでは珍しく日本のサーバからのロード時間をテストしてくれる。ついでにブラウザ別の結果も見ることができるのでおすすめのオンラインツール。

最適化ツール

CSSスプライト

オンラインツール: CSS Sprite Generator
Ruby(ターミナルから利用): merbjedi/sprite - GitHub
SASS連携: Generate CSS Sprites on the Fly with Lemonade

JavaScriptとCSSの結合と縮小化

Ruby(ターミナルから利用): Juicer - a CSS and JavaScript packaging tool / Ruby - cjohansen.no
オンラインツール (CSSとJS): Online YUI Compressor
オンラインツール (CSS): Clean CSS
オンラインツール (JS): Closure Compiler Service

画像最適化

Mac OS X GUI: ImageOptim – a PNG/JPEG/GIF optimizer for Mac OS X 　 ### バラバラのツールは必要ない？

そんなにたくさん上げられても使いこなすまで時間がかかりそうだと思ったら、以前紹介した
 HTML5 Boilerplateのビルドスクリプトを利用することをおすすめする。
CSSスプライト以外はHTML5 Boilerplateのビルドスクリプトでも行える。

.htaccess(サーバ側で設定できるなら、その方がベター)

.htaccess on HTML5 Boilerplate

HTML5 Boilerplateの.htaccessを利用するだけでYSlowのスコアが15ポイントはあがるのではないかと思うほどすばらしいファイル。

スピードについて

つい先日FireFox4がリリースされたがChromeのスピードには及ばない。SafariもOperaも起動速度に関してはかなり気を使っているしページのレンダリングに関しても同様。
毎日確実に利用するものだからこそスピードが大事。ということだろう。

ウェブサイトも同様にスピードが大事。
Googleのページランクに関わるからでも上に書いた実質的なロスでもかまわない、どうにかしてページロード速度の最適化が大切であるかをステークホルダと共有し実践してほしい。
もちろん個人サイトでどんな風にやっていくべきかを実験するのもいいだろう。

私自身かなり気を使って最適化をしている。このサイトは海外のサーバなので日本では少しレスポンスが遅く他の個人サイトと同様Amazon S3に移行する予定だ。

すると、.htaccessが使えないのでRakeを使って自動化を行うよう調整中。 Amazonのクラウドサービスを使ってみるというのもいい経験になったしRakeによるビルド/デプロイの自動化もツールとして昇華しやすいので会社でも役に立つと思っている。

Elsewhere

cssradar@twitter / 1日5件以内のウェブデザイン情報をつぶやきます
CSS Radar Newsletter / CSS Radarニュースレター。Twitterまとめ + α
Google + / どんな風に使っていくかアイデア募集中

LESS - CSSプリプロセッサ

2012-01-18 10:57:14 +0900

時短、効率、スピードアップのためのはじめてのLESS入門 @ SwapSkills

SwapSkillsにてLESSについての勉強会にて2012年2月18日（土）13:30 ～私が登壇することになりました。
この勉強会ではLESSをこれまで使ったことがない人に向けてLESSの導入の利点、欠点など(このパートはGoogleの小久保浩大郎さんが担当します)を説明し、私は後半のLESSの文法についての担当になります。
この勉強会をきっかけにLESSのページを丸ごと日本語訳したりして改めて勉強しなおしました。
LESSについて勉強しなきゃな、と思っている方はぜひこの機会にどうぞ!

CSSプリプロフェッサとは

If it ain’t broken, don’t fix it.

壊れてないなら、直す必要はない。
CSSは追加してほしい仕様はあるけど、壊れている、とまでは感じない。プログラミングの何たるかをまったく理解していなかった私にも覚えられた。

LESSやSASSに代表されるCSSプリプロセッサは、CSSにはないプログラミング言語的な機能を追加してくれるツール。
絶対に必要かというとそうでもないが、使いこなすとよりシンプルに、パワフルなスタイルシートを実現することができる。
実際に私もこのブログを始め様々な個人のプロジェクトではLESSを使い始めている。

私がSASSよりLESSを選んだのは制作者であるcloudhead氏はLESSをCSSとはまったく異なる言語にしないようにかなり気を使っているからだ。
CSSは宣言型プログラミングの流れを組む言語であり、cloudhead氏はLESSも同じ流れを保ったままで言語を拡張しようとしている。
CSSを開発する人は必ずしもプログラム言語に詳しいとは限らないからcloudhead氏のアプローチを選択した。

LESSでできること

LESSでは、変数、ミックスイン、入れ子ルール、名前空間、四則演算と関数などをCSSに追加することができる。
プログラミングの経験があるならそれぞれ覚えがあるだろう機能達ばかりでCSSには存在しない機能。

オフィシャルサイトに詳しく利用法については説明があるので詳細はこちら。
制作者の了承を得てオフィシャルサイトの日本語化を行ったので英語が苦手な方はこちら。

ここではLESSの基本機能とそのシンタックスについて紹介していこう。

変数

@color: #4D926F;
#header {
  color: @color;
}
h2 {
  color: @color;
}

というLESSは、

#header {
  color: #4D926F;
}
h2 {
  color: #4D926F;
}

のように解釈される。

@+変数名

で定義できる。正確には変数というよりは定数に近い使われ方をしている。

@var: red;

#page {
  @var: white;
  #header {
    color: @var; // white
  }
}

#footer {
  color: @var; // red  
}

ただしプログラミング言語と同じくスコープがあり上記のようにローカルに定義がない場合は、親ルールから定義を探しそれでもなければグローバルを探すように作られている。
このスコープに関しては変数だけではなくミックスインの定義についても同様に扱われる。

ミックスイン

こちらも実際にどのようにLESSで記述し実際にCSSでどのように解釈されるのかを見た方が早いだろう。

.bordered {
  border-top: dotted 1px black;
  border-bottom: solid 2px black;
}

というLESSで定義したミックスインを

#menu a {
  color: #111;
  .bordered;
}

にしてルールセットの中に追加すると、

#menu a {
  color: #111;
  border-top: dotted 1px black;
  border-bottom: solid 2px black;
}

CSSではこのように解釈される。

CSS3を利用する場合、まだまだ多くのベンダープリフィックスを追加しなければいけないのが現実。
そんな際にこのミックスインは威力を発揮する。
ミックスインはパラメータを渡したりデフォルトを定義することもできるので、使い回しが効く機能でもある。
詳しい説明はこちらから。

入れ子ルール

ルールセットを入れ子にすることで通常であればなんども繰り返し書かなければならないセレクタを省略できるのが入れ子ルール。

#header { color: black; }
#header .navigation {
  font-size: 12px;
}
#header .logo { 
  width: 300px; 
}
#header .logo:hover {
  text-decoration: none;
}

というCSSは、LESSでは

#header        { color: black;
  .navigation  { font-size: 12px }
  .logo        { width: 300px;
    &:hover    { text-decoration: none }
  }
}

というように記述することができる。
何度もセレクタを書かずに済むだけではなくDOMの構造とほぼ同じ構造になるし、なによりこのように記述することを覚えるとキレイにセレクタを整理する癖がつく。
なお、&:hoverという記述があるがこちらは疑似クラス(:link、:visited、:hover、:focusなど)を追加するのに活躍する。
&という結合子は、入れ子になったセレクタを子孫として扱わず親セレクタに追加することができる。
なので疑似クラスだけではなく、

.float.left {...}

というようなマルチクラスの記述にも対応できる。

名前空間

こちらは変数やミックスインをまとめる際に活用できる機能。

#bundle {
  .button () {
    display: block;
    border: 1px solid black;
    background-color: grey;
    &:hover { background-color: white }
  }

#bundleという名前空間の中に.buttonというミックスインを定義する。

#header a {
  color: orange;
  #bundle > .button;
}

このようにして呼び出すことが可能。
例では#bundleとIDをバンドル化しているが、実際にはクラス名でも要素名でもバンドル化は可能。
つまりスタイルシート内にあるすべてのミックスインは名前空間を持つことができる。

四則演算と関数

まずは演算から見ていこう。

@base: 5%;
@filler: @base * 2;
@other: @base + @filler;

color: #888 / 4;
background-color: @base-color + #111;
height: 100% / 2 + @filler;

計算機がデスクの上におかれていたりしないだろうか？私はおいてある。
ウェブデザイナには計算機を手放せない人も多いことだろう。
その必要をなくしてくれるのが演算。その名前の通り、足し算、引き算、かけ算、割り算を行うことができる。

ただの計算機とは違い色の演算もすることができる。
しかし#888 / 4の答えは予想できても、#c28381 * #fafafaはどんな色になるのかわからない。
よりわかりやすく色を操作するためにあるのが関数だ。

lighten(@color, 10%);     // @colorより10%明度が*高い*値を返します
darken(@color, 10%);      // @colorより10%明度が*低い*値を返します

saturate(@color, 10%);    // @colorに10%の彩度を*追加*した値を返します
desaturate(@color, 10%);  // @colorから10%の彩度を*削減*した値を返します

fadein(@color, 10%);      // @colorから10%透明度が*高い*値を返します
fadeout(@color, 10%);     // @colorから10%透明度が*低い*値を返します
fade(@color, 50%);        // @colorの50%の透明度を持つ値を返します

spin(@color, 10);         // @colorから10度色相が大きい値を返します
spin(@color, -10);        // @colorから10度色相が小さい値を返します

mix(@color1, @color2);    // @color1 と @color2 をミックスした値を返します

変数と演算、そして色の関数の組み合わせはスタイルシートにより明確な意味を持たせることもできる。
15pxや#fefefeは作った本人以外、もしかすると作った本人ですら2週間も経てばその意味を忘れてしまうだろう。
しかし以下の例を見てほしい、

@base-color: #fefefe;
@accent-color: #f99157;
@subtle-accent: lighten(@accent-color:, 20%);
@dark-accent: darken(@accent-color:, 20%);
@base-font-size: 16px;
@base-height: @base-font-size * 1.618;

このようにデザインの基礎になる部分を変数化して、演算や色の関数を使ってバリエーションを作るということもできる。
データに名前を付けるのが変数の本当の実力でそれぞれに名前がついていれば16pxが大事な値であるかも一目瞭然にすることもできる。

便利なミックスインのコレクション

自分がよく利用するルールのミックスインを定義しておけば飛躍的にCSSの開発はスピードアップする。
フロントエンドデベロッパやウェブデザイナはいつだって時間が足りない職種なので自分なりのコレクションを作っておくといいだろう。

Preboot.less

TwitterのBoostrapでも利用しているミックスイン/変数コレクションの先駆者

LESS by Stuff & Nonsense

Andy Clarkeも記事中に非常に便利なミックスインを紹介している。

.font-size(@font-size: 16) {
	@rem: (@font-size / 10);
	font-size: @font-size * 1px;
	font-size: ~"@rem";
}
// pixelをremに変換しつつ、remが使えない場合のフォールバックを入れる

h1 { .font-size(32); }

// CSS
// h1 {
//    font-size:32px;
//    font-size:3.2rem;
// }

また、以下のカラースキーム生成もCSSなら大変だがLESSならより自由度が高く使い回しができて便利。

@col : #468DB6;			// Base colour
@comp : spin(@col, 180);  	// Complementary colour

@Col_l1 : lighten(@col, 5%);	// Lighten base
@Col_l2 : lighten(@col, 10%);
@Col_l3 : lighten(@col, 15%);
@Col_l4 : lighten(@col, 20%);

@Col_d1 : darken(@col, 5%);	// Darken base
@Col_d2 : darken(@col, 10%);
@Col_d3 : darken(@col, 15%);
@Col_d4 : darken(@col, 20%);

@Comp_l1 : lighten(@comp, 5%);	// Lighten complementary
@Comp_l2 : lighten(@comp, 10%);
@Comp_l3 : lighten(@comp, 15%);
@Comp_l4 : lighten(@comp, 20%);

@Comp_d1 : darken(@comp, 5%);	// Darken complementary
@Comp_d2 : darken(@comp, 10%);
@Comp_d3 : darken(@comp, 15%);
@Comp_d4 : darken(@comp, 20%);

加えて、彼のモバイルファーストアプローチのBoilerplateである320 and Upに他のミックスインがあるので参考に。

LESS Elements

Preboot.lessと重複する部分も多いけれどぜひチェックしておいてほしい。

大事なことは自分で自分が使いやすいミックスイン/変数コレクションを作ること。
二度使えないコードを書かないことは大切なこと。何度も使えるコードを何度も書かないことも同じくらい大事。
D.R.Y(Don’t Repeat Yourself)はプログラミングにおける基本的なプリンシパルの1つだが、CSSではなかなか難しいのでLESSでそれを補完できるのは非常に心強い。

使い方

ここまで来てようやく使い方の説明になるが、

<link rel="stylesheet/less" type="text/css" href="styles.less">
<script src="less.js" type="text/javascript"></script>

と使い方はとても簡単。
注意してほしいのは、rel=”stylesheet/less”の部分だけ。

さらにLESS.jsを実際に呼び出している場合は、#!watchという文字列をURLの後ろにつけると、LESSファイルの保存に合わせてスタイルをしてくれる。
なお、ローカルファイルではChromeで動作しないかも知れないので、そんな場合はChromeに-allow-file-access-from-filesのパラメータを渡して起動すれば動作する。
毎回毎回リフレッシュするのは面倒な上、意外と時間の無駄なので開発中はぜひ利用してほしい。

CSSへのコンパイル

node.jsで動作するサイトでない限りはLESSの記述はCSSに展開する必要があるだろう。

node.jsを使ったサーバサイドでのコンパイル以外ではLESSファイルをCSSへコンパイルするには大きく2つの方法がある。

GUIツール
コマンドライン

GUIツールから紹介しよう。 GUIツールは大体同じ動作で、.lessファイルがあるディレクトリをツール上で指定すると自動でコンパイルしてくれる。
おそらく全部のツールで.lessファイルを保存するたびにCSSに自動でコンパイルされるので実際に呼び出すファイルはCSSで問題ない。
詳しい使い方はツールのヘルプを参照。

WinLess - Windows GUI for less.js / Windowsのネイティブアプリで無料
SimpLESS - Your LESS CSS Compiler / Win、Linux、Macで動作するAdobe Airアプリ。無料
Crunch! - The tastiest LESS editor / Win、Linux、Macで動作するAdobe Airアプリ。無料
LESS.app For Mac OS X / Macのネイティブアプリ、無料

他にも幾つかGUIツールはあるが無料のツールは知る限りこの4つ。

LESS.appを作成したBryan Jones氏はCodeKitという新しいアプリを作成していてベータ版の間は無料。LESSをCSSに変換するだけでなく、SASSやStylusにも対応し、HAML、Coffee Script、画像の最適化など様々な機能が満載の夢のようなアプリ。Macのみ。

また同じくMacのみになってしまうが、LiveReloadというアプリもLESS、SASS、Coffee Scriptを保存と同時にブラウザをアップデートしながら変換してくれる。

コマンドラインでの利用にはもちろんNode.jsが必要。
Mac、Windowsともにnode.jsからパッケージがダウンロードできるので、あとはダブルクリックするだけ。簡単。

インストールが終わったらターミナルアプリから

lessc styles.less > styles.css

とすればいいだけ。

lessc -x　styles.less > styles.css

のように、-xオプションをつけると圧縮したCSSとして展開される。

参考リンク

Elsewhere

cssradar@twitter / 1日5件以内のウェブデザイン情報をつぶやきます
CSS Radar Newsletter / CSS Radarニュースレター。Twitterまとめ + α
Google + / どんな風に使っていくかアイデア募集中

ワイヤフレーム

ワイヤフレームとは

ワイヤフレームって作ったことありますか？
ワイヤフレームはウェブページのコンテントを視覚的に表現するドキュメントの中核を担う存在。建築用語でいうところのブループリントと同じだろうか。

52 Weeks of UXによると、UXデザイナにとってなくてはならないモノであり、IAのベストフレンド、とさえある。(Wireframing is not a religion)

私が現在働いている会社にはもちろんUXデザイナという職種もないし、IAという職種もない。デザイナがその一部を担っている。
私にとってもワイヤフレームはなくてはならないツールでありベストフレンド。現在担当しているプロジェクトではこの数週間に60以上のワイヤフレームを作成している。
まだ一度もPhotoshopを開く事なく、ワイヤフレームをベースにしたプロトタイプも4ページほど作成してある。
どんな見た目になるのかはまだ誰もわからないが、どんなコンテンツがどこに必要で、どんなアクションがいつ必要なのかについては、共通の認識を持っている。これこそがワイヤフレームの強みであり、存在意義。

ワイヤフレームの使用法

見てみないとわからない。
デザイナとして働いている私自身、外部のデザイナに仕事を依頼している場合に、そんな台詞を言うことがある。

誰でもデザインについてはそれぞれの主観を持つことができる。

どこかで見てみないとわからない、という人は、レストランでも食べてみないと注文できないのか、というようなことを言っている場面に出くわしたことがあるが、では、国産イノシシのシヴュや、オーストラリア産仔羊肉のナバラン仕立てとメニューにあったら、どれくらいの人がどんな味の料理が出てくるかわかるか？
私はいまだにポワレがなんだかも覚えられないくらいはフランス料理に詳しくはないから、私には無理だ。
でも、そんな料理を饗してくれるレストランには、それらがどんな料理なのか素人にもわかるように教えてくれるその道のプロフェッショナルがいるから訊けばわかる。少なくとも想像することを手助けしてくれる。

ワイヤフレームは差異と類似を明確にするツール。 How to Get Clients to Approve Your Wireframes Every Time@UX Movementでも言及されているが、リデザイン前のデザインと、より効果的だと考えているワイヤフレームを比較することで違いを提示する。クライアントの要望に近しいデザインとの類似をワイヤフレームで提示する。この2つの比較はPhotoshopで作成した精度の高いモックアップでも可能だ。しかし、ワイヤフレームのフットワークの良さはより効率的にパターンを生み出す原動力になる。
幾つかのワイヤフレームのパターンの中で差異や類似を提示することももちろんできる。

もう1つのワイヤフレームの使用法

ワイヤフレームは思考を助けるツールでもある。思考を集約することも、拡張することも、とても自然に行うことができる。
最前この数週間で60以上のワイヤフレームを作ったと書いたけれど、その内私自身もプロジェクトメンバも納得できる状態になっているのは4枚くらいだ。
その4枚については、合わせて10回以上は繰り返して変更を加えてきている。
私が実際にワイヤフレームを作成している時間は非常に短い。Photoshopで高精度なモックアップを60枚作り、4枚を10回以上は修正する、なんてただの悪夢でしかない。人は誰でもある事柄に費やした時間に比例してその事柄に愛着を持ってしまう習性がある。
デザイナやコーダにとって修正はいつだってつらいのはそのためだ。たとえその修正が圧倒的に効果的だと思っていても、いつでも芽生えた愛着と天秤にかける自分がいる。
だからこそ素早く作成も修正も行うことができるワイヤフレームの作成方法を模索する必要がある。

またデザインは問題を解決するための手段であるとよく言われる。ワイヤフレームは問題を見つけ出す手段でもあるところが大きな違い。
迷子になっている人が、今自分がどこにいるのか把握できないのと同じく、問題を明確にできなければ解決することは不可能。その問題を浮き彫りにするためのツールとしてもワイヤフレームは有効だ。

ワイヤフレームツール

フリーのツールも、有料のツールも、画像編集アプリケーションと同じくらいの種類があるワイヤフレームツール。中には実際にクリックしたり、マウスオーバできたりとインタラクションすら簡単に作成できる高度なツールも存在する。

私が利用しているのは、Balsamiq。手書き風のワイヤフレームを簡単に作成できるAdobe Airアプリ。環境を選ばないし、ライセンス1つで自分が使用している端末なら数に制限無くインストールできる。
$79とやや高額な価格設定かと思うかも知れないが、幾つかのツールを試用してみて、マニュアルなしでも利用できる手軽さと、意外なまでに拡張性がある部分を評価して購入した。
今やBalsamiqでワイヤフレームだけではなく、ワークフローやサイトマップも作成したりもするようになりBalsamiqを使わない日はない。

多くのウェブアプリも存在するジャンルではあるが、私はブラウザで作業するのがやや苦手なのでデスクトップアプリに絞って探したが、 gomockingbirdやFirefoxのアドオンとしても動作するPencil Projectなども試してみるといいだろう。

デスクトップアプリでBalsamiqと最後まで悩んだのが、flairbuilder。こちらはbalsamiqよりも高機能で実際に動作するプロトタイプを作成できる強みがある。ただワイヤフレームアプリにおいてはシンプルさを優先した方が確実に効率的だということでBalsamiqを選択した。

もちろん使い慣れたPhotoshopやFireworksなども工夫をすれば、かなり効率的にワイヤフレームを作ることができるはずだ。

ドキュメントとしてのワイヤフレーム

37SignalsのDon’t Do Dead Documentsにて、

If a wireframe document is destined to stop and never directly become the actual design, don’t bother doing it. If the wireframe starts as a wireframe and then morphs into the actual design, go for it.

とある、
要約すると、ワイヤフレームを単純なドキュメントとして作成するならワイヤフレームの存在に意味はなく本当のデザインに変化していくなら作るべきだということ。

ドキュメンテーションはどんな職種でも必要になるアウトプットの1つだと思うが、デザイナも例外無く成果物の1つとしてドキュメントがあるだろう。ワイヤフレームはデザイナのドキュメントとしてはもっとも視覚的なドキュメントになるはずなので、ないよりはあった方がインパクトがあるかも知れないが、 37Signalsの記事で言及されているように、デザインに昇華しないワイヤフレームは単純に時間の無駄なのでその時間を追加のパターンの作成や、追加の修正に費やした方がいい。

私にとっては思考を手助けしてくれるツールの側面がまずあり、そこからデザインへの昇華は自然なフローとなっているのでワイヤフレームは飛ばすことができないタスクの1つ。

参考リンク

Elsewhere

cssradar@twitter / 1日5件以内のウェブデザイン情報をつぶやきます
CSS Radar Newsletter / CSS Radarニュースレター。Twitterまとめ + α
Google + / どんな風に使っていくかアイデア募集中

HTML5 Boilerplate

HTML5 Boilderplateとは

フロントエンドデベロッパな人たちはウェブ開発プロジェクトを始めるにあたり、HTML、CSS、JSのスケルトン(必要最小限の記述をしたファイル達)を含んだディレクトリを持っている人が多い事だろう。
私も個人のプロジェクト、仕事でのプロジェクトともに、それぞれに少しだけカスタマイズを行うだけで開発を始めることができるディレクトリを持っている。

今回紹介する(おそらくすでに紹介するまでもないほど知られているが)HTML5 BOILERPLATEは、Paul IrishとDivya Manianを中心として生み出された膨大な量の知見を詰め込んだHTML5を使ったプロジェクト用のスタートポイント。
知っての通りHTML5を使い始めるのは決して今からでも早すぎるということは決してないが、HTML5に対応するなんてまだ先、と思っていても、このHTML5 BOILERPLATEに詰め込まれたベスト中のベストプラクティスを吸収しておけば、現在のプロジェクトもより盤石にすることができるはずだ。

HTML5 Boilerplateの特筆すべき5つのポイント

Modernizr

ModernizrはJavaScriptを利用して、ブラウザでサポートしているHTML5/CSS3機能を検出し、HTMLタグ内のclassにサポート状況を出力したり、IEにおけるHTML5要素のスタイル設定行うユーティリティライブラリ。
HTML5での開発には欠かす事ができないライブラリ。
CSS

HTML5用リセットCSSをベースに、非常に強固なデフォルトスタイルと.clearfixなど便利なツールClassが用意されている。クロスブラウザ対応はIE6にも対応してあり、日本ではまだまだ現実的な対応として求められる箇所なだけに非常に便利。
また、プリント用のメディアクエリや、スマートフォン用に使えるメディアクエリの記述もされている
HTML

IEコンディショナルコメントを活用したIE用Classの生成を始めとして、HTML5の新要素を含んだ形で、かつ最小限のスケルトンとして提供されている。
JavaScript

Google CDNが落ちてもローカルからjQueryを呼び出すスニペットを始めに、ユニットテストを行いやすいような設計でJavaScriptのファイル群は用意されている。jQueryの利用を前提にして、プラグインの呼び出しを記述するファイルなどが用意されている。
パフォーマンス最適化

HTML5 Boilerplateでは、クロスブラウザ対応などはもちろんとして、パフォーマンス最適化を最も重視した構成になっている。
JSをドキュメントの最後に配置するという非常に当たり前の事から、.htaccessファイルによる最適化(gzipやファイルのキャッシュ設定など)も提供されており、少し前のバージョンからはAntを利用したビルドスクリプトを使って、ファイルの圧縮、結合、キャッシュバスタの設定、画像ファイルの最適化などを自動(コマンドは使うが)で行えるようにできるようにしている。

HTML5 Boilerplateの入手方法

http://html5boilerplate.com/から最新の安定板(1.0 RC 2011/03/11現在)をダウンロードすることができる。まずは、コメントありのファイルをダウンロードして、一通りソースコードを読んでみる事をおすすめする。非常に勉強になる事ばかり。

つい先日から、http://jp.html5boilerplate.com/日本語に翻訳されたバージョン(私が翻訳を行いました。完璧とは言いがたい訳です。誤訳やよりよい翻訳があれば、githubにて翻訳プロジェクトをクローンしていますので、フィードバックをお待ちしています）も利用できるようになっている。

また、Githubからでも入手可能なので、Gitを扱い慣れている場合はそちらから。ブランチとしてコメントのある、なしを選べる(masterがコメントあり、strippedがコメントなし)

他にも15秒でHTML5 Boilerplateをベースに必要なスターティングポイントを生成してくれるサービス、Initializrというサイトもある。
コメント、JavaScript、jQuery(圧縮するか、否かも)、Modernizrの利用、サーバ側の設定ファイル、Google Analyticsの要不要など、カスタマイズすることが可能。

ビルドスクリプトの使い方

私もAntに詳しくないのでHTML5 Boilerplateのビルドスクリプトの使い方については、IBMのデベロッパワークにお任せすることに。詳しくはこちら。

私自身はRakeに慣れてきたので、AntのビルドスクリプトをRakeに置き換えてみようかなと思っている。すでにRakeマスタな人がいたら、ぜひ本家のHTML5 BoilerplateにPull Requestを送ってくださいませ。

参考リンク

Elsewhere

cssradar@twitter / 1日5件以内のウェブデザイン情報をつぶやきます
CSS Radar Newsletter / CSS Radarニュースレター。Twitterまとめ + α
Google + / どんな風に使っていくかアイデア募集中

コマンドライン

コマンドラインについて

Terminal.appは怖い。
GUIでなんだって出来る時代にパソコンに出会った私にとっても、それは変わらない。
Macをメインで使い始める前、たっぷり3年以上もUbuntuというLinuxディストリビューションをメインで使っていた私でも、Terminalで何かをしなければならない時しか開くことはなかった。

MacVimをメインのエディタにしてから3ヶ月ほど、年明けからJekyllを使ってブログを作成しはじめた。Rubyを覚えてみようと今年から勉強中。
自分自身考えてもいなかったが、それらすべてがターミナルの便利さを教えてくれた。

MacVimでは、もちろんコマンドを実行できるが、コマンドそのものとは関係なく、インサートモードとノーマルモードの切り替えというメンタリティはGUIとCUIのメンタリティと似てる。それに覚えるのに時間はかかるかもしれないが、一旦覚えてしまうともう戻れない中毒性に近い利便性を手に入れる楽しみも覚えられた。
Jekyllはターミナルを使わなければブログの更新すら出来なくなる。基本的なコマンドはJekyllを使ううちに覚えてしまった。
Rubyはirbで実際にRubyを使って気楽に自分の書いたコードをテストしたりするのにターミナルを利用している。

ソースコードリーディングのテキストとしてお気に入りのHTML5 Boilerplateで、Build Scriptが追加され、フロントエンドデベロッパの間でも、自前のオートメーションを作ることが当たり前になってきそうな流れもある。そんなタイミングだからこそ、ターミナルを使いこなせる人になろうと、こんな時代に提言したい。

私のように家ではMacで会社ではWindowsという人も多いだろう、今回はMacについての紹介になるがきっかけさえつかんでしまえばどうにかなる。ちなみに私はWindowsではCygwinをConsoleから利用している。

まずは見た目からカスタマイズ

私はGUIアプリでも、たとえそれがいかに便利でも見た目が悪いと長続きしないタチ。本末転倒かもしれないがそんな性格がウェブデザイナとしての自分を支えていると思い込んでいる。
だからこそターミナルにも見た目を要求したい。

Visor

Visorはターミナルをショートカットキーで呼び出すことが出来るTerminal.appのヘルパ。control+controlで画面の1/3ほどのターミナル画面がスライドしてくる便利でかつ、おしゃれなツール。
MacではiTerm2というターミナル互換アプリも人気があるようで、こちらはVisorとは連動できないが、同じようにショートカットキーで呼び出すことができるオプションがある。
.bashrc(リンク先は私が利用している.bashrcファイルの一部)

デフォルトでTerminalを開くと黒い背景に白い文字。あまりにも地味なので私はもう少しだけカラフルにしている。
そのついでにGitをターミナルで使いやすくなるようにブランチ名や変更を知らせてくれるマークもカラーをつけて表示している。

ちょっとカスタマイズしてあげるだけで気持ちよく利用することができる。

Mac OSXでターミナルにgitのブランチ名を表示する方法

少し話から外れるがせっかくなのでその方法を紹介しよう。
まずはgitのオートコンプリーションを探してみよう。

/usr/local/git/contrib/completion/git-completion.bash

通常であれば、上記のようなファイルがあるはずだ。もしなければ、こちらにファイルがあるので、/usr/local/git/contrib/completion/というディレクトリにgit-completion.bashという名前で保存してほしい。

そして次は.bashrc。
MacVimを利用している人なら見覚えがある.(ドット)ファイル。.bashrcはTerminalの中で働いているBashの設定ファイル。

gistにも置いてあるが

# git settings
source /usr/local/git/contrib/completion/git-completion.bash
GIT_PS1_SHOWDIRTYSTATE=true
export PS1='\[\033[32m\]\u@\h\[\033[00m\]:\[\033[34m\]\w\[\033[31m\]$(__git_ps1)\[\033[00m\]\$ '

Git用のカスタマイズは上記の部分。こちらだけでも.bashrcファイルの最後の方に追加しておけば設定終了。
もし.bashrcファイルが見当たらないようであれば、

touch ~/.bashrc
open ~/.bashrc

として、開いたエディタに上記のスニペットを追加すればOK。

source ~/.bashrc

保存したら、上記のコマンドで変更を反映できる。

ターミナルの使い方

私自身もまだまだ基本的なコマンドしかソラでは実行できない。必要に応じてコマンドは覚えていけばいいので、自分のペースで続けていってほしい。
まずはターミナルで使える便利なショートカットキーを、そして実際にいくつかコマンドを見ていこう。

ショートカットキー

control + A / 現在のラインの一番始めに移動
control + H / 現在のラインの一番最後に移動
control + U / 現在位置より手前のラインを削除。ラインの一番最後の場合はラインを削除になる。間違ってオートコンプリートしてしまったときや癖で上カーセルを叩いてしまった場合に便利
control + C / 現在動作しているプロセスを終了する
command + T / 新しくタブを作る。
Tab / ファイル名やディレクトリ名をオートコンプリートしてくれる。先ほど設定したgitのオートコンプリートも同じキーでOK
上カーソル / ターミナルのヒストリを呼び出してくれる。

ほかにもまだまだショートカットキーはあるが、私が普段使い出来るショートカットはこんな感じだ。

コマンド

cd

Change Directoryの略。cd DIR_NAMEのように、移動したいディレクトリ名を入力する。
Tabを使ってオートコンプリートできるし。cd DIR_NAME/CHILD_DIR_NAMEというようにさらに深い階層へもいける、/の後も数文字タイプしたらきちんとオートコンプリートしてくれる。
cd ..とすれば親ディレクトリに移動、cd ~とすればルートディレクトリに移動となる。
pwd / 現在のディレクトリを表示してくれる。ふと迷子になりがちなので便利
ls

ディレクトリ内のファイル、ディレクトリを表示するコマンド。
ls DIR_NAMEとすれば、DIR_NAMEの中のファイル、ディレクトリを表示。
ls -lとすると、ファイル、ディレクトリの詳細の情報つきでリスト表示。
touch / ファイルを作成するコマンド。touch style.cssとすれば現在のディレクトリにstyle.cssを生成してくれる。
open / こちらはファイルやディレクトリを関連づけしてあるアプリで開いてくれるコマンド。
mkdir / ディレクトリを生成するコマンド。mkdir DIR_NAMEでDIR_NAMEというディレクトリを作成できる。

まだまだたくさんのコマンドがあるが、私が安心して利用できる基本コマンドはこれくらいだ。ファイルをコピーしたり、削除したりするコマンドは不安が残るので少し慣れたら使い始めるといいだろう。
とりあえずのところは、open DIR_NAMEとしてFinderを立ち上げてコピーや削除をすれば問題ない。

パッケージマネジャ

Bashだけでももちろん協力なツールではあるがせっかくだからもっとたくさん機能を追加してみたい。
RubyやPython、Javaなどコマンドラインでも使える強力なツールがあるがこれらのツールを管理するのはとても大変。そのためにパッケージマネジャが必要になってくる。

Macにはデフォルトで使えるパッケージマネジャはインストールされていない。MacPortやFink、そして今回紹介するHomebrewがMacではデファクトとされている。

Homebrewはシンプルで強力な新しい世代のパッケージマネジャ。非常に簡単にインストールできるし利用も簡単なので、初心者にはもってこいのパッケージマネジャ。
私はHomebrewでgitをインストールし直した。こちらのほうがアップデートが簡単にできるということで。

Homebrewのインストール

xcodeをインストール、Macで開発するのに当たって絶対に必要になってくるのでxcodeをインストール。Homebrewでも使う。
ruby -e "$(curl -fsSLk https://gist.github.com/raw/323731/install_homebrew.rb)"

以上でインストールが完了する。
早速インストールが終わっているか確認してみよう。

brew --version

0.7.1らしいバージョンナンバが表示されれば問題ない。
それでは早速ツールをインストールしてみよう。

brew install curl

curlはさまざまなプロトコルを用いてデータを転送するライブラリ。(by Wikipedia cURL)

brew searchとすればインストールできるツールの一覧を表示。brew listとするとインストールされているツールの一覧を表示。

英語ではあるがbrewのコマンドはこちら

ターミナルの世界へようこそ

ここまでできたらすっかりコマンド使いっぽく見える。コマンドラインになれてきたら次のステップはオートメーション。
私はRubyのRakeを使っていろいろなタスクを自動化しはじめている。
興味があれば、まずはHTML5 BoilerplateのBuild Scriptについて調べてみるといいだろう。
現時点ではHTMLを圧縮したり、CSSをコンバインして圧縮したり、Jpeg、PNGのファイルサイズを最適化したりと実に様々なフロントエンドなタスクを自動化している。HTML5 Boilerplateではantというビルドツールを活用している。

RubyではCSS Spriteを自動化したりすることもできるようなのであの30分はかかりそうな面倒なspriteも自動で行うことができるわけだ。

どこかの本で読んだことの受け売りだが60分かかるタスクがあるとしたら、59分かけてそのタスクを行うスクリプトを書いて、1分で実行する。これからのウェブデザイン/フロントエンドデベロッパにはそんな心構えが必要になってくるだろう。

Elsewhere

cssradar@twitter / 1日5件以内のウェブデザイン情報をつぶやきます
CSS Radar Newsletter / CSS Radarニュースレター。Twitterまとめ + α
Google + / どんな風に使っていくかアイデア募集中

Git バージョンコントロール

2011-12-03 01:40:50 +0900

バージョンコントロールについて

バージョンコントロール。まだ始めていなかったら、今からでも遅くはない。

作業用フォルダがstyle.bk20110128なんて名前であふれている
なんでこの変更したのか、覚えていない。もう3ヶ月も前の話だし
誰が最新のファイル持ってるかわからないまま、作業を開始、もう1度やり直し

HTMLであろうと、CSSであろうと、JSであろうと、何であろうとソースコードを人間は必ずどこかで例のような目にあうのだ。

バックアップも、更新履歴も、システムでやればいいじゃない。を解決してくれるのがGit。
セットアップも簡単で、利用するのも簡単。あのLinuxの父、Linus TorvaldsがLinux Kernelを管理するために開発した、というオリガミは信頼の証。

Gitのインストール

※以下はMac環境での説明になるが、Windowsでもほとんど変わらない。

OSX Installer for Gitから、自分のOSバージョンにあわせてdmgをダウンロード。Winはこちら
あとはインストーラにお任せ。

私はHomebrewを使って、Gitをインストールした。

Gitはアプリケーションフォルダには入らない系統のアプリ。Terminalで使える。
Terminal(日本語だと端末？)の時点で、たぶん半数以上のユーザの興味を奪った自信があるが、騙されたと思って立ち上げてほしい。アプリケーションフォルダのユーティリティフォルダにあるはずだ。

では、git --version
をTerminalへコピペしてみてほしい。ちゃんとインストールできていれば、
git version 1.7.1.1
というような表示がされるだろう。

で、コマンドラインでしか使えないの？なんてことはないので、

SmartGit(個人利用はフリー、Winにも対応)
Tower(betaテスト中フリー、Macのみ)
TortoiseGit(フリー、Winのみ)

こちら、GitをGUIで利用できるようにするアプリ達。私はTowerをテストしつつ、Macでも、Winでも使えるSmartGitをメインで利用している。どちらも日本語版はないが、基本の用語さえ覚えてしまえば問題ないだろう。 GUIアプリをインストールしても、もう少しTerminalは開いたままに。

Gitの基本用語

レポジトリ(Repository) - 更新履歴などを管理するバージョンコントロールの要になる保管庫。
コミット(Commit) - エディタでいうならば保存に近いコミット。Gitに対して変更が完了したよ、と伝えるコマンド。コミットにはメッセージが必要で、どこをどうして変更したのか伝えることで履歴管理が可能になる
クローン(Clone) - Gitでは0からレポジトリを作成するのも簡単だが、既存のレポジトリをクローンすることができる。多人数で開発をする際は非常に便利
ブランチ(Branch) - メインの開発からの分岐を作成するブランチ。“Git のブランチモデルは、Git の機能の中でもっともすばらしいものだという人もいるほど” Pro Git

Gitをインストールした後にやるべきこと

Terminalはまだ開いたままだろうか？
準備が整ったら以下のコマンドを、必要な部分は修正してから、Terminalにて実行。

まずは自己紹介をしよう

git config --global user.name "名前"
git config --global user.email メールアドレス@example.com

標準のエディタを設定

*Terminalから利用する場合にコミットメッセージを書くのに使うエディタ。たいていの場合Terminalのデフォルト、viかvimが使われる。それ以外のエディタが好みの場合は設定しよう。

git config --global core.editor emacs

ホワイトスペースを無視する

Gitではホワイトスペース1つを追加してもファイルを変更したと認識される(Rubyではホワイトスペースは大事)が、大抵の場合、ホワイトスペース1つでコミットする、ということもないだろう。

git config --global apply.whitespace nowarn

すべてのGitレポジトリに無視ファイルを適応

Macなら.DS_Store(普段は見えないけれどGitは認識する)など、OSが自動で生成するファイルとか、毎回.gitignore(無視リストファイル)をレポジトリに追加したり、その.gitignoreをコミットしたりするのは面倒。

git config --global core.excludesfile ~/.gitignore

このコマンドのままだとホームディレクトリに.gitignoreがあるから–globalで読んでねという意味になる。
私はこのファイルをDropboxを使ってすべての環境で同じファイルを見るようにしている。

Dropboxにdotというディレクトリを作成しその下に.gitignoreファイルを作成してる

git config --global core.excludesfile /Users/[ユーザディレクトリ]/Dropbox/dot/.gitignore

Macならこんな具合。

.gitignoreファイルの文法は

# '#' から始まる行はコメント
# foo.txtというファイル名は無視
foo.txt
# .htmlで終わるファイルを無視。'\*'はワイルドカード
*.html
# '!'は例外。上の例から引き続きで、.htmlで終わるファイルは無視するけどfoo.htmlは例外。
!foo.html

# Macユーザなら、下記で基本はOK。参考: https://github.com/github/gitignore/blob/master/Global/OSX.gitignore

.DS_Store?
Icon?
# Thumbnails
._*
# Files that might appear on external disk
.Spotlight-V100
.Trashes

Gitの基本的なワークフロー

それでは先ほど紹介した用語と、ほかのいくつかのGitのコマンドを交えながらGitの基本的なワークフローを説明しよう。

その前に少しTerminalで使えるコマンドを少々。

cd - ”Change Directly”。ディレクトリを変更するコマンド。cd ../とすれば、親ディレクトリにも移動できる、HTMLのリンクと同じ。
pwd - 現在のディレクトリを教えてくれる。Macだけかも
ls - 現在のディレクトリに含まれるファイルをリストアップしてくれる、Winだとls -aとしないとだめ？
touch - ファイルを作成できる。touch style.css

ファイルの移動や、削除ももちろんコマンドでできるが。慣れないうちは上記の4つで十分だ。私もコマンドになれてきたとはいえ、使うBashコマンドの7割は上記の4つという程度。

それでは、Gitの世界へようこそ。最初は面倒だなと思うこともあるけれど、これから幾多の困難をともにする強力なパートナとなってくれるだろう。

git init

既存のレポジトリをクローンしない場合、git initはgitのスタートを告げるコマンド。
作業ディレクトリに対して.gitディレクトリを作成する。

Macユーザ恐れるなかれ、.gitディレクトリ、だけではないが.(ドット)から始まるファイル、ディレクトリは普通はFinderには見えない隠し要素になる。
Terminalでlsとすれば、きちんと存在が確認できる。

defaults write com.apple.finder AppleShowAllFiles TRUE
killall Finder

または上記のコマンドを叩くと見えるようになる。
おお、うざい。と思ったら、

defaults write com.apple.finder AppleShowAllFiles FALSE
killall Finder

で元に戻せる。TotalFinderというFinderにタブを追加できるアプリケーションなら、GUIでOn/Offできる機能もついてくるのでおすすめ($15)(ちょっと重いけど、便利)。

git add

.gitが作成された作業ディレクトリに必要なファイルを作成/コピーしてきたら、git addコマンドで、ファイルをレポジトリに追加する。
私は大概git add .としてしまう。最後の.(ドット)は、まだレポジトリに追加されていないファイル全部、という意味だ。
もちろん、git add ファイル名としてファイルを1つづつ追加することも可能。

※readme.mdというテキストファイルを追加して、そこにプロジェクトの概要などを書き留めておくと、便利だ。.mdはMarkdownというライトウェイトマークアップ言語の拡張子。

git commit

初めてのコミット。まずはプロジェクトの開始を伝えるコミットからスタート。

git commit -a -m "Initial Commit"

-aフラグは、すべての変更に対してコミットするという意味。便利だが、ある理由で1ファイルを修正したのか、そのある理由が複数ファイルに渡る修正なのか、それとも？となってしまうので、コミットの単位については明確な理由がかける範囲で。
-mフラグは、エディタを開かず、その場でコミットメッセージを書けるようにする。その後’(シングルクォート)か”(ダブルクォート)で囲んだ部分がメッセージになる。日本語でももちろん問題ない。

git status

それではgitの現状を確認してみよう。git statusでは、.gitディレクトリに含めれるファイルすべてを密かに監視している。
ファイルは追加(add)されているか？コミット済みなのか？　コミットから変更されたか？前回のコミットから変更されたか？
git statusはそれらの状態を教えてくれる便利なコマンドだ。

git log

ファイルに変更を加え、いくつかのコミットを行った後、しばらくすると変更点についてはすっかり忘れている。
そんな時はコミットメッセージを読めばわかる。(わかるようにコミットメッセージを書くことが大事)

git log --graph --pretty=oneline

とフラグを渡しつつ、git logとすると下記のようにコミット1回につき1行で、表示される。

7366587c589fe6ee60aeff553e899dc13086d7ec About Responsive Web Design is finished
28b07e6c8fa6299c9c6b3321a339b1c7881e2fe4 erase meta since I use .htaccess
90187a85261b208abbb0c52511fcf675ebe4739d fix css little bit
5035c4eabe855efbac15596663190a6126eb0880 Read me was old
4600e678e757950e5d6a7c7fbfc9a6420333e1c2 Ready to deploy

ここでは残念ながら地味な表示だが、Terminal内では、デキる感じがしないでもないように、黒背景にグリーンが映えるマトリックスな世界を繰り広げられる(Terminalの設定による)。
pimping out git logで紹介されていた

git config --global alias.lg "log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative"

とすると、git logのデフォルトで1行、色つきフォーマットでログを見ることが可能

git branch

Gitの真打ち、branch。ブランチは分岐を表示・作成するコマンド。

コミットがすべて完了しているmaster(デフォルト)で、

git branch newfeature

とすると、masterをベースにnewfeatureというブランチが作成される。

私は現状、以下のようにブランチモデルを作っている。

master(デフォルト) = 現時点で本番環境を管理するブランチ。ここへのコミットは少ない。gitnのtag機能を使ってバージョンナンバを持っている。
develop = 開発バージョン。基本的にすべての作業はこのブランチをメインして行う。ここへのコミットは非常に多い。
feature = developとの違いは、開発の中でも特に新しいデザインパターン用のコーディングなどを行う。
fix = 文字通り修正用のブランチ。修正が完了次第コミットし、必要に応じてmasterまたはdevelopとマージする。

開発の規模感にもよるが、HTML、CSS、JavaScriptをメインで担当する私にとっては上記のブランチでまかなえる。
上記のブランチモデルは、A successful Git branching modelを参考に、よりシンプルにしたバージョン。このブランチの詳しい使い方については、また別の記事としたい。

git merge

branchにはmergeは欠かせない。表裏一体の存在といえる。branchを作成し、その場で開発を続けていても、いつかはmasterへマージする日がやってくる。
マージする際、衝突があればgitはそれを解決しないとマージできないと警告を発する。SmartGitを利用していれば、グラフィカルな環境で衝突している部分を表示してくれる。

git mergeをする際には、まず現在いるブランチをコミットして、からgit checkout masterというように、マージさせたいブランチに切り替える。
自分が今いるブランチがどこなのか、ほかにどんなブランチがあるかを確認するには、git branchとすれば

*master
newfeature

というように表示してくれる。
ちなみに、Terminal用プログラムBashの設定で

function parse_git_branch {
  ref=$(git-symbolic-ref HEAD 2> /dev/null) || return
  echo "("${ref#refs/heads/}")"
}

RED="\[\033[0;31m\]"
YELLOW="\[\033[0;33m\]"
GREEN="\[\033[0;32m\]"

PS1="$RED\$(date +%H:%M) \w$YELLOW \$(parse_git_branch)$GREEN\$ "

上記を追加すると、コマンドプロンプト(コマンドを叩く左側に出る文字列)に、現在のブランチを表示してくれる。 USERディレクトリ下に.bashrcという名前で上記を追加して保存。既存でなければ、ファイル名を.bashrcとし保存すればOK。

では無事にmasterへブランチを切り替えられただろうか。

git merge myfeature

これで、myfeatureブランチはmasterブランチへマージが完了する。

GitのTips & Tricks

git alias

コマンドラインの便利さはコマンドを覚えてしまえば、色々なことがコマンド1つ、あるいは2つでできてしまう、ということにつきる。
gitもGUIツールの利便性は否定しないが、コマンドラインから利用することにしている私。
少しでもタイプする文字を減らしたいので、そんな際に便利なのがgit alias。
あらかじめ登録したコマンドをショートカットのように呼び出す事ができる機能だ。

git config -e --global

とすると、システムワイドで利用するgitの設定ファイル.gitconfigファイルをエディタで開ける。
すでに自分のメールと名前は設定済みのはずなので、ファイルに追記すれば、aliasを利用できる。

6行目までは、単純によく使うコマンドを2文字に省略しただけで、
lgはこの記事から拝借した。git logを少しセクシーにしてくれる。

fixは私があまりにもよく繰り返すコミットしたあとでそのコミットに入れるべき変更に気がついたり、コミットを重ねるべきタイミングでない際に使う--amendオプションをaliasにした。
コミット後、編集が必要だったファイルがあれば、そのファイルを編集し、git add FILEと追加して、git fixとすると、前のコミットメッセージを繰り返しタイプせずとも以前のコミットメッセージを利用してコミットできる。

unstageはaddの反対でgitのstageに追加したくないファイルを削除してくれる。

[alias]
st = status
ci = commit
br = branch
co = checkout
df = diff
dc = diff --cached
lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative
fix = commit --amend -C HEAD
unstage = reset HEAD

git diff

フラグなしにgit diffとした場合、最後のcommitと現在の状態を比較する
git diff -- <filename>とすると、1ファイルのみを比較できる
git diff --cachedではステージングにあるファイル群とHEAD(*)を比較する

* HEADは現在のブランチと同義だと思っていていいそうだ。(What is git head, exactly? - Stack Overflow)

あってはならない事だとは思うが、Commitを忘れて次の編集時に気がつくなんて事はそこそこ多く発生する。
バージョンコントロールを初めたばかりならなおさらだろう。そんな時にも便利なのがgit diffだ。

もちろん、チームでの作業の場合、マスタをCommitする際に、他の人が作業した部分をレビューするのには欠かす事ができないコマンド。

Githubの使い方

fork

forkはGithub内で公開されているレポジトリを自分のレポジトリとしてコピーしてくる事を指す。
利用したいレポジトリを見つけたら、forkボタンをクリックすれば自分のレポジトリにコピーが完成。この時点でどんな変更を行おうとそれは自分のレポジトリ内だけで完結する。
その変更をオリジナルにも反映するべきという場合にはPull Requestをすることでオリジナルレポジトリの所有者に変更を伝える事ができる。

git clone git@github.com:ユーザ名/レポジトリ名.git

forkしたレポジトリをローカル環境にclone。
ちなみにコマンドラインで上記を実行する際は自分がどのディレクトリにいるのか確認しておこう。
pwdで自分の居場所を教えてくれる。
レポジトリ名でディレクトリが生成されるので、ついでにremoteの設定をしておこう。この設定をしておけばオリジナルレポジトリで変更があった際にその変更をfetchできる。

cd レポジトリ名 # まずはそのディレクトリに移動
git remote add upstream オリジナルのレポジトリのgitパス #パスはgithubのレポジトリのページにあるのでコピー
git fetch upstream # 変更をfetch
git merge upstream/master # 変更を自分のブランチにmergeする

ヘルパスクリプト

Git Extras

visionmedia/git-extras

Git ExtrasはGitに便利コマンドを追加するスクリプト集。

git commits-since yesterday で昨日からのコミットだけを見る事ができたり、
git delete-submodule lib/foo でlib/fooのsubmoduleを削除したり、
git-touch [filename] でfilenameを作成して、git addしたり、
git undo で最後のコミットを削除したりする。

インストールは簡単。

curl https://raw.github.com/visionmedia/git-extras/master/bin/git-extras | INSTALL=y sh

紹介した以外にも沢山のコマンドが追加されるので入れておいても損はしないと思う。

参考リンク

Pro Git - オンラインでなら無料で日本語訳されたPro Gitを読むことができる。まだ私自身すべてを読み終えたわけではないが、かなり勉強になる
Git cheat sheets (github) - Githubにあるgitのチートシート
A successful Git branching model - ブランチモデルの実例をコマンドともに解説している
git(1) Manual Page - gitのマニュアルページ。コマンドのフラグなどはこちら。git helpからコマンドでも参照できる
Git ユーザマニュアル (バージョン 1.5.3 以降用) - 上記リンクの日本語版
Get Started with Git (A List Apart) - A List ApartにてAl Shaw氏による記事
GitCasts - Gitのスクリーンキャスト。英語だが、グラフィカルな環境でしか覚えられない人には最適

Elsewhere

cssradar@twitter / 1日5件以内のウェブデザイン情報をつぶやきます
CSS Radar Newsletter / CSS Radarニュースレター。Twitterまとめ + α
Google + / どんな風に使っていくかアイデア募集中

レスポンシブウェブデザイン

2011-11-19 13:07:17 +0900

レスポンシブウェブデザインとは

いまこの記事を読んでいるモニタのサイズは何インチだろうか？
iPhone、アンドロイドOS搭載スマートフォン、iPad、ネットブック、ノートPC、デスクトップPCと数年前なら思いもよらなかったモニタ/スクリーンサイズでユーザはウェブサイトを閲覧し始めている。今後もさらに解像度が異なる環境が増えていくことは間違いない。

ではそのサイズのモニタごとに、スクリーンごとにデザインを作り、HTML/CSSを書き足していくのか？
その疑問への1つの回答がレスポンシブウェブデザイン(Responsive Web Design)。
多くの場合、CSS3で利用が可能になる予定のMedia Queriesを活用して、モニタ/スクリーンのサイズに合わせて最適なデザインを供給するデザイン/コーディング手法がレスポンシブウェブデザインと呼ばれている。

レスポンシブウェブデザインの例

Simon Collison / Simon Collisonはレスポンシブウェブデザインをいち早く導入したウェブデザイナ
Information Architects / WordPressを使ってレスポンシブデザインを実現している
Think Vitamin / こちらも最近のリニューアルからレスポンシブウェブデザインを導入
The Boston Globe / メジャーな新聞社のサイト。ここまで大きな規模は初
CSS-Tricks / レスポンシブウェブデザイン + CSS3のアニメーションを組み込んだ意欲作

レスポンシブウェブデザインが解決しないこと

レスポンシブウェブデザインは、特にハンドヘルドデバイス用に最適な解決方法と考えられるが、すべての問題に対する解決を提示できるわけではない。

A List Apartの記事、Responsive Web DesignにてEthan Marcotteは、次のように書いている。

That’s not to say there isn’t a business case for separate sites geared toward specific devices; for example, if the user goals for your mobile site are more limited in scope than its desktop equivalent, then serving different content to each might be the best approach.

ユーザのゴールに合わせて、ハンドヘルドデバイス用にコンテンツを変更することがベストの解決方法である場合もあるということだ。

Responsive Web Design: Mobile: Context(Think Vitamin)にてNick Pettitも、レスポンシブウェブデザインを採用するかについて、

スピード

ハンドヘルドデバイスはWIFIで接続することもあるが、多くの場合は3G回線で接続する。すでに多くのユーザが感じているように、iPhone4のSafariがいくら早くなっても、デスクトップのブラウザのスピードには勝てない。JavaScriptやCSSを無意味にハンドヘルドデバイスでも読み込むことはスピードを犠牲にすることになる。

スクリーンサイズ

言わずもがな、ハンドヘルドデバイスのスクリーンサイズは決して大きくない。display: noneが解決してくれる問題かもしれないが、実際には難しい場合もある。例えば、レストランの情報をデスクトップからアクセスする場合と、ハンドヘルドデバイスからアクセスする場合とでは、提供すべくコンテンツが異なる。そして画像のサイズについて、iPhone4など解像度の高いスクリーンを持つデバイスも現れはじめており、レスポンシブウェブデザインだけでは解決できない問題もある。

場所

ハンドヘルドデバイスは持ち運ぶため存在する。スクリーンサイズの差異による問題点と同じく、デスクトップと、ハンドヘルドデバイスではユーザが求めているコンテンツそのものが異なる場合も多い。デスクトップではほとんど役目を果たすことがないGeolocationも、ハンドヘルドには重要になってくる。

というような観点で検討するべきだと話している。

EPISODE #6: MOBILE FIRST (The Big Web Show)では、Luke Wroblewskiは「モバイルからまずデザインを始める」という提案をしている。
こちらも非常に興味深い。現時点では通常デスクトップ用のデザインからスタートし、その後にハンドヘルドデバイス用に最適化していくのが通常のフローと言えるが、Lukeはモバイルデバイス用のデザインを先に行う事でモバイルで提供すべきサービスの根幹に集中することができ、デザインだけではなく、UIやサイト構造、そしてインタラクションもシンプルにすることができると話している。
ミニマムなスタート地点からデスクトップ用デザインなど大きなモニタ/スクリーン、マウスやキーボードなどに対応するデザインを作ることで、すべてのユーザに対して最適なデザインを提供できるという考え方だ。

Media Queries

レスポンシブデザインでは多くの場合、CSS3でサポートされる予定のMedia Queriesを活用しサイズの異なるモニタ/スクリーンに対し最適なデザインを提供する。
Media Queriesについては、Hardboiled Web Designの著者であるAndy Clarkの記事Hardboiled CSS3 Media Queriesで実例を見る事ができる。

/* iPhone 3 (横向き) ----------- */
@media only screen 
	and (min-width : 321px) {
	/* ここにスタイルルール */
}

CSS3で拡張されるMedia Queriesでは、screenやprintのようなメディアタイプだけでなく、デバイス自体のサイズやスクリーンのサイズなどを利用できるようになる。
例:min-width : 321px、max-width : 320p、max-device-width : 1024px

上記のように既存のスタイルシートに追記することも可能だし、

<link rel="stylesheet" href="smartphone.css" media="only screen and (min-device-width : 320px) and (max-device-width : 480px)">

というようにlinkを使って別のスタイルシートとして管理することもできる。

@import url(smartphone.css) only screen and (min-device-width : 320px) and (max-device-width : 480px);

W3Cによれば@importを使っても上記のように記述することが可能。(Media Queries)

現時点でのMedia Queriesのサポート状況は、Firefox, Chrome, Safari, Opera, Internet Explorer 9, Android スマートフォン, そしてiOSデバイス(iPhone、iPhone4、iPad、iPod touch)がサポートしている。(※Androidスマートフォン、iPhone、iPod touchについては、W3Cで宣言されているすべての値を利用できるわけではないようだ)

Androidスマートフォン、iPhone、iPod touch、iPadなどのハンドヘルド端末については、

<meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0;">

という記述も必要になるだろう。 meta viewportについてはSafari Reference Library(英語)が詳しい説明をしている。
またはQuirksmodeのCombining meta viewport and media queries(英語)も参考になる。

また、IE6〜IE8まではCSS3で拡張される予定のMedia Queriesはサポートされていないので、レスポンシブデザインの実装をしないか、css3-mediaqueries-jsというJavaScriptを使った実装は可能だ。
レスポンシブウェブデザインはすべてのブラウザで見た目を同じにしなくてはならないという思想からはほど遠くプログレッシブエンハンスメントという手法に近いので、無理にIE6〜IE8への実装をする必要性はない。
レスポンシブウェブデザインは、確かにユーザのスクリーンサイズに合わせた最適なデザインを提供することができるが、それができなくてもユーザビリティはマイナスになったりはしない。

レスポンシブグリッドCSS

レスポンシブグリッドの最大の弱点は、実装がやや大変なこと。現実的にモバイルに最適化されることを想定していないウェブデザインをモバイル用に変更したり、サイズが変わった際にどのようにグリッドが変更していくべきかなど、デザインとテクニックの両面で解決しなければいけない問題点がある。
そこで現れ始めたのが、レスポンシブウェブデザインのためのグリッドCSSだ。

Less Framework

黄金比をベースに3、5、8、13コラム、最小320pxから1280px以上のモニタ/スクリーンに合わせてコラムグリッドの数を変更する。実際に配布されているのは、bodyに対してmedea queriesを使って幅のサイズを指定するところのみ。コラムグリッドについては、配布されるファイルのコメントを参考にグリッド用のクラスを作成する。非常にミニマムな構成なので、レスポンシブウェブデザインを学ぶ上でのソースコードリーディングに最適だ。

The 1140 grid

こちらは、その名前の通り1140px以上を最大幅とするレスポンシブグリッドCSS。Less Framework3と異なる点はコラムグリッド用のクラスは用意されているところ。そしてコラムグリッドとガター(コラムとコラムの間のマージン)はパーセントで指定されているところ。画像に対してもmax-widthを指定し、モニタ/スクリーンのサイズに対して最適なサイズに変更されるようになっていたりする。Photoshopのファイルも配布している。

レスポンシブウェブデザインの問題点

レスポンシブイメージ

まさに魔法とも思える画像へのレスポンシブ対応である

img,
embed,
object,
video {
  max-width: 100%;
}

に隠された問題点を指摘できるだろうか？

ブラウザによって縮小された画像のクオリティ
大きなサイズの画像であることには変わらない = 帯域の無駄

この問題点に対して、多くの解決が提案され続けている。
多くの提案については、Responsive IMGs Part 2 — In-depth Look at Techniques « Cloud Four(英語)にてその手法と問題点についてよくまとまっているので目を通しておくことをおすすめする。

この記事からさらにまとめると

Adaptive Images in HTML

JavaScript + PHP + .htaccessを利用したほぼサーバーサイドで解決できるこの手法は、画像が常に同じファイル名であるためにCDNを利用している場合に問題が出る可能性があるがインフラチームと連携すれば実装面と効果面でROIが高いと言える解決。

Testing Responsive Images

JavaScriptのみで解決する方法がこちら

<noscript data-large='Koala.jpg' data-small='Koala-small.jpg' data-alt='Koala'><img src='Koala.jpg' alt='Koala'></noscript>

まずは画像をnoscriptタグで囲んで、

$('noscript[data-large][data-small]').each(function(){
  var src = screen.width >= 500 ? $(this).data('large') : $(this).data('small');
  $('<img src="' + src + '" alt="' + $(this).data('alt') + '" />').insertAfter($(this));
});

とjQueryでスクリーンサイズに合わせて別画像を呼び出す。
noscriptを使うという慣れない実装ながら、CDNでも問題を起こさないし、大小の画像を両方にリクエストを投げる事もない。リクエストの回数と画像のダウンロードにかかる帯域を節約できる見た目以上にエレガントな解決方法。

How to use src.sencha.io

tinySrcというサービスがSenchaに吸収され、src.sencha.ioとして生まれ変わった解決法。
こちらは画像をsrc.sencha.ioに投げるとデバイスに最適化したサイズに変換して戻してくれる。
Senchaのインフラに頼り切ることにはなるが、個人サイトレベルであれば問題ないだろう。

と3つほどが解決の候補にあげられる。
サイトの規模やサーバーサイドチームと相談の上、環境に応じた解決を適切に選択してほしい。

レスポンシブ広告

ウェブサイトには画像や動画など以外にも固定幅の要素がある。
それが広告。ほとんどのウェブデザイナは広告表示にまつわる仕事をしたことがあるだろう。
ウェブサイトの収入は多くの場合この広告に頼っている現状を考えると、レスポンシブウェブデザインを加速するにはこの問題を解決しないわけにはいかない。

Responsive Advertising via Mark Boulton

Mark BoultonがBoston Globeのレスポンシブウェブデザイン対応から得た経験から、問題の解決作を提案している。

Responsive Advertising via ART=WORKR

そのMark Boultonの提案への改善策を提案しているのがこちら。

どちらの解決作も

広告は標準化された固定サイズである
広告はサイズと掲載位置をベースに制作され販売される
広告にはpop-over、動画などリッチアドという広告もある

という3点にフォーカスして問題の解決を図ろうとしている。
結論からいって、3.への解決はどちらも苦慮中で、1.は標準サイズのクリエイティブを再利用して解決できるとしている。

問題は2.の掲載位置。現状ではセールスチームの人間がお客さんにこのサイトのこの位置に掲載されます、と言って販売してくるわけだから、往々にして掲載位置を固定するためにテンプレートが存在することになる。
つまり

テンプレート > 掲載位置とサイズ > 広告

というメンタルモデルとなるというのがMark Boltonの考えで、彼の提案は掲載位置とそれに伴うサイズでの販売ではなく、それらをパッケージ化して販売し、スクリーンサイズに合わせて表示する広告サイズを変化させるというもの。
全サイズでのインプレッション数をパッケージとして保証すれば問題は解決されるということだ。

それに対して、ART=WORKの提案は

レンジ > テンプレート > 掲載位置とサイズ > 広告

というように先ほどのメンタルモデルにレンジという上位の概念を取り入れたもの。
ここでいうレンジについては、実際に画像を見てもらった方がわかりやすい。(レンジについて)

ウィンドウサイズをレンジで区切ってそのレンジに合わせてこれまで通りに広告を販売できる。
モバイルデバイス用に広告を表示させる場合は、そのレンジで購入すればいいという単純な仕組み。

私の経験では現状日本では、PC用、モバイル用というレンジに近い概念で広告は販売されている。少なくとも私の会社ではそうだ。
これは日本ではそもそもスマートフォン以前の携帯端末への広告販売に適応してきた歴史があるからだ。
携帯用、PC用、両方でという販売形態はすでに販売側にも実装側にも制作側にも経験がある。
この分野に置いては日本が海外を先行していると言えるので、経験を海外に向けて発表でいるいい機会と言える。

参考リンク

参考図書

Elsewhere

cssradar@twitter / 1日5件以内のウェブデザイン情報をつぶやきます
CSS Radar Newsletter / CSS Radarニュースレター。Twitterまとめ + α
Google + / どんな風に使っていくかアイデア募集中

CSS Radar | Little Books For Front End Developers

ウェブデベロッパのための英語

はじめに

はじめの一歩

80/20の法則

森を見て、木を見ない

ならうより慣れろ

読み続けるためのツール

おすすめの本

Elsewhere

Vim

はじめに

コマンド

ファイルを分割ウィンドウで開く

行をソートする

バッファにあるファイルを全部タブで開く

プラグイン

snipMate

MatchTag

Prefixr

Tabular.vim

Gundo

Pathogen

設定

タブをFirefoxのように操る

参考リンク

Elsewhere

Jekyll

Jekyllとは

開発環境の準備

基本フォルダ/ファイル構造と記事の作成

基本フォルダとファイルの準備

記事の作成

テンプレートの作成

Liquidについて

_config.ymlの設定

ページの作り方

基本以外のフォルダについて

ローカル環境でプレビュー

サーバへのアップロード

rakeを使って自動化する

Elsewhere

ウェブデザイナのためのRuby

Rubyはウェブデザイナに優しい

Rubyのインストール

Ruby Gem

ウェブデザイナにおすすめのパッケージ

CSS Sprite

SASS/LESS

Juicer

CSS Redundancy Checker

Rake

まとめ

Elsewhere

インブラウザ デザイン

インブラウザ デザインとは

インブラウザ デザインのプロセス

アイデアの集約と大まかなレイアウトの決定

このステップで利用するツール

ベースになるHTMLとCSSの作成

このステップで利用するツール

レイアウト

このステップで利用するツール

残りのステップは、デザインしていくだけ

インブラウザ デザインをより加速するオンラインツール達

インブラウザ デザインの注意点

参考リンク

Elsewhere

パフォーマンス最適化

パフォーマンス最適化の意味

ページのロード時間で失うモノ

Steve Soudersの教え

最適化チェックツール

最適化ツール

CSSスプライト

JavaScriptとCSSの結合と縮小化

画像最適化

.htaccess(サーバ側で設定できるなら、その方がベター)

スピードについて

Elsewhere

インブラウザデザイン

インブラウザデザインとは

インブラウザデザインのプロセス

インブラウザデザインをより加速するオンラインツール達

インブラウザデザインの注意点