2007-07-17

Movable Type プラグインアーカイブをつくりました。

未だに? ココログの方にリンクが貼られたりするので (&ブログのエントリーに書いては都度アップしていたのが今となってわかりにくすぎるので) これまでに書いたプラグインをまとめたページを作りました。

今後はこちらの方でメンテナンスしていきます。



2007-07-17 プログラミング | | コメント (0) | トラックバック (0)

2007-01-31

Hyper EstraierでMovableType検索。

以前のエントリー「mt-search.cgiの代替プログラム。」で書いたように、mt-search.cgiは速度面や負荷に難があるので代替プログラムを書いてみた。ずいぶんマシになったとは思うがまだまだ遅い。

ということで MovableType にHyper Estraierの「文書ドラフト」を出力するテンプレートを追加してそれに対してインデックス作成→検索を行い、精度が高く高速な検索を実現できた。

別館の方に詳細は書いたので、実装方法はそちらを参考に。

Hyper Estraierの「文書ドラフト」をMTから生成して検索する。

Junnama Online (Mirror)検索

2007-01-31 プログラミング | | コメント (0) | トラックバック (0)

2007-01-25

mt-search.cgiの代替プログラム。

2007/6/6追記：CGI版を公開しました。

mt-search.cgi は実際にビジネスブログ等で使うのはちょっと非力な気がするので (一定時間置かないと再検索できなかったり、タグの中身も検索してしまったり検索速度の問題もあるし) 、代替プログラムを書いてみた。

PHPでMySQLを検索するという手もあるわけだが、MySQL限定っていうのもMTらしくないし、かといって重たくなっても嫌なのでプログラム自体はMT APIを利用したPerlプログラムとして、PHPからPerlを呼び出して検索するようにした。SQLで検索せず正規表現で一つ一つマッチするかどうか見ている。

SQLで検索するよりは不利だけど、CGI起動の待ち時間が無いので体感速度的にはまずまずかと。

同じプログラムでCGIでも動作するように作ったので一応両方同じ動作をする。

ローカルで1000エントリ(SQLite)程度を対象に検索して0.2〜0.3秒。

公開用に設置している以下の環境ではマシンがちょっと非力ではあるけどMySQL、エントリー数は100強。

せっかくなので、

PHP版:
※1月31日追記：PHP版をHyper Estraierを使用したものに変更しました。
CGI版:
mt-search.cgi：

※広告↓貼っておいて何ですが、MT構築・カスタマイズは当社へ!


検索結果画面

機能としては、

  1. Blog名(+description)、カテゴリー名(+description)、エントリー名＋エントリー本文(+text_more,excerpt,keyword)を対象とする
  2. タグの中身は検索しない (画像のALT属性は検索する)
  3. Blog名、カテゴリー名でも検索するかどうかは設定で変更できる
  4. 指定した件数でページ送り
  5. スペース区切りでand検索

# このまま移転しちまおうかな...

2007-01-25 プログラミング | | コメント (1) | トラックバック (0)

2007-01-14

MovableType Background Rebuilder Plugin(beta6).

エントリ一覧→「削除」の際に複数エントリーが削除されないバグを修正
エントリ一覧→「その他の操作」→「公開する」「非公開にする」のアラートメッセージを修正


BackgroundRebuild_beta6.zip
BackgroundRebuild_beta7.zip(12KB)
プライマリ・ページはこちら。

2007-01-14 プログラミング | | コメント (0) | トラックバック (0)

2007-01-11

MovableTypeの体感速度を上げる(続き)。(MovableType Background Rebuilder Plugin(β5)).

※最新版はこちらから。

エントリ一覧→「再構築」, 「その他の操作」→「公開する」「非公開にする」のバックグラウンド化
エントリ編集→「保存」の際にカテゴリ情報が保存されない不具合を修正しました。

# カテゴリは盲点でした。Entryとは別に、MT::Placement で指定されているわけですね。

2007-01-11 プログラミング | | コメント (0) | トラックバック (1)

2007-01-05

MovableTypeの体感速度を上げる。

