Galaxy Nexusを購入しました

先週、12月19日にSamsung Galaxy Nexusを購入しました。現時点でAndroid OS 4.0を搭載した唯一の機種です。また、その名の通りGoogle監修によるリファレンスモデルのNexusシリーズの最新機種です。
国内では既に12月4日にドコモから日本向けのGalaxy Nexus SC-04D発売されており、その手のレビュー等については他の方が既にたくさんレビューされているので、今回この場では、それ自体に対する使用感などについてはここでは特に書きません。そちらが目的の方は別途探してみてください。

では何を書くかというと、誰も興味ないであろう、既にiPhone4を利用しているのに、どうして買ったかなどを自分の記録のために書いておきたいなと思った次第です。

なんで?動悸は?


Android機は今まで触ったこともあるし、それ向けにモック程度のアプリを作ったこともありました。しかしどちらも仕事として、また会社端末の初代Xperia、初代GALAPAGOSの機種を触ったことがあった程度でした。
この辺りで感じたことは、動作がモッサリ、タッチした箇所が目的でない場所で反応するなど、以前から使っていたiPhoneと比較しても全く使いたいと思える端末ではありませんでした。
なので、今後もAndroidは買いたくないし使いたくないなと思っていました。

しかし、昨今のスマートフォンの普及状況を見ても分かるとおり、端末も安価で多数のメーカーから販売されているAndroid端末の普及速度は、スマートフォンのみならず各種タブレット、さらには一部でカーナビに使われるなど、様々なところで目にするようになってきました。

……なんていう堅苦しい市場動向は、多少は考えていつつもそこまで今回は考えてません。
詳しくは経緯にて。

また、アプリの開発、マーケットへの公開についてもiOS用に開発するよりも開発しやすく(Javaで作れる習得のし易さ、開発環境もeclipse+Android SDKでどの環境でも行える)、AppleのAppStoreに出すよりも容易(実質審査はなく、開発者に年間利用料を請求するのではなく、登録費用登録費用$25を初回に支払うのみ)なため、開発者としても遊びやすいなと思えるところでした。

あとは、先ほど挙げましたが、普及台数が多いのは本当のところで、今までWebアプリを主に作ってきた身として、Android位はせめて手元に実機で欲しいなというところです。
エミュレータでも良いんだけど、確認だけでアレ立ち上げるのは。。。

ぶっちゃけた話しが、ただ携帯の買い換えをしたかっただけです。
本当を言うとWindows Phone 7.5(Mango)の端末が欲しかったのですが、

現状、auの東芝製端末しか出ていない。
auにMNPしたくない。

というところで今回は諦めたのですが、本命としてWP7はまだ欲しいので、どこかでうっかりする可能性がまだまだありそうです。



経緯


今年(2011年)9月頃に仕事で出張したバングラデシュ国内で、それまで使っていたガラケーを紛失。

恐らく、舗装されてない道を移動する際に使ったバイクタクシー的な乗り物に乗ってる最中に、ポケットから飛び出してそのまま。

見つかるハズもなく帰国。

携帯会社の安心保険的なものを使ってもあまり安くそこそこの機種をゲットできそうにもなく断念。

今さら新しいガラケーなんて買う気もなく、iPhone4使っているのにiPhone4 S買う気にもなれず。

