2014年12月アーカイブ

部屋と Movable Type と私

| コメント(0) | トラックバック(0)

この記事は Movable Type Advent Calendar 2014 - Adventar の最終日の記事です。過去2年もトリつとめさせていただきましたけど、気合い入ってるよね、過去の自分。でも今年はあっちに大物(MT Studio)上げたから、ちょっとグダグダ書かせてください。

Movable Type 1.0から13年が経過しました。様々な紆余曲折を経て、特に、ここ日本では本当にたくさんのウェブサイトやブログのCMSとして使われてきました。コマーシャルライセンス、サーバーインストール型、数万円、Perl製というソフトウェアでは希有な存在でしょう。

私が最初に Movable Type に触れた時からも8年が経過しました。ココログを使っていましたから、それをあわせると 10年になります。PowerCMS というプロダクトをリリースしてからも 7年。PowerCMS は Movable Type の歴史の半分以上の年数使われてきました。

また、コマーシャルライセンスと個人無償ライセンスのデュアルライセンスで、ユーザーコミュニティが活発であるのも MTの特長でしょう。 思えば Movable Type 4.0のリリース時に東京のイベント(WebSig24/7)に登壇させていただいたのが、私のMTコミュニティデビューでした。

「Web 屋さんのためのMovable Type4」登壇

野田 純生さま

過去登壇したテーマでいま思うこと
ツールはあくまでもツールに過ぎませんが、サイト制作に用いるツールを選ぶことは、制作体制づくりやワークフローづくり、もっといえば会社組織づくりにさえも深く関係しているのだと振り返ってみて思います。
あの時登壇したことが製品リリースにつながり、結果的に会社も(いい意味で)変わってしまったのですから。
WebSigに登壇してみて
あのときはMT3ベースのPowerCMSからMT4ベースのPowerCMSへの過渡期でした。社内ライブラリであって、まだ製品ではなかったのです。二次会でモデレータの皆様に「売らないのか」「売らないのか」って100回くらい言われたのでカッとなって製品として売り出したらあれから7年で1,000も売れることになりました。
PowerCMSは、WebSigがきっかけで生まれたソフトウェアとも言えます。今日の二次会?でも私を焚き付けてください。きっと何かが生まれるかも。
近況
皆んながWordPressに夢中になっても、相変わらずMT三昧の日々を送っています。 東京に引っ越す気は全くありませんが、週に3日は東京で過ごしています。誰か遊んでください!

※↑誰か遊んでください! が最重要センテンスです。そこはお忘れなきよう!

この時は MT4 をGPLに、という話題がトピックでした。ちょうど7年前の12月にオープンソース・プロジェクトの開始が宣言されています。

このGPL化は結果としてシックス・アパートにとって忘れたい過去となったのでしょう。WordPressに流れたユーザーが戻ることもなかったという判断もあり、MT6からはMTOSは提供されなくなりました。

さて、大切なことを言っておきますが、2015/9/30にMT5.2系がEOL (End of Life): 製品ライフサイクル終了日を迎えます。EOM (End of Maintenance): メンテナンス終了日は今年の9月に既に迎えており「セキュリティに重大な影響を及ぼすと考えられるクリティカルなバグ」以外は修正されませんし、サポートも受けられません。つまり、MTOS は来年 EOL を迎えます。

さて、部屋と「Movable Type」と私という素敵なタイトルでクリスマスに相応しい「Movable Type Advent Calendar 2014」の最終日エントリーを書いているわけですが、本題は実はここからです。

Movable Type 宣言。

さて、(アルファサード株式会社 代表取締役社長としての)私が、来年も Movable Type にフルにコミットしていく宣言としての5つの約束について書きます!

宣言その1〜Movable Type をもっとパワフルにします。