MovableType Background Rebuilder Plugin.の改良版。 一応β4ということで。

※最新版(1.0RC1)はこちらから。 関連エントリ：

「別プロセスで再構築を行い、CMSの画面上は結果を先に返す」というのが基本的にやっていることなのだが、再構築は確かに早くなるが、負荷の面ではどうなんだろう。
それでもレスポンスを先に返すことで（実際には結果のページに先にリダイレクトしている）、明らかに体感速度は上がる。

今回の改良点は大きく分けて2点。

1点めは、改良というか機能の追加で、エントリーの編集画面でエントリーの「保存」「削除」をクリックした時のエントリーの再構築処理をバックグラウンド化してみた。

「保存」クリック→「GIFアニメーション表示」→「変更を保存しました。」

というのを

「保存」クリック→「変更を保存しました。」※再構築はバックグラウンドで。

今回はブログ全体の再構築の必要がないので、該当するエントリ、インデックス、前後のエントリのみを再構築する。バックグランドでの処理時間はだいたい2〜3秒。「変更を保存しました。」は正確には嘘だけど、「保存」→「変更を保存しました。」→「エントリーを確認」でエントリーを別ウィンドウで開いた時、まず再構築は終わっているから、ここはそのまま「変更を保存しました。」。
エントリーを公開状態から下書きに戻した際にも、インデックスと関連するアーカイブ、前後のエントリを再構築するようにしている。

同じくエントリーの編集画面からエントリーを「削除」した時、デフォルトの動作はエントリーの一覧画面が表示され、変更を反映するために「再構築してください」のメッセージが表示されるのだが、1つのエントリーを削除した時に全体を再構築するのは効率が悪いような気がしたのでここの処理も変えるようにした。 「削除」した時にはそのひとつ前か後（$entry->previous、もしくは $entry->next）のエントリーに対して再構築をかけ（もちろんバックグラウンドで）、エントリーの一覧へリダイレクトする。

MT3.3はかなり再構築については考えられていると感じる。（ローカル環境で見ていると良く分かるのだが）ブログ全体に対して再構築をかけても、不要なファイルの更新はされないようになっている（ように見える）。

それでも、個別エントリーを保存した時にブログ全体に対して再構築をかけると（デフォルトテンプレートでエントリ数300、MacBook+SQLite+MT3.3）約7秒。一方個別エントリー、前後のエントリー、関連するアーカイブ＋インデックス再構築だと2〜3秒。

後者の方が書くのは面倒だけど、そうするのが筋? かと思ってそのようにした。

もう一点は前回の「フィードバック」を受け取る部分の改良。

Ajaxで非同期に結果を取得しにいくのが結局負荷を増やしてしまうことに繋がるので、せめて結果を受取りに行く動作の開始待ち時間を設定できるようにした。もちろん、結果が気にならない人は結果を受け取らないよう設定してもらえればその部分の負荷はかからない。デフォルトは3秒。

すべてデフォルト設定の状態の場合、
「バックグラウンド再構築」又は「すべてのブログを再構築」をクリック→「再構築プロセスを開始しました。」表示→3秒待つ→その後1秒毎に結果取得のCGIにアクセスを試み、結果が取得した時点で非同期通信はストップ。
その後の3秒で取得に失敗した場合はエラーを表示。各数値はプラグインの設定画面で設定できるようにしてあるので、環境やエントリー数によって最適な値を調整することで負荷を最小限にできると思う。

と、いうことで、あとはエントリー一覧画面からチェックボックス選択→「再構築」の部分かなぁ...と思いますが、仕事が始まっちゃったので、残りはいつできることやら...



2007-01-05 プログラミング | | コメント (1) | トラックバック (2)

2007-01-04

MTのプラグインを書く10の理由。

去年の11月から2ヶ月と少し、MovableTypeのプラグインばかり書いているような気がする。ここに書くネタもそればっかり。

精力的に様々なプラグインをリリースしているFujimotoさんとか、他にも何人かいらっしゃるのですが、後発? の僕なりにMT のプラグイン開発をしていて思ったことをちょっとまとめてみる。

