【イベントレポ】9月のWordBench大阪とWordBench京都に参加しました。 #wbosaka #wbkyoto
9月のWordBench大阪とWordBench京都に行ってきました。
大阪はCSSの話。京都はCI(継続的インテグレーション)とKintoneを使ったプラグイン開発の話でした。
第45回 WordBench 大阪 「使いやすいWordPressテーマを作るために必要なCSSのつくりかた」
【WordBench京都 9月号】「CI(継続的インテグレーション)」と「kintone×WordPressハンズオン」
WordBench大阪
WordBench 大阪ではCSSの話でした。
Editor StyleとCSS設計についての2部構成。
まずは、Editor Styleについて
ビジュアルエディタか、テキストエディタか?
WordPressにはビジュアルエディタとテキストエディタがありますが、
このブログを書くときはいつもテキストエディタで書いています。
どっち使ってる人が多いんですかね??
WordPressを使って制作して納品ということもまだなく、自分が使えればどっちでもいいやと思ってたので、特にエディタについて考えていませんでした。
ただ、このビジュアルエディタ、使わないと損!
WordPressがビジュアルエディタに力を入れているそうで、
Markdownな書き方ができるようになっていたりどんどん改良されているそうです。
htmlを書かなくてもいいので、htmlが分からないお客さんに納品するときのためにも知っておいたほうが良さそう。
でも、せっかく便利なビジュアルエディタで書いても、デフォルトの見出しなんかは大きさが違うぐらいです。
スタイルを指定した場合、結局プレビューでスタイルが適用されているか確認しないとだめです。。。
そこで、登場するのが「Editor Style」
Editor Style
Editor Styleを使うとビジュアルエディタにスタイルを適用することができます。
なので、ビジュアルエディタ上の表示と、実際に投稿したときの表示を同じ状態にできます。
Editor Styleの編集は、テーマのCSSフォルダ内にあるeditor-style.cssを編集するか、
なければ以下のコードをfunctions.phpに追加します。
function my_theme_add_editor_styles() { add_editor_style( 'css/editor-style.css' ); } add_action( 'after_setup_theme', 'my_theme_add_editor_styles' );
そして、CSSフォルダ以下にeditor-style.cssファイルを作れば準備完了です。
editor-style.cssを書き換えるとビジュアルエディタのスタイルが変更されます。
これは単純な例ですが、Editor Styleを使えば、ビジュアルエディタを活用できそうです。
ただ、これって管理するCSSファイルが増えちゃいますね…。
例えば、style.cssのh1のスタイルを変更したら、editor-style.css内のh1も修正する必要があります。
これってめんどくさい!
ってことで、一元管理する方法
add_editor_style( ‘style.css’ );
先ほど書いたfunctions.phpに追記する記述のパスを変更します。
function my_theme_add_editor_styles() { add_editor_style( 'style.css' ); } add_action( 'after_setup_theme', 'my_theme_add_editor_styles' );
新しくeditor-style.cssを作るのではなく、style.cssに一緒に書いてしまおうという方法です。
確かに、この方法にすると管理するファイルがstyle.cssだけになります。
また、ちゃんと設計してCSSを書くと、例えば見出しのスタイルを変更した場合にビジュアルエディタも実際の表示も一度に変更できます。
そんな書き方を紹介しているのが、WordBench大阪で使われたスライド数200枚のこちらのスライド。
Sassで書く方法や、その他細かいノウハウも紹介されています。
CSS設計についてもこちらのスライドに載っています。
CSSの設計はCSSを書き始める最初の段階でしっかりとやらないと後々カオスなCSSに…。
書くだけなら簡単なCSSなんですが。
自分でもどこに何が書いてあって、どこを修正したらいいか分からない秘伝のCSSを作ってしまったこと数知れず。
設計についてはまだまだ勉強中なので、このスライドやスライドで紹介されている「Web制作者のためのCSS設計の教科書」で勉強します。
WordBench京都
WordBench大阪の翌日に開催されたWordBench京都。
一転して、プログラマーよりの話でした。
CI(継続的インテグレーション)と、Kintone・WordPressを使ったプラグイン開発です。
CI(継続的インテグレーション)
開始早々、開発の闇を見ました。
#wbkyoto
自分の環境だと動いてたよ問題こわい。
— Toro_Unit(山の上のとろゆに) (@Toro_Unit) 2015, 9月 13
めっちゃ怒ってるwww #wbkyoto
— shimakyohsuke (@shima_x_o) 2015, 9月 13
地獄をみた
#wbkyoto
— △ (@misumi_takuma) 2015, 9月 13
#wbkyoto
「バグは仕様に変わる」
— Toro_Unit(山の上のとろゆに) (@Toro_Unit) 2015, 9月 13
開発において、テストをした場合に開発をしていた環境ではなかったエラーがテストの環境では出たりして、テスト→修正を繰り返すことがあります。
バグがバグを呼びそのうち何が仕様なのかも分からなる地獄へ陥ります。
プログラマーではないので開発をしたことはないですが、開発のテストに関わったことはあるので同じような経験があり、すごく共感できました。
共感したらダメだけど。
開発が終わった後にテスト工程を設けてしまうとバグ地獄に陥ってしまうので、短期間のテスト、そしてテストも自動化しましょうという話でした。
ちょっと詳しくないのですが、Travis CIとかPHPUnit、Gitを使えば、コミットしたときに自動でテストが開始し、エラーがあった場合開発に携わっている人全員に通知したりできるようです。
地獄に陥らないためにも、短期間のテストとテストの自動化はすごく重要ですね。
CIとはなんぞやという人は、WordCamp Kansai 2015のCIハンズオンで使われたスライドを。
Kintone・WordPressハンズオン
WordBench京都の後半はKintone・WordPressを使ったプラグイン開発をしました。
スピーカーはKintoneのエバンジェリスト・細谷さんです。
エバンジェリストって初めて聞いたので、意味を調べてみました。
1 キリスト教で、福音(ふくいん)伝道者。
2 製品などの啓発・宣伝を行う人。
コトバンク
なるほど、製品の啓発をする人なんですね。
写真はキリスト教の伝道者でもおかしくない感じですが。
ハンズオンで作るプラグインは、
アンケートフォームで入力された内容を、WordPressのショートコードでサイトに表示させるものです。
Kintoneを使うと、アンケート内容や顧客の情報を管理するアプリケーションをはじめ、いろんなものをプログラミングなしでつくれるそうです。
Kintone
30日の無料お試しなら、2,3分で登録完了するので、すぐに始められます。
画面はこんな感じで、ドラッグ&ドロップの直感操作で作ることができます。
当日のスライドはこちら。
かなり詳しく書いていただいてます。
当日はMAMPがどうかなっててプラグイン完成までたどり着けなかったので、後日スライド見ながらやってみます。
このスライドは109枚。
2日間で見たスライドのページ数ハンパない。
さいごに
どちらの勉強会も最後は懇親会でピザとお酒。
参加者の方たちと話をして、食べて飲んで。
楽しくて、充実した土日でした。
これゲットしました。