まず、来年も Movable Type やるぞ! を宣言しておきます。これまで以上に付き合っていくことになると思います。私はプラグイン作者でありコミュニティの一員である以前に、Movable Typeを日本で ? 番目に多く販売している会社の代表者です。 Movable Type 関連の複数のプロダクト、サービスを立ち上げることをお約束します。複数。いくつかはクラウドに関連するサービスになるでしょう。Movable Type と付き合い続けてきたウェブ制作者がより仕事をしやすくなり、クライアントに提案しやすくなるようなもの、Movable Type を少し違う世界に連れて行くようなものに取り組みます。ちなみに今年の振り返りはこんな感じです。結構頑張ってるでしょ? 来年はもっと頑張ります。

来年と書きましたが、年末に立て続けに2つ、リリースしました。

まぁ、パワフルにするってことは、もっと売るって受け取っていただいて結構です!

宣言その2〜Movable Type Open Source のメンテナ、PowerCMS サポート兼任担当者を募集します。

前半でも少し触れましたが、MTOSが来年いよいろEOLを迎えるのをきっかけに、アルファサードでMTOS、MT5.2xに対するサポート体制を作りたいと考えています。もちろん、いつまで、を約束することは現時点ではできませんが、まずは以下の取り組みから始めます。

時々の状況によって比率は変わってきますが、PowerCMS サポートエンジニアと Movable Type Open Source(5.2xベース)のメンテナンスを兼務するエンジニア(兼務)を募集します。諸条件等は追って纏めて何らかの求人媒体に出稿しようと思っていますが、我こそは! という方は電子メールで contact@alfasado.jp まで履歴書、職務経歴書、自己PR等を添えてご送付ください。

リンク先のページにも書きましたけど、考えていることはこんなことです。中の人的にはいいね! とかしづらい話題かもしれませんが、コミュニティにとって悪いことやないと思うし、直接商売に影響があるような話しではないと思うんですね。予算なけりゃWordPressかなんかに流れると思うし、中長期で見ればむしろ、いい話しだと思うのです。

  • Movable Type / PowerCMS エンジニアの育成
  • Webサービスのエンジンなどに利用可能なオープンソースのテンプレートエンジン、ORマッパとしての利用促進
  • MTOS メンテナンスの過程で得られた成果・知見の本体へのフィードバック、還元
  • Movable Type / PowerCMS の開発者、Web制作者の裾野を広げる
  • より実験的な Movable Type、例えばコメントやトラックバックを切り離した小さなMovable Type、あるいはスクリーンリーダーで管理画面が扱えるアクセシブルな Movable Type といった実験的、派生的なプロジェクトの推進

色々考えてのことですけど、DynamicMTML や MT Stidio 相応の時間をかけて開発してて、でも商売になったりせんよなこれ。もしくは、PowerCMSにしたって、そりゃもっとたくさんの人に使って欲しい、でも生活もあるやんか。お金も欲しいし、でもなぁ、とかグダグダ悩んでるくらいならデュアルライセンスでいいから、まず公開してみようよ、って思って。そのプラットフォームがない、とか有償版しかないってのも悲しいし。

宣言その3〜Movable Type のiOSクライアント作る、宣言

今年は Mac App Storeデビューしたというトピックもあるんだけど、MTクライアントのMAUS とか ColorTester とかの寄附ボタンとか、押してくれた人(ありがとうございます)とかの数見てると、儲かる仕事にも思えないわけですが、年末年始の休みを利用して少し取り組んでみようと思っています。API、クライアントなければただの仕様?じゃねーかと思うからです。

iOSクライアントのイメージ

宣言その4〜MTを利用してウェブサービス作る、宣言

私にとってのMTは、もはやMTでなく、PowerCMSでなく、開発プラットフォームでありORマッパでありテンプレートエンジンなわけです。であれば、ウェブサービスを仮に作るなら、MTベースで作りたい。万が一ヒットしたとしたらスケールアウトの問題が出てくるだろうけど、最初のリリースの敷居低いから、それこそ当たる当たらん考えててもしょうがないし。

