2014年7月アーカイブ

もう、ずっとなんだけど、今に始まったことではなくて、何年前からだったか継続して続けていることがある。

HTMLTidyGateway

小さなものでもいいから、形にして、リリースすること

数が必要なわけではなくて、一つものをメンテし続けるということでも構わないし、ブログを続けて書くということでも構わない。作りかけのものが100あるより、1つ世に出すことのほうが、結果になってると思うのです。

扱っているテーマが小さなもので、ニッチなものであるからそれが大した話題になったりそれが直接儲けにつながるわけではないけれども、リリースにはそれなりにエネルギーが要る。CPANにモジュールアップしようと思えば、テスト書いたり英語でドキュメント書いたりパッケージにしたりといったエネルギーが要るし、ウェブサービスやサイトにするなら、それなりのデザインも必要です。

人の力を借りなくても何とかなる時代

でも、今やGitHubページでもtumblrでも、もしくは Twitter Bootstrapでもいいんだけど、形を整えるならいくらでも方法はある時代なんだし、サーバー立てるにしてもAWSなんかのクラウド普及で敷居下がってる。コスト面もスキル面も、これまでになく低いスキルとコストでリリースできるようになってると思う。

何故、小さなものか。

別におっきなものでも全然構わんし、でっかいことはいいことだけどさ、忙しいじゃない。そんなに自由にできる時間なんて無いってのが実際の所ですわね。でも、小さなものでも「リリース」にはそれなりのエネルギーが必要で、モノができたら8割、あとリリースの2割の作業には別のスキルやモチベーションが必要なんですよきっと。

何故小さなものをリリースすることを推奨するかってのは、小さなものをリリースするってのは、この、リリースするという別のスキルを鍛えるということにつながるからです。

受託のウェブ制作でもCMS構築でも、リリース時って別のエネルギーが要るじゃないですか。リリースって、そう多くないんだけど(職種や案件規模でも違うと思いますが、少なくとも私たちの会社ではリリースってそんなに頻繁にあるわけじゃなくて、何だか特別なタイミングです)。

これを、普段から、自分のプロジェクトで鍛えておくことで、大きなリリースに耐えられる地力をつけようという意味です。

自分の名のもとに何かをリリースすることで、顧客の気持ちがわかる

小さなものであっても、細かなデザイン崩れやリンク切れとか、エラーとか不具合とか、自分の名のもとにやると、気になるし、嫌じゃんか。なので、リリース後の微調整とかを自然とやるようになる。だから、修正はいっぺんに言ってよ、とか顧客に言う前に、その背景がちゃんと理解できるようになる。細かな修正や、やり直し、手戻りは、最初からあるものですよ。そういうことが、小さなもののリリースによって学べると思うのです。

CSS調整したりJQueryでゴニョゴニョしてもいいのですが、基本的にはプラグインを書きます。とはいっても、メニューやウィジェットの表示非表示程度なら、config.yamlだけ用意すればそれで実現できます。メニューについては別に権限外せば出ないですし、ウィジェットは×クリックで消せばいいんですけどね。

この手のは今までさんっざん書いてると思うけど、そういう問い合わせがあったので。

mt/plugins/MyPlugin/config.yaml

ウェブページの一覧をメニューから削除する

メニューのIDを指定し、displayを0にする。メニューのIDは /lib/MT/App/CMS.pm で定義してあります。

applications:
    cms:
        menus:
            page:manage:
                display: 0

Movable Typeニュースをシステム管理者以外には非表示にする

プラグインのほうがコアモジュールより後に初期化されるから、要するに config.yaml で上書きすれば良いです。ウィジェットのIDも /lib/MT/App/CMS.pm で定義してあります。

widgets:
    mt_news:
        label: Movable Type News
        template: widget/mt_news.tmpl
        singular: 1
        set: sidebar
        handler: $Core::MT::CMS::Dashboard::mt_news_widget
        view: user
        condition: sub { return MT->instance()->user->is_superuser }
        order:
            user: 500

はい、以上。

JSONを返すAPIチックなものを作ってMTのプラグインも作った。詳細は"あっち"のブログに書きました。

HTML Tidy Gateway トップページ

でことで、こっちのブログでは実装にまつわるメモ。

Perl CGIで書いた。CGIモジュールとHTML::Templateを利用。

MT以外のPerl自体何だか久しぶりだったのですが、MT利用なし、DB接続のないCGIがこんなに軽いものだとは...

#!/usr/bin/perl
use strict;

my $tmpl_dir = '/path/to/tmpl/';
my $this_url = 'http://altstyle.alfasado.net/html-tidy-api.cgi';

use CGI;
my $query = new CGI;
$tmpl_path = File::Spec->catfile( $tmpl_dir, 'html-tidy-api-bootstrap.tmpl' );
my $template = HTML::Template->new( filename => $tmpl_path );
print $query->header;
$template->param( FORMURL => $this_url );
print $template->output;

HTML::Template、MT3まではMTの管理画面で使われてましたね。非常にシンプルです。TMPL_VAR、TMPL_IF、TMPL_UNLESS、TMPL_LOOP が使えます。

<TMPL_VAR NAME="FORMURL" ESCAPE="HTML">

