さくらのVPS|VPS(仮想専用サーバ)はさくらインターネット
さくらのVPS提供開始にあたり(さくらインターネット創業日記)
自分が今お借りしているサーバは、linode.comという米国の会社のVPSです。いろいろおもしろ機能がたくさんあって、コストパフォーマンスもいいのですけど、すべてのアクセスが太平洋を横断して行われるので、レイテンシ(応答速度)が遅くなりがちなのがネックです。さくらインターネットさんでVPSやってくれないかな、とずっと思っていたので、早速申し込んで使ってみました。
申し込み
WEBからフォームに入力して申し込むとメールが届いて、すぐに利用を開始できます。さすがVPSですね。
管理コンソール。linode.comに比べると機能が少ないのでシンプルです。
使ってみた
モバイラーズオアシスのシステムを持ってきてさくっと動かしてみた。期待通りレイテンシが早いので、数字の上ではだいぶ軽くなります。ただ、重い部分は後でロードするとかの最適化をかけてあるから、体感的にはほとんど分からないんじゃないかなぁ。
比較
| Linode 512(Fremont) | さくらのVPS | |
| RAM | 512MB | 512MB |
| ストレージ | 16GB | 20GB |
| 料金 | $19.95 = (1$90円で)1795円 | 980円 |
| レイテンシ | 148ms | 21ms |
| clone機能 | あり | なし |
| DNS | 無料 | 1000円 |
レイテンシは僕のパソコンからping打って測定した時間です。
ほぼ同じスペックのサーバを国内に設置してお値段半分なのだから、さくらさんとてもがんばっていると思います。
回線に関しては、いったい何人を100Mbpsの中に詰め込む気なのかが分からないので、ここは保留。
DNSサーバの価格
linode.comでは、DNSサーバが無料オプションでついているのに対して、さくらインターネットさんでは別途申し込まないといけません(¥1050/月)。VPS1台+DNSサーバだと、2000円くらいかかるので、実はinode.comと同程度のお値段になります。でも、DNSサーバは1申し込みで10ゾーン使えるので、何台かVPSを借りるのであれば、だんだんさくらのVPSが有利になっていきます。
メモリの増設
それよりも気になるのは、さくらのVPSはサーバスペックが固定であること。
linode.comだと、追加費用を払ってメモリを増やしてもらうことが出来ます。このおかげで、モバイラーズオアシスがニュースサイトに取り上げられて一時的にアクセス数が増えた時は、メモリを増やしてもらってアクセスをさばいておいて、ほとぼりが冷めたら元に戻す、というような事が出来ました。サーバ構成を変えずに対応できるのがとても便利です。
さくらのVPSでは、こういった増強オプションがないので、ユーザーさんが増えてきたら、WEBサーバとDBサーバを分割するとか、複数台のWEBサーバでユーザーさんのアクセスを裁くというような技術が必要になってきます。
ユーザー数が100万人とかに到達した時には、メモリ増設では追いつかなくなるので、遅かれ早かれ勉強しないといけない技術ではあるのですけど、5万PVくらいのプチ人気サイトのためにロードバランサーの導入とか、ちょっとめんどくさい・・・
クローン機能
あと、linode.comでは、新しいVPSを申し込んだ時に、既存のVPSのクローンを作ることが出来ます。さくらのVPSだと、新しいVPSを導入するたびに自分でApache入れてRuby入れて・・・というのを繰り返さないといけないのですけど、クローン機能を使うと、今動いているサーバと全く同じサーバをもう一台作ることが出来るので、サーバを増設する時の作業がとても楽になります。
セットアップスクリプトを書くとかすれば対応できる話ではあるのですけど、人間楽なことを覚えるとすぐダメになりますよね(笑)
自分的結論
linode.comの便利機能に慣れた立場からすると、運用が大変そうだなぁ、と感じます。リーズナブルに国内のサーバを利用できる点はとても良いのですけど、機能面で不足が目立ちます。さくらさんなら、きっとすぐ追いついてくるんじゃないかと思うので、しばらく様子を見ておこうと思いました。
ところで、iPhone3GS以降のiOS4(つまりiPhone3以外)では、マルチタスキング画面というのが使えます。ホームボタンを二回押すと、こういうのが出てきますよね。
この画面で、どれでもいいのでアイコンを長押しすると・・・
アイコンを並べ替える時と同様の、プルプル状態になります。アイコン左上のマイナスをタップすると、そのタスクがメモリから削除されます。
例えば、わりとメモリをたくさん消費するHootSuiteを削除するとこんな感じ。
もっとも、iPhone4はメモリが豊富なので、削除しないと困るような目にあったことはありません。適当に操作していたら出来ることに気づいて、意外と知らない人がいるみたいなのでとりあえず記事にしてみました。
最近USBケーブルで携帯電話を充電するのが当たり前になってきて。
ノートパソコンにUSB充電ケーブルをつないで携帯電話を充電することって良くあると思う。出張のときとか。
夜寝る時にパソコン立ち上げておくと、
- 画面がまぶしい
- 勝手にサスペンドして全然充電できていないことがある
- 勝手にウイルスチェックが始まって、ヒュイーン!ってファンが鳴り出す
- 勝手にナントカアップデートが始まって、勝手に再起動したりする。うっかり音を切り忘れていて夜中にファンファーレが鳴ったりなんかした日にはもう!
で、画面を閉じても電源を切らない設定とか、出来るだけファンを回さない設定とかウイルスチェックのスケジュールを調整とか、ググれば全部出てくるんだけど、寝る前にそんなことしたくないじゃない?パソコンの設定を変えるのが楽しいとか何その初心者的対応。
で、そういうのを一気にかっ飛ばして要求を満たす方法。
パソコンをBIOS画面にする。
BIOS画面は、たいていUSBに給電してくれる。画面を閉じたら電源を切るとか余計な機能もついていないし、処理が軽いからファンも回らない。勝手にナントカアップデートが走る心配もなくて超便利なので、そういう需要がある時はお試しあれ☆



