ポケモンがたくさんとれる公園

結婚して半月が経ち、だいぶ生活が落ち着いてきました。
先週から、ウェビングスタジオとしての業務も再開しております。

今後は一般の土日祝以外に、木曜日もお休みをいただきます。
土曜日を勉強や自分のサイトの作業に宛て、日曜日と木曜日は完全に仕事をしない日にするつもりです。

これは以前から決めていたことで、夫の唯一の休みが木曜日というのが主な理由ですが、私自身の今後を考えてのことです。

ここ数年、勉強に充てる時間が取れないことが悩みになっていました。世の中はどんどん新しい技術が登場していて、この先もウェブの仕事を続けていくには必須の知識もあるのですが、通常業務をこなすのに手一杯で、勉強会の準備をプライベートの時間や睡眠時間を削ってやるような状況でした。

若い頃はそれでなんとかなっていましたが、40歳を超えたあたりから体がついてこなくなってきて、「ブログの更新や勉強に充てる休日」が必要だと考えるようになりました。周囲でも海外では週休三日だという話がちらほら出ていました。

一緒に暮らす人ができたことで、少しだけ必死に働かなくてもよくなり、その代わり、少しだけ家事が増えました。
ウェブの仕事は私の天職なので生涯続けたいですが、続けるために、敢えて仕事のボリュームを減らそうと思います。

しかし、初回から理想通りに行っていません。木曜日はのんびりできましたが、土日は働いていました…

まあ、人生は長いです。焦るとすぐ力尽きてしまうので、試行錯誤しながら新しいライフサイクルに慣れていきたいと思います。

このたび、北海道札幌市から愛知県豊橋市に転居し、結婚いたしました。
緊張のあまり「けっきょん」とタイピングしてしまったのは内緒です。

結婚は、一般にはプライベートのお知らせです。ですがフリーランサーの場合は事務的なご連絡もあり、全国の友人知人にご説明するのもなかなか大変ですので、公開記事とさせていただきます。

9月23日に書いた記事「CMSの管理画面でクラス名を変更できるようにしたことを後悔している」の続きです。

この記事を読んだプログラマの友人に
「モジュールに設定したクラス名一覧を資料化すればいいのではないですか？」
と聞かれました。

当初はこれについても書くつもりでしたが、結論から言うと諸々の問題で難しいのと、ますます記事が長くなるので追記しなかったのでした。

この件について改めて書いてみたいと思います。

モジュールID一覧を作ったことはある

一時期、管理画面で表示されている「モジュールID一覧」のHTMLをPDFに書き出し、資料として納品時にお渡ししていたことがありました。

a-blog cmsは、CMS内の設定（IDがnewsのカテゴリーのエントリーを5件呼び出す）に名前をつけて「モジュールID」として使い回すことができます。DrupalのViewsも同様だったと思います。
これもクラス名と同様、管理画面でしか参照できないものです。なので友人の指摘の通り、資料化しようと考えたのです。

ですが、これには以下のような問題がありました。

予算がつかない

これはウェブ制作全体の問題ですが、「サイトマップ」「マニュアル」以外の資料には、あまり価値を見いだされません。企画を重視していない案件では「カスタマージャーニーマップ」さえ予算がつくのが難しいでしょう。それ以前に私は受注制作がメインなので、予算に関われる案件はまずありません。

もしこちらから「モジュールID一覧もお送りしますね」と言っても、たぶん「いやー、いらないですよ！」と返事が来ます。
なので、できるだけシステム化して、こちらの見積内に組み込むことになります。よほど効率化しないとタダ働きになります。

やっぱり使われない

そうやって頑張って作成しても、サイトの改修自体がないことが多いです。私自身も完全納品だと、その後は声がかからないので使うことはありません。前回の記事のように、常時改修をお手伝いさせてもらっている案件もまれにありますが、全体の一割くらいです。
もしかすると、多くの納品先が、このような資料を必要としていたのかもしれません。しかし何も言われないのでわからないのです。あー、SNSでつながっている方、その後必要だったかこっそり教えて下さい…

サーバーと同期されない

オフラインの資料にしてしまうと、管理画面の内容を更新したときに資料も更新しなければなりません。資料と最新の状態が食い違うのはまずいです。 これは友人も指摘していました。むしろ資料作成を重視するプログラマさんやSIerさんは、こっちを気にすると思います。

管理画面の情報を常に閲覧できればいいのでは

そこで「管理画面に、モジュール関連の必要な情報だけを一覧できるテンプレートを作ればいいのでは？」と考えました。
テーマ内に含むようにできれば、毎回資料を作成する手数もなくなります。