MTのプラグインを書く10の理由

別に10でなくとも良いのだが、語呂が良いので、まぁ深く考えずに。
個人的なことと仕事のことも混ぜこぜであるが、それもまぁ、なんだ...

  1. パターンを覚えれば後はすごく楽である。

    例えば、年末のウチの会社の社内プレゼンの時に色々なプラグインをその場で書いたり改造したりというのを実際にやってみたのだが、テキストフィルター等は正規表現でテキストを置換するだけだから、基本のひな形が作れればあとは様々なものがすぐにできる。

  2. ちょっとしたものでも実用性の高いものが書ける。

    KOFの時にやったのが「丸付き数字を括弧付き数字に変換するフィルター」。 基本、ビジネスブログというか企業サイトの受託をやっているので「運用」のことを問われてCMS的にMT、ということがスタートだから、ドキュメントに「アクセシビリティ指針」とかで「この文字は使わないでください」とか書かないといけなくなるケースがある。 ただ、本当はそんなこと書きたくないし、使う側も気にしたくない筈である。

    「この文字は使わないでください」→「この文字は使えません」→「この文字は適切な文字に自動置換されます」

    どれが使い手に優しく読み手に優しいシステムだろうか。

  3. 「技」でカバーするよりスマート、且つコストを下げられる。

    MTをCMSとして使う場合、例えばエントリーの並べ順をどう制御するか、等設計段階で色々気をつける必要が出てくる。

    この例で言えば、エントリーのタイトルの先頭に数字を入れる（出力時に数字は切る）とか、追記欄、抜粋（概要）欄に数字を入れる、といった方法が良く知られている（←そうなのか? 実際にウチのスタッフが行っていた方法でもあるが）。

    それはそれで良いのだが、エントリーが増えた時、順番を一つ一つエントリー編集画面を開いて制御するのか? 間に一つエントリを入れたいときはどうするんだ? というと、「000-001-000」とかにすると言う。間に数字を入れやすいように。

    少し考えれば分かることだが、並べ替えを頻繁に行い、エントリーが増えてくると訳が分からなくなる。

    運用のことを考えてのCMSなのに。

    では、プラグイン書き? はこうすればいいんじゃないか? というアイデアが湧く。で実際に書く。慣れてくれば時間はさほどかからない。

    CMSでエントリーの並べ順を制御する例

  4. MT APIが良く出来ている。

    例えば、タブ区切りテキストファイルを用意して1行に1エントリの情報を入れる。 左から、BlogのID、エントリタイトル、出力ファイル名、テキスト、追記、抜粋（概要）を入力、以下のようなスクリプトを走らせる。

    require MT;
