タスクランナー導入～とあるWordPress制作環境～

古川 勝也NPO法人 あおもりIT活用サポートセンター 理事

自己紹介

• 古川 勝也(こがわ まさや)

• あおもりIT活用サポートセンター理事

• CalmTech(カームテック) 代表

• CPIエバンジェリスト

• テクテク編集部 代表

• 料理研究一家「古川家」

本日の流れ

• Webデザインを取り巻く現状

• セッションの対象とゴール

• ブラウザの外のJS

• パッケージマネージャー概説

• タスクランナー概説

• WordPress制作環境での導入例

• まとめ

Webデザイナーはどこへ行く？認識をすり合わせましょう

Webは高度な複合技術

• ホームページ作りたい！（ごく気軽な思い）

• サーバー、ドメイン、FTP…etc

• HTML、CSS、JS、ビットマップ…etc

• CGI、データベース、SSL…etc

• CMS、ウェブビルダー、ブログ…etc

• 一体いくつ覚えればいいのよ！？（半ギレ）

楽になったコトも苦になったコトも増えましたね

ぜんぜん手軽じゃない

だって、いっぱい増えてますもの

Webデザイン業界の個人的超解釈

• DTP業界からの流入で本格スタート

• 検索エンジン浸透で代理店、マーケターが本腰

• SEO戦国時代、ガラケー天国

• 回線の高速化が普及してキャズム越え

• iPhone登場でアプリバブル到来

• １人１台スマホ、SIer業界からの流入が増加

• コンテンツと技術の乱立で見直し開始 ＜イマココ

どういうバランスにしていきます？

マーケティング

インタラクション

マークアップ

IA UX

ビジュアルデザイン

大事なのはゴールとモチベーション

そもそもナゼ？

Web技術のコモディティ化

• 誰でも「すぐに」ホームページ、ブログ開設

• 誰でも「すぐに」決済機能つきECサイト開設

• 誰でも「すぐに」写真、動画を共有

• 誰でも「すぐに」メッセージ送信、返信

大量生産、大量消費、スピード命

• 技術の進歩が高速化＆多様化

• 消費サイクルも高速化

• 高度化した技術がインフラとして浸透

でも健康でいることを第一にしましょうね

時間がいくらあっても足りない

時間は資源であり有限、効率よく使いたいところ

時は金なり

どうやって壁を越えていくか？

• 手動の割合を減らしていく

• 作ったものは可能な限り再利用する

• １つの仕事が連鎖する仕組みを作る

それが全てではありませんが

自動化せよ

本セッションでの自動化とは

• コンピューターに任せる仕事の範囲を決める

• コンピューターに任せるために仕事を定型化する

• 繰り返しに落とし込む

• コンピューターに仕事を任せる

コンピューターは知の鏡

自動化＝機械化

機械化するメリットとは？

• ミスの可能性が減る

• 品質の保証ラインが均一化される

• 人間が拘束される時間が減少する

• 人間しかできないコトに集中できる

• 「時間」を「価値」に転化する機会が増える

時間をお金で買うのも1つの選択ですが

時は金なり

Web制作で自動化できることは？

• CMSや制作環境の導入

• CSSやJSの結合、圧縮

• 動作確認のブラウザリロード

• 複数デバイスでの表示確認

本セッションのターゲット前提知識が色々とありまして・・・

HTMLの前提知識・経験

• 静的サイトの制作経験がある

CSSの前提知識・経験

• CSSフレームワークを知っている、使っている

• CSSプリプロセッサを知っている、使っている

JavaScriptの前提知識・経験

• jQueryとかのライブラリを使ったことがある

• JSONを見たこと、聞いたことがある

WordPressの前提知識と経験

• WordPressインストールは自分でできる

• XAMPPやMAMP上に構築できる

• 独自テーマを作成したことがある

そう、あれです。黒いやつです。

運命の別れ道

Y/n

黒い画面つかってみますか？

顔に出てますよ？

今、迷わず「No」と思いましたね

嘘です

（・∀・）ｶｴﾚ!

他の方法もちゃんとあります

黒い画面をできるだけ避けたい方へ

CodeKit(Macのみ)一時期、話題になったコンパイルツールが進化しました

Prepros(Win/Mac/Linuxすべて対応)コンパイルとかブラウザリロードとかFTPとか全部やってくれます

これで十分なのでは？

• Sass/SCSSだけ自動化は手軽

• ブラウザリロードだけでもありがたいぐらい

• まず必要性と利便性を感じてみる

• Macユーザー特権でなくなってきました

git for windows(git-bash)Windowsで黒い画面を使うにはこれが１番手軽

プログラマーには日常的ですが・・・

なんで黒い画面前提なんでしょうね

GUI化は多大な労力が必要

• フロントエンドの変化がかなり早い状況

• 今は「鉄板」がない

• 作ってすぐ動かすにはCUIが手軽

• GUIだとカスタマイズに限界がある

• カンプ作って終わりならな… ＜ 同じこと

コントロールできない技術はリスクにもなります

待つことも重要な選択肢

ブラウザの外で動くJSいろいろな使い方されるようになりました

Node.js

• サーバーサイドJavaScript環境

• フロントエンドに役立つツールがいっぱい

• Long-term Support版がオススメ

パッケージマネージャー概説これがないと困ったことになります

なぜ必要なの？

• Aと言うライブラリを使うにはBが必要

• BはCとDに依存したツール

• えーと、つまり全部入れればいいのかな？

• バージョンの相性とかあんの！？

• 人の手でやってられません

• Node.jsのパッケージ管理ツール

