トップ画像について | 著者について | この日記のはてなブックマーク数

CAPTCHAを使わないspam判定 このエントリをはてなブックマークに追加

2010/01/16 土曜日 - 09:33:08 by かなだ

私はspamよけの専門家ではないので、この方法に欠点があったり、すでにある技法でしたらすみません。実際に導入してみたところ、1日300くらい来てたspamがぱったり止んだので紹介することにする。

私はCAPTCHAはあまり好きではない。あれは私の脳を多少なりとも浪費させるし。誤判定すらある。

あと、普通のクイズ形式のCAPTCHAとかアホかと本気で思う。人間が機械に使われてどうする。

Googleなどではしかたないと思う。Googleだけをターゲットにするspammerがいるので、普通の対策はほとんど意味をなさない。

しかしうちのような一般のBlogに対する無差別なspam行為に対してはどうだろうか?個人BlogにCAPTCHAは大げさすぎる。そこが有名サイトであるとか、DoS攻撃に遭っているならともかく、ごく単純な方法でspamよけは可能。「アルファベットのaを入れてください」とでもしておけば、spammerはとたんに静かになる。そもそも逆チューリングテストってのはそもそもその程度のものでいいはず。

しかし私はこの方法を望まない。aと打つのが面倒だからだ。そこで逆の発想を取ってみた。トラップの入力エリアを用意して、そこにspammerが打たないような文字列を打ち込んでおくのだ。

spammerは、トラップと本文欄のどちらが本文かわからないのでおそらく両方にspamメッセージを残していくだろう。しかし、私が作った仕組みは、トラップを編集すると投稿できなくしてある。

実例はコメント欄に実装してあるので試してみて欲しい。単に渡ってきた値をみて、spam trapと言う文字列がなかったら蹴っているだけのことある。

これで、3日間で1000通はきていたspamが1件(手入力?)に減った。

仕事の流儀~浅川 智恵子編を観て このエントリをはてなブックマークに追加

2010/01/13 水曜日 - 11:13:04 by かなだ

以下、視覚障碍者と書きますが、基本的に識字困難者(かつて文盲と呼ばれた人)たちも含むと思ってください。両者を含むと地球の人口の相当な数がこれにあたります。

今回のプロフェッショナル - 仕事の流儀は視覚障碍者のアクセシビリティの研究家、浅川氏だということで録画して今朝観ました。

浅川氏は小学生の時プールの縁に目をぶつけただけで、原因不明のまま全視力を失ったそうで、視覚障碍が(視覚的な)健常者とは遠くない話であることを実感させられました。他人事ではないのです。

詳しくは省略しますが浅川氏のモチベーションはすごいもので、障碍者に対する教育が十分ではなかった当時、よく途中で挫折しなかったものだと思います。

浅川さんの基礎研究は一言で言ってしまえばWebの読み上げ技術、視覚障碍者のWebへのハードルを下げることを目的としているようです。彼女の開発しているソフトウェアは、リンクは男声、一般テキストは女声で読み上げる、文節区切りでじっくりと読むなど、健常者にはなかなか思いつかないところにまで配慮が行き届いていていました。

浅川さんの所属しておられるIBMではソーシャルアクセシビリティという研究もなされていて、CGM的にコミュニティがアクセシビリティを向上させていく、アクセシビリティの高いコンテンツには人が集まるという正のフィードバックに関しても研究しているようです。

これを観ていて真っ先に思いついた単語が情報デバイドとデジタルデバイドです。今後、情報がデジタルで流れるようになっていく過程で、アクセシビリティの低下はデジタルデバイドと情報デバイド(デジタル社会においてこれらは表裏一体)を生みます。視覚障碍者は一般の紙媒体を読むことが基本的にできません(OCRリーダーのようなものはありますが)。これがデジタル化するということは、音声情報への変換も容易になり、情報デバイドの縮小に貢献するはずです。実際Kindleは視覚障碍者に30万冊の書籍へのアクセスを可能としました。これはすごいことです。