ずっとやってみたかったことだし、アイデアもあるのだ。

宣言その5〜クラウド版のCMS+αのサービスを立ち上げる、宣言

MTはクラウド版あるわけですけど、PowerCMSは現状ありません。AMI や Azureのキットはあるんですけどね。来年は一つ以上、立ち上げを行います。より安心、任せておけるサービスを提供しお客様の選択肢を増やします。

これらの宣言と関係あるかどうかわかんないですが、一人じゃやれへんし、年末の全社会議でも社員に話したけど、来年はピッチ上げるつもりだし、おもしろそうやん、って思ったら一緒に戦おうぜ。よろしくね!

それでは、今年も良いクリスマスを。

MTプラグインのお気に入りに投票する「Movable Type プラデミー賞 2014 とかいうふざけた企画がある模様で、このプラグインこれまでに使ったことあるなー、プラグイン入れ直してちょっと見てみるかどんなんだっけ、とかそういうことになりますよね。なりますよね! ね! ね!

でも、プラグインをインストールするって

  • プラグインをウェブブラウザでダウンロードする
  • FTP(SFTP)クライアントでプラグインをアップロードする
  • その時、plugins ディレクトリと mt-static に(toolsがあればそこにも)それぞれアップする

という手順になりますよね。ファイルが多い時はZIPのままアップしてログインしてCUIで解凍して配置するなんて人もいるかもしれませんが、どっちにしても面倒です。

ということで、プラグイン作りました。plugins、mt-staticディレクトリがWebサーバーから書き込めるパーミッションになっている必要があるので、そこは、まぁテスト環境なりローカル環境で使うという割り切りでお願いします※。

※PowerCMS には プラグイン管理機能(PluginManager.pack) があって、これを使うと常駐スクリプトをサーバーで動かして、そのスクリプトがよしなに配置、パーミッション設定をしてくれます。自動アップデート機能もあります。

プラグインをGitHubやその他の方法で公開している時のメジャーなファイルフォーマットはZIPですよね? で、アーカイブの構成的にはこんな感じになっていると思います。PluginInstallerは、config.yamlを起点にして同じディレクトリ構成になっていることが前提となりますが、ZIPファイルのURLを管理画面から入力して、直接プラグインをインストールすることができます。


    ZIPアーカイブのルート/
    |__ plugins/
       |__ MyPlugin/
           |__ config.yaml
    |__ mt-static/
       |__ MyPlugin/
    |__ tools/
       |__ mt-my-tool/
...

GitHubのページからダウンロードリンクをコピー

システムプラグイン設定からプラグインをインストール

ライセンス

  • PluginInstaller ライセンス(プラデミー賞に1ポチするのが条件! ←嘘や。自己責任でご自由にお使いください)

この記事は、Web Accessibility Advent Calendar 2014、4日目の記事です。

私の会社(アルファサード株式会社)で今年、PowerCMS 8341と Crawl という2つの ウェブアクセシビリティチェックツール を作りました(ColorTesterというコントラストチェックツールも作りました)。PowerCMS 8341 は Movable Type / PowerCMS のプラグイン、Crawl は OS X用のチェック機能を内蔵したブラウザです(非公開)。
すべてのソフトウェアの企画・検討から実装までを私が担当しましたので、今日はそのチェックロジックについて紹介したいと思います。もちろん、ここはこうであるべきではないのか? なんかのフィードバックをいただければ幸いで、今後も修正やアップデートを随時行っていきたいと考えています。

Crawl については、まだ公開していないのですが、下記の記事を書く際に利用しました。

ウェブページに対するチェックツールのチェック結果には差異がある?

他にも有償のもの、無償のものなどがいくつか存在するかと思いますが、何の言語で作られているかはともかく「検査のロジック」が同じであれば、結果は同じになるはずです。基本的には各ツールとも、HTMLソースやHTMLソースのレンダリング結果に対してチェックを行います。