• サーバーサイド、フロントエンド問わず

• npmにもタスク実行機能が備えられている

npm

-g はグローバルの意味 1度インストールすると以後はどこでも呼び出し可能に

> npm install -g [パッケージ名]

初期処理として packages.json 作成 プロジェクトごとにパッケージを管理する想定

> npm init

インストールしたパッケージは packages.json に追記 ̶save でパッケージ間の依存関係も追加される ̶save-dev は制作時のみ使用するパッケージを指す node_modules 以下にインストールされる

> npm install [パッケージ名] ̶save > npm install [パッケージ名] ̶save-dev

プロジェクトで packages.json を共有している時に利用 指定しておいたパッケージが一括でインストールされる そのためにも ̶save と ̶save-dev オプションが重要 ̶production で ̶save-dev で入れたパッケージ除外

> npm install

• Twitter製パッケージマネージャー

• フロントエンド用に特化

• Bootstrapとか

Bower

初期処理 bower.json 作成 プロジェクトごとにパッケージを管理する想定

> bower init

インストールしたパッケージは bower.json に追記 ̶save でパッケージ間の依存関係も追加される ̶save-dev は制作時のみ使用するパッケージを指す bower_components 以下にインストールされる

> bower install [パッケージ名] ̶save > bower install [パッケージ名] ̶save-dev

プロジェクトで bower.json を共有している時に利用 指定しておいたパッケージが一括でインストールされる そのためにも ̶save と ̶save-dev オプションが重要 ̶production で ̶save-dev で入れたパッケージ除外

> bower install

• Rubyのパッケージマネージャー

• Sass/SCSS、Compassぐらい

RubyGems(通称：gem)

グローバルでインストール プロジェクトごとにパッケージを管理するBundlerもある

> gem install [パッケージ名]

• PHPのパッケージマネージャー

• WordPressがらみで使うかも

Composer

composer.json というパッケージを記述するファイル生成

> composer init

インストールしたパッケージは composer.json に追記 パッケージ間の依存関係も追加される ̶dev は制作時のみ使用するパッケージを指す vendor 以下にインストールされる

> composer require [パッケージ名] > composer require [パッケージ名] ̶dev

composer.json に記述されたパッケージをインストール

> composer install

うわぁ・・・って思われても仕方ありません

察しの通り、全部つかいます

実はコマンド形式ほぼ一緒

npm install

bower install

gem install

composer install

タスクランナー概説なんと本編はここから！

Gulp

• タスクという単位の処理を自動でこなす

• 非同期で実行するので既存ツールより高速

• プラグインを組み合わせると高度な処理が可能に

インストールから実行まではこれだけ

> npm install -g gulp > gulp

WordPress制作環境に導入いくつかのアプローチがあります

ツール群をどう取り込むべきか？

• WordPress構造はどうする？

• 独自テーマだけ作ることができればいい？

• 動作確認はどうやって行う？

なるべく手動で用意しないように

ゼロから考えるより既存をカスタム

Yeoman

• ひな型を自動生成してくれるツール

• 様々なひな型が公開されている

• インストールしたもので勉強する

後は yo というコマンドを呼ぶだけ

> npm install -g yo

YeoPress

• Yeoman経由でWordPressをインストール

• 初期設定を対話形式CUIで行う

• あらかじめカスタムされたフォルダ構造もある

• local-config.phpで設定を上書きできる

WordPressのインストールが始まります ̶advanced オプションをつけると細かい点を調整できます

> npm install -g generator-wordpress > yo wordpress ̶advanced

WordPress日本語化に注意

• アップデートすれば日本語化は大丈夫

• WP Multibyte Patch は自分で入れます

local-config.phpテスト環境用のファイルを置くだけで設定の切り替えができます

yo-emi

• WordPressのテーマひな型 Emi がベース

• Yeoman経由でインストール

• Gulp、Sass、Autoprefixerなど設定済み

• LiveReloadで自動更新

テーマフォルダの下で実行します テーマ名は英数字とアンダースコアでつけましょう ハイフンだと自動生成される関数名でエラーになります

> yo emi

Gulp利用前に

> gem install sass

gulpfile.jsでコンパイル対象を指定する

LiveReload使用が初期状態

制作環境が最初から整っている、ありがたさ

洗練された土台でスタートダッシュ

Bedrock

• WordPressのひな型

• 最初から色々とカスタマイズ済み

• 構成は複雑に見えるが、よく整理されている

• dotenvという仕組みで設定を変更できる

パッケージをインスールしましょう 必要なものは最初から記述されています

> composer install

やはりWordPress日本語化に注意

• アップデートを忘れずに

• これもWP Multibyte Patch は自分で入れます

.envlocal-config.phpのようにテスト環境と設定の切り替えができます

• WordPressテーマのひな型

• 必要なものは一通り揃っている

• Bedrockは必須ではない

Sage

Sageインストールの前に

> gem install sass

パッケージをインスールしましょう 必要なものは最初から記述されています

> npm install > bower install

manifest.jsonGulpで使用される基本設定が記述されています

まとめお持ち帰りできることはありましたか？

できそうなところから自動化

• SCSS/Sassの導入とコンパイル

• ブラウザリロード

• 複数端末での表示チェック

• GUIツールからまず触ってみる

自動化＝機械化

機械化したメリットとは？

• ミスの可能性が減る

• 品質の保証ラインが均一化される

• 人間が拘束される時間が減少する

• 人間しかできないコトに集中できる

• 「時間」を「価値」に転化する機会が増える

大事なことなので３回言いました

時は金なり

良き「きっかけ」となりますように

http://www.aoit.jp