仕様書とか提案書にiPhoneの画面を書く時はとっても便利ですので、一度おためしあれ☆
派遣プログラマ時代の思い出が反響いただいているようでありがとうございます。一応言っておくと、本当に経験した話です。書いてない話はあるけど書いてあることはだいたい本当。
ところで、そのラピュタですが、日本企業と外資がくっついて出来た職場だったので、公用語が英語でした。
スタッフの40%近くはインド人で、20%くらいそれ以外の国の人もいて、残りが日本人なので、英語ネイティブを無視して仕事はできない状況です。
日本人がほとんどの状態で「公用語を英語にします」と宣言してしまった会社とはだいぶ状況が異なるとは思うのですけど、英語が得意でもない日本人が英語で仕事することを求められたらみんなどうするかというのはやっぱり面白い気がするので、こっちも書いてみようと思います。
日常
公用語が英語といっても、別に社内で日本語を口にすることが禁止されているわけではありませんでした。お昼休みは、日本人同士で固まって食事に行くので、そういう場面での会話は日本語です。他の国の人たちも、だいたい同じ国の人が固まることが多かったです。少数派の国の人たちは、余りっ子組みたいなのを作ってましたが。
自分、「これってもしかして英語力を上げるチャンスじゃね?」とか思ってインド人のみなさまと食事に行くことを試みたのですけど、相当難しいです。後述するように食べるものが違ってますし、彼らは彼らで食事の時くらい自分たちの言葉で雑談したがるので、居心地が悪くて、結局自分の会社のグループに戻ってきてしまいました。
メールについても、日本語と英語が半々くらい。ただし、公式な連絡(会議の通知とか)については、すべて英語でした。 正確に言うと、元が日本語のメールには必ず英訳がついてくるのに対して、英語のメールに日本語訳がついてくることは原則ない、という感じ。
公用語が英語なので、「英語のメールなので読み飛ばしていました」的ないいわけは許されないことになっています。
とはいえ、大学で掲示板を見てなくても友達経由で試験日程を知っている人がいたように、日本人の同僚が助けてくれるからボ~っとしていても何とかなっちゃう人は存在していました。
会議について
会議は英語で行われます。ルールでそうなっているのもあるけど、会議のメンバーに日本語が分からない人がいるからそうならざるを得ない。会議の進行役の人は、可能な限り英語で議論する場面は減らしたいから、一時間の会議に二時間くらいかけてアジェンダを作ります。半分くらいは使いそうな英語をチェックしておく時間だけど、結果的に議事録ドリブンな会議になったので、これはこれで有益だった気がします。
たまに日本人しかいない会議があると、とっとと日本語で片付けてしまうことは普通に行われていました。予定の半分くらいの時間で終わって、日本語で話したのに議事録だけが英語で残ります。
あと、会議中に話がややこしくなった場合、「ジャストアモーメントね」と話の流れを止めておいて、日本人同士が日本語で話をまとめてしまって、あとでそれを英語で説明するという裏技が普通に使われていました。
職場には、部署に一人か二人、英語のスペシャリストが雇われています。日本語で重要なメールが流れた場合に英語にして再送するのがメインのお仕事ですが、重要な会議の時には通訳みたいな形で入っていただくこともあるし、日本人が書いた英語ドキュメントのレビューをお願いしたりすることも出来ました。
ただし、100人以上のメンバーを一人で見ていますので、おいそれと仕事は頼めません。下っ端は自分で何とかするしかありませんでした。あ。でもたまに言い回しとかは教えてもらってた。
ドキュメントについて
すべて英語で書くことが求められていました。日本語で書かれたものはメモであってドキュメントじゃないみたいな扱いです。 で、そんなこと言われたっていきなり英語のドキュメントなんてほいほい書けないので、みんなどうしていたかというと。1.似たようなドキュメントをコピペする
過去のドキュメントは専用のリポジトリがあって、すべてそこから検索することが出来ました。
そこで、ここから自分の書きたいのと同じような内容のドキュメントを見つけてきて、コピーして、必要なところだけ直せば英語ドキュメントできあがりです。プログラマ同士、ER図とかクラス構成図は世界共通の概念ですから、案外これで実用的な文書ができあがっていました。
2.翻訳サイト
大枠はコピペできますけど、ある程度は英語の文章を書く必要がでてきます。また、英語の文書を読まないといけない場面はもっとたくさんあったので、翻訳サイトへのアクセスは相当多く行われていました。
ところが、こうやって翻訳される文書は、本来社外に出してはいけない書類とか、NDAを結んで入手したドキュメントもたくさん存在するので、それを社外の翻訳サイトにパカパカ貼り付けるのはどうなのよ、というのが問題になります。
そこで、社内に専用の翻訳ソフトサーバが導入され、今後WEB上にある翻訳ソフトは使わずに社内サーバを使うように、とのお達しが通達されます。
これが高いくせに全然使えないんだ・・・ろくな訳ができないことがでないことが知れ渡ると、こっそり社外の翻訳サイトを使う人が続出して、やがて社内サーバはほとんど誰も使わなくなりました。
#個人的には、名詞だけ置き換えて使えばそんなに問題にならないと思うんですけどね。
「Appleの新商品iMogyaの機能について」をそのままWEBに流すとまずいですけど、「Aの新商品Bの機能について」をWEBで訳して、AとBを元に戻せば、別に情報は流出しないですよね。
飲み会
この職場、何が大変かというと、飲み会が大変でした。米国では仕事が終わった後に飲み会なんて考えられないのですけど、日本の職場だし、日本に来ているインド人はたいてい独身だったので、打ち上げくらいは開催することが出来ました。
ただし、インド人の中には菜食主義者の方がたくさんおられます。肉を一切食べない人、ブタが駄目な人ウシが駄目な人、人によって様々。
この時点で、ほとんどの飲み屋さんは全滅します。白木屋とかありえない。
最初のうちは、菜食主義者の人用メニューを用意してもらったりもしていたのですけど、お店としても出せる料理がほとんどなくて困ったメニューになることが多かったので、やがて、宴会は豆腐料理専門店で行われるようになりました。
湯葉をつつきながらビールで乾杯。あ、たまにアルコールも駄目な人がいるので、湯葉を食べながらウーロン茶で乾杯する人たちもいた。
飲みながら英語をしゃべるのは、慣れたら出来るんですけど、豆腐で宴会盛り上がるのはたいそう難しかったです。あれ、今でもやっているのかなぁ・・・