他方Webはといえば、インターフェイスに凝る一方で着実にアクセシビリティを低下させています。元来HTMLは文書構造記述フォーマットであり、むしろ視覚障碍者へのアクセシビリティの方が高いくらいでないといけないはずですが、フレームやテーブルの濫用、画像の多用、Ajaxなどの動的コンテンツなどにより本文へのアクセスが困難になっています。現在のデジタルコンテンツはWebなしでは成立しないと言ってもいいくらいですからこれでは本末顛倒です。

デジタルには、情報デバイドを縮小する使命があります。これを拡大するものであってはなりません。この番組をみて私は奇妙な感覚を覚えました。この人たちはなぜこんなに苦労しているのだろう? なぜ読む側がこんなに頑張らなきゃならないのだろう?

コンテンツ提供者はアクセシビリティに対してもっと配慮すべきです。バリアフリー社会というのはそうあるべきでしょう。他方で浅川さんは視覚障碍を持つ張本人であるにも関わらずバリアフリー社会の実現に尽力していらっしゃる。これでは順序が逆ではないですか。

スロープという概念がない社会で、階段を登るために、四肢障碍者の方が車椅子が階段を登る装置を開発している。残念ながらWebの現状はこれと同じようなものであると言わざるを得ません。

実のところ駅のスロープにしても国のガイドラインありきで行われているわけですから(多分)、そういったガイドラインのないWebにそういうものを求めるのは無理があるかも知れません。私は自浄作用を望みますが、どうしても無理ならば国は公的資金をWebのバリアフリー化に投資すべきだと思います(既にしていたらすみません)。

私は浅川さんのすごさに非常な感銘を受けましたが、Webが障碍者への情報デバイドを広げている現状を目の当たりにしたようで、そちらのショックの方が大きかったです。

2009年エントリまとめ このエントリをはてなブックマークに追加

2010/01/05 火曜日 - 06:48:55 by かなだ

2009年のエントリの中で人気が高かったものを列挙して行きます。

まあタイトルそのまんまなんですけどね。変数名には意味のあるものを付けましょう。テストスクリプトなんかでハマりがちですが、$fooとか$barを推奨します。

これはお勧めします。電波が届かない環境でもWikipediaがオフラインで引けるようになります。ただ32GB〜ユーザーじゃないとメモリがきついかも。

裏は取れてないですが誤報だったように思います。すみません。

概してsaltのかけかたは甘い傾向にあります。ユーザー数が多いと固定文字列saltは十分攻撃対象に成り得ます。最近の情報漏えいではMessageDidgestも取っていなかったところもあるようで。気をつけましょう。

CatalystのChainedというディスパッチ法について。私はLocalよりもこっちの方をお勧めします。モジュール分けをきちんとしないと訳がわからなくなることがあるのでそこだけ注意。

CoroとAnyEvent::HTTPを使うとこんなに簡単に非同期クローラが作れますよ、と。forkでクロールするのと効率が段違いなのでだまされたと思ってお試しあれ。

XS解説シリーズです。だんだん難しくなりますが、Cを覚えながら順に読めばXSとはなんぞやというのがなんとなく分かってくるはず。

Coroの分かりにくい概念を、実際に動作するスクリプト例で実感してもらおうというものです。並列ってそういうことか、とわかるようなスクリプト例を3つ用意しています。

Time::HiResでオーバーライドされるtime()関数は使い物にならないので気をつけましょう

Perlの日本語ドキュメントポータルを何とかしようという提言ですが予想以上の反響を頂きました。実際に現在プロジェクトは進行中でございます。提示してあるURLで議論が行われているので興味のある方は是非。多分これが今年一番反響の大きかったエントリです。

Plack(PSGIの実装)を使うと、コードの扱いが非常に楽になるということが端的に分かる例。Plackの必要性にピンと来ていない人は是非

書いていて思ったのは、Coro, AnyEvent, Plackなど流行の技術には人気が集まるという点。他方、KindleとかWebSocketsみたいにまだブレイクしていない概念や技術は反応薄いなーといった感じ。まあKindleの世界を変えてしまいそうなポテンシャルは手にとって見ないと分からないのかも知れない。

あと書いてよかったなと思うのがPerlDocJP/perldoc.jpの改善についての議論。これがうまく行けば必ずPerl界はよい方向に進むと思っています。これについては現在も議論・開発が継続していますので、興味のある方は是非参加をお願いいたします。