a-blog cmsなら簡単にできるかもしれないと、管理画面にざっと書いてみたテンプレートがこれです。

<!-- BEGIN_MODULE Admin_Module_Index -->
<!-- BEGIN module:loop -->
mid: {mid}<br>
モジュールID: {identifier}<br>
<!-- BEGIN status#open -->
<span class="acms-admin-label acms-admin-label-info admin-status-label acms-admin-text-nowrap"><!--T-->有効<!--/T--></span><!-- END status#open --><!-- BEGIN status#close -->
<span class="acms-admin-label acms-admin-label-danger admin-status-label acms-admin-text-nowrap"><!--T-->無効<!--/T--></span><!-- END status#close -->
<br>
	<!-- BEGIN_MODULE\ Admin_Module_Edit ctx="bid/%{BID}/mid/\{mid\}" -->
	説明: \{description\}<br>
	追加クラス: \{module_exclass\}<br>
	追加属性: \{module_exattr\}<br>
	<!-- END_MODULE\ Admin_Module_Edit -->
<hr>
<!-- END module:loop -->
<!-- END_MODULE Admin_Module_Index -->

Admin_Module_Indexモジュールは、モジュールIDの最低限の情報を一覧表示するモジュールです。
ループ内でエスケープされているAdmin_Module_Editモジュールは、指定したモジュールIDの詳細情報を出力し、GET送信すれば編集可能にするモジュールです。
いずれも管理画面専用です。

• mid
• 識別名
• 有効／無効
• 説明文
• 追加クラス（モジュールのカスタムフィールド）
• 追加属性（モジュールのカスタムフィールド）

ここまで一画面で表示できればかなり便利になると思ったのですが…
残念ながらAdmin_Module_Editに属性値でIDを渡すことができないようで、説明文やクラスは表示できませんでした。何か間違えているのかもしれませんが。

となると、PHPを書いて、データベースへの直接のアクセスが必要になります。さすがにそこまでする必要があるかは微妙です。

リッチCMSに備えないといけない

かつては汎用CMSとは、本格的なエンタープライズCMSではなく、ごくごくシンプルなものでした。
ですが利用者が多いWordPressであっても、納品後にもコーディングに関与できる「リッチCMS」の採用が当たり前になっています。

制作側もこれまでのように作るだけで終わらせず、納品から半年後、一年後の改修で無駄な工数を食わないよう、対策を講じなければならなりません。
消化不良ですがこの話題はまたいつか。

突然「#10年間を振り返る」というハッシュタグが盛り上がっているのですが。

成功自慢か不幸自慢かネタ以外は流れていくだけの場で書く内容ではないでしょうよ。

という正論で殴りつつ、ブログに書きます。

10年前の写真。POKEN覚えてる？

10年間を振り返る

いろいろなコミュニティと関わりましたが、全体にはa-blog cmsとともに歩んだ10年間だった気がします。人生にも影響するとは思わなかったな…

2009年　34歳　CSS Nite LP6参加
2010年　35歳　a-blog cms Traning Campではじめて愛知県へ行く
2011年　36歳　CSS Nite in Sapporoの実行委員になる
2012年　37歳　Facebookページ本の執筆に参加
2013年　38歳　愛知県へ移住
2015年　40歳　baserCMSテーマコンテストでグランプリを受賞
2016年　41歳　北海道へ帰郷、a-blog cmsエバンジェリストになる
2018年　43歳　CSSフレームワーク「echo.css」を公開
2019年　44歳　ふたたび愛知県へ移住

私生活の10年間

ひとくちに「10年間」と言っても、公私では内容が異なります。上の10年間で、2014年と2017年が空いていますが、私生活ではいろいろあった年でした。

2014年はこれまで溜まってきた自分のダメな部分が出た年で、体調を崩したうえに、仕事でもコーディングでスランプに陥って、毎晩Ingressをしていた記憶しかありません。
いっぽう2017年は、私生活を良くしていこうと考え始めた年で、友人にヨガを習ったり、うさぎを飼いはじめたり、ゲーム用の自作PCを作ったりと、ほんわかした記憶が多いです。

今年は6月に、長年闘病をしていた母が他界しました。とても寂しいですが、これもまた節目でもあります。

私生活は、本人と近しい人以外にはどうでもいいことですし、面白くも興味深くもありません。ですが本人には、いいことも悪いことも、その後の表につながっていくのだろうと思います。

この先の課題

