デジカメを購入しました。フジのFINEPIX F70EXR。

ついでにflickrのアカウントも取ってみました。
http://www.flickr.com/photos/webbingstudio/

私は、写真を撮るのも撮られるのも苦手です。
これまでは、携帯でスナップを撮るくらいしかしてきませんでした。

ウェビンブログ：勉強会とデジカメと顔出しの微妙な事情

そんな私がカメラを買ったのには、お仕事やプライベートなど、いろいろ思うところがあってのことです。

デザインの勉強になる（かも）

写真を撮るときは、大なり小なり、自分が観ているものを「被写体＝作品対象」として意識することになります。
今まで何となく観ていた些細なものも、意識すればデザインの要素であるわけです。

デザインスキルを向上するためには「何故これを美しいと思ったか」「何故このような色／構図にすると美しくなると思ったか」を考えることが大切だと言われます。
WEBデザイナー・イラストレーターに写真好きが多いのは、単なる素材集めのためだけではないのです。

デジカメだとクリアに観られる

私は生まれつき、斜視・乱視・眼球振動があります。なので、眼鏡をかけても遠くの景色（特に夜景）は鮮明に見えません。
覗き込むタイプの銀塩カメラで、写真をうまく撮れなかったのもこのせいです。

ですが、Twitterで知り合った写真好きな人たちの作品を観ているうちに
「あれ？風景をデジカメで撮って家で見れば、綺麗に観られるんじゃね？」
「て言うか、今のデジカメはディスプレイ見ながら撮れるから、私でも失敗しないんじゃね？」
と今更気付きましたwww

意識的に「苦手」を克服する

私が写真を撮るのが苦手なのは、銀塩カメラ時代にピンボケ写真ばかり撮っては凹んできたからです。

私が写真を撮られるのが苦手なのは、自分にコンプレックスがあるからです。

うまく撮れないと思うなら、オートフォーカスのデジカメを使えばいい。

撮られるのが嫌なら、少しでもコンプレックスが減るように自分を磨けばいい。

そういう風に、自分の意識を変えていこうと思いました。
それは今年の私のテーマでもあります。

自分の記録を残す

今のお仕事に就くまで、あまり自分の記録を残したいとは思えませんでした。
ですが最近は、勉強会やオフ会で沢山の人に会い、いろいろな場所へ行くようになって、少しずつ「自分が体験したことを残したい」と感じるようになっています。

文中で貼っている写真は、札幌エスタ＝ビックカメラ前のブリッジから試し撮りしたものです。
札幌駅前を見渡すことができる、なかなかいいところです。
iPhoneやMacbookなどの大きな機材を買ったときや、打ち合わせ等、お仕事の節目に通ることも多く、なじみの深い場所です。

使い慣れていなくて結局ヘタレな写真になってしまいましたが…
（本当はもっとひどかったので補正しています）

年が変わってから、いろいろとこれまでしてこなかったことを試したりしています。
「下手な鉄砲も数撃ちゃ当たる」というやつで、
どれかひとつくらい、いや全部がちょっとずつ、今後の役に立ってくれるかもと期待してみる今日この頃です。

つぶやく

MovableTypeの初期テンプレートセットには、「最新記事のフィード」という、Atom1.0形式のフィード用テンプレートが含まれています。
サイトから配信するRSSフィードは普通は「新着記事」になるので、よほどこってりしたカスタマイズをしない限り、このテンプレートをそのまま使うことになります。

しかし、テストサーバーで記事を入れ込み→本番サーバーに移行という流れで構築をしている場合、このテンプレートの扱いにはちょっとした注意が必要です。

「最新記事のフィード」テンプレートの14行目に、以下のようなコードがあります。

<id><$mt:EntryAtomID$></id>

MTタグ「<$mt:EntryAtomID$>」はAtomフィード内で各エントリーに一意のIDを振るために用意されているものです。

これが、再構築すると以下のような文字列に変換されるのですが、

tag:[記事を書いた時のブログのドメイン名],[記事の公開年]:[ブログトップのサーバー内相対パス]/[ブログID].[記事ID]

[記事を書いた時のブログのドメイン名]と、[ブログトップのサーバー内相対パス]は、ドメインやサーバーを変更してもそのままデータベースに残ってしまいます。

つまり、もしも ｈttp://exmaple.testserver.com/test/ というURLにテストブログを作って記事の入れ込みをしていた場合、本番サーバーへ移行した後も、