use MT::Entry;
open(FH, $file_path);
while (<FH>) {
	my $line= $_;
	my @datas = split(/¥t/,$line);
	my $entry = MT::Entry->new;
	$entry->blog_id($datas[0]);
	$entry->author_id(1);
	$entry->status(2);
	$entry->title($datas[1]);
	$entry->basename($datas[2]);
	$entry->text($datas[3]);
	$entry->text_more($datas[4]);
	$entry->excerpt($datas[5]);
	$entry->save or die $entry->errstr;
}
close(FH);

    データベースへのアクセスは意識する必要がないし、SQL文も書かなくて良い。
    # そもそも自分がSQLが得意じゃないというのもあるけど。

    MT APIについては、「Movable Type オブジェクト・リファレンス」が公開されているので、これを見ながら書けば良い（このリファレンスについてはところどころ違うんじゃね? というところもあるのだが...）。

    ブログ、エントリやコメント等へのアクセス方法は、MT::Objectの項を見て基本をマスターしてしまえば、あとはさほど意識する必要がない。

    必要に応じてPHPMyAdmin等でDBの中身をチェックしながら作業を行えば、各種オブジェクトが自在? に操えるようになる。

  5. 簡単な割には、そこへ踏み出す人は意外と少ない。

    と、いう気がするだけです...はい

    ただ、こういう経験はある。外部の人にMTベースの開発案件を依頼した時、「PHP+MySQLの方が自分的には絶対早いので、MTのデータベースにPHPからアクセスして実装したい」のだと。
    で、（今だから言えることではあるが）出来上がったものは、MT APIを利用した開発と比較して、やはりやり方に「力技」的な部分が多く、UIの面でも不満の残るものとなってしまった。

  6. 通常のプロジェクトと比較して、「ハック」している気分が強くなる。

    TransformerプラグインでCMSのカスタマイズする場合、「MTの振る舞いを良く観察して」→「操作の流れ、どこで何が行われているかを把握して」→「その部分に割り込んだり、呼び出されるテンプレートを書き換える」という手順になることが多いのだが、

    「設計」→「実装」→「検証」

    が一般の開発の流れだとしたら、

    「観察・検証」→「実装」

    みたいな感覚である。とにかく1からゴリゴリ書く人には向いていないような気もするが、横着好きで手を抜くのが大好きな人は（もちろん、良い意味である）、ハマるような気がする。

    エントリー編集画面のカスタマイズ例

  7. MT自体がプラットフォームであり、ユーザーがそこに存在する。

    以前、MacOS用のデスクトップアプリなんかをちょこちょこ作成したり公開したりしていたこともあるが、Macって少数派ではあるがユーザーは確実にいる訳で、だからこそ開発意欲が湧く。もちろんMacユーザーとMTユーザーの数を比較するのもナンセンスだが、何と行ってもブログのスタンダードなツールであるし、自分が作っていて面白いという以上に、ユーザーがそこに居る、というのが動機になる。

  8. CMSのカスタマイズ系プラグイン開発では、デザインを考えなくて良い。

    アイコンひとつ、テーブルのセルの色一つ、プログラム書いてりゃWebアプリがつくれるわけではない。そこにデザイナーとの協業が入ったとしても、この部分のデザインどうするの? みたいなやりとりは絶対発生する。

    MTについては、MTのCSSを基本的に踏襲すれば良いわけだから、デザイン部分についてはほとんど考えなくて良い。

    何よりナビゲーション部分なんかは逆に変更すると戸惑うだろうから、さわらないようにすべきだし、こういった部分で頭を使わなくて済むのはメリットだろう。

    エントリー一覧表示のカスタマイズ例

  9. デザイナーとの協業が可能になる。

    ひとつ前の項目とダブる部分もあるが、MTの場合はWebデザイナーにも認知があるから、「こんなコンテナタグ用意したし、引数でこう変化するように作ったからフロント部分はお任せね」ってなことが実際に可能である。

    テンプレートエンジンとか色々あるけれど（実際MTもHTML::Template という Perl モジュールが使われている）、Webデザイナーの多くが例えばSmartyでの開発経験を持っているわけではない。そして、それらの多くは開発者側からのアプローチである。

    その点、「MTとかCSSとかできなくて何がWebデザイナーよ、」くらいの感覚は浸透している（ような気がする）。

    そういった面で、CMSが絡む仕事をデザイナーと進めやすいツールだと言えると思う。

    # あ、別に僕はプログラマでも何でもないです。
    どっちかと言えばデザインや実装の側に近い人間なのですが。

  10. 7〜8割くらいはMTで実現できるのだが...という開発案件のベースに使える

    ユーザー認証やエントリーの登録・管理等の基本部分だけでも、一から設計して実装するのはそんなに簡単なもんじゃない。

    実際、イチからやったら2ヶ月では絶対に無理! という案件も、MTをベースにすることで1ヶ月で骨格ができてしまった、という経験がある。 仕事の場合は特に、人件費とライセンスを天秤にかけたらライセンス料かかってもこれでやっちまった方が早い、という要素は重要だと思う。

といったことで、何でこんなエントリを長々書いたかというと、MTだけじゃないんだけど、サイト制作についてこんなアプローチを最近はとっていて、それが面白いぜ! ってことが言いたかったのです。

で、一緒に誰かやらないか? ということで、当社では人材を募集中です。

