2008年6月アーカイブ

既に一週間経ってしまいましたが、6月21日WebSig24/7MT4分科会第2回勉強会参加してきました。

当日は僕の誕生日だったのでお祝いしてもらってこっぱずかしかったですよ(嬉しかったですよ。ありがとうございました)。

ケーキ!

当時発表したものですが、こちらにて公開しました。WYSIWYGエディタのTinyMCEをMTのリッチテキストとして使えるようにするプラグインです。基本的にはウチの会社のF君の成果(曰く、胃が痛かったけど何とかやってみました、という仕事の成果)をプラグイン化したものです。

TynyMCEプラグインの画面

もうひとつ、画像のアップロードと管理を簡単にするSideBarImageのCSS微調整版もこちらにあげておきます。

小川さんの話を聞いて、英語ベースのコミュニティでも逃げてちゃいかんよな、ということを改めて思ったのと、小山さんの話が面白くも中途半端で言いたいことが一杯あった一日でした。

グループワークの時間はやっぱり短い。一日ガリガリコードを書いて夕方発表、くらいがちょうど良いような気がしました。僕は事前に大分準備してたので、それなりに発表とか出来ましたけど。

Web衰退時代をどう楽しむか

住太陽 vs 切込隊長 with 高木敏光

いやぁ、面白かったですよ。笑わせていただきました。切込隊長さん住太陽さんで「Web衰退時代をどう楽しむか」とかやってるんだもん。

# そのまま飲みに行ったらもっと面白かったんだろうけど、ハードな一週間で疲れもピークだったのでとりあえず昨夜はそのまま宿へ直帰でした。

*トークの内容についてはここらへんで見てくださいね。

要するにここは東京

トークの中でぶっちゃけ隊長の名指し発言とか住さんの過去とか、そんなのは大人だから僕は書かない :-p

会場における数少ない大阪人的な感想として、第一にあげておきたいのは『あぁ、ここは東京で「ど真ん中」な業界の話でもって「衰退」ってのを語ってるんだなぁ』ということだ。地方零細のWeb業界人としては (一応東京には出てるけど) 霞のようなものを食って生きているわけで、正直この部分の衰退を語られても関係ないなぁというのが前提。但し、田舎のひがみとかでは全然なくて、「大手クライアント→広告代理店→業界」って流れがやはり東京のマーケットの構造の大きな部分を占めているのであって、衰退も何も (トークの中にもあったけど) 効果があるかないかわからんし検証も出来ないものを何となく提案して好きな仕事やって金貰ってたツケが回ってきてるんだ、東京では。

大阪とか名古屋では

何でこんなことを第一に思ったかというと、週の前半は大阪名古屋のCSS Nite(日、月曜)行ってたわけで、そのギャップがすごくて面白かった(っていっちゃ怒られると思うが)から。

「名古屋(大阪)の大手クライアントが東京に発注投げて名古屋(大阪)で下請けやってる」とか「仕事がない」「予算がない」とか、おまけに「元気がない」とか。

# しかし参加人数が違うとはいえ、東京開催との反響とかフィードバックとの数の差はどうだ?

で、木曜日あたりに某所でのMtgで話していたことにも絡むんですが、「地方格差」みたいなことを言うわけです、地方の人は。ところがところが、衰退の時代、変化の時代には地方だろうが何だろうがチャンスはごろごろ転がっていて、例えば以下の住さんのエントリーにある「供給過剰と業界の成熟から単価が下落し続けている」「CMSや外国人の労働力が、一層単価を引き下げる」とかに注目してみると...

CMSや外国人の労働力が、一層単価を引き下げる

面白いのは「地方」では「格差」で「国際」になると「競争」になるんだな(もちろん国際的な地域格差ということも当然あるのだが、この手の話の中では「国際競争」とか「グローバル化」という話になる)。

