2008年1月アーカイブ

Let's PHP!

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

この物語はフィクションです。えぇ、フィクションですよ。

(男子)だからぁ...ログインしてからさぁ、

perl -MCPAN -e shell

(女子)あの! ログインって何? って言われて...どうもモジュール入れるのとか禁止されてるみたいなんですよ。

(男子)何言ってんのさ? 何言ってんのか意味わかんねぇ。

(女子)...

先輩に言われた通りにお客さんに言ったんですけど何だか駄目らしいんですよぉ...助けてくださいよぉ...

(男子)放っておけよ、そんな客

(女子)そんなわけにはいかないですよぉ...

(PHPer登場)

(PHPer)どれどれ...仕方ネェな、PHPは使える?

(女子)はい、PHPは使えるらしいです。

(PHPer)じゃぁオレが書いてやるよ。何だかなぁ...

(女子)すいません! ありがとうございます。先輩についていきます!

昨日の続き。

管理画面カスタマイズは基本MTタグで行えますが、より便利で使い慣れたMTタグを扱えるようにします。例えばエントリー編集画面でMTEntriesを使うとか。

Download:

プラグインを放り込んだだけでは何もしません。

例えば、エントリーに「タグ」がついているとして、同じタグがついているエントリーを5件「関連するエントリー」として管理画面に表示させたいとします。

  • alt_tmplフォルダにcmsフォルダを作成して tmpl/cms/edit_entry.tmpl のコピーを置く
  • 1054行目、<mt:include name="include/editor.tmpl"> の直下あたりに以下のようなMTタグを貼付ける

<MTCMSEntryContext>
<MTIf name="id">
<MTEntryIfTagged>
    <mtapp:setting
        id="rerated"
        label_class="top-label"
        label="関連エントリー">
<MTSetVarBlock name="entrytags">
    <MTEntryTags glue=" OR ">
        <$MTTagName$>
    </MTEntryTags>
</MTSetVarBlock>
<MTEntries tag="$entrytags" lastn="5">
    <MTSetVarBlock name="current"><MTEntryID></MTSetVarBlock>
    <MTEntriesHeader>
    <ul style="margin-left:18px;margin-top:5px">
    </MTEntriesHeader>
        <MTIf name="id" ne="$current">
        <li style="list-style-type:disc"><a href="<MTEntryPermalink>"><MTEntryTitle></a></li>
        </MTIf>
    <MTEntriesFooter>
    </ul>
    </MTEntriesFooter>
</MTEntries>
    </mtapp:setting>
</MTEntryIfTagged>
</MTIf>
</MTCMSEntryContext>

反映後の管理画面は以下のような感じになります。

注意点としては、エントリーオブジェクト自身にアクセスしたい場合、<MTIf name="id">のようにして、idの有無をチェックする必要があります。idが無い場合=新規エントリーの投稿になりますので、エントリーがロードできなくてエラーを吐いてしまうからです。もちろんインデックステンプレートで利用出来るタグであればこの分岐は必要ありません。

関連するエントリーを表示させるカスタマイズ

パブリックドメイン。利用に制限は設けません。

MT4.1/MTOSによって新しい仕事ができましたね、マークアップエンジニアの皆様。MT4.1ではカスタムフィールドもありますし、管理画面のユーザビリティ向上のためのカスタマイズはプログラマの手を借りずにマークアップエンジニアのあなたが(誰)が行いましょうね??

MTのカスタマイズ方法を紹介したブログとかで、 tmpl/の中のファイルの何行目に手を入れたりパッチを当てたりしてカスタマイズできるよ、みたいな Tips を紹介しているケースがあるけれど、直接ソースをいぢくる必要は全然ないのです。

そりゃぁMTOSはGPLだし直接触っても怒られやしないんだけどね。

例えばエントリーの投稿画面をごにょごにょしたいとして、プラグインの中で