現在発売されているAndroidも特に魅力がなく。(
↓→SBMからWP7機が出てたら買ってた

分割購入ではなかったものの、端末代金割引終了まであと数ヶ月。

以前使っていた4年ほど前の携帯を使う。

しかしバッテリーが膨張して破裂寸前状態、また電池も5分程度しか持たない情況でどうにか過ごす。

どうにか3ヵ月粘ったが、無くした端末よりも機能的にも劣り、電源も持たない状態で毎月通信費を取られるにはもう限界。

Android 4.0搭載のGalaxy Nexus発売。

Nexusはリファレンス機なので、メーカーやキャリアのつまらないプリインアプリが無い。
↓→変な制限もなく、素のAndroidがそこそこ最新スペックで使える

ドコモにMNPしてしまおうか(SoftBankを使ってます)
↓→でもドコモ版は相変わらず制限あるし使いづらい。
↓→ドコモはiモードのしがらみで生まれたSPモードがあるのが好きじゃない。
↓→そのSPモードはずっと障害続き
↓→→その矢先にランダムメールアドレス事故。
↓→→ドコモにはやっぱり移りたくない…

Nexusは世界中で売ってるし、この際SIMフリーを探してみよう

意外と安く、5.6万円程度で買える。

よし、買おう!



SIMフリーです


今回は自分では初となる、SIMフリー、そして初の自前Androidということでちょっと楽しみにしてました。
本来であればガラケーからの乗り換えとなるのでSIMフリーとは言え、ショップでスマホ向けプランに契約を切り替えないと行けないのですが、あれこれ調べた結果APNさえ設定すれば諸処の都合上今の契約でもうまく使えそうであることが分かったため、現在はそのまま使っています。
あとガラケー側で利用しているおサイフケータイなどがまだ残っていて、こちらの切り替えが出来てないので通信できなくなってしまうと困るなーというのがあります。

一昨年と昨年は年に2〜3回程度海外に出張に行くこともあったので、今後も出張期間や海外に行く際にはこの端末に現地のSIMを挿して使えば、ローミングで高額にならずに安くすむし良いなーという利点も含めてます。



で、何したの



まずはフツーに起動して、アカウント設定して、アプリ入れて…としていたのですが、フォントがアレ…。
そう、中華フォントと言われているCJKフォント。あれ?聞いてた話しだとモトヤフォントが採用されてリポジトリにも入ってたはず…。
で、見慣れない書体で違和感をぬぐいきれず、フォントの入れ替えについてググってたりしました。

その方法については、以下のサイトを参考にさせて戴きました。
Linux/CGP作業メモ » Galaxy Nexusのフォント入替え方法(非rooted)のメモ

上記のサイトでの補足事項として、最初、DroidSansFallback.ttfの記述の後ろに設定を追加していたのですが、どうもDroidSansFallback.ttfで定義内でマッチしない言語のフォントをすべてを拾ってしまうようだったので、これの直前に追加する形にしたところ、うまく反映できました。

現在はrootを取得してまでしたいこともないので、その辺りについては全く行ってないです。


で、まとめると


そんなわけで、WP7端末が欲しい私がAndroid端末を購入したつまらない話しでした。

さくらのVPSを使いながら行ったウェブサイトの3つの負荷対策

久しぶりのブログ更新になります。
色々と書きたいこともあったけど、サボってます。(継続中)

少し前の日記に書いたのですが、このブログおよび僕が公開しているいくつかのウェブページについては、基本的にさくらのVPS 512を利用しています。
512は最低プラン(初期からあるプラン)でメモリが512MBしかない環境です。そんな環境なのもあり、以前にTwitterのアカウントが商標権問題で変更せざるを得なくなった話を書いた際に、ありがたい事(?)に/.Jに取り上げられたり、はてブも300近いブックマークをもらったりするほどのアクセスとなりました。

当時、記事を公開した日の朝には、はてブやTwitterなどで話題に上げられ、アクセス増からサーバが高負荷状態となり、記事の閲覧が出来ない状態が続いていたりもしました。このときはmysqlやApacheの再起動を繰り返してみたりするも、あまり効果を発揮できず、最終的にはサーバを再起動させたように覚えています。

この時以降、こんなしょぼくれた個人サイトやブログでも、ある程度はサーバ負荷対策やキャッシュをしっかりしておかなければなと思い、いくつか対策を行ってきました。
これはサイトを運営する上で、サーバやサービスを落としてはいけないという下手な使命感のようなのもありますが、自分自身ウェブ系エンジニアを名乗るとして、それだけのことが出来ていないことが恥ずかしくもあったためです。


長い前置きとなりましたが、そんな僕が現在まで行ってきた大量アクセス時の負荷対策をいくつか挙げていきます。



Wordpressのキャッシュプラグインのインストール
WP Super Cache


おいおい、そこかよというツッコミも聞こえてきそうですが、当時、僕はこのプラグインを入れたつもりだったのですが、実際には入っていない状態となっていました。
そのため、記事のリクエスト時に毎回データベースに接続が行われ、データベースへの接続も、要求処理も原因し、結果過負荷となり、ページを表示出来ない状況に陥っていました。
その後このプラグインを正しくインストールして設定することで、ページのキャッシュが有効化され、大量アクセスが発生してもデータベースへの負荷をかけることなくページを表示できる様になりました。
なので、このプラグイン一つをとっても大量アクセスに対しては劇的に変わるため、これはWordpressでサイトやブログを運営するにはほぼ必須だなと実感しました。


Apacheからnginxへ
nginx
php-fpm

今まではApache + phpモジュールという、ウェブサイト構築ではごくごく一般的な構成を取ってきました。しかし、この構成は設定も楽で、管理もしやすく、TIPSも大量にあるため運用するにはとても最適なのですが、大規模アクセスとなるとApacheのメモリ消費量や負荷が目立つようになってきます。また、Apacheの中にphpへの処理が組み込まれるような形となる(具体的には異なりますが)ため、php側の処理にApacheが引きずられることとなり、phpの処理が関係ない部分まで応答が返せなくなるケースにまで至ることがあります。

そこで、メモリやCPUリソースの消費量も少なく、高速にリクエストされたコンテンツを処理して配信することができると話題のnginxを導入してみました。
これを導入することでメリットがあるのは、複数のウェブサーバとアプリケーションサーバで構築された中規模以上の環境でのリバースプロキシとしての利用や、画像などの静的コンテンツを大量に配信するサービスだと思います。

普通のウェブサービスの場合は、運用のし易さの面からも、ある程度の規模なら今までのApache + phpでもなんら問題ないと思います。
僕がこれを導入したのは、負荷対策と言うよりどちらかというと、最近のCGM系コンテンツやUGC系サービスサイトでよく見かけるようになってきたと言う技術的な流行が気になったというところと、個人的な実験的な要素が濃いです。

このnginxはApacheに比べて格段に動作が軽いのと、phpなどのスクリプトはfastcgiとして基本的に切り離していること、細かなところでカスタマイズができること、機能的にもApacheにはない、高速配信のためのキャッシュの仕組みがいくつか設けられていることなどのメリットもあります。
ただし、現時点ではまだまだ新しいサーバで、日本国内における運用系の情報は圧倒的に少ないですが、開発も活発で、また後発のプロダクトと言うこともあり、先発のApacheをはじめとしたサーバのいいところを取り入れて行っていると思い、今後も期待が出来そうかなと思います。
こちらの機能や導入についての詳細は、いくつかのブログで既に書かれているので、そちらを参照してみてください。


CDNの利用
CloudFlare

僕はCDNと聞くと、Akamaiなどを利用した、それこそ大規模なサイトでのコンテンツ配信をイメージしていたのですが、そのCDNを個人のウェブサイトにも簡単に、しかも無料で導入することができました。それがこのCloudFlareです。

CloudFlareは、ウェブサイトを丸ごと、cloudflareが持つCDN上にキャッシュとして持ち、配信してくれます。
簡単なイメージ的には、キャッシュプロキシが入る感じです。

これの導入方法は少々敷居が高いものの、至って簡単で、CloudFlareでアカウントを登録した後、サイトのドメインのDNSをCloudFlareの提供するDNSサーバに切り替え、DNSの設定をするだけ。簡単です。

メリットとしては、

  • キャッシュプロキシとなってくれるため、サイトに一切手を入れず、丸々をキャッシュしてくれるため、導入が楽

  • 高機能なDNS機能もフリーで提供される

  • ほぼ静的なページを大量のアクセスを捌くのに、追加サーバ導入コストを抑えられる

  • 簡易アクセス統計機能付き(リクエスト回数など)

  • キャッシュプロキシだけど、Google Analyticsなどの外部アクセス解析機能などにもしっかり対応

  • リクエストを弾きたいIPなども制御できる

  • これらがすべて無料(ただしある程度以上の規模は利用不可?)

といったところ。
上記を管理するコントロールパネルのUIのよく出来ていて、簡単かつ気持ちよく設定できます。
ぶっちゃけ、CDN機能を使わずに、高機能なDNS機能だけ使わせてもらうことも可能。最近対応していましたが、以前はVALUE-DOMAINのフリーDNSではIPv6には対応していませんでしたが、CloudFlareではIPv6にも対応されていました。

逆にデメリットとしては、

  • ドメイン単位での導入が前提なので、そもそもドメインを持っていないと利用できない。

  • ドメインのネームサーバ変更を必要とするため、サブドメイン毎に複数サービス運用している場合に、一部のサービスだけ利用を試してみるといった利用がしづらい(設定すれば可能だが…)。

  • サーバプログラム内でユーザのIPアドレス毎に制御を行っている場合、そのまま利用できない(一部参照先ヘッダの変更など、プログラムの書き換えが必要)

といったあたりでしょうか。


ちなみに、自分のサーバへのリクエストログには、CloudFlare経由の場合、すべて米国にあるCloudFlareのIPからの接続が残ります。
余談ですが、CloudFlareのキャッシュプロキシサーバは
varnishを利用している最近はnginxベースのものになったようです。
(コメントをいただきましたたくさんありがとうございます)




以上、3つとなります。他にも出来ることはあると思いますが、まずはこれでひとまずと思っています。
というのもあれ以降、大量のアクセスが舞い込むようなことが無いため、これでどれほどの効果が上がるかがまだ検証できていない状態です。


#本当は別のことを書こうと思っていたのに、気付いたらまったく違う内容で書き上げてしまっていたというオチ。

PSNの障害と個人情報漏洩について

話題のPSNのネットワーク障害、いうかセキュリティ問題および個人情報漏洩について、本日14時頃にSCEからメールが来ていたので掲載してみる。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【重要なお知らせ】2011年4月27日
“PlayStation Network”/“Qriocity”をご利用の皆様へのお詫びとお願い
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

※本メールは重要なお知らせとなりますため、
“PlayStation Network”/“Qriocity”にアカウント登録されている皆様へ
お送りさせていただいております。

本内容は下記のURLからもご確認いただけます。
http://www.jp.playstation.com/R/m10427_PSN001


2011年4月21日より“PlayStation Network”および“Qriocity”の障害が
継続しており、お客様および関係各位に多大なるご迷惑をおかけしており
ますことを深くお詫び申しあげます。

弊社では、同日より各サービスの公式Webサイト上に障害の状況を都度告知
すると同時に、本件詳細についての徹底調査を行ってまいりましたが、このたび
“PlayStation Network”および“Qriocity”に対する不正アクセスにより、
2011年4月17日から19日にかけて以下のようなお客様のアカウント情報が漏洩して
いた可能性があることが判明いたしましたので、ここに深くお詫びを申しあげる
とともに、その旨を報告させていただきます。

漏洩した(不正アクセス者が入手した)とみられるアカウント情報: 

・お客様が“PlayStation Network”/“Qriocity”に登録した、氏名、住所、
 Eメールアドレス、生年月日、“PlayStation Network”/“Qriocity”パスワード、
 “PlayStation Network”オンラインID

また、以下の情報につきましても不正アクセス者が入手した可能性があります。

・購入履歴、請求先住所、パスワード再設定用の質問への回答等のプロフィールデータ
・サブアカウントに関する上記情報(お客様がサブアカウントを作成されている場合)

なお、お客様が“PlayStation Network”または“Qriocity”にクレジットカード情報を
登録されている場合、登録されているクレジットカード番号(セキュリティコードを
除く)および有効期限に関する情報が不正アクセス者に入手された可能性を完全に
否定することはできませんが、現時点ではそのことを示す形跡は見つかっておりません。

弊社では冒頭に記載しました不正アクセスの事実が確認された時点で速やかに
以下の措置を講じるとともに、引き続き詳細についての調査を継続しております。

1)“PlayStation Network”および“Qriocity”サービスの一時的な停止
2)本件の調査を情報セキュリティ専門会社に依頼し、実態の把握に努めること
3)個人情報の保護強化を目的とし弊社のシステムセキュリティを更に高度化するため、
  システムの再構築によるネットワークインフラの補強