こうして10年間にやったことを書き出してみると、ここ数年は10年前の目標だった「a-blog cmsの案件増加」と「年収の安定」を達成できているものの、新しいスキルをあまり勉強できていません。
来月からまた愛知県民です。落ち着いたら次の10年間につながるようなことにまた挑戦していきたいです。

コーディングとCMSのテーマ設計の話です。かなりCMS構築に慣れていないと理解しづらい内容になるので、順を追って説明します。

モジュール型のサイト設計

CMSで運用されるサイトは、トップページや下層ページのサイドバーで、投稿の新着やナビゲーションなどの「モジュール」を埋め込む前提で構築やコーディングをします。
ここでは「モジュール」としていますが、CMSによって名称は異なります。よく知られているのはWordPressの「ウィジェット」です。

コーディングにについては、以前書いた記事「CMSの構築を考慮したコーディングとかクラスの命名規則の話」で詳しく書いていますが、つまりはこの場合、それぞれのモジュール（＝ウィジェット）はクラス名が付与されたdivで包括される前提となります。

例えば、WordPressの人気テーマ「Lightning」のトップページで、新着記事を表示している箇所は以下のようにマークアップされています。

<div class="widget widget_vkexunit_post_list" id="vkexunit_post_list-13">
（新着記事リスト）
</div>

自由モジュールであることを示す「widget」、テーマ専用パーツであることを示す「widget_vkexunit_post_list」のクラスに加え、一意のIDが付与されています。
これによって似たようなモジュールをページに複数配置しても、クラスかIDで区別してCSSスタイルを調整できます。

モジュールのクラス名を自由に決められるようにしてみる

DrupalのBlockやViewsでは、先述した包括divに付与するクラス名を変更できる機能があります。コーダー側のコーディングルールを活かせるので、とても魅力的な機能です。

ヘッダ、フッタのボタン、包括divの属性を変更できるようにした例

このクラス名変更機能を、a-blog cmsのモジュール設定に組み込んだのが、二年ほど前に公開したテーマ「echo_zero」でした。

モジュールの外観のカスタマイズ | はじめての方へ | 解説資料 | echo_zeroデモサイト

このテーマは当時はかなり満足していて、安定したウェブサイトをサクサク構築できるので、いくつかの案件にそのまま採用していました。
…が、二年が経って、一部の案件でこの機能が足を引っ張るようになってしまいました。

クラス名を見つけられない

完全納品ではなく、納品後も改修をお手伝いする案件だと、半年ほど経ってコンテンツが増えてきてから、二段階目の改修を依頼されることがあります。
モジュールの追加やデザイン変更などが発生しますから、コーディングも変わってきます。以前はイベント新着関係のモジュールが一個しかなかったのに、似たようなモジュール（関連イベント・現在位置から近い順）が増えたりします。

半年も経つと、自分の作ったテーマでも細かい構造は忘れています。このクラスは、どのモジュールで使用していたろうかと、テーマをクラス名の一部、例えば「module-event」などで検索してみても…見つかりません。
クラス名はCMS側で管理しているので、ローカル環境のエディタの全文検索ではヒットしないのです。
こうなると、a-blog cmsの管理画面に入って「モジュールID」の一覧から該当のモジュールを探すことになります。かなりの手間です。

CMSで何もかも管理すればいいわけでもない

一般に配布するテーマであれば、クラス名を変更できる機能は非常に便利です。
利用する人の大半は、モジュールごとに細かくCSSを調整したり、コーディングルールにこだわったりすることがないので、メリットの方が大きいでしょう。

ですが、自分がいちからテーマを作成していて、改修も多い場合は、修正すべき箇所をローカル検索できないというのは、毎回の時間のロスは大したことがないものの、けっこうストレスが貯まります。

そんなこんなで最近は、多くの人がやっているように、記事リストを呼び出す箇所を共通のインクルードファイルにして、クラス名や繰り返すコンポーネント名を変数で渡す構築になっています。
以下はa-blog cmsの場合です。a-blog cmsはJSON形式で変数を渡せます。これなら検索にもヒットします。

@include("/include/module/summary.html", {"class": "c-module-event-top", "mid": "summary_event_top", "loop": "event"})

ここまで書いて、どのくらいの人にこの文章が伝わっているのだろうか…と思いはじめていますが…

よく考えたら、モジュールの包括divを、制作者以外が変更できるようにする必要は基本的にないわけです。配布テーマでは便利でも、制作者が不便になるような機能は制作段階で外しておかなければと、改めて反省しています。