ところが、必ずしも各ツールの検査結果は一致しません。JIS X 8341-3:2010(WCAG2.0)が規格である以上、同じ結果になるのが望ましいのでしょうが、お墨付きのついた検査のロジックが公開されているわけでもないので、やむを得ないことです(とはいえ、そんなに差異があるようにも見えませんが、ロジックが公開されていない以上、差がないとも言えません。ソースが公開されているものもあるので、ソース読めばわかるんでしょうし)。

公開されているロジック(最低要求仕様)としては下記のWAICのサイトのドキュメントがあります。

文字通り「最低要求仕様」とある通り、本当に最小限のことしか書かれていません。また、HTML5の登場や、最近の JavaScript を多用した動的な Web や WAI-ARIA などの新しい技術に対応するにはどうすればよいかなど、このドキュメントもそろそろ改訂が必要な時期にさしかかっているように思います。

コントラストチェックツールの検査ロジックは明確でツールによる結果の差は(基本的に)ない

また、HTMLに対するチェック以外にも、以下のようなコントラスト比のチェックツールがあります。

後者(ColorTester)は私が作成したのですが、コントラスト比については計算式が決まっているため、ツールによる差異はありません(正確には色空間の設定が影響するため、例えば OS X と Windows OS 等の差により微妙に異なることがあります)。

WCAG 2.0(W3C勧告)日本語訳 [原題:Web Content Accessibility Guidelines (WCAG) 2.0]

相対輝度

色空間内のすべての点の相対輝度。最も暗い黒を 0 とし、最も明るい白を 1 とする。

注記 1: sRGB色空間においては、色の相対輝度は、L = 0.2126 × R + 0.7152 * G + 0.0722 * B と定義されており、RG および B は以下のように定義される:

  • RsRGB <= 0.03928 の場合、R = RsRGB/12.92 else R = ((RsRGB+0.055)/1.055) ^ 2.4

  • GsRGB <= 0.03928 の場合、G = GsRGB/12.92 else G = ((GsRGB+0.055)/1.055) ^ 2.4

  • BsRGB <= 0.03928 の場合、B = BsRGB/12.92 else B = ((BsRGB+0.055)/1.055) ^ 2.4

そして、RsRGB、GsRGB、及び BsRGB は、次のように定義される:

  • RsRGB = R8bit/255

  • GsRGB = G8bit/255

  • BsRGB = B8bit/255

^ という記号は、指数演算子である(計算式は、[sRGB] 及び [IEC-4WD]を参考にしている)。

ColorTester は背景色と前景色の推測というユニークな機能があります。推測のロジックについては下記の記事で紹介しています。

ColorTesterの背景色前景色の推測機能

ウェブページに対するチェック

さて、話しを戻します。HTML(ウェブページ)を元にチェックを行うロジックですが、PowerCMS 8341と Crawl では、以下のルールを元に、DOM操作で HTMLタグをパースして、チェックを行っています。Crawl のほうは WebKit のレンダリング結果に対してチェックを行う分、より正確な結果となります。PowerCMS 8341 においては CMS用のツールであるため、純粋にコンテンツ部分に対するチェックを行うことができる、管理しているコンテンツに対してエビデンスを残していける、などの特徴があります。

尚、実装にあたって私が心がけたことが一つだけあります。それは、できるだけ既存ツールが無条件に「人の手による確認が必要」とする項目についても、何らかのロジックで判定を行い、適合、N/Aとなる項目を増やす(というより、「確認」を減らす)ことです。何故か? 既存のチェックツールではエラーや警告はともかく、ここは人の手で確認してね、という項目がページごとに数十個(場合によっては数百)並ぶのです。ウェブアクセシビリティに造詣の深い、一部のコンサルタントや実装者でないと、実装も修正も適合判断もできない、という現実があるのかないのかわかりませんが、そういう現状があるのだとしたら、ウェブアクセシビリティの普及にはマイナスだと考えました。ここは、難しいところでもありますが。何よりも、ユーザーが不利益を被ってしまっては意味がありませんし。もちろん、異論反論あるでしょう。こいつはバージョン1.0。実際の利用者からのフィードバックなども随時反映していくつもりです。

