ただつらつらと日記が書かれていくようです。

カテゴリー: ITめいたこと (26ページ目 (31ページ中))

どうやらGoogle MapsをAPI経由で呼び出せなくなってるようで…。

GoogleMapのサイトは問題なく地図が表示されているようだけど、API経由で地図を表示してるサイト(tabelogとか)は軒並み地図が灰色になってしまっているようだ。それは、Google Maps APIsのGoogle Codeのサイトも例外ではないみたいだ(スクリーンショット中のサンプルの地図も灰色になってる。)

20091117175849

あー、早く直らないかなぁ…。

追記:

Google Maps APIのフォーラムを眺めていると、Google社員のPamelaさんがこんなことを書き込んでいた。

We are releasing the fix now, and expect the fix to be rolled out everywhere within the next half hour.

このポストが19時3分頃だから、もうすぐ直りそうだ。

Google Maps Hacks 第2版 ―地図検索サービスをもっと活用するテクニック
Rich Gibson Schuyler Erle
オライリー・ジャパン
売り上げランキング: 36224
おすすめ度の平均: 4.0

4 地図サービスを抑えておきたい人必携です。

*1:スクリーンショット中のサンプルの地図も灰色になってる。

Google Analyticsをケータイのアクセスカウントに使ったけどセッションが…。

Googleから、GoogleAnalyticsをケータイのアプリケーションへのアクセスカウントに使う方法とサンプルスクリプトが公開されて久しい。これまで、やや無理のある方法を使ってGoogleAnalyticsでケータイのアクセスをカウントしてた関係で、ちょっと試用しており、PVなどの数字自体はとりあえず出ているものの、どうも数字が妙なところがちらほら…。

例えば、というか、とにかく、auのケータイにおいてセッションを把握できていない。つまり、1PV=1セッションとして数えられている。そのおかげで、全セッションに対するauケータイのシェアがやたらと大きくなるし、平均PVとか直帰率とか他の数字も巻き込んでおかしくなってしまっているようだ。あー、どうしたことでしょう。

まぁ、画面の解像度とかFlashのサポート状況などは、結局、GoogleAnalytics側で端末に関するデータを持っていないと取れないんじゃないか(例えば、機種名から解像度の情報を探してくるみたいな)と思われるし、そんなに重要なパラメータでもない気がするので、とりあえず置いておいてもいいかという気がする。あと、ページタイトルもNotSetになってるけど、これもPC版がJavaScriptで取ってる項目だろうし、取れなくてもしゃーないか。

…で。

Google先生に聞いてみたところ、同じようなことで困ってらっしゃって、かつ、Google提供のソースへのパッチを載せられているBlogのエントリーを発見→no title

パッチの内容を拝見すると、Cookieがうまく取れていないってことで、キャリア毎の個体識別番号を元にセッションを認識してもらいましょうという方針らしい。あー、なるほど、確かにこれで対応できそうだー。感謝。

auセッション問題は何とかなりそうだけど、試しに作ってみたプロファイルには、Google提供のサンプルコードで動いてるケータイのアクセスカウントしか来ないにも関わらず、ユーザの「OS」の項目が、「not set」になっていたりするセッションが多少あるのはどうしたことでしょう。うーむ。で、「not set」以外の「OS」としては、「EZweb Device」と「NTT DoCoMo」と「J-Phone」があるんだけど、最後の「J-Phone」の数が少ないので、この「not set」ってSoftbankっぽいなぁと思ったりするんだけど…(汗)あー(遠い目)

集客力を飛躍的に向上させるGoogleAnalyticsアクセス解析の極意
石井 研二
秀和システム
売り上げランキング: 3365
おすすめ度の平均: 3.5

1 関数の記述に注意が必要
5 値段以上の価値ありまくり
5 暴露しすぎでは・・・

お得なSSLサーバ証明書に関するメモ…の補足。

昨日、「お得なSSLサーバ証明書に関するメモ。 – お仕事日記。」ってエントリーを書いたけれど、結論としては、値段も高いけど、ケータイサポート率も高いVerisignもいいけれど、GeoTrustのSSL証明書って値段の割にケータイのサポートもそこそこでいいんじゃないだろうか的な結論になってた…つもりだ。

で、今日、たまたま、PHPで有名なアシアルがSSL証明書を扱っているのを見つけた。で、デモページがあったのでブラウザでアクセスして、証明書を眺めてみたが、そのルートCAがGeoTrustと同じ「Equifax Secure CA」であることがわかった。