今回ですます調がちゃんぽんになってお馬鹿な文章になってしまいましたが直す気力がないのでとりあえずポストします。

4ヶ月で2年分の学習効果?Blogエントリ駆動型勉強法 このエントリをはてなブックマークに追加

2009/12/28 月曜日 - 07:29:54 by かなだ

さて、年末も押し迫り、早朝覚醒でやることもなく、かと言ってコードを書くほど覚醒していないので自分がなぜエントリを書くかについて触れたいと思います。

まず過去ログを見て驚いたのが、僕は今年、9月下旬からくらいしかまともにBlogを書いていなかったことです。実は僕は去年から不況に重ねて深刻な不振に陥り1年くらいコード書いてなかった(Perlに至っては2年書いていなかった)のですが、そこにPerlの案件が天使の羽のように舞い降りてきてまたPerl界に復帰したのです(感謝しています)。それが9月頃なわけです。なので色々偉そうに書いていますが実はこれらは、僕が2年の間に完全にPerl界から遅れてしまった分を取り戻すための闘争記でもあったわけです。

ただ僕の性分として「勉強中」を標榜すると甘えた記事しか書けないので、あえて前から知っていた技術を披露してやるぜ!みたいな体裁を取っています。そうすると嘘や間違いは絶対書けないですから(まあ書いちゃいますが)ものすごく裏を取るわけです。そうやってわざと自分を追い詰めるのが自分のやりかたです。

ぶっちゃけて言うと、極端な話、エントリのタイトルを書いた時点では僕はそれについての知識が全くないことすらあります。まず大枠をつかんでからエントリを書きはじめ、不明な点が出たらそれを徹底的に調べて理解してそれを書き、矛盾を見つけては調べの繰り返しで練上がったエントリがいくつかあります。

1つ良くできたエントリを書こうと思ったら、結局はそのことについて完全に理解する必要が出てきます。僕は基本的にコードを載せる時は検証可能なコードしか書きません。例えばマニュアルから例を引いてきてこんなことができるんだよ、ということは一切しません。マニュアルの例は動作しないことがあるし、丸写しでは何も理解していない可能性だってあるのです。

僕は大抵の場合自力で検証用コードを書きます。どんなにコードの書き方を高尚に書いても、それで実際コードが組めなければ技術ブログとしては価値がないと思っているからです。検証用コードはエントリの内容の確実な裏打ちになります。そしてcode snippetには大きな需要があるので社会貢献にもなります。

そしてなにより、コードを書くに勝るコードの学習法はありません。エントリで検証用コードを書く習慣はそれを義務づける行為となります。

僕はこの、「知らないことを知っている人と同然に書くことで知っている人と同様の知識を獲得する」手法をエントリ駆動型勉強法と呼ぶことにします。

知らないことを知った風に書くとどうdisられるか分からない、その恐怖感が僕のエントリを正確にします。だからdisられるのが平気だったりそうなっても構わないという性格の人にはこの方法は向かないでしょう。私はエントリの間違いを指摘されると、自分を恥じるとともに間違えた原因を徹底的に考え、同じ過ちを繰り返さない対策を練りだし自らを厳しく律して次のエントリに望みます。エントリが少しでも正確に近いこと、これはこの学習法で一番大事なところかも知れません。

「なんだ素人のエントリか」と思わないでください。書き始めはそうかもしれません。しかし書き終わった直後の僕はおそらくは「ちゃんと知っている人」になっているはずです。もしそうならば、そのエントリは「ちゃんと知っている人」の文章になっているはずです。

最近の私のBlogに運用実績などの話が少ないのは、そういった理由もあります。

Blogを書くことには他の副作用もあります。実際にはこっちがメインでしょう。既に書いていらっしゃる方は経験済みでしょうが、知っているはずの知識が、文章化すると矛盾を生じ、調べてみるとちっとも分かっていなかったという現象です。文章は論理ですから論理の立たないものは破綻した文章にしかなりません。そこを自分で見抜く目を持っているのなら、文章化することで自分の知識を系統立て、矛盾があればそれは即座に明らかとなり、事故を起こしたり大恥をかいたりする前に自力でそれを修正することができます。

私はこのBlogを公共の利益のために書いていますが、それが同時に自分の知識を深める行為につながっています。「情けは人のためならず」ってやつですね(違う)。