また、各箇条について、チェック対象外、つまり適用しない項目を設定で指定できるようにしてあります。一部の項目については、設定によって厳しさのレベルを変えられるようにもしました。サイト固有の何か? がある場合はチェック結果の表示前にコールバックプラグインを追加してカスタマイズが可能です。

各箇条に対しOK、エラー、警告、確認、N/A(対象外)のいずれかを返します。frameもしくは iframe要素が存在する場合は、常に別途チェックを促します。

PowerCMS8341のレポート(その1)

PowerCMS8341のレポート(その2)

凡例

適合について評価可能
対象外(N/A)について判別可能
何らかのエラー、警告を表示可能
×常に確認を表示

等級A、等級AAに対応するチェックの基本的なロジック

細分箇条題名等級試験自動試験のロジック
A
7.1.1.1非テキストコンテンツAフォームのコントロールにラベルもしくはtitle属性がない(エラー)、フレームが存在する(確認)、Img、Input(type=image)要素にALT属性がない(エラー)、ALTテキストが空(確認)、ALTテキストがファイル名と一致(警告)、Object要素かEmbed要素がある場合(確認)、フォームの中に画像がある場合、CAPTCHAかどうかの確認を表示、いずれも見つからなかった場合、確認を表示。ALTテキストが空の場合に確認を出す、出さないについては設定で選択可能。別途、画像のALTのチェック画面で一括チェック済みの場合は、問題が見つからなかったことを表示。
7.1.2.1収録済みの音声しか含まないメディア及び収録済みの映像しか含まないメディアAObject要素とEmbed要素が存在しない場合、N/A。そうでない場合、確認を表示。
7.1.2.2収録済みの音声コンテンツのキャプションAObject要素とEmbed要素が存在しない場合、N/A。そうでない場合、確認を表示。
7.1.2.3収録済みの映像コンテンツの代替コンテンツ又は音声ガイドAObject要素とEmbed要素が存在しない場合、N/A。そうでない場合、確認を表示。
7.1.3.1情報及び関係性A非推奨、廃止要素のある場合エラー。テーブルがある場合確認。いずれにも当てはまらない場合、確認(リストであるべき、などは確認できないため)。
7.1.3.2意味のある順序A×常に確認を表示。
7.1.3.3感覚的な特徴A×常に確認を表示。
7.1.4.1色の使用A×常に確認を表示。
7.1.4.2音声制御AObject要素とEmbed要素が存在しない場合、N/A。そうでない場合、確認を表示。
7.2.1.1キーボード操作Aonmouse〜属性のある要素にonkey〜が無い場合(onmouseoverに対するonfocus、onmouseoutに対するonblur指定がある場合を除く)に確認、そうでない場合、OK。
7.2.1.2フォーカス移動AObject要素とEmbed要素が存在しない場合、N/A。そうでない場合、確認を表示。
7.2.2.1調整可能な制限時間AScript要素及びイベント属性の指定がない場合N/A、そうでない場合、確認。<meta http-equiv="refresh">が存在する場合エラー。
7.2.2.2一時停止、停止及び非表示AScript要素及びイベント属性の指定があるか、Object要素とEmbed要素があるか、Gifアニメーションがある場合、確認、そうでない場合N/A。
7.2.3.13回の閃光又は閾値以下AScript要素及びイベント属性の指定があるか、Object要素とEmbed要素があるか、Gifアニメーションがある場合、確認、そうでない場合N/A。
7.2.4.1ブロック・スキップA見出し、もしくはスキップリンクがある場合OK、そうでない場合、エラー。フレームが存在し、title属性がないか、空文字の場合エラー、そうでない場合、確認。
7.2.4.2ページタイトルAtitle要素が存在し、空文字でない場合、確認。そうでない場合、エラー。
7.2.4.3フォーカス順序Atabindex属性の有無を確認し、指定があれば確認、そうでない場合、N/A。
7.2.4.4文脈におけるリンクの目的AA要素の内容が空の場合、Area要素のALTテキストが空もしくは属性がない場合、エラー。そうでない場合、確認。target属性の指定がある場合、確認。オプション設定でリンクテキスト=URLの場合に警告を出す、出さない、target属性の指定がある場合、確認を表示する、しないを選択可能。
7.3.1.1ページの言語Ahtml要素にlang属性もしくは xml:lang属性が無い場合、エラー、ある場合に確認。
7.3.2.1オンフォーカスAonfocusイベント(属性)の指定がある場合、確認、そうでない場合、N/A。
7.3.2.2ユーザインタフェースコンポーネントによる状況の変化Aフォームがない場合、N/A。フォームコントロールにイベント属性の指定が無い場合、N/A。フォームに送信ボタンがない場合、警告。そうでない場合、確認。
7.3.3.1入力エラー箇所の特定Aフォームがない場合、N/A。フォームがある場合、確認。
7.3.3.2ラベル又は説明文Aフォームコントロールにラベルがない場合、確認(ラベルもしくは説明があるか)。そうでない場合、N/A。
7.4.1.1構文解析ADoctype指定があり、htmlである場合、OK、そうでない場合、確認、指定がない場合エラー。id属性もしくはaccesskey属性の重複がある場合、エラー。
7.4.1.2プログラムが解釈可能な識別名、役割及び設定可能な値AScript要素及びイベント属性の指定がある場合、確認、そうでない場合、N/A。
AA
7.1.2.4ライブの音声コンテンツのキャプションAAObject要素とEmbed要素が存在しない場合、N/A。そうでない場合、確認を表示。
7.1.2.5収録済みの映像コンテンツの音声ガイドAAObject要素とEmbed要素が存在しない場合、N/A。そうでない場合、確認を表示。
7.1.4.3最低限のコントラストAA基本的には常に確認を表示。別途画像のチェックですべての画像に適合フラグもしくはN/Aとなっている場合、OK。
7.1.4.4テキストのサイズ変更AA×常に確認を表示。
7.1.4.5画像化された文字AA画像がない場合、N/A、そうでない場合、確認。別途画像のチェックですべての画像に適合フラグがついている場合、OK。
7.2.4.5複数の到達手段AA×常に確認を表示。
7.2.4.6見出し及びラベルAA見出しがない場合、警告、そうでない場合、確認。
7.2.4.7視覚的に認識可能なフォーカスAA×常に確認を表示。
7.3.1.2部分的に用いられている言語AAhtml要素以外にlang属性が存在する場合、確認を表示。
7.3.2.3一貫したナビゲーションAA×常に確認を表示。
7.3.2.4一貫した識別性AA×常に確認を表示。
7.3.3.3入力エラー修正方法の提示AAフォームがない場合、N/A。フォームがある場合、確認。
7.3.3.4法的義務、金銭的取引、データ変更及び回答送信のエラー回避AAフォームがない場合、N/A。フォームがある場合、確認。

