実際記事を読んだわけではないのですが、そういえば2,30年前には「2010年ぐらいになるとこんな風になっているのかな！？」と考えたりしたものです。
考えて見れば、2010年。
エヴァンゲリオンが秘密裏に開発されていたり、空飛ぶ車がチューブの中を走っていたり、宇宙怪獣が攻めてきたり、アンドロイドが電気羊の夢を見たり、ほかにもあるかな？そんなイメージがありました。
ですが、実際あんまり劇的には変わってないですね......
2,30年前に比べて明らかに「近未来」と言えるものってなんだろう......？
インターネットとか、携帯電話や無線技術とか、電気自動車とか、そんな感じ？まだあるかなぁ？
いっそ仮想化してしまおうと思って、復旧したデータをもとに新しいサーバーを構築しているのですが、ようやくブログが復活できるぐらいになってきました。
他のサービスが復活するまでまだ時間がかかりそうですが、とりあえず一安心です。
昨年は何かとばたばたしていたせいか、なんだか余裕の無い一年だったように思えます。
今年はもっと精神的に余裕を持って、のほほ～んと過ごしたいと思います。
とはいえ、やってみたいことがたくさんあって、時間的余裕は相変わらず無さそうですが......
しかしベーゴマを廻すのは難しく、うまく廻せませんでした。
「ベイブレード」は廻す部分を便利に自動化して、戦わせることに特化した遊びになっているので、息子にはコマをうまく廻すテクニックは難しかったのでしょう。
(私は世代的？にベーゴマをほとんどやったことが無いので廻せませんが......)
確かに、小さいベーコマを廻すのは難しいので、簡単に廻せたほうが勝負が白熱していいのかもしれません。
ただ、手先の器用さが必要なこととか、廻すテクニックで勝負するという部分が「ベイブレード」では失われているように思えます。
先日私は「Handy Search!」というサイトを作りました。
一般の人や携帯端末などでは意外と敷居の高い「キー入力」をせずとも検索できる仕組みです。
しかし、キーを入力する必要が無ければ、その人はキーを入力するスキルを身に着けることは無くなってしまうのではないでしょうか。
もちろん、障碍を持った方が一般の人と同じように生活できるようにしたり、今までできなかったような短時間での長距離移動ができるようになったりと、できなかったことをできるようにするのは素晴らしいことだと思います。
しかし、便利にするということは、必ずしも人の進化を促すものではなく、かえって自分自身を退化させる危険性があるということも忘れてはならないと思います。
そんな不便さをちょっとでも軽減しようと、検索を補助するサイトを作りました。
「Handy Search!」 (http://handy-s.net/)
あらかじめ「検索ワードランキング」などから検索ワードをDBに入れておき、その検索ワードから検索できるようにすることで、キー入力しなくても検索できるようにしてみました。
検索ワードは自前の入力やアクセス数などで格付けされて、よく使われるものや旬のワードは上に来るようになっています。
ちなみに携帯でも同じURLでアクセスできます。
今回は、英語版もPCだけですけど用意してみました(同じURLです)。
少しでも、ネットワークコンピューティングの使い勝手向上の一助になれば幸いです。
さあどうだ！？
cd /usr/ports/multimedia/ffmpeg/
make install
次に、PHPでffmpegを使うライブラリをインストールします。
こちらはPHPのextensionとして提供されています。インストールは同じくportsから。
cd /usr/ports/graphics/php5-ffmpeg/
make install
何故かmultimediaディレクトリではなくgraphicsディレクトリに入ってるんですよね。謎です。
インストールが完了すると、PHPの設定ファイル/usr/local/etc/php/extension.iniに
extension=ffmpeg.so
のように追加されます。
Apacheを一度再起動して、試しにMPEG4動画の1フレームをとってきて、サムネイルを作成するWebアプリを作ってみました。
$movieFile = 'test.mp4'; //MPEG4ファイルを指定
$MOV = new ffmpeg_movie($movieFile);
$FRM = $MOV->getFrame(10); // 10フレーム目のイメージを取得
$IMG = $FRM->toGDImage();
ob_end_clean();
header('Content-Type: image/jpeg');
imageJpeg($IMG, NULL, 100);
imageDestroy($IMG);
おおっ、画像が表示された。すごいすごい。
]]>
Amazonでこの本を注文して、ちょっと勉強してみました。
先日の導入からしてMVCモデルを踏襲していたので、Zend Frameworkはそれを強要するものかと思っていたのですが、そういうわけでもないみたいですね。
コンポーネント単位で使い分けすることが可能なようで、便利なコンポーネントは活用していきつつ、自前のものでZend Frameworkに無いものなどは組み合わせて使えば効率化できそうですね。
SQL生成モジュールや個人情報がらみのバリデートチェックなどは無いようなので、自前のものを使うようにしようかな。
余談ですがこの本、PHP中級者以上向けの入門書なので、位置づけが難しいですね。
中級者以上がZend Frameworkを知るにはいいのですが、初心者にZend Frameworkを覚えてもらうのにはちょっと敷居が高そうです。
逆に中級者以上だとこの内容では物足りないですし。
Zend Frameworkは、PHPのサイトと同じく、リファレンスページがしっかりできていて、調べやすくなっています。
ただ、私はまだ入門者ということで、リファレンスだとよくわからないのでこちらの記事を参考にしてZend Frameworkのお勉強をはじめました。
......しかし記事の最後までキッチリ作ってもなぜか動かない。なぜだろう。どうしてだろう。
PHP Fatal error: Uncaught exception 'Zend_Controller_Dispatcher_Exception' with message 'Invalid controller specified (error)'
とか言われてしまい、ページは真っ白のまま。
......さんざん調べてようやく原因が判明。
ビューのファイルを置くディレクトリ名の指定で「views/scripts/＜コントローラ名＞/＜アクション名＞.phtml」と書いてあったのですが、
コントローラー名が「Index」だからディレクトリ名も「Index」にしていたのが間違いで、どうもディレクトリ名は「index」と小文字で指定するようでした。
......罠だ......＿|￣|○
実はPostfixは、デフォルトではメールボックスの処理を同時に1通しか処理しないようになっています。
確かに、並列処理してしまうと、時系列順にメールボックスに入らなくなったりする可能性がありますので、このようになっているのだと思います。
それにあわせて「mailbox_command」にProcmailを指定して処理させているときも、1通ずつしかメールを処理してくれません。
そうするとおのずと、SpamAssassinも1通づつしかメールを処理しません。
local_destination_recipient_limit = 2
上記のように記述すると、同時に2通のメールをメールボックスで処理しますので、「mailbox_command」も2通同時に処理されます。
SpamAssassinも2通並列で処理してくれますので、大量のメールも高速でさばいてくれます。
SpamAssassin自体は重いですけどね。
ちなみに、「mailbox_command」などのコマンドの実行時間を設定するには、「command_time_limit」という設定を変更します。
デフォルトは1000sなので、倍にするには、postfix/main.cfに
command_time_limit = 2000s
のように記述します。
Postfixは様々な設定があって、動作を詳細に設定できていいですね。
]]>開発者が自由に登録できるようになったそうで、さっそく「エアよみたん」も登録させていただきました。
ほかにも何か作ろうかなぁ。
まだ登録が少ないのですが、いくつか面白そうなものもありました。これから盛り上がっていくといいですね。