2010-08-19 追記
ごめん、今更なんだけど、見積もりは「60%と90%」じゃなくて「40%と90%」だったような気がしてきた。まあ本質的には大きく違わないんだけど。この考え方の背景はこちらをご覧ください。
システムの納期とは確率分布だ-Publickey(追記終わり)
で、紅茶屋さんが、そうはいっても、最新技術を追いかけ回す企業が旧態依然とした企業より生産性が高いとは限らないよ?とのご指摘。Togetter-「派遣PG時代の思い出」
- 某N社で「メソッドを作ると処理が上下に飛んで可読性が落ちるので、出来る限り一つにまとめてください」と言われたことがある。僕は300行で挫折したが、1万行メソッドを書ききった強者がいた。クラスを作るには申請書が必要だった。
- 「これ参考にしてください」と言って渡されたフローチャートは双六のようで、最後から一つ手前に「仕様変更で振り出しに戻る」と書いてあっても驚かないような代物だった。
現場を変えようと取り組んでも結果として何も変わらないことはよくあります。また、よしんば何か新しいものが導入されても最初の目論見からはねじれた形で運用されてしまうこともあります。それはその通りなんだけど、その筋で考えると結局、一般兵は最新技術なんか追いかけ回さずに軍曹の言うことを素直に聞いてりゃいいんだ、という結論になってしまって、 それだったら結局、件のtogeterのエントリを見て笑っておくのが一番精神的に健康が保てるような気がする。
慣習やしがらみという壁はそれほど厚いものです。オフコンが反対の部屋でいまだ現役でデータをあげてくるのに、自分のまわりだけ新しい体制を導入したのではひっかきまわすだけです。運用教育にまつわるコストは、おそらくWEB系の方々が思われているほど低くはありません。
ITドカタを笑ってすましてちゃだめだろ-紅茶屋くいっぱのあれこれ日記
数百人規模のエンジニアが一つのプロダクトを開発しているのに、見通しのいいコードを書こうとする文化が存在していて、プログラマの見積もりがそれなりに当たるようになる魔法のメソッドが存在した現場の話。ラピュタは本当にあったんだ!

