Wikipediaの荒らしとの戦い「56人の管理者vs人形使い」
さて、前の記事では知られざるWikipediaの内幕である管理者たちについて紹介しました。彼ら管理者の地道な活躍によってWikipediaの記事の質は今のレベルに保たれていると言っていいでしょう。しかし管理者がいるということはその逆の存在、つまり「荒らし」も相当数存在していると言うことです。 中でもすさまじい例になると、ホンモノの「人形使い」と呼んでもいいくらいのレベルの恐ろしい荒らしもいるわけで。 では、Wikipediaの荒らしとの戦い「56人の管理者vs人形使い」を見てみましょう。 見つけたのはこれ。スチュワードについて調べている最中に見つけました。 利用者:Suisui(今泉誠)は卵かけご飯が好きなプロ市民 - Wikipedia このページの最下部を見ると、「Peaceの操り人形だと疑われるユーザー」「操り人形だと疑われるユーザー」と書いてあります。見てみましょう。 Catego
Wikipediaの舞台裏「Wikipediaの管理者」とは？
先の記事ではWikipediaの誕生秘話として、その過程を見ることでどのようにしてWikipediaから今のWikipediaたりえるようになっていったのかという事実を、Wikipediaの前身である「Nupedia」からネット上での各種意見に至るまで、様々なものを見ることで経緯をたどりました。 次はこのWikipediaを裏から支える「管理者」の存在についてです。Wikipediaは決して誰もが勝手に書きまくって編集しまくってそれで質を維持しているわけではなく、その質を維持するために裏で支えている人々が少数ですが存在しているわけです。 今回はそのあたりを見てみましょう。 まず、これが管理者です。 Wikipedia:管理者 - Wikipedia どうすれば管理者になれるかというと、以下の通り。 現在のウィキペディアのルールでは、しばらくウィキペディアの更新をしており、ユーザー名がある程
フリーな百科事典「Wikipedia」誕生秘話
現地時間で2007年1月15日、Wikipedia（ウィキペディア）は6周年を迎えました。 が、このWikipediaの前に「Nupedia」（ヌーペディア）というのがあったことはあまり知られていません。Nupediaが開始されたのは2000年3月。今のWikipediaと違い、専門家（基本的に博士号を取得していることが条件）によるフリーな百科事典を目指したものだったのですが、ほとんど記事が投稿されず、2003年9月に停止しています。2000年3月から2003年9月までに掲載された記事はわずか24本。というのも、専門家による査読制度が非常に厳しく、7段階もの過程を要したため。そういう一切を省いたWikipediaの方がいかに優れた仕組みだったのかがよくわかります。 しかし、本当は「Wikipedia」というのはどのような経緯で今のような形になっていったのでしょうか？そして、Wikipedi
[ThinkIT] 第4回：Wikiによる情報共有 (1/4)
半年後には情報どころかライブラリさえ時代遅れになってしまうようなWeb系の企業では、社員の技術レベルの向上や「共通認識」を持つことが非常に大切です。社員の技術レベルは教育などを通して向上することが可能です。では共通認識を持つにはどのようにしたらよいでしょうか。 一般的に従業員同士などの共通認識を作るには「コミュニケーション」や「情報共有」が非常に重要となります。その手法として、社内メーリングリストやグループウェア、時にはバグトラッキングシステムなどが共通認識を作る場として利用されることもあります。それらのツール中でも、最もよく利用されているものが「Wiki」です。 そもそもWikiとは、Web上で誰でも編集できるという特長を持つCMSです。インターネット上に誰でも編集できるWebサイトを作り、テーマにそった情報を書き込んでいくというのが一般的な利用方法です。また自分以外の人が編集できないよ
徒然なるままにBlog - Apacheチューニング: ロギングを高速化する
あまり知られていません(と思われる)がApache2(2.0.41以降)にはアクセスログの書き出しをメモリにバッファリングし高速化させるという機能があります。 今回はその機能を有効にするとどれぐらい速くなるのか調べてみました。 設定方法はhttpd.confに BufferedLogs On と追加するだけでログのバッファリングが有効になります。 以下ベンチマークを取った結果です。 バッファリング無効984 Request/Sec バッファリング有効1033 Request/Sec (参考)ロギング無し1055 Request/Sec ※小さなhtmlファイルに対してab -c 100 -n 1000を何度か繰り返した結果の平均です。 体感では違いを感じられないとは思いますがベンチを取るとおよそ5%程Request per secondの値が上がっていました。 静的なファイルが
マルチ・スレッド（multi-thread）プログラミングの落とし穴、その１（かもしれない）
ここのところ技術系ブロガーの間で話題になっている、「C10K問題（参照１、参照２）」は、ひとことで言えば、多くのウェブ・サーバーで採用されているmulti-threadやmulti-processに頼った（もしくは頼りすぎた）多重処理というアーキテクチャーのスケーラビリティに対する極めてまっとうな警告である。 この話は、決して最近になって始まった話ではなく、パソコン業界ではパソコンのOSにpreemptiveなマルチタスクが導入されはじめた９０年代の前半から、さらに遡ると、DECを中心にテクノロジーが進化したミニコンの時代から、ソフトウェア・エンジニアたちの間で盛んに討論されてきたテーマである（さすがに、メインフレーム時代の話は私は知らない）。 十数年を経た今でも、いまだに決着が付いていないこの問題は、私の大好きなテーマの一つでもあるし、もし私が博士号をこれから取得しようとするのであれば、
タグとオントロジー
タグとは何か del.icio.usのWhat are tags?から ブックマークなどを整理したり後で思い出すために、自分で自由に与える1語の説明 タグは階層がなく自由なので、あてがいぶちの分類に無理に合わせる苦労がなく、扱いやすい ほかの人のタグと合わせて、関心事項についての協調型レポジトリを構築できる 統制されない自由なキーワード 手軽に利用でき、新しい現象もすぐタグにできる 既存の統制語彙では新しい動きに対応できない 一方、多数のユーザが与えるキーワードには、同義語、多義語が必然的に含まれる 体系化のないフラットな空間 階層ではなく、キーワードの組み合わせで詳細概念を柔軟に表現 一方、階層を利用したグループ化や関連概念の検索はできない 統計的なグループや関連付けはある程度可能 タグのかたち 対象、ユーザ、キーワードの3大要素 タグは、タグを与える対象、タグを与えるユーザ、タグに用い
about:config - Firefox - index
Firefox など Gecko 系のブラウザでは、ロケーションバー（URL を入力するところ）に「about:config」と入力したときに出でくるページ(?)を通して、色々と設定を変えることができます。 このページは、about:config について説明している About:config entries の内容を私の独断と偏見で編集したものです。項目数が非常に多いため、いつ完成するかわかりません。また、内容の正確性については無保証であり、自己責任で利用してください。英文を読める人は上記サイトを直接、参照したほうがいいでしょう。（とはいえ、mozillazine のページもその内容に関する保証はありません。） 内容を一ページにまとめるのは困難だと判断したので、いくつかのページに分けて説明しています。例えば、bidi.browser.ui の情報を見るには、bidi.* と書かれたリンク
inforno :: キーボード派のWindows開発環境
そういえば、こういうサイトに定番っぽい開発環境を書いたのがないので、自己紹介？も兼ねて晒してみます。 開発はだいたいWindows上のvmware(Debian)でやってます。ただし、そこは定番どころばっかりなのでパス。まぁvim+screen+zshです。puttyでつないでますよ。sambaでマウントしてますよ。ええ。それぞれ結構設定しまくっていて、グローバルなSVNサーバーにおいてあります。 Windowsでの開発環境 あんまりWindowsは好きではないけど、Macよりは好きだったりする。というわけでWindows。普段使いのOSでもあるので、主に自分用の小物を書くことが多いです。怠け者なので、自動化できるものはすぐプログラムに置き換えちゃいます。でも言語は結構様々。もとから言語にこだわらず、一番適しているものを使う主義なので小物が多いにもかかわらず、言語は結構多いのかも。 今のと
早く、安く、確実に！ すべてを実現することが可能
早くユーザビリティ評価を終えられれば終えられるほど、デザインプロセスにもたらされる影響は大きくなる。時間のかかる手法は、年に一度のユーザビリティ検診で採用すべし。 Fast, Cheap, and Good Usability Methods: Yes, You Can Have It All by Jakob Nielsen on January 2, 2007 コンサルティング業界では古くから“早く、安く、確実に! ～いずれか２つを選べ～”と言ってきた。何かを短期間でかつ安く仕上げたいならば、質を諦めなければならないし、短期間でかつ上等な仕事をしようとすれば、料金がかさむことになる、といった意味である。多くの分野で言い得てはいるものの、ユーザビリティのある重要な側面、“方法論”については含意されていない。 ユーザビリティに関しては、もっとも迅速で、もっとも安価な手法こそが最良の選択とな
ユメのチカラ: どうでもいいプチ蘊蓄、i18nの話
読者の皆様、これはブックマークだ。 baccus-dのブログを見ていたらi18nのお話が出ていたので、i18nの起源というプチ蘊蓄を語る。 この起源についての質問はインターネットでも時々間欠温泉のようにわきあがるいわばFAQみたいなものなのだが、90年代初頭にはつかわれていたとかいう証言がえられるが、なかなか起源まで行きつくものは少ない。 これはずばり85年頃のDEC (Digital Equipument Corporation) (後にコンパックに買収され、その後コンパックはHPに買収された)にScherpenhuizenという人がいて、彼のマシン(VMS/DECNET)名にS12Nという名前をつけていた。当時のVMS/DECNETはノード名の制限が6文字だった。なんでS12NかというとScherpenhuizenという名前は最初のSから最後のnまでに12文字あるからである。 この長い
秋元@サイボウズラボ・プログラマー・ブログ: Google AdSense規約改訂に関する続報
Google AdSenseの規約がさらに窮屈にで紹介したブログJensenseで情報のアップデートがされた。 Google AdSenseチームへ問い合わせて、今回の新ルールからはっきり読み取れなかったところを確認したということ。 それによれば、AdSenseに類似のデザインで別会社の広告を併用することが禁止されたのは確かだが、過去にあった「他社のコンテクチュアル広告を並べてはいけない」というルールについては、逆に無くなり、違反ではなくなった、という確認がされている。 # 有名とはいえ一ブロガーのブログエントリだし、AdSenseをビジネスの糧にしているような人はご自分で確認をされたし 日本ではAdSenseが圧倒的だと思うが、ブレイナーなど他のコンテキストマッチ広告や、いずれ上陸するかもしれないYahoo!のYPN(といっても、現時点ではYPNの規約の方にAdSenseとの共存を禁ずる
CNET Japan Blog - 江島健太郎 / Kenn's Clairvoyance：Lingr and Comet - 技術解説編
さて、お待たせしました。いよいよCometとLingrについての技術解説です。 ■Comet解説 さて、まずはCometとは何で、どういう背景によって生まれたのか、についての解説から始めます。 まず前提として、Webアプリケーションにおいては、通信開始のトリガーは常にクライアント側が握っています。つまりURLを入力したりボタンをクリックしたときなどに通信が発生することになるわけですが、このようなアーキテクチャは、サーバ側で発生した変化をリアルタイムにクライアント側に通知することが原理的にできないことを意味します。 チャット・アプリケーションでは、複数のユーザから不定期にメッセージが送信され、それが他の参加者に一斉に配信されなければなりません。しかし、メッセージを受け取ったサーバ側では、それをクライアントに即座にプッシュで通知する方法がないのです。 そのため、一定期間ごとにブラウザがサーバに
フォームの入力値をリアルタイムにバリデーション「Realtime validation」:phpspot開発日誌
Realtime validation using Ajax Ajaxなどを駆使して、入力値を動的にチェックするライブラリ、realtime validation を公開しました。 >> http://masuidrive.jp/validation 正規表現とメッセージを指定するだけで、入力した瞬間にユーザに対してガイドメッセージを表示させる事ができ、今までの様に画面遷移後にエラーが出て、ユーザがエラー位置を把握しづらいと言う事がありません。 フォームの入力値をリアルタイムにバリデーション「Realtime validation」。 prototype.js と、配布している validate.js を読み込んだあと次のようなコードを書くだけ。 Validator.register({ "#mail" : { "/^([^@\s]+)@((?:[-a-z0-9]+\.)+[a-z]{2
水の飲みすぎには注意しましょう。 : ひろゆき＠オープンSNS
【教えてくん】コミュニティーなのです。 なんかニュースとかあったらここに書こうかと思ってますよ。とりあえず、おいらのブログ 水の飲みすぎには注意しましょう。 昨夜、友達が来て、XBOX360をやってたりしたのですが、 その友達が、「水の大飲み大会」というのがアメリカで行われていて、 7.6リットル飲んだ主婦が水中毒で亡くなってしまったとか言ってたのですね。 「まぁ、7リットルが致死量だとしても、水だったら結構飲めるでしょ。」 なんて、話になり、おいらが水をひたすら飲んでみることになりました。 0.9リットルの瓶に水を入れて飲んでいたのですが、 0.9リットルならそれほどつらいということもないのですが、 のどが渇いてないのに無理して飲むのは飲みづらいなぁ、、という感じ。 んで、1.8リットルまで飲むと、かなり飽きてきます。 飲めないことはないのですが、もう飲みたくない気持ちでいっぱいです。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
秒速にちゃんねる:子供を見る親 - livedoor Blog（ブログ）