Movable Type 構築における分業とコーディング（ MTDDC Meetup TOKYO 2015 登壇フォローアップ ）

当日のセッションの様子

当日の資料を bit part のブログで紹介されていましたので、こちらでもあげておきます。

MTDDC Meetup TOKYO 2015 でセッションしてきました | bit part blog

「リモートワークで加速する」というのを見出しにしていましたが、一番重要なのは、分業できるような体制を作っておくというところです。

「分業ができる」というのは、ただ単純に作業を分割して渡せるというのではなく、分業をすることで作業を効率的に回せる体制にしているのがポイントになります。

HTML・CSS・JavaScript のコーディングと Movable Type 構築の分業

チーム分業で進行しているメリットとして、全体の構築時間の短縮が図れることが挙げられます。

HTML・CSS・JavaScript と Movable Type 構築 は別の作業者が行うことで、同時に進行することができます。特に Movable Type の実装では、設定を先に進めることで、設定の項目に不足がないのかなどの確認をしながらや実装上問題がないのかなどを、テーマにHTMLを当てる作業をする前に確認すしながら進めることができます。

互いに得意な分野を専属で進めることが可能なため、作業スピードが早いまま進行できるというのもポイントです。

Movable Type などの CMS で利用される前提の HTML

コーディングとCMS構築を分業していることでよく問題とされるのが、CMSに入れることが考慮されていないマークアップやスタイル設計になってしまっていることです。

例えば HTML の繰り返しだけで済ませられる部分の途中で、デザイン再現のためだけに、分岐が入る class などを入れてしまったり、そもそも繰り返しを前提としていないために、記事が複数入った時に余白がデザインどおりになっていなかったり、デザインで想定されていないテキスト量やサイズが入った際に崩れてしまう、などが挙げらます。

よくある一例：見出しの右余白やアイコン下

CMS やシステムの View の実装をしている人であると気づきやすいのですが、デザインだけしかしていないデザイナーやコーダーは、問題配慮を意識していないために、CMS に入れた際に問題になったりすることが多いのです。

見出し

<h3 class="heading--demo1"><i class="fa fa-hand-o-right"></i>見出し</h3>

.heading--demo1 {
  padding-left: 20px;
}
.heading--demo1 i {
  margin-right: 10px;
}

デモ

デザイン時に見出しや１行でも問題ないような文量の見出し例で作られている場合が多いです。

しかし、運用上複数行の文量がはいることがあり得る場合、長い見出しがはいってまうと、以下のような表示なります。

デモ

右側の余白がないため、いっぱいまで詰まってしまう（ブラウザのサイズによっては１文字分広く空いているかもしれませんが）表示になる場合があります。また、デザインとして OK なのか NG なのか判断つかない部分ではありますが、アイコン下にもテキストが回り込んでしまう状態になっています。これが許容な場合は問題ないですが、許容されないで気にするクライアントもいるため、予め確認したり配慮しておく部分となります。

<h3 class="heading--demo2"><i class="fa fa-hand-o-right"></i><span>２行以上が表示される見出し見出し見出し見出し見出し見出し見出し見出し見出し見出し見出し見出し見出し見出し見出し見出し見出し見出し見出し見出し見出し見出し見出し見出し</span></h3>

.heading--demo2 {
  padding: 0 20px;
}
.heading--demo2 i {
  float: left;
  margin: 5px 10px 0 0;
}
.heading--demo2 .span {
  display: block;
  overflow: hidden;
}

配慮のスタイルを入れたデモ

こちらのスタイルがいいというわけでは全然なく、私の場合はクライアントから上記のようなスタイルにしてほしいという依頼が多いだけです。

配慮のスタイルでは、アイコンを float:left にして、テキストの部分を block スタイルにした span に oveflow: hidden; を入れて回り込みを解除しています。今回の例では、このスタイルにしましたが、実案件などではアイコンを :before の擬似要素にいれて配置することのほうが多かったりします。

CMS を配慮することで

CMS に入れるということを前提にした HTML・CSS にしてコーディングをしておくことで、手戻りなどが少なくなり、結果的には作業時間の短縮にも繋がるので、ここは分業しないという場合でも対策しておくべき箇所です。

静的HTMLジェネレータの活用

先程はコーディング時のデザインにおける運用時の配慮についてを簡単にですがご紹介しました。しかし、我々のチームでの取り組みはそれだけではないです。

もう一つ、HTMLのコーディング時から、共通部をインクルードして、それを CMS 実装者に渡せるようにして作業をしています。

PHP のインクルードでやっていた頃もありました

以前は、HTMLのコーディングをするときでも、ヘッダーやフッターなど PHP のインクルードを前提として進めていたこともありました。しかし、サーバーの用意などに手間がかかってしまうという準備の手間が発生したり、確認用にサーバーの設定も必要だったりすることもありました。

PHP を使うというのも簡易なのでありなのですが、手間を出来るだけとりたくないという理由から、今は PHP のインクルードで共通部分を作るのをやめました。

静的 HTML ジェネレータの活用

なんとか簡単にできないかと、次に採用したのが、 jekyll でした。

Jekyll • Simple, blog-aware, static sites

GitHub でも使えるということもあり、案件でも活用できそうだなと考え使い始めたのですが、徐々に遅さが気になるように。