7.1.4.3、7.1.4.5については、別の画面(アイテムの管理)画面で人の手によりチェックを入れることができるようになっており、そこを経てからチェックすることで「適合」判定が可能としています。正確には機械チェックで判別可能な項目、とは言えないかもしれませんが、ソフトウェアとして適合するためのインターフェイスやフローを提供しているということで◎(適合について評価可能)としています。7.1.4.3については、ColorTester と同様の機能をウェブアプリ内に実装しており、自動及び手動でのコントラストチェックが可能です。

7.2.4.1など、いくつかの項目については、PowerCMS 8341ではテンプレート側で担保することが前提です。PowerCMS 8341ではウェブページや記事については検証範囲を限定してチェックするので、これらの項目はほぼすべてのケースで適合となります。

判りやすい突っ込みどころとして、applet要素であるとか、bgsound要素とか、そういうのがない、ってのはありますよね。これらに対応していないのは、単に「もういい加減えーんちゃう? 見たことないわ」という理由なんですが、必要なら組み込んでいこうとも思います。ちなみに、ページ内で使われているタグを一覧化する機能、使われているタグによってページを検索する機能があります。

また、「HTML5の登場や、最近の JavaScript を多用した動的な Web や WAI-ARIA などの新しい技術に対応する」チェックとしては、このロジックでは不完全です。とはいえ、ウェブアクセシビリティ対応が急がれる官公庁や自治体においてそのような技術が用いられることは現段階では稀であり、こういったシンプルなロジックで検査することで対応負荷を下げられるのなら、このロジックには相応の価値があるのではないかと考えます。ロジックさえはっきりできれば、Perlモジュール化するとか、オープンソースのライブラリ化されるかとかで、恩恵を受けられる人も増えるかもしれません。