tag:exmaple.testserver.com,2010:/test//1.999

という文字列がAtomフィードに残ることになります。

AtomIDは一意の値を振るためのものなので、存在しないドメイン名が残っていても問題はないようですし、わざわざソースコードを見ない限り、このIDが一般の閲覧者の目に触れることはありません。
ですが、自社サーバーで作業していた場合などは、やはりテストサーバーのドメインは知られたくないところです。

対策としては、データベースを直接書き換える手も考えられますが、<$mt:EntryAtomID$>自体を使用せず、他のMTタグを組み合わせて同じような書式を作ってしまう方法が手っ取り早いです。

<id>tag:<$mt:BlogHost$>,<$mt:EntryDate language="en" format="%Y"$>:<$mt:BlogRelativeURL$>/<$mt:BlogID$>.<$mt:EntryID$></id>

上記のようにタグを書くと、再構築をした段階のドメイン・サーバーの情報を元にIDが再発行されます。

つぶやく

現在地共有ゲーム？の「foursquare」をはじめてます。

foursquareのはじめ方については、こちらの記事が詳しいです。
5分でわかる foursquare の始め方 | WWW WATCH

何日か利用してみて、このサービスをずっと楽しむためのポイントがわかってきたので、これから参入する人たち、プライバシーが心配で迷い中の人たちのためにまとめてみます。

１．遠くの有名人より、近くの一般人

初期登録すると、Twitterかfacebookのfollower / friendsで既にfoursquareをはじめている人たちに、リクエストを送ることができます。
とりあえず、Twitterのfollowerの皆さんにひと通りリクを送ってみたのですが、何日か経ってひとつ失敗したなあと気付きました。

私はTwitterでは、東京を中心に、本州在住のWEBクリエイターをたくさんfollowしています。
彼らのつぶやきはとても勉強になるからです。
でも、彼らがチェックインしている場所にいくことはまずないので、foursquareでは彼らの行動は参考にならないし、あんまり面白みがないのです。
（ドワンゴなどの著名企業が出るとおおっと思いますがw）

むしろ、同じ札幌に住んでいる、WEB屋でない普通の人たち（Twitterであれば道民部など）を集めた方が、ずっとfoursquareを楽しめるわけです。

２．ShoutとTipsは違う

見落としがちですが、チェックインするときにTwitter等に流す「Shout」は一時的なもので、foursquareで共有される情報とは別です。
（スナップショットはiPhoneアプリの画面です）

そこのポイントに関する情報を恒久的に残したい場合は、上部のタブにある「Tips」で登録します。

なので、TwitterにShoutでpostしつつ、foursquareにも情報を残したい場合はShoutの文言をコピーして、Tipsにペーストするということをしなければいけません。
ただし、後で自宅のPCから追加することもできるし、まだ行ったことがないポイントにTipsを投稿することもできます。

意外とこれに気付いてない人が多いらしく、今のところあまりTipsを投稿している人はいないみたいです。
今後、foursquareが日本で定着するには、海外のように生のクチコミ情報を共有したり、クーポン発行などのショップとの提携が必要なわけで、もっとMAYOR争い以外の楽しみ方が広まればと思います。

３．チェックインするのはチェックアウトするとき

foursquareをはじめるときに、プライバシー面でいちばん心配なのが
「現在地をチェックインしたことで、自分の足取りをつかまれてしまう」
というところです。

完璧ではないですが、私は簡単な予防法を実行してます。
「そこに来たとき」ではなく、「そこを離れるとき」にチェックイン。
foursquareで重要なのは「何回チェックインしたか」であって、「何時にチェックインしたか」というのはけっこうどうでもいいのです。

MAYOR争いの楽しみは無くなってしまいますが、変質者被害などが心配な女の子たちは、チェックイン数が多い街中のポイントを、広く浅くチェックインしていくようにしていけば、安心して楽しめると思います。

くれぐれも、自宅でチェックインしてしまわないようご注意を。
（すぐ消すことはできますが）
iPhoneアプリは、うっかりタップしない位置にアイコンを置いておいた方がいいです。
iPhoneへのパスコードロックも忘れずに。