その製品は、外資系の会社と日本の会社が合併して出来た会社の製品だった。ので、本国にもエンジニアがいっぱいいるし、日本にもエンジニアがいっぱいいて、トータル数千人規模の開発じゃなかったかと思う。全容は把握できなかったけど。
過去10機種以上が同じソースコードの上に開発されていて、そこに機能を追加したり、場合によっては既存のコードをいじったり。数機種の開発が並行して進んでいた。
あっちの不具合がこっちの開発に影響したりしないために、機種ごとにブランチが切られていた。
というか、実はブランチがプログラマの人数×数倍存在していて、プログラマはそれぞれ自分のブランチ上で開発ができる、すんごい規模のソースコード管理システムが動いていた。機種コードネーム+社員IDみたいなブランチの命名規則があった。
あとで書くけど全体としてスケジュールはゆるかったから、マスターが動かない時は、動くようになるまで一週間くらい放っておくこともあった。
せっぱ詰まった人が文句言って、当事者か上級エンジニアが直していたのだと思う。末端のエンジニアからしたら、一週間待てば勝手に直るイメージだった。

A:プログラマが見積もりを出す時は、「90%の確率で実現可能な納期」と「60%の確率で実現可能な納期」というのを見積もる。つまり、前者はよほど致命的な問題が見つからない限り実現可能な納期で、後者はたいていの物事がうまくいった場合の納期。
マスターブランチにマージするのは、60%と90%の間のバッファの時期にリリースする事になるから、今日中にリリースせねばならない的な圧迫感のある状況に追い込まれることは滅多になかった。
チームリーダーも、「○月○日がデッドラインだ!」みたいなことは言わなくて、「今月くらいでできあがる時期のはずだから、タイミングを見てリリースしてね。出来たら報告してね」みたいなノリだった。
あと、全体にスケジュールはゆったりしていた。最初、普通に日本の開発現場のつもりでぎりぎりの見積もりを作ったら、「本当にそれで出来る?本当に実現できる数字を聞かせて。見積もりが大きかったら機能を切って調整できるけど、出てきた見積もりが遅れた時はとても困るんだ」と言われた。
でも、競合する日本製品と出荷ペースはあんまり変わらなかった。
理由は分からないんだけど、プログラマをぎりぎり締め上げてスケジュールを短縮しても、いい加減なソースコードを書いたり、どうしようもないプログラマを入れてしまったりして遅れる分が出てくるから、最終的にできあがるペースは案外変わらないのかも。
実際、ドキュメントとかも大量に作られていたし、レビューもしっかり行われていて品質はとても高かった。