僕が最近あれこれ書いているのは、仕事で書いている中から派生したものだったり、仕事でMTをCMSとして導入したい、という案件でやっている中で「何でこれができないんだろう?」「何かこれ、使いにくくないか? （CMSじゃなくてブログだから仕方ない面もあるのだが）」という中から生まれて来たものです。

経験は問いません。
何より、今こうやって「創る」ことが本当に楽しいので、教える意欲も満々です。

まぁここを見ている人で、興味が湧いたなら、一度まず話をしませんか?

2007-01-04 プログラミング | | コメント (0) | トラックバック (2)

2007-01-03

MovableType Background Rebuilder Plugin(2).

※最新版はこちらから。

何人かの方が試してくださったようで、正常に動いたとの報告をもらえた。
ただ、再構築の結果を一切フィードバックしないので「正常に動いてる...っぽい? らしい。」という反応がほとんど。

ということで、再構築結果のフィードバックを受け取るようにしてみた。

Bootstrap AppでMTのAPIを利用したCGIを別に作り（MT本体だと負荷がかかりそうなので本末転倒じゃないかと...）再構築結果画面が表示された段階でAjaxというか、JavaScriptでCGIに非同期アクセスを定期的に試み、実行ログができていたらそいつを返す、という感じで。

せっかくなので再構築にかかった時間も表示するようにしてみた。

実行結果の画面表示

※Firefox1.5、Safari 2.0で動作確認済み。
(IEで確認していないのが何ともですが、正常に動いたらどなたか教えてください...) 1/5追記：IE6/7で確認済み

『メイン・メニュー > プラグイン > Background Rebuilder > 設定を表示』で以下の設定が行えるようになっている。

  1. 再構築の実行結果を取得する
    このチェックを入れない場合、再構築の実行結果を表示しない。
  2. 実行結果の取得間隔(ミリ秒)
    再構築の実行結果を取得するプログラムを何ミリ秒単位で取得しにいくかを数字で設定する。
    デフォルト値は1000（1秒）。
    この場合、1秒おきに/plugins/BackgroundRebuild/BackgroundRebuild.cgiへアクセスし、実行結果の取得を試みる。
  3. 実行結果の取得回数
    再構築の実行結果を取得するプログラムの実行回数を指定する。
    デフォルト値は180回。
    この場合（実行結果の取得間隔が「1000」の場合）、1秒おきにMax3分まで再構築実行結果の取得を試みることになる。
  4. すべてを再構築時の実行待ち秒
    「すべてのブログを再構築」ボタンをクリックした時、プログラムはブログ単位で順番に再構築プロセスを走らせるようになっているが、次のブログの再構築プロセスを走らせる前に待ち時間（秒）を設けることをできるようにした。デフォルト値は0秒。

設定値については、かなりサーバー環境によって変える必要があるのではないかと思う。前のエントリにも書いたが、

  • 1GBのメモリを積んだMacBookにMAMPのApache+SQLite+MT3.3-jaの組み合わせ。
  • Blogを5つ、各Blogのテンプレートはデフォルト状態。
  • 以下のようなスクリプトで各ブログに300のエントリを作成してテストを実施。
my $mt = MT->new(Config => 'mt-config.cgi');
use MT::Entry;
for (1..300) {
	my $entry = MT::Entry->new;
	$entry->blog_id($blog_id);
	$entry->author_id(1);
	$entry->status(2);
	$entry->title('TestWeblog_entry_'.$_);
	$entry->basename($_);
	$entry->save or die $entry->errstr;
}

この時、デフォルトの状態で「すべてのブログを再構築する」をクリックして再構築した場合、各ブログの再構築時間は14〜15秒。

『すべてを再構築時の実行待ち秒』を5秒程度に設定した場合、各ブログの再構築時間は4秒前後という結果に。

但し、『すべてを再構築時の実行待ち秒』を設定した場合、CGIの方でその時間待たされるし、デフォルト設定の場合は各ブログの再構築が並行して行われることになるので体感速度的にはデフォルト設定の方が早い。
それでもこの設定項目を設けたのは、『各ブログの再構築を並行して行う』っていうのが、やはり負荷的にどうかということが気になったから。