そんなわけで、つらつらとfoursquareの楽しみ方を書いてみましたが、同地域の知り合いが少なかったり、都市圏に住んでいないとなかなか楽しさを見出すのが難しいサービスだなあ、というのが実感です。
地方都市に住んでる人たちは、気心の知れた友達に声をかけて、ゲーム感覚で一斉に始めてみるのがいいかもしれないですね。

つぶやく

前回の記事で書いた通り、地図を追加する機能を標準で持っていないMovableTypeに、それを実装しようとすると、この記事を書いた時点では有力なプラグインがなく、面倒なカスタマイズが必要になります。

あんな長いチュートリアルを書いておいてなんですが、どうしてもMovableTypeを使わなければならない案件でないなら、標準で実装しているCMSを提案した方が、予算・工数の面からも確実というものです。

私が把握している、投稿画面に地図追加機能を実装しているCMSは下記の通りです。

1. a-blog cms
2. concrete5
3. bingo!CMS
4. Jimdo

このうち、bingo!CMSはYahoo!マップ、それ以外はGoogleMapsのAPI Keyを取得する必要があります。

地図の目的地を検索し、中心に持ってきて吹き出しのコメントを入力する、という操作感はどれもほぼ同じです。
尚、冒頭のスクリーンショットはa-blog cmsの画面です（私の本サイトの投稿画面なので、デフォルトとはカラーリングが異なります）。

ただし、四つのCMSは設計思想が微妙に異なっています。
a-blog cmsはMovableType・WordPressと同様に、カテゴリーや時系列のアーカイブでコンテンツを出力する更新方法が基本設計ですが、残りの三つは実際に表示されているコンテンツ内をクリックして、ホームページビルダーやDreamweaverのように、直感的に編集させる更新方法が基本になっています。

コンテンツが少なく、各ページの構成が異なるサイトであれば下の三つの方が構築しやすいですし、前の記事のような、入力フォーマットがが決まっているコンテンツを大量に生成するサイトであれば、a-blog cmsが適していると考えられます。

個人的には、MovableType・WordPressの代替として選択するのであれば、管理画面のカスタマイズのしやすさの点からも、機能面の近さからもa-blog cmsをお勧めしたいところです。

つぶやく

需要が高いと思いますが、MovableTypeは意外にも、2010年1月の時点でこの機能を追加できる有力なプラグインがないようです。
手作業でのカスタマイズ方法は下記ページで紹介されていますが、投稿画面編集・GoogleMapsの座標取得の知識が必要です。

Movable Typeの記事投稿画面にGoogle Mapsを表示｜Skyward Design

もうひとつの選択肢として、「Mapper」プラグインを使って、管理画面で入力した「住所」から地図を自動表示させる方法があります。
今回はさらにjQueryプラグイン「thickbox」を連携させ、モーダルポップアップで表示するカスタマイズを紹介します。

デモサイト

本記事のデモサイトはこちらです。（ベース：MovableType5）

Mapperプラグインデモ ＊ 道民部がたむろしている店

時間ないので店は数件しか登録してないですが…w

お店の個別ページで、「地図を表示する」リンクをクリックすると、住所を参照した地図がthickboxのポップアップで表示されます。
住所欄には正規版の機能であるカスタムフィールドを使っていますが、追記欄をうまく活用すればMTOSでも可能です。

注意点

住所から検索・変換をしているため、正確性にやや難があります。
（デモサイトの場合、串鳥の座標が東急の真上になってしまってます）
吹き出しの内容も詳細指定するなど、完璧さを重視する場合はGoogleの公式コードを直接書き込むなど、別の方法を検討してください。

プラグイン・ライブラリを用意する

まず、カスタマイズに必要な素材を用意します。

「Mapper」は、任意のMTタグ内に書かれた[map:住所]という「Mapタグ」を地図に変換するMovableTypeプラグインです。

http://code.google.com/p/ogawa/wiki/Mapper_Plugin

「thickbox」は、リンクに特定のclassを指定するだけで、画像やHTMLをモーダルポップアップさせるjQueryのプラグインです。

http://jquery.com/demo/thickbox/

jQuery本体も、まだ使ったことがない場合はこちらからダウンロードしてください。

http://jquery.com/

thickbox自体の設置方法はここでは割愛します。必要なファイルをサーバーにアップロードしておいてください。

GoogleMaps API Keyを入手する

Mapperを利用するには、API Keyを取得する必要があります。

下記ページで利用するサイトのURLを登録し、キーを取得してください。

http://code.google.com/intl/ja/apis/maps/signup.html

