選択されているタグ : 運用

a-blog cms1年目で知っておきたかったこと

「a-blog cms Advent Calendar 2019」という企画があります。
この記事は、その21日担当として書かれました。

a-blog cms始めて1〜2年で知っていたかったことを、過去の自分に伝えるように書いてみます。
「はじめの方で知っておきたかったなぁ。」ということを、ざっくばらんに羅列しました。

こういった情報は職域によって違いそうなので、私のスキルと仕事時間の割合を、下記に載せておきます。


自分自身が、こういうスキル&働き方なので、内容は偏っているかなと思います。

デバイス大事だよ編


多機能マウスと、アプリ「Clipy」を使おう!


マウスは、ロジクールMasterシリーズ旧型。

マウスは、ロジクールMasterシリーズ旧型。

アプリ「Clipy」にはスニペット機能があるので、a-blog cms関係でよく使う記述を登録できます。
多機能マウスのボタンにClipyのスニペット機能を割り当てれば、スニペットをすぐ呼び出せます。
べんり〜!

さらにClipyの「クリップボード履歴」機能と、多機能マウスも相性が良いです。


@econa77さん、すばらしいアプリをありがとうございます

@econa77さん、すばらしいアプリをありがとうございます

いきなりa-blog cmsと関係うすい感じですが、日々の作業を効率化するのは大事ですね。

最初からこうしてたら、数時間は時短できていたのでは?
というか、この爽快感よ!
「気分よく仕事するの大事よね。」って思います。

メルカリなどで、状態のいい旧モデルを購入すると、さいふにやさしいマウスになります。


a-blog cms関係のスニペット例

a-blog cms関係のスニペット例


値付け大事だよ編


Webサイトをちゃんと「維持する」って、思ったよりお金かかるよ!・・・という話。
これもa-blog cmsと関係ないのでは、と思われるかもしれませんが、関係あります。


常に迫ってくる「期限切れ」たちとの鬼ごっこ


Webサイトは、常に迫ってくる「期限切れ」との鬼ごっこです。

  • PHPのサポート期限切れ
  • サーバのOS期限切れ

など「今のままのWebサイトでいいんだ」では通りません。

また予期せぬトラブルで、緊急対応することもあります。
自分(自社)と無関係な原因だとしても、頼まれたら動かないと・・・って場合もあります。

ほかにも、クライアントの担当者さんが変わることもあります。
そしてクライアントさんから「ちょっと最初から説明してくれる」と請われることもあります。
※ドキュメントがあったとしても

つまり、なんやかんや「Webサイト作った人 or 保守してる人」として、動く時間があるってことです。


「Webサイトを維持する」ための費用を考える


なので、値付けで解決しましょう。
たとえば「Webサイトを維持する」ための費用を、将来必ずかかる費用として「均して毎月いただく」という解決法があります。
3〜4年に1度はコンテンツのリニューアルがなくても、サーバ環境&a-blog cmsのバージョンをアップデートするって合意を得るのです。

あとから「アップデートのために○○円かかります」とか「サーバを引っ越さないと維持できないです」と、クライアントさまに伝えるのは色々と不都合が出てきます。
ちょっとした質問に答えたり、アップデートの計画を練る時間を、1年で合算したら「えっ・・・こんなに時間とけてるの?」という量になるはずなので、ちゃんとお金をいただきましょう。