弊社にとって安全且つ高品質のエンタテインメントサービスをお客様に提供することは
最優先事項と認識しております。弊社では今回の事態を真摯に受け止め、引き続き
個人情報の保護の強化とサービスの速やかな復旧を目指してまいります。

本件に関する追加情報やサービスの復旧時期などが判明した場合には、Webサイト等を
通じて継続的にお知らせしてまいります。お客様には多大なるご迷惑とご心配をおかけ
しておりますことを重ねてお詫び申しあげます。

“PlayStation Network”および“Qriocity”のサービスが復旧した際は、お客様が
ご利用のパスワードを変更されることを強く推奨いたします。併せて、お客様が
インターネット上でご利用の他のサービス等で、“PlayStation Network”/“Qriocity”
と同じユーザーIDやパスワードを使用されている場合は、それらの変更を強くお奨め
いたします。

さらに、お客様に成りすました不正ログインや不正利用を防ぐために、アカウントに
登録されている情報の詳細やクレジットカードの引き落とし履歴等を定期的に確認される
ことを推奨いたします。(クレジットカードに関連する情報についてご不明な点等に
つきましては、ご利用のクレジットカード会社にお問い合わせください)

なお、いかなる場合におきましても弊社からお客様のクレジットカード情報等の
個人情報をEメール等でお尋ねすることはありません。安全のため、お客様各位に
おかれましてはEメール、電話、郵便などを使ってお客様の個人情報を聞き出そうと
する手口には十分お気を付けください。

本件についてご質問等がございましたら、
株式会社ソニー・コンピュータエンタテインメント インフォメーションセンター
および“Qriocity”お客様窓口までお問い合わせください。

≪お問い合わせ先≫
“PlayStation Network”についてのお問合せ
株式会社ソニー・コンピュータエンタテインメント インフォメーションセンター
TEL 0570-000-929(PHS、一部のIP電話の場合 03-3475-7444)
受付時間10:00〜18:00
http://www.jp.playstation.com/support/

“Qriocity”についてのお問合せ
“Qriocity”お客様窓口
0120-365-859
※携帯電話・PHS・一部のIP電話などフリーダイヤルがご利用になれない場合
0466-31-2505
受付時間 月〜金:9:00〜18:00 土日祝:9:00〜17:00
http://www.qriocity.com/support

==============================================================================
本メールの送信メールアドレスは配信専用のため、返信いただいても
回答することができません。不審なメールやメッセージを受け取った方は、
当メールに記載のお問い合わせ窓口へご連絡をお願いいたします。

「お問い合わせ窓口」
ソニー・コンピュータエンタテインメント
インフォメーションセンター
TEL 0570-000-929(PHS、一部のIP電話でのご利用は03-3475-7444)
受付時間 10:00-18:00
http://www.jp.playstation.com/R/support_formjp

-------------------------------------------------------------------------------
<発行>
ソニー・コンピュータエンタテインメント

■“PlayStation Network”のご利用に関する規約
http://www.jp.playstation.com/R/psn_kiyaku

■よくあるお問い合わせ(FAQ)
http://www.jp.playstation.com/support/

■ソニー・コンピュータエンタテインメントの個人情報保護方針
http://www.jp.playstation.com/about/privacy.html