このエントリもまた、「書く」という行為の大事さを啓蒙すると同時に、僕はなぜBlogを書き続けるのかという動機についての内省にもなっているというわけです。

しかしよくもまあ本当のことをぶっちゃけたものだと思います。これを読んで今までのエントリに関して失望した方がもしあれば本当に申し訳ないと思ってます。

perldocjp / new_perldocjp懇親会ご報告 このエントリをはてなブックマークに追加

2009/12/27 日曜日 - 09:02:46 by かなだ

そういえばBlogで報告すると言っておきながら完全に忘れておりました。開催は10日以上前になってしまうのですが、その時MLに投げた報告書をまるまる掲載してご報告に代えさせて頂きます。

なお、条項に自動翻訳の活用が盛り込まれていますが、これは小飼氏の立案で、最初、場の全体が凍りつきましたが、問題点などを皆で洗っていったところ、終にはアリではないかと素案に残ってしまったというものです(決定事項ではないです)。

先日行われた懇親会の報告をいたします。

先日は、コアのメンバーの方に大勢集まっていただき、 大変感謝しております。お忙しい中無理に来て頂いた 方も多く、申し訳ないと思うとともにとても嬉しく思って おります。ありがとうございました。逆にコアでない方 の参加がなかったのが少々残念に思います(あくまで 今回は懇親会でしたので)。

このことは私がこのプロジェクトを進めていく上での大変 なモチベーションとなりましたし、私が主張していることの 妥当性についての私にとっての貴重な裏づけにさえな りました。このプロジェクトは、昨日を以って本格始動した ような気さえします。

また後半ではPerlDocJpの話から外れ、色々と面白い お話が出来て楽しくすごせました。

やはりバーバルオンリーの場ではなく、直接お会いして 色々をお話する重要性を再認識致しました。 ご多忙かとは存じますが、3,4ヶ月に一度とか頻度を決めて、 定例会のようなものが実施できたらなと思います。

以下に懇親会で出たプロジェクトに関する話題について まとめておきます。

なお不覚にも書記をしていなかったため、記憶に頼ってい るので間違っている部分、抜けている部分等あると思いま すがご容赦下さい。また、二次会以降での話も混じってい ますので、懇親会で出ていない話題も入っていますがご 容赦下さい。

  • 大筋では私のエントリhttp://kaede.to/~canada/doc/newperldocjp-and-me で問題ない
  • プロジェクトリーダーは私が続投します。正直向いていないが、ほかにしてくれる人がいないため。
  • ただしコードベースの管理は牧さんが担当。私が不慣れすぎて不適当なため(牧さん申し訳あり

 ませんでした)。

  • Gitを推していたが、svnで十分ではないかということ。分散型の危険性について。
  • 課題が多すぎてプロジェクトが前に進めない可能性について
    • 現在の2つのポータルがうまく稼動していないこと
    • pod2htmlについて
    • perldocが日本語を通さないことについて
    • Pod2::*への対応について
  • 閲覧ポータルを先にやり、翻訳を次にする方針は続行。閲覧ポータルによって間口を広げ、翻訳

 者を集める仕組み

  • 集客については私がこのプロジェクトについて執筆する話を取り付けてあるので、そこからもある

 程度望めるのではないか

  • 「みんな真面目すぎ!もっと楽することを考えよう」 - 小飼弾氏
  • お金を支払っての翻訳について
  • Wikiベースの翻訳ポータルについて
    • まだWiki型にするとは決まっていないが、やるとしたらの話
    • オープンにはしない方向?(ID制)
    • 閲覧ポータルと間口を同じにし、閲覧ポータルの客を翻訳に引き入れる(Wikipedia型)
    • 未翻訳についてはsearch.cpanをミラーしてもよいが、粗訳を自動翻訳に任せるのもあり
    • 自動翻訳については翻訳の著作権の絡みで懸念あり
    • モジュールのアップデートについては、diffを取り差分を翻訳するというアイデア

とりあえず今思いつけることをつらつらと書きました。おそらく足りていないところがたくさんあると 思うので、参加者の方、補完していただけると助かります。

それでは皆さん、お疲れ様でした。