主な「Webサイト作った人」として動きがちなこと


  • a-blog cmsのセキュリティ的なアップデート対応(自分の瑕疵がない場合
  • 自分のカスタマイズにミスがあった場合の修正作業(たとえ納品から2年後とかでも)
  • PHPのバージョンアップと、対応したa-blog cmsデータへの入れ替え
  • cssのちょっとした調整(ブラウザ依存・a-blog cmsのシステム依存)
  • Webサイト更新における挙動・ルールへの質問対応(いただいたマニュアル無くしたので再送ください系を含む)
  • 実現度が低い「この機能は付けられるか?」への対応
  • Googleマイビジネス、Google Analytics、Indeedなど運用に関する質問への対応(あなたに質問することではないかも?でも知ってたら教えて系を含む)

ただこれは「自分の場合こうでした」ですね。仕事の仕方や、役割次第で、別の解決法もあると思います。


やらかし、そして学び編 7つ


ミスしたり、やらかすことで得る知見もありましょう。


1.IFブロックを壊さない


これまで何度IFブロックをぶっ壊したことでしょう。
テキストエリアなど「改行を含む値」が入る変数を、そのままIFブロックで使うとIFブロックの途中で改行されてしまいます。

<!-- BEGIN_IF [{hoge}/nem/] -->
{hoge}[escape|nl2br]
<!-- END_IF -->

↑こういうIFブロックで{hoge}が改行を含む場合に、注意です。

<!-- BEGIN_IF [{hoge}[escape|delnl]/nem/] -->
{hoge}[escape|nl2br]
<!-- END_IF -->

上記のようにテキストエリアの変数をIFブロックで使う時は、校正オプション「delnl」が必須です。
改行できる値のテストは必ず改行して動作確認しつつ、納品時のチェックもしましょう。

escapeはVer.2.11以降で不要になるかな。


2.ルールの導入は、どうしても必要な時だけ


ルールで「できちゃうこと」は多いが、他の機能で実現できるなら、他の機能でやる。
ルールは「ルールじゃないと無理」な時だけに使う。
・・・という心構えでいきましょう。

もう詳細は忘れましたが、自分以外の人が作った「小鳥遊という名字は、たかなしと読む」みたいな難読ルールと遭遇して、こんな気持ちを他の人に味わわせてはいけないと思いました。
※小鳥遊とは「小鳥が遊んでいるなら鷹はいないよね→たかなし」という日本語にいくつかある言葉遊びの1つ


3.コンバーターをなめると、休日に電話がかかってくる


コンバーターとは、フォームでつかう機能です。
入力された値のチェックや変換ができます。
たとえば全角で入力した「curry」を半角の「curry」に変換して、フォームで送信できます。

以前、フォームのカスタマイズをした時、
コンバーターをさぼったおかげで、休日にクライアントさまから「なんか急にフォームでエラーが出る!すぐ直して」と連絡をいただきました。
メールアドレスに使用する文字列に、半角に変換するコンバーターを適用していれば、防げた連絡でした・・・。



4.ブログは消せる


エントリーを誤って消すことは、あるかもしれません。
そしてブログを誤って消すことも、あるかもしれませんね。

だから、クライアントさまが各種サポートが終わった年末に、うっかりブログを消すこともできるんですね。
クライアントさまが「だいじょうぶ!」と仰っても、クライアントさまが使うアカウントの権限を「管理者」にするのはやめましょう。


5.リニューアルの時は、リダイレクト機能を思い出して


サイトのリニューアルでサイト構造が変わって、エントリーのURLが変わることあります。
エントリーの数が数千とか数万あると「どうすんの?」ってなります。
でも安心!
エントリーのURLが変わっても、自動リダイレクトしてくれる機能があります。
config.system.yamlにentry_301_redirect  : onって書けばOKです。

これで何度か助けられてるんですが、このリダイレクト機能を忘れてて、無駄にリダイレクト手書きしたこともあるんですよね・・・。


6.カスタムフィールドの値は、記述が表示されていないと削除される


エントリー保存するとき、カスタムフィールドの値はいったん全削除されます。
カスタムフィールドの値を全て削除したのちに、入力されている値を登録します。

たとえば「投稿者のときだけ表示されるカスタムフィールド」があると、管理者がエントリー保存した瞬間に、カスタムフィールドの値が削除されます。
この仕様を知らないと
「妙に変だな〜。たまにカスタムフィールドの値が消えるな〜。やだな、こわいな〜。(CV:稲川淳二)」
ってなります。

それじゃ困るって時は、カスタムフィールドの値を削除しない方法があります。
下記を、カスタムフィールドを記述しているファイルに1回書けばOKです。

<input type="hidden" name="updateField" value="on" />
<input type="hidden" name="field[]" value="updateField" />


7.サーバのFTP領域にあるファイルは、更新されるよ


config.server.phpの先祖返り、累計10回くらいしてる私です。
ローカルにあるDB情報を記載してない「素のconfig.server.php」をアップロードして、サイト表示できない・・・というYARAKASHIですね。
環境的に今はこういうこと少ないと思います。

「こんなミスを自分以外するのかな」と思いつつも、過去の自分に向けて書いているので改めて説明します。
オンラインアップデートやCMSインストール時に、リモートにあるファイルが書き換わります。
そこでローカルにあるファイルをアップすると先祖返りし、場合によっては大きな影響が出る・・・という話ですね。


対処法はこんな感じでGo


  • オンラインアップデート後などは、リモート側からローカルにファイルをダウンロードしよう
  • バックアップから復元できるようにしておこう
  • FTP領域へのログイン情報を渡す相手は、上からの指示であってもよくよく考えよう

気の持ちよう編 5つ


1.合宿はこわくないし、a-blog cmsに興味あれば行ってOK


「a-blog cms初心者も歓迎」っていうけど、さすがに自分じゃ場違いかな〜・・・と思っていました。
でも合宿では、本当にa-blog cms初心者でもOKでした!
合宿(Training Camp)や、a-blog cmsのイベントは得るもの多いから行ってみよう。

a-blog cmsのユーザーといっても、さまざまです。


バックボーンはさまざま。

バックボーンはさまざま。


  • 制作会社でバリバリ使ってるデザイナー
  • 制作会社だけどコードは書かないディレクター
  • 自社サイトのWeb担当者

・・・など。
職域も職能も、サイトの規模も、ビジネスの仕方も違うっていうことが普通です。
なので「場違い」とか、そんな気にしなくてOK。
a-blog cmsに興味あれば行ってOK!


2.自信満々で作った管理画面が、ぜんぜん思い通り使われなくても、いじけなくてOK。


いじけるなベイベー♪ いじけるなベイベー♪
一生懸命つくった管理画面が、ぜんぜん効果的じゃ無い・・・というのは、慣れないとダメージがあります。
ただ使いやすい管理画面を作るスキルがないとか、あるとか、けっこうどうでも良いというか。


  1. ユーザーさんが使いやすい(だろうと想像して)管理画面をつくる
  2. 実際に使っている様子を見る
  3. ユーザーさんの行動が想像と違った箇所を改善する

これを粛々とつづければ、良い感じに近づいていきます。
いじけないで、ユーザーさんをみればOK。


3.テーマを継承して作ってもいい


「site2019」など最初から入っているテーマがあります。
はじめ、こうしたデフォルトのテーマを元にサイト制作するのは「手抜き」に似た印象をもっていました。

それは技術的になにか根拠があるのではなく、なんとなーく「つくる側として、だめかも?」という思い込みでした。
デフォルトのテーマを継承して作る方が合理的な場合があるので、いらない思い込みは捨てましょう。


4.サイト構造は、みんな試行錯誤して作ってる


サイト構造を、どのようにa-blog cmsに反映するか。
ふつうに難しい問題です。


  • どの情報単位で子ブログにするか
  • カテゴリーで分けるのか、タグやカスタムフィールドで分けるのか

・・・など、ふつうにみんな試行錯誤します。
はじめ私は「a-blog cmsのサイト構造は最適解があるのに、自分は常に迷っていてあかん」と思っていました。
(みんな迷わずテキパキ最適解を選べるのだと思っていた。)
でもCMSの機能拡張とともに、サイト構造の分け方は変化してきているし「どんな時でもこれが最適解」というものは無さそうなので、試行錯誤しててOKです。

たしかに「やっちゃいけない分け方」はあるので、どんなサイト構造でも良いってことではありません。
だけど、常に迷っていてもいいじゃん?というスタンスは、OKと思います。


5.校正オプションは、作ってもらおう!


なぜか「自分で作れないものは、実装できない」思考になっていた時期がありました。
しかし「あったらいいな」という校正オプションは、誰かに依頼して作ってもらえば良いです。
自分のようにphpの知識ゼロで、プログラマの職能がない場合は特に。


機能・テーマ編 5つ


1.site2019とか継承する時の「contact」フォルダ等の扱い


デフォルトのテーマ「site2019」などを継承して、テーマ制作する時に問題があります。
それは、site2019に含まれる「news」「contact」といったカテゴリーに依存する部分です。

制作するサイトでも、たまたま「news」「contact」カテゴリーがあれば問題ありません。
しかし、制作するサイトにcontactが不要な場合に、contactがあっただろうページにアクセスすると、フォームが表示されてしまいます。


テーマ「site2019min」

テーマ「site2019min」

そこで、カテゴリーに依存する情報をsite2019から削除した「site2019min」を作ります。
継承元をsite2019minにして、制作するテーマは「hoge@site2019min」のようにします。
こうすれば、もしもアップデートでsite2019に修正・変更があっても対応しやすいです。


2.エントリーサマリーでだいたいOK


「エントリー○○」モジュールは、たくさんあります。
でも、だいたいエントリーサマリーを使っておけばOKです。

詳細ページのように、表示したい情報がある時だけエントリーボディーを使います。
エントリーボディーは、エントリーサマリーに比べて負荷が高いモジュールです。
なので、ここぞって時に使います。

あとは、負荷の面でも、拡張性の面でもエントリーサマリーでOK!


3.情報の単位として「エントリー」がつよい


サイト全体で使う情報を、どこに格納するか迷うことがあります。
あるいは情報のまとまりを、もっと便利にできないかと検討することがあります。

そんなとき、しばしば「エントリー単位なら、いざという時つよいな」ってなります。
エントリーは拡張性が高く、サイトのどこでも目的の情報を抽出しやすいからです。

カテゴリーのフィールドで十分、モジュールフィールドでOK・・・というケースは、もちろんあります。
ただ拡張性の確保や、何か詰まった時は「エントリー単位で情報をまとめると、どうかな?」と思考すると早そうです。

ましじめ @tamshow_さんの記事が参考になります。


今後もしも、エントリーのインポート・エクスポート関連が充実したら、最強ですね。


4.a-blog cmsには「非推奨」が存在する


a-blog cmsには非推奨の書き方・機能があります。
ガイドラインを読むと解消できるので、ちょっと慣れてきたくらいに、分かる箇所だけでも読むとYARAKASHIを抑制できます。

すがわら@シュガーさんのスライド、@_h_miki10さんの記事も分かりやすいです。
ガイドラインから特に重要な項目がまとめられていたり、補足があったりします。



ガイドラインは下記です。



5.キャッシュを積極的に使おう


キャッシュがあるせいで、クライアントさんのPCに古い情報が表示され、確認が二度手間になる。
だから、キャッシュはオフにしよう。
・・・とまではいきませんが、それに近い状態になっていた頃がありました。


使えるキャッシュは、どんどん使いましょう!


キャッシュを使えば、高速表示できます。
サーバーへの負荷も抑制できます。
閲覧者さんが使う「ギガ」を抑制できます。


a-blog cmsのキャッシュは大きく2つ


  • サーバーのキャッシュ
  • クライアントのキャッシュ(各スマホなど端末ごとの記録)

上記のように、a-blog cmsのキャッシュは大きく2つあります。
「常に100%最新の情報を表示すべき」場合にキャッシュは使えませんが、それ以外はどちらも使う方が良いです。


コンフィグから設定!

コンフィグから設定!


キャッシュの自動生成


またサーバーのキャッシュには「自動生成」機能があります。
キャッシュがリフレッシュされるタイミングに、予め指定したURLのキャッシュを自動生成してくれる機能です。

キャッシュの自動生成には注意点があります。
自動作成するページを数十も指定すると、自動作成の負荷が高くなり、エントリー保存時の待機時間が長くなります。

なのでサーバーの性能や、更新の利便性を考慮して、できるだけキャッシュの自動生成も使いましょう。



たぶん、現在進行形で「知っ得情報」はある


これを書いている今も「あのとき知っていれば!」という情報はあるかなと思います。
もしも、この記事で「そこはこうだよ!」とか「こうすると良い」みたいなことがあれば、twitterとかでおしえてください。

それでは!


投稿者名 すずきカレー 投稿日時 2019年12月21日 | Permalink

カスタムユニット内の文字列は、cmsで置換できない

a-blog cmsの秋合宿ありがとございました〜!
学んだ〜!
IKKOのテンションを借り、勢いでブログを書く私です。


カスタムユニットは最高。しかし・・・


ユニットを思い通りにカスタマイズできる、夢の機能。
私もよく使っていて、すでに多くのサイトに導入してます。最高。

カスタムユニット詳細については下記リンク先参照。


しかし、カスタムユニットには注意点があります。


カスタムユニット内の文字列は、cmsで置換できない


カスタムユニット内の値は、a-blog cmsの機能でテキスト置換できません。
(2019-12-03 a-blog cmsのVer.2.11β時点)

※2019/12/04追記&修正
当初「カスタムユニットは検索できない」と認識していましたが、検索はできます。
できないのは置換でした。

ところで「テキスト置換」という便利な機能、みなさまお忘れではないでしょうか?
使用頻度は少ないですが、この機能は超いいやつです。
この機能でカスタムユニットの値も置換できれば、最高オブ最高なのですが・・・。


場所は「データ修正 > テキスト置換」

場所は「データ修正 > テキスト置換」


他の値は基本的にテキスト置換ができます。


このように、ユニットやカスタムフィールドの値は、cms内で検索&置換できます。
あるいはテンプレートに記述した文字列の場合は、コード書くソフトで検索&置換できます。
そして現状はカスタムユニットは、手動での置換になる格好です。


カスタムユニットの値が置換できないと、どういう時に困る?


たとえば、次のようなとき、カスタムユニット内の値が置換できなくて困ります。

  • 単純に語句の変更依頼があったとき
  • 語句を統一するとき
  • 社名・サービス名など名称の変更があったとき

ジャカードとジャガード

ジャカードとジャガード、どのサイトでも統一してほしいですよね。

豊田市の田中さん→豊田市のTさん
・・・と、変更してほしいみたいな依頼はありえそうです。

語句の統一とは、
プリンターをプリンタにしよう
「ジャカード靴下」と「ジャガード靴下」を統一しよう
・・・みたいなパターンです。

文章に限らず、URLや、変数で使っている値でも問題はおこえりえますね。


カスタムユニット内の値は、フルテキスト検索しよう


カスタムユニット内の値も、置換対象かも?
・・・と疑心にかられたとき、次のような検索手段があります。
まずは検索して値の有無を確かめ、必要なら個別に編集していきましょう。


フルテキスト検索


cmsのフルテキスト検索で、カスタムユニットの値も検索可能です。
たとえば、エントリー管理の「キーワード」欄は、フルテキスト検索になるはずです。


いつものエントリー管理画面から検索できる

サイトにキーワード検索機能があれば、そちらでもカスタムユニット内の値を検索可能にできます。
フルテキスト検索については、下記を参照。



最高のカスタムユニットを便利に使い続ける対処法


カスタムユニットを使うときは、こんな感じにしようと個人的に思いました。

  • 本文を入れる用途では、カスタムユニットを使わず実装できないか立ち止まって一考する
  • カスタムユニットは置換できないことを承知の上で使う
  • 将来的にカスタムユニット内の値も検索できるようになるのを待つ

Ver. 2.11でも未対応


a-blog cms Training Campで確認したところ、Ver. 2.11でもカスタムユニット内のテキスト置換には未対応のようです。
もしかすると、将来的にこの記事で書いた問題は解消されるかもしれません。
ただ、お話しした感じだと、2020年内の対応は難しそうかなと感じました。

以上、もしも間違いあったらtwitterとかで教えてください!

2019-12-04 @steelydylanさんの指摘で、間違いに気づけました。ありがとうございます!


投稿者名 すずきカレー 投稿日時 2019年12月03日 | Permalink

Web制作者の役割と「約束を守りたい」と思われる環境

長谷川恭久さんのpodcast「automagic.fm」千貫りこさん回を聞きました。


automagic.fm(2018年1月の)で千貫りこさんがJimdoをよく使った、という話をされていました。
Jimdoで素早くウェブサイトを制作する。ちゃっちゃとウェブサイトを公開して、反応を見ながら運用していくという方法が、この1〜2年は多かったという話です。
思い当たる節が自分にもあり、ポッドキャストを聴いて考えたことをメモしようと思います。


月1で、行政のビジネス相談サービスに参加して


愛知県の岡崎市には、OKa-Biz(オカビズ)と言うビジネス相談サービスがあります。
オカビズが対象としているのは、主に中小企業の経営者さまで、無料で何度でも相談いただけます。

僕はそこへ月に1度、出勤しています。肩書はITアドバイザーです。
ITアドバイザーの守備範囲は、Webを主軸にした情報発信です。
たとえば無料のブログを使って、自社の集客や売上アップに繋げます。
Podcastでも話題にあったように、Jimdoのような無料でできるサービスを使うことも多いです。

なお、行政が無料で行うビジネス相談なので、使えるWebサービスは「無料のサービス」が基本です。
個人的には「お金をかけずに情報発信で成果を上げる」という、縛りゲームをしているような心地にもなります。

無料で始めて、相談者さんの判断で有料プランへ移行するっていうのは、もちろんアリです。


Webサイトの更新、自社で全てできる状態ならば、更新はつづくのか


オカビズには3年以上在籍しているので、相談数は数百回になると思います。
そんな中、結果的に「これは更新が続けられるな」という条件があるなと、思っています。
その条件のひとつが、約束を守っていただく環境にする・・・ということです。

たとえば、無料で相談できるオカビズにおいても、ブログの更新をし続けるために、相談者さんと僕とで約束をすることがあります。
「次回の相談までに記事を5つ書いてください」と言うような形で、僕から宿題を出します。
(宿題という言葉を選ぶ理由は、結果的にそう言うとタスクを完遂してもらえる率が高かったからです。)
すると次回「約束した宿題はできましたか?」といった形で確認することができます。
あるいは「次回までの店舗写真を持ってきてくれれば、相談時間内で写真をテンプレートに反映します」という約束をすることがあります。

そうすることで、約束を守れば状況がよくなっていく、という感じを作っていきます。
そういう関係性が作れると、無料のツールであっても成果が出やすくなります。

そういう経験をして、こんな「思い当たる節」があります。
Webサイトの更新にWebデザイナーが必要だからこそ、Webサイトの運用が滞りなく行われる・・・といった場合もあるのではないか、と。

この人との約束、守りたいなっていう感じ

cmsがあれば自社だけで更新が完結できる、という話とは別の面で。
間に人(Webデザイナー)が入るからこそ、情報発信が止まることなく続けられるってこともあるのでは?っていう。

もちろん人と約束したからといって、クライアントさまが必ずその更新の約束を守るとも限りません。
しかし1人で孤独に更新し続けるよりも、マラソンのペースメーカーのように他者が伴走してくれれば、更新が続けられる。
そういう可能性があるのではないかと、思いました。

タッチの南ちゃんが理想というか。
この人との約束、守りたいなっていう感じが大事なんだと思います。
その役割は、人間だから可能だと思います。

また、オカビズのIT相談の枠は人気で、時には1ヶ月以上も待つ必要があります。
環境として「貴重な時間を使って相談やカスタマイズしてもらえる」ことを、相談者さんが実感しやすいので、約束を守ってもらいやすいことに繋がっているのでは?
・・・とも思います。


職能だけじゃなくて、役割に着目してみると


Webサイトを更新しやすい仕組みは、もちろん大切です。
同時に、Webで情報発信を続けられる関係性もまた、大切なのではないかと考えています。

Webサイト運用で必要な職能といえば、アクセス解析や、広告の評価、市場の調査などが多いなと思います。
一方で「この人と約束を守りたい」みたいな・・・なんていうんでしょうね。
社会的な役割としての、南ちゃんというか。
そこまで強い関係性はムリなのですが、運用をつづけられる動機になりたいなと思います。

そういうわけで職能だけじゃなくて、役割にも、Web制作者の身の置き場があるのかもな〜って思いました。

ポッドキャストを聴いて考えたことは、だいたいこのような事です。


投稿者名 すずきカレー 投稿日時 2018年01月29日 | Permalink

a-blog cmsを長期使用したユーザーに対する観察

個人的メモ。

cmsを使って更新する人は、もしかすると何年も同じ管理画面を使います。
そうした中で、効率化のために管理画面の最適化を依頼されることはあります。
しかし、納品時の管理画面をそのまま「そういうもの」として受け入れてしまう場合もあります。

そこで、たとえば「cmsを5年間運用してみて更新ユーザーがどう感じるのか?」という見方があると良いなと思いました。

更新ユーザーがどう感じるのか?


時間軸 ユーザーの認識
cmsの導入を検討中 使いやすそう。
直感的に操作できそうだ。
プロトタイピング 問題なく更新できる。
納品時 実際に更新してみて、使いやすいと感じた。
5年間、運用した時 ???

この表における「???」を、より良くするにはどうすれば良いか。
答えを出したいなぁと思います。


投稿者名 すずきカレー 投稿日時 2017年12月08日 | Permalink