プラグインを有効化する

MovableType内にMapperをアップロードします。
管理画面内のMapperの設定画面に入ると、GoogleMaps API Keyを求められます。さっき入手したキーをコピペして保存してください。

住所のカスタムフィールドを作成する

住所欄のカスタムフィールドを作成します。
ここでは「CFaddress」としました。ここのベースネームを変更した場合や、追記を利用する場合は、以降のGoogleMapsを呼び出すテンプレートのMTタグを読み替えてください。

ブログ記事テンプレートを２つ作る

Mapperで生成される地図はJavaScriptを多用しています。このため、コンテンツ内のMETAタグの指定や、今回使うthickbox等のjQueryライブラリと衝突しやすいです。
それを防ぐために、地図だけインラインフレームで呼び出します。

MovableTypeは同じアーカイブで出力URLが違うページを複数作ることができるので、これを利用して「ブログ記事テンプレート」を２つ設定します。

画面のように設定すると、

ブログ記事

[ブログのURL]/[カテゴリー]/post-[エントリーID].html

Google Maps

[ブログのURL]/[カテゴリー]/map-[エントリーID].html

という、二種類のHTMLが記事ごとに生成されることになります。

コンテンツ用テンプレートの作成

「ブログ記事」という名前のテンプレートの方が、コンテンツ（地図を呼び出す本ページ）となります。
HTMLソースを書き、head内に以下のコードを追加してください。

<link rel="stylesheet" type="text/css" href="[ファイルへのパス]jquery.thickbox.css" media="All" />

<script type="text/javascript" src="[ファイルへのパス]jquery.js"></script>
<script type="text/javascript" src="[ファイルへのパス]jquery.thickbox.js"></script>

地図を表示するポップアップのリンクを表示したい個所に、以下のようにコードを書きます。
a要素内のURLの詳しい記述方式については、thickboxのページ内の「Inline Content」の項を参照してください。

<mt:If tag="CFaddress">
<a href="#TB_inline?width=600&height=480&inlineId=mapframe&modal=true" class="thickbox">&raquo;&nbsp;地図を表示する</a>
</mt:If>

さらにページの末尾、bodyの閉じタグの上あたりに、以下のコードを書きます。
フレームのwidthとheightは任意調整してください。

<mt:If tag="CFaddress">
<div id="mapframe" style="display: none;">
  <p class="map-title"><$mt:EntryTitle encode_html="1"$>の周辺地図</p>
  <iframe src="map-<$mt:EntryID$>.html" width="600" height="400" marginwidth="0" marginheight="0"></iframe>
  <p class="map-close"><input type="submit" value="×閉じる" onclick="tb_remove();" /></p>
<!-- /#mapframe --></div>
</mt:If>

重要なのは、インラインフレームの内部HTMLを指定している部分です。

map-<$mt:EntryID$>.html

上記のようにEntryIDタグを仕込むことで、２つ目のエントリーテンプレートを呼び出すことになります。

ポップアップ用テンプレートの作成

「Google Maps」という名前のテンプレートの方は、ポップアップ用です。以下のコードが全てになります。
地図のwidthとheightは任意調整してください。

<html>
<body style="margin: 0; padding: 0;">
<mt:If tag="CFaddress">
<mt:Mapper width="600" height="400" zoom="18">
  <p>[map:<$mt:CFaddress convert_breaks="0"$>]</p></mt:Mapper>
</mt:If>
</body>
</html>

Mapperで拡張されたMTタグを使い、カスタムフィールドの「住所」を表示します。
段落でマークアップさせないよう、「convert_breaks」モディファイアに「0」を指定しておいた方が安全です。

METAタグなどは敢えて指定しない方が、各ブラウザでちゃんと表示されるようです。

最後にテンプレートを再構築し、リンクをクリックするとポップアップが出るか確認してください。

つぶやく

私の場合、制作会社から依頼を請けることが多いので、そこの担当者＝ディレクター、またはその会社の、MovableType／WordPressのスキルを持つ制作の方がコードを見ることがあります。

個人でテンプレートの構築をしていた頃は、変数や独自タグを駆使してけっこう複雑なコーディングもしていたのですが、チーム制作に関わるようになってからは
「自分以外のテンプレート制作者が見ても、理解しやすい構造になっているか」
を考慮するようになりました。