ミクパ♪(初音ミク ライブパーティ 2011)に行ってきたよ

2011年3月9日、ミクの日です!
今年も、昨年のミクの日感謝祭 39's giving dayに続いて、初音ミク ライブパーティー 2011 ミクパ♪に行ってきました!

…といっても今年はライブチケットは残念ながらとれず、ライブビューイングで見てきました。正直なところ、ライブビューイングもチケットが取れなくて、東京ジョイポリス内でのライブビューイングしかないなーと思っていたところ、藤城嘘さんに1人分チケットを譲っていただき、どうにか見れた次第です。嘘さん本当にありがとうございました!!


そんなわけで今日は昼から会場に行き、物販に並んだりしながら時間まで過ごしていました。
物販では公式グッズでパンフレットとピンバッチ、コラボグッズでいくつかとCDを購入しました。
正直なところ、今回の公式グッズの方は総じてデザインが…


そのあたりはさておき、ライブの方について。
今回のライブについては既に各所で出ているかもしれないけれど、突っ込みどころが満載で、ファンにとっては非常に残念結果となってしまっていた印象を受けました。


スクリーンの変更
前回ライブ時には、ミクさんは透明アクリル板(?)による透過スクリーン投影によるもので、非常に先進的かつ新鮮なライブとなっていました。必要な場所以外、背後がすべて透けて見えるため、あたかもそこにいるように感じることができるものでした。
一方で今回は巨大LED液晶スクリーンによる表示。大きいスクリーンがあってそこにミクさんが表示されている状態。
その場に臨場感は減るものの、これはこれで透過スクリーン投影による弊害(正面から見ると、背面のプロジェクタからの光がまぶしくて一部見づらい、ライブのライティングの演出でスクリーンを照らせない、元々色がないところに投影するため若干透けて見えるなど)を回避できたのではないかと思います。
あと肉眼でも若干うっすら感があるのに対し、カメラなどの映像で残すとさらに写りが弱くなると思うので、主催の5pb.さん的には変更ここの理由かなとも思っています(あくまでも素人目線で思った部分です)

また、ライブ中のミクさんの表現方法が広がっていたのではないかなと思います。たとえば、スポットライトで照らされた際には、それに併せて照らされているようにうまく背景の光と影をつけることで、あたかもそこにいるような演出を細かく描画できる(実際にそのようなシーンがあった)、透過スクリーン投影では難しかった(と思われる)透明度を持った映像エフェクトの鮮明な描画(背中から映えた翼など)ができるようになっていたと思います。


振り付けの変更
聞き慣れない新しめの曲やDIVA系では見たことのない曲も多々含まれていたので全部かどうかは分かりませんが、一部の曲などにおいて、DIVAと比較して振り付けが変更されていました。
僕が気付いたところでは、炉心融解の振り付けが少々激しくなってたなーと感じました。
あとはカラフル×メロディーでミクとリンが交互に前後入れ替わって出てきて歌うところがなく、それぞれ横に並んで歌っていました。

これらの振り付けは今後のDIVAでも反映されるのか気になるところです。


ライブの進行について
ここについてはいくつかあります。
まず、誰もが納得いかなかった、開始1時間後に入った謎の30分休憩
僕が今まで見てきた様々なライブの中でこれは前代未聞です。
仮に休憩があったとしても、場面転換演出の一部として、ステージ全体の照明を落として数分間あるくらいです。
まして、開始僅か1時間後、さらに言うとミクさん登場から30分程度で休憩30分。

/人 ◕ ‿‿ ◕ 人\ < もう訳が分からないよ

仮にも演舞時間の決まっている有料ライブです。その中で30分を、よく分からない休憩と称して同じCMをひたすら流すというのは理解できません。どう見ても時間埋めでしかないです。

演奏しているバンドへの休憩の意味なのでは?
→これはないと考えています。今回のライブ中にあった曲でも、バンド演奏を必要としない(生演奏しにくいシンセ音出構成された楽曲など)曲がいくつかあったわけで、その曲の間は少なくとも休むことができたと思います。
ましてバンドがサポートメンバーによる構成であったとしても、有料ライブで演奏にはある程度以上のプロであるはずなので、そのあたりの体力付けもされてるはずだと思います。そうでなかったとしても、30分の休憩は普通に考えて長すぎます。
(通常はMCである程度この間を設けるんですけどね、ミクさん、ボーカ"ロイド"なのでね…)

これだけでも今回の内容の中で結構クレーム来るんじゃないかなぁ。どうしてこんな進行でOKが出たのか分からない。
とにかく、多くの人にとって謎かつ不満になる要素だったと思います。

次にライブ中のメドレーについて。全体を通して、去年と比べてもメドレーが多かった印象です。
むしろメドレーであることがメインであるかのような流れだったのに驚きました。
あとそのメドレーの組み合わせもあり得ない。観客はみんな非常に曲間のつなぎからノリづらそうだったし、なんでテンポが同じ、あるいは似た曲同士でつなげなかったのだろう、と割と素人目で見てもみんな感じていたと思います。


メンバー紹介もないの?
バックで一生懸命演奏しているバンドメンバーの紹介もライブの醍醐味の一つ。前回はそこもちゃんとあったのですが、残念ながら今回はそれもないままでした。
あとゲストで登場していたPの紹介もなく、Pが演奏していてもPを写すシーンが全く組まれておらず、Pを写すカメラも用意されていなかった。
一体何のためとゲスト出演だったのだろう。失礼ながら、これなら別にPがいなくても問題なかったのではないかとすら思えてきます。
告知や集客、注目を集めるために出演Pを書き連ね、読んだのだろうか、前回も呼んでいたから今回も呼ぶか(けど紹介も映像もなし)という流れだったのでしょうか。

ライブビューイングへの対応
今回はライブビューイングでの観覧だったのでカメラでの映像がかなり重要でした。
しかしアングル内には大きな柱が映り込んでしまっていたり(構造上仕方ないかもしれないですが)、音が明らかに劣化していたり(128k〜134kbps程度?の音質に聞こえました)と言った状態。




いろいろな意味で5pbさんには期待を裏切られたなと思います。前回のSEGAさん主催のライブがすばらしくできが良かったというのも理由としては全然ありますが、それにしてもちょっと酷いなと感じられる部分が大きく出てきてしまったのが残念です。
正直なところ、公式グッズも今回は微妙で、はっきり言ってしまうとコラボグッズの方がデザイン的にも良いものが多かったです。

