25 posts tagged “work”
SlideShareでご覧いただけます。
このようなストーリーと、社内Wikiならではの要・不要を検討したい機能として「Wikiファーム」「Wikiポータル」「WYSIWYG」「アクセス管理」「履歴管理」を挙げて、まとめました。Wikiは基本的には、個人作業やグループワークにおいて便利なツールで、しかも設置は容易です。このため、企業にはボトムアップで、非公式に持ち込まれていきます。
こうしたWiki上での作業は、作業過程でのメモや書きかけのもの、使用しないと決めた情報など、様々な情報の蓄積を生み出しますが、ナレッジとして利用されるには各Wikiをイントラネットとあわせて横串で検索できる仕組みなどが必要です。
一方で、アクセス可能であるという時点で、予期せぬ情報の漏洩減となる可能性があります。これを踏まえて、企業の立場ではWikiを「LAN上のどこか」から「公認のイントラネット内」に集約する必要があります。
これは、Wikiに限らず、情報収集過程を蓄積するSBS、これまで公開されなかった知見を蓄積するBlogなど、Web 2.0ツール全般に言えることです。これらを公認・集約して、セキュリティ・コントロールを取り戻すこと、ナレッジを蓄積・拡大するプラットフォームとして統合することが必要です。一言で言えば、Enterprise 2.0のプラットフォームの構築を、トップダウンで行う必要があります。
なお、社内Wikiについては昨年の春から検討をはじめて、早1年半になります。この間に、株式会社シャノン様、TISの倉貫様、NECの福岡様、enNetforumの遠山様、マッシュアップペディアの中津川様、技術評論社様、他多くの方々にお世話になりました。今後とも社内Wikiについての活動は続けていきますが、一つの区切りでもあり、ひとまずこの場でお礼申し上げます。
昨日のセミナの資料作りで、久しぶりに自分のノートPCにインストールしてあったKwikiを動かしました。
WikiwygというWiki用に開発されたWYSIWYGエディタを組み込んであって、これのスクリーンショットを取りました。
このKwiki、いつ頃インストールしたものだったか調べてみたら、2006年1月のWiki小話Vol.5の頃でした。すごく前の話ですね。その後、Kwikiがどんな状況になっているかフォローしていなかったのですが、www.kwiki.orgを見てみると、Kwiki2になっているようです。で、インストールしてみようと思ったら、動かない。
2006年12月からKwiki 2.0に着手し、まずTracを立ち上げた（え？）。Kwikiは500以上のCPANモジュールに依存し、kwiki-*モジュールが150以上ということで、モジュール多すぎ。そこでIngyがモジュールを集めてKwikiのSVNリポジトリに突っこんで解決することにした。で、シンボリックリンクを張りまくった結果、WindowsやPerl 5.8.1以前では動かないことになって「古いPerlとWindowsは忘れよう」と。
...だそうで、YAPC::Asia 2007に行っていれば分かっていたことだったのですね。チケットは買ったんだけど、仕事を休めず、行けなかったですよ。ちなみに、YAPCでそう宣言しただけではなく、www.kwiki.org上でも「WIndowsでの動作は期待していないし興味もない、使いたければvmwareとかを使うか、Cygwinででも」と言ってしまっています。
Currently there is no expectation or interest in porting Kwiki to Win32.
If you'd like to run Kwiki2 on windows your best bet will be to use a virtualizer like vmware and run a linux appliance that includes svn, a webserver and perl.
Running Cygwin is another alternative.
せっかく確認したのだからということで、Wiki小話の際に作ったミニプレゼン資料「Way to Wikiwyg」を更新して、今回はSlideshareに登録してみました。Slideshare、簡単ですね。
mixiのあんなデータやこんなデータを引っ張り出してPerlで遊ぶためのモジュール、WWW::Mixiの0.50版を公開しました。CPANにもアップロードしたのだけど、反映されるのはまだかな？でも、じきに反映されるはずです。
今回は、mixiのHTMLがあちこち変わったのに合わせて、あちこち修正（しただけ）です。
そういえばこの6月に、WWW::Mixi::Scraperというモジュールがリリースされています。
どこかに書いたか忘れましたが、WWW::Mixiの開発動機には「inetdではWWW::Mechanizeを使えない（使えなかった）けど、LWPでmixiのscrapingは面倒！」と思ったことがあります。そこで、LWPモジュールさえ利用できれば動作するWWW::Mixiモジュールを作成しました。私のイメージでは、WWW::MixiとWWW::Mixi::Scarperでは依存モジュールの差も、大きな違いです。
このところ、「perl」タグの記事 - Walrus, Voxing.で何度か書いているように、WWW::Mechanize＋HTML::TreeBuilderというのは強力な組み合わせで、WWW::Mixi::ScarperがベースにしているWeb::Scraper＋XPathというのはさらに上位の組み合わせです。拡張しやすさと、HTML変更に対する強度は、石垣さんが書かれているようにまず間違いなくWWW::Mixi::Scraperが上。
WWW::Mixiは、設置しやすさが重要な時に使うのが良いのではないかと思います。
「一日当たりどれだけの数のエントリを処理しているのか」を調べたくなって、livedoor Readerの24時間以内の未読エントリを数えるスクリプトを書いてみました。
注意ですが、このスクリプトは実行環境にも、livedoorにも優しくありません。ヘビーです。ただ、実際にこうしたことが知りたいという状況があったということと、このまま使うわけにはいかなくても、Perlでlivedoor ReaderのAPIを利用するためのサンプルスクリプトにはなるでしょう。
use WWW::Mechanize;
use JSON;
use Jcode;my $id = ""; # livedoor ID
my $pass = ""; # livedoorパスワード
my $mech = WWW::Mechanize->new;
my %subs = ();{# ログイン
my $uri = URI->new('http://member.livedoor.com/login/index');
$uri->query_form(['livedoor_id' => $id, 'password' => $pass]);
my $res = $mech->post($uri);
}{# 未読subscribeのidを取得
my $uri = URI->new('http://reader.livedoor.com/api/subs');
$uri->query_form(['unread' => 1]);
my $res = $mech->post($uri);
my $obj = JSON::jsonToObj($res->content);
foreach my $sub (@{$obj}) {
$subs{$sub->{'subscribe_id'}} = {'id' => $sub->{'subscribe_id'}, 'title' => $sub->{'title'}};
}
}{# 各未読subscribeの未読エントリを取得
my $from = time - (24*60*60);
my $count = 0;
foreach my $sub (values(%subs)) {
$sub->{'count'} = 0;
my $uri = URI->new('http://reader.livedoor.com/api/unread');
$uri->query_form(['subscribe_id' => $sub->{'id'}]);
my $res = $mech->post($uri);
my $obj = JSON::jsonToObj($res->content);
foreach my $item (@{$obj->{'items'}}) { $sub->{'count'} += 1 if ($item->{'created_on'} >= $from); }
$count += $sub->{'count'};
printf("%s : %d\n", jcode($sub->{'title'}, 'utf8')->sjis, $sub->{'count'});
}
print "----\ntotal : $count\n";
}
今回は受け取るデータ形式がJSONなので、HTML解析やXML/Feed解析は不要で、JSONモジュールを使用。mech+TreeBuilder+XML::*PPではなくmech+JSONという組み合わせになります。
livedoor ReaderのAPIの叩き方は「pybigi: PythonでLivedoor Readerから未読の記事を取得する」を参考にしました。ありがとうございました。
18日に、Yahooが日本語形態素解析Webサービスを公開しました。
同APIを使うと、解析対象の日本語文を形態素に分割し、品詞名や読み、基本形、形態素の総数、各形態素の出現回数を返す。対象の文章がどんな特徴的な単語で構成されているのかを把握でき、検索APIと組み合わせればブログの類似記事検索なども可能になるとしている。
ITmedia News：Yahoo！の日本語形態素解析エンジンAPIを公開
ためしに、軽くPerlから呼び出して、結果をCSV形式で保存してくれるスクリプトを書いてみます。各種コードから使うのであれば、DOM操作などもできるXML形式のレスポンスのままでいいのだけど、人間が見てどういうサービスかとか、使えそうかとか考えるにはCSVが便利。
use File::Slurp;
use Jcode;
use URI;
use WWW::Mechanize;
use XML::TreePP;# ---- ユーザ、解析対象ごとの設定 ----
# IDと解析するセンテンス
my $appid = ''; # Yahoo Developpersで登録したID
my $sentence = ''; # 解析するテキスト# プロキシ関連の変数（要HTTPプロキシ時）
my $http_proxy = ''; # プロキシサーバ、'http://proxy.example.com:8080'など
my $proxy_user = ''; # プロキシ認証時のユーザ
my $proxy_pass = ''; # プロキシ認証時のパスワード# ---- 以下修正不要 ----
# URIの構築
$sentence = jcode($sentence)->utf8;
my $uri = URI->new('http://api.jlp.yahoo.co.jp/MAService/V1/parse');
$uri->query_form([
'appid' => $appid,
'sentence' => $sentence,
'results' => 'ma,uniq'
]);# WWW::Mechanizeの初期化
my $mech = WWW::Mechanize->new;
my $proxy = $http_proxy;
$proxy =~ s/^([a-z]+:\/\/)/$1${proxy_user}:${proxy_pass}\@/i if ($proxy && $proxy_user && $proxy_pass);
$mech->proxy('http', $proxy);# リクエストとレスポンスの取得
my $res = $mech->get($uri);
die "Can't get response." unless ($res);
die $res->status_line unless ($res->is_success);
my $source = $res->content;# XMLの解析
my $xml = XML::TreePP->new;
my $tree = $xml->parse($source);# 形態素解析結果の出力
my $parsed = '';
foreach my $word (@{$tree->{'ResultSet'}->{'ma_result'}->{'word_list'}->{'word'}}) {
my @values = map { $word->{$_} } ('surface', 'pos', 'reading');
@values = map { ref($_) ? ' ' : $_ } @values;
my $line = join ',', map {(s/"/""/g or /[\r\n,]/) ? qq("$_") : $_} @values;
$parsed .= $line . "\n";
}
if ($parsed) {
$parsed = jcode("標記,品詞,読み\n")->sjis . jcode($parsed)->sjis;
write_file('parsed.txt', $parsed);
}# 頻度集計結果の出力
my $count = "";
foreach my $word (@{$tree->{'ResultSet'}->{'uniq_result'}->{'word_list'}->{'word'}}) {
my @values = map { $word->{$_} } ('count', 'surface', 'pos', 'reading');
@values = map { ref($_) ? ' ' : $_ } @values;
my $line = join ',', map {(s/"/""/g or /[\r\n,]/) ? qq("$_") : $_} @values;
$count .= $line . "\n";
}
if ($count) {
$count = "回数,標記,品詞,読み\n" . jcode($counted)->sjis;
write_file('count.txt', $count);
}
これで「ほら、mech+TreeBuilder+XML::*PPが便利でしょう！」と言うつもりだったのだけど、よく考えたらHTML::TreeBuilderも、mechの便利なところも使ってないですね。そこだけはちょっと失敗。
6月20日にローンチ予定だったWikiCreole 1.0は、7月3日まで議論継続、次回IRCミーティングは26日(火)となったようです。
Discussion will continue until 2007-Jul-03. Our next IRC meeting will be on Tuesday, 2007-Jun-26, 21:00 GMT.
WikiCreole: Home
ということでWikiCreole: Creole 1.0 (和訳)の更新もそれまでなし。
ところで、この和訳につけていただいたはてなブックマークを見るといくつかコメントがついているのですが、どちらかと言えばネガティブイメージがあるのかもしれません。これまでの記法論争、標準化動向を知っていると無理もないかな、と思いますが。
表現できるものに差がある記法がいくつ増えたところで相互変換できないのは変わらない
はてなブックマーク - WikiCreole: Creole 1.0 (和訳)
Wiki 記法の標準化。MediaWiki、PukiWiki、はてなと戸惑う
はてなブックマーク - WikiCreole: Creole 1.0 (和訳)
WikiCreoleの価値は、最終的には記法の良し悪しじゃなくて、いくつのWikiエンジン、何％のWikiサイトでこれが使えるようになるかという点にあると思います。その意味では、一昨日のエントリでは関係者一覧であるWikiCreole: Peopleを紹介しましたが、あわせてWikiCreole: Implementetion（実装について）を紹介しておかなければいけなかったかもしれません。
このうち、WikiCreole: EnginesではWikiCreoleをサポートしている/サポートを計画しているWikiエンジン（アプリケーション）がリストされています。
- 既にWikiCreoleサポートし始めているものには、MoinMoin、TiddlyWiki、JSPWikiなど10種類が挙げられています。
- 部分的にサポートしているものには、TracWikiが挙げられています。
- サポートを計画中のものにはC2 Wiki（Ward CunninghumのWiki）、MediaWiki、TWiki、PhpWikiなど10種類が挙げられています。
- サポートするツール（Tools supporting）にはPEARパッケージやJavaScriptによるパーサなど5種類が挙げられています。
これらのWikiエンジンが、あるWikiの編集画面から別のWikiの編集画面にテキストをコピー＆ペーストすれば、同じように表示されるようにしようと動いています。Creole 1.0仕様のはしばしに「あるWikiエンジンから別のWikiエンジンに移動した時に」といった記述があり、このコピー＆ペーストができるということにはこだわりがあるように感じます。
また、現在のサポート状況では、準拠しているWikiCreoleのバージョンに違いがあったり、プラグインとしての実装が目に付きます。しかしそこで改めてPeopleをみれば、各エンジン開発の中心に近い人たちが多いように見受けられ、「個人的に一度は実装してみたけど」「プラグインとして実装してみたけど」で終わらずに済むのではないかと期待しています。
この書式を完全サポートする Wiki エンジンを作る（もしくは既存のを改造する）とよいのではないか。
YAMDAS現更新履歴 - Wiki記法標準化プロジェクトWikiCreoleのCreole 1.0和訳公開
そう、私も、この書式を完全サポートする Wiki エンジンを作る（もしくは既存のを改造する）とよいのではないかと思います。
日本のWikiエンジンのうちいくつで、何％のWikiサイトで、WikiCreoleが使えるようになるかが、日本でのWikiCreoleの価値を決めます。もしかすると、世界のWikiコンテンツの中での日本のWikiコンテンツの価値も、「編集に参加しやすいか」「引用（コピー＆ペースト）しやすいかどうか」の差で、ちょっとだけ上下させるかもしれません。
WikiCreole Wikiにある、現在「提案」段階にあるWiki Creole 1.0の仕様を和訳しました。下記で公開します。
WikiCreoleについては、まずは江渡さんのメールから引用。
WikiCreoleという、Wikiの書式標準化プロジェクトが動いています。
WikiSym2006から始まったようです。Ward Cunningham氏も関与していたことから、これはうまくいくかもしれない。
WikiCreoleという命名も、なかなか秀逸です。Creoleという言葉自体知らなかったのですが、Wikipediaをあたって、なるほどと思わされました。
クレオール言語（クレオールげんご）とは、意思疎通ができない異なる言語の商人らなどの間で自然に作り上げられた言語（ピジン言語）が、その話者達の子供によって母語として話されるようになった言語を指す。公用語や共通語として話されている地域・国もある。
Ward Cunninghum以外の関与している人は、WikiCreole WikiのPeopleというページで見られます。ここで名前が挙がっているWikiエンジンやサービスを眺めただけでも、JSP Wiki、Doku Wiki、WikiMatrix、MediaWiki、SnipSnap、MoinMoin、WikiGatewayといった具合で、Wiki界のかなり広くに影響力がありそうな感じです。
これらが一斉にWikiCreoleを採用したり、完全に切り替えるわけではないにしても。
WikiCreole 1.0版は、WikiCreole Wikiのトップページによれば、19日のIRCミーティングを経て20日にはローンチされるとのこと。
We will have a meeting on Tuesday, June 19, at 22:00 UTC on IRC freenode channel #creole to fine-tune Creole 1.0 and then we will launch it on Wednesday morning, June 20.
この和訳は何とか「IRCミーティング前夜」に間に合わせることができました。それから、1.0版がローンチされれば、上のリンク先にあるドキュメントもそれほど遅れずに更新したいと思っています。
個人的な感想としては、参加者も重要なのだろうけど、それ以上に実際のCreoleがかなり受け入れやすい文法になっていることが印象的です。特定の実装の記法を引きずっているような感じはしなくて、シンプルで素直な感じ。それでいて、実装を考えるときに必要そうな情報も揃っている気がする。このWiki記法、結構いいんじゃないかな。
A9.comによる「Specifications/OpenSearch/1.1/Draft 3」を和訳しました。下記で公開します。
OpenSearchは、Amazon.com参加のA9.comが提案した検索結果の配信方法で、FireFox2の検索プラグインやIE7のSearch Provider Extensibilityなどで採用されているようです。
仕様自体は、OpenSearch Description Document、OpenSearch URL template syntax、OpenSearch Query elements、OpenSearch Response elementsなどから成っていますが、最初のOpenSearch Description Documentを読みこなせば、あとはこれを詳細に説明したり、関連仕様の側から説明したような簡単に読める内容です。また、OpenSearch Description Documentについては平林氏のHyper Estraier開発メモにある「OpenSearch対応」などコンパクトにまとまった日本語のページが多くあるので、これらとあわせ読んでいただくのがよいかもしれません。
Have fun in Japanese!
ファイルアップロードをCGIで受け付けることを考えていて、ふと「JcodeモジュールでSJIS→EUC→SJIS、SJIS→UTF8→SJISと変換したら元に戻る文字、戻らない文字ってどうなっているだろう」ということが気になりました。一言で言えば、「Perlで安全に使えるマルチバイト文字は？」ということになります。
packだとかのあたりが良く分かっていないので、かなり力任せな次のようなコード（実際にはもう少し結果の整理などをしてくれるようにしましたが、肝はこんなところ）を書いて実験。
foreach my $num (0..64764) { # \x00 .. \xFC\xFC
my $char = undef;
my $code = sprintf('%04X', $num);
$code =~ s/^00//;
$code =~ s/(..)/\\x$1/g;
eval qq(\$char = "$code");
next unless ($char =~ /^(?:$re_sjis)$/s);
my $euc_result = (jcode(jcode($char, 'sjis')->euc, 'euc')->sjis eq $char) ? 1 : 0;
my $utf_result = (jcode(jcode($char, 'sjis')->utf8, 'utf8')->sjis eq $char) ? 1 : 0;
printf("%s (%s) ... %s\n", $char, $code, ($euc_result and $utf_result ? 'OK' : 'NG'));
}
結果はPerlメモ/日本語の扱い - Walrus, Digit.にまとめましたが、正規表現に整理すると大崎氏の文字の正規表現 - Perlメモに「SJIS文字（機種依存文字・未定義領域を含まない）」としてまとめられているものとまったく同じでした。やるまでもなかったといってしまえばそれまで。
まあ、これでUTF-8時代の今でも「昔から言われている『機種依存文字』を使わないでください、それ以外はOKです」と胸を張って言えます、ということで。
Wiki小話Vol.7「Podcastle Night」を開催しました。
メインの小話は70名申込みで椅子が全部埋まり、会場としてお借りした沖電気9階の会議室には講演者、スタッフ他を合わせてきっと90名ぐらいが入りました。その後の懇親会も、手にカウンターを持って入店者数を数えてくださったLF CAFEの方によれば54名。大盛況のうちに閉幕を迎えられました。多謝！
実は私自身は受付などでずっと会場の外にいたのですが、nijimuさんに録音してもらった音声（非公開）をようやく聞けましたので、いくつかノートというか。
■ Wikiとは何か
「『PodcastleってWikiなんですか』と塚本さんに聞かれて、えらい難しい質問する人だなぁと。まずPodcastleとは何か、Wikiとは何かという問題があるわけで...」と江渡さん。江渡さん（とSHIMADAさん、AsOさん）とは、延々と「Wikiとは何か｣をやり続けているみたいです。
最近、僕の中ではまた少し認識が変わっていて、いろんなWikiのバリエーションを認めつつ、そこで定義がぶれてくる部分を剥ぎ取っていくと、最後に残るのはこういうものかな、と思い始めています。
- Wikiアプリケーションとは、文書構造を持つWebページ全体を編集する機能を提供するCMS的なアプリケーション。JavaScriptやAjax、ブラウザ用のWYSIWYGのない時代に生まれており、文書構造をテキストエリアであらわすのにWiki記法という手法を生んだ。
- Wikiサイトとは、コンテンツ（テキスト）の編集機能をサイト訪問者、利用者に開放しているWebサイト。
一人WikiやTiddlyWiki、個人CMS系のSiteDevやPassWikiなどを見ていると、Wikiアプリケーションだと思うけど、Wikiサイト的な定義はあてはまらない。WemaやPodcastleを見ていると、サイトとしてはWikiサイトだと思うけど、Wikiアプリケーションの定義はあてはまらない。
WikiアプリケーションとWikiサイトはもう独立に存在していて、WardsWikiなどは偶然にこの両者（とWiki文化）が並存していたと見るのが自然じゃないかな、と。このあたりは、もう少し長い文章でお読みいただく機会があると思います。
■ 時間配分について
もりだくさんはいいけど少し希薄になってしまった。もうちょっと時間あったら良かったですね。
Podcastleの講演 - unnonouno
音声を聞いてみるとそれぞれ、1時間ぐらいのセミナーを持ってもらって「Podcastle Day」にしても良い面白さですね。そのあたりは、かなり悔しいです。いやきっと、産総研で開催してくれるに違いない！
イベントとしては希薄どころか特濃だったと思うのですが、もっと時間がほしかったのは間違いないです。悔しいなぁ。
■ 運営のもろもろについて
今回は初めての会場で、運営の組み立てもばたばたしてしまって、講演者の皆様と共催者のたつをさん、会場提供してくださった沖電気の方、それからnijimuさんにかなり助けられました。本当に感謝です！
それから...
今回、参加者の名前入りのネームプレートが入り口で配られていたのですが、あれ、すごく良かったです。
まちゅダイアリー - 今日は Wiki 小話の日
...については、小話Vol.4から作り始めたんだったかな？名札ケースは200円もしないものなので、こういう感想をもらえると嬉しくて、もう元が取れたようなものです。
でももし、御礼をと考えていただけるようであれば、まちゅさんに「Wikiのセキュリティアップ考～認証、権限、スパム対策～」とかで小話をしてもらえれば！
■ Wiki小話について
江渡さんからは懇親会の締めの挨拶で「小話が久しぶりに復活したのは良かったです。今年は月に1回ぐらいやってほしいですね。あ、数値目標ね」と言われてしまいました。月に1回はどうか分からないけど、できるだけやりたいですね。もっと面白い話を聞きたいです。
あと、「Wiki小話/Vol.7 - Podcastle Night。」からリンクされている感想は全部呼んでますよ！ありがとうございます～。