「地方競争」という言葉はあまり聞かんのだよな。大阪と名古屋で東京のマーケットの仕事を奪う、とか聞かないものね。単価が下がったら物価の低い地域の方が有利だったりしないか? CMSが単価を引き下げるのなら、格安のCMSをマーケットに投入してもっともっと単価を下げてやって、成熟した? 東京の競合から仕事奪ってやるとかそんなこと言う人がもっと出てくると面白いと思うんだけど。

供給過剰と業界の成熟から単価が下落し続けている

そうなの? 業界が成熟しているとはどうにも思えなかったりするな。実感がない。一例だけど例えば「Webディレクター至上主義」的な考え方とかに違和感があるんですよ。

発注側は確実に変化していて、事業に本気なところ程社内にそういった部門をツクり、組織化しようとしているように感じます (そういったクライアントと仕事をすることが増えています)。

これは即ち「制作会社の人間にそんなものを期待しない」という流れです。そうなった時に、クライアントが制作会社、制作プロダクションに求めるものは何でしょうか? 大した力もなくクライアントの担当者程本気でもない上流工程の『知識集約型』人材でふくれあがってコスト競争力の無くなった制作会社を切る * ことか、数少ないウェブ業界の『知識集約型』仕事をこなせる人材を引き抜くかです。

* そのかわりに (例えば) クライアント自身の立てた事業戦略をスムーズに理解し下流工程までをカバーできてコスト競争力も高い発注先をピンポイントで新たに見つけるのです。

人材が引退しない業界

この業界に限らないのだけれど、新しい業界には (若いのは流入してくるけど)「人材が引退しない」という構造的な欠陥(?) があって、元々ディレクターってのはそこから生まれたポジションではないかと思っているのです。

どういうことかというと、大きな会社(というより、社歴の長い会社)なら定年でリタイアする人がいて新入社員が入って来てという流れがあって、その中で会社の成長を描いていけばいいわけです。新陳代謝ってやつですね。ところがこの業界、せいぜいが僕と同世代とか少し上の人が上の世代。まだリタイア出来ないししたくもないよね。

単価が右肩あがりであれば、現場そのままやっていって成り立つわけですが制作単価はむしろ低下していく(若い人の成長も速い。高速道路もあるし :-p )。であれば「ツクルより人やカネを動かす仕事をやれ」(高木さんの話にあったような)ということになって、そこからディレクターというポジショニングが出てくる。

でもね、それってクライアントの都合じゃなくて制作者の都合で生まれて来たポジションなんですよ。より効率よく「人やカネを動かす仕事をやれ(そういう組織をつくれ)」、いいかえれば「中間管理職を設けて、より多くの金を生み出せるようにする」ということ。

それこそマーケットが拡大するか会社が成長するから成立する考えだと思うんですよ。リタイアする人がいなかったら「人が成長し、上に立って複数の人を抱えて仕事をハンドリングしていく」ってのはすぐにポストの不足を招くじゃない。ポストを不足させないためには一定のスピードで成長することが前提になるのです。

現実問題として、大きくならない会社で人材の入れ替わりがなかったら5年後には平均年齢が5歳上昇しているということだし、普通の会社だったら人件費コストが上昇して価格を上げないと辛くなってくる。

では、どうするか

これは東京も地方も変わらんと思うのですね。だから「衰退」や「格差」といって悲観する必要は全然ないのですね。東京が特別上手くやってるわけじゃないし、まだまだ成熟なんてしていないと僕は思うのです。そして「変化」と「チャンス」は必ずセットです。

では、どうするか...なんだけど、ここでは書かない(そのうち書くかもしれないけど、自分で考えるべきことだ)。書かないけど僕は考えてるつもりだし、社員に聞かれたらちゃんと答えてる(というか聞かれてなくても喋ってるかな)。

「衰退」つまり何も考えていないところはもたない。だから、業界で働いている人は社長に聞いてみたらいいと思う(フリーランスの人やトップの人は自問すれば良いし)。「Web衰退時代をどう乗り切っていきますのか?」って。納得できる答えが返ってこなかったら...身の振り方を考えた方がいいかもしれないと思うよ。