と、つらつらと文句をたれてしまいましたが、それでも去年に引き続きやってくれただけ良かったと思うようにもしたいですね。
今回のミクパについてはそれ自体はそこそこ楽しく過ごせたと思います。ただ、メインとなるライブ部分に残念な結果が多々散見されてしまったので、もし来年もまたあるとしたら、今年の残念だった部分改善していただき、今年のような中途半端な感じにならず、是非とも最後までみんなが満足行く形にしていただきたいものです。

FirefoxからChromeに乗り換えてみた

今までずっとMozilla Firefoxを使ってきていたのですが、起動しただけでメモリは食いまくるし、タブ開きすぎるとすぐ固まるし、重いし…といった調子で、だんだんと使い勝手が悪く感じてくるようになりました。

といってもFirefox本体が悪いと言うより、むしろアドオンの入れ過ぎだったり、タブ開きまくりだったり、(ブラウザを)起動しっぱなしだったり。。。といったことが原因になっているのだと思います。
(しかし便利なアドオンはどれも捨てがたい)
そして他にも、アドオンのインストールやアンインストール、無効化をするにはブラウザの再起動が必要で、アドオンのアップデートが入る度に再起動しなければならないので、そこも面倒くさいなーと思うところでした。

そこで思い切ってGoogle Chromeに乗り換えることにしました。