<TMPL_IF NAME="HAS_ERROR">
    <TMPL_LOOP NAME="ERRORS">
        <TMPL_IF NAME="FIRST"><ul class="list-group"></TMPL_IF>
            <li class="list-group-item" style="list-style-type:none"><i class="icon-pencil"></i> &nbsp; <TMPL_VAR NAME="MESSAGE"></li>
        <TMPL_IF NAME="LAST"></ul></TMPL_IF>
    </TMPL_LOOP>
<TMPL_ELSE>
    <p><i class="icon-pencil"></i> <TMPL_IF NAME="JAPANESE"><TMPL_VAR NAME="NO_ERROR_JAPANESE"><TMPL_ELSE>No error was found.</TMPL_IF></p>
</TMPL_IF>

ループの指定は以下のような感じで。MTの vars のセットなんかと似ているというか、元々これだったんですものね。

my $i = 0;
for my $error ( @errors ) {
    my $line = { MESSAGE => $error };
    if (! $i ) {
        $line->{ FIRST } = 1;
    }
    $i++;
    if ( $i == scalar( @errors ) ) {
        $line->{ LAST } = 1;
    }
    push ( @messages, $line );
}
$template->param( ERRORS => \@messages );

ただ、MTのテンプレートエンジンなんかと比較すると、テンプレートで使っていない param を突っ込むとエラーになるとか、緩さはあまりないです。

Twitter Bootstrap + google-code-prettify

デザインはTwitter Bootstrapを使いました。検証結果のHTMLに行番号とか付けるのには google-code-prettify を使いました。検証結果から該当行へリンク貼るところは、HTML Tidyの行番号から割り出して正規表現でゴニョゴニョしてます。

MAUSのアイコン

Data APIで MTのアイテムを管理する

ここ半年程コツコツとブログエディタ作ってるんですが、まともなクライアントソフトを作ろうと思えば画像の管理機能くらいは欲しいじゃない。アップロードのエンドポイントは標準であるけど、以下のエンドポイントがない。

  • 画像(アイテム)の一覧
  • アイテムの編集(上書き、メタ情報の編集)
  • 削除

これじゃあ、上げっぱなし(アップロードしっぱなし)で、MT3以前と変わらんということになるので、まずエンドポイントを拡張するプラグインを作った。

色々できます。

  • 画像(アイテム)の一覧
  • 画像(アイテム)の検索
  • アイテムの編集(上書き、メタ情報の編集)
  • 削除

https://github.com/junnama/mt-plugin-data-api-endpoint-assets

MAUSに組み込んだ

元々Hack-A-Thon(Hack-A-ThonでMT Image Managerを作った。)で画像管理のための単機能ソフトを作ったんだけど、それだけじゃあんまり面白くないので、MAUS(ブログエディタ)に組み込んだ。

  • 画像の一覧表示、キーワード検索
  • ダブルクリックもしくは右クリックからアプリケーションを選択して画像を開く機能
  • 画像を編集して保存すると上書きアップロードする機能
  • 情報を見る(キーボードショートカットCommand+I)
  • 「情報を見る」画面で、画像のメタデータの編集
  • 画像を削除(キーボードショートカットCommand+Delete)
  • 一覧からエディタへのドラッグ&ドロップ(タグの挿入)
  • 右クリックで、HTMLをクリップボードにコピー(その際に、画像の配置を選べるように)

これはこれで、なかなかに素敵でしょ?

MAUSのキャプチャ(イメージマネージャを追加)

未サポートです。すいません。こう書いとかないとサポートチームに怒られるし(><。 そのうちMTのパッチなりバージョンアップでサポートされる筈かと。多分。知らん間にPHPがオプション機能扱いになってるけど(あんまり嬉しくないってか、むしろ気に入らないのだが)

ダイナミック コンテンツの生成など、Movable Type のオプション機能を利用したい場合は こちら もご参照下さい。

リンクテキストが「こちら」になっているのは、アクセシビリティ的に宜しくないということを覚えておいてね。

さて、こちらのページ (Movable Type のオプション機能を利用するための環境) には、このような記述があります。

既知の問題があります。 PHP5.3x PHP5.4x 以外のバージョンでは、ダイナミックパブリッシングが利用できません。

先日、ローカルデモ環境のMySQLが壊れて、MAMPを最新版にしたらPHPが5.5になっててエラーが出たのです。焦りました。エラーの内容は、以下。

Deprecated:preg_replace():The/e modifier is deprecated,
use preg_replace_callback instead in
/var/www/cgi-bin/mt/php/extlib/smarty/libs/Smarty_Compiler.class.php on line 270

決勝トーナメント見てると、そりゃ、レベルが高いというか、こんなところで日本チームが勝ち抜けるのかというと、普通に無理っぽい印象をうけます。何だ今さら? まぁそりゃそうなんだけど。

でも、何が起こるかなんて誰にもわからないのが、フットボールだ。

自分たちのサッカーを封印して、ガチガチに固めてワントップのカウンターに賭けるというのも、もちろん有りだろう。徹底的に相手のストロングポイントを研究して、そこを殺すという戦い方も、もちろんあるし、決勝トーナメントの戦いを見ていると、そういう戦い方を意識しているようなチームも相応にあるし。

JR鶴が丘駅のポスター。2005年12月3日は長居の悲劇。のサムネール画像

Facebook

Twitter

このアーカイブについて

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

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

次のアーカイブは2014年9月です。

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

Powered by Movable Type 6.2.6