# 取り敢えず池○のヘ○スにでも言って恋愛小説(官能小説?)書くための取材からでも始めてみよう w (←当日会場にいた人向けのネタですよ)

MT4.2から「ダイナミックパブリッシングでのページ分割」が可能ということで、以前書いたPagerプラグインのテンプレートタグを下記のページのテンプレートタグ互換に改造しました。

テンプレートタグはエイリアスとしているので以前のページに書いてある書き方でもそのまま動きます。

但し、一点 MTEntriesについては「offset="0"」と書くようにしていましたが、これもダイナミックとあわせて「offset="auto"」と書くようにしました。

上記ページでも「この機能は、詳細なテストを行っていない実験的な機能ですので、サポート対象外です。」とあって、このプラグインも同じく詳細なテストは行えていません(MT4.1でしかテストしてないし)。不具合とかうまく動いたとかフィードバックいただければ嬉しく思います。

テンプレートの編集

次のテンプレートをコピーしてください。

<div class="content-nav">
  <MTIfPreviousResults><a href="<MTPreviousLink>" rel="prev">
           &laquo; Previous</a>&nbsp;&nbsp;</MTIfPreviousResults>
  <MTPagerBlock>
    <MTIfCurrentPage><MTVar name="__value__"><MTElse><a href="<MTPagerLink>"><MTVar name="__value__"></a></MTIfCurrentPage>
    <mt:unless name="__last__">&nbsp;</mt:unless>
  </MTPagerBlock>
 <MTIfMoreResults>&nbsp;&nbsp;<a href="<MTNextLink>" rel="next">
         Next &raquo;</a>
 </MTIfMoreResults>
</div>

ここではカテゴリ別ブログ記事リストテンプレートを編集します。既に、カテゴリ別ブログ記事リストテンプレートには class の値が content-nav の div 要素で囲まれたブロックがあるので、その部分をコピーしたテンプレートと置き換えます。

次にカテゴリ別ブログ記事リストテンプレートの中から MTEntries ブロックタグを探します。MTEntries ブロックタグに、値が auto の offset モディファイアを追加するか、既に offset モディファイアがあったら値を auto に変更します。また limit モディファイアで、1ページに表示する件数 (例えば 10) を設定します。

加えて対象とするテンプレートの以下のチェックボックスをオンにしてください。

テンプレート編集画面のチェックボックス

Download:

MT4LP5(CSS Nite LP, Disk 5)「Movable Type プロフェッショナルスタイル」の中でalt-tmplフォルダに代替テンプレートを放り込んでそれに手を入れる方法があるよ、ということを例をあげて説明しているのですが、「管理画面をカスタマイズするとバージョンアップで管理画面のインターフェイスが変更された時どうよ」みたいな話が出ます。

実際問題、これはどうしようもないと思います。MT3→MT4で管理画面カスタマイズ系のプラグインの多くがそのままでは動かなくなったことは記憶に新しいと思うわけですが、それでも「壊れにくい」「修正対応しやすい」カスタマイズの方法とか注意点とかがそれなりにあるのでそのあたりを少しご紹介します。

可能な限りプラグインで拡張可能なアクション、ウィジェット、メニュー等として登録するように

例えばボタンひとつ追加、とかの場合は以下のようにMTのプラグインによって拡張する方法が提供されているので、基本的にバージョンアップ時にもそのまま使えます。実際list_actions, page_actionsはMT3系の時も提供されていました。ただ、メジャーバージョンアップの時に仕組み自体が変更になるかならないかはわかりません(menu等はMT4で導入されているし、その辺のしくみが変更になる可能性はないとはいえません*)。

* ただ、これまでの流れを見る限りMTの場合移行の際の互換性には最大限の気配りがされているので、少なくともバージョン一つアップして使えないってことは考えにくいと思います。

プラグインアクション(list)