A:バグトラッキングシステムが存在して、プログラマと同じ人数くらいのテストエンジニアがいた。
そのテストエンジニアが担当のモジュールをテストして、出てきた不具合をバグトラッキングシステムに登録していた。
プログラマが自分で見つけた他のモジュールのバグをあげることもあった。
ここまでは普通。普通と違ったこと。
1.テストエンジニアは派遣会社から連れてこられた素人じゃなくて、テストの理論を把握していて自分でテスト計画を立てたりなんかできる人が普通にいた。
2.登録されたすべての不具合を解決する文化がなかった。
日本だと、出荷前にはバグを0にして出荷するから、最後の数個はプロジェクトマネージャ権限で無理矢理Closeしたりrejectしたりするじゃない?
これに対して、そもそもバグを0にするという考え方が存在しなかった。バグトラッキングシステムには、常に無数のバグが放置されていた。
もちろん、担当レベルでたいていのバグは直していたし、致命的に困りそうな不具合はリーダーが割り振って修正していたけど、トータルで見ると、重要度の高い方からつぶしていって、納期が近づいてきたら、これくらいでいいかな?的な気分で製品が出荷されていく感じだった。
結果的に出荷した製品に不具合は残っていただろうけど、そのおかげで製品が売れなくなったという話は聞いたことがない。いくつかの機種は日本にも出荷したけど、普通に売れていた。
A:自分は1派遣エンジニアに過ぎなかったから、あの巨大なプロジェクトのコスト構造は分からない。でも何年もそれで回るのだから、コスト超過な状態ではなかったのだと思う。
日本の派遣会社に対するコスト要求はとても厳しかった。外資系で現場は英語がデフォルトだったから、テストエンジニアも普通のエンジニアも、インド人がいっぱい雇われていた。
日本国内で英語をしゃべるエンジニアといったら付加価値つけて高くなりそうなものだけど、インド人と価格競争を迫られるんだから、派遣会社はたまったもんじゃなかったと思う。
でも、現場に出るエンジニアにしてみたら、英語力はぐんぐん伸びるし、無茶をいわれない現場だったから、それはもう天国のようであった。
あと、世界規模で出荷してたから、必然的に予算も大きくなるよね、というのもあったのかも知れない。