特に質問されることが多いのが、自分以外には見通しが利きにくい、以下の二つです。

• 何度も使い回す関係でモジュール化して、インクルードで読み込んでいる部分
• mt:SetVarやPHPの変数を使用している部分

特にMovableTypeの「mt:Include」には多彩な機能があり、下のようにモディファイアに変数の値を渡したり、

<$mt:Include module="Module_Hoge" foo="Var"$>

（↑読み込み先の「Module_Hoge」モジュールで変数名fooに値Varが渡されます）

「mt:IncludeBlock」という、変数の値を渡すことを前提としたタグもあります。

<mt:IncludeBlock module="Module_Hoge2">
Movable Typeへようこそ！
<mt:IncludeBlock>

（↑読み込み先の「Module_Hoge2」モジュールで変数名contentに値「Movable Typeへようこそ！」が渡されます）

ですが、私はこういった変数の渡し方はできるだけ避けています。

このような変数の渡し方をコード全体に渡ってやってしまうと、モジュール側の方のコードを見て
「あれ？ここで参照されてる、変数fooってなんだろう」
と思ったときに、読み込み元と思われるベーステンプレートを上から下まで探さなければいけなくなります。
繰り返しや条件分岐などの一時変数以外は、わかりにくい場所で変数を宣言するのは避けるべきです。

私の場合、サイト内で頻繁に利用されることがわかっている固定値は、
「mt:SetVars」「mt:SetVarBlock」などを使い、テンプレートの先頭でまとめて宣言してしまうようにしています。

全テンプレートに使用する変数はやはりモジュールとなりますが、少なくとも変数について訪ねられたら
「グローバルテンプレートの『Module_Config』を見てください」
とか
「テンプレートの文書宣言の次辺りに書いてあります」
と、簡単に変数を宣言している場所を答えることができます。

モジュールの呼び出し方に関しても、

と、外側のレイアウト用のdivが残るように、かつHTMLタグを分断しないように呼び出し、各テンプレートのHTML構造を見通せるよう気を付けています。

また、複雑な条件分岐などをしているところでは、mt:IgnoreやPHPコメントなどで説明を添えることも多くなりました。

<mt:Ignore>### ○○のときは△△を表示します ###</mt:Ignore>

これまでのTipsでもう出てきていますが、変数やモジュールの命名に関しても
「Global_」や「Module_」などの接頭語を統一して、それらが何に使われているのかが名前を見ればわかるようにしているのも、テンプレートをわかりやすくするための工夫のひとつです。

…と、何だか高度なことをやっているような書き方をしましたが、これらはシステムそのものを作り、かつ日常的にチーム制作をしているプログラマにとっては、基本中の基本だろうと思います。

「デザイナー」を名乗っていると、デザインをテンプレートで再現することに集中しがちになりますが、HTML/CSSコーディング同様、テンプレートの構築もプログラミングの一種です。
テンプレートコーディングに関しても、より早い構築・改修ができるよう、定期的にブラッシュアップをはかりたいものです。

つぶやく

あけましておめでとうございます。