その次に使ってみたのが Middleman です。

Middleman: Hand-crafted frontend development

jekyll 同様に Ruby で動かし、Sass も当時使っていた Connpass も、そして Livereload まで付いている！なんて楽なんだ！と当時は使っていました。しかし、様々な案件を行っていくうちに、自分たちのやりたいことでの柔軟性に欠けてしまう点がいくつかでてきました。

gulp で Metalsmith を利用

そして最終的に今活用しているのが gulp です。 gulp に、静的HTMLジェネレータの Metalsmith を組み合わせて利用をしています。

Metalsmith

Metalsmith はプラグインベースで静的HTMLを作成するツールなので、実際に利用しているテンプレートはこちらではなく、 Swig という JavaScript Template Engine のほうです。

Swig - A Node.js and Browser JavaScript Template Engine

Swig だけでは面倒な記事の挿入部分だったり設定回りを Metalsmith が補ってくれているようなイメージです。

これらは Node.js で動作可能なので、 同じく Node で動く gulp との組み合わせも楽なので、こちらを採用することにしました。

ちなみに Node.js 製だと Assemble や Handlebars.js などもあるのですが、これまでのやりたかったことからシンプルに移行できたのが Swig だったので、Metalsmith + Swig で構築をしています。

静的HTMLジェネレータの導入で連携

では、実際にどのようにして、ジェネレータを要して、CMS 実装者に渡しているか。

スライドの途中にも紹介したのですが、以下の様なことが可能になります。

HTML

<body{% if page == 'top' %} class="page--top"{% endif %}>
{% include 'header.html' %}
  <div class="layout-container">
{{ contents | safe }}
  </div>
{% include 'footer.html' %}
</body>

これを Movable Type の MTML に置き換えてみると以下のようになります。

MTML

<body<mt:Unless name="page_class"> class="<mt:Var name="page_class" />"</mt:Unless>>
<mt:Include module="header.html" />
  <div class="layout-container">
    <mt:EntryBody />
    <mt:EntryMore />
  </div>
<mt:Include module="footer.html" />
</body>

インクルードなどの部分を置き換えるだけです。

これで、HTML → MTML にするとき、対応箇所が明確なので、連携が比較的楽になります。

どうやってつかうの？

Metalsmith の導入方法は、以前ブログでかいていたので、是非そちらを参考にしてみてください。

Nodeで動作する静的サイトジェネレータ「metalsmith」を使ってみた

静的サイトジェネレータ「metalsmith」を gulp で使う

上記のリンクとは若干違う構成で、最近は以下のようにしています。

gulpfile.js：HTML部分抜粋

gulp.task('metalsmith-build', function (done) {
  return cp.spawn('npm', ['run','metalsmith'], {stdio: 'inherit'})
    .on('close', done);
});

gulp.task('html', ['metalsmith-build'], function () {
  return gulp.src(['./**/*.html'])
    .pipe(gulp.dest('html'))
    .pipe(browserSync.stream());
});

Metalsmith の書き出しに合わせて BrowserSync の reload をするのではなく、 一度HTMLをビルドディレクトリではなくて一時ディレクトリに出力したあとに、実際に置きたいディレクトリに出力するようにしています。

このように、HTML → CMS の連携時にも優しい工夫をしておくと、渡したあとにも迷わず共通部分をわけて作ったりすることができるため、静的HTMLジェネレータの活用はお薦めポイントになります。

jade などではダメなのか？

よくこの話をすると、jade とかもっと便利になるツールがあるという話をされることもあるのですが、自分たちはそれを利用していません。自分たちがコーディングをしたあとに、別の作業者が CMS などに入れる際に、そのまますぐに利用ができないためです。

HTML 形式で共通部分をわけて作っておくという状態が、その後の作業を楽にするポイントです。jade で作ってしまうと、 CMS などのテンプレート実装者が見るのは、デプロイされた HTML のほうになってしまい、そこから、どのモジュールを取り出すのかなどを考える手間が多少なり発生してしまうことになります。

使えないということではなく、その後の連携を比較的楽にするためのことなので、もしも HTML の形式ではないほうが良い、ということになるのであれば、そちらを利用するほうが良いと思います。

分業・リモート前提だけではなく一人でも会社でも同じ

話は一度戻り、分業やリモート作業の効率化について。CMS の配慮もそうですが、分業で行うようなことやリモートで作業する・しないにしても、どちらでも効率化に繋がる要素はたくさんあります。

しかし、一人で作業をしたり、会社内で回すようなときは、面倒になってやらないというものが多かったりします。

分業でも一人でも、リモートでも会社内でも、いずれにしても効率化を目指すのであれば「やっているべきこと」であることには変わらないのです。

bit part とそのパートナー同士は、その「やっているべきこと」をキチンとやっているだけで、それをやっているからこそ、リモートだろうと分業だろうと、効率的にスピーディーに作業をすることができるようになっているだけです。

最後に：余談

静的 HTML を JS のテンプレートで書いて渡すと楽！とは書いたのですが、これが同じ理論で MTML とコマンドラインで静的 HTML が出力可能なのであればもっと楽なのかなと思いました。

神がきっとなんとかしてくれるということを願います。

掲載写真

Photographer

Zengame

License

Creative Commons (by)