A:紅茶屋さんと同じ結論になるのがつまらないのだけれど、結局この職場も、巨大すぎて改善なんておいそれと出来ないという点では一緒なのです。
改善のための提案をすることは可能だし聞いてくれるんだけど、例えば何百万ステップもあるソースコードを何千のブランチに切ってアジアとヨーロッパからアクセスしても動き続けているシステムに対して改善なんて提案できるかという話で。
プロジェクト全体としては少しづつ改善が行われていたんだけど、それは自分のあずかり知らないずうっと上の方でいろんな事に目配りして検討した結果が降りてくるものであって、末端の自分は巨大なシステムの隅っこの歯車みたいな気分でした。歯車としてはとても恵まれた環境だったと思うんだけど。
で、幸せだけどなんだかつまんないよね、と思う一方で、いいめもをはじめとして、プライベートはいろいろ盛り上がっていった結果、やめることになりました。
今思えば、サーフィンが趣味でプログラミングが仕事みたいな人だったら、幸せに過ごせる職場だったんじゃないのかなぁ、と思います。
A:飲みに行った時に聞いてください。でも、派遣(請負w)ですから、自分がいた会社に今入ったからといってその現場に入れるかというと微妙だと思う。あと、同僚や上司と技術的なやりとりをできる程度の英語力が必須です。
ページビューの体感値から一年以上たって、新しい情報も入ってきたので更新してみようと思いました。
前回同様、ググって出てきた数字を鵜呑みにしているので、アクセス数の数え方とか、調査時期によって数倍の誤差があり得ます。数年間全く更新されていない媒体資料ってどうなのよ、という気もするのですが、数字として参考になりそうなサイトなのでそのまま載せました。
数字をクリックすると情報元のサイトにリンクしています。中には、一日単位とか一年単位のPVもあったので、そういう時は30倍とか1/12にして換算させていただきました。
1万PV/月
大手ニュースサイトに取り上げてもらったり、はてなブックマークでホットエントリしたことがある、くらいのレベル。IT系のイベントに出た時にその話をすれば、「あぁ」って言ってもらえる。
「はてな流大規模データ処理」を見てきたがホットエントリした昨年11月で、22000PV/月でした。
その後ここ数ヶ月は、5000PV/月くらいで落ち着いております。
あと、Gigazineさんで取り上げていただいたメイドめーるの最大アクセス数が26,000PV/月でした。
10万PV/月
「一応その分野では名前を聞いたことがある」くらいのサイト。でも、まだ単独で広告を取るのはむつかしいので、広告を出すとしてもアドセンスやアフィリエイト広告が中心。
- AMNの参加基準:5万PV/月以上
- モバイラーズオアシス:7万PV/月
- F.Ko-Jiの「一秒後は未来」:83000PV/月
- [Z]ZAPAブロ~グ2.0:20万PV/月
100万PV/月
直接の広告申し込みが入るようになったり、営業かけて広告を取ってきたり出来るようになる。
- 404 Blog Not Found:125万/月
- 無料占い・おまじないの雑誌マイバースデイ(MyBirthday):100万PV/月(pdf)
- [N]ネタフル:120万PV/月
- nanapi[ナナピ]:250万PV/月
- ZAPAnet総合情報局:700万PV/月
- ドラゴンクエスト9攻略Wiki:350万PV/月
#2009年8月は、4000万PV/月
1000万PV/月
- ITMediaNews:1000万PV/月
- AMN参加サイトをあわせて:1000万PV/月(pdf)
- Gigazine:6155万/月
#2009年に見た時は、4942万PV/月でした - J-CAST:4000万/月
- デイリースポーツオンライン:2400万/月
1億PV/月
誰でも名前を知っているような企業からも広告を取ってくることが出来るかもしれない
- ITMediaのサイト全体で::9000万PV/月
- ZAKZAK:9300万/月
- nikkeiBPnet:1億2000万/月
- MSN産経ニュース:3億9千万/月
- はてな:4億PV/月(2005年)
- pixiv:8億PV/月
#2008年9月で3億PV/月でした - アキバBlog:2億PV/月
#2005年は、870万PV/月
100億PV/月以上
大手自動車メーカーなどの広告が(単独で)出る可能性がある
- livedoor:36億PV/月(pdf。PCサイトのみの数字)
- mixi:150億PV/月(PC,携帯を含む)
- Yahoo!Japan:469億PV/月(pdf)
- アメブロ:121億PV/月
#2008年:69億PV/月
考察
- だいぶ数字感覚ができてきて、100万PVがどれくらい遠いかが具体的に見えるようになってきました。今なら、「100万PV/月くらいアクセスがあるサービスならいろいろ支援もできる」という意味がよく分かります。
- Yahooが36億→469億というのはいくら何でもおかしい。でも、アメブロが69億→120億であれば、おかしいのは去年の数字の方でしょうか。トップページだけの数字を見てしまった可能性が高いですね。
- 広告代理店がある程度PVをまとめて出してくれていることに気づきました。例えばメディアレーダーのサイトで検索すると、新聞社とかmixiとかのPVを見ることが出来ます。
追記
2010-08-07 00:45:32
zapaさんからご指摘をいただいたので、最新のデータを反映しました。データを提供していただいたzapaさんに感謝します。
それにしても、ドラゴンクエスト9攻略Wiki、ページビューが1/10になるとは。攻略サイトは大変ですね。
PETAZINE「GIGAZINEがやられたか...」まで書いてめんどくさくなってやめた。
だめだだめだ、そこであきらめちゃダメだ!もっともっとがんばれよ!
でも、こんなの毎回つくるのはめんどくさそうなので、四天王メーカーをつくってみました。
四天王メーカー