Chromeに変える理由は、

  • 動作が軽いらしい


  • (ブラウジングとJavascriptエンジンが)早いらしい


  • W3C準拠なので大抵のサイトは問題なく表示できる


  • HTML5に対応(現段階では一部)


  • 開発が盛ん


  • I♥Google


  • という理由なんですが、これOperaでも同じじゃね?ってところですが、個人的には一番下の理由ってのもあります。
    ちなみにOperaは嫌いじゃないです、むしろ好きな方です。これでもかと言うほどW3Cに準拠してて、Web屋さんとしては嬉しい限りなブラウザ。
    なのだけれども、使い慣れないというのもありこっちになっちゃいました。向こうの方がブラウザの歴史も長いんですけどね。


    さて、移行をするにはいくつか現在の環境からもってこないと不便です。
    1から環境を作り直していって、自分にしっくりしたものを作り上げていくのもいいですが、やっぱりなるべく慣れてる環境の方が作業効率もいいし、アレがないコレがないとイライラすることもなくなりますしね。



    ブックマーク

    ブラウザのブックマークなどは各ブラウザが実装してるインポート機能で持ってくればどうにでもなりそうだけど、それほど使っていなかったのでここはまっさらなまま移行。

    アドオン / Extension

    あとはFirefoxで使っていたアドオンと同じような機能をもつExtensionを探してきて入れて、一部のグリモンもそのままインストールし直すことで移行できたけど、それでも一部のグリモンはどうしても動かなかったので、それはExtensionなどで代替になりそうなものを探してカバー。
    それでもなかったら…対応されるのを待つか諦める。
    自分でどうにかできそうならグリモン書き換えるのもありだろうけど、面倒だったのとそこまで困らないものだったので放置。


    Chromeのよい点


  • とにかく早い


  • 本体のアップデートは自動的に行われ、任意のタイミングで終了または再起動したときに最新版になっている!


  • Extensionのインストール、アンインストール、アップデート、無効化はブラウザの再起動無しで行える


  • Googleアカウントを紐づけることで、どこの環境で使っても常に同じ環境で使うことが出来る!


  • 各ブラウザタブがそれぞれ独立したプロセスとして動作している→一部のタブで反応がなくなっても他のタブは生きている。


  • Extensionなしに、ブラウザだけでGreasemonkeyスクリプトに対応している。


  • Web開発に最適!


    • Webデバッグツールが標準で付属する!

      • Windows版ならCtrl+Shift+I、Macなら⌘(command)+option(alt)+Iで起動

      • →Firebug相当のデバッグツールがWebKit標準で組み込まれているためFirebugいらず!(コレとは別にChrome用Firebugも存在します)

      • →このデバッグツールの嬉しいところは、デバッグツールから編集したHTMLやCSSの結果がその場で即時画面に反映されて確認できること。わざわざHTMLの書き換え→リロードといった手間も省けます。


    • WebKitベースなのでiPhoneやAndroid向けサイトの確認もばっちり!

    • HTML5に対応している。→現時点での実装はOperaには負けますが...



  • メモリ管理がすばらしい


    • 参照されていないタブ管理のメモリ消費を抑える


    • しばらく閲覧していないタブはメモリ上から解放し、次に閲覧されたタイミングでキャッシュから表示する。
        →Firefoxでもアドオンを使えば同等の事は再現できるが、Chromeはこれがデフォルトで行われる。



  • ブラウザの機能毎のPCリソース使用率が分かりやすい。


    • タブやExtensionでそれぞれで利用しているメモリやCPUの割合をちゃんと管理しているので、どの部分でどれだけリソースを消費してるかがタスクマネージャですぐに分かる。

    • それぞれがどの処理(JavaScriptの処理や画像や各スクリプトのキャッシュなど)においてメモリやCPUリソースを消費しているのかまでが分かる。


    Chromeの設定画面からGoogleアカウントでログインし紐付けることで、アカウントごとにChrome利用環境を同期させることができます。




    Chromeの微妙な点


  • 起動するだけでプロセスが大量に立ち上がる


  • いつの間にかバージョンアップされている


    • バージョンアップというものをユーザに全く意識させない。反面、ユーザに選択肢がゆだねられていない。

    • → 過去のバージョンを使い続けたかったとしてもそれが行えない。



  • Firefoxに比べてExtensionが少ない。


    • → これはしょうが無いかなぁ。とはいえ、今ではだいぶその数も増えてきているし、今後は同等程度に増えてくる可能性は大いにある。



  • 時々プロセスが暴走し、全体的に停止する。。。


    • → これは僕が開発版であるDevChannel版を使っているせいかもしれないですが、たまにあります。

    • ただほかのブラウザが全停止して再起動する頻度に比べればこのケースは少ないと思います。




    そんなわけで、現在はChromeに乗り換えて開発も閲覧もとても快適に過ごしてます。
    Throw away Firefox, Let’s enjoy the web with Chrome !!

    テスト用の簡易SMTPサーバをPythonで作る

    メール送信処理のテストをしたいのだけれど、わざわざテスト用のメールサーバを用意するのも面倒。
    そんな時に便利なテスト用サーバを簡単に作る方法。

    以下のコードを記述し、Pythonで実行するだけ。


    pythonコマンドで上記スクリプトを実行してコマンドプロンプトまたはターミナルに待機させておくだけ。

    あとはローカル環境からメール送信を実行すると、インターネット上のメールサーバに行かず、送信されたメールは、例え宛先が実在するドメイン名、ホスト名、アカウント名であっても、すべて上記のスクリプト側でキャッチされ、外(インターネット)へは行きません。

    キャッチされたメールの内容は画面に出力されていきます。

    なのでスパムメール送信処理のテストにはもってk
    ループ処理などで一斉にメール送信をする処理のテストであっても、誰にも迷惑をかけずテストをすることが出来ます。

    以下の記事から引用
    テスト用のオレオレSMTPサーバー - Watanabe.Tの日記
    http://d.hatena.ne.jp/watanabe_t/20080808/1218175319

    すごく便利だったのですが、だいぶ前に元記事が消えてしまっていた(この方のアカウント毎無くなっていた)ので、Webアーカイブから引っ張ってきて紹介。(もし問題があるようでしたらこの記事も消します)

    初めてはてブホッテントリに入って分かったこと。

    約1ヶ月前の先月末(2011年1月30日)、僕がこの記事を書いたことにより、僕が今までに経験たことがないことが起こった。

    280を超えるはてブ数、そしてTwitterからの大量のアクセスだった。

    今までそれほどの注目を集めるようなことをしたことがなかった僕は、この事態に驚きつつも、それだけの注目を受けたことに少しばかり嬉しさがあった。
    しかしその反面で、ウェブサイトを運営するに辺り、やってはいけないことに直面する。

    アクセス集中によるサーバの過負荷と、それによる接続障害

    接続障害と書くと少々大げさな気もするが、要はサーバが大量のアクセスを捌ききれなくなり、応答を返せなくなってしまっていた。
    ブログの記事を書いたのが深夜。と同時にTwitterとFacebookにその記事を流した。
    しばらく様子を見ていたものの、特にいつもと変わらない状況であったため、そのまま眠りについた。

    そして翌朝、目が覚めるとブログが表示できない。そう、いつの間にか注目を浴びることとなっていた。
    正直どのタイミングから、どのタイミングでそんなに人が流れてきていたかは分からないが、おそらくはTwitterだろう。
    ブログ投稿時には、他にもいくつかのブログフィードにPingを送っていたのでそちらからかもしれない。

    で、そんなことより朝出勤前から繋がらない。
    これでは仕方が無いので、まずは状況を確認。別なサーバに設置していたmuninと、ターミナルからSSHでサーバに入り、重い中どうにかtopコマンドやfreeコマンドなどで状況を確認。Load Averageがひどいことになっている。さらにSWAPが発生しまくっていたことから、メモリSWAPが原因でLAが高くなり、繋がらなくなったとわかる。
    まず原因として一番はApache、そしてMySQL。なのでとりあえずこの2つを再起動し、状況が治まってきたことを確認し、まずは出勤した。

    稼働環境

    現在のこのブログ及び僕が運用しているいくつかのウェブサイトは、すべて同一の環境下で動いてる。
    その環境とは…

    サーバ: さくらのVPS
    CPU: Core2 Duo 2.4GHz (/proc/cpuinfo の情報に基づく)
    メモリ: 512MB
    サーバOS: CentOS 5.5
    ブログシステム: Wordpress 3.0.4_ja
    HTTPD: Apache 2.2.x
    PHP: 5.3.x
    MySQL: 5.1.5x

    上記がすべて1つの仮想マシン上で稼動している。


    結果

    結果的にはWordpressが参照するDBへの同時接続が多くなり、(またMySQLの設定も動作環境に適していなかった)接続が溜りったことにより(?)SWAPが大量に発生し、LAが上昇するという事になっていたようだ。
    また、キャッシュ機構はMySQL側にもPHPにもWordpressにもそれぞれ有効にしていたが、それでも足りなかったか、Wordpressのキャッシュ機構を適切に設定出来ていなかったため、急激なアクセス増に対して一気に許容範を超え、負荷が上昇することが、その日のうちに度々発生していた。

    一番まずかったのは、その日は仕事中のこともあり、接続できない状態を分かりつつもしばらく対応できない状態が2時間ほど続いたとき、さてサーバにログインし、Apacheの再起動を…と思っていると、ログイン出来ない。それどころか繋がらない(応答しない)。
    muninのグラフを見てもチョチョ切れでもはや計測不能。ただし負荷がかかっていることはその前後にかろうじて観測できたグラフから確認できていた。

    さくらのVPSの管理画面からシリアルコンソールでつなごうとしても反応がない。仕方が無いのでサーバマシン(仮想)を強制再起動しました。その後再起動をし、無事事無きを得ました。

    完全に個人用途で趣味のため、大したウェブサービスが乗っているわけじゃないものの、仕事柄なのか少し焦りました。
    あと、別に広告貼ってたりしてるわけじゃないけど、せっかくのアクセスが機会損失になるのも嫌だし、なによりブログを見に来てくれているにもかかわらずつながらなくて見れないのはやっぱり失礼ですしね。




    TwitterにURLを流して気付くこと

    これはアクセスログをリアルタイムに見ていて気づいたこと。
    時間帯も影響するかもしれないが、TwitterにURLを流した瞬間に、まず多数のURL収集ボットがやってくる。
    今回深夜にURLを流した際はそれほど来なかったが、以前日中に流してみたときは、ドッと複数のURL収集ボット?がやってきた。それらはおそらくUserStreamを常に監視してURLが流れてくるとその先をクロールし、情報を取得してくるのだろう。

    さらに誰かがRTした瞬間に、急激にアクセスが集中する。RTされたタイミングで多くの人がアクセスするのと、自動的にリンク先URLを巡回するクライアント(短縮URLの展開機能?)やボットによってたくさんのアクセスが本当に短時間で集中することになる。
    これらによって本当に何度も処理仕切れなくなって応答を返せなくなっていた。

    なにが言いたいかというとTwitter怖い。


    結論

    スラッシュドットジャパンにも紹介されたりもしましたが、今回においてはスラッシュドット効果よりもはてブ効果と、何よりTwitterによる瞬間的なTwitter効果が怖かったです。

    そんなわけで、ブログというものはそれ専門で運用している外部のサービスにおいて運用していた方が、安全安心だなと思った次第でした。
    (この間のはたまたま集中しただけなので、多分このブログはしばらく動かさないと思います。)

    訴えられそうになった話:経緯、思ったこと、反省点、経過など

    今回、ブログに公開したことによって、様々な意見や考え方に触れることできた。

    しょうがないねとか、嫌だなーとか、もっと粘ってふんだくればいいのにとか、そんな商標権にそこまで権利ないよとか。
    あまり例にない事と言うことや、話題性の高いTwitter上でのトラブルと言うこともあり、色々とあちこちで意見やコメントを見せてもらいました。


    経緯

    で、なんで僕は今回応じるようにしたのか。

    簡単に言ってしまうと、僕は頭悪いし法的な知識はまるでない。そして面倒くさがりである。なのでアカウントIDを譲った。

    それにそんな状態で下手に争って負けて変な前例作ったら、みんなに大バッシングくらいそうだし。例え勝てたり和解で終わったとしても弁護士費用の方が高そうだしそんなお金ないし。
    というか、それ以前に今後このような事例が増えるようなことにもなって欲しくない。
    また、一個人がインターネットにおいて自由にアカウントIDすら使えなくなってしまうことは無論望んでない。
    ただし、もちろん他人の権利(法的に保護されているものもそうでないものも)を意図的に侵害するのは論外。

    とかなんとかいうのは後付けの理由で、僕なりにちゃんとした理由がある。
    最初に挙げたとおり、面倒事はゴメン被りたいというのも一つの理由である。


    いちいち法廷でとか書面でとか対応するのは流石に面倒ゴメンだし、前回書いたとおり、たかがウェブサービスのアカウントIDだ。
    ぶっちゃけて、何かの拍子にTwitterがサービス終了したり、なくなってしまえばそれで終わりなだけ。
    いま、誰が見てもTwitterのサービスそのものには価値はあれど、Twitter上のアカウントIDに価値があるのかと言えば、それぞれの使われ方や気に入り方次第だと思うけれど、一般的にはそんなものは正直皆無。あったとしても、ドメイン名などのパブリックなものと比べれば全然大したものじゃないと思っている。
    で、そんなものに対して金品を対価として相手に提供してまで欲しいというなら、僕は逆に美味しいと感じた。

    たとえばTwitterではなく、別のウェブサービスだったとしよう。
    「君のYahoo!のアカウントID良いね、いくら払うからそれちょうだい」
    「君のBloggerのアカウントID良いね、iTunesギフトカードあげるからそのアカウントちょうだい!」
    というのと道理は同じであると考えている。
    これもYahoo!やBloggerのサービスがなくなってしまえばそれまでの話。(おそらくは数年以上の単位で、そんなことはないと思うけど)

    これがドメイン名だとした場合、ドメイン名が勝手に消失する可能性は、WWWのドメイン名ベースでのアドレス解決を行う構造でも代わらない限りない。あるいは登録者自身の不手際でもない限り、消失することはほぼない。

    というわけで、アカウントID云々で手間をかけるには、僕はそれほど価値がないと考えているのと、そこに対して金銭的価値を見いだしてくれる人がいるなら、それが僅かであってもこちらにとってはおいしい。



    もう一つ。
    今回はAnonymizer, Inc.の社長から直接メールで連絡が来た。
    どのように僕のメールアドレスを知ったかは知らないけれど、僕はメールアドレスを各所に公開していたので、アカウントから照会ページのリンクでも辿って連絡を付けたのだろう。

    そんなことはさておき、今回の件をTwitterの運営元であるTwitter社経由で行っていた場合どうなっていたか。

    このページによると、先方も色々手順を踏んでいかなければならなそうだが、最悪の場合、僕のTwitterアカウントはTwitterによって突如凍結されていた可能性もある。

    といっても、(恐らく)Twitter側も相当悪質なケースを除いていきなり行ってくるとは思わないが、僕はTwitterをかなり利用しているし、万が一にも突然アカウントを凍結されてしまうのは正直辛い。
    なので、それが行われなかっただけでも僕はよかったと思っている。




    あとになって思ったこと、反省点

    反省点としては、まず向こうの要求に応じる応じないはさておき、一旦連絡してもう少し考える時間をもらうこともできたかなと。
    1週間ですべてを決断しろとまではメールでも書いてなかった。(が、提示条件をのんで対応する意志があるなら1週間以内に対応しろとは書いてあった。)返信がなければ法的に権利を主張する(出るとこ出る)よ。とはあったけど。

    ただ、相手が提示する条件を受けるには、結局のところ1週間以内で意志決定し、(ないよりマシ程度にいい条件を取るなら)対応をせざるを得なかったのかなーというのは事実。

    でもね、そんなに欲しいアカウントIDを、Twitterサービス開始から4〜5年経ってしばらくしてからひょこひょこやってきて、お前のそれ、ウチの名前だから。勝手に使ってるなよ、おとなしく寄こさないなら訴えることもあるからな。
    っていうのもなんかなーと思うんです。
    やろうと思えばサービス開始時にでもアカウントを取ることはできたわけで。
    少なくとも日本でTwitterが注目され始めたのは、Twitterのベータサービス開始(2006年7月)から半年〜1年後だったとみてる。(自分を含め、古くから利用している日本人ユーザのアカウント登録日から推測)
    あと商標権が、他者のウェブサービスにおけるアカウントIDにまで範囲が及ぶのも正直微妙。

    ただ、上にも書いたとおり、Twitterの利用規約的にはアウトっぽいのもあったので、下手に争ってアカウント丸々凍結されたら、この場合そっちの方が怖い。


    経過について

    そんなこんなで最初の連絡を受けてから既に1週間経った訳ですが、向こうから連絡が来たのは最初のメールと、その後僕が一度質問を送ったものへの回答メールの2回のみ。

    2回目に来たメールには、今度は丁寧な英語で回答が返ってきた(僕が質問を英語で送っていたので)。
    そのメールには「アカウント変更したら改めて教えてね。そしたら、ウチのサービスを君に提供する準備するから。で、そのとき登録に必要だから、君の情報(メールアドレスとかその程度)教えてね。登録できたらその情報も送るから。」と書かれていた。
    その後改めて、こちらから「アカウント変更したので確認とかアカウント名の取得とかよろしくね」と返信したものの、以降連絡が来なくなってしまった。

    もしかしたら忙しい社長さんなのかも知れないが、せめて1週間以内でという指定で要求してきたのであれば、なおさら素早く対応してくれても良いと思うのは日本人だからですかね。。。

    一昨日に改めて催促のメールも送ってみたけれど、これでまた何も連絡なかったら、ちょっとはこっちも強気に要求してもいいよね。

    後日談
    その後、催促してみたり何度かメールを交わして、最初にメールでもらっていたとおり、最後まできちんと対応してもらいました。

    Twitterアカウント名が商標権侵害で訴えられそうになった話

    2011年1月27日、僕はツイッター上において約4年間使用してきた自分のアカウント名を、 @anonymizer から @anon5r に変更した。
    これには次のような利用があったからだ。


    2011年1月25日、僕の元に1通のメールが届いた。
    その内容は、普段ツイッターで利用していたアカウント名 @anonymizer が、米国Anonymizer, Inc.の商標権を侵害していると言う内容だった。
    差出人名は Anonymizer社の社長、Bill Unrue氏。

    貴方が利用しているTwitterのアカウント名である @anonymizerが、Anonymizer社の国際商標権を侵害していて、その顧客を混乱させている。

    中略

    Twitterユーザ名のいかなる部分においてもAnonymizer社の商標であるAnonymizerの名前を使用しないで欲しい。また、米国、ヨーロッパ、カナダ、もちろん日本でも国際商標権を取得しており、その他の国においてもこれらを現在取得中である。よって、必要に応じては当社は商標権侵害として提訴することも可能である。

    中略

    ただし、なるべく訴訟問題としてこの問題を避けたいのでこちらから提出する条件を貴方が飲めるのであれば、アカウント名を変更し、その旨同意のことをこのメールから7日以内に返信して欲しい。
    ただし、返答なき場合は法的手段で権利主張を訴える考えがある。

    ※上記内容は意訳。

    文章もすべてとても丁寧な日本語で書かれていた。そこは恐らく日本語を扱える国際弁護士なんかに頼んだものだろう。

    それにして、ドメイン名であればまだしも、たかだか1ウェブサービス上におけるアカウント名について商標権を訴えられるとは考えてもいなかった。
    (アカウント名程度なら権利侵害をしてもいいという意味ではない)

    ちなみに2つめの中略の部分には、向こうから提示された条件が書かれていた。その条件というのは

    • 対応に際して一定の金額を支払うこと。

    • Anonymizer社のサービス1年間分無料で提供すること。



    正直、そこで金銭的な関係が発生するとは正直思ってなかった。せいぜい、後者程度かなと。
    この条件提示を受けて、「あぁ、このアカウントそんなに欲しいんだ」と思った。
    と同時に、ぶっちゃけ長い間使ってきたアカウント名で愛着はあるとは言うものの、変更するだけでそこまでしてもらえるならそれでもいいか。
    という考えがよぎり、この交渉に応じることにした。

    上にも書いたとおり、4年間使い通してきたアカウント名をみすみす手放すのは惜しい。ずっとこれでやってきたわけだしね。
    けれど、僕が権利侵害していると言えばそれは事実だし(それがアカウント名までに及ぶかは調べてないし分からないけれど)、僕自身、ツイッターのアカウント名にそこまでこだわる理由もない。
    そして何より正直そんなつまらないことで訴訟なんか起こされてても(お互いに)しょうがない。


    ちなみに現在は @Anonymizer のアカウントAnonymizer, Inc. が既に使用しているらしい。先方が行ってくれるという誠意条件のところはまだ連絡を取り合ってる最中だけど、社長はお忙しいらしく返信は2日に1回くらいの頻度でしかもらえていない。正直、本当に条件を守ってもらえるのかも現在においては不明…。っても、こんな事で向こうが最初から嘘をついてもしょうがないと思うので今のところ信じてます。


    こんな事があり、現在は @anon5r というアカウント名に変更してます。
    @anon5r というアカウント名も anonymizer という語の一部をNumeronym (ヌメロニム)で省略しただけなんだけれども。
    欲を言えば、ホントは @anon (現在取得されている)が使いたいんだけどねぇ…。


    何故こうなった!いや、僕がアカウント名を使ってたからなんだけどね。でも、いい悪いとかは抜きにして、Anonymizer社がここまでしている理由は正直よく分からない。

    先日、アカウント変更直後に anonymizer でググってみたら、日本語での検索結果で3番目、英語でググってみて2ページ目の3番目に僕のツイッターアカウント名が出ていた。
    なのでそういった意味でもAnonymizer, Inc.にとっては魅力的だったのかもしれないし、まったく見ず知らずの訳の分からない日本人がろくでもないことをつぶやいていたりして気にしていたのかもしれない。

    また別の見方として、Twitterにおけるアカウント名が企業にとって重要なものとなってきていること、そして何より、Twitterそのものが企業にとって重要な情報発信媒体となってきていることが言えるのではないかなと感じた。



    最後に念のため申し上げておくと、僕はドメイン名紛争問題などにおける企業名や商標名などのアカウントを取得して、売るといった目的でアカウントを利用していたわけでは決してないことを付け加えておきます。
    今回のケースでは先方の好意もありこのような結果となりましたが、全ての企業がこのような対応をされるとも思いませんし、それ以前に既に命名などにおける権利を保有している他者への侵害目的でのアカウント名またはスクリーン名の利用はTwitterの利用規約に反することになり、その旨の対応がTwitterにより行われる可能性がありますのでその旨ご注意ください。
    (この利用規約については僕は十分理解しないままずっと使い続けてきてしまい、最近この問題があって規約を読み返したとき、初めてこの規約について気付いたので…)


    以下、変更と追記

    2011年1月31日 13時32分

    先方からの条件を具体的に書いてしまっていたのを抽象的にした。理由はこれを前例として似たような問題の発生と、それに対する対価基準がこれ。といった事例が事例が増えるのを避けたいため。

    追記として、僕がアカウント名に anonymizer というIDを使っていた理由は、実際に Anonymizer.com のサービス名に影響を受けていたという事実があります。
    (ただしAnonymizer.comや同社に対してどうこうしたいという考えは全くありません)
    また、"Anonymizer" という単語は実際同社による造語であり、一般的な用語ではないというのも事実。

    僕の中でそういった経緯もあり、今回の対応をとりました。
    元々に自分で考えた(つもりであった)名前が、今回のような問い合わせがあったとしたら、別の対応を取っていたかも知れません。


    2011年1月31日 17時13分

    Twitter社における、商標権に関するポリシーを明言しているページへのリンクを追記。

    NGINXのSecureLinkモジュールを使ってみる

    突然ですが SecureLinkモジュール とはなんぞや、というところですが、簡単に言うと、サービス登録時のメールアドレス確認で、下記の様なメールで見たことがあるような、一定時間のみ有効な時限式URLの認証機能を提供するモジュールです。 通常このような機能を作成する場...