てか、ApacheとかIISへの導入方法のインストラクションは、GeoTrustのサイトへのリンクじゃないですか…ってことで、日本ジオトラストとアシアルが売ってるSSL証明書は、結局、同じモノではないかと思う。で、アシアルから買った場合は、12,800円/年。うーむ、これは安い(汗)

しかし、アシアルのサイトを眺めてみたけれど、サイトシールに関する言及がさっぱりないことに気がついた。もしかして、サイトシールが提供されない(…もしかして、ケータイ向けのSSL証明書ってことなら、PCのブラウザで表示するサイトシールを提供してなくても仕方ないってなるんだろうか…)から、この安さってことなんだろうか(汗)まさかねぇ…。

まぁ、安さを追求するなら、GoDaddyとかRapidSSLに買いに行けば、3000円くらい/年でSSL証明書を入手することもできるわけで、ま、ちょっといろいろと微妙な世界ではあるんだけどなぁ。

お得なSSLサーバ証明書に関するメモ。

最近、SSLサーバ証明書を更新する必要があって、いろいろと調べ回ってみた。まぁ、そもそもSSL証明書なるものの価値というのは、どれくらい多くのブラウザやケータイが、そのSSL証明書のルートCAの証明書を持っているかという辺りで決まってそうだというのが、調べてみての感想。とはいえ、SSL証明書の商売って、結構、儲かってそうな印象(汗)も受けた。

例えば、PCのブラウザだけをターゲットとしてSSLを使うのであれば、とりあえず、GoDaddyのサイトでも行って買ってくるのが一番安いのではないかと思う。アメリカのGoDaddyとお取引する関係で、実際にやったことないけれど、決済周りとかいろいろとややこしいことになりそう。とはいえ、実在性証明などが伴わない、一番安いSSL証明書で\2,700/年くらいだった。(どういうわけかGoDaddyのサイトでは、日本円の価格を表示することができる)この辺の値段を知ってしまうと、日本国内で買うことができるSSLサーバ証明書のお値段は激しく高いことになる。

日本国内でもGoDaddy級のお値段を設定しているSSLサーバ証明書屋さんもあるが、その辺を除けば、普通のSSL証明書は、だいたい2.5万円~8万円くらいが相場ではないかと思う。GoDaddy系のルートCAのSSLサーバ証明書が発行される「JCert」のSSLサーバ証明書は結構安かった(1FQDNのドメイン認証なSSLサーバ証明書で¥26,250)

ま、EV証明書となるともっと高くなるが、SSLを使って通信内容を暗号化したいと思うクライアントがブラウザのアドレスバー辺りが緑色になってうれしくなるという要件でもない限り、、、特段、必要ないのかもなぁと遠い目をしてしまった。普通のSSL証明書でも、サーバとクライアント間の通信は暗号化されるわけだし、実際にアドレスバーが緑になるメリット感はあるのだろうか。うーむ、わからん。

一方、GMOが売っている「GlobalSign」のSSLサーバ証明書とかだと、ケータイ対応に若干の難しさがあるような気がした(ちなみに、私が使ってるケータイのN904iは未対応だったし…汗)が、ケータイを使わないのであればアリだろうなぁ。ケータイ端末を100%近い割合でカバーしたいならVerisignのSSLサーバ証明書を買うことになりそうだけど、結構いいお値段である。

なんだかんだ調べてみて、2006年からVerisignグループ入りした「GeoTrust」のSSLサーバ証明書がなんとなくお買い得な印象を受けた。ケータイ端末のカバー率に関して「92.8%の携帯電話で利用可能」って書いてある割には、標準価格が36,540円で、キャンペーン価格で22,050円。ほどよく安い気がする。まぁ、ケータイのカバー率が100%に近い「Verisign」か、ほどよい値段の割には結構ケータイをカバーしている「GeoTrust」で我慢するのかはなかなか難しい選択肢だ。

あと、インテックが扱っている「EINS/PKI+」ってサービスでは、ルートCAがRSAになっているSSLサーバ証明書を買うことができそうだ。値段が通常料金で5万円/年だから安いサービスではないけれど、ケータイには割とRSAのルートCAの証明書が入っているので、ケータイをターゲットとするWebサイトでSSLを使いたい場合には選択肢になりうるのかもしれない。

非定型業務の可視化って…。

InterstageのBPMエンジンの新しいのが出たらしい。

富士通、「Interstage BPM」新版-現場の“非定型作業”も可視化:

http://enterprise.watch.impress.co.jp/docs/news/20091109_327677.html