ちょっと前までは平成生まれも珍しく、ネットをしている人もほとんどいなかったのに、気がつけば21世紀も10年過ぎました。
そして私は春にはさんじゅうg(ry

今年の年賀状のテーマを、中島敦の短編「山月記」にすることは、半年くらい前から決めていました。
自らの臆病な自尊心を飼い太らせ、虎に変わってしまう主人公・李徴（りちょう）の独白には、フリーランスのクリエイターは皆、何か思うところがあるんじゃないでしょうか。

私は年賀状のイラストに、前の年にあったことを絡める傾向があります。
（昨年の年賀状はSecondLifeをイメージしています）
当初は単に、月に吠える虎の構図になるはずだったのですが、私らしいというか、ややひねりが入った一枚になってしまいました。

昨年の後半、自己管理不足やストレスなど無理がたたって、メンタルの持病がひどく悪化しました。
私の「虎」が、近しい人に噛み付いたり、Twitterのタイムラインに吠えまくりました。

虎になった李徴に再会した親友・袁（えんさん）の前に、李徴は姿を見せることはありません。
李徴の苦しむ訴えは、動物たちには恐ろしい吠え声にしか聞こえません。

だけど私の場合、
家族や友人（袁）は私の様子に戸惑いつつも見守ってくれたし、
Twitterのfollowers（動物たち）はつぶやきに耳を傾けてくれました。
お取引先（月）は私のスキルを必要として、変わらずお仕事を回してくれました。

なので私は、年賀状の虎を吠えさせませんでした。
Twitterのログに残っていた虎も、できるだけ消しました。

李徴の言う通り、虎になってしまった方がぶっちゃけ楽でした。
だけど虎はWEB制作ができません。
私はこの仕事をまだ投げ出したくはありません。

今年の年賀状は、この仕事をできる限り続けて行くという誓いと、
お世話になった皆様への感謝を込めさせていただきました。

今年も頑張ります！

つぶやく

レース編みが趣味だった母の影響で、小学校のときからやっています。
写真の中央にある皮ケースのかぎ針セットは母から譲り受けたもので、四十年近い年季ものですがしっかり現役です。

WEB制作に出会う前は講師を目指して検定を受けていたこともあるので、雑誌やショップなどで下調べをしたあと、採寸・製図・目数段数の計算などして、全て手作りします。

…と書くとなんだかかっこよさげですが、最近は本業が不調なときにしか手が進まず、ひと冬に一着できればましな方です。
昨年はマフラーしか作れませんでした。

今作っているカーディガンはこのあと長めの襟をつけて、背中の穴にウエストを絞る紐を通せば出来上がりです。
モコモコしていますが、最終的に固めにアイロンをかければ、今風の風合いになります。

一見エコな趣味に見える編み物ですが、毛糸を買って手作りすると、同じものを店で買う場合の数倍の費用がかかります。
リサイクルショップで買ったニットをたおす手もありますが、洗い直し、くせをとって「かせ」に巻くのにこれまた数倍の手数がかかります。

そこまでして何故やるかと言われれば、「好きですから…」「気分転換になりますから…」としか言いようがありません。

仕事が趣味に限りなく近い今の私は、とても恵まれているし幸せですが、こういう「誰にも気兼ねなくできること」にも時間とお金を投資できる余裕は、持っていたいと思います。

つぶやく

新しい技術を得ることも大切ですが、今の作業、ブラッシュアップできてますか？

iPhoneアプリ「HTML/XHTMLタグ辞典」が人気の、大藤幹先生の新刊「XHTML&CSS超高速コーディング術」の出版記念セミナーが、アップルストア札幌で開かれました。

今回は「コーディング＝カンプを元にHTMLとCSSを作成する業務」を専門に扱う制作会社「牧野工房」の協力を受け、短時間で正確、かつ美しいコーディングを行うための、牧野工房の実践的なノウハウが紹介されています。

コーディング専門の牧野工房
スキルパートナーズ株式会社

本のPRになると思うのでNDAに反しない範囲で書きますと、私はこの牧野工房さんとお仕事をさせていただいたことがあります。

その際にワークフローの一部を拝見することになったのですが、とにかく驚いたのが、書籍の協力者である、大杉さんのコーディング技術と、徹底した作業工程の管理体制でした。
ルールが厳しいのはもちろんですが、それら全てに理由付があり、しかもコーディングスキルの向上につながります。
セミナー内で大杉さん自身が
「牧野工房のルールに従っていれば、IE6でも問題は発生しない」
と断言されていますが、大げさな話ではありませんでした。

そのような経緯で、私自身も牧野工房のコーディングルールの影響を大きく受けています。
今回の書籍が出版となったのも、大藤先生がハンズオンセミナーを通して大杉さんのスキルに感心したからなのだそうです。

セミナーでの紹介によると、テーマは「手戻りをなくすこと」。

1. 基本をしっかり守る
2. 手順に沿って進める
3. 情報をしっかり管理する

という、当たり前のように見えてずさんになりがちな、牧野工房の実践テクニックが公開されています。

牧野工房が使用している工程管理表・テンプレートが同梱されていたり、大杉さん考案の「シャドーコーディング」(いきなり書くのではなく事前に構造をイメージする)についても触れられていますので、WEBデザイナー・コーダーの方は是非ご一読を。

何故私がこんなに薦めているのかというと、良いコーディングルールの普及・共通化は業界全体のワークフローの改善につながっていくからです。

私のようにフリーランスでやっていると、様々な会社のコーディングをお手伝いすることになります。既にコーディングを終えた静的コンテンツのCMS埋め込みなどもすることがあります。
私が全て作業する案件ならいいのですが、普段行っているものと違う（場合によっては効率の悪い）ソースコードに合わせるのはなかなか厳しいものがありますし、工程にもムダが出てしまいます。

HTML5の仕様が発表され、つい新しい技術に目が行ってしまいがちですが、基本をしっかり守り、ブラッシュアップすることを忘れないようにしたいものです。

つぶやく

「a-blog cms」の新バージョン、1.2.0がリリースされました。
主な追加機能は以下の通りです。

1. WYSIWYGエディタの追加
2. 絵文字の入出力に対応
3. ショッピングサイト機能(メール通知のみのシンプルなカートが標準搭載)
4. ルール(使用するテーマの条件分岐)に「正規表現」が追加
5. 出力ソースのクリーンアップ
6. モジュールの追加

入力形式にWYSIWYGが加わったことで、一般のブログやWordに慣れている更新担当者がいる案件にも対応しやすくなったと思います。
制作する立場としては、やはりルールの正規表現対応や、モジュール追加が興味深いところです。
導入事例紹介のページもどんどん厚みを増しているので、今後が楽しみです。

前の記事にもある通り、私＝WebbingStudioは、a-blog cmsのビジネスパートナーになりました。

制作会社ではなく、しかも自分からCMSを選択する機会が少ない個人事業主の私がどうしてa-blog cmsを支援することにしたのかというと、
「制作会社・クライアント双方の意識を変え、成長させる」
可能性に強い興味を持ったからです。

制作会社側の意識

MovableType・WordPress（特にWP）での小規模な構築案件を重ねると、制作者はこんな考え方に慣れてきてしまいます。

• テンプレート化すると、もうDreamweaverなどのオーサリングソフトで編集できない
• HTML・CSSを完全に完成させてからでないと動的部分に手をつけられない
• コンテンツは全てCMSの管理下に置くものだ
• 管理画面・投稿画面は配置が決まっているものだ

大規模な案件を経験するとわかってくることですが、デザイン性が高く、かつクライアントが更新する可能性がほぼないコンテンツを無理にCMSの管理下に置く必要はありません。
ぶっちゃけ、ウェブページテンプレートなんぞなくてもいいのです。
むしろ今後更新依頼をもらえる余地を残しといた方が(ry

一般のブログ的なCMSは、これら静的コンテンツを動的コンテンツと切り分けるのが難しくなっていますが、a-blog cmsは特に意識しなくても、同時にオーサリングソフトで一括管理することが可能です。
（実際、私の本サイトのうち「About」と「Work」は普通の静的コンテンツです）

また、a-blog cmsは投稿画面も制作できるため、いかに更新担当者が作業しやすくするかを考えることで、「インフォメーションアーキテクト」や「アクセシビリティ」に対する意識も持つことができます。
これらは、今後のWEBデザイナー・コーダーに必須のスキルになっていくと思います。

プログラマはCMSに対する考え方が異なるので、彼らが加わるとまた事情が変わってきますが、少なくともプログラマがいない制作会社／プログラマが必要ない案件のワークフローを激変させる可能性を、a-blog cmsは持っているのです。

クライアント側の意識

私のように制作会社から協業依頼を請ける場合、はじめからMovableTypeに決まっている案件がひじょうに多いです。
クライアントが以下のような固定意識を持ってしまっているパターンも散見されます。

• MovableType以外のCMSを知らない
• 管理画面の配置が公開サイトと違う＝CMSとはそういうものだ
• MovableTypeとかいうのが有名だし実績も多いからとりあえずこれを採用すれば無難だ

もちろんMovableTypeは拡張性が高く安定した、良いシステムです。
管理画面の編集も可能です（a-blog cmsほど直感的でないですが）。
ですが、提案する側が「MTを前提としたディレクション」を行ってしまうのは、カスタマイズを扱う私としては、あまり良い傾向とは思えません。
更新手順が複雑になってしまっては意味がないです。

MTと同様に拡張性が高く、かつ設計思想が異なるa-blog cmsを選択肢に挙げることは、クライアントの意識を変えられる可能性もあるのです。

CSS Nite LP6に参加する前から、何らかの国産CMSをMovableType・WordPressと同様にサポートしようと検討してきましたが、私のお仕事の傾向もあって、最終的に、a-blog cmsがメインとなりました。

a-blog cmsは、制作会社とクライアントを「成長させる」CMSです。

a-blog cmsを触ってみてください。

つぶやく