おごちゃんの雑文

www.shortplug.jpをAWSに引っ越しました。

今のうちのサーバ群でパワーがどうこうということはないのだけど、今後アクセス増えたりした時に、ハードを一々買うというのもダルいのと、どうやってもタイムラグがあるということで、思い切ってAWSに載せることに。ウェブサービスでありがちの、「リリースアナウンスした時に凄いトラフィックが来るけど、数日したら閑古鳥」みたいなのにうまく対応しないことには、せっかく作ったものがムダになってしまいかねないし。

しばらく練習を兼ねて、あれやこれややっていたのだけど、とりあえずは運用出来る程度のことは大丈夫になった。まだ、AWSに最適化してはいないのだけど、あまりベタに最適化してしまうのも厄介の元なので、まぁ程々に。

自分でインフラ構築してないシステムを使うのは初めてで、いろいろ勝手が違ったのだけど、まぁそんなことは慣れてしまえばどうってこともない。出来ること出来ないこと、便利なことそうでないことを把握してしまえば、思った程は自前のサーバと違う点もない。まぁ、ウェブコンソールが遅いのはかったるいのだけど。

これを機会に、今までPGpool-IIでやっていたレプリケーションは、PostgreSQLネイティブのレプリケーションを使うことにした。これで、突然わけのわからないダウンを起こすこともなくなるだろうと期待。

後は課金がどうなるかだなぁ。

githubから、メールアドレスをverifyしろとゆーメールが来た。

示されたURLをクリックすると、「mails」のところにアラートマークが出ている。どうもこれらしい。

「Verify」とゆーボタンがあるので押す。アラートマークはそのままなので、おそらくverifyのためのメールが来て、そこに書かれたURLをクリックすると… とゆー類の手続きがあるのだろう。とは言え、1時間くらい経過しているのに、まだ何の音沙汰もない。

「メールでverify」の類のことをした直後は、メールのチェックが頻繁になる。届いてなければ、「spamに落ちたかなー」とか思いながらspamフォルダまで覗いたりする。普段見掛けないメールが来るだろうから、ちょっとそれっぽいメールはspamなような気がするものまでチェックしたりする。

つまりどういうことになるかと言えば、

spamやフィッシングへの警戒レベルが下がる

ということになる。普段「spam乙」とか思ってるものまで開いてしまうし、それっぽい送信者であればフィッシングメールまでチェックするだろう。

もちろん、用心していればそういったものであっても、せいぜい「時間のムダ」だけで終わることだ。不用意にメールは開かない、フィッシングは警戒する… 当たり前のことである。でも、メールの送信を依頼したのに届かないとなると、その閾値がちょっとだけ下がる。うっかりフィッシングに釣られてしまわないとも限らない。

仮に私がgithubあたりでフィッシングやるとしたら、

1. githubのアカウントを取る(正規なものでいい)
2. 何らかのアクションを要求するメールを待つ(別にターゲットはgithubに限らないから待つのもそんなに苦ではない)
3. アクションを要求するメールが来たらアクションをして、その時に来るメールを保管
4. 2,3を元にフィッシングメールを作る

ってことをやると思う。多分闇雲にフィッシングするよりも、ずっと成功率は上がる。PayPalなんて、しょっちゅうそんなメールが来るものだから、どれが本物のメールなのか、とっさにわからなかったりする。まぁ、リンク先を見て判断するのではあるけど。

まー、そんなわけで「verifyメール」の類は、実はちょっと危険なものなんではないかなーとゆー気がしている。そもそも、「verifyしろよメール」を受け取った時点で、そのメアドは十分信頼出来るメールだと思うのだが。注文書の類を一方的にメールで送って来るのとは違って、「何らかの認証のための手続き」の一部としてメールを使うことは、もうちょっと注意した方が良いのではないか。

PS.

問題のメールは案の定「一次spamフォルダ」で発見された。ここで落ちるのは、発信者や形式がいかにもspamなものだけなんだが…

ネット上の「人格」って、みんなが人格があると思って相手しているものだったら、アイドルでもボットでも架空人格でも、「人」として扱っていいと思う。

そのためには、「法人」でも「自然人」でもない、第三の「人」の概念が必要だろうけど。

「人」のような形で「人」と同じようにふるまってるんだから、それは「人」でいいんじゃないかと思う。どうせネット上での付き合いで、その「人」にリアルに会うことはとても少ない。会えば「人でない」のは明らかな対象であっても、会うことがないんだから、「人っぽければ人」で十分だし。