業務プロセスには、あらかじめ定義可能な「定型業務」と緊急発生する予測不可能な「非定型業務」の2種類が存在する。従来のBPMは、このうち定型業務をあらかじめモデリングして定義しておくことで、可視化を行うものだ。そのため、予測不可能な非定型業務の可視化は不得意といえた。

 例えば、「注文数や納期の変更」「発注元により異なる製造工程」「取引先ごとに異なる修正指示」などの非定型業務は、「業務プロセス全体の80%を占めるとも言われ、メールや電話で都度確認して作業状況を把握するしかなかった。そこで従来の定型業務に加え、非定型業務をいかに可視化するかが課題となっていた」(矢作氏)のだという。

以前、BPMエンジンが動作するミドルウェアを扱っていたせいか、やっぱり、非定型業務っていうのは非定型業務としてビジネスプロセスを遷移させるしかないんじゃないかと思われ。やっぱり、例外処理は例外処理なわけで。

ま、確かに、非定型業務の可視化は課題だとは思うけれど、もし、どういうことが起こるか予想しうるのであれば、それはやっぱり定型業務として、ひとつのビジネスプロセスとして定義しうるんじゃないかと思うけどなぁ(汗)うーむ、なんつーか、仮に、非定型業務が業務プロセス全体の80%を超えてたら、BPMエンジンを導入している意味が消失してるような気もするわけだし、BPMエンジン導入前のBPRとか大丈夫かという世界なのかもしれず。あー。

ムームードメインでドメインを更新したら、お名前.comにトランスファー

ムームードメインで管理している.netドメインがあって、そろそろ更新の季節だというメールが届いた。そうですかということで、素直に更新しようとしたら、コントロールパネルの画面にこんな文章が出てきて、手が止まった。

ドメインの更新に伴い、更新時に『お名前.com』へのトランスファー(移管)処理が行われます。トランスファー申請中は、ドメインの操作が行えません ので、予めご了承下さい。

* レジストラが変更になりましても、お客様側での設定やドメイン料金は変更されませんのでご安心ください。

* 入金確認後、トランスファーが完了するまで10日程度 かかる場合がございます。

* トランスファー更新にともなって、承認のため、「トランスファー承認手続きのお願い○○」及び 「Domain Transfer Request for ○○」という件名のメールが送信される場合がございますが、 こちらに対する手続きは一切必要ございません。

* トランスファー更新の後、60日間は他のレジストラへの移管を行うことが出来ない場合がございます。

* 移管状況の詳しい内容はドメイン詳細でご確認できます。

いきなり、お名前.comにトランスファーしますと言われても、意味がわからないんですけど…と思い、ヘルプページやサポートフォーラムを覗いてもさっぱりその辺への言及がなかった。こういうのって、なんか気持ち悪い気がする。で、ちょっと調べてみて、なんとなくわかったのでメモ。

ICANNのサイトを見ると、ムームードメインはICANN認定のレジストラではないから、ムームードメインがgTLDドメインを扱うためには、上位レジストラとしてICANN認定のレジストラが必要になる…と。

で、確か、ムームードメインは、eNomが上位レジストラだったんだけど、しばらく前にpaperboy&co.がGMOの連結子会社になった関係で、ムームードメインの上位レジストラをeNomからお名前.comに変えるというのがGMOグループ内の決定となったといったところだろうか。まぁ、上位レジストラがどうなっていようが、ドメインを使う分には問題ない…はず(レジストラのサービスの質を担保するためのICANN認定なんだろうし)だから、とりあえず、同意することにした。

初心者向けサービスを標榜する割には、しれっと「お名前.comにトランスファーします」なんて意味不明なことを言い始めるもんなぁ…って、どうなんでしょう。

さくらインターネットのレン鯖のMLのreply-to関係の設定をいじってみた。

さくらインターネットのレンタルサーバでは、fmlによるメーリングリスト機能を利用できる。サーバのコントロールパネルから送信先のアドレスを編集できたり、設定を変更できたりする…が、使っていて、ちょっと不便なことがあった。それは、メールヘッダの「reply-to」に関する設定をコントロールパネルから変更できないことだ。

ちなみに、デフォルト設定では、メーリングリストを介して配信されるメールの「reply-to」は、メーリングリストのアドレスになっている。つまり、メーリングリストを介したメールに対して返信すると、メーラーが「to」に指定するのはメーリングリストのアドレスになる。

そもそもメーリングリストとは何かを考えれば、そういう仕様でしかたないのかもしれないなぁとは思うが、ただ、単に「1個のメールアドレスで受けたメールを複数のアドレスにコピーして送るもの」としてメーリングリストを使いたいこともある。