何かくどいくらいしつこくなりますが、違った見方やこういうケースどうすんの? ってのはあると思います。建設的な議論のたたき台になれば嬉しく思います。

CMSならではの、工夫

PowerCMS 8341 においては、CMSならではのいくつかの面で工夫しました。長くなりますのでここでは割愛しますが、ご興味のあるかたは下記の記事をごらんください。

さて、未来に向けて

仮にも私は有償ツールの提供元でもありますが、クローズドに各社が開発してツールごとに異なる結果となるよりも、こういうドキュメントを公開することで各ツールの検証結果の差異がなくなっていくことで、サイト運営者も、制作者も判断に迷うこともなくなるのではないか。 いまだにこの手のツールの紹介セミナーで「競合他社お断り」というケースも見られますが、ここはオープンにやっても良いのではなかろうか。この記事は1人のツール開発者からの提案でもあります。

で、今度さ、「ウェブアクセシビリティチェッカー開発者バトル」ってイベントを企画して、是非呼んでください!

ってことで、アクセシビリティやるぞ! やるぜ! 会場向かうぜ! (まだ早いか!)宜しくお願いします。

追記(12月4日16:10)

実際に大量のページをチェックしてると、あ、これあかんやつや、ってやつが見つかるもので、例えばページ内にある複数のリンクテキストが同一で遷移先URLがバラバラなものとか、これは機械判別できるな、これ 7.2.4.4 だな、とか、そういうのが日常的に見つかっていくわけで、追加機能要望や気づいた点を開発者へフィードバックできる機能とか(PowerCMSには管理画面からサポートフォームへ投げる仕組みがあるけど)も有用ではないかな、と思ったりしました。

あと、先週の MTDDC Meetup TOKYO 2014 で話したツール開発の Making のスライドも宜しければあわせてどうぞ。

さらに追記(12月4日16:45)

という「エア」ツッコミがあったので、以下のような機能を提供していることを追記しておきます。

で、このツッコミで思い出したのですが、この手のツールをつくるときに「褒めて伸ばすツール」という考え方をしました。つまり、このリンクテキスト同一云々の件は、こんな箇所があるよ? 確認してね。というメッセージを出すとして、逆になかったら「こういう問題箇所は見つかりませんでした!」的なメッセージを入れるというものです。褒めてくれるツールの方が、さわってて心地いいやん。ということです。

チェックツールを作っていると、いかにエラーを見つけるか指摘するか、という思考になってしまいがちなんだけど、いいところは敢えて褒めてあげよう、ということです。俺も成長したもんだ(違)。

Facebook

Twitter

このアーカイブについて

このページには、2014年12月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2014年11月です。

次のアーカイブは2015年1月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

Powered by Movable Type 6.2.6