とゆーこともあって、Shortplugでは、プロフィールについての実在性については全く考えていません。アカウントについては、社会的にいろいろ問題があるから、場合によっては実在性の証明を求めることが、あるいはあるかも知れないけれど。

Shortplugは機能がたくさんある上に、それを隠そうとしていません。

本当は、いくら機能があっても、それが表に見えないようにしておくのが良いのかも知れません。でも、それはなるべくしないでいます。なぜなら、そういったつくりにすると、一見わかりやすく見えるのですが、ちょっと何かがあると、いきなりわけがわからなくなるからです。

Facebookもかなり複雑ですが、それをいい具合に隠しています。それでもまだ複雑ですが、その複雑さをモロに見せるようにはなっていないので、実際の難しさよりもずっと簡単に見えて、とっつきも良いです。

その代わり、ちょっと何かあると、さっぱり動作がわからなくなります。

「ハイライト」って適当にフィルタかけて、適当な優先度で見ることが出来るようになっていて、自分の関心のあるものを見やすくなってます。でも、それがどんな基準であるか、実のところよくわかりません。

コンテンツやアプリを単位にフィルタかけられるし、それをすぐ設定出来るのはいいんですが、「シェア」とか「いいね」されると、それをスルーして見えるようになります。どうやって止めたらいいんでしょう？

「いいね」って基本機能のままでは、後でまとめて見ることが出来ません。じゃあれは自分のためになってないんでしょうか？

「友達かも？」とか時々言って来るのですが、それどんな基準？ 共通の友達すらいないのに。

等々、無意識に操作できて、それに見を任せていると結構便利なんですが、それで本当にいいのか、ちょっとわかりません。

Shortplugは今もこれからも、そういった機能は多分つけないと思います。Shortplugでは、

使っている人がわかる範囲でしか動かない

とゆー考えを貫きたいと思っているからです。何が起きてるかわかるとゆーことは、気持ち良く使うには大事なことだと思っています。気は利かないけど、愚直に動いてくれるように。

とは言え、無駄に難しくなるのは避けたいので、その辺はこれからずっと改良して行きたいと思います。直感的でない部分とか少なくないし、自分でもあれって思うことあるし。

私の見聞きした話の断片を憶測でつないだことなんで、話半分で読んで欲しい。ただ、個々の事実として語っている部分は事実だ。

また、スキャンダル的な部分を除けば、いろんなプロジェクトに共通することなので、一つの「寓話」として読んでもらうといいかも知れない。

特許庁のプロジェクトがコケたって話はあちこちで語られ、いい話のネタになっているようなんだけど、私が知っている範囲では、そういった綺麗な失敗ではない。
More »

「人を呼ぶ時計の話」という小噺がある。これをふと先日思い出した。なんてことはない、

こっち。こっち

という奴。
More »

デスマ寸前のプロジェクトは無事納品出来た。まだいろいろ問題はあるのだけど、「区切りをつける」ことは大事だ。

件のプロジェクトをやっていると、この客は「デスマ体質」を持っていることがわかったので、そうならないように細心の注意… ってあたりは別エントリにて。

件のエントリのコメントに、頭の悪い反応があったので、あらためて反論… じゃなくて注意しておこう。
More »

説明が面倒臭いんで、今の忙しさを「デスマ」ってことにしてるんだけど、正確にはこれはデスマなんかじゃない。

私が考えるデスマとは、

工程が破綻した結果、
着地点がわからなくなったもの

を言うのだ。「破綻」というのは本当に破綻で、納期を踏み抜いたという程度のものは破綻とは言わない。それは単なる「遅延」であって破綻じゃない。
More »

こないだからVistaを使っているわけだが。

最初はまぁ慣れないせいもあって若干とまどったりもしたけど、半日もしたら別にどうってことはなかった。Vistaは散々いらない子扱いされていることは知っているし、実際今まで入れてみるモチベーションはなかったのだけど、ここ数日はVistaばかり使うことになっていた。

そんなにたいそうなことじゃないけど、率直な感想として

言う程ダメでもないじゃん

と思った次第。
More »

LinuxプログラマとしてはLinuxが動いてくれないと商売にならないので、Linuxも動かすことに。

Linuxは64bitも32bitも使いたいし、DebianもUbuntuも使いたい。そこでVMということになるのだけど、これもなかなか頭痛い。
More »