デザイン変えてみた
といっても目的はデザイン変更ではなくて、MT4のコメントのcaptcha機能をまともに稼動させたかったのが動機だが。
リキッドデザインにしたかったので、 小粋空間: Movable Type 4.1 テンプレートセット(スタイル対応版)を使わせていただきました。
Web屋のネタ帳Webビジネスに必要な「戦略」「システム」「デザイン」の3要素とそれらをまとめる「マネジメント」について現場の実感と独自の観点でお送りするコラム・・・のはずなんですが、要するにWebがらみのシステム&デザイン業界に関する小ネタとツッコミの雑記です。 |
といっても目的はデザイン変更ではなくて、MT4のコメントのcaptcha機能をまともに稼動させたかったのが動機だが。
リキッドデザインにしたかったので、 小粋空間: Movable Type 4.1 テンプレートセット(スタイル対応版)を使わせていただきました。
ドコモのiモードID機能のリリースはこのための布石でもあったわけで。
AdSense 日本版 公式ブログ: モバイル版コンテンツ向けAdSenseが主要3キャリア対応となりました (2008/5/1)
モバイルサイト運営者の皆様より多くのご要望をいただいておりましたモバイル コンテンツ向けAdSenseが本日より主要3キャリア対応となりました! 今までは、au、およびソフトバンクモバイルのネットワークのみに対応しておりましたが、本日よりNTTドコモ対応のサイトでもモバイル コンテンツ向けAdSenseがご利用いただけます。
see also:
自分でもいやになりそうなくらいくらいしつこく取り上げるが、ドコモのiモードメールの仕様には単純にして影響広範囲な問題がある。
で、最近こんなことがあったらしいんだが↓
iモード生みの親、ドコモを去る 慶大院教授に (Asahi.com 2008/4)
NTTドコモの携帯電話でのインターネット接続サービス「iモード」の生みの親の一人として知られる夏野剛・執行役員(43)が同社を去り、5月1日から慶応大院の政策・メディア研究科特別招聘(しょうへい)教授に就くことになった。
ぜひとも、メールアドレスの件について村井教授と対談していただきたいものだ。ここまで無視しとおした以上もうやらないだろうけど。
それから、iモードの生みの親といった単語は彼ではなくて元リクルートの松永真理氏のものだと思うのだが。
まあ、彼が苦労人であることは認めよう。そのへんはこの本を読むとわかる。
以上。最近は知らん人多いらしいのであえて古い本を紹介してみた。
日付を表現したい場合は YYYY-MM-DD たとえば
2008-05-16
時刻を表現したい場合は hh:mm:ss たとえば
11:25:30
日本時間であることをわかりやすく明記したい場合は
11:25:30+09:00
もちろんグリニッジ標準時からの時差がプラス9時間、の意。
(「JST」と書けとかUTCならZだとかそういう細かい話は省略。)
日付と時刻を両方表現したい場合は
2008-05-16T11:25:30+09:00
つまり日付と時刻をTでつなげる。
これが世界的スタンダードとしてISO8601とRFC3339に定められた日付と時刻の表現方法。 有名どころの言語やらデータベースその他ミドルウェアはすべてこれに沿った表記を解釈し入出力できるようになっている。 プログラマのみなさんは覚えておいて損はないというか絶対覚えておいたほうがいい。 できればプログラマに発注する側の人間も覚えておきましょう。
日付がスラッシュ区切り(YYYY/MM/DD)だったりするソフトやらライブラリやらが巷に散見されるが、まったくおすすめできない。実は筆者がいまそういうコードを使う羽目になっているのだが、使いづらいのなんのって。。。
日付と時刻という、どう書いてもよさそうな超基本的データフォーマットであっても、きちんとスタンダードに沿うことが、ソフトを使いやすく&使われやすくするための第一歩だ。
see also:
日付と時刻をTで結ぶ方式は普及していない[文系大学的IT系の悲哀]という記事が出ている。 経験則というものは人それぞれなのでそれはそれでかまわないが、「PostgreSQLはYYYY-MM-DDTHH:MM:SS 形式を考慮してない」といった明らかに誤った認識はpgsqlファンとしてはつっこまざるをえない。
ものはついでなので、いくつか例を挙げて説明を加えておこう。
同意である。人間の眼の観点から言うとそう。 しかしここではどっちかいうとコンピュータ視点であり、かつできればの範囲で人間にもわかりやすく、というのが主眼であることをご理解いただきたく。
それから、日付と時刻をTでつなぐということ云々よりも、 年月日は/じゃなくて-でつなぐものだ、ということを知らなかった人のほうが多いんじゃないかと思われる。
なお、「T」なんてよくわかんねーからやだ、と言っている人のブログのrssフィードには <pubdate>2008-05-16T13:45:23</pubdate>とあったりすることを忘れてはならない。あなたもお世話になっているのだ。
そうなんですよ。なんでそんなことになったのやら。忘れてたとしか思えん。
var timestamp = Date.parse('2008-05-16T11:25:30+09:00');
window.alert(new Date(timestamp));
ってやってもうまく動いてくれない。
var timestamp = Date.parse('2008/05/16 23:59:59"');
window.alert(new Date(timestamp));
ならOK。
でもそれじゃ不便だよねってことで、 [JSAN] Date.W3CDTF - ISO-8601日時フォーマット対応JavaScriptクラスなんてのを作ってる人もいる。 筆者もお世話になってる。
なお、ECMAScript(JavaScriptの仕様の土台?というべきか)の次のバージョンではiso8601形式がサポートされることになっている。
http://www.ecmascript.org/es4/spec/overview.pdf より抜粋
The Date class has been upgraded in several ways. Chiefly, there are methods for producing and consuming ISO-8601 format time strings, and Date instances keep track of their age with nanosecond precision and can be used as low-cost high-precision timers.
EcmaScriptバージョン4を搭載するブラウザが普及するのって何年後よ?とかいう野暮はいわない方向で。
とりあえずHTTP::Date使ってみた。
$ cat test.pl
#!/usr/bin/perl
use HTTP::Date;
my $t = HTTP::Date::str2time('2008-05-16T08:23:45+09:00');
print HTTP::Date::time2iso($t)."\n";
$ perl test.pl
2008-05-16 08:23:45
こんな感じ。入力は対応しているが出力の際は「T」は無いらしい。残念。
HTTP::Date - date conversion routines - search.cpan.orgを参照のこと。
$ cat test.php
<?php
echo date('c',strtotime('2008-05-13T02:45:23+09:00'));
?>
$ php test.php
2008-05-13T02:45:23+09:00
こんな感じで入力も出力も可能。なお、
PHP: strtotime - Manualには、対応しているフォーマットとしてなぜかGNU tarコマンドのマニュアルの一部にリンクが張られており、そこにはISO8601フォーマットに関する言及は無い。しかし見てのとおり動き的にはちゃんと対応している。これは「ソースは書かれているがマニュアルの更新は滞っている」というOSSにありがちなパターンの典型である。
Ms-Officeの寡占状態にあるデスクトップのビジネスアプリ市場において標準への準拠なんてされるわけがない(笑)。当然、ExcelやAccessでは2008-05-16T08:23:45+09:00なんてのは入力しても期待通りには動かない。
が、oracleやらmysqlやらpostgresqlに押されっぱなしのサーバー市場においてはMSは標準という錦の御旗に従順である。
ISO 8601 形式 - SQL Server 2005 Books Online (2007 年 9 月)
Microsoft SQL Server 2005 では、ISO 8601 形式を使用して日付と時刻のデータを指定できます。 形式は次のようになります。
yyyy-mm-ddThh:mm:ss[.mmm]
testdb=> select cast('2008-05-13T12:04:56+09:00' as timestamp with time zone);
timestamptz
------------------------
2008-05-13 12:04:56+09
(1 row)
ちゃんとTIMSETAMP型にキャストできる。
mysql> select cast('2008-02-03T04:23:45+09:00' as datetime);
+-----------------------------------------------+
| cast('2008-02-03T04:23:45+09:00' as datetime) |
+-----------------------------------------------+
| 2008-02-03 04:23:45 |
+-----------------------------------------------+
1 row in set, 1 warning (0.00 sec)
こうしてみると、YYYY-MM-DDThh:mm:ss+09:00の形式の入力には対応しているものの出力には対応していないケースが多いようだ。残念。まあ入力さえできれば出力はどうにでもなるものなのでいいのかな。
立場上、どこのサイトとは言えないので聞かないように。
要するに、こんなことが多発している(た)のだそうだ。
Hi. This is the qmail-send program at excite.co.jp.はいはい。over quota = メールボックスが容量一杯。
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<*********@excite.co.jp>:
user is over quota
簡単に言うと、上のような状況を打破するために、そのサイトではメールアドレスの入力欄に ***@excite.co.jp と打ち込むとお断りのメッセージを出すようにしてしまったそうだ。「代わりにHotmailがいいですよ」というアドバイスまでつくらしい。笑
大胆な、と思ったけど、そのサイトにおけるexciteメールの利用者数がたいした数じゃなくて売り上げ影響ほとんど無いわりに無駄なサポートコストが大きいので、そうした、とのこと。なるほど、合理的である。
そもそもなんでこんなことが起きるのか?話は簡単だ。
下記が、エキサイトメール - ヘルプ -の抜粋。40メガか、4ギガの見間違いかと思ったよ。(笑)
どんな機能があるの?
4Mの容量、POPメールの受信、SPAM防止、フィルタリングなど便利な機能をたくさんご用意しております。
ちょっとした写真つきメールをもらったり、メールマガジンを何通か受け取ったりすれば、4メガなんてすぐだ。そのとき、どうなるか?実際にexceiteメールで試してみた。
添付ファイルつきのメールを何通か送ってみたが、画面上は変化が現れない。
ただし、「メールボックスの管理」というリンクでは容量の状態が一応見れる
さらに何通か送り込んで、容量の95%を消費した状態。
これでも、通常見る受信ボックス画面では何も変化をつかめない。
容量の99%を消費した状態。もうこの状態では何を送ってもエラーで返されてしまう。
しかしそれでも、通常見る受信ボックス画面では変化をつかめるメッセージ等が何も出ない。 あまりにも不親切で、4メガの容量しか持たないWebメールとしては最低最悪なユーザビリティだ。
ちなみにHotmailやYahooメールでは、ユーザーが常に見れる位置にメールボックスの容量メーターが表示される。こんな感じ↓
90%を超えると赤くなる。わかりやすい。↓
そもそも1ギガの容量を使いきるユーザーもまれだろう。(笑)
メール、特にWebメールは、インターネットユーザーにとってごくごく基本的なインフラ的サービスだ。メールサービスを提供する側とそのユーザーという二者間に問題はとどまらない。メールをやりとりする第三者の相手がいての話だからだ。
だから、冒頭に挙げたWebサイトのような事態が発生する。 無料サービスなんだから、などという言い訳が通用するサービス領域ではないのだ。 メールというものは。
いまどきたったの4メガ。しかも容量使い切ったことにものすごく気づきにくい。 そんな中途半端な品質でしかサービス提供できないのなら、むしろ「やめちまえ」と。
基本的なサービスにおける基本的なユーザービリティの軽視が、見えないところで混乱を呼ぶだけでなく、じわりじわりとユーザーを減らしてゆく恐怖、の一例でした。
うん、うわさは本当だと思う。
「@」でエラー抑制すると PHP が遅くなるという噂について(a++ My RSS 管理人ブログ 2008/5)
でもね、よく考えよう。100万回ループさせたら9秒の差が出ました、って、、、 100万回とか1000万回ループするfor文なんてものを書くのは実際の開発現場においてよくあることなんだろうか?(いやもちろん、実験だからそういう数値を使ってることは承知のうえで)
Webシステムの画面として稼動するスクリプトにおいてそんなものすごいループをしなければならない状況になったことは少なくとも筆者はない。もしそうなったとすればそれはその前段階で何かがおかしいと思ったほうがいいんじゃなかろうか。
じゃあやっぱり百万オーダーのレベルでループしなければならない処理なんてありえないよね、というとそうでもない。典型的なのは、バッチ処理だ。全ユーザー/全データ/全ファイル/全商品の情報にアクセスしてなにか定型処理をするとか、そういうの。
でもね、そんな大量処理がたとえば10秒以内といった短い時間で終わることなんてハナから期待してない/期待されてないケースがほとんどだ。それに、大量の処理においてボトルネックになるのは、エラー出力の抑制処理なんかじゃなく、DB上でのSQLによる検索、更新処理とか、もっと単純にファイル読み書きのディスクI/Oスピードとか、そういうのだろう。
そんな状況にあって、「隊長!@マークによるエラー出力抑制を全部書き直したら30分の処理が29分50秒になりました!」なんて言われても、よくやったほめてやる!なんてことにはなりにくい。
PHPにおいて@によるエラー抑制はほどほどに、という論は、処理スピード云々の話ではなくエラー処理はどうあるべきか?の話だ。 javaでtry{}catch{}構文使ってるけどcatch{}の中身が空っぽだったりするソースコードを見かけたとき「せめてそこでエラーログを吐くくらい書かないとあとあとバグ退治しづらいぜ」という話になるのと似たような感じ。
ブログに書いてある箇条書きが額面どおりとは限らない。 日本人が日本語で書いてるブログだろうと 外人が英語で書いたブログだろうとそれは同じ。
本当に大切なことを見失わないことが肝要だ。
って言ってる筆者もたしか1回か2回くらいしか使ったことないんだが。
paypalのサイトの日本語版ができたのがたしか2007年3月ごろ。そろそろ「Paypal支払い対応」をうたったECサイトとかが増えてきてもよさそうなころあいなのだが、あんまし見かけない、、、のは気のせい?
取引手数料 - 日本海外支払い - PayPalによると、料率は以下のとおり。 楽天のR-Card Plusの料率は3.6%らしい(※1)から、遜色なさそう。
| 月間売上高 | 取引あたりの価格* |
| $0.00 USD - $3,000.00 USD | 3.9% + ¥40 JPY |
| $3,000.01 USD - $10,000.00 USD | 3.4% + ¥40 JPY |
| $10,000.01 USD - $100,000.00 USD | 3.2% + ¥40 JPY |
| > $100,000.00 USD | 2.9% + ¥40 JPY |
ドルとかユーロとか通貨変換がからむ決済はさておき、 日本円←→日本円という普通の決済になんかしらの制限てあるんだろうか? 日本だと銀行法に触れるの触れないのという話は聞いたことがあるようなないような。
アメリカンな小切手文化、カード文化が日本人に合うとか合わないとかいう話はいまさらどうでもいい。
単なる知名度の問題なの?
※1:楽天の出店案内のページのどこをさがしてもクレジットカード決済の料率について記述が無い理由はまあアレだ。(笑)
1年後あたりに、どうだったのか経過を聞いてみたい。
住友電気工業株式会社|プレスリリース 2008年 社内オフィスソフトに「OpenOffice」を全社レベルで活用
see also:
よく「環境テロリスト」と表現されているのを見かけるが、 「ポアするしかないな」とつぶやいたどっかのカルト宗教と似たようなレベルの思考能力なわけで、 つまり彼らは環境カルトと表現されるのもまた適切かと。
ちょっと前に学校裏サイトで娘が実名で攻撃され、父としてメールを送ってみた : ITmedia オルタナティブ・ブログっていうブログが話題になっていてふーんと思っていたらそれについて学校裏サイトのいじめ解決が実はマッチョの成功体験だったという話 - E.L.H. Electric Lover Hinagikuっていう話もでていてまあそういう見方もあるよね程度に読み流していたらそのマッチョと飲みませんか? 割り勘で。 - E.L.H. Electric Lover Hinagikuっていう話になっているらしくてへーと思っていたらその会場としてFANTASY DINING 迷宮の国のアリスをチョイスしたのが件のお父さんらしくてなんか知らんけど「俺も行きます」ってメール書きそうな自分がいま少々酔ってることに気づいてそもそも当日俺たぶん仕事だろからもう寝る。