callbacks => {
            'MT::App::CMS::template_param.edit_entry'
                => ¥&_entry_param,

としていぢる方法は良く知られているわけで、MT4からはDOMでもって項目を追加したりすることも出来る。


callbacks => {
            'MT::App::CMS::template_source.edit_entry'
                => ¥&_entry_source,

とすれば、ソースをプログラムで書き換えることができるし、


callbacks => {
            'MT::App::CMS::template_output.edit_entry'
                => ¥&_entry_output,

とすれば、テンプレートレンダリング後のソースにアクセスして書き換えることもできる。

でも、所詮プログラムだし、Perlわかんねーし、ってな場合はノンプログラミングでカスタマイズ出来る方法も用意されている。

mtフォルダの直下に alt_tmpl フォルダがあって、ここに edit_entry.tmplのコピーを置く。このコピーに対して修正をかければ、そいつが優先される。

テンプレートを他のフォルダに置きたければ mt-config.cgi に


AltTemplatePath my-alt-tmpl

とか書けば良い。

プラグインを作成する時に、前述のようにcallbackでDOMとかMT3時代に良く見られたtemplate_sourceを正規表現でって言う方法も良いけど、alt_tmplに置く方法だとノンプログラミングでカスタマイズ出来て、且つノンプログラミングとは言ってもMT4.1のMTタグはもはやプロムラミング言語チックなんだから、代替テンプレートを用意して「管理画面の見た目カスタマイズ部分」と「プラグラミング部分」をうまくわけると効率アップと分業化がうまく出来るんじゃないでしょうかね。

DOMでプラグインが壊れにくいっていってもメジャーアップグレードの時は駄目だろうし、MT4.0→4.1でもやっぱりテンプレート変わってるから調整は皆無にはならないから、見た目調整をプログラミングから分離させる方法は良いと思うんだけど。

プラグインの場合は配布とかセッティングとか一発で、alt_tmplにこれ、pluginにこれ、mt-staticにこれっていかにも面倒なんだが、プラグイン配布とか設置とか考えるのならばテンプレートの場所をプラグインで定義してやれば良い(実はこれを書こうと思ったというか、ちょっとさっきやってみたのがこれで、そう考えると長い前振りだね)。

プラグインでCMSのテンプレートをカスタマイズする際に、プラグインフォルダ直下の/tmplフォルダにテンプレートを置くには以下のように書く。


sub init_request {
    my $plugin = shift;
    my ( $app ) = @_;
    if ( $app->isa('MT::App::CMS') ) {
        $app->config( 'AltTemplatePath', File::Spec->catdir($plugin->path,'tmpl') );
    }
}

というようなことで、管理画面のカスタマイズ方法をまとめ中。

いや、本当にどうでも良いプラグインです。

MTで構築されているサイトを見分ける方法ってありますか? とか聞かれて、そんなのあるわけないんですけど、デフォルトテンプレートをカスタマイズしている程度のサイトはともかくそうでない場合は「なんかやたらと連続した改行とか、HTMLがスカスカに見えるサイトは何だかMTっぽいかも」とか思ったりしたので(テンプレートの見通しが悪いよりましっていうか、別に気にしない人は気にしなくていいんですけどね)。

逆にソースコードとか貼るときは邪魔だし、pre要素とか使うときは邪魔ですけどね。

Download:

パブリックドメイン。利用に制限は設けませんです。

Movable Type >> Plugin というカテゴリーの階層があったとして、Pluginを選択すると自動的に Movable Type にも属するようにしちゃう、というプラグインです(しかしこんな名前でいいのか!? 英語力ないとプラグイン書くより名前とか Description 考える方が面倒じゃ)。

カテゴリーが階層化されている場合に、親カテゴリーを同時に再構築するプラグインってのを前回作成しましたが、そもそもカテゴリーに属するエントリーが無い場合カテゴリーアーカイブやカテゴリー月別アーカイブが吐き出されすらしないということで(「親カテゴリにもチェック入れてください」必殺「運用でカバー」が出かかったので) 作った。

逆に、カテゴリーにチェックを外すときに注意が必要になりますけどね...

Download:

パブリックドメイン。利用に制限は設けません。

エントリーアセットの一覧表示

エントリーに貼付けた画像等のアイテムはMTEntryAssetsタグで取り出せる。 エントリーとアイテムの関連付けはobjectassetテーブルに保存されている、ってのはほとんどの人にとってはどうでも良いことだと思うけど、せっかく関連づいているのだからエントリーの編集画面からアイテムの名前とかタグとか編集したいんじゃないかなぁ...ということで作ってみました。

MT4.1/MTOS専用。4.0では動作しません。

久しぶりにムービーも載せますね。

パブリックドメイン。利用に制限はありません。

数千から1万エントリーくらいのブログを何とかせなあかん! ってな仕事がいくつかあったので、そのあたりにあわせて改良。

mod_rewriteに対応させるとともに、バックグランド再構築を「エントリー保存時」「全再構築時」のどちらで実行させるかをそれぞれに選択出来るようにした。 mod_rewriteに対応させるときは以下のようにテンプレートに.htaccessとか設定しておくと良いかも。


Options -Indexes +SymLinksIfOwnerMatch
<IfModule mod_rewrite.c>
  <IfModule mod_dir.c>
    DirectoryIndex index.php index.html index.htm default.htm default.html default.asp <$MTCGIRelativeURL$>plugins/RebuildAt1stView/RebuildAt1stView.cgi
  </IfModule>
  RewriteEngine on
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteRule ^(.*)$ <$MTCGIRelativeURL$>plugins/RebuildAt1stView/RebuildAt1stView.cgi [L,QSA]
</IfModule>
<IfModule !mod_rewrite.c>
  ErrorDocument 404 <$MTCGIRelativeURL$>plugins/RebuildAt1stView/RebuildAt1stView.cgi
  ErrorDocument 403 <$MTCGIRelativeURL$>plugins/RebuildAt1stView/RebuildAt1stView.cgi
</IfModule>

あと、FileInfoテーブルとBackgroundRebuildテーブル(プラグインで拡張したテーブル)をそれぞれ管理画面からクリアできるようにした。

なぜなら、アーカイブマッピングなんかを変更した時にFileInfoに古いデータが残っていたりする時に再構築時にエラーが発生することがあるので。クリアしたら一旦全構築すれば最新のデータに更新されます。

管理画面のプラグイン設定は以下のような感じに。エントリーの数が多い場合はこの設定のように「エントリー保存時」のみバックグラウンドで再構築する設定がおすすめ。エントリーが数千もあるブログで全再構築をかけると、BackgroundRebuildテーブルに再構築対象のファイルがリストアップされるのですが、このテーブルに数千もファイルが登録されてしまうと、単にエントリーを更新した時にもこの数千に対して処理を行おうとするので何か効率が悪いというか、気持ち悪かったのでこのように。

全再構築後の静的ファイルの生成は run-periodic-task実行時にまとめて行うと良いかと。

RebuildAt1stView設定

また、RebuildAt1stView.cgiをfcgi化しておくとファイルが存在しない時の閲覧がスムーズになるけれどもこちらの事象が気になる方は定期的にプロセスを立ち上げ直すようにしておくと良いかと(実際に僕はそうしている)。

ダウンロード

以下プラグイン開発のためのメモ。

build_file_filter コールバックが呼ばれた時に、それがエントリー保存後の再構築なのか全再構築時の再構築処理なのか、はたまた別のCGI(コメントとか)とかタスク実行による再構築なのかが分かれば、ケースによって再構築を行うかどうかの分岐が出来るのではないかと思ってちょっとMTの振る舞いを調べてみた。

Apache限定かと思うけど、結局は以下のような環境変数をチェックしてケースバイケースで分岐させれば良いんだわ。

  • $ENV{'REDIRECT_URL'};
  • $ENV{'SCRIPT_NAME'};
  • $ENV{'QUERY_STRING'};
  • $ENV{'REQUEST_URI'};
  • QUERY_STRINGに「'&type=entry-'+数字&」が含まれていたらエントリー保存時の再構築と判断
  • SCRIPT_NAMEがAdminScript(例:mt-cgi)でなければ別のスクリプトからの再構築(よって、RebuildAt1stView.(f)cgi, BackgroundRebuild.cgiが含まれていたら再構築を行う、等の分岐をさせる)
  • REDIRECT_URLに値が入っていたら、NotFoundによって渡されたリクエストからの再構築
  • mod_rewriteによるリクエストはREQUEST_URIをチェック、とか

ちとハマったのでメモしておく。


mv Makefile.AP2 Makefile

make

/usr/local/apache2/build/special.mk: No such file or directory

top_dir      = /usr/local/apache2
↓
top_dir      = /etc/httpd

でも同じ。httpd-develが必要? RedHatのサイトには既にない模様。ダウンロードは以下から。

http://apt.freshrpms.net/pub/redhat/linux/9/en/os/i386/RedHat/RPMS/

ここから httpd-devel-2.0.40-21.i386.rpm をダウンロードしてインストール。引き続きmakeできないので、以下のようにしてインストール。


/usr/sbin/apxs -n mod_fastcgi -i -a -c mod_fastcgi.c fcgi_buf.c fcgi_config.c fcgi_pm.c fcgi_protocol.c fcgi_util.c

httpd.confに


LoadModule mod_fastcgi_module /usr/lib/httpd/modules/mod_fastcgi.so

が追加されて再起動時にエラーを吐くのでこいつを削除して以下を追加


LoadModule fastcgi_module modules/mod_fastcgi.so

<IfModule mod_fastcgi.c>
    AddHandler fastcgi-script .fcgi
    FastCgiIpcDir /tmp
    FastCGIConfig -autoUpdate -idle-timeout 120 -killInterval 3600 -maxClassProcesses 6 -maxProcesses 15
    <Location /path/to/foo>
        SetHandler fastcgi-script
    </Location>
</IfModule>

Apacheを再起動。

MT4.1/MTOSでFizzBuzz。

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

昨日の続き。

MT4.1/MTOSで追加されたopモディファイアを使ってFizzBuzz。

* 見やすさのためにインデントや改行入れてます。


<MTEntries lastn="100">
<mt:for from="1" to="100">
<mt:setvarblock name="count_3">
    <mt:var name="__counter__" value="3" op="%">
</mt:setvarblock>
<mt:setvarblock name="count_5">
    <mt:var name="__counter__" value="5" op="%">
</mt:setvarblock>
<mt:if name="count_3" eq="0">
    Fizz
</mt:if>
<mt:if name="count_5" eq="0">
    Buzz
</mt:if>
<mt:unless name="count_3" eq="0">
    <mt:unless name="count_5" eq="0">
        <mt:var name="__counter__">
    </mt:unless>
</mt:unless>
</MTEntries>
</mt:for>

1から100までの数をプリントするプログラムを書け。ただし3の倍数のときは数の代わりに「Fizz」と、5の倍数のときは「Buzz」とプリントし、3と5両方の倍数の場合には「FizzBuzz」とプリントすること。

ということで、例えばこんな感じとか。

perl -e 'for(1..100){print$_ if$_%3&&$_%5;print"Fizz"unless$_%3;print"Buzz"unless$_%5;print"\n"}'

で、これをMT4のテンプレートタグだけで出力してみようということで。意味があるのかどうかわからんが。

* 見やすさのためにインデントや改行入れてます。


<mt:setvar name="count_3" value="1">
<mt:setvar name="count_5" value="1">
<MTEntries lastn="100">
<mt:setvar name="out" value="0">
<mt:if name="count_3" eq="3">
    <mt:setvar name="count_3" value="1">
    Fizz
    <mt:setvar name="out" value="1">
<mt:else>
    <mt:if name="count_3" eq="2">
        <mt:setvar name="count_3" value="3">
    <mt:else>
        <mt:if name="count_3" eq="1">
            <mt:setvar name="count_3" value="2">
        </mt:if>
    </mt:else>
    </mt:if>
</mt:else>
</mt:if>
<mt:if name="count_5" eq="5">
    <mt:setvar name="count_5" value="1">
    Buzz
    <mt:setvar name="out" value="1">
<mt:else>
    <mt:if name="count_5" eq="4">
        <mt:setvar name="count_5" value="5">
    <mt:else>
        <mt:if name="count_5" eq="3">
            <mt:setvar name="count_5" value="4">
        <mt:else>
            <mt:if name="count_5" eq="2">
                <mt:setvar name="count_5" value="3">
            <mt:else>
                <mt:if name="count_5" eq="1">
                    <mt:setvar name="count_5" value="2">
                </mt:if>
            </mt:else>
            </mt:if>
        </mt:else>
        </mt:if>
    </mt:else>
    </mt:if>
</mt:else>
</mt:if>
<mt:if name="out" eq="0">
    <mt:getvar name="__counter__">
</mt:if>
</MTEntries>

さて問題(?)。MT4.1/MTOSだともっとスマートにプログラミングチックな書き方ができると思います。

* 流行んないかな?

追記: 4.1/MTOSで書いてみた。シンプルに書けます。

小粋空間さんのエントリーで紹介されていたこちらのプラグイン (ParentCategoryRebuild 2.0) がMT4で動かないですよ〜作ってくださいよ〜という泣き? が入ったので。

Download:

パブリックドメイン。利用に制限は設けません。

テレビには誰も突っ込まないのは何故だろう?

いや普段テレビって滅多に見ないんだけど、今回のはたまたま見ちゃったってのもあって書く。むしろ「品格」がないのはテレビでは?*

* 分かり切ったこと書くなよって言われそうだけどさ。

これに対する反応として以下のエントリーがあがって、

そんでもって、こう↓来た。

さて。僕の考える「ウェブを作る人」のストレートな反応は、

そんなくだらない大量のエフェリエイトリンク経由して4000万/年の手数料を(クライアント - ユーザーの双方が) とられているくらいだったら、俺がもっと簡単で有益で分かりやすくて低コストでクールなサービスを作ってやるよ!

ユーザーにもクライアントにももっと利益になるサービスを俺たちが作れるんじゃないか!? そんでもって、こんなスパムサイトたち駆逐してやるよ!

というものだ。以上。


以下はさらに駄文。

そいつらがスパム (有害) かどうか評価するのはモノを購入したユーザーと売ったクライアントがすればいい話だ(厳密には携帯の場合お金を出してる親も含めてだったりするかもしれんがそれはユーザーの評価に含むとして)。

もし双方がハッピーだったとしたらそれは外野が口を挟む問題ではない。

もちろんそれをどう取り上げるかについては別の話(「品格」が絡むのだ)。

例外は、それが他者にアンハッピーをもたらした上でのハッピーだった場合。

正確にはこれら4,000万を稼ぐ(←本当だと仮定して)アフェリエイトを凌駕するキラーサービス(分かりやすくいえば検索エンジンとか圧倒的に力のあるショッピングモールとか)が登場して、「そこへ人が流れてしまった後で」こんどはそのキラーサービスを騙して利益を上げようとする行為(ここではじめて「スパム」となる)は「品格」が備わっていない。

まともに反応するとこうなるのだが、実は僕自身はその数字の真偽も本当の内容も知らないから(たまたま番組は見たけど)、あくまでも彼が本当にその数字をたたき出しているという前提で少しだけ触れておくことにした。

*↓最後に、ここに「品格」があることを祈る。エントリー上げる前にいくつかフィルタしたけどさ。

某案件のMTのテンプレートの出力結果がおかしいのでちょっと調べますとのことで、しばらくしてからマークアップ担当からメールが来てこの記事の内容に間違いがあったとのこと。

なので、もらったメールをそのまま貼付けてエントリーを上げるという何という手抜き(笑)。

年度別+月別アーカイブのツリー表示の件ですが、野田さんがブログで公開
されているテンプレート
(http://junnama.alfasado.net/online/2007/11/_mtarc.html)
を使用した場合、

1〜3月の記事が最新の場合に先頭に来る年度が2度表示されてしまいます。

これは、最初の<MTArchiveList>のループのときに下記の部分も表示してしまう
のが原因です。

=========================================================

<mt:if name="FiscalYear" gt="$YYYYMM">
<mt:unless name="printYear">
</ul><$MTArchiveDate format="%Y" calculation="-1"$>年度
<ul class="module-list"><mt:setvar name="printYear" value="1">
</mt:unless>
</mt:if>

=========================================================

下記のソースで解決するかと思われます。

=========================================================
<MTArchiveList archive_type="Monthly">

<mt:unless name="Year">
<mt:setvarblock name="startMonth"><$MTArchiveDate
format="%m"$></mt:setvarblock>
<mt:if name="startMonth" lt="4">
<$MTArchiveDate format="%Y" calculation="-1"$>年度
<ul class="module-list"><mt:else>
<$MTArchiveDate format="%Y"$>年度
<ul class="module-list"></mt:else>
</mt:if>
<mt:setvar name="printYear" value="1"> <====================追加
</mt:unless>

<mt:setvarblock name="CompareYear"><$MTArchiveDate
format="%Y"$></mt:setvarblock>

<mt:if name="Year" ne="$CompareYear"><mt:if name="printYear"><mt:setvar
name="printYear" value="0"><mt:else>
</ul><mt:var name="CompareYear">年度
<ul class="module-list"></mt:else></mt:if></mt:if>

<mt:setvarblock name="Year"><$MTArchiveDate format="%Y"$></mt:setvarblock>
<mt:setvarblock name="YYYYMM"><$MTArchiveDate
format="%Y"$><$MTArchiveDate format="%m"$></mt:setvarblock>
<mt:setvarblock name="FiscalYear"><$MTArchiveDate
format="%Y"$>04</mt:setvarblock>

<mt:if name="FiscalYear" gt="$YYYYMM">
<mt:unless name="printYear">
</ul><$MTArchiveDate format="%Y" calculation="-1"$>年度
<ul class="module-list"><mt:setvar name="printYear" value="1">
</mt:unless>
</mt:if>
<li class="module-list-item"><a
href="<$MTArchiveLink$>"><$MTArchiveTitle$></a></li>
<MTArchiveListFooter>
</ul>
</MTArchiveListFooter>
</MTArchiveList>

=========================================================

2008年の目標3つ。

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

まず、目標や計画を立てる時に少しだけ有用と思う話を最初に。

「こうする、ああする」「こうしたい、ああしたい」ってのは漠然とした単なる「希望」にすぎないので、より具体的にしたい場合は「望ましい結果の状態」を書くと良いのだそうな。だから、「今年はこうする」と書くかわりに「来年の今、こうなっている」と書くことで具体的な目標や計画になる。

まぁ、今ここで書く話とはちょっと違うのだが、仕事や人生での中長期のプランを書く時には覚えておくといいのではないかな。

さて、今年の目標、というか今年の12月31日における「望ましい結果の状態」。

1.生きていること。

あたりまえ? それが前提だって?

いやいや、これを最初にきちんと書いておきたい。こんなことを改めて書いたのは初めてだけど。

たまたまTwitterやmixiとかで何人かの方が身内の方をなくされたことを書かれていたのを目にして、僕はその方たちがその人を失ったことの本当の意味とか重みがわからないからどんな言葉もかけられずにいるのだが、そんなことも多少あってまず自分が生きていることをひとつ目の目標としたい、と何となく思ったのだ。

もちろん、人生を前半/後半に分けるなら多分後半にいるのだろうという自覚というかそんなものもあるのかもしれない。ただ、自分が人生の後半にいるのか終盤にいるのかまだ前半なのかなんてことはわからないのだから、とにかくこの1年をちゃんと生きておこうと。

もちろんやりたいことが一杯あって、まだまだそれらのことをやっていたいという思いが強くあるので余計にそう思うのだけど。

2.自分が生きていることを望んでくれる人がいること。

単に生きていればいいってわけでもなくて、「12月31日」の段階でもそう願ってくれている人が存在すること。もちろん、現状でもそう願ってくれている人はいるんだと思う(思いたい?)けど、1年後もそう思ってもらえていること。

3.その人たちの期待に応えられていること。

信頼というものは、得難く失いやすいものだ。当然ながら期待に応えること即ち言いなりになることではないのだが、自分に何らかの期待をかけてくれる人、自分を必要としてくれる人の信頼に応えられていること。

40超えて今年の目標がそんなもんかい!? って感じかもしれんが、もちろん仕事における目標とか企みとかは沢山ある。仕事においては今年もいくつかのチャレンジをする。そのあたりはまたいずれ書くかもしれないが、自分の目標としてこの3つを掲げておく。

誰が掲げたっておかしくない目標だけど、今までこんなことを掲げたことは一度もなかったわけだから、それはそれで今年の自分らしい目標であると思うよ。

さて、明日から本格的に日常に戻ろう。

とにかく出遅れるというかアンテナは張っているつもりだけど書くのが遅くなりがちな今日この頃。みなさんペース早過ぎますよ。

とfshinさんのエントリーに反応する振り?をしつつ,つらつらWebを徘徊していて面白かったのがこれ。

その時貴方たちは何してますか?マックのレジ打ちですか?

その時? とりあえずプチリタイアして貯めたお金でそこそこの生活してるでしょう。若干の投資なんぞをしてるかもしれんし(まだ必死で目の前の仕事を片付けているかもしれないけどね)。

Web屋って言葉はともかく(僕はそもそもあんまり好きな言葉じゃないけど、多分定義すると僕のようなのがWeb屋の典型なんだろう)、いわゆるWeb屋の仕事ってのは「インターネット上のメディアを作る、運営する、換金する」ことではないのかい? メディアってのはコンテンツでありソフトである。コンテンツやソフトの質は(例えば映像メディアに例えると)NTSCだろうがPALだろうがハイビジョンだろうがMPEGだろうがWindowsMediaだろうが「そんなの関係ねー」わけだが、「運営する」「換金する」のにハイビジョンよりNTSCが有利だったりすることはあるのかもしれん(最近は映像ビジネスやってないからよく分からんけど)。つまり、Web屋にとってのXHTMLだとかCSSだとかJavaScriptだとかPHPだとかPerlだなんだってのは、「インターネット上のメディアを作る、運営する、換金する」ための手段にすぎない。

だから要素技術なんてしょせん手段に過ぎないわけだし、時間が経てば必要とされる技術やメディアの姿は変わってくるのは当然。

現状にしても「つくる」のが主なメシの種なやつもいるし、「つくるためのものをつくる(言語を作るとかCMSやオーサリングツールを作るとか)」ことを生業にしてるやつもいるし、運営でメシ食ってるやつもいるし、運営の仕組みを売ってるやつもいる。要素技術はなくとも換金することがうまくて食ってるやつもいる。

もちろん「換金能力」だって立派な能力である(そしてその通貨単位はとりあえず「円」である)。

えーっと、話がまとまらない方向にいってしまいがちですが、つまり要素技術のどのあたりのスキルを身につけておくべきかってのは、就職のために「エクセルが使えます、CSSが書けます、XXスクリプト書けます」ってのを増やす努力の延長線程度の意味しかなくて、もちろん短期的にはそれは意味のあることではあるが、むしろ大切なのは「何」を判断しキャッチアップするセンスであり思考であり、「現状にあぐらをかかない謙虚さとハングリーさ」であるのだと思いますよ。ええ。

「インターネット上のメディアを作る、運営する、換金する」仕事をしている人たちであるならば、スキルや資格をベースにモノゴトを考えることをやめるべきでしょう。ウチのカイシャ的に昨年は、Webサイト制作に加え、モバイルコンテンツ、そしてTVに組み込まれるコンテンツの仕事もやったし、もちろん「ツクル」ためのしくみを「ツクル(CMSとか)」仕事もやったけど、「インターネット上のメディアを作る、運営する、換金する」という軸は変わりない。

まぁ、ここまでは普通に反応しておく。つまりWeb屋はもっと目線を上げないといかんよね、と。

しかし、

一人で一ヶ月かかって50万とかそんな案件の世界であって、

インドはマジでやばいってホント。

が並んでいるあたりどこまでどう考えてるんでしょうね。 人月単価の話ではないみたいだけど、結局は一人で一ヶ月かかって50万だろうが100万だろうが「インドはマジでやばいってホント。」って原価の話ではないのかい? (50万だって高いんでない? って話ではなくて?)

申し訳ないんだけれど、それは決して2007年におけるwebのメインストリームでは無いよね。

って、「メインストリームで勝負しない」っていうのはきわめて普通の戦略なんだけどな。

いや、申し訳ないんだけれど。

エントリー編集画面で「確認」ボタンをクリックして「プレビュー」するときにプラグインなんかで拡張したデータをプレビューに反映させるため? のコールバック「cms_pre_preview」がMT4.1で追加されていたのでメモしておきます。Custom Fieldのため?

エントリーにPDF2つファイル添付する拡張してる時にプレビューに反映させるコードですが、pdf_ja,pdf_enカラムにアップロードしたファイルのパスを格納しているとして、pdf_ja_org,pdf_en_orgフィールドにアップ済みのファイルパスを放り込んでいる場合のコードをメモっときます(例がわかりにくいと思うけど)。


sub _preview_entry {
    my ($cb, $app, $obj, $data) = @_;
    my $q = $app->param;
    my $pdf_ja = $q->param('pdf_ja_org');
    my $pdf_en = $q->param('pdf_en_org');
    if ( $pdf_ja ) {
        push @$data,
          {
              data_name  => 'pdf_ja_org',
              data_value => $pdf_ja
          };
        $obj->pdf_ja($pdf_ja);
    }
    if ( $pdf_en ) {
        push @$data,
          {
              data_name  => 'pdf_en_org',
              data_value => $pdf_en
          };
        $obj->pdf_en($pdf_en);
    }
}

ついでに「cms_post_preview」の追加と、「build_file」コールバックが呼ばれてくれると嬉しいってのも書いておきます!

Facebook

Twitter

このアーカイブについて

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

前のアーカイブは2007年12月です。

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

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

Powered by Movable Type 6.2.6