このAPIを使うためには、bitlyにユーザー登録して、APIキーというのを取得します。で、そのユーザー名とAPIキーがあれば、
http://api.bit.ly/shorten?version=2.0.1&login=[ユーザー名]&apiKey=[API Key]&longUrl=[目的のURL]というようなURLにアクセスすることで短縮URLを生成することが出来ます。
問題なのは、このAPIキーをJavaScriptでも使うことが想定されていることで。
JavaScriptで使うということは、ブラウザでソースを見たらユーザー名もAPIキーも丸わかりなのに、堂々と使っている方が結構おられます。
悪用シナリオ1
被害者Aさんが、JavaScriptでbitlyAPIを使ったWEBページを開設していたとします。スパム業者がやってきて、Aさんのページからユーザー名とAPIキーを拾います。
スパム業者は、このユーザー名とAPIキーを使ってスパムページへの短縮URLを生成して、スパムメールに貼り付けて送信しました。
数日すると、このURLはスパムメールであるという通報がbitlyに届くので、該当の短縮URLは凍結されます。
ついでに、スパム生成に使われたAさんのアカウントも凍結される可能性が高いですよね。悪くすると、Aさんはスパムメールの送信者と疑われてしまうかも知れません。
悪用シナリオ2
悪意のある第三者Bが、Aさんのページからユーザー名とAPIキーを拾います。Bは、Aさんのユーザー名とAPIキーを使ってアダルトサイトの短縮URLを生成しました。
Bさんはこういう風に公表します。「あれ?Aさんこんなページも見てるんだぁ!やーい、エッチエッチ!」
Aさんにとって身に覚えのない話ではありますが、自分の生成履歴にある以上、なかなか説明の難しい立場に追い込まれてしまいました。
対策
本来ならば、bitlyがAPIキーの仕様を変えて、登録されたドメイン以外からアクセスがあったらはじいてしまうようになっているべきだと思います。googleMapsとかはそうなっています。
でも、公式フォーラムに出ている指摘を見ると、「そんなのいいじゃない、気になるならJavaScript以外から使えば?」と思う人もいらっしゃるみたいです。
上記のようなシナリオは困るよね、と思う方は、bit.lyのAPIをJavaScriptから直接使うのではなくて、PHPやRubyなどのサーバ側で動作する言語から使うことをオススメします。
[PHP]bitlyのAPIKeyを遮蔽する方法まとめ-RinGoonPOP!!
以前から要望されていた公式retweet機能に対応したり、スキン変更が出来るようになったりしました。あと、UIが日本語対応したのも今回からだっけ。
一気にがらっと変えたので、ついて行けない人が続出しているように見えます。 この手のリニューアルは、大胆にやり過ぎるとユーザー離れのきっかけになるので怖いところですね。 ボクは、しばらくたったら慣れるんじゃないかと思っているのですが。
それはさておき、新UIになって公式retweetが標準になったので、以前みたいにコメントが書けなくて戸惑っている人がたくさんいる模様。以前使っていた非公式retweetが使えるようにする方法をまとめました。
左上のフクロウをクリックすると、いろいろメニューが出てきます。「設定-初期設定」を開いて
「Twitterの公式リツイート」のチェックを外すと、以前と同様の非公式retweetが出来るようになります。
あと、がんばって日本語訳した人には申し訳ないのですけど、ボクはなんだか変な日本語がとても気になるので、言語選択を「English」にして使っています。