このあたりはやはりデータを集めないと最適な値は決められないような気もするので、もし導入された方いらっしゃいましたらフィードバックいただけると幸いです。

  • BackgroundRebuild_beta3.zip(12KB)
  • BackgroundRebuild_beta7.zip(12KB)
※最新版はこちらから。

尚、本バージョンからライセンスを『クリエイティブ・コモンズ・ライセンス（表示-非営利-継承 2.5）』としました。

Creative Commons License

2007-01-03 プログラミング | | コメント (3) | トラックバック (2)

2006-12-31

MovableType Background Rebuilder Plugin.

※最新版はこちらから。

今、結構大規模? なMTのプラグインを書いているのですが、その中でちょっと思いつきで作ってみましたので公開します。

「再構築」をバックグラウンドで行うプラグインです。あの、クルクルまわるのを見なくても良くなります。「タイムアウト」でお悩みの方もお試しくださいませ。

ログとったり、再構築後にメールで通知するとかあった方が良いとは思いますが、皆さまの環境できちんと動作するかどうかご確認の上ご利用ください(できればフィードバックいただけると嬉しいです)。

改変、再配布等ご自由にどうぞ。尚、ご利用は自己責任でお願いします。 1/3 新バージョンよりライセンスライセンスを『クリエイティブ・コモンズ・ライセンス（表示-非営利-継承 2.5）』としました。

「すべてのブログを再構築」については、プルダウンの選択状態に関わりなくすべてのBlogのエントリー、アーカイブを再構築します。

それでは、良いお年を!

1/1追記：
若干処理方法を修正しました。
テスト環境で「すべてのBlogを再構築する」際に2つめ以降のBlogのエントリーアーカイブが生成されない現象を見つけたので、1Blogずつリダイレクト→再構築という形にしました。

テストはMacBook+MAMP, SQLiteの環境で、MT3.3、エントリー数300のBlogを5つ(計1500のエントリー)作って行いました。

1/3追記:
フィードバックを受け取れるようにしました。
ライセンスを変更しました。

  • BackgroundRebuild_beta3.zip(12KB)
  • BackgroundRebuild_beta7.zip(12KB)
※最新版はこちらから。

2006-12-31 プログラミング | | コメント (0) | トラックバック (4)

2006-12-03

[KOF2006] MTプラグインサンプル及びドキュメント公開します。

11月18日のKOFで実施した「MovableTypeのプラグイン開発」で当日配布した資料とサンプルソースコードを公開します。

当日はフィルタープラグインでテキストを置換するサンプル、Transformer プラグインで管理画面をカスタマイズするサンプルを例に説明しました。

2006-12-03 プログラミング | | コメント (0) | トラックバック (0)

2006-11-17

MovableTypeのプラグイン開発。

大阪・南港ATCで行われる関西オープンフォーラムで 「MovableTypeプラグイン作成入門」 と題して50分ほど話します。

Transformerプラグインの開発を例にとって、管理画面をカスタマイズする方法を中心に話す予定です。

http://k-of.jp/2006/user_program.html#B34

開始時刻：11月18日(土) 15:00〜 (50 min) [会場:5F-N4]

Six Apart社のウェブログシステム「MovableType」のPerlAPIの利用方法をカスタムプラグイン開発方法を例にとって説明します。
管理画面のカスタマイズによって、CMSのユーザビリティを向上させる事例をご紹介します。

ということで、KOFに来られる方でご興味のある方はどうぞよろしくお願いします。

2006-11-17 プログラミング | | コメント (0) | トラックバック (2)

2006-04-10

Color Quest 英語版。

ちょっと、Webを散策していたら、こんなページに出会ったので...

Apple - Support - Discussions - utility to help colorblind people ...
http://discussions.apple.com/thread.jspa?threadID=322380&tstart=0

After a deep search on the internet, I've found this:

って、僕のページはディープな世界？

先日のエントリー（それ、本当に赤色？）にも書いたのですが、ニーズは少ないんだろうけど、必要とされているソフトなんだろう、ということで、英語版を作ってあげておいた。実は以前に基本的なところは英語化してあったので、それをひっぱりだしてちょこっと直しただけだけど。