sub init_registry {
    my $plugin = shift;
    $plugin->registry({
        applications => {
            cms => {
                list_actions =>

プラグインアクション(リスト)

プラグインアクション(page)


sub init_registry {
    my $plugin = shift;
    $plugin->registry({
        applications => {
            cms => {
                page_actions =>

プラグインアクション(ページ)

メニュー(dialog)

sub init_registry {

    my $plugin = shift;
    $plugin->registry({
        applications => {
            cms => {
                menus => {
                    'create:ui_sample_dialog' => {
                        dialog => 'foo',

メニュー(mode)


sub init_registry {
    my $plugin = shift;
    $plugin->registry({
        applications => {
            cms => {
                menus => {
                    'create:ui_sample_mode' => {
                        mode => 'foo',

メニュー

ダッシュボード(widget)


sub init_registry {
    my $plugin = shift;
    $plugin->registry({
        widgets => {
            my_widgets => {
                label    => 'My Widget',

ダッシュボードウィジェット

カスタムインポートフォーマット


sub init_registry {
    my $plugin = shift;
    $plugin->registry({
        'import_formats' => {
            'import_ctsv' => {
                label => 'CSV or Tab-Separated Values',

インポートフォーマット

クイックフィルタ


sub init_registry {
    my $plugin = shift;
    $plugin->registry({
        applications => {
            cms => {
                list_filters   => {
                    entry => {
                        next_approval => {
                            label => 'Next revision awaiting approval',
                            order   => 1000,
                            handler => sub {
                                my ( $terms, $args ) = @_;
                                $terms->{next_status} = 6;
                            },
                        },

クイックフィルタ

template_paramコールバックのDOMScriptingで拡張する

template_param, template_source, template_output コールバックで管理画面に変更を加えるときは正規表現でソース等を書き換えるよりもtemplate_paramコールバックのDOMScriptingで拡張するほうが(比較的)壊れにくい。正規表現で置換とかやらないと実現出来ないケースも多いとは思うけれど、その場合でもソースの書き換えは最小限ので済ませ、template_paramで値をセットしたり書き換える箇所が後から変更になっても柔軟に対応出来るようにalt-tmplと組み合わせる(テンプレートにソースを挿入するポイントにコメントを入れるとか)等、工夫次第でメンテナンス性の高いカスタマイズとすることもできるでしょう。

BlogBody, BlogMore, BlogKeyword, BlogExcerptフィールドを追加する例


sub init_registry {
    my $plugin = shift;
    $plugin->registry({
        object_types => {
            'blog' => {
                'text' => 'text',
                'keywords' => 'text',
                'text_more' => 'text',
                'excerpt' => 'text',
            },
        },
        callbacks => {
            'MT::App::CMS::template_param.cfg_prefs'
                => ¥&_blog_extras_param,
        },
   });
}

sub _blog_extras_param {
    my ($cb, $app, $param, $tmpl) = @_;
    my $pointer_field = $tmpl->getElementById('description');
    my $nodeset = $tmpl->createElement('app:setting', { id => 'keywords', label => $plugin->translate('Keywords') , required => 0 });
    my $innerHTML = '<div class="textarea-wrapper"><textarea name="keywords" id="keywords" class="full-width short" cols="" rows=""><mt:var name="keywords" escape_html="1"></textarea></div>';
    $nodeset->innerHTML($innerHTML);
    $tmpl->insertAfter($nodeset, $pointer_field);
    $nodeset = $tmpl->createElement('app:setting', { id => 'excerpt', label => $plugin->translate('Excerpt') , required => 0 });
    $innerHTML = '<div class="textarea-wrapper"><textarea name="excerpt" id="excerpt" class="full-width short" cols="" rows=""><mt:var name="excerpt" escape_html="1"></textarea></div>';
    $nodeset->innerHTML($innerHTML);
    $tmpl->insertAfter($nodeset, $pointer_field);
    $nodeset = $tmpl->createElement('app:setting', { id => 'text_more', label => $plugin->translate('Extended Page') , required => 0 });
    $innerHTML = '<div class="textarea-wrapper"><textarea name="text_more" id="text_more" class="full-width short" cols="" rows=""><mt:var name="text_more" escape_html="1"></textarea></div>';
    $nodeset->innerHTML($innerHTML);
    $tmpl->insertAfter($nodeset, $pointer_field);
    $nodeset = $tmpl->createElement('app:setting', { id => 'text', label => $plugin->translate('Text') , required => 0 });
    $innerHTML = '<div class="textarea-wrapper"><textarea name="text" style="height:150px" id="text" class="full-width short" cols="" rows=""><mt:var name="text" escape_html="1"></textarea></div>';
    $nodeset->innerHTML($innerHTML);
    $tmpl->insertAfter($nodeset, $pointer_field);
}

ブログのフィールド拡張

alt-tmplの書き換えでは追加・変更箇所をできるだけ外部ファイルとしてインクルードする

alt-tmplにコピーを置いて直接手を入れる場合は「テンプレートの見通しを良くする」「変更箇所がわかりやすいようにする」というオーソドックスな考え方でメンテナンス性向上とバージョンアップ時の対応コストを下げることができるでしょう。

例えば以下のようにして変更箇所をインクルードファイルにしておけばバージョンアップの際にそのまま使えるかもしれない(CSSとかid/class名の変更くらいは必要かもしれないけれど)。


<mt:include name="include/edit_entry_extra.tmpl" id="edit_entry_extra">

テンプレートの変更箇所にコメントを入れる

お約束ということで。


<mt:ignore>======拡張フィールドの追加======</mt:ignore>
<mt:include name="include/edit_entry_extra.tmpl" id="edit_entry_extra">

知らんがな(笑)。

なんででしょうね? いや、部外者の僕にわかる筈もないのですが。

  1. 相手の会社のことも調べないで電話で営業してくるから(制作会社に...)
  2. 御社にはノウハウがないでしょうから我が社のパートナーになりませんか、とか言ってくるから

というのは半分は冗談だけど(いや、半分と書いたのは実際にそういう営業が結構あるので)。

「なぜSEOは嫌われるのか?」と言っているということは、嫌われてる自覚があるわけですよね、きっと。

もし(1)から(4)のすべてが正しいと納得がいく方は、論理的思考に向いていないと思うべきである。

おいちょっと待てw 何このあげ足取りのような表現。検索ユーザーAさんのケース、サイトオーナーBさんのケース、SOHOビギナーCさんのケース、ブロガーDさんのケースって書いてあるわけで同一人物が言っているわけじゃないんでしょう? すべて正しいかどうかはともかく、(1)も(2)も(3)も(4)もありがちなことだよね。うん、あるあるって(笑)。

という人は論理的思考に向いていないって...で、結びがこれ?

W3C勧告とか論理構造とかWeb標準とか

昔の記事の再掲載ですかこれ。もはや(X)HTMLの構造をいぢくりまわしたところで効果がどれほどあるのか疑わしいと思うのは僕だけか?

追記(強調は筆者):

Internet ExplorerやFirefox、Safariでほぼ同じに表示されないページ、見出しや段落、リストで構造化されていないコンテンツは、どんなに内容が深くても、良いとは言えないのである。

ブラウザ毎にほぼ同じに表示されること? が良いコンテンツの条件だって?

このブログとかウチの会社のサイトのページランクが上がった経緯

もはやページランクがどうって話じゃないと言われているみたいだし僕も別にGoogleのランクを上げることに腐心しているわけじゃないのだが、最近ページランクがひとつ上がりました。

で、これはSEOとか気にした結果でもW3C勧告とか論理構造とかWeb標準とかを気にして「最適化」を図った結果でもないのです。

ランクが上がった理由はだいたい分かっているのです(この「だいたい」ってのが結構重要で、アクセス解析とかもそうだけど、サイトの運営や方向性を考える時には「木を見て森を見ず」にならないよう、限られたリソースと時間を割いてあまり細かなところを見過ぎないってのも大切かと思うのですね)。細かな数字の分析もそりゃ余裕があればやれば良いですが、大きなところを見て、あとはさっさと手を打っていくことが大切かと。

えー、ランクが上がった理由は、ひと言でいえば被リンクが増えたからでしょう。これもノウハウとか言う程のもんでもなくて、ちょっとでも検索エンジン/SEO(←SEO言うな)に興味のある方なら知っていることですよね。

では、どうやって?

  • ブログに数多くエントリを上げた。で、時々SBM等で炎上した。

違! (違わない?) いや、でもエントリを数多く上げたのは事実で、それは去年の4月くらいに「ちょっと(ほぼ)毎日書いてみようか」と思って意図的にやってみたのだ。

それはまぁそうとして、他には...

  1. サイトのデザインと内容をリニューアルした。但し特にSEOとか気にしてリニューアルしていない。事業の方向性が少しずつ変わって来たので(また、これからこっちにシフトしていくよ、という部分を反映して)それにあわせて再構築したということ。
  2. 会社のサイトにちょっとしたプログラムを置いたりウェブサービスを作ったりした(このゲートウェイはいくつかのサイトの運営者の方から自分のサイトにリンクつけていいですか? といった問合せをいただいたりして、そこで紹介していただいたり)。
  3. セミナー(セミナーなのかどうかわからんのですがこれとか)とかイベント(これとか(大阪も))呼ばれたものは出来るだけ参加して、呼ばれなくても自分で出たり(これとか)
  4. はじめて製品というものを作って、プレスリリース代行サービスを利用して投げ込みをしたり(利用したのはこちらの会社さん。他にもいくつかあって、特にどうしてもこの会社っていうポイントは見つからなかったけど、きちんとサイトが作られている印象だったので)。
  5. シックス・アパートさんのProNet Japan (拠点登録ってのもしたので大阪も) への加盟とかAcc04(2006 - 既にページがないみたいだけど)の協賛とかWeb制作者年鑑への登録 (リンクは稼げてないけど) とか、普通に販促に少しばかりのコストをかけたということ。
  6. アワードにエントリー。2006年は小口の協賛だったけど、今年は応募者として参加(入賞)(エントリーには費用がかかったけど、大した値段じゃないし、そういうコストをきちんと払うということを行った)。

結局、意図的にお金を払って被リンクを増やそうとして行ったのは 4.のプレスリリースくらい(この4にしても、被リンクというより単なるリリースだし、5.はまぁそれにあたるかもしれないけれど、リンクが目的ではないし、6.は入賞しなきゃどうにもならんかったわけで)。

1.のリニューアルにしても、こういう会社(制作会社)だからWeb標準とか丁寧にコーディングすることは前提なわけですが、考えていたのはビジュアルをがらっと変えることによるブランディング(主に人材採用面を考えて)と、事業の再構築、実態にあわせた内容の見直しというもので、キーワードがどうとかたいして考えちゃいなかったのです(サイトに「SEO」という言葉が消えていた、というのも本当に後から検索して気づいた)。

ウチはネットショップでもないし、業種とか仕事の実態次第ではもっともっとSEOとか言わなきゃならんこともあるのでしょうけど、結局SEOっていってもこうした施策(普通に事業活動とか広報活動ともいう)を行った結果起こること(被リンクの増加、特定キーワードへの最適化)をトレースしているだけであって、費用(コストだけじゃなく手間とか社内のリソースを使うことも含む)かけ方として、SEO会社に依頼するのがいいのか、経営の中で考えて適切な施策を打つのが良いのかは、それぞれが判断すればいいことじゃない? と思うわけですが。

ちなみに、プレスリリース代行会社に払ったコストは5万円もかかってませんし、もちろん製品の開発やウェブサービス、サイトリニューアルは内製とはいえ無料なわけじゃないのですが、継続してかかるコストもほとんどなかった、というのが現実です。

だから、SEOってのは経営であり広報であり事業活動であって、一般的に言われるSEO技術やテクニックってのはあくまでもそれによって起こる事象をなぞる技術なんではないでしょうか(だから事業活動が伴わずに事象だけがなぞられると嫌われる、ということじゃないでしょうかね)。

SEO生業にしている人が本当に怖いのは「◎間違いだらけの「SEO批判」~なぜSEOは嫌われるのか?」で書かれているような「批判」じゃなくて「検索エンジンに嫌われる」ことだと思うわけですが、嫌われないか気にしながらやる商売ってのもあんまり精神に宜しくない商売じゃないかと思うわけで、僕はやりたくないなぁ。

結論

結論は、ありません。いや、強いて言うなら僕の会社ではSEOはやりません。経営の戦略に沿って、どのようにアウトプットしていけばいいか、その中でウェブをどう活用していけばいいかについての提案やそのための仕組みづくりや戦略の遂行はサポートします。SEOはやりません。

追記:何か以前にも同じようなこと書いてたな。

発端はこれ。

何か古い記事が再掲載されてるということであれこれツッコミが入ってますね。

ベアワードのファイルハンドルはグローバルということですね。とはいえ、Googleとかで調べると実際出てくるのは比較的古いものが多いようで。

Movable Type(4.1)はどうしているんだろうと思って覗いてみたらみたらこんなコードが(App:CMSのcreate_dashboard_stats_file部分)。


    local *FOUT;
    if ( !open( FOUT, ">$file" ) ) {
        return;
    }

「local *FOUT;」とな。で、まぁそれは本題ではなくて、MTの場合はFileMgrを使うということなんだろうな。


use lib $ENV{MT_HOME} ? "$ENV{MT_HOME}/lib" : 'lib';

use MT;
use MT::FileMgr;

my $src    = 'Hello FileMgr!';
my $updata = 'Hello FileMgr! (Updated)';
my $out    = 'hello.txt';
my $put    = 'put.txt';
my $rename = 'rename.txt';
my $dir    = 'directory';

$out       = File::Spec->catdir( $dir, $out );
$put       = File::Spec->catdir( $dir, $put );
$rename    = File::Spec->catdir( $dir, $rename );

my $fmgr = MT::FileMgr->new( 'Local' ) or die MT::FileMgr->errstr;

print $fmgr->mkpath( $dir );

# directoryを作成する (成功した場合「1」)

print "¥n";

print $fmgr->exists( $dir );

# directoryが存在するか (存在する場合「1」)

print "¥n";

print $fmgr->can_write( $dir );

# directoryが書き込み可能か (書き込み可能な場合「1」)

print "¥n";

print $fmgr->put_data( $src, $out );

# directory/hello.txt に 'Hello FileMgr!' を書き込む (戻り値はバイト数)

print "¥n";

print $fmgr->put( $out , $put );

# directory/put.txt に hello.txt の中身を書き込む (戻り値はバイト数)

print "¥n";

print $fmgr->content_is_updated( $out, ¥$updata );

# directory/out.txt の中身(Hello FileMgr!)と $updata(Hello FileMgr! (Updated)) を比較する (値が異なる場合「1」)

print "¥n";

print $fmgr->rename( $put, $rename );

# directory/put.txt を directory/rename.txt にリネームする (成功した場合「1」)

print "¥n";

print $fmgr->get_data( $rename );

# directory/rename.txt の内容をprintする

実行結果


1
1
1
14
14
1
1
Hello FileMgr!

MT::FileMgr->new( 'Local' ) のところ、 MT::FileMgr->new( 'FTP',@args ) (@argsにFTPホスト、ログイン名、パスワードを入れる)とFTPサーバー上のファイル読み書きができる(らしい。そうなんだ...知らなかった)。

参考:

Facebook

Twitter

このアーカイブについて

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

前のアーカイブは2008年5月です。

次のアーカイブは2008年7月です。

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

Powered by Movable Type 6.2.6