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

投稿者: 管理人 (31ページ目 (40ページ中))

全文検索エンジンのTritonnとかLuceneとか。

最近、全文検索エンジンがあった方がいいような気がして、SennaをMySQLに組み込んだTritonnを、いじくってみた。

ちょっと使った感じでは、とにかく、インデックスを作る時間がかなり必要になりそう。で、そのインデックスを作っている間、ディスクアクセスがごりごり走る関係で、マシンが重ーくなるわけで、それって本番環境でインデックスを作ったりしたら、どうなるんだろうと思う。(ま、普通に考えれば、レスポンスタイムが悪化しますわな)

ま、それを回避するために、他のマシンで全文検索エンジン用のインデックスファイルを作って、そのファイルをTritonnが動くサーバにアップロードするって技もあるにはあるんだろうけれど、インデックスファイルをアップロードする前にMySQL(Tritonn)はやっぱり落としておきたいような気がする(うっかり、アップロード中のインデックスファイルを見ちゃったMySQLはどうなるんだろう…とか思うと)ので、そうなると、例えば、2インスタンス立てて、1つでインデックス切り替えやりつつ、もう1つのインスタンスで運用して、終わったら切り替えるみたいな運用が考えられるけれど、MySQLを2インスタンスってのがこれまた面倒な気がする。こういう運用なら、サーバ2台立てて、ロードバランシングする運用になるんだろうか。

…うーむ。

ふと、Apache Jakartaプロジェクトに全文検索エンジン「Lucene」ってのがあることがわかったので、Luceneを試用してみることにしよう。別に、全文検索エンジンと新アプリケーションの間は、SQLでインターフェイスしなきゃいけないアーキテクチャでもなさそうだし(加えて、Luceneは上司が嫌いなJavaだけど)アプリケーション間のインターフェイスをHTTP+JSONにでもしておけば、問題もないだろうし。

全文検索エンジンには、インデックス作成(の時間と負荷)と、インデックス入れ替えの問題(ま、止めてもいんだろうけど)はやっぱり付いて回りそうだなぁ。この辺がシームレスにできればいいんだけども。

追記:

そういえば、Hadoopを使ってLuceneのインデックス作成を分散処理することができれば、なかなか愉快なことになると思うけど、どうなんだろうか。調べてみよう。

「実践ハイパフォーマンスMySQL」の第2版が出たらしい。

近々、買おうと思っていたら、第2版がでたらしいではないか。どうやら、前版では、MySQL4+MyISAMを前提にしていたけれど、第2版では、MySQL5+InnoDBを前提にした内容に書き換えられているらしい。まぁ、WebアプリだとMyISAMも登場する機会は少なくなさそうだけど、値段が値段だけど、買っといて損はないか…。

実践ハイパフォーマンスMySQL 第2版
Baron Schwartz Peter Zaitsev Vadim Tkachenko Jeremy D. Zawodny Arjen Lentz Derek J. Balling
オライリージャパン
売り上げランキング: 11142

さくらインターネットのレンタルサーバへの不満。~DNS編~

最近、仕事でさくらインターネットのレンタルサーバのビジネスプロを使っている。

で、このサービスを検討している時には、このサービスはビジネス仕様をウリにしてるので、属性型JPドメイン(ま、co.jpドメインですな)をさくらインターネットに管理してもらって、さくらインターネットのビジネスプロを使おうと思っていたが、ちょっとイヤな予感がして問い合わせてみて、どうもそういう使い方ができないことがわかった(汗)

というのも、さくらインターネットで属性型JPドメインを預かってくれるのは確かなんだけど、ゾーンファイルの編集が不可という残念な仕様。結局は、さくらインターネットが決めている、いくつかのAレコード(wwwとかftpとかmailとか)とMXレコードがゾーンファイルに書かれて、それでなんとか使えというサービス仕様だった。例えば、社外向けにblogサーバでも立てようとして、blog.xxxxxxxxx.co.jpとか使おうとすると、それはできませんということだ。で、どうにかならないかとサポートに聞いてみたら、他社のDNSサーバを使って、そこのゾーンファイルにさくらインターネットのサーバのIPアドレスを書く使い方を提案されてしまう始末。あぁ、無理なのね(涙)

まぁ、さくらインターネットのDNSサービスでは、ゾーンファイルの編集とか一切できませんというのなら、納得もできるし、そもそも期待もしないんだけど、属性型JPドメインはゾーン編集不可で、gTLDドメインとか(汎用JPドメインは可だったかも)はゾーンファイル編集し放題だから、なんとなく、なんとかならないものかなぁと思ってしまう。

加えて、さくらインターネットは、ユーザにSSHを解放しちゃうくらいの自由度がウリだったりする側面もあるわけだし、ビジネス仕様なレンタルサーバなわけだし、属性型JPドメインのDNSはなんとかならないもんだろうか。

追記:

ふと思ったのは、今回、さくらインターネットのドメイン管理サービスで預かってもらおうとしたドメインは、他社で取得したモノで、それをさくらインターネットに移管しようとしたので、もし、最初から新規でさくらインターネットで取得した属性型JPドメインだったら、ゾーンファイルを編集することができるのかもしれない…が、未確認。

どうやら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にトランスファーします」なんて意味不明なことを言い始めるもんなぁ…って、どうなんでしょう。

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