そんな用途の場合は、fmlに任せるようなことではないのかもしれない…が、さくらインターネットのレンタルサーバ(少なくともビジネス向けのサービスの方は)のコントロールパネルでは、転送メールを利用するときに、転送先アドレスの指定がCSVでアドレス指定なので複数のアドレスを設定するときにかなり使いづらいという事情がある。…なので、仕方なくfmlにただメールを転送させることにした。

実際に会社の代表アドレスに、メーリングリストを使ってみると、さくらのレンタルサーバ上のfmlを介して届く関係で、reply-toがメーリングリストのアドレスになっている。なので、お問い合わせメールが届いて、それに普通に返信すると、問い合わせてきた人には届かなくて、社内だけに届いてしまう羽目になる。

そんなわけで、もし可能なら、メーリングリストでreply-toの付与を抑止できたらいいなぁと思ったけれど、その辺の設定項目がコントロールパネルになくて困った。さくらのレンタルサーバでは、SSHでログインすることが出来るので、fmlの設定をいじくってみることにした。

fmlのドキュメントなどを読んでみたら、「reply-to」の付与を抑止するには、設定ファイルに

&DEFINE_FIELD_FORCED

って書いてあるのを消せって書いてあったけど、そんなこと書いてなくて…どうしたものかと。なんとなく見てる設定ファイルを間違えているような気がしないでもないけど、なんとなく面倒な気がしたので、とりあえず、fmlが自動的にMLのアドレスを入れたreply-toを付与する前に、reply-toを書いてしまえばいいんじゃないかという…ちょっと邪道っぽい解決策を思いついた。

…というわけで、こんなのを設定ファイルに書き込んでみた。要するに、START_HOOKを利用して、reply-toにアドレスを指定してあるメールがMLに送られたら、改めて、そのメールアドレスをreply-toに入れてメールを配信するし、reply-toを指定していないメールに関しては、メールヘッダーのfromに書いてあるアドレスをreply-toに強引に(汗)入れて配信する…と。

$START_HOOK =q#

if (&GET_HEADER_FIELD_VALUE(‘reply-to’)) {

&DEFINE_FIELD_FORCED(“reply-to”, &GET_HEADER_FIELD_VALUE(‘reply-to’));

}

else {

&DEFINE_FIELD_FORCED(“reply-to”, $From_address);

}

#;

とりあえず、かなり強引なやり方ではあるけれど、reply-toでややこしくなる事態は回避できたような気がする。まぁ、思いつき型の解決策にありがちな、なにかのレアケースでややこしいことになりそうな気もしないけど、、、しばらく様子を見てみようかと。

MS製Firefoxプラグインがお粗末な件。

Firefoxを使ってたら、いきなりプラグインのいくつかを無効化するダイアログが開いたと思ったら、.NET向けのプラグインが無効化された。まぁ、一回も使った記憶がないからいいか…みたいな。

その背景には、こんなのがあったらしい。要らないプラグインを強制インストールするなよなぁ…ほんと(汗)

テクノラティジャパンがサービス終了とな。

Blog検索サービスの「テクノラティ」@日本がサービス終了するらしい。1週間前くらいにもう一個のBlogを登録しようとしたら、よくわからんエラー(OpenID経由で登録しようとしたんだけど、本来であれば、登録完了って出るはずのところで登録開始の画面に遷移してた)が発生して登録できなかった背景にはサービス停止があったようだ。

まぁ、思い出してみれば、Tecnorati以降、Googleブログ検索をはじめBlogを検索できるサービスが登場して、一瞬、賑わいを見せたけれど、結局、効率的なマネタイズがうまくいかなかったのだろう。例えば、Ask.jpのように脱落したサービスもあったが、Technoratiも例外ではなかったようだ。細かく見れば、アメリカのTechnoratiはサービスリニューアルを行ったタイミングだが、日本のTechnoratiが追随せずに、サービス終了したって感じだろうか。

blog検索が登場した黎明期には、Web検索とは別のものとしてBlog検索が成立していたことになる。でも、その背景にあったBlog検索とWeb検索を分けていた要素、いい変えれば、Blog検索にしかできなかったことは、Blogにポストされたエントリーを早く検索可能になることくらいしかなかったんだろうと思う。

結果的に、Googleあたりがインデックス更新の頻度を上げて、Web検索にBlogも取り込んで、新しい情報を検索結果に引っ張り出せる仕組みを入れた時点で、Blog検索の独立系サイトはPVを集められない運命にあったのかもなぁと思うと、あらためてGoogleあたりの脅威ってのはいろんなところに潜んでいそうだ。

«過去の 投稿 新しい 投稿 »