Color Quest ver1.0 英語版
<http://alfasado.net/colorquest/index.html>

Color Quest ver1.0 日本語版
<http://alfasado.net/colorquest/index_ja.html>

ついでに日本語版も含めて不具合をいくつか修正（2年半ぶりにさわりました）。

先日のエントリで紹介した学生さんから転載許可が出たので、差し支えない範囲でここに転載します。
こういうのが、作り手をやる気にさせる。

今大学で建築を学んでいます。授業ではCADという、パソコンで 図面をかくソフトを使っていて、そのソフトでは平面図だけではなく、 色のついた、CGで表現したりもします。

しかし、色盲のため青だと思って選んだのが紫だったり、黄色だと思ったのが実は違っていたりして、どんどん色を使わなくなりました。

学年が新しくなり、早くも製図の課題がでました。ずっとこのまま色で悩み続けるのは建築をやるうえで不安なので、色を言葉で表すソフトはないものかと探した結果、野田さんの作成した、Color Questを発見しました！

Color Questはフローティング表示もでき、とても使いやすいです。
Color Questに出会えて本当に嬉しいです！
これからはこのソフトに支えられつつ、色に立ち向かっていきたいと思います！

2006-04-10 プログラミング | | コメント (0) | トラックバック (0)

2004-12-04

プログラミング。

最近はあまりやってないが、プログラミングにハマった時期がある。

昨日、システム系の会社の人と飲んでいて「プログラミングのきっかけ」の話になったのだが、その人の話はわかりやすかった。中学の時にMSXでBasicプログラミングをしたのが最初。本を買ってきてひたすらソースコードを打ち込んでゲームを動かす、というパターン。高校時代には既にプログラミングの道に進むことを決めていて、その後専門学校へ行き、業界に入った、ということだった。僕も中学時代にそんな友人がいたなぁ...ということを思い出したが、プログラムを保存するのにカセットテープを使用する、そんな時代だった。

僕の場合は、友人がそんなことをやっているのを横で見ていても、ちっとも興味が無かった。出来上がったゲームで遊ばせてもらうくらい。何が楽しいのか全然わからなかった。高校時代にも全然興味なし、大学時代も全く触っていなかった。今とは時代が違う、ということもあるけど。

大学時代に、バイト先の先輩がMac（Color Classicだったっけ?）を買って「すごいだろう」てなことを言っていた時も、「はぁ...」ってな感じだった。HyperCardが使いたくてMacを買ったらしい。今となってはすごく良く分かるんだけど、当時は「はぁ...」しか言えなかったんですね。

仕事をするようになって、ワープロは使うようになった。コンピューターをはじめてちゃんと使ったのは20代の後半、はじめて買ったのは28の時（中古のLC575）。

長くなるので省略するが、はじめてプログラム（もどき?）を書いたのは、AppleScriptでだった。当時会社にはインターネットに繋がる環境がなくて、仕事で必要だったので（そんな状態でWebサイトの制作を受注したのだ!）モデムを買ってきてつないだのだが（9600bps!）、インターネットにつなぐ時には社内LAN用の設定を変更しなければならない。そんな切替え機能は当時のOSにはなく、あまりに面倒なので、設定を変更するScriptを書いたのだ。しかも日本語で。


a = b;

じゃなくて

a を bにセットする

だったかな? もう忘れてしまった。

if (a=b){
...
}else{
...
}

とかじゃなくて

もし a が b ならば
...
そうでなければ
...
以上

です。今から考えるとすごい言語だけど、とにかくそこから始まったわけです。で、ソフトにインターフェイスを加えたい...ってなことからHyperCardに行って（5年ぶりの再会）、CGIプログラミングに行って、REALbasicにハマって...

何でこんなことになったんだろう?

2004-12-04 プログラミング | | コメント (0) | トラックバック (0)

その他のカテゴリー

Web制作・ビジネス | ごあいさつ | アクセシビリティ | プログラミング | 書評など | 駄文・雑文