2004年12月28日
仕事柄年末だから忙しいということはあまりないのですが、年始に始まるキャンペーン用プログラム作成を今になって依頼されたりとか、blogを書いている時間がない（って書いてるけど）くらい時間に追われてます。でもいつもマイペースなワタクシ。
今日は岡崎律子さんの『for RITZ』を買って帰ろうと思っていたけど、店が開いている時間に帰れるかどうか。。。こんな状態でも今日が仕事納めです。^^;
(22:08追記)
結局、まだ職場にいます。
そんなこともあろうかと、お昼休みにビックカメラまでダッシュして『for RITZ』を買っておきました。
あとは1/3にサーバーが落ちないことを祈るのみです^^; 最悪3日に出社。
投稿者 Utayume : 13:09 | トラックバック (0) | 05 Work(Perl, PHP, etc) /Misc
2004年12月11日
仕事で作っているサイトでWebからの申し込みをできるようにしました。本当は先月初めには公開可能だったものの、周りの体制が整わず1ヶ月も遅れてしまいましたが、トップページの更新情報にも出さずに密かに始めたにも関わらず、本日5件のお申し込みがあり、安いところばかりですが6万円ほどの売り上げ。
データを表示するだけなら気楽にできるんですが、こういう個人情報を扱うプログラムだと、やはりかなり気を遣います。
カード決済ではないのでまだマシ（この会社では店頭でもカードが使えない）とはいえ、数ヶ月以内にはカード決済までやろうと思っているので、また胃が痛くなりそうです。^^;
その前に、年内にもうひとつプログラムを作って公開予定。う〜。
とりあえず現在バンコク、ソウル、台北、上海が申し込み可能です。よろしければどうぞ。。。って、どこかわかりませんね。探してみてくださいな。
まぁ、Webからの申し込みが多くてもわたしの給料は上がりませんけどね。逆に何か重大な問題が起こったら、確実に首になります。因果な商売だわ。(泣)
投稿者 Utayume : 23:40 | トラックバック (0) | 05 Work(Perl, PHP, etc)
2004年12月07日
FirefoxベースのNetscape Browserをダウンロードできたので、ちょっと使ってみました。
AOLは現在IEベースのブラウザを開発中で、自社ブランドであるNetscapeとの折衷案？とも言えるブラウザです。えむもじらさんのところでも解説されていますが、そんな背景から、このブラウザ独自の機能として、NetscapeのレンダリングとIEのレンダリングを切り替えて使うことができます。
Operaも似たような機能がありますが、OperaはレンダリングはあくまでOperaで、UserAgentを他のブラウザへ切り替えるだけなのに対し、今回の新Netscapeではレンダリングエンジンそのものが切り替わるので、IEを選べばWindowsが標準で持つIEのフロントエンドとして動作します。（。。。と推測します）
UserAgentは以下のように切り替わります。
【Netscapeモード】
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20041122 Firefox/0.5.6+
【IEモード】
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)
必要悪としてこのような機能を搭載することは「アリ」だと思います。
が、これって技術的な問題からWindows版でしか搭載されないような気もします。
Firefox 1.0では正式採用が見送られたタブブラウズ拡張も搭載されて、タブの動作を細かく指定できるようになっています。
しばらく使ってみた感想としては、さすがにFirefoxベースだけに、アプリ起動も表示もかなり高速になったと思います。
メインのブラウザとして使っても満足のいくレベルです。
ただ、デザイン的な問題として、多少操作しにくい部分もありましたので改良を希望します。ちなみに、個人的には、この全体的にコテコテなデザインは好きではありません。（えむもじらさんによると、デザインはよりシンプルに変更されるようです）
また、RSSリーダーの機能は搭載されておらず、Firefoxでは非常に便利に感じているので、この点はかなり残念です。
拡張機能については試していません。
投稿者 Utayume : 12:02 | トラックバック (0) | 03 Computer /05 Work(Perl, PHP, etc)
2004年11月16日
某ECサイトで使う予定のプログラムで受け付け番号みたいなものを発行したいと思ったので、その備忘録。
例えば、RDBMS側の自動番号振り付け（MySQLの場合AUTO_INCREMENT）で受付番号を付加して新規レコードを書き込んだ後に、今書き込んだレコードを読み込めばいいわけです。
1.AがDBに書き込み
2.Aが一番最近のレコードを読み込み
しかし、もし上記2の読み込み前に他の書き込みがあった場合には違うデータを読み込んでしまうおそれがあります。
1.AがDBに書き込み
2.BがDBに書き込み
3.Aが一番最近のレコードを読み込み（←Bのレコードを読み込んでしまう）
4.Bが一番最近のレコードを読み込み
このような場合、多くのRDBMSでは、トランザクションという機能を使うと、複数の処理（SQL）を排他的にひとつのまとまりとして実行することができるので、書き込みの競合を防ぎ、データの整合性を保つことができます。
MySQLでもトランザクションはできるのですが、テーブルタイプ（フォーマットみたいなもの）をInnoDBにする必要があります。デフォルトのテーブルタイプは（おそらく）MyISAMです。MyISAMはフィールドにどんなデータが入るかあまり考えなくても気軽に使えるのですが、InnoDBの場合はデータ領域をどのように設計するかを予め考えなくてはいけません。
それもまためんどくさいので、MyISAMのままで手頃にできないのかな？と調べたら、MySQLでは、トランザクションとは別にLOCK TABLESという命令があり、これはMyISAMでも使えることがわかりました。
1.LOCK TABLES…
2.INSERT INTO…
3.SELECT…
（4.UNLOCK TABLES…）省略可
というようにすればいいわけです。
複雑な処理でもなくロック中は大した時間でもないので、トランザクションを使わずにも、これで十分かな。
もしこれに問題がありましたら教えてください。＞MySQLのえらいひと
投稿者 Utayume : 15:12 | トラックバック (0) | 05 Work(Perl, PHP, etc)
2004年11月02日
PHPでセッションを利用すると、デフォルトの設定では、ブラウザのキャッシュが無効になります。
どういうことかというと、例えば、「入力フォーム→確認→送信」という流れのプログラムがあり、データの受け渡しにセッションを使うためにそれぞれのページで
<?php
session_start();
?>
という記述をすると、「確認」の後にブラウザの[戻る]ボタンで戻ろうとしても、「有効期限切れ」が出て「入力フォーム」を表示できなくなります。
これを回避するためには以下のように記述します。
<?php
session_cache_limiter('private_no_expire');
session_start();
?>
php.iniの記述を変更しても同様です。
参考：PHPマニュアル セッション処理関数(session)
ただし、なぜデフォルトでsession_cache_limiterが'nocache'となっているかを考えると、セッションで受け渡すようなデータ（極端な例ではクレジットカード番号とか）がやたらとキャッシュされるとセキュリティ面で問題となるからであり、もし'private_no_expire'や'private'として使うのなら、そのあたりの配慮も必要かと思います。
それと、最近気が付いたことですが、php.iniのsession.gc_maxlifetimeはデフォルトでは「1440」になっています。
session.gc_maxlifetimeは、簡単に言うと、セッションの有効期限（そのセッションが最後に利用されてからの秒数）であり、その値が1440秒、つまり24分なのですね。
ほとんどは問題ないとは思いますが、例えば、入力フォームなんかで、仕事しながら入力して、しばらくしてまた書き始めるみたいな場合は、セッションの期限切れになって送信できなくなる、ということもあり得るのです。
このあたりの対策もしておく必要があります。
いえ、最近わたしの作ったPHPプログラムで実際に体験したので。
投稿者 Utayume : 18:51 | トラックバック (0) | 05 Work(Perl, PHP, etc)
2004年10月21日
ITとは何の関係もないわたしの職場（旅行会社）の朝礼で、えらい人がblogについて語ったらしいです。
わたしは朝礼には出ないのでその話を直接聞いたわけではありませんが、また聞きしたところによると、以下のような内容らしいです。
オンラインブッキング等でのWebの有用性
↓
料金等が時間単位で変更になるので、HTML手書きではついていけない
↓
blogを使えばいい
この方のblogへの理解度は定かではありませんが、話を聞くと、どうも、blogというものを「HTMLを自動作成するツール」としか認識していないようです。それだけならば今までだってPerlやPHPでオリジナルなものを作れるわけで、ここまでblogが流行している理由にはならないわけです。
じゃ、なぜこんなに流行っているのか、わたしなりに考えてみると、今までのサイトとの大きな違いは、横の繋がりが簡単に取れる、それによりblog全体が大きなコミュニティとなり、一つの話題がさらに広がっていくということだと思うんです。
機能としては、トラックバックであり、コメントであり、エントリーのしやすさ、ですね。
このあたりの認識がないとビジネスとしてのblogの方向性も間違ったものになると思いますし、成功することはないです。
blogでの商用利用というのは以前からわたしも考えていますが、「RSS」や「積極的なCSSの利用」はすぐに実践できるものの、blogそのものの利用価値は、可能性はものすごく感じるものの、具体案を出せないでいます。
この朝礼があった後、4人の人から「うた夢さん（仮名）の作っているサイトってblogですか？」って訊かれました。
もうそれって、3年前にPerl CGI、今年からphp＆MySQLのシステムを一から作ったわたしにも、blog界（？）にも失礼です。
blogというものがIT業界やサイト作成者以外にも認識されつつあるのはうれしい限りですが間違った認識はいけません。
勉強しろ！
ということを、職場から書き込んでみたり^^;
投稿者 Utayume : 20:01 | トラックバック (0) | 04 Blog /05 Work(Perl, PHP, etc)
2004年09月21日
わたしが仕事で作っているサイトで以前から懸案であったのが、各ホテルの地図を表示すること。
一つ一つIllustratorで手作業で作っていく（現在はメジャーなところだけこの方法）のが手っ取り早いかもしれないけど、1万件もあり、道路等の名称変更も頻繁にあるので、手作業で作っていくのは事実上不可能。
で、数ヶ月前に某地図会社に見積もりを出したところ、システム構築費用で650万円だそうで、維持費で月40万円だと。
わたしがお金を出すわけではないのでそれでもいいんじゃない、と外注するつもりでしたが、さっき日経Linuxを立ち読みしていたら、オープンソースのMapServerなるシステムがあるらしいじゃないですか。
（上記リンク先は有料の日本語対応版、本家はここ。MapServer自体は基本機能のfree版と高機能の有料版があります）
これならわたしにもできるじゃないですか。わたしがシステム構築＆メンテすればわたしの人件費だけで済みます。
400万円で請け負います！(爆)
実際は他にも仕事があるのでわたしが作るのは無理なんですけどね。あ〜あ。
投稿者 Utayume : 17:37 | コメント (2) | トラックバック (0) | 05 Work(Perl, PHP, etc)
2004年08月26日
今抱えている仕事。
・某所の口コミ情報プログラム（今月中）
・某所のWeb予約システム（「クリスマスには間に合わせたい」（プププッ）。。。TT）
・某サイトのBlog化（1ヶ月以内には）
・某会の会報制作（1ヶ月以内には）
むぅー。
あまり煮詰まると、全部投げ出してしまう可能性あり。^^;
投稿者 Utayume : 14:19 | コメント (2) | トラックバック (0) | 05 Work(Perl, PHP, etc)
2004年08月17日
ITmediaニュース：大手サイトを横断してホテル料金を比較する「モノリス」
わたしの仕事とも多少かぶる、気になるニュースです。
モノリスは、複数の国内宿泊予約サイトのデータを自動収集し、宿泊料金を比較できるサイト「モノリス」を8月17日にオープンする。
Google等のサイト検索エンジンと同じようにクロウラーで各サイトの料金を取得して自社でDB化しているそうです。
実際の予約はそれぞれの宿泊予約サイトで行うので、事実上広告のようになり、宿泊予約サイト側からのクレームも出ないと思うし、いずれは掲載ホテルからの広告収入も期待できる。
技術的には今までの検索エンジン技術の流用なので開発資金もそれほどいらない。
わたしとしては、「やられたー」って気分。
ただ、実際に検索してみたら、現状では遅くて使い物になりません。検索ボタンを押して結果が表示されるまで1分以上かかって、次のページを見る気をなくします。
初日だから多少重くなるというのを差し引いてもサーバー環境に問題あると思われ。
投稿者 Utayume : 12:42 | トラックバック (0) | 05 Work(Perl, PHP, etc)
2004年07月19日
以前のエントリーでGDを使ったサムネイル画像の作成方法を書きました。これを書いたときは使用サーバーでGD2.0が使えなかったので検証できませんでしたが、いつのまにか使えるようになっていたので画質の比較をしてみます。
厳密には、PHPプログラムの上で、GD2.0の環境でしか使えない関数（imagecreatetruecolor、imagecopyresampled）と、GD1.xがあれば使える関数（imagecreate、imagecopyresized）の画質比較ですね。
大きい画像がオリジナル画像で、小さい画像の左がGD1.6、右がGD2.0を使用して作成したサムネイルです。
phpinfoでのバージョン表示では
・1.6.2 or higher
・bundled (2.0.15 compatible)
ソースは
GD1.6
$img = imagecreate(60,60);
$imagefrom = imagecreatefromjpeg($file1);
imagecopyresized($img,$imagefrom,0,0,$resize_x,$resize_y,$resize_w,$resize_h,$imagesize[0],$imagesize[1]);
GD2.0
$img = imagecreatetruecolor(60,60);
$imagefrom = imagecreatefromjpeg($file1);
imagecopyresampled($img,$imagefrom,0,0,$resize_x,$resize_y,$resize_w,$resize_h,$imagesize[0],$imagesize[1]);
このように、imagecreatetruecolorとimagecopyresampledの二つの関数を使うかどうかの違いです。
で、画像を見てみるとGD1.6の方は、画像によってはなんだかわからないぐらい潰れてしまい、対してGD2.0ではちょっとぼやけたような印象にはなりますが、全体像はわかりやすくなったようです。
関数の使い方でもう少し綺麗にできるような気もします。
まぁ、この程度の画像ならどっちでもいいっちゃいいんですが。^^;
ただ、画質の問題よりも、GD1.6の頃のコードでは元画像によってはサムネイルの作成に失敗（色が抜ける）することがあったのに、新しいコードにしてからはそのようなことがなくなったので、変更して良かったと思っています。
投稿者 Utayume : 23:21 | トラックバック (0) | 05 Work(Perl, PHP, etc)