京都を出発して三日目。
昨日は兵庫県赤穂市に宿泊して、
本日一日で岡山県を完走。
現在地は広島県福山市です。
ちょこちょこ土産の品などを買っているので、
だんだんリュックが重くなってきた。。。
足腰の筋肉痛に加えて、今日は肩こりにも悩ませることに。
とりあえず今のところ、進行は順調。
この調子なら明日には実家の西高屋に着くな。
今日もきつかったが、多分明日が一番きつい。
山の中をひたすら走ることになるので、
おそらくアップダウンがかなり激しい。。。
あとちょっと頑張ろう。
さて柔軟して寝よー。
2009年9月21日月曜日
2009年9月19日土曜日
ハチクロ的大脱走 はじめに
本人は修行というか忍耐試しのつもりなんですが、
たぶん他の人から見たら脱走以外の何者にも見えないんだろうなぁと苦慮しつつ
それでもやってしまいました。
実家に帰ります。
自転車で。
ちなみに下宿先は京都の寺田。
実家は広島の東広島市。
総走行距離は350km～400km程度。
一日に80～100Km進めば着くはず。
本当は観光とかしつつまったり帰りたいんですが、
シルバーウィーク内に終わらせなければならないという時間制限があるので
結構タイトなスケジュールになりそうです。
ちなみに現在地は、兵庫県三宮。
既に筋肉痛が始まっております。。。若いってスバラシイ＜泣
明日は
さぁ、この文系（体育会系の逆って意味で）の足腰がどこまで保つかな。
たぶん他の人から見たら脱走以外の何者にも見えないんだろうなぁと苦慮しつつ
それでもやってしまいました。
実家に帰ります。
自転車で。
ちなみに下宿先は京都の寺田。
実家は広島の東広島市。
総走行距離は350km～400km程度。
一日に80～100Km進めば着くはず。
本当は観光とかしつつまったり帰りたいんですが、
シルバーウィーク内に終わらせなければならないという時間制限があるので
結構タイトなスケジュールになりそうです。
ちなみに現在地は、兵庫県三宮。
既に筋肉痛が始まっております。。。若いってスバラシイ＜泣
明日は
さぁ、この文系（体育会系の逆って意味で）の足腰がどこまで保つかな。
2009年7月28日火曜日
2009年7月25日土曜日
2009年7月23日木曜日
危篤
四年間付き合っていた私のパートナーが危篤状態に陥りました。
いえ、Let's noteなんですけどね。
前々から外傷は酷かったです。
基板が見えちゃったり、キーボードが浮いちゃったり。
けど、多少肥満気味ながらも(HDD残量3GB程度...DVD焼いたら成仏しかけました)頑張って働いてくれてました。
しかし、とうとう躁鬱病も患い始めました。
ええ、顔がいきなり暗くなったり明るくなったり。
あたかも、寿命がきた蛍光灯が明滅を繰り返すがごとく、モニタがプッツンプッツン落ち始めました。
入院させたくとも代理がいないので、離れることも出来ず。。。
かといって、いつ昇天召されるか分からない人をアチコチ連れて行くのも賭けですし。。。
いい加減、新しい相棒を確保せねば；；
いえ、Let's noteなんですけどね。
前々から外傷は酷かったです。
基板が見えちゃったり、キーボードが浮いちゃったり。
けど、多少肥満気味ながらも(HDD残量3GB程度...DVD焼いたら成仏しかけました)頑張って働いてくれてました。
しかし、とうとう躁鬱病も患い始めました。
ええ、顔がいきなり暗くなったり明るくなったり。
あたかも、寿命がきた蛍光灯が明滅を繰り返すがごとく、モニタがプッツンプッツン落ち始めました。
入院させたくとも代理がいないので、離れることも出来ず。。。
かといって、いつ昇天召されるか分からない人をアチコチ連れて行くのも賭けですし。。。
いい加減、新しい相棒を確保せねば；；
2009年7月19日日曜日
AS3 in Amazon ☆ Product Advertising APIのHMAC-SHA256署名への対応
Python側での対応が終わったので、次はFlexアプリケーションにてAmazonの署名リクエストを行うように対応。
私の検索方法が悪かったのか、参考になるWebページがあまり見つからなくて困った(>_<) 結局、一番分かり易い、というかクリティカルなところを解決してくれたのはAmazonのコミュニティだった。
やっぱり大事なんだな、こういうところ。
AS3でHMAC-SHA256署名を行うにあたり、まずは以下のパッケージを導入する必要がある。
as3crypto
zipファイルをダウンロードして解凍。
com以下を作業用ディレクトリにコピペ。
後は、このパッケージのHMAC、SHA256、Base64クラスをインポートして、HMAC-SHA256でハッシュ化した後、Base64エンコードする。
この辺の手順については、RHC2104の仕様とか全然読んでない；；
Pythonの時にお世話になった以下のページを参考にハッシュ化とエンコードを行った。
Amazon Product Advertising APIの署名認証をPythonでやってみる
以下、参考までにAS3のソースを公開。
BeteArrayをnewしてから、writeUTFBytesで中身を書き込むのが味噌。
as3cryptoのテストコードではHexというクラスをnewして、Hex.toArray("署名したいドキュメント")でByteArray型の値を生成していたんだけど、こちらを使うとSignatureが不正になってしまった。
SignatureのURLエンコードはreplaceメソッドで手作業。。。
最初はescape関数を使ってたんだけど、+が上手く%2Bに変換されないんだよね。
エラー続発につき、とりあえず+と=だけ変換するように改良。
ちなみに、ダウンロード終了後に呼び出すイベントハンドラ、onAmazonRequestCompleteメソッドには複数の引数を与えてる。
これは、以下のように、イベントハンドラの中で、さらにfunctionをreturnすることで可能となる。
難産だった。。。
私の検索方法が悪かったのか、参考になるWebページがあまり見つからなくて困った(>_<) 結局、一番分かり易い、というかクリティカルなところを解決してくれたのはAmazonのコミュニティだった。
やっぱり大事なんだな、こういうところ。
AS3でHMAC-SHA256署名を行うにあたり、まずは以下のパッケージを導入する必要がある。
as3crypto
zipファイルをダウンロードして解凍。
com以下を作業用ディレクトリにコピペ。
後は、このパッケージのHMAC、SHA256、Base64クラスをインポートして、HMAC-SHA256でハッシュ化した後、Base64エンコードする。
この辺の手順については、RHC2104の仕様とか全然読んでない；；
Pythonの時にお世話になった以下のページを参考にハッシュ化とエンコードを行った。
Amazon Product Advertising APIの署名認証をPythonでやってみる
以下、参考までにAS3のソースを公開。
/*** Import ***/
import com.hurlant.crypto.hash.HMAC;
import com.hurlant.crypto.hash.SHA256;
import com.hurlant.util.Base64;
/*** Field Variables ***/
private var requestUri:String = "ecs.amazonaws.jp"
private var requestPath:String = "/onca/xml"
private var amazonSecretKey:String = "AWSの秘密鍵"
/*** AWS Access Method ***/
private function sendAmazonRequest(var1:int, asin:String):void{
var amazonloader:URLLoader = new URLLoader()
// タイムスタンプの作成：ISOフォーマット、UTC(世界標準時)
// make Timestamp: ISO format, UTC
var timestamp:String = makeTimeStamp()
// バイトコード順にソートしつつ、クエリを連結
// クエリをそれぞれescape関数でURLエンコードしておく（×escapeMultiByte）
// sort query by the byte code ascending, and join them
// query is urlencoded by 'escape' method (not escapeMultiByte)
var query:String = "AWSAccessKeyId=Amazonへのアクセスキー&"
+ "ItemId=" + asin + "&"
+ "Operation=ItemLookup&"
+ "ResponseGroup=" + escape("Medium,Images,EditorialReview,Reviews") + "&"
+ "Service=AWSECommerceService&"
+ "Timestamp=" + escape(timestamp) + "&"
+ "Version=" + "2008-08-19";
// 署名の生成
// make Signature
var signatureText:String = ["GET", requestUri, requestPath, query].join("\n") // 署名する文書 Document for signature
var signature:String = makeSignature(signatureText, amazonSecretKey)
// URLエンコードした署名をクエリの最後に追加
// リクエストURLの完成
// add urlencoded Signature to query tail
// complete request Url
query += "&Signature=" + signature.replace(/\+/g,'%2B').replace('=', '%3D')
var requestUrl:String = "http://" + requestUri + requestPath + "?" + query
// amazonへアクセス（onAmazonRequestCompleteにてダウンロード完了後の処理を行う）
// access to Amazon (after download complete, onAmazonRequestComplete() executed)
amazonloader.addEventListener(Event.COMPLETE, onAmazonRequestComplete(var1, amazonloader));
amazonloader.load(new URLRequest());
}
private function makeTimeStamp():String{
// ISOフォーマットでタイムスタンプを生成 YYYY-MM-DDTHH:mm:ss
// 世界標準時（UTC）を採用
var timestamp:String = timeStamper.getUTCFullYear() + "-"
+ to2size(timeStamper.getUTCMonth() + 1) + "-"
+ to2size(timeStamper.getUTCDate()) + "T"
+ to2size(timeStamper.getUTCHours()) + ":"
+ to2size(timeStamper.getUTCMinutes()) + ":"
+ to2size(timeStamper.getUTCSeconds())
return timestamp
}
private function to2size( data:Number ):String{
// 日付や時分秒が10未満の場合、2桁となるよう左に0を挿入
var strData:String = data.toString() // 返却する文字列
if (data < 10) {
strData = "0" + strData
}
return strData
}
private function makeSignature(signatureText:String, key:String):String{
// HMAC-SHA256署名の作成
// 署名する文書と、ハッシュキーを引数として受取り、String型の署名データを返す
// generate HMAC-SHA256 signature
// accept "document for signature(String)" and "signature key(String)" as variables
// return signature(String)
//HMAC-SHA256署名を行うクラス
var hmac256:HMAC = new HMAC(new SHA256());
// 署名する文書のバイトデータ ByteArray for signatured document
var signatureTextBytes:ByteArray = new ByteArray();
signatureTextBytes.writeUTFBytes(signatureText)
// 署名用のハッシュキーのバイトデータ ByteArray for signature key (AWS secret key)
var keyBytes:ByteArray = new ByteArray();
keyBytes.writeUTFBytes(key)
// HMAC-SHA256署名を行い、ダイジェストを生成
// generate Digest (HMAC-SHA256)
var digest256:ByteArray = hmac256.compute(keyBytes, signatureTextBytes);
// ダイジェストをBase64でString型にエンコード
// encode Digest(ByteArray) to String by Base64encoding
var signature:String = Base64.encodeByteArray(digest256)
return signature
}
BeteArrayをnewしてから、writeUTFBytesで中身を書き込むのが味噌。
as3cryptoのテストコードではHexというクラスをnewして、Hex.toArray("署名したいドキュメント")でByteArray型の値を生成していたんだけど、こちらを使うとSignatureが不正になってしまった。
SignatureのURLエンコードはreplaceメソッドで手作業。。。
最初はescape関数を使ってたんだけど、+が上手く%2Bに変換されないんだよね。
エラー続発につき、とりあえず+と=だけ変換するように改良。
ちなみに、ダウンロード終了後に呼び出すイベントハンドラ、onAmazonRequestCompleteメソッドには複数の引数を与えてる。
amazonloader.addEventListener(Event.COMPLETE, onAmazonRequestComplete(var1, amazonloader));
これは、以下のように、イベントハンドラの中で、さらにfunctionをreturnすることで可能となる。
// AmazonのXMLのNamespaceをnewしておく。リクエスト時の"Version"との一致が必須
// make Amazon XML Namespace instance. Namespace Version needs to be as same as "Version" at request
private var ns:Namespace = new Namespace("http://webservices.amazon.com/AWSECommerceService/2008-08-19");
// ダウンロード終了イベントを受け取るメソッド
// Method accepting download complete event
private function onAmazonRequestComplete(var1:int, amazonloader:URLLoader):Function{
// 実際にイベントを処理するfunctionを返す
// return function which handles Event actually
return function(e:Event):void{
default xml namespace = ns;
var response : XML = new XML(amazonloader.data);
// 以下、XML操作...
// And read and write XML...
}
}
難産だった。。。
2009年7月18日土曜日
google-code-prettify の導入
今までベタ貼りしていたソースコードをもっと見やすくしようと、
ソースコードを綺麗に表示してくれるJavascriptを導入。
色々種類があったけど、とりあえず見た目がシンプルなものをチョイス。
google-code-prettify
導入の際にお世話になったのが、こちらのサイト。
ソースコード を色づけして 表示 する - 八発白中
意外なのがBloggerにJavascriptのアップロード機能がついてなかったこと。
Google app engineとかあるから、できるようなイメージで居たんだけど。。。
他、Googleのサービスをあさっても、jsをアップロードできそうなサービスが見当たらなかったので、仕方なく手元のWebサーバにアップロードしてお茶を濁す。
しかし、納得いかんなぁ。。。なんでapp engineがOKで、jsが駄目なんだろ？
とりあえず、テストしてみた。
おぉ綺麗☆
もっと早く入れとけば良かったなぁ。
ソースコードを綺麗に表示してくれるJavascriptを導入。
色々種類があったけど、とりあえず見た目がシンプルなものをチョイス。
google-code-prettify
導入の際にお世話になったのが、こちらのサイト。
ソースコード を色づけして 表示 する - 八発白中
意外なのがBloggerにJavascriptのアップロード機能がついてなかったこと。
Google app engineとかあるから、できるようなイメージで居たんだけど。。。
他、Googleのサービスをあさっても、jsをアップロードできそうなサービスが見当たらなかったので、仕方なく手元のWebサーバにアップロードしてお茶を濁す。
しかし、納得いかんなぁ。。。なんでapp engineがOKで、jsが駄目なんだろ？
とりあえず、テストしてみた。
#include
/*
九九の表を表示する
*/
int main(void){
int i, j;
printf(" ");
for (i=1; i<10; i++){
printf("%2d ",i);
}
printf("\n");
for (i=1; i<10; i++){ // i の段
printf("%2d ", i);
for (j=1; j<10; j++){
printf("%2d ", i*j); // i x j の値を表示
}
printf("\n");
}
return 1;
}
おぉ綺麗☆
もっと早く入れとけば良かったなぁ。
[Python] Amazonへの署名付きリクエスト
再びAmazonへのリクエストネタ。
今まではAmazonへのリクエストはアクセスキー（秘密鍵とは別）さえあれば、本の詳細情報やレビューとかの公開されたデータは、誰でもリクエストで取得できた。
けど、8月15日から全てのリクエストについて、署名なしリクエストは受けてくれなくなるそう。
しょうがないので、以下のサイトを参考に対応。
Amazon Product Advertising APIの署名認証をPythonでやってみる
以下が更新したAmazonリクエスト取得用メソッド。
色々なタイプのデータを取りに行くので、こんな形にしてる。
英語がめちゃくちゃなのは・・・もはや標準仕様ということで＜汗
==================================================
import urllib
import hashlib, hmac, base64
from datetime import datetime
AWS_SECRET_ACCESS_KEY = 自分の秘密鍵
AWS_ACCESS_KEY_ID = 自分のアクセスキー
AWS_JP_URI = 'ecs.amazonaws.jp'
AWS_JP_ENDPOINT = '/onca/xml'
AWS_VERSION = '2008-08-19'
def getAmazonXML(search_options):
"""
与えられたオプションからAmazonへのリクエストを作成・実行
XMLを取得する
Makes a request to Amazon from the given search_options and executes it.
XML is acquired.
"""
# 全てのリクエストに共通するリクエストパラメータ
# Common request parameter to all Amazon request
options = {'Service' :'AWSECommerceService',
'AWSAccessKeyId' : AWS_ACCESS_KEY_ID,
'Version' : AWS_VERSION,
'Timestamp' : datetime.utcnow().isoformat(),
}
# optionsにsearch_optionsを追加（連想配列の結合はupdate()）
# search_options is added to options (if samekey exists, updated)
options.update(search_options)
# リクエストはバイト順にソートした上でURLエンコード
# その後、正規表現より+を%20(quote処理)に変更
# Request is sorted based on bytedata, and urlencoded.
# And "+" is replaced with "%20"(quote)
query = urllib.urlencode(sorted(options.items())).replace("+", "%20")
# 署名の作成
# generate signature
text = '\n'.(['GET', AWS_JP_URI, AWS_JP_ENDPOINT, query]) # target of signature
signature = base64.b64encode(hmac.new(AWS_SECRET_ACCESS_KEY, text, hashlib.sha256).digest())
# 署名のリクエストへの追加とURLエンコード
# make url for Japan Amazon ECS
request_url = "http://" + AWS_JP_URI + AWS_JP_ENDPOINT
request_url += "?" + query + "&" + urllib.urlencode({'Signature': signature})
# リクエストの実行
# execute request
xml = urllib.urlopen(request_url).read()
return xml
==================================================
なんか、随分メンドくさくなっちゃったな。。。
ってか、あとAS3も対応しなきゃいけないんだった。。。あう。
今まではAmazonへのリクエストはアクセスキー（秘密鍵とは別）さえあれば、本の詳細情報やレビューとかの公開されたデータは、誰でもリクエストで取得できた。
けど、8月15日から全てのリクエストについて、署名なしリクエストは受けてくれなくなるそう。
しょうがないので、以下のサイトを参考に対応。
Amazon Product Advertising APIの署名認証をPythonでやってみる
以下が更新したAmazonリクエスト取得用メソッド。
色々なタイプのデータを取りに行くので、こんな形にしてる。
英語がめちゃくちゃなのは・・・もはや標準仕様ということで＜汗
==================================================
import urllib
import hashlib, hmac, base64
from datetime import datetime
AWS_SECRET_ACCESS_KEY = 自分の秘密鍵
AWS_ACCESS_KEY_ID = 自分のアクセスキー
AWS_JP_URI = 'ecs.amazonaws.jp'
AWS_JP_ENDPOINT = '/onca/xml'
AWS_VERSION = '2008-08-19'
def getAmazonXML(search_options):
"""
与えられたオプションからAmazonへのリクエストを作成・実行
XMLを取得する
Makes a request to Amazon from the given search_options and executes it.
XML is acquired.
"""
# 全てのリクエストに共通するリクエストパラメータ
# Common request parameter to all Amazon request
options = {'Service' :'AWSECommerceService',
'AWSAccessKeyId' : AWS_ACCESS_KEY_ID,
'Version' : AWS_VERSION,
'Timestamp' : datetime.utcnow().isoformat(),
}
# optionsにsearch_optionsを追加（連想配列の結合はupdate()）
# search_options is added to options (if samekey exists, updated)
options.update(search_options)
# リクエストはバイト順にソートした上でURLエンコード
# その後、正規表現より+を%20(quote処理)に変更
# Request is sorted based on bytedata, and urlencoded.
# And "+" is replaced with "%20"(quote)
query = urllib.urlencode(sorted(options.items())).replace("+", "%20")
# 署名の作成
# generate signature
text = '\n'.(['GET', AWS_JP_URI, AWS_JP_ENDPOINT, query]) # target of signature
signature = base64.b64encode(hmac.new(AWS_SECRET_ACCESS_KEY, text, hashlib.sha256).digest())
# 署名のリクエストへの追加とURLエンコード
# make url for Japan Amazon ECS
request_url = "http://" + AWS_JP_URI + AWS_JP_ENDPOINT
request_url += "?" + query + "&" + urllib.urlencode({'Signature': signature})
# リクエストの実行
# execute request
xml = urllib.urlopen(request_url).read()
return xml
==================================================
なんか、随分メンドくさくなっちゃったな。。。
ってか、あとAS3も対応しなきゃいけないんだった。。。あう。
2009年7月17日金曜日
SwitchProxy → Multiproxy Switch
FireFox3.5にバージョンアップしてSwitchProxyが使えなくなってからというもの、家で学校で開発用で、とプロキシをいちいち手動で設定し直していました。
いい加減、耐え切れなくなってきちんと検索したら見つかりました。
Multiproxy Switch
名前、変わってたのね。。。
道理で見つからないのね。。。
開発は別の人ですが、機能、見た目は同じでした。
ようやくストレスから解消されそうです。
いい加減、耐え切れなくなってきちんと検索したら見つかりました。
Multiproxy Switch
名前、変わってたのね。。。
道理で見つからないのね。。。
開発は別の人ですが、機能、見た目は同じでした。
ようやくストレスから解消されそうです。
2009年7月16日木曜日
「遇う」ときは「遇う」
普段滅多に会わない友人と、一度「遇う」と、連続して「遇う」ことが多い。
いつもは別の友人に立て続けに「遇う」んだけど、
今回は、同じ日に同じ子に、二度偶然「遇った」。
ちょっと新鮮な気がする。
その子とは久しぶりに可愛いものトークで盛り上がれて楽しかった。
ちなみに本日のメインキャスト。
大阪、三角公園近くの300均で買った「ひよこドーナッツ」
携帯スタンドと携帯ストラップ、大小取り揃えております☆
基本、可愛いアイテムにハッスルする人間なので、
こういう話題で盛り上がれるとスゴク心が癒されます。
何かもう、今日は色々やりとげた気持ちで一杯です。
え、研究？
勿論、進んでないよ＜泣
いつもは別の友人に立て続けに「遇う」んだけど、
今回は、同じ日に同じ子に、二度偶然「遇った」。
ちょっと新鮮な気がする。
その子とは久しぶりに可愛いものトークで盛り上がれて楽しかった。
ちなみに本日のメインキャスト。
大阪、三角公園近くの300均で買った「ひよこドーナッツ」
携帯スタンドと携帯ストラップ、大小取り揃えております☆
基本、可愛いアイテムにハッスルする人間なので、
こういう話題で盛り上がれるとスゴク心が癒されます。
何かもう、今日は色々やりとげた気持ちで一杯です。
え、研究？
勿論、進んでないよ＜泣
2009年7月15日水曜日
ぷちショック
AWSに繰り返しアクセスするようなインタフェースを作ってるんですが、
Amazonへのアクセス速度が遅い事にイライラ。
ローカルサーバからXMLファイルを取得する形に変えれば、とりあえずデモは早くなるんじゃないかと思ってシステムを改良。
改悪でした。
Amazonのアクセス速度の方が4倍近く早い。
複数のデータをとるときは、Amazonに連続したアクセスへのインターバルがあるせいでローカルのを取ってきた方が早いんだけど、最初の一歩はAmazonの方が断然早。
コードがPythonなのが悪いのか、我が家のApacheがのんびりなのか。。。
あう゛ぅ……。
とりあえず、これで据え置きして、アクセス速度の向上は今度やろう。。。
はぁ……。
Amazonへのアクセス速度が遅い事にイライラ。
ローカルサーバからXMLファイルを取得する形に変えれば、とりあえずデモは早くなるんじゃないかと思ってシステムを改良。
改悪でした。
Amazonのアクセス速度の方が4倍近く早い。
複数のデータをとるときは、Amazonに連続したアクセスへのインターバルがあるせいでローカルのを取ってきた方が早いんだけど、最初の一歩はAmazonの方が断然早。
コードがPythonなのが悪いのか、我が家のApacheがのんびりなのか。。。
あう゛ぅ……。
とりあえず、これで据え置きして、アクセス速度の向上は今度やろう。。。
はぁ……。
2009年7月14日火曜日
Skype v.s. Apache
今更ながら引っかかりました。
Skypeが起動してるとApache が起動しない件 : karate style
焦った。本気焦った。
ミーティングで動かせなくなるかと思った。。。
怖かったよぅ。。。
とりあえず以下のスキルを習得したのでまあ良かったことにする。
■Windowsのイベントビューアを見る
（コントロールパネル＞管理ツール＞イベントビューア）
■netstat -oanでポートのListen状態を調べる
ずっとWindows使ってたけど、開発環境を整えたことはあまり無かったから意外と知らんなぁ。。。
Skypeが起動してるとApache が起動しない件 : karate style
焦った。本気焦った。
ミーティングで動かせなくなるかと思った。。。
怖かったよぅ。。。
とりあえず以下のスキルを習得したのでまあ良かったことにする。
■Windowsのイベントビューアを見る
（コントロールパネル＞管理ツール＞イベントビューア）
■netstat -oanでポートのListen状態を調べる
ずっとWindows使ってたけど、開発環境を整えたことはあまり無かったから意外と知らんなぁ。。。
2009年7月7日火曜日
第15回WI2研究会 終了
今回の研究会は、私にとってエンジン的な存在になりそうです。
MYCOMでは新しい道が見えた。
そこを走り出すための活力をWI2で得た。
そんな感じ。
それから、被験者実験の実験計画の重要さについて、よく勉強できました。
今やろうとしている実験についても、その辺りきちんと埋めていきたいです。
お世話になった先生方、本当にありがとうございました。
で。
とりあえず、出発前の目標についてそれぞれ達成度を確認しますかね＜笑
１．全部の発表についてメモをとる
２．１セッションにつき１回は絶対に質問する
３．名刺を１０枚獲得してくる＜笑（要は話せってコト）
1は90点かな。大体全部はとったけど、質問とかタイプが間に合わないところもあったし。
次回からはテープレコーダ持っていこうか＜笑
2は80点。チュートリアルが質問できなかったけど、これは何ていうか。。。
私自身のレベルを上げないとね。
チュートリアルで-30点だけど、2日目にたっぷり質問できたので+10点してあげて80点てところかな。
的確な質問ができなかったのが残念。
なんか「こうしたら良いのに」ってところが上手く表現できないんだよね、大向さんも「場数を踏めば」と仰ってくださったので、まずは研究室の中でもっともっと練習練習。
3は100点。色んな人に挨拶できたし話せたし、良かった良かった。
内向的、かつ人見知りが激しい私にしては画期的♪
あとは実になる話をできる人間にならないとね。
総合得点は90点。
WI2は本当に楽しかった。
けど、この楽しさはきっと聴講生というお客様身分なのもあるんだろうな。
きっと発表者として上がったら見えるものがまた違うんだろう。
次回10月の第16回WI2には講演者として参加したいけど。。。
ちょっと日程的に厳しそうだなぁ＜汗
もっと生産性を上げないと現時点ですらヤバい。。。
がんばるぞー！
MYCOMでは新しい道が見えた。
そこを走り出すための活力をWI2で得た。
そんな感じ。
それから、被験者実験の実験計画の重要さについて、よく勉強できました。
今やろうとしている実験についても、その辺りきちんと埋めていきたいです。
お世話になった先生方、本当にありがとうございました。
で。
とりあえず、出発前の目標についてそれぞれ達成度を確認しますかね＜笑
１．全部の発表についてメモをとる
２．１セッションにつき１回は絶対に質問する
３．名刺を１０枚獲得してくる＜笑（要は話せってコト）
1は90点かな。大体全部はとったけど、質問とかタイプが間に合わないところもあったし。
次回からはテープレコーダ持っていこうか＜笑
2は80点。チュートリアルが質問できなかったけど、これは何ていうか。。。
私自身のレベルを上げないとね。
チュートリアルで-30点だけど、2日目にたっぷり質問できたので+10点してあげて80点てところかな。
的確な質問ができなかったのが残念。
なんか「こうしたら良いのに」ってところが上手く表現できないんだよね、大向さんも「場数を踏めば」と仰ってくださったので、まずは研究室の中でもっともっと練習練習。
3は100点。色んな人に挨拶できたし話せたし、良かった良かった。
内向的、かつ人見知りが激しい私にしては画期的♪
あとは実になる話をできる人間にならないとね。
総合得点は90点。
WI2は本当に楽しかった。
けど、この楽しさはきっと聴講生というお客様身分なのもあるんだろうな。
きっと発表者として上がったら見えるものがまた違うんだろう。
次回10月の第16回WI2には講演者として参加したいけど。。。
ちょっと日程的に厳しそうだなぁ＜汗
もっと生産性を上げないと現時点ですらヤバい。。。
がんばるぞー！
2009年7月6日月曜日
第15回WI2研究会 2日目セッション4「Webサービス」
お昼は市立大学の人たちと例のオープンしたてのパン屋で食べました。
日曜日なのでお子ちゃま多数＜笑
WI2もこのセッションで終わり。
非常にためになる研究会でした。
===============
■学術研究プラットフォームのサービス提案
岡本さん
・YahooJapanで10年勤務
学術成果のプラットフォームを作りたいと考えるようになった。
・問題意識
インターネットの学術利用→ 専門分野の横断、研究者と市民の接続
→メディアの限界
→プラットフォームへの転換
学者や専門化がそれぞれ自分個人のウェブを管理し、最新の専門知識を競うように公開する時代が来れば良いと思う。
・基本コンセプト
インセンティブデザイン＝良い物を作れば作ってくれる→使わざるを得ない状況においていく
ユーザビリティ＝Web標準から遅れている
アビリゲート＝データを一元化しすぎると×（ブックマークはココ、ブログはアッチみたいな）サービスを取り込んでいく
インテリジェンス＆インタラクション！
・管理対象データの区分
Relation＝研究者同士の関連
Event＝研究会情報
Task＝TODO
Output＝上手く統合して行きたい
Process＝成果よりはプロセスをはっきり示すべきでは？
・インセンティブデザイン
自分自身に関る情報を整理→機械的な学習も必要
情報の発見
労力の削減→各種申請書類フォーマットへの対応
支援の獲得→プロセスの発表に対して、一般市民がDonateされる、Donateは謝辞や還元される
・課題
持続性 ビジネスモデル的な問題
商用利用禁止規定
依然クローズな基盤データ環境 APIを公開してくれない
質問1
プロセスを見せるのは面白い。研究者がサボってるかどうかもよく分かる。どう見せる？
→Twitter的なもので良い。等身大の研究者像を伝える。意外と研究者のブログでも研究については発信されていないから。
質問2
財閥系からの支援が得にくい。どうやって儲ける？
→ビジネスモデル的には難しい。当面は別の仕事で食っていく。透明な資金を集める。日本人は300万人の研究者がいる。学術産業をちゃんと立ち上げるべき。
質問3
国のやる仕事と民間のやる仕事は新しいところでレイヤーを引かないといけない。どのレベルまでやる事を期待している。
→基盤データを作るのは国の仕事（営利ビジネスとは立ち行かない）NIIやJSTにはデータプロバイダーとしてやってほしい
■XMLデータベースを用いた柔軟なUGCサービスの提案
NTTサイバースペース研究所 榎本さん
・XMLデータベース
なかなか市場が広がらない。。。
→蓄積して利用していく方向で広げていこう
モデルが違えば柔軟性も違う
→ユーザ生成コンテンツ（UGC）を構造化できるんじゃない？
イベント情報の共有サービス
http://www.craigslist.org/
http://tokyo.kijiji.co.jp/
・提案の骨子
うまく使えば、メンテフリーなシステムが作れるんじゃないか？
→テンプレートの利用
データの構造の異種性を超えられるんじゃない？
→自動レイアウト
質問1
新しい項目を増やすと検索のフィールドも増えていくのは面白い。ただ増えすぎた場合はどうするの？
→構造化をまずしてもらう。セットで使えるようなのをインテリジェントに求めるなどしたい。
質問2
スキーマの型は？
→基本的にテキストしている。型の推測か、ユーザが定義するか、方法は考えている。
質問3
教育分野にて、大学生のシラバスに使えるのでは？
→よく知らないのでまた教えてほしい
質問4
インタフェース周りがよく分からない。
→ユーザがよく使うものは残り、そうでないものは淘汰されていく。スキーマの進化があるんじゃないか？
ボトムアップにできていくところは面白い。
■Pirka'r: ブラウザ間非互換問題を解決するWebデザイナ向けツール
三菱総合研究所 飯尾さん
・様々なブラウザで問題なく閲覧できるコンテンツ作成支援
ユーザ視点で問題を見つめなおしてみるべき。
・Web標準のコンポーネント
HTML、CSS、Javascritp
同じコンテンツでも表現や動作に違いが出る（becauseブラウザ戦争など）
・WaSPのアプローチ（伽藍方式）：ブラウザベンダに注意
・バザール方式：問題のあるコンテンツを探して警告
・20万サイトを調査、142種類の非互換性（自動チェックできるのが）→3割のサイトに問題を発見
・原因の分析
オーサリングツールの問題（HPビルダー）
発注者側の意識 特定ブラウザだけ対応すりゃいいや
作成者の意識 テストに工数をかけたくない
最近はWebブラウザも増えたし、携帯からのアクセスも増えた
→支援ツールPirka'r http://pirkar.ashikunep.org/
1.標準準拠チェック
2.ブラウザ互換性チェック
3.マルチブラウザ視認チェック
？？チェックするだけ？修正候補は出してくれない？？
質問1
コミッタになれそうな人はいるのか？
→まずはJavaScriptでチェック。共同会社がひっぱってきてくれる予定
質問2
現場でWebデザインしているとIE6だと例外構造を出したりする必要がある。全部に対応しようとしている？それともばしっと？
→前の方。
■飽きずに継続利用できる情報推薦の実現に向けた試み
中央大学大学院 稲村さん
・協調フィルタリングなどの既存の推薦手法は、ユーザが感じる「飽き」という感性的な側面まで考慮していない
→「飽き」を感じる感性モデルを明らかにする
お弁当の献立作成をモデルにする！
メニューの固定化。マンネリ化。。。
・お弁当
複数のおかずからなる
素材
味 五味五色五法
色
素材
お弁当を特徴ベクトルで表現する
おかずID（素材ID、味ID、色ID、調理法ID）
今回は素材IDのみに着目
・素材IDの類似度をcos角度で求める＝マンネリ度
ガウス関数：間隔が短いとマンネリ度を感じるが、長いと感じない
シグモイド関数：ある程度似たものが続いてもマンネリを感じないが、あまりに際限なく続くとマンネリを感じる
・評価実験
提案モデル→最初の頃は累積データが少ないので過敏な結果になったが、割と近似できた
被験者によってマンネリの感じ方は大きな差がある
おかずによってマンネリ度に与える重みも違う
お弁当の色の変化もマンネリ感に影響を与える
質問1
マンネリが減っていく方のモデルは？次にカレーを何時出すか？
→マンネリを感じさせないところは調べられたけど、次においしく食べれるときの検出はしていない。
質問2
評価実験って実際に食わせてます？
→見せただけ
質問3
何故、お弁当を選んだのか？
→弁当作りの得意な子がいた
これはお弁当作成支援システムなのか？
→そう
■街メタファを用いたブックマーク整理支援システムの開発
東京農工大学 田端さん
・ソーシャルブックマークサービス
ユーザがブックマークの整理を積極的に行わない → 無秩序化
（↑整理作業に動機付けがないから）
→整理作業にゲーム性を与えて動機付けにする！
・街メタファの導入（都市建設シミュレーション：シムシティ）
都市を発展させながらブックマーク整理
ブックマークをドラッグし、その種類を選択（スポーツ、経済など）→スタジアムのアイコンがたつ
→関連性の近い建物が集中するほど発展する
→発展するとビルになったり、あばら屋になったりする。
建物がそれぞれベクトルを持ち、距離に応じて計算を行う→発展度
最終発展度と比較して、発展度が高ければ発展！低ければ衰退。。。
どのような配置が、整理された状態か？実際に作ってみた！
旅行サイトの集合とポータルサイトの集合に分かれた。
天気と旅行サイトは近かった。
質問1
背景に地図を持ってくる意味がよく分からない。街の区画をはっきりさせた方が見易くないか？
→今作ってる最中で、今後検討する。
質問2
ポータルサイトなんかは持ってるデータが多様すぎる。クラスタリングすると二次元平面上への表現が難しくないか？
→区画というもので対応したい。
ユーザがインタラクションして、何となく位置を決めるだけなのか？グループウェアに拡張する？
→する予定で居る。
===========
「飽きずに継続利用できる情報推薦」ってのはうちの研究室の先輩がやってるのにちょっと似てるかも。
先輩がやってるのは、「飽きる前にユーザの興味の揺れを感知して、新しい興味に振り向ける推薦」
……うーん、解明しようとしている内容は違うけど、ゴール的には一緒なのかな。
後で見せよう♪
この研究室ではこのテーマを今後深めていくらしいので楽しみ。
きちんと覚えておこー！
Pirka'rは結構面白そう。
推奨コードの提示機能までついてるのは、CSSに然程詳しくない身としてはかなり嬉しい。
ちょうど研究紹介サイトを新しく作り直さないといけない所だったので、ぜひぜひ使わせてもらおうと画策中♪
街メタファの導入については、品川先生の研究室の学生さんだったので、後で品川先生と話す機会があったときにちょっと疑問に思ったところを聞いてみた。
「これ初期投資が大変じゃないですか？」
そう、やってることは面白そうなんだけど、なんか最初に配置させる作業が面倒くさそうなんだよね。。。
品川先生曰く、デフォルトの配置などを提供できたら良いが、そのための理想的なデフォルト配置の情報もまだ足りない。まずは基礎的なデータを集めて行く事が必要とのこと。
あとビジュアルももうちょっと……、被験者実験前にアイコン画像が粗いのを何とかしたら、大分結果に反映されそうだなぁ。
まだまだ先は長そうなので、がんばって欲しいです。
これにてWI2の発表は全て終了。
みなさまお疲れ様でした！！
日曜日なのでお子ちゃま多数＜笑
WI2もこのセッションで終わり。
非常にためになる研究会でした。
===============
■学術研究プラットフォームのサービス提案
岡本さん
・YahooJapanで10年勤務
学術成果のプラットフォームを作りたいと考えるようになった。
・問題意識
インターネットの学術利用→ 専門分野の横断、研究者と市民の接続
→メディアの限界
→プラットフォームへの転換
学者や専門化がそれぞれ自分個人のウェブを管理し、最新の専門知識を競うように公開する時代が来れば良いと思う。
・基本コンセプト
インセンティブデザイン＝良い物を作れば作ってくれる→使わざるを得ない状況においていく
ユーザビリティ＝Web標準から遅れている
アビリゲート＝データを一元化しすぎると×（ブックマークはココ、ブログはアッチみたいな）サービスを取り込んでいく
インテリジェンス＆インタラクション！
・管理対象データの区分
Relation＝研究者同士の関連
Event＝研究会情報
Task＝TODO
Output＝上手く統合して行きたい
Process＝成果よりはプロセスをはっきり示すべきでは？
・インセンティブデザイン
自分自身に関る情報を整理→機械的な学習も必要
情報の発見
労力の削減→各種申請書類フォーマットへの対応
支援の獲得→プロセスの発表に対して、一般市民がDonateされる、Donateは謝辞や還元される
・課題
持続性 ビジネスモデル的な問題
商用利用禁止規定
依然クローズな基盤データ環境 APIを公開してくれない
質問1
プロセスを見せるのは面白い。研究者がサボってるかどうかもよく分かる。どう見せる？
→Twitter的なもので良い。等身大の研究者像を伝える。意外と研究者のブログでも研究については発信されていないから。
質問2
財閥系からの支援が得にくい。どうやって儲ける？
→ビジネスモデル的には難しい。当面は別の仕事で食っていく。透明な資金を集める。日本人は300万人の研究者がいる。学術産業をちゃんと立ち上げるべき。
質問3
国のやる仕事と民間のやる仕事は新しいところでレイヤーを引かないといけない。どのレベルまでやる事を期待している。
→基盤データを作るのは国の仕事（営利ビジネスとは立ち行かない）NIIやJSTにはデータプロバイダーとしてやってほしい
■XMLデータベースを用いた柔軟なUGCサービスの提案
NTTサイバースペース研究所 榎本さん
・XMLデータベース
なかなか市場が広がらない。。。
→蓄積して利用していく方向で広げていこう
モデルが違えば柔軟性も違う
→ユーザ生成コンテンツ（UGC）を構造化できるんじゃない？
イベント情報の共有サービス
http://www.craigslist.org/
http://tokyo.kijiji.co.jp/
・提案の骨子
うまく使えば、メンテフリーなシステムが作れるんじゃないか？
→テンプレートの利用
データの構造の異種性を超えられるんじゃない？
→自動レイアウト
質問1
新しい項目を増やすと検索のフィールドも増えていくのは面白い。ただ増えすぎた場合はどうするの？
→構造化をまずしてもらう。セットで使えるようなのをインテリジェントに求めるなどしたい。
質問2
スキーマの型は？
→基本的にテキストしている。型の推測か、ユーザが定義するか、方法は考えている。
質問3
教育分野にて、大学生のシラバスに使えるのでは？
→よく知らないのでまた教えてほしい
質問4
インタフェース周りがよく分からない。
→ユーザがよく使うものは残り、そうでないものは淘汰されていく。スキーマの進化があるんじゃないか？
ボトムアップにできていくところは面白い。
■Pirka'r: ブラウザ間非互換問題を解決するWebデザイナ向けツール
三菱総合研究所 飯尾さん
・様々なブラウザで問題なく閲覧できるコンテンツ作成支援
ユーザ視点で問題を見つめなおしてみるべき。
・Web標準のコンポーネント
HTML、CSS、Javascritp
同じコンテンツでも表現や動作に違いが出る（becauseブラウザ戦争など）
・WaSPのアプローチ（伽藍方式）：ブラウザベンダに注意
・バザール方式：問題のあるコンテンツを探して警告
・20万サイトを調査、142種類の非互換性（自動チェックできるのが）→3割のサイトに問題を発見
・原因の分析
オーサリングツールの問題（HPビルダー）
発注者側の意識 特定ブラウザだけ対応すりゃいいや
作成者の意識 テストに工数をかけたくない
最近はWebブラウザも増えたし、携帯からのアクセスも増えた
→支援ツールPirka'r http://pirkar.ashikunep.org/
1.標準準拠チェック
2.ブラウザ互換性チェック
3.マルチブラウザ視認チェック
？？チェックするだけ？修正候補は出してくれない？？
質問1
コミッタになれそうな人はいるのか？
→まずはJavaScriptでチェック。共同会社がひっぱってきてくれる予定
質問2
現場でWebデザインしているとIE6だと例外構造を出したりする必要がある。全部に対応しようとしている？それともばしっと？
→前の方。
■飽きずに継続利用できる情報推薦の実現に向けた試み
中央大学大学院 稲村さん
・協調フィルタリングなどの既存の推薦手法は、ユーザが感じる「飽き」という感性的な側面まで考慮していない
→「飽き」を感じる感性モデルを明らかにする
お弁当の献立作成をモデルにする！
メニューの固定化。マンネリ化。。。
・お弁当
複数のおかずからなる
素材
味 五味五色五法
色
素材
お弁当を特徴ベクトルで表現する
おかずID（素材ID、味ID、色ID、調理法ID）
今回は素材IDのみに着目
・素材IDの類似度をcos角度で求める＝マンネリ度
ガウス関数：間隔が短いとマンネリ度を感じるが、長いと感じない
シグモイド関数：ある程度似たものが続いてもマンネリを感じないが、あまりに際限なく続くとマンネリを感じる
・評価実験
提案モデル→最初の頃は累積データが少ないので過敏な結果になったが、割と近似できた
被験者によってマンネリの感じ方は大きな差がある
おかずによってマンネリ度に与える重みも違う
お弁当の色の変化もマンネリ感に影響を与える
質問1
マンネリが減っていく方のモデルは？次にカレーを何時出すか？
→マンネリを感じさせないところは調べられたけど、次においしく食べれるときの検出はしていない。
質問2
評価実験って実際に食わせてます？
→見せただけ
質問3
何故、お弁当を選んだのか？
→弁当作りの得意な子がいた
これはお弁当作成支援システムなのか？
→そう
■街メタファを用いたブックマーク整理支援システムの開発
東京農工大学 田端さん
・ソーシャルブックマークサービス
ユーザがブックマークの整理を積極的に行わない → 無秩序化
（↑整理作業に動機付けがないから）
→整理作業にゲーム性を与えて動機付けにする！
・街メタファの導入（都市建設シミュレーション：シムシティ）
都市を発展させながらブックマーク整理
ブックマークをドラッグし、その種類を選択（スポーツ、経済など）→スタジアムのアイコンがたつ
→関連性の近い建物が集中するほど発展する
→発展するとビルになったり、あばら屋になったりする。
建物がそれぞれベクトルを持ち、距離に応じて計算を行う→発展度
最終発展度と比較して、発展度が高ければ発展！低ければ衰退。。。
どのような配置が、整理された状態か？実際に作ってみた！
旅行サイトの集合とポータルサイトの集合に分かれた。
天気と旅行サイトは近かった。
質問1
背景に地図を持ってくる意味がよく分からない。街の区画をはっきりさせた方が見易くないか？
→今作ってる最中で、今後検討する。
質問2
ポータルサイトなんかは持ってるデータが多様すぎる。クラスタリングすると二次元平面上への表現が難しくないか？
→区画というもので対応したい。
ユーザがインタラクションして、何となく位置を決めるだけなのか？グループウェアに拡張する？
→する予定で居る。
===========
「飽きずに継続利用できる情報推薦」ってのはうちの研究室の先輩がやってるのにちょっと似てるかも。
先輩がやってるのは、「飽きる前にユーザの興味の揺れを感知して、新しい興味に振り向ける推薦」
……うーん、解明しようとしている内容は違うけど、ゴール的には一緒なのかな。
後で見せよう♪
この研究室ではこのテーマを今後深めていくらしいので楽しみ。
きちんと覚えておこー！
Pirka'rは結構面白そう。
推奨コードの提示機能までついてるのは、CSSに然程詳しくない身としてはかなり嬉しい。
ちょうど研究紹介サイトを新しく作り直さないといけない所だったので、ぜひぜひ使わせてもらおうと画策中♪
街メタファの導入については、品川先生の研究室の学生さんだったので、後で品川先生と話す機会があったときにちょっと疑問に思ったところを聞いてみた。
「これ初期投資が大変じゃないですか？」
そう、やってることは面白そうなんだけど、なんか最初に配置させる作業が面倒くさそうなんだよね。。。
品川先生曰く、デフォルトの配置などを提供できたら良いが、そのための理想的なデフォルト配置の情報もまだ足りない。まずは基礎的なデータを集めて行く事が必要とのこと。
あとビジュアルももうちょっと……、被験者実験前にアイコン画像が粗いのを何とかしたら、大分結果に反映されそうだなぁ。
まだまだ先は長そうなので、がんばって欲しいです。
これにてWI2の発表は全て終了。
みなさまお疲れ様でした！！
第15回WI2研究会 2日目セッション3「ユーザ行動分析とWebページ解析」
2日目午前の後半戦。
空腹との戦いでした。
============
■リアルタイム閲覧者ネットワークによる検索システムの提案
京都産業大学 松井さん
・背景と問題点
情報取得：検索サービス、コミュニケーションサービス
→Webページをライブで閲覧しているユーザのネットワークをリアルタイムで構築
・Wiredシステム
ライブ検索機能
ライブ閲覧者の発見
注目記事をすばやく発見
ページコミュニケーション機能
同じ興味を持つユーザからの支援
・システム概要
リアルタイムな閲覧人数に基づいて既存の検索エンジンによって返される結果をリランキング（人数順）
Firefoxアドオンで実現しているっぽい
同一ページ閲覧ユーザとコミュニケーションが行える
ページに入ると、そのページ内にいる別のユーザが緑色の●として浮いてチャットができる。
・アドオンのダウンロードページ
http://klab.kyoto-su.ac.jp/~matui
質問1
同じページを見ているからといって同じ興味を持つのか？探している者同士だとお互いにそのテーマが分かっていないのでは？
→アバウトに考えてるので、もうちょっと考察した方が良いとは考えている。
質問2
どういうユーザを想定しているのか？新しいコミュニケーションメディアを提案しているのか検索システムを提案しているのか？
→同列に考えいている
質問3
たくさんの人が使ったら破綻しちゃいそう。
→ユーザの表示上限数は提示できる。目的別のチャットルームを立てる。
質問4
同時閲覧しているかはサーバ管理。検索結果のコンテンツからさらにリンクをクリックとれる？
→とれる
質問5
実際にWebページをみているひとが一覧で出たサービスがあった気がするんだけど、
→検索と組み合わせてユーザの発見をやりやすくしている点は独自性がある。
■非タスク試行型対話システムにおける非同期並列的相互作用による言語獲得手法の提案
北海道大学 若原さん
・雑談のできるロボット＝非タスク志向型対話システム
・知識源としてWebを用いる→予め何でも知っているように見えるシステムができる
→コストが高い
・チャットルームを公開し多数のユーザに利用してもらう→人間との対話から学習する
→少しずつ話せるようにする
・非同期並列的相互作用
システムとユーザがきれいに交互というのが多くのシステム。
実際のチャット：必ずしも二者ではないし、交互でもない。
→内部状態を挟んで入力フェーズと出力フェーズが独立している
・入力フェーズ
4文字部分のWindowを使ってセグメント分割
セグメントを発話キャッシュに保存
・出力フェーズ
内部状態を常に監視し、内部状態でもっとも重みの高いセグメントを発話 （マルコフ連鎖）
・miniブログ上に人間と対話を行うシステムを実装
→Twitterにて公開 ＠hadzimmo
人間同士の対話から学習
全く白紙の初期状態→現在：学習開始から1ヶ月程度
キャッシュ：対話の開始から終了まで保持
対話の観測対象ユーザ数300人
対話に実際に参加9名
「おはよう」「おかえり」くらいは出来たらしい。他にも。
「デートしてください」「喜ん。。。wwww」
「おはようございます」「おめでとうございます」
「お、お疲れ様です」「仙台から乙ありでーす」
※ ちょっと笑える。おもろー！
・考察
学習量がたりない
整合性のない対話が多く見られた
・今後の課題
マルコフ連鎖に代わる発話生成方の開発
あいづちの挿入
ユーザの感情を判断
質問1
Twitterをターゲットにしたのは？
→チャットらしいチャットだと、話題が錯綜して対応できない。Twitterだと大体一つの話題でまとまっている。
Twitterは頻繁に会話にならない。あまり会話らしい会話ができない。
→今のままでは困難なので、Twitterに限らずにやっていきたい。
質問2
雑談を成立させようとすると、意味の塊が重要になってくる。表層を貯めていくと、意味に転換することを考えているのか？それともある程度データをためたら、内部に意味を組み込むようなフェーズに踏み込むのか？
→今のところ表層以外を考えていない。今後検討する。
質問3
ワンパターンな会話に陥ってしまわないか？
→出力リストの一番上のものだけを用いるのではなく、ランダムで出力している。
■情報探索プロセスにおける利用者の検索履歴活用行動の分析
筑波大学 松村さん
・モチベーション：Googleなどの検索システムが持つ多様な機能は、本当に情報探索に役立っているのか？
・利用者の情報探索プロセスを明らかにする
→今回は検索履歴の活用、どんなとき、何故、どのように使ってるのか
→検索履歴の有効な使い方を明らかにする
・実験 2007年8月～2008年5月
協力者：10名（図書館情報学、看護学、教育学、医学） エキスパート？？
フェーズ1 自分でテーマを決定、文献収集、適合判定 どんなテーマがあったの？？
フェーズ2 追加収集
ここまでは通常の検索システム
フェーズ3 履歴活用行動取得実験（ログ、発話思考法、インタビューなど）
履歴を見ながらやってもらった
タスク1 過去に自分が検索したテーマで5件
タスク2 過去に自分が検索していない、他者がやったテーマで3件
関連クエリ(検索キーワード)＝テーマ
適合だと思ったってのはどうやって抽出しているの？？
他者の関連文献について、入力キーワードの妥当性が確認できる
検索戦略の切り替え、自分他人の渡り歩き→行き詰ったとき、レスポンスがおそいとき
・今後
ミクロな分析からプロセス全体へ
質問1
ログの量に差はなかった？
→かなりあった。
■ユーザ関与を伴った推薦方式設計
大阪大学 甲斐さん
・モチベーション：推薦の精度はある程度向上した、今後は精度向上だけでなくユーザ満足度を向上させるべき
・ユーザ関与
ユーザが推薦仮定に介入し、推薦機構を制御すること
ユーザ負荷を下げる
MediaUnbound：35もの質問に答える必要がある
eHarmony：一時間程度かかるアンケート ユーザ負荷がかかるが
？？どういうユーザを対象にしているかによりけりで、負荷に耐えられるかどうかは何を得たいかによるのでは？？
・提案手法
推薦過程に関与すると言う好意事態が満足度に影響するのでは
音楽推薦システムを実装、
どのような関与を用いるか
どうのような推薦アルゴリズムを用いるか？
・Rating（好き、嫌い）
・コンテキスト入力（いつ、どこで、誰と）：ユーザの嗜好は状況によって違う
・コンテンツ属性指定（推薦してほしいコンテンツの属性を明示的に指定）
・プロファイル編集（ユーザプロファイルの可視化）
推薦結果にRatingするのは全部同じ。
関与を反映しているグループと反映していないグループの2とおり。
ベイズ推定を用いた内容に基づくフィルタリング
ユーザが好きな曲・好きでない曲のコンテンツ属性の頻度を学習
各楽曲をユーザが好む確率を学習
？？夜好きな曲っていう曲の属性情報はどうやって求めている？？
・分析項目
満足度
関与の度合い
推薦精度
被験者の音楽に対する興味の度合い
質問1
コンテンツ量が増大した場合、コンテンツの属性をどうやって対応するのか？
→ユーザに評価してもらう。またランダムに幾つかとって評価してもらい、それで補完していく。
質問2
負荷に耐えられるかどうかは何を得たいかによるのでは？
→実験で真剣さについても検討する。
■Webページ間の共通性の発見に基づく多層的な発見に基づく多層的なWeb閲覧セッションの抽出
兵庫県立大学 木村さん
・閲覧履歴を多層的に表現する手法
・Web閲覧セッションとする
→ラベルを付与し、一繋がりを1セッションとする
・上位階層の発見
となりあうセッション同士をTF-IDFで主な用語を抜き出し、重なった用語の中で分散が最小の語を上位階層ワードとする
・下位階層の発見
各ページの候補キーワードの和集合を求め、なんちゃらかんちゃら
・実験
セッション切れ目に失敗が多い
質問1
情報推薦に結び付けたいとはどうやった形なのか？推薦に利用するとなるとどういう風な粒度でどういう風にとるのかが影響するのでは？
→割と楽観的に考えている。ゴールを先に決めておくべきだった。
研究で整理された事項が、役立つようにしてほしい。
質問2
将来像があまり明確でないようだが、、、グルーピングした結果をユーザに見せてあげて推薦するのか、取った情報を裏方として使うのか？
→裏方として考えている。
その場合、かなり精度が必要になる。インタラクションしながらだと、もうちょっと気持ち悪さはないのでそちらを考えてはどうか？
質問3
内容に加えてアクセスや時間は活用するの？
→していない。
■ソーシャルブックマークの分析に基づく競合Webページの発見
兵庫県立大学 湯本さん
・目的：ソーシャルブックマークを用いて競合ページを発見し、その情報を用いて対象ページの価値判断を支援する
競合Webページの定義：分類できる最も細かいカテゴリが対象ページと同じWebページ
タグの親子関係を求め、代表タグ集合（ページに付与された主要なタグのうち、子を持たないトピックタグ）を形成する
↑親子関係そのものはソーシャルブックマークから調べる
・提案手法
1.対象ページの代表タグ集合を取得
2.代表タグ集合内のタグが用いられるページ集合を取得
3.ランキングするっぽい
ブックマークされていないWebページ：自動タグ付け（Tf-idfなどを使う）
競合Webページへのリンクを提示してあげる。
？？Googleでいう関連ページのことかな？？
・予備実験
代表タグ集合によるページ集合の取得→条件の緩和が必要
自動タグ付けの精度確認→不正解のタグを含んでしまうことが多かった
質問1
タグを階層化するべきか？もともとタグはディレクトリ構造へのアンチテーゼでは？
→完全に全てを階層化するわけではない。
親子関係というのは完全なツリー構造なのではない？
→そのとおり。
競合Webページというより、分類が同種であるというニュアンスを持たせた方が良い。
============
ハジモ君は面白かった。
後でTwitter見に行ったけど。。。なかなか苦労していらっしゃるようで＜苦笑
一番興味があったのは「ユーザ関与を伴った推薦方式」
これは「設計」というよりも、ユーザ関与と推薦の精度の両者の「相関を定式化」する研究として捉えるべきかな。
大変興味深い研究。結果が楽しみ。
音楽を対象にしてるなら、Music Genome Projectとかも良い感じに使えそう。
ユーザが提供するデータが増えれば増えるほど勿論推薦の精度はあがる。
ただそれを嫌がったり面倒くさがるユーザが多いから、クリック履歴や閲覧履歴からこっそりユーザのデータを取ってくる方向に今は進んでいる。。。
見つかる.jpとかはそこを思いっきり踏み倒して、ユーザに面倒くさい入力を求める代わりに的確な商品の推薦を行うように工夫されている。（ファジィ理論も少しあるみたい）
あそこらへんのユーザ関与を「定式化」できれば推薦に良い指標が生まれそうだなぁ。
空腹との戦いでした。
============
■リアルタイム閲覧者ネットワークによる検索システムの提案
京都産業大学 松井さん
・背景と問題点
情報取得：検索サービス、コミュニケーションサービス
→Webページをライブで閲覧しているユーザのネットワークをリアルタイムで構築
・Wiredシステム
ライブ検索機能
ライブ閲覧者の発見
注目記事をすばやく発見
ページコミュニケーション機能
同じ興味を持つユーザからの支援
・システム概要
リアルタイムな閲覧人数に基づいて既存の検索エンジンによって返される結果をリランキング（人数順）
Firefoxアドオンで実現しているっぽい
同一ページ閲覧ユーザとコミュニケーションが行える
ページに入ると、そのページ内にいる別のユーザが緑色の●として浮いてチャットができる。
・アドオンのダウンロードページ
http://klab.kyoto-su.ac.jp/~matui
質問1
同じページを見ているからといって同じ興味を持つのか？探している者同士だとお互いにそのテーマが分かっていないのでは？
→アバウトに考えてるので、もうちょっと考察した方が良いとは考えている。
質問2
どういうユーザを想定しているのか？新しいコミュニケーションメディアを提案しているのか検索システムを提案しているのか？
→同列に考えいている
質問3
たくさんの人が使ったら破綻しちゃいそう。
→ユーザの表示上限数は提示できる。目的別のチャットルームを立てる。
質問4
同時閲覧しているかはサーバ管理。検索結果のコンテンツからさらにリンクをクリックとれる？
→とれる
質問5
実際にWebページをみているひとが一覧で出たサービスがあった気がするんだけど、
→検索と組み合わせてユーザの発見をやりやすくしている点は独自性がある。
■非タスク試行型対話システムにおける非同期並列的相互作用による言語獲得手法の提案
北海道大学 若原さん
・雑談のできるロボット＝非タスク志向型対話システム
・知識源としてWebを用いる→予め何でも知っているように見えるシステムができる
→コストが高い
・チャットルームを公開し多数のユーザに利用してもらう→人間との対話から学習する
→少しずつ話せるようにする
・非同期並列的相互作用
システムとユーザがきれいに交互というのが多くのシステム。
実際のチャット：必ずしも二者ではないし、交互でもない。
→内部状態を挟んで入力フェーズと出力フェーズが独立している
・入力フェーズ
4文字部分のWindowを使ってセグメント分割
セグメントを発話キャッシュに保存
・出力フェーズ
内部状態を常に監視し、内部状態でもっとも重みの高いセグメントを発話 （マルコフ連鎖）
・miniブログ上に人間と対話を行うシステムを実装
→Twitterにて公開 ＠hadzimmo
人間同士の対話から学習
全く白紙の初期状態→現在：学習開始から1ヶ月程度
キャッシュ：対話の開始から終了まで保持
対話の観測対象ユーザ数300人
対話に実際に参加9名
「おはよう」「おかえり」くらいは出来たらしい。他にも。
「デートしてください」「喜ん。。。wwww」
「おはようございます」「おめでとうございます」
「お、お疲れ様です」「仙台から乙ありでーす」
※ ちょっと笑える。おもろー！
・考察
学習量がたりない
整合性のない対話が多く見られた
・今後の課題
マルコフ連鎖に代わる発話生成方の開発
あいづちの挿入
ユーザの感情を判断
質問1
Twitterをターゲットにしたのは？
→チャットらしいチャットだと、話題が錯綜して対応できない。Twitterだと大体一つの話題でまとまっている。
Twitterは頻繁に会話にならない。あまり会話らしい会話ができない。
→今のままでは困難なので、Twitterに限らずにやっていきたい。
質問2
雑談を成立させようとすると、意味の塊が重要になってくる。表層を貯めていくと、意味に転換することを考えているのか？それともある程度データをためたら、内部に意味を組み込むようなフェーズに踏み込むのか？
→今のところ表層以外を考えていない。今後検討する。
質問3
ワンパターンな会話に陥ってしまわないか？
→出力リストの一番上のものだけを用いるのではなく、ランダムで出力している。
■情報探索プロセスにおける利用者の検索履歴活用行動の分析
筑波大学 松村さん
・モチベーション：Googleなどの検索システムが持つ多様な機能は、本当に情報探索に役立っているのか？
・利用者の情報探索プロセスを明らかにする
→今回は検索履歴の活用、どんなとき、何故、どのように使ってるのか
→検索履歴の有効な使い方を明らかにする
・実験 2007年8月～2008年5月
協力者：10名（図書館情報学、看護学、教育学、医学） エキスパート？？
フェーズ1 自分でテーマを決定、文献収集、適合判定 どんなテーマがあったの？？
フェーズ2 追加収集
ここまでは通常の検索システム
フェーズ3 履歴活用行動取得実験（ログ、発話思考法、インタビューなど）
履歴を見ながらやってもらった
タスク1 過去に自分が検索したテーマで5件
タスク2 過去に自分が検索していない、他者がやったテーマで3件
関連クエリ(検索キーワード)＝テーマ
適合だと思ったってのはどうやって抽出しているの？？
他者の関連文献について、入力キーワードの妥当性が確認できる
検索戦略の切り替え、自分他人の渡り歩き→行き詰ったとき、レスポンスがおそいとき
・今後
ミクロな分析からプロセス全体へ
質問1
ログの量に差はなかった？
→かなりあった。
■ユーザ関与を伴った推薦方式設計
大阪大学 甲斐さん
・モチベーション：推薦の精度はある程度向上した、今後は精度向上だけでなくユーザ満足度を向上させるべき
・ユーザ関与
ユーザが推薦仮定に介入し、推薦機構を制御すること
ユーザ負荷を下げる
MediaUnbound：35もの質問に答える必要がある
eHarmony：一時間程度かかるアンケート ユーザ負荷がかかるが
？？どういうユーザを対象にしているかによりけりで、負荷に耐えられるかどうかは何を得たいかによるのでは？？
・提案手法
推薦過程に関与すると言う好意事態が満足度に影響するのでは
音楽推薦システムを実装、
どのような関与を用いるか
どうのような推薦アルゴリズムを用いるか？
・Rating（好き、嫌い）
・コンテキスト入力（いつ、どこで、誰と）：ユーザの嗜好は状況によって違う
・コンテンツ属性指定（推薦してほしいコンテンツの属性を明示的に指定）
・プロファイル編集（ユーザプロファイルの可視化）
推薦結果にRatingするのは全部同じ。
関与を反映しているグループと反映していないグループの2とおり。
ベイズ推定を用いた内容に基づくフィルタリング
ユーザが好きな曲・好きでない曲のコンテンツ属性の頻度を学習
各楽曲をユーザが好む確率を学習
？？夜好きな曲っていう曲の属性情報はどうやって求めている？？
・分析項目
満足度
関与の度合い
推薦精度
被験者の音楽に対する興味の度合い
質問1
コンテンツ量が増大した場合、コンテンツの属性をどうやって対応するのか？
→ユーザに評価してもらう。またランダムに幾つかとって評価してもらい、それで補完していく。
質問2
負荷に耐えられるかどうかは何を得たいかによるのでは？
→実験で真剣さについても検討する。
■Webページ間の共通性の発見に基づく多層的な発見に基づく多層的なWeb閲覧セッションの抽出
兵庫県立大学 木村さん
・閲覧履歴を多層的に表現する手法
・Web閲覧セッションとする
→ラベルを付与し、一繋がりを1セッションとする
・上位階層の発見
となりあうセッション同士をTF-IDFで主な用語を抜き出し、重なった用語の中で分散が最小の語を上位階層ワードとする
・下位階層の発見
各ページの候補キーワードの和集合を求め、なんちゃらかんちゃら
・実験
セッション切れ目に失敗が多い
質問1
情報推薦に結び付けたいとはどうやった形なのか？推薦に利用するとなるとどういう風な粒度でどういう風にとるのかが影響するのでは？
→割と楽観的に考えている。ゴールを先に決めておくべきだった。
研究で整理された事項が、役立つようにしてほしい。
質問2
将来像があまり明確でないようだが、、、グルーピングした結果をユーザに見せてあげて推薦するのか、取った情報を裏方として使うのか？
→裏方として考えている。
その場合、かなり精度が必要になる。インタラクションしながらだと、もうちょっと気持ち悪さはないのでそちらを考えてはどうか？
質問3
内容に加えてアクセスや時間は活用するの？
→していない。
■ソーシャルブックマークの分析に基づく競合Webページの発見
兵庫県立大学 湯本さん
・目的：ソーシャルブックマークを用いて競合ページを発見し、その情報を用いて対象ページの価値判断を支援する
競合Webページの定義：分類できる最も細かいカテゴリが対象ページと同じWebページ
タグの親子関係を求め、代表タグ集合（ページに付与された主要なタグのうち、子を持たないトピックタグ）を形成する
↑親子関係そのものはソーシャルブックマークから調べる
・提案手法
1.対象ページの代表タグ集合を取得
2.代表タグ集合内のタグが用いられるページ集合を取得
3.ランキングするっぽい
ブックマークされていないWebページ：自動タグ付け（Tf-idfなどを使う）
競合Webページへのリンクを提示してあげる。
？？Googleでいう関連ページのことかな？？
・予備実験
代表タグ集合によるページ集合の取得→条件の緩和が必要
自動タグ付けの精度確認→不正解のタグを含んでしまうことが多かった
質問1
タグを階層化するべきか？もともとタグはディレクトリ構造へのアンチテーゼでは？
→完全に全てを階層化するわけではない。
親子関係というのは完全なツリー構造なのではない？
→そのとおり。
競合Webページというより、分類が同種であるというニュアンスを持たせた方が良い。
============
ハジモ君は面白かった。
後でTwitter見に行ったけど。。。なかなか苦労していらっしゃるようで＜苦笑
一番興味があったのは「ユーザ関与を伴った推薦方式」
これは「設計」というよりも、ユーザ関与と推薦の精度の両者の「相関を定式化」する研究として捉えるべきかな。
大変興味深い研究。結果が楽しみ。
音楽を対象にしてるなら、Music Genome Projectとかも良い感じに使えそう。
ユーザが提供するデータが増えれば増えるほど勿論推薦の精度はあがる。
ただそれを嫌がったり面倒くさがるユーザが多いから、クリック履歴や閲覧履歴からこっそりユーザのデータを取ってくる方向に今は進んでいる。。。
見つかる.jpとかはそこを思いっきり踏み倒して、ユーザに面倒くさい入力を求める代わりに的確な商品の推薦を行うように工夫されている。（ファジィ理論も少しあるみたい）
あそこらへんのユーザ関与を「定式化」できれば推薦に良い指標が生まれそうだなぁ。
第15回WI2研究会 2日目セッション2「評価・サービス統合」
遅刻しました。
ホント申し訳ないです。
まさか、ICOCAのチャージが0円になってるとは思わず、駅に駆け込もうとしたところで
ピンポーン☆
泣く泣く切符を買ってる間に電車は行ってしまいました。。。
私の阿呆。。。
幸先の悪いスタートでしたが、発表はきっちりと聞かせていただきました。
以下、メモです。
===============
■関連単語抽出アルゴリズムの改良と評価
九州大学 倉門先生
・提案手法
関連語の抽出：TF-IDFを用い、ある範囲内にある語のみに絞り、目的語に近い語に高い評価値を与える。
複数文書間の重み付け：文書頻度の逆数（IDF）を利用して、多くの文書に習われる単語の評価値を抑える
→語数の多いテキストの重みを抑えるために、正規化を行う
？？今まで正規化しなかったのか？？
・実験
従来手法、提案手法、従来手法＋局所的重み付け、従来手法＋大局的重み付け、TF、IDF。
元データはGoogleの検索結果の上位ページ：検索結果が不良となるクエリを用いるべき？
被験者４人、４パターンで確認。
→平均値は向上した。
質問1
限定する範囲は、段落をまたいだ場合でも有効なのか？
→今は有効になっている。今後は対応していきたい。
質問2
Googleのサジェストと真っ向からぶつかるところを目指している。瞬時に候補を出せるメリットがある。
→Googleサジェストの結果と比較すると、Googleの方が履歴を利用しているので真っ当な感じがする。
質問3
統計的なベーシックな手法だと感じた。クエリの分野マップを見たときに自分の研究はどこに位置していると思うか？
→今後関連研究についても詳しく調べる
質問4
実験について詳しく教えてほしい
提案手法のスコアが高い方がユーザが高く評価していると本当に言えるのか？
質問5
どういうページを検索したいんでしょうか？不良なページを使うと結局精度が下がってしまうのでは？
→かも知れない。
■ODPを利用したユーザプロファイル作成と個別化検索システムの評価
九州大学 中村さん
・研究背景
→検索システムの性能の向上が必要
・ODP Open Direcotry Project
話題の階層向上でWebページを分類した世界最大のWebディレクトリ
人手に寄ってWebページを分類
・提案手法
ODPの各ディレクトリに属するWebページの内容に着目
トップだけでなく、ODPの上位2階層を利用したユーザの興味・関心を細かく表現したユーザプロファイルの作成
・ユーザプロファイルの作成
ODPの各ディレクトリをインデックスとするベクトル
従来手法ではODPの各最上位ディレクトリをインデックスとしたベクトルで表現
→提案手法：下位ディレクトリ2層目まで。細かなプロファイリングが可能
1.ODPに属するWebページ群から単語を抽出
2.各単語が各ディレクトリにどのくらい関連しているか？
3.パーソナルドキュメントから単語を抽出（E-mailとか）
4.関連度を見る
一般のWeb検索エンジンで検索された結果をReranking
↑ベクトルの比較はcos類似度を用いる、これの順にランキング
各単語の関連度算出→エントロピー
ページベクトル：Webページのディレクトリへの関連度
最上位ディレクトリの選定
初期検索結果の上位10件、20件のタイトルとSNIPPET（紹介文）から単語を抽出
ODP最上位ディレクトリの関連度を求め、一番大きいのを選定
・評価実験
初期検索における適合率が50％以下のものを使用する。
？？この実験条件は不味くないか？？
ここでちょっと力尽きた。。。
質問1
ページを一つ選んだらそれを基準にRerankingする。最初に選んだページが本当にパーソナルデータであるのか？
→一応、全部に目を通してもらってから選んでもらっている。
複数のカテゴリにまたがるような文書がほしい場合は最大のディレクトリ一つをとるのは適切な結果をだせるのか？例えば証券システムがダウン場合、経済、システム対応の2つが見たい
→プロファイルのベクトルが両方のカテゴリに対して値を持っていれば、見つけることはできる
質問2
一番上のところでは粒度が粗すぎて、もっと下の方を見ないといけないのでは？
→階層構造なので、下が膨大になってしまうので
それは分かるが、そういう問題に立ち向かうにはこれと戦わないといけない
→今回1、2層と広げてみた。今後も掘り下げていきたいと思っている。
どういうユーザが対象のシステムなのか？
→検索のときに自分の見たいページをうまく見つけたいというユーザ全般。
リランキングしたいんであれば、もっと最初のところから入っていかないといけないのでは？
質問3
第一階層よりも第二階層の方が粒度が上がる？パーソナルデータから出たtf-idfを使った方が良いのでは？何故ODPを使ったのかがよく分からない。
→単にカテゴリを使おうと思った。
■拡張可能関係データベース管理システムを用いたWebサービス統合
山口大学 松井さん（同姓同名が研究室にいてビビッた。。。）
・提案手法
それぞれ存在するWebサービスへのアクセスをSQLによる問い合わせを行う
DBMSに全てのアクセスを集中させる。
PHP/PLでユーザ関数を記述する
→ユーザ自身の手で作るのは負担になるし、ソフトウェアの信頼性も下がる
Pg/WAFL：ユーザ定義関数のXMLによる仕様記述
※ とりあえず帰ってくるカラム名は自力で調べる必要があるっぽい
RSSリーダとかが実装例
？？XMLデータベースを使わないのか？？
・Webサービス
HTTPを用いた情報交換によりサービス
XMLで利用（SOAPなど）
・関連研究
EaRDB：ユーア定義関数を用いてWebサービスにアクセス。ユーザ定義関数の自動生成はできない。
YahooQueryLanguage：データソースのXMLによる記述を与える。複数のWebサービスへのアクセスは不可。
質問1
PgWAFLはWPLに比べるとアプリケーションよりの技術になっているのでは？あまり手間が減らないんじゃ？
→調査不足もあってWPLなどにあわせた記述にすべきだった。
RESTを対象としているところで結構ややこしいように思える。RSSについてもベンダ独自だったり、して大混乱する。Webアプリケーションの開発では統合的な記述としては解決できてないのでは？どの辺まで解決したいの？
SOAPはXMLのフォーマットで仕様記述が完全だけど、RESTは記述に限界がある。RESTを使うなら、その辺も考えて作らないといけない。
質問2
SQLの形でアクセスしようとしている。ユーザ定義関数を作るメリットは？
質問3：XMLで表現できる情報の空間とRDBで表現できる空間って違うようね？Amazonのデータは著者が複数帰ってきてその人数は分からない。その場合ユーザ定義関数はどうかけるのか？
→対応できない。
XMLとRDBの本質的な違いになる部分をちゃんと定義できるようにしてしまわないと難しい。
質問4
認証付きサービスについては考えているの？
質問5
全検索結果からのどこからどこまで取る？
→ページ数の指定はできる
全ての検索結果をえるのに何度もリクエストをしないといけない場合もある。それは大丈夫？
→ユーザ定義処理の中に繰り返し記述をする。
===============
関連単語の抽出とODPは、結構うちの研究室でも使えそうな技術だな。
Webサービス統合は魅力的な提案ではあるけど、やっぱり難しそう。
XMLDBを使えば良いのにと簡単に考えていたけど、その後先生たちから
・XMLDBの知名度や実用性
・XMLDBの形がアプリケーション実装者にとって嬉しい形なのか
という問題が挙がった。。。確かに。
それにWebサービス統合って、結局利用するアプリケーション依存、そこで拡張が激しくなってしまいそう。認証とかセキュリティの話が入ってくると尚更。
そういやRESTメインでやってたけど、確かGoogleAppsにSOAPじゃないと取れないデータがあった気が。。。ムツカシイなぁ。
ホント申し訳ないです。
まさか、ICOCAのチャージが0円になってるとは思わず、駅に駆け込もうとしたところで
ピンポーン☆
泣く泣く切符を買ってる間に電車は行ってしまいました。。。
私の阿呆。。。
幸先の悪いスタートでしたが、発表はきっちりと聞かせていただきました。
以下、メモです。
===============
■関連単語抽出アルゴリズムの改良と評価
九州大学 倉門先生
・提案手法
関連語の抽出：TF-IDFを用い、ある範囲内にある語のみに絞り、目的語に近い語に高い評価値を与える。
複数文書間の重み付け：文書頻度の逆数（IDF）を利用して、多くの文書に習われる単語の評価値を抑える
→語数の多いテキストの重みを抑えるために、正規化を行う
？？今まで正規化しなかったのか？？
・実験
従来手法、提案手法、従来手法＋局所的重み付け、従来手法＋大局的重み付け、TF、IDF。
元データはGoogleの検索結果の上位ページ：検索結果が不良となるクエリを用いるべき？
被験者４人、４パターンで確認。
→平均値は向上した。
質問1
限定する範囲は、段落をまたいだ場合でも有効なのか？
→今は有効になっている。今後は対応していきたい。
質問2
Googleのサジェストと真っ向からぶつかるところを目指している。瞬時に候補を出せるメリットがある。
→Googleサジェストの結果と比較すると、Googleの方が履歴を利用しているので真っ当な感じがする。
質問3
統計的なベーシックな手法だと感じた。クエリの分野マップを見たときに自分の研究はどこに位置していると思うか？
→今後関連研究についても詳しく調べる
質問4
実験について詳しく教えてほしい
提案手法のスコアが高い方がユーザが高く評価していると本当に言えるのか？
質問5
どういうページを検索したいんでしょうか？不良なページを使うと結局精度が下がってしまうのでは？
→かも知れない。
■ODPを利用したユーザプロファイル作成と個別化検索システムの評価
九州大学 中村さん
・研究背景
→検索システムの性能の向上が必要
・ODP Open Direcotry Project
話題の階層向上でWebページを分類した世界最大のWebディレクトリ
人手に寄ってWebページを分類
・提案手法
ODPの各ディレクトリに属するWebページの内容に着目
トップだけでなく、ODPの上位2階層を利用したユーザの興味・関心を細かく表現したユーザプロファイルの作成
・ユーザプロファイルの作成
ODPの各ディレクトリをインデックスとするベクトル
従来手法ではODPの各最上位ディレクトリをインデックスとしたベクトルで表現
→提案手法：下位ディレクトリ2層目まで。細かなプロファイリングが可能
1.ODPに属するWebページ群から単語を抽出
2.各単語が各ディレクトリにどのくらい関連しているか？
3.パーソナルドキュメントから単語を抽出（E-mailとか）
4.関連度を見る
一般のWeb検索エンジンで検索された結果をReranking
↑ベクトルの比較はcos類似度を用いる、これの順にランキング
各単語の関連度算出→エントロピー
ページベクトル：Webページのディレクトリへの関連度
最上位ディレクトリの選定
初期検索結果の上位10件、20件のタイトルとSNIPPET（紹介文）から単語を抽出
ODP最上位ディレクトリの関連度を求め、一番大きいのを選定
・評価実験
初期検索における適合率が50％以下のものを使用する。
？？この実験条件は不味くないか？？
ここでちょっと力尽きた。。。
質問1
ページを一つ選んだらそれを基準にRerankingする。最初に選んだページが本当にパーソナルデータであるのか？
→一応、全部に目を通してもらってから選んでもらっている。
複数のカテゴリにまたがるような文書がほしい場合は最大のディレクトリ一つをとるのは適切な結果をだせるのか？例えば証券システムがダウン場合、経済、システム対応の2つが見たい
→プロファイルのベクトルが両方のカテゴリに対して値を持っていれば、見つけることはできる
質問2
一番上のところでは粒度が粗すぎて、もっと下の方を見ないといけないのでは？
→階層構造なので、下が膨大になってしまうので
それは分かるが、そういう問題に立ち向かうにはこれと戦わないといけない
→今回1、2層と広げてみた。今後も掘り下げていきたいと思っている。
どういうユーザが対象のシステムなのか？
→検索のときに自分の見たいページをうまく見つけたいというユーザ全般。
リランキングしたいんであれば、もっと最初のところから入っていかないといけないのでは？
質問3
第一階層よりも第二階層の方が粒度が上がる？パーソナルデータから出たtf-idfを使った方が良いのでは？何故ODPを使ったのかがよく分からない。
→単にカテゴリを使おうと思った。
■拡張可能関係データベース管理システムを用いたWebサービス統合
山口大学 松井さん（同姓同名が研究室にいてビビッた。。。）
・提案手法
それぞれ存在するWebサービスへのアクセスをSQLによる問い合わせを行う
DBMSに全てのアクセスを集中させる。
PHP/PLでユーザ関数を記述する
→ユーザ自身の手で作るのは負担になるし、ソフトウェアの信頼性も下がる
Pg/WAFL：ユーザ定義関数のXMLによる仕様記述
※ とりあえず帰ってくるカラム名は自力で調べる必要があるっぽい
RSSリーダとかが実装例
？？XMLデータベースを使わないのか？？
・Webサービス
HTTPを用いた情報交換によりサービス
XMLで利用（SOAPなど）
・関連研究
EaRDB：ユーア定義関数を用いてWebサービスにアクセス。ユーザ定義関数の自動生成はできない。
YahooQueryLanguage：データソースのXMLによる記述を与える。複数のWebサービスへのアクセスは不可。
質問1
PgWAFLはWPLに比べるとアプリケーションよりの技術になっているのでは？あまり手間が減らないんじゃ？
→調査不足もあってWPLなどにあわせた記述にすべきだった。
RESTを対象としているところで結構ややこしいように思える。RSSについてもベンダ独自だったり、して大混乱する。Webアプリケーションの開発では統合的な記述としては解決できてないのでは？どの辺まで解決したいの？
SOAPはXMLのフォーマットで仕様記述が完全だけど、RESTは記述に限界がある。RESTを使うなら、その辺も考えて作らないといけない。
質問2
SQLの形でアクセスしようとしている。ユーザ定義関数を作るメリットは？
質問3：XMLで表現できる情報の空間とRDBで表現できる空間って違うようね？Amazonのデータは著者が複数帰ってきてその人数は分からない。その場合ユーザ定義関数はどうかけるのか？
→対応できない。
XMLとRDBの本質的な違いになる部分をちゃんと定義できるようにしてしまわないと難しい。
質問4
認証付きサービスについては考えているの？
質問5
全検索結果からのどこからどこまで取る？
→ページ数の指定はできる
全ての検索結果をえるのに何度もリクエストをしないといけない場合もある。それは大丈夫？
→ユーザ定義処理の中に繰り返し記述をする。
===============
関連単語の抽出とODPは、結構うちの研究室でも使えそうな技術だな。
Webサービス統合は魅力的な提案ではあるけど、やっぱり難しそう。
XMLDBを使えば良いのにと簡単に考えていたけど、その後先生たちから
・XMLDBの知名度や実用性
・XMLDBの形がアプリケーション実装者にとって嬉しい形なのか
という問題が挙がった。。。確かに。
それにWebサービス統合って、結局利用するアプリケーション依存、そこで拡張が激しくなってしまいそう。認証とかセキュリティの話が入ってくると尚更。
そういやRESTメインでやってたけど、確かGoogleAppsにSOAPじゃないと取れないデータがあった気が。。。ムツカシイなぁ。
第15回WI2研究会 懇親会にて
今回の飲み会は結構色んな人と話せてよかったですー。
ただやっぱり学生の多い席が一番落ち着きました；；
市立大の人たちはブログの要約やってたり主観的情報の抽出やってたり、
結構面白そうな研究しています。
主観的情報の抽出は私も興味あるところなので、是非彼には次回WI2で講演してもらいたいですねぇｗｗ
で、途中、杉原先生と斎藤先生に実験に関する講釈を受ける機会がありました。
大変勉強になりましたが、学生の席に戻ったときに「何か口から出てる」。。。
魂っぽいものが抜け出てたみたいです。
以下、杉原先生の話を個人的にまとめたもの。
酔った頭で内容を噛み砕いたんで、若干曲解も混じってるかと。。。
========
・個人を系とした斎藤先生の実験は、文化的な違いを無視して（正確には無視できるものと蓋然性の高い仮定をして）個人の経験による差異を掘り下げたもの。
社会を系とした松田先生の日本人の謙譲に関する実験は、国籍を見て、同一国籍内の個人差には重きを置いていないもの。
自分が何を掘り下げたいのかによって、対象として選ぶ被験者が、その選定基準が代わる。
・システムの有効性をみたいときはまた別。
そのシステムがどんな機能を持つか書き出して、その有効性を発揮できる対象を選ぶべき。
誰を対象にしたシステムなのか、そのためにどの機能を用意したのか、ここがアンクリアだと不味い。とりあえず学会や論文として叩かれる。
そして、それらを確立した上で、その機能がどう対象に影響を及ぼすのかを仮定として立てる。
☆機能と被験者はセットであるべき！
う～ん、私はどういう対象を選んでいるんだろう？？
ある程度ネットリテラシーがある人、即ち経験？精神状態？提示で誘導しているのか？
ちゃんと考え直さないと。
[※ここにあったものは削除しました。色々とすみません。。。]
========
こうして話が終わる頃には、私の口からエクトプラズムが……。
ついでに杉原先生にはパワポが欲しいとお願いしてみました。
せめて、参考文献だけでも欲しいわぁ。
ただやっぱり学生の多い席が一番落ち着きました；；
市立大の人たちはブログの要約やってたり主観的情報の抽出やってたり、
結構面白そうな研究しています。
主観的情報の抽出は私も興味あるところなので、是非彼には次回WI2で講演してもらいたいですねぇｗｗ
で、途中、杉原先生と斎藤先生に実験に関する講釈を受ける機会がありました。
大変勉強になりましたが、学生の席に戻ったときに「何か口から出てる」。。。
魂っぽいものが抜け出てたみたいです。
以下、杉原先生の話を個人的にまとめたもの。
酔った頭で内容を噛み砕いたんで、若干曲解も混じってるかと。。。
========
・個人を系とした斎藤先生の実験は、文化的な違いを無視して（正確には無視できるものと蓋然性の高い仮定をして）個人の経験による差異を掘り下げたもの。
社会を系とした松田先生の日本人の謙譲に関する実験は、国籍を見て、同一国籍内の個人差には重きを置いていないもの。
自分が何を掘り下げたいのかによって、対象として選ぶ被験者が、その選定基準が代わる。
・システムの有効性をみたいときはまた別。
そのシステムがどんな機能を持つか書き出して、その有効性を発揮できる対象を選ぶべき。
誰を対象にしたシステムなのか、そのためにどの機能を用意したのか、ここがアンクリアだと不味い。とりあえず学会や論文として叩かれる。
そして、それらを確立した上で、その機能がどう対象に影響を及ぼすのかを仮定として立てる。
☆機能と被験者はセットであるべき！
う～ん、私はどういう対象を選んでいるんだろう？？
ある程度ネットリテラシーがある人、即ち経験？精神状態？提示で誘導しているのか？
ちゃんと考え直さないと。
[※ここにあったものは削除しました。色々とすみません。。。]
========
こうして話が終わる頃には、私の口からエクトプラズムが……。
ついでに杉原先生にはパワポが欲しいとお願いしてみました。
せめて、参考文献だけでも欲しいわぁ。
第15回WI2研究会 1日目チュートリアル「ユーザ評価を見つめなおす」
第15回WI2研究会 チュートリアル……。
今回私がこの研究会に参加した最大の目的がここにありました。
チュートリアルがタイトルだけとは知らなかったのでガンガンメモりました。
===========
■定量調査・実験と定性的調査の基本的な考え方
北陸先端科学技術大学 杉原先生
・ユーザ行動分析が研究テーマ
現場に行って調査分析する（定量的調査、定性的調査）
・システム開発者は評価はそんなに拘らない
←→杉原先生
システムつくりはそこそこ、評価は大好き♪
・現場にとって真なるニーズ抽出法の提案
・調査、実験、実践的調査
・調査
定量的調査
質的調査
変数を一定に出来ない部分に、学問的に重要な変数が含まれている事が多い
・実験
条件を意図的に操作
・アクションリサーチ 実践的調査
研究者が現場に関与しながら
←→事例研究とよく対比される
・調査の基本的な考え方
周到な準備をした調査・実験だけが良い結果を導く
定量的調査の目的：平均的モデルを求める 文脈は無視される事が多い 仮説検証型研究
定性的調査：文脈をくみとる 仮説生成型
・尺度の種類、性質
順序尺度を感覚尺度に近づける必要がある→そういう風に実験計画を立てる
四則演算ができるのは比率尺度だけ
順序尺度は中央値を出すか、順序として出すか。だけ
・質のデータの示し方
冗長さが意外とダイナミクスの表示に大事
・理系の実験
比較対照が必要
手順、境界条件は規定済み
結果の再現性が重要視→最終的な目的が現象の制御である
・仮説検証方研究
境界は所属分野により暗黙的に決定（境界の見極めが重要）
ノイズは第3の変数として考察の対象になる
・心理実験と社会科学系の調査
手順、境界条件試行錯誤の
比較対象があると良いけど、新規性に注意！
手順の再現性が重要で結果の再現性はない
新規性が最重要、蓋然性の高い結論が重要視→最終的な目的が現象や概念の説明
・研究に求められるもの
新規性 研究そのもの
妥当性 データ
調べたい事をきちんと図る事が出来ているかということ
内的妥当性（その分野で）、外的妥当性（一般性）、理論的妥当性（自分の仮説と理論の一致）
信頼性
再現可能性→社会研究の場合結果そのものは再現されないことも多い
代表性
適切なサンプリングを行っているか
単なる特殊例ではないか？
論理性・一貫性 研究そのもの
・理系の場合は積み上げる。社会現象は掘り下げる。
社会現象を掘り下げると実は根っこが違う事が分かる
・定量的調査と定性的調査のプロセス比較
定量的調査：仮説構成→数量的データ→数量的データの分析
定性的調査：問題を収拾と分析が同時
厳密な意味ではやり直しがきかない
・質的調査
非干渉的技法
クオリティを高めるには・・・
密な記述が必要、
ユーザ：基本的に自分の都合だけで話す
研究者：キーワード的な概念を中心にご都合主義
結果を一般適することはできない
数を増やせば良いのか？否、それは定量的調査→深さ、豊かさを記述 複雑かつダイナミックな相互作用を取り扱うために向いた
・混合研究法
定量と定性の組み合わせ
・実験・定量調査の概念
・実験のメリット
実験条件を厳密に統制可能
因果関係を説明するための状況を人為的に作る
・実験のデメリット
変数を減らすためやや不自然な状況を作らざるを得ない
・被験者内計画と被験者外計画？
全ての条件に同一の被験者を参加させる→目的がばれる
1条件あたり20人が必要と言われる
かく乱変数が多く出てくる（反復による疲労や練習効果）
→ランダマイゼイション（実験の試行順序を被験者ごとに無作為に決める）
カウンタバランス（ランダムさに偏りが表れないよう各実験条件が均質化するように）
・参考文献リスト
実践的研究の進め
データはウソをつく
質的調査法入門
ユーザのための教育・心理統計と実験計画法
・枝葉話でしたが気に入った名文
『かすかな生が圧倒的な死と対峙していると言う密度の濃さ』
■ユーザの認知プロセスに着目したWebインタラクションの分析
愛知教育大学 斎藤先生
・実験的な質的な中間を分析している
認知的な視点から、学習教育的な視点へ
・経験や課題の違いによる情報探索行動の違い
どういう風にデータを分析している？被験者をどうとらえている？
・研究目的
1.認知的アプローチによるWeb情報探索プロセスの検討
2.問題解決について、Web検索の知識や経験の違いによるパフォーマンスやプロセスの違い
・被験者の選出
Webサーチ経験の多寡を基準に被験者を捕らえる
Webコンテンツの性質を感覚的に理解している
→ちょっとこれではもやっとしているので＜汗
経験の分類指標として「日常的なWeb利用、情報収集スタイル、検索エンジンに関する知識」
点数付けをして中間層を排除（単純に2分割ではなく）してグループ間の比較をし易くした
・課題の設定
事実発見課題 パフォーマンスを0/1で判断できる
日常的な課題 被験者によって知識の差がない課題
・パフォーマンスデータ
事実発見→発見できた人数：Expert＞Novice
プロセスに関するデータ→発話プロトコル：課題遂行中に頭に浮かんだ事をすべて声に出してもらった（プロトコルアナリシス）
行動データの収集：閲覧履歴、パソコン画面
・分析の仕方
科学的発見における空間探索のモデル Two space model(Simon & Lea, 1974)
実験の統制（探索の絞込み）
仮説空間（キーワード空間）→実験空間（Web空間、検索結果、ページ）
←
実験結果のフィードバック（探索結果のフィードバック）
・モデルに基づいて分析指標を提案
空間内の探索に関する指標
空間から空間に推移していくパターンの指標
・発話プロトコル
予測に関する発話、評価に関する発話
声に出し、書き起こし、コーディング(評価、予測のタグ付け)し、信頼性の確認（評定者によるコーディングの確認、結果の確認）
・行動データの分析
ProblemBehaviorGraph（PBG）
探索スキーマ
・WebにおけるExploratorySearchの分析
・研究目的
1. ExpcloratorySearchの分析
2. 視線データ
・被験者
Expert:図書館情報学専攻の大学院生
Novice:他専攻の学部生
・課題の設定
自由度の高い情報収集課題
・パフォーマンスデータ
前の＋
課題遂行後のインタビュー
視線データ
・Webページのどこをみているか？
Webページの何処を見ているか？
装置さえよければ取れる
！Webページの何を見ているか？
ページの位置≠特定の内容→コーディングでカバー
？？スクロールしちゃいけないねぇ
・相補的なデータの分析
行動データ
ブラウザログ
画面キャプチャ
視線データ
↓仮説をあてて、検証
発話プロトコル
課題遂行中・後
・レポート作成はサブタスクに分けにくい
インタビューデータの分析
→レポートに対する戦略の違い
・院生：参考文献リスト
・学部生：Webページをそのまま使おうとしている
・利用者の特性を要因とする場合
☆特性の定義やレベル分けの基準を客観的に分かるようにする→できるだけ量的な指標で基準の違いを示す
Moore(2007) SearchExperience研究のメタ分析
・課題の設定
Simulated Task：被験者間の比較が厳密
Open Ended Task：被験者の興味を反映したリアルな行動、難易度・情報量の統制が困難
どちらを選ぶかは自分が何を見たいかに関ってくるなぁ。。。ってことで。
■ゲーム理論的方法論に基づきユーザ特性を理解するための社会的心理学実験
NTTコミュニケーション科学基礎研究所 松田さん
・学生時代：社会心理学
・実験に対する熱い思いを買われ、杉原先生に呼ばれてきた。
●人間モデル
どんな結果が得られても「こうなりました」って書けばいいんでしょ？
→松田さん「このヤロー」
一回目の発表、中島さんのさんの67％って良い数字？多分良い。比較対照があればOKだったんじゃない？
・性に関する実験
1.男性が女性のイラストの魅力を評定
→ウエストとヒップの比が0.7がもっとも好まれる
2.嫉妬の性差
→男性：女性の肉体的な浮気を許せない
→女性：男性の精神的な浮気を許せない
人間モデルに照らすと明らかになる
1は子孫繁栄のため：ウェストが細いと妊娠してない→女性に対する魅力。
2も。女性は妊娠してしまうと自由に動けなくなる→父親への信頼度が重要。
・4枚カード問題
一方がひらがななら、他方は偶数でないといけない
「1」 「4」 「あ」 「イ」
対偶を利用した良い問題 → 「一方が奇数なら、他方はカタカナでないといけない」
両方カタカナだったり、両方偶数であるのはOKってことだよ！
●人を使う実験がめちゃめちゃになる理由
人はウソをつく。悪意のない嘘。
特に日本人は「謙譲」を美徳する民族なので。
ある問題をとかせる。
理論的には平均より上か下か？
何も無いと→「平均より下ですよー」が69.2%
金がかかると（予測が正解していたら100円上げます）→「平均より下ですよー」が23.2%。。。ｵｰｲ
・研究者倫理の問題
都合の良い評価実験データが得られる状況はデータの捏造と紙一重。
将来の研究者に負の遺産を残してはならない。
・実験者と参加者の間の相互作用
ギヤク効果（無自覚）→参加者が信じきり、効果が表れてしまう。。。
ピグマリオン効果→出切るというと伸びる
要求特性（自覚）→仮説を予測し、それに基づいて行動する
＊別の目的を装う＝質問紙にもあえて多様な質問項目を列挙する
＊意図的に操作できない測定法
評価懸念→知的能力・常識が試されていると懸念し、行動が変化
知人や指導学生を参加者にするとき、特に注意が必要
実験者効果→無自覚に実験者が参加者の行動を誘導してしまう
二重盲検方
・Deception（騙し）の人権倫理問題
インフォームドコンセプトに反する重大問題かも
論文では倫理委員会によるチェックが必要だったりする。。。
・参考文献
心理学研究法 高野
■フィールドマイニングの試み
大阪大学 松村先生
・もとはAI、コミュニケーション方面のひと
→分析の対象ブログ、2chもした。。。
→データマイニングの限界はどこだ？データありきの学問だよなぁ
→物理空間、フィールドを対象としたデータ分析
人間が気付くようなきっかけの方法論
行動を変化させるちょっとした工夫
・男子便器の目標→年間のトイレ掃除代が一億円くらい浮いたらしい
・ゴミ箱の口
・公演のベンチの真ん中に手すり→ホームレスが寝なくなる
・車道の絵→車の速度を下げる
・高速道の段々狭まっていく点々→車の速度を下げる
身近な道具もキッカケになる
・カメラ→撮れるものがないかと色々見るようになる
・ベビーカー→地面の段差に敏感になる
生活空間は見ているのに見ていない、聞こえているのに聞いていないことに溢れている
フィールドマイニングは人とモノと環境との関係を再構築する
→フィールドの変化がどう人の行動に変化を及ぼすか
・石橋らくがきマップ
全年齢を対象にしようと思うとオフラインな仕組みに
・外でランチ
実験をやったのが11月だったので、実用的ではなかったが外に関心は向けられた
・阪大坂を使った実験
福男
地元が炊き出ししてイベント化
次年度からは地元と市から予算が着くようになったらしい
・イメージマップを用いた
石橋という駅をもつ町のイメージ
子供がかなり集まったらしい
・ムーバブルチェア
動かせる椅子を放置して、利用の様子を観察
年齢などによって座る位置が変化した
・音を使った実験
音を聞かせてどこでやってる音かを当てさせる
・お店の落書き帳
ラン検定（連続性の検定）
■質問
to松村先生：フィールドマイニングのマイニングってどこにかかってるの？
最初は環境にいろいろセンサを取り付けるつもりだったのでこういう名前に。。。
フィールドマイニングの本来の語義は「穴をほること」です。
to松田さん：被験者を疑い出すとゴールが見えない。どこまでやれば良いかというラインはある？
出せない。結局それはみなが試行錯誤して続けていくしかない。
情報系の人がやってる実験は低い所で止まっているのではないか？
実験者効果がとくにでかいのでは？
変な基準で図ったデータが将来の人にリファらされると怖い。
to松村さん：ノーマンの行ってる認知系からプロダクトのデザインに行く。デザインの話なんだろう、それは工学者が必要とされるものだ。情報工学研究者として＋な部分、マイナスな部分を教えてほしい。
認められない。。。研究としての分野が難しい。投稿先や評価基準が分からない。もう趣味です。
to斎藤先生：エキスパートとNoviceの切り分けは統計的に見ればセーフ？
本当は指標がほしい
to皆さん：質問はない ヒューマンインタフェースの本場の学会ではチュートリアルが多い、ユーザ評価どうするか？
研究テーマになりそうな素材をなげて、評価もする
to斎藤先生：視線のデータをどう料理している？眼球運動のどういう特性を使っている。
視線データ、注視点、停留点
to斉藤先生：視線についてのデータをとるにはどのくらい勉強しないといけない？
眼球運動のデータを使って研究を行っていた人と一緒にやっている。
to杉原先生：明確な因果関係の把握は難しく、類推でしかないのでは？
質的な調査と量的な調査を組み合わせるべき→少ないデータでは因果関係をいえない
to松田さん：極度に被験者実験の条件を拘束すると、工学と実験のミッシングリングを埋められなくなるのでは？
ユーザ評価をやっつけでするなら、やらない方がいいじゃん
何でユーザ評価しないといけないのか。
===========
杉原先生の発表速過ぎ。。。
ほとんどメモれんかった。。。パワポが欲しいよ～っ(>_<)
斎藤先生の話はかなり具体的。
一通りの手順が明らかなので、参考にしたいと思います。
松田さんはとにかく面白い！しばらく研究室でネタにできそうｗｗ
あと二重盲検法について調べとこ。
松村さんの話は何か今年のMYCOMで聞いた気がするんだけど。。。後で飲み会で確認したら来てないそうなので、多分別の機会だったのかなぁ？うーん。。。
ちなみに質問を1回するという目標は達成できず。
レベル高すぎました；；
今回私がこの研究会に参加した最大の目的がここにありました。
チュートリアルがタイトルだけとは知らなかったのでガンガンメモりました。
===========
■定量調査・実験と定性的調査の基本的な考え方
北陸先端科学技術大学 杉原先生
・ユーザ行動分析が研究テーマ
現場に行って調査分析する（定量的調査、定性的調査）
・システム開発者は評価はそんなに拘らない
←→杉原先生
システムつくりはそこそこ、評価は大好き♪
・現場にとって真なるニーズ抽出法の提案
・調査、実験、実践的調査
・調査
定量的調査
質的調査
変数を一定に出来ない部分に、学問的に重要な変数が含まれている事が多い
・実験
条件を意図的に操作
・アクションリサーチ 実践的調査
研究者が現場に関与しながら
←→事例研究とよく対比される
・調査の基本的な考え方
周到な準備をした調査・実験だけが良い結果を導く
定量的調査の目的：平均的モデルを求める 文脈は無視される事が多い 仮説検証型研究
定性的調査：文脈をくみとる 仮説生成型
・尺度の種類、性質
順序尺度を感覚尺度に近づける必要がある→そういう風に実験計画を立てる
四則演算ができるのは比率尺度だけ
順序尺度は中央値を出すか、順序として出すか。だけ
・質のデータの示し方
冗長さが意外とダイナミクスの表示に大事
・理系の実験
比較対照が必要
手順、境界条件は規定済み
結果の再現性が重要視→最終的な目的が現象の制御である
・仮説検証方研究
境界は所属分野により暗黙的に決定（境界の見極めが重要）
ノイズは第3の変数として考察の対象になる
・心理実験と社会科学系の調査
手順、境界条件試行錯誤の
比較対象があると良いけど、新規性に注意！
手順の再現性が重要で結果の再現性はない
新規性が最重要、蓋然性の高い結論が重要視→最終的な目的が現象や概念の説明
・研究に求められるもの
新規性 研究そのもの
妥当性 データ
調べたい事をきちんと図る事が出来ているかということ
内的妥当性（その分野で）、外的妥当性（一般性）、理論的妥当性（自分の仮説と理論の一致）
信頼性
再現可能性→社会研究の場合結果そのものは再現されないことも多い
代表性
適切なサンプリングを行っているか
単なる特殊例ではないか？
論理性・一貫性 研究そのもの
・理系の場合は積み上げる。社会現象は掘り下げる。
社会現象を掘り下げると実は根っこが違う事が分かる
・定量的調査と定性的調査のプロセス比較
定量的調査：仮説構成→数量的データ→数量的データの分析
定性的調査：問題を収拾と分析が同時
厳密な意味ではやり直しがきかない
・質的調査
非干渉的技法
クオリティを高めるには・・・
密な記述が必要、
ユーザ：基本的に自分の都合だけで話す
研究者：キーワード的な概念を中心にご都合主義
結果を一般適することはできない
数を増やせば良いのか？否、それは定量的調査→深さ、豊かさを記述 複雑かつダイナミックな相互作用を取り扱うために向いた
・混合研究法
定量と定性の組み合わせ
・実験・定量調査の概念
・実験のメリット
実験条件を厳密に統制可能
因果関係を説明するための状況を人為的に作る
・実験のデメリット
変数を減らすためやや不自然な状況を作らざるを得ない
・被験者内計画と被験者外計画？
全ての条件に同一の被験者を参加させる→目的がばれる
1条件あたり20人が必要と言われる
かく乱変数が多く出てくる（反復による疲労や練習効果）
→ランダマイゼイション（実験の試行順序を被験者ごとに無作為に決める）
カウンタバランス（ランダムさに偏りが表れないよう各実験条件が均質化するように）
・参考文献リスト
実践的研究の進め
データはウソをつく
質的調査法入門
ユーザのための教育・心理統計と実験計画法
・枝葉話でしたが気に入った名文
『かすかな生が圧倒的な死と対峙していると言う密度の濃さ』
■ユーザの認知プロセスに着目したWebインタラクションの分析
愛知教育大学 斎藤先生
・実験的な質的な中間を分析している
認知的な視点から、学習教育的な視点へ
・経験や課題の違いによる情報探索行動の違い
どういう風にデータを分析している？被験者をどうとらえている？
・研究目的
1.認知的アプローチによるWeb情報探索プロセスの検討
2.問題解決について、Web検索の知識や経験の違いによるパフォーマンスやプロセスの違い
・被験者の選出
Webサーチ経験の多寡を基準に被験者を捕らえる
Webコンテンツの性質を感覚的に理解している
→ちょっとこれではもやっとしているので＜汗
経験の分類指標として「日常的なWeb利用、情報収集スタイル、検索エンジンに関する知識」
点数付けをして中間層を排除（単純に2分割ではなく）してグループ間の比較をし易くした
・課題の設定
事実発見課題 パフォーマンスを0/1で判断できる
日常的な課題 被験者によって知識の差がない課題
・パフォーマンスデータ
事実発見→発見できた人数：Expert＞Novice
プロセスに関するデータ→発話プロトコル：課題遂行中に頭に浮かんだ事をすべて声に出してもらった（プロトコルアナリシス）
行動データの収集：閲覧履歴、パソコン画面
・分析の仕方
科学的発見における空間探索のモデル Two space model(Simon & Lea, 1974)
実験の統制（探索の絞込み）
仮説空間（キーワード空間）→実験空間（Web空間、検索結果、ページ）
←
実験結果のフィードバック（探索結果のフィードバック）
・モデルに基づいて分析指標を提案
空間内の探索に関する指標
空間から空間に推移していくパターンの指標
・発話プロトコル
予測に関する発話、評価に関する発話
声に出し、書き起こし、コーディング(評価、予測のタグ付け)し、信頼性の確認（評定者によるコーディングの確認、結果の確認）
・行動データの分析
ProblemBehaviorGraph（PBG）
探索スキーマ
・WebにおけるExploratorySearchの分析
・研究目的
1. ExpcloratorySearchの分析
2. 視線データ
・被験者
Expert:図書館情報学専攻の大学院生
Novice:他専攻の学部生
・課題の設定
自由度の高い情報収集課題
・パフォーマンスデータ
前の＋
課題遂行後のインタビュー
視線データ
・Webページのどこをみているか？
Webページの何処を見ているか？
装置さえよければ取れる
！Webページの何を見ているか？
ページの位置≠特定の内容→コーディングでカバー
？？スクロールしちゃいけないねぇ
・相補的なデータの分析
行動データ
ブラウザログ
画面キャプチャ
視線データ
↓仮説をあてて、検証
発話プロトコル
課題遂行中・後
・レポート作成はサブタスクに分けにくい
インタビューデータの分析
→レポートに対する戦略の違い
・院生：参考文献リスト
・学部生：Webページをそのまま使おうとしている
・利用者の特性を要因とする場合
☆特性の定義やレベル分けの基準を客観的に分かるようにする→できるだけ量的な指標で基準の違いを示す
Moore(2007) SearchExperience研究のメタ分析
・課題の設定
Simulated Task：被験者間の比較が厳密
Open Ended Task：被験者の興味を反映したリアルな行動、難易度・情報量の統制が困難
どちらを選ぶかは自分が何を見たいかに関ってくるなぁ。。。ってことで。
■ゲーム理論的方法論に基づきユーザ特性を理解するための社会的心理学実験
NTTコミュニケーション科学基礎研究所 松田さん
・学生時代：社会心理学
・実験に対する熱い思いを買われ、杉原先生に呼ばれてきた。
●人間モデル
どんな結果が得られても「こうなりました」って書けばいいんでしょ？
→松田さん「このヤロー」
一回目の発表、中島さんのさんの67％って良い数字？多分良い。比較対照があればOKだったんじゃない？
・性に関する実験
1.男性が女性のイラストの魅力を評定
→ウエストとヒップの比が0.7がもっとも好まれる
2.嫉妬の性差
→男性：女性の肉体的な浮気を許せない
→女性：男性の精神的な浮気を許せない
人間モデルに照らすと明らかになる
1は子孫繁栄のため：ウェストが細いと妊娠してない→女性に対する魅力。
2も。女性は妊娠してしまうと自由に動けなくなる→父親への信頼度が重要。
・4枚カード問題
一方がひらがななら、他方は偶数でないといけない
「1」 「4」 「あ」 「イ」
対偶を利用した良い問題 → 「一方が奇数なら、他方はカタカナでないといけない」
両方カタカナだったり、両方偶数であるのはOKってことだよ！
●人を使う実験がめちゃめちゃになる理由
人はウソをつく。悪意のない嘘。
特に日本人は「謙譲」を美徳する民族なので。
ある問題をとかせる。
理論的には平均より上か下か？
何も無いと→「平均より下ですよー」が69.2%
金がかかると（予測が正解していたら100円上げます）→「平均より下ですよー」が23.2%。。。ｵｰｲ
・研究者倫理の問題
都合の良い評価実験データが得られる状況はデータの捏造と紙一重。
将来の研究者に負の遺産を残してはならない。
・実験者と参加者の間の相互作用
ギヤク効果（無自覚）→参加者が信じきり、効果が表れてしまう。。。
ピグマリオン効果→出切るというと伸びる
要求特性（自覚）→仮説を予測し、それに基づいて行動する
＊別の目的を装う＝質問紙にもあえて多様な質問項目を列挙する
＊意図的に操作できない測定法
評価懸念→知的能力・常識が試されていると懸念し、行動が変化
知人や指導学生を参加者にするとき、特に注意が必要
実験者効果→無自覚に実験者が参加者の行動を誘導してしまう
二重盲検方
・Deception（騙し）の人権倫理問題
インフォームドコンセプトに反する重大問題かも
論文では倫理委員会によるチェックが必要だったりする。。。
・参考文献
心理学研究法 高野
■フィールドマイニングの試み
大阪大学 松村先生
・もとはAI、コミュニケーション方面のひと
→分析の対象ブログ、2chもした。。。
→データマイニングの限界はどこだ？データありきの学問だよなぁ
→物理空間、フィールドを対象としたデータ分析
人間が気付くようなきっかけの方法論
行動を変化させるちょっとした工夫
・男子便器の目標→年間のトイレ掃除代が一億円くらい浮いたらしい
・ゴミ箱の口
・公演のベンチの真ん中に手すり→ホームレスが寝なくなる
・車道の絵→車の速度を下げる
・高速道の段々狭まっていく点々→車の速度を下げる
身近な道具もキッカケになる
・カメラ→撮れるものがないかと色々見るようになる
・ベビーカー→地面の段差に敏感になる
生活空間は見ているのに見ていない、聞こえているのに聞いていないことに溢れている
フィールドマイニングは人とモノと環境との関係を再構築する
→フィールドの変化がどう人の行動に変化を及ぼすか
・石橋らくがきマップ
全年齢を対象にしようと思うとオフラインな仕組みに
・外でランチ
実験をやったのが11月だったので、実用的ではなかったが外に関心は向けられた
・阪大坂を使った実験
福男
地元が炊き出ししてイベント化
次年度からは地元と市から予算が着くようになったらしい
・イメージマップを用いた
石橋という駅をもつ町のイメージ
子供がかなり集まったらしい
・ムーバブルチェア
動かせる椅子を放置して、利用の様子を観察
年齢などによって座る位置が変化した
・音を使った実験
音を聞かせてどこでやってる音かを当てさせる
・お店の落書き帳
ラン検定（連続性の検定）
■質問
to松村先生：フィールドマイニングのマイニングってどこにかかってるの？
最初は環境にいろいろセンサを取り付けるつもりだったのでこういう名前に。。。
フィールドマイニングの本来の語義は「穴をほること」です。
to松田さん：被験者を疑い出すとゴールが見えない。どこまでやれば良いかというラインはある？
出せない。結局それはみなが試行錯誤して続けていくしかない。
情報系の人がやってる実験は低い所で止まっているのではないか？
実験者効果がとくにでかいのでは？
変な基準で図ったデータが将来の人にリファらされると怖い。
to松村さん：ノーマンの行ってる認知系からプロダクトのデザインに行く。デザインの話なんだろう、それは工学者が必要とされるものだ。情報工学研究者として＋な部分、マイナスな部分を教えてほしい。
認められない。。。研究としての分野が難しい。投稿先や評価基準が分からない。もう趣味です。
to斎藤先生：エキスパートとNoviceの切り分けは統計的に見ればセーフ？
本当は指標がほしい
to皆さん：質問はない ヒューマンインタフェースの本場の学会ではチュートリアルが多い、ユーザ評価どうするか？
研究テーマになりそうな素材をなげて、評価もする
to斎藤先生：視線のデータをどう料理している？眼球運動のどういう特性を使っている。
視線データ、注視点、停留点
to斉藤先生：視線についてのデータをとるにはどのくらい勉強しないといけない？
眼球運動のデータを使って研究を行っていた人と一緒にやっている。
to杉原先生：明確な因果関係の把握は難しく、類推でしかないのでは？
質的な調査と量的な調査を組み合わせるべき→少ないデータでは因果関係をいえない
to松田さん：極度に被験者実験の条件を拘束すると、工学と実験のミッシングリングを埋められなくなるのでは？
ユーザ評価をやっつけでするなら、やらない方がいいじゃん
何でユーザ評価しないといけないのか。
===========
杉原先生の発表速過ぎ。。。
ほとんどメモれんかった。。。パワポが欲しいよ～っ(>_<)
斎藤先生の話はかなり具体的。
一通りの手順が明らかなので、参考にしたいと思います。
松田さんはとにかく面白い！しばらく研究室でネタにできそうｗｗ
あと二重盲検法について調べとこ。
松村さんの話は何か今年のMYCOMで聞いた気がするんだけど。。。後で飲み会で確認したら来てないそうなので、多分別の機会だったのかなぁ？うーん。。。
ちなみに質問を1回するという目標は達成できず。
レベル高すぎました；；
第15回WI2研究会 1日目第1セッション「情報抽出・分析」
7月4日、5日と広島市立大学で開かれた第15回Webインテリジェンスとインタラクション(SIG-WI2 ｼｸﾞｳｨｯﾂ) に参加してきました。
うちの大学も相当ド田舎にありますが、こちらもなかなか野趣に溢れておりました（失礼）
緑が多くて、ところどころに美術系の学生が作ったモニュメント（スターゲートみたいな）があって結構楽しかったです。
ただ、土日ということで学食・購買が一切空いていないのには閉口しましたが。。。
大学前のパン屋が2日前にオープンしてなければ、完全に昼食を食いっぱぐれるところでした。
会場は写真左手の小ホールでありました。
学生で聴講のみなので参加費はタダ♪
Proceedingと懇親会費だけ払ってきました。
うちの認知系のボスがProceedingを楽しみにしているようなので、ここで第一目的はクリアしました。
……まさかチュートリアルがタイトルだけとは思いませんでしたが；；
以下、午前のセッション「情報抽出・分析」のメモです。
個人的解釈、私的推測入り乱れてます。
「？？」は私が疑問に思った部分です。
==============
■ブログにおける話題語の出現理由の抽出と話題に関する詳細記事推薦
発表者：早稲田大学 中島さん
・話題語：ブログ上で一時的に急増した語
背景知識がないと何故その話題語が急増したのか分からない
→6つの情報：話題理由、意味、中心人物、場所、時間、情報源を抽出する
※ 多分、この6つを対象とした根拠は6W1H
・提案手法
（人物、場所、時間、手段）→（理由）→（詳細記事）の順序で抽出
1.まずWikipediaで定義文（「●●とは××である」）を獲得する
2.ブログ記事のフィルタリング→話題語を含む記事全て
3.除去する記事：話題語ばかりを含むスパム的記事があるので除去する→話題語の関連語をどの程度含むかを見る
4.記事本体の形態素解析→地域、人名、数タグをつける
5.並んだ名詞を連結させる。連結した語には元のタグを継承させる
6.タグを改めて人物、場所毎に抽出→最も出現数の高い語を抽出
？？日時と状況が必ずしも一致しないのでは？？
7.話題語を含む、中心人物、場所、時間、情報源を多く含む1文を抽出
8.記事を推薦
・評価実験
・ウィキペディアの話題語に対する網羅性：話題語に関する記事がウィキペディアに存在するか
45語を対象に調査→53％くらい網羅
・ウィキペディアから抽出された意味の評価
人手で評価した結果→90％以上が一致
・話題語の抽出情報と推薦記事の一致について
中心人物、話題理由、推薦記事（複数の要素による判断）は精度が高かった
場所（人名が場所と判断されてしまった）、時間（テレビ番組から書いてる人が多い）の精度は低かった
Googleブログでは詳細に書かれたブログ記事が存在しない場合も合った
アニメやドラマの場合、特殊な語が多かった
・関連研究（話題語に関する研究）
・ブログの係り受け：慶応大学の数原先生
・Yahoo!Japanブログ検索
[質問1]
ブログ記事よりもニュースを見せた方が良いような気がする
→テレビ番組や、うどんの日とかニュースにならない話題語もある。
ハニカミ王子とかそういうのをフォーカスした方が良い
[質問2]
時間についてブログエントリーの日付と、「今日」、「昨日」の単語の組み合わせの方が良いのでは？
→まだ実装できていない
話題語はブログによって増幅されたマスコミ報道になるのでは？
→ニュース記事にならない報道もある
[質問3]
この区分はかなりナイーブなものになるのでは？中心人物、場所と組織の違いはどうやって？（例：広島市立大学は組織？場所？）
→中心人物の場合、人名しかとっていない
[質問4]
現実の推薦では話題語としてアップされると、それにアクセスする人が増えて過剰に話題語の推薦順位があがる。
→自動的に時間で区切って、関連語による検索の重み付けを行う
話題語以外の語を使うと、その人の興味でひくとどうなるのか？
[質問5]
式の重み付けの手法について
→実験結果によって適切な値を決めた
■ブロガーの体験熟知度に基づくブログランキングシステム
京都産業大学 中島さん（前の発表者と同じ！）
・ブログの検索やランキングに対する要求の増大
ブログとWebページは違う。ブログは投稿直後は外部からのリンクが存在しない。Googleの検索方式だとこれを見つけるのは難しい。
・従来手法
ブログエントリに対するランキング：新着順やキーワード
ブログサイトに対するランキング：リンク数、アクセス数、投票数によるランキング
→目的トピックに関する最新エントリが存在するとは限らない
？？ブログサイトの知名度は低いが隠れた名文を探したいのか？→名文サイトは必然的に高いランキングを持つ気がするのだが？？
？？投稿数と投稿内容のレベルに相関性があるのか？あれば分野別にランキングを作った方が早いのでは？？
・提案手法のコンセプト
☆熟知度が高いブロガーが書いた記事は素人が書いた記事よりも価値が高い
中身よりも情報の発信者に対する権威が、エントリの信頼度を保証するのでは？
→対象トピックに関して詳しく書かれたエントリを数多く投稿したブロガーは熟知度が高い
・提案手法
1.熟知領域リストの作成
「ファン、マニア、フリーク」で検索してこれらの検索後の直前の語句のうち、出現頻度が高いものを辞書に登録
→500領域
独自開発した生活体験シソーラス(LETS)を用いて、そのカテゴリを熟知領域リストとして採用
→14000領域
熟知語そのものではなく、「赤ちゃん」にたいして「離乳食」「おむつ」といった関連語による重み付けも必要！
2.ブロガーの熟知度スコアの算出
熟知語と関連語と共起語数を用いて算出
スパム対策もしている
3.ブログランキングの算出
熟知語をリスト化→この熟知語リストからクリックすると、その側面からみたその熟知語を扱うブログが見れる
熟知ブロガーを熟知度に基づいてランキング
・ニュアンス比較について
ニュアンス（清清しい、感動、可愛い、怒り、恐怖など）とその関連語からブログ記事のニュアンスを判定
全ブロガーと熟知ブロガーのある語に対する感情の主成分を解析
・効果
ある検索ワードに関する結果だけでなく、関連ワードもリストアップするので、その関連ワードに依存した立場による記事が見れる
ニュアンス比較によりどういう感情をもってブログを書いているのかが分かる
・実験システムに関するデータ
ブロガー 70000以上
エントリ 140000以上
20個のキーワードに対して、熟知ブロガーとして妥当か判定91％
エントリは67％
学生は20人
・今後は信頼性の高さを提示できるようにしたい
・生活体験シソーラス
ブログやニュースなどの実テキストにしばしば表現される生活体験を体系的に整理・分類したシソーラス
概念の変化について扱う（移籍した野球選手etc）
自動的カテゴリ辞書管理システム：連想辞書の自動生成
成分解析エンジン：任意の入力テキストを分類するグラデーション・エンジン。広告や商品のレコメンデーションに応用している。
[質問1]
ブロガーの熟知度とエントリの妥当性の評価が分かれたのは何故？
[質問2]
頻繁にエントリを出しているブログでも内容がやばい場合もある
→フィルタリング、熟知ブロガー同士のリンク関係などを利用してうまく排除したい。
[質問3]
LETSはどうやって作る？
→候補は機械的に、最後の決定は人手である
ブログの信頼性の指標はすでにあるのでは？それと関連させることは考えていない？
→普段は違う意見のグループが、あるテーマについては合意が取れた場合、そのエントリは信頼性が高い。そういうところをみたい。
■キーワードの時系列データにもとづくブログ、ニュース、スパムの解析
島根県立大学 石田先生
・事項相関に基づきキーワード出現頻度の基本周期系列を抽出するアルゴリズム
・分析データ
実験データの取得期間：2008年1月1日から2009年5月15日
ブログ、ニュース、スパム
毎日ランキング上500をとり、出る単語を解析
それぞれの単語について各日に登場した回数の配列を求め、自己相関を求める
・自己相関の隣接差分積
時系列データの自己相関の局所的ピークを検出
・情報源に対する比較（定量的分析）
7日周期が多い
・ブログ：7日比べて14、21日周期も多い（月末、週一のテレビ番組）
長い場合は365日
・スパム：短い周期の頻度、スパマーが短い周期で類似文章を投稿
2日周期が多い
・ニュース：基本周期に沿っている
7日が突出している
・定性的分析
・週間キーワード（基本7、たまにずれる）
出現頻度リストについてブログは鋭く、スパムは平坦
・完全週間キーワード
？？休講ワードが出てきた？？これって完全週間なの？？
・週間ブログキーワード（特徴的なキーワードを適当に選定）
週末の運動に関するキーワードが多かった。
・年間キーワード（365日を周期としている）
[質問1]
自己相関とはどうやって求めているのか？
→単語の出現頻度を毎日だす（日数分の配列を用意して、それぞれにその日のその単語の出現頻度を入れる）。それに共分散を算出
どういうアプリケーションに応用したいのか？
→広告などのマーケティングに利用
[質問2]
がちがちなアルゴリズムになってないか？
→緩くしてしまうと、解釈が難しいデータになってしまった。
[質問3]
結果がある程度自明になってはないか？周期性が見つけられて、そこに何かがあるのが分かったら良いんだけど。そこらへんからどうやって人の活動を見出したいの？
→今後分析していきたい
[質問4]
フーリエ変換を使おうと思わなかったのか？
→自己相関を使う事を決めていた
スパムブログフィルタに使えないか？
→使える
■旅行ブログからの観光情報の自動抽出
広島市立大学大学院 石野さん（えらい美人！声もきれい！うぐいす嬢かと思った！！）
・2007年観光立国推進基本法が成立
データベースはあるが、人手で集めているので大変
→ブログから自動的に観光情報を抽出
網羅性、最新性、ブログ著者の属性からユーザに適した観光情報
・提案手法
1.旅行ブログの検出
旅行ブログの例：観光情報が含まれているかで判定
観光：余暇時間の中で、日常生活圏を離れて行う様々な活動であり、ふれあい、学び、遊ぶ事を目的とするもの
複数エントリにまたがる旅行エントリは、中日が検出できない。。。（最初の日と最後の日しか旅行とかかない）
→系列ラベリング問題として扱う
機械学習としてCRFを利用
2.旅行ブログからの観光情報抽出
地域名と土産者の対の抽出 Google7-gram？？（これがないと余計な文章を抽出してしまう）
→旅行ブログに含まれる地域名と土産物の両方を持っている文を抽出
→新たな土産物の対を抽出
・実験 検出編
まずYahoo!ブログから観光、旅行という単語を含むエントリを抽出
再現率は低かったが、精度が高かった。→ブログ数を増やすことで解決できる
再現率＝複数エントリに渡る旅行記の一部の場合、検出できない場合もある（こういう漏れのなさが再現率）
記載内容が少なくても難しい
検出誤り＝旅行ブログでないのに、旅行ブログとしてみてしまう
エントリの前後に旅行ブログがあったりする
地元紹介のエントリ？？これは取れても良いのでは？（地元の判別さえできればOK）
他人の旅行を紹介しているエントリ
・実験 観光情報の自動抽出
それぞれ任意に80000文を抽出
旅行ブログ
一般ブログ
一般ウェブ
[質問1]
土産ものと場所の対だけでなく、景色とかを扱う場合は、このままの手法で使えるか？
→有効であるものとないものに分けられる。食事をメインに扱いたい。
公共機関ではなく、ブログからの抽出の意義は？
→ユーザの主観的な感想が見たい。
踏み込んだ事が書いたブログじゃないと抽出する意味が無い。そこらへんまでやってるのか？
→（なんば先生）ブログ先生から抜く意義はパーソナライズにある。ブログを書いている著者のパーソナルデータから、さらにリコメンドできたら嬉しい。
[質問2]
旅行ブログでないと判定したものの中の地元紹介は何でだめなのか？ニッチな観光情報として使えるのでは？
→今回の目的には沿ってなかっただけ。
この手のブログはすっごいスパムが多い。。。偽情報とかはどう判別しているのか？
→今後。
？？ブログエントリにタグってついてないのかなぁ、それ利用できないのかなぁ？？
==============
ここまでが第一セッション。
目標である「１セッションにつき１回は絶対に質問する」はクリア☆
やっぱりWebマイニングの世界はテキストベースが多いんだなと改めて実感しました。
ブロガーの体験熟知度についてははうちの研究室で、pdfの推薦を考えている同期の研究の参考にもなりそうです。
生活体験シソーラスLETSはちょっと欲しい。。。
最後の旅行ブログの質問2について、彼女と同じ研究室の院生が、ブログからの主観的データの抽出を行っているそうなので、それと組み合わせると結構良い感じになりそうです。
10月のWI2でそっちの発表も聞けたら良いなぁ☆
うちの大学も相当ド田舎にありますが、こちらもなかなか野趣に溢れておりました（失礼）
緑が多くて、ところどころに美術系の学生が作ったモニュメント（スターゲートみたいな）があって結構楽しかったです。
ただ、土日ということで学食・購買が一切空いていないのには閉口しましたが。。。
大学前のパン屋が2日前にオープンしてなければ、完全に昼食を食いっぱぐれるところでした。
会場は写真左手の小ホールでありました。
学生で聴講のみなので参加費はタダ♪
Proceedingと懇親会費だけ払ってきました。
うちの認知系のボスがProceedingを楽しみにしているようなので、ここで第一目的はクリアしました。
……まさかチュートリアルがタイトルだけとは思いませんでしたが；；
以下、午前のセッション「情報抽出・分析」のメモです。
個人的解釈、私的推測入り乱れてます。
「？？」は私が疑問に思った部分です。
==============
■ブログにおける話題語の出現理由の抽出と話題に関する詳細記事推薦
発表者：早稲田大学 中島さん
・話題語：ブログ上で一時的に急増した語
背景知識がないと何故その話題語が急増したのか分からない
→6つの情報：話題理由、意味、中心人物、場所、時間、情報源を抽出する
※ 多分、この6つを対象とした根拠は6W1H
・提案手法
（人物、場所、時間、手段）→（理由）→（詳細記事）の順序で抽出
1.まずWikipediaで定義文（「●●とは××である」）を獲得する
2.ブログ記事のフィルタリング→話題語を含む記事全て
3.除去する記事：話題語ばかりを含むスパム的記事があるので除去する→話題語の関連語をどの程度含むかを見る
4.記事本体の形態素解析→地域、人名、数タグをつける
5.並んだ名詞を連結させる。連結した語には元のタグを継承させる
6.タグを改めて人物、場所毎に抽出→最も出現数の高い語を抽出
？？日時と状況が必ずしも一致しないのでは？？
7.話題語を含む、中心人物、場所、時間、情報源を多く含む1文を抽出
8.記事を推薦
・評価実験
・ウィキペディアの話題語に対する網羅性：話題語に関する記事がウィキペディアに存在するか
45語を対象に調査→53％くらい網羅
・ウィキペディアから抽出された意味の評価
人手で評価した結果→90％以上が一致
・話題語の抽出情報と推薦記事の一致について
中心人物、話題理由、推薦記事（複数の要素による判断）は精度が高かった
場所（人名が場所と判断されてしまった）、時間（テレビ番組から書いてる人が多い）の精度は低かった
Googleブログでは詳細に書かれたブログ記事が存在しない場合も合った
アニメやドラマの場合、特殊な語が多かった
・関連研究（話題語に関する研究）
・ブログの係り受け：慶応大学の数原先生
・Yahoo!Japanブログ検索
[質問1]
ブログ記事よりもニュースを見せた方が良いような気がする
→テレビ番組や、うどんの日とかニュースにならない話題語もある。
ハニカミ王子とかそういうのをフォーカスした方が良い
[質問2]
時間についてブログエントリーの日付と、「今日」、「昨日」の単語の組み合わせの方が良いのでは？
→まだ実装できていない
話題語はブログによって増幅されたマスコミ報道になるのでは？
→ニュース記事にならない報道もある
[質問3]
この区分はかなりナイーブなものになるのでは？中心人物、場所と組織の違いはどうやって？（例：広島市立大学は組織？場所？）
→中心人物の場合、人名しかとっていない
[質問4]
現実の推薦では話題語としてアップされると、それにアクセスする人が増えて過剰に話題語の推薦順位があがる。
→自動的に時間で区切って、関連語による検索の重み付けを行う
話題語以外の語を使うと、その人の興味でひくとどうなるのか？
[質問5]
式の重み付けの手法について
→実験結果によって適切な値を決めた
■ブロガーの体験熟知度に基づくブログランキングシステム
京都産業大学 中島さん（前の発表者と同じ！）
・ブログの検索やランキングに対する要求の増大
ブログとWebページは違う。ブログは投稿直後は外部からのリンクが存在しない。Googleの検索方式だとこれを見つけるのは難しい。
・従来手法
ブログエントリに対するランキング：新着順やキーワード
ブログサイトに対するランキング：リンク数、アクセス数、投票数によるランキング
→目的トピックに関する最新エントリが存在するとは限らない
？？ブログサイトの知名度は低いが隠れた名文を探したいのか？→名文サイトは必然的に高いランキングを持つ気がするのだが？？
？？投稿数と投稿内容のレベルに相関性があるのか？あれば分野別にランキングを作った方が早いのでは？？
・提案手法のコンセプト
☆熟知度が高いブロガーが書いた記事は素人が書いた記事よりも価値が高い
中身よりも情報の発信者に対する権威が、エントリの信頼度を保証するのでは？
→対象トピックに関して詳しく書かれたエントリを数多く投稿したブロガーは熟知度が高い
・提案手法
1.熟知領域リストの作成
「ファン、マニア、フリーク」で検索してこれらの検索後の直前の語句のうち、出現頻度が高いものを辞書に登録
→500領域
独自開発した生活体験シソーラス(LETS)を用いて、そのカテゴリを熟知領域リストとして採用
→14000領域
熟知語そのものではなく、「赤ちゃん」にたいして「離乳食」「おむつ」といった関連語による重み付けも必要！
2.ブロガーの熟知度スコアの算出
熟知語と関連語と共起語数を用いて算出
スパム対策もしている
3.ブログランキングの算出
熟知語をリスト化→この熟知語リストからクリックすると、その側面からみたその熟知語を扱うブログが見れる
熟知ブロガーを熟知度に基づいてランキング
・ニュアンス比較について
ニュアンス（清清しい、感動、可愛い、怒り、恐怖など）とその関連語からブログ記事のニュアンスを判定
全ブロガーと熟知ブロガーのある語に対する感情の主成分を解析
・効果
ある検索ワードに関する結果だけでなく、関連ワードもリストアップするので、その関連ワードに依存した立場による記事が見れる
ニュアンス比較によりどういう感情をもってブログを書いているのかが分かる
・実験システムに関するデータ
ブロガー 70000以上
エントリ 140000以上
20個のキーワードに対して、熟知ブロガーとして妥当か判定91％
エントリは67％
学生は20人
・今後は信頼性の高さを提示できるようにしたい
・生活体験シソーラス
ブログやニュースなどの実テキストにしばしば表現される生活体験を体系的に整理・分類したシソーラス
概念の変化について扱う（移籍した野球選手etc）
自動的カテゴリ辞書管理システム：連想辞書の自動生成
成分解析エンジン：任意の入力テキストを分類するグラデーション・エンジン。広告や商品のレコメンデーションに応用している。
[質問1]
ブロガーの熟知度とエントリの妥当性の評価が分かれたのは何故？
[質問2]
頻繁にエントリを出しているブログでも内容がやばい場合もある
→フィルタリング、熟知ブロガー同士のリンク関係などを利用してうまく排除したい。
[質問3]
LETSはどうやって作る？
→候補は機械的に、最後の決定は人手である
ブログの信頼性の指標はすでにあるのでは？それと関連させることは考えていない？
→普段は違う意見のグループが、あるテーマについては合意が取れた場合、そのエントリは信頼性が高い。そういうところをみたい。
■キーワードの時系列データにもとづくブログ、ニュース、スパムの解析
島根県立大学 石田先生
・事項相関に基づきキーワード出現頻度の基本周期系列を抽出するアルゴリズム
・分析データ
実験データの取得期間：2008年1月1日から2009年5月15日
ブログ、ニュース、スパム
毎日ランキング上500をとり、出る単語を解析
それぞれの単語について各日に登場した回数の配列を求め、自己相関を求める
・自己相関の隣接差分積
時系列データの自己相関の局所的ピークを検出
・情報源に対する比較（定量的分析）
7日周期が多い
・ブログ：7日比べて14、21日周期も多い（月末、週一のテレビ番組）
長い場合は365日
・スパム：短い周期の頻度、スパマーが短い周期で類似文章を投稿
2日周期が多い
・ニュース：基本周期に沿っている
7日が突出している
・定性的分析
・週間キーワード（基本7、たまにずれる）
出現頻度リストについてブログは鋭く、スパムは平坦
・完全週間キーワード
？？休講ワードが出てきた？？これって完全週間なの？？
・週間ブログキーワード（特徴的なキーワードを適当に選定）
週末の運動に関するキーワードが多かった。
・年間キーワード（365日を周期としている）
[質問1]
自己相関とはどうやって求めているのか？
→単語の出現頻度を毎日だす（日数分の配列を用意して、それぞれにその日のその単語の出現頻度を入れる）。それに共分散を算出
どういうアプリケーションに応用したいのか？
→広告などのマーケティングに利用
[質問2]
がちがちなアルゴリズムになってないか？
→緩くしてしまうと、解釈が難しいデータになってしまった。
[質問3]
結果がある程度自明になってはないか？周期性が見つけられて、そこに何かがあるのが分かったら良いんだけど。そこらへんからどうやって人の活動を見出したいの？
→今後分析していきたい
[質問4]
フーリエ変換を使おうと思わなかったのか？
→自己相関を使う事を決めていた
スパムブログフィルタに使えないか？
→使える
■旅行ブログからの観光情報の自動抽出
広島市立大学大学院 石野さん（えらい美人！声もきれい！うぐいす嬢かと思った！！）
・2007年観光立国推進基本法が成立
データベースはあるが、人手で集めているので大変
→ブログから自動的に観光情報を抽出
網羅性、最新性、ブログ著者の属性からユーザに適した観光情報
・提案手法
1.旅行ブログの検出
旅行ブログの例：観光情報が含まれているかで判定
観光：余暇時間の中で、日常生活圏を離れて行う様々な活動であり、ふれあい、学び、遊ぶ事を目的とするもの
複数エントリにまたがる旅行エントリは、中日が検出できない。。。（最初の日と最後の日しか旅行とかかない）
→系列ラベリング問題として扱う
機械学習としてCRFを利用
2.旅行ブログからの観光情報抽出
地域名と土産者の対の抽出 Google7-gram？？（これがないと余計な文章を抽出してしまう）
→旅行ブログに含まれる地域名と土産物の両方を持っている文を抽出
→新たな土産物の対を抽出
・実験 検出編
まずYahoo!ブログから観光、旅行という単語を含むエントリを抽出
再現率は低かったが、精度が高かった。→ブログ数を増やすことで解決できる
再現率＝複数エントリに渡る旅行記の一部の場合、検出できない場合もある（こういう漏れのなさが再現率）
記載内容が少なくても難しい
検出誤り＝旅行ブログでないのに、旅行ブログとしてみてしまう
エントリの前後に旅行ブログがあったりする
地元紹介のエントリ？？これは取れても良いのでは？（地元の判別さえできればOK）
他人の旅行を紹介しているエントリ
・実験 観光情報の自動抽出
それぞれ任意に80000文を抽出
旅行ブログ
一般ブログ
一般ウェブ
[質問1]
土産ものと場所の対だけでなく、景色とかを扱う場合は、このままの手法で使えるか？
→有効であるものとないものに分けられる。食事をメインに扱いたい。
公共機関ではなく、ブログからの抽出の意義は？
→ユーザの主観的な感想が見たい。
踏み込んだ事が書いたブログじゃないと抽出する意味が無い。そこらへんまでやってるのか？
→（なんば先生）ブログ先生から抜く意義はパーソナライズにある。ブログを書いている著者のパーソナルデータから、さらにリコメンドできたら嬉しい。
[質問2]
旅行ブログでないと判定したものの中の地元紹介は何でだめなのか？ニッチな観光情報として使えるのでは？
→今回の目的には沿ってなかっただけ。
この手のブログはすっごいスパムが多い。。。偽情報とかはどう判別しているのか？
→今後。
？？ブログエントリにタグってついてないのかなぁ、それ利用できないのかなぁ？？
==============
ここまでが第一セッション。
目標である「１セッションにつき１回は絶対に質問する」はクリア☆
やっぱりWebマイニングの世界はテキストベースが多いんだなと改めて実感しました。
ブロガーの体験熟知度についてははうちの研究室で、pdfの推薦を考えている同期の研究の参考にもなりそうです。
生活体験シソーラスLETSはちょっと欲しい。。。
最後の旅行ブログの質問2について、彼女と同じ研究室の院生が、ブログからの主観的データの抽出を行っているそうなので、それと組み合わせると結構良い感じになりそうです。
10月のWI2でそっちの発表も聞けたら良いなぁ☆
2009年7月4日土曜日
研究会にいってきます
明日７月４日から２日間に渡って広島で開かれるＷＩ２（Webインテリジェンスとインタラクション研究会）に参加してきます。
研究会そのものは初めてではないのですが、いつも同じ研究室の先輩同輩が一緒なので、今回初めて１人きりでの参加ということに妙にドキドキしてたります。
いや、実のところ大分ドキドキです。
発表しないのに＜笑
人と話すの下手くそなんですが、たくさん知り合いできたら良いな。
とりあえず今回の目標としては
１．全部の発表についてメモをとる
２．１セッションにつき１回は絶対に質問する
３．名刺を１０枚獲得してくる＜笑（要は話せってコト）
そして一番重要なのが笑顔を絶やさないこと。
ポジティブさが大事☆
研究会そのものは初めてではないのですが、いつも同じ研究室の先輩同輩が一緒なので、今回初めて１人きりでの参加ということに妙にドキドキしてたります。
いや、実のところ大分ドキドキです。
発表しないのに＜笑
人と話すの下手くそなんですが、たくさん知り合いできたら良いな。
とりあえず今回の目標としては
１．全部の発表についてメモをとる
２．１セッションにつき１回は絶対に質問する
３．名刺を１０枚獲得してくる＜笑（要は話せってコト）
そして一番重要なのが笑顔を絶やさないこと。
ポジティブさが大事☆
2009年7月1日水曜日
劇的ビフォーアフター 生け花編
ちょっと花を生けてきました＜笑
私がTAをしている講義で知り合った子が、生け花サークルの代表をやっていて
お稽古体験のお誘いを受けて行ってきました。
まあ、とっくに院生なんで（汗）ホントに遊びに行ったような感覚なんですけどね。
お稽古には小原流の先生が呼ばれていました。
あまり流派について詳しいことは分からないのですが、
国宝の装飾を行ったりと割と有名な流派みたいです。
今回やったのは「瓶にいける」形で、お盆ではなく縦長の花器にいけるというものです。
実はお盆に生ける方が簡単で、瓶に生けるのはちょっと難しいらしく、
あまり初心者向きではないという。。。＜汗
とりあえず30分奮闘した結果、こんな感じになりました。
まずは中央にあるメインの花（主枝、クルクマという花らしい）を生けるのですが、
こいつをどう立てたものか、最初からつまづきました＜汗
先生曰く、前後20度の傾きはOkとのことで、竹串で補強しつつ主枝を投入。
その後回りのミドルサイズの花（副枝、トルコキキョウ）を45度の傾きでさして、
あとは周りを飾っていきました。
盆の場合、剣山（針がびっしり並んだ奴）で固定できるのですが、
瓶の場合はそれが出来ないので、微妙なバランスで枝や花を重ねていきます。
これがかなり難しく、私の作品は、しょっちゅうバランスを崩して倒壊してました・・・(T_T)
出来たお花は、一旦バラして、家に持ち帰ってから生け直します。
再現不能かと思いましたが、案外うまく生けなおせました。
解像度の関係であまり変わらないように見えるかもしれませんが、
実際のバランスはやっぱりお稽古で生けたときの方が全然良かったですね。
ザ先生マジック＜笑
結構楽しかったので、出来ればまたお稽古したいです。
ただ、年甲斐を考えるとなかなか難しいものが。。。
ちなみにお世話になった生け花サークル様のサイトです。
↓↓
日花里
ありがとうございましたー☆
私がTAをしている講義で知り合った子が、生け花サークルの代表をやっていて
お稽古体験のお誘いを受けて行ってきました。
まあ、とっくに院生なんで（汗）ホントに遊びに行ったような感覚なんですけどね。
お稽古には小原流の先生が呼ばれていました。
あまり流派について詳しいことは分からないのですが、
国宝の装飾を行ったりと割と有名な流派みたいです。
今回やったのは「瓶にいける」形で、お盆ではなく縦長の花器にいけるというものです。
実はお盆に生ける方が簡単で、瓶に生けるのはちょっと難しいらしく、
あまり初心者向きではないという。。。＜汗
とりあえず30分奮闘した結果、こんな感じになりました。
まずは中央にあるメインの花（主枝、クルクマという花らしい）を生けるのですが、
こいつをどう立てたものか、最初からつまづきました＜汗
先生曰く、前後20度の傾きはOkとのことで、竹串で補強しつつ主枝を投入。
その後回りのミドルサイズの花（副枝、トルコキキョウ）を45度の傾きでさして、
あとは周りを飾っていきました。
盆の場合、剣山（針がびっしり並んだ奴）で固定できるのですが、
瓶の場合はそれが出来ないので、微妙なバランスで枝や花を重ねていきます。
これがかなり難しく、私の作品は、しょっちゅうバランスを崩して倒壊してました・・・(T_T)
出来たお花は、一旦バラして、家に持ち帰ってから生け直します。
再現不能かと思いましたが、案外うまく生けなおせました。
解像度の関係であまり変わらないように見えるかもしれませんが、
実際のバランスはやっぱりお稽古で生けたときの方が全然良かったですね。
ザ先生マジック＜笑
結構楽しかったので、出来ればまたお稽古したいです。
ただ、年甲斐を考えるとなかなか難しいものが。。。
ちなみにお世話になった生け花サークル様のサイトです。
↓↓
日花里
ありがとうございましたー☆
2009年6月27日土曜日
ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()
Pythonのエラー（自己流翻訳）
ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()
値に関するエラー
1、もしくはそれ以上の長さの配列に適切な値が入っているかが曖昧です。
配列.any() か 配列.all() を使って確認してください。
for 値 in 配列 とかで配列がNoneだったり、他の型だったりすると発生するエラー。
私の場合は、引数の引き回し中に失敗(;_;)
ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()
値に関するエラー
1、もしくはそれ以上の長さの配列に適切な値が入っているかが曖昧です。
配列.any() か 配列.all() を使って確認してください。
for 値 in 配列 とかで配列がNoneだったり、他の型だったりすると発生するエラー。
私の場合は、引数の引き回し中に失敗(;_;)
2009年6月26日金曜日
プロキシからSSHができないって謎
私は研究室でプロキシサーバの管理をしています。
普段はアカウントを追加したり、登録IPを変更したりと、まったり管理しているのですが
久々にトラブルな仕事が回ってきました。
内容はプロキシサーバからSSHできないマシンが発生するというもの。
pingも通じない、SSHもうんともすんとも言わない。。。
同じ部屋にある別のマシンからはSSHできるのに。
traceroute打ったり、telnetしたり、色々やりました。
そして、原因は単純でした。
ネットワーク上に同じIPをstaticした阿呆がいた＜怒
通じないマシンのIPを固定IPからDHCPに変更すると
見事にｐｉｎｇが通るようになりました。
プロキシからpingが通らなかったのは、
単にもう一台の同じIPのマシンの方がプロキシに近かったから。
IPを割り当てる管理者のミスか、IPをstaticにしたマシン側のミスか。
とにかく犯人が見つかったらシバキ倒します。
私の30分を返せー！と。
普段はアカウントを追加したり、登録IPを変更したりと、まったり管理しているのですが
久々にトラブルな仕事が回ってきました。
内容はプロキシサーバからSSHできないマシンが発生するというもの。
pingも通じない、SSHもうんともすんとも言わない。。。
同じ部屋にある別のマシンからはSSHできるのに。
traceroute打ったり、telnetしたり、色々やりました。
そして、原因は単純でした。
ネットワーク上に同じIPをstaticした阿呆がいた＜怒
通じないマシンのIPを固定IPからDHCPに変更すると
見事にｐｉｎｇが通るようになりました。
プロキシからpingが通らなかったのは、
単にもう一台の同じIPのマシンの方がプロキシに近かったから。
IPを割り当てる管理者のミスか、IPをstaticにしたマシン側のミスか。
とにかく犯人が見つかったらシバキ倒します。
私の30分を返せー！と。
2009年6月24日水曜日
2009年6月23日火曜日
[AS3] やりたいこと別リンク集
このページは継続的に更新する予定。
適当な所でWiki化。
[AS3]
AS3でAWS（Amazon Web Service）
http://www.adamrocker.com/blog/150/amazon_web_service_actionscript30_e4x.html
addEventListerに引数付き関数
http://ameblo.jp/linking/entry-10088469739.html
Alertを起こす
http://livedocs.adobe.com/flex/2_jp/docs/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000548.html
Eventの伝播の仕方＆祖先ノードへのイベント伝播を止めるにはstopPropagation()！
http://livedocs.adobe.com/flex/201_jp/html/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Book_Parts&file=events_054_15.html
[Flex]
マウスイベント基本
http://my.opera.com/sizuhiko/blog/2008/08/25/flex2-coverflow-7
スクロールバーを見せるか見せないか
http://labs.uechoco.com/blog/2008/02/flex3panelcanvas.html
Flexでポップアップ
http://www.jinten.net/blog/archives/24
FlexのhtmlTextでサポートされているタグ
http://livedocs.adobe.com/flex/2_jp/docs/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000561.html
mouseEventを受け取るコンポーネントを指定（普通はネストしている子コンポーネントが引っかかる）
http://l00oo.oo00l.com/blog/archives/143
※あるコンポーネントにマウスイベントを受け取らせないときは
mouseEnabled="false" mouseFocusEnabled="false"の合わせ技が必要
適当な所でWiki化。
[AS3]
AS3でAWS（Amazon Web Service）
http://www.adamrocker.com/blog/150/amazon_web_service_actionscript30_e4x.html
addEventListerに引数付き関数
http://ameblo.jp/linking/entry-10088469739.html
Alertを起こす
http://livedocs.adobe.com/flex/2_jp/docs/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000548.html
Eventの伝播の仕方＆祖先ノードへのイベント伝播を止めるにはstopPropagation()！
http://livedocs.adobe.com/flex/201_jp/html/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Book_Parts&file=events_054_15.html
[Flex]
マウスイベント基本
http://my.opera.com/sizuhiko/blog/2008/08/25/flex2-coverflow-7
スクロールバーを見せるか見せないか
http://labs.uechoco.com/blog/2008/02/flex3panelcanvas.html
Flexでポップアップ
http://www.jinten.net/blog/archives/24
FlexのhtmlTextでサポートされているタグ
http://livedocs.adobe.com/flex/2_jp/docs/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000561.html
mouseEventを受け取るコンポーネントを指定（普通はネストしている子コンポーネントが引っかかる）
http://l00oo.oo00l.com/blog/archives/143
※あるコンポーネントにマウスイベントを受け取らせないときは
mouseEnabled="false" mouseFocusEnabled="false"の合わせ技が必要
2009年6月22日月曜日
[Flex][AS3] 文字列のID名からオブジェクトを取得
私は処理系はPythonで書いているのですが、GUIの方はFlex使いだったりします。
本当はGUIもdjangoとか使いたいんですけど。。。時間がぁ＜泣
閑話休題。
MXML上のコンポーネント（Label、Canvas等）のオブジェクト本体を
String型、文字列のID名から取得したいと考え、過去大分悩んだことがありました。
最近分かった答えが、
var id:String = "label1"
var labelObj:Object = this[id]
thisから連想配列見れば良かっただけorz|||
当たり前と言ったら当たり前＜汗
駄目だAS3全然分かってない。。。
2009年6月21日日曜日
2009年6月20日土曜日
cron-aptの設定をしてみた
Debianのパッケージの更新を自動化するcron-aptを入れました。
といっても私のサーバじゃなくて、管理してる研究室のサーバに。
うちの研究室、Linuxサーバが大量にある割りに、そういうセキュリティに必要な設定を知らない人が多いんですよねー、もち私も含めて。
詳しい人がいる間に色々、改革してもらわんと♥
とりあえず、以下インストールと設定のログです。
1. cron-aptのインストール
# aptitude install cron-apt
2. cron-aptの設定
# emacs /etc/cron-apt/config
==================================================
# 以下の行を設定
#更新コマンドとしてaptitudeを設定
APTCOMMAND=/usr/bin/aptitude
#後述するupgrade設定のため
ACTIONDIR="/etc/cron-apt/action.d"
#ファイルの出力
ERROR="/var/log/cron-apt/error"
TEMP="/var/log/cron-apt/temp"
LOG="/var/log/cron-apt/log"
# syslogには常に出力
SYSLOGON="always"
# デバッグモード
DEBUG="verbose"
==================================================
3. 実行時刻の変更デフォルトは朝4時に動作するようになっている。
# emacs /etc/cron.d/cron-apt
==================================================
# Every morning at 6 o'clock.
0 6 * * * root test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt
==================================================
4. upgradeの設定標準設定ではupdateのみであるため、upgradeも行うように設定を変更
# emacs /etc/cron-apt/action.d/3-download
==================================================
# dist-upgrade -d -y -o APT::Get::Show-Upgraded=true
safe-upgrade -y -o APT::Get::Show-Upgraded=true
==================================================
5. apt-listchangesの設定変更現在はupgrade中にconfirmation(変更点一覧の確認プロンプト)が出る設定になっているので、出ないように設定を変更。
# emacs /etc/apt/listchanges.conf
==================================================
#confirm=1
confirm=0
==================================================
6. 確認
* cronの時刻を適当に設定し、upgradeまで行われているかsyslogや/var/log/cron-apt/logを見て確認する。
確認後、以下のようにcron-aptを書き換える。
# emacs /etc/cron-apt/config
==================================================
# syslogには出力しない
SYSLOGON="always"
→ # SYSLOGON="always"
# ログのレベルをdebugからalwaysに
DEBUG="verbose"
→ DEBUG="always"
==================================================
* apti-listchangesの動作確認
以上☆
なんか、変にcronに梃子摺りました。
反応意外と遅かった。。。
といっても私のサーバじゃなくて、管理してる研究室のサーバに。
うちの研究室、Linuxサーバが大量にある割りに、そういうセキュリティに必要な設定を知らない人が多いんですよねー、もち私も含めて。
詳しい人がいる間に色々、改革してもらわんと♥
とりあえず、以下インストールと設定のログです。
1. cron-aptのインストール
# aptitude install cron-apt
2. cron-aptの設定
# emacs /etc/cron-apt/config
==================================================
# 以下の行を設定
#更新コマンドとしてaptitudeを設定
APTCOMMAND=/usr/bin/aptitude
#後述するupgrade設定のため
ACTIONDIR="/etc/cron-apt/action.d"
#ファイルの出力
ERROR="/var/log/cron-apt/error"
TEMP="/var/log/cron-apt/temp"
LOG="/var/log/cron-apt/log"
# syslogには常に出力
SYSLOGON="always"
# デバッグモード
DEBUG="verbose"
==================================================
3. 実行時刻の変更デフォルトは朝4時に動作するようになっている。
# emacs /etc/cron.d/cron-apt
==================================================
# Every morning at 6 o'clock.
0 6 * * * root test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt
==================================================
4. upgradeの設定標準設定ではupdateのみであるため、upgradeも行うように設定を変更
# emacs /etc/cron-apt/action.d/3-download
==================================================
# dist-upgrade -d -y -o APT::Get::Show-Upgraded=true
safe-upgrade -y -o APT::Get::Show-Upgraded=true
==================================================
5. apt-listchangesの設定変更現在はupgrade中にconfirmation(変更点一覧の確認プロンプト)が出る設定になっているので、出ないように設定を変更。
# emacs /etc/apt/listchanges.conf
==================================================
#confirm=1
confirm=0
==================================================
6. 確認
* cronの時刻を適当に設定し、upgradeまで行われているかsyslogや/var/log/cron-apt/logを見て確認する。
確認後、以下のようにcron-aptを書き換える。
# emacs /etc/cron-apt/config
==================================================
# syslogには出力しない
SYSLOGON="always"
→ # SYSLOGON="always"
# ログのレベルをdebugからalwaysに
DEBUG="verbose"
→ DEBUG="always"
==================================================
* apti-listchangesの動作確認
以上☆
なんか、変にcronに梃子摺りました。
反応意外と遅かった。。。
2009年6月19日金曜日
tracのインストール
作業用兼雑記用にtracを入れることにしました。
以下作業メモ。
1. まずtrac本体をinstall
# aptitude install trac
2. 次に、trac用のsubversionリポジトリの作成
$ cd /var/local/
$ mkdir repos
$ cd repos
$ sudo svnadmin peridot
3. 公開するtracの作成
$ cd /var/local/
$ mkdir tracs
$ cd tracs
$ sudo trac-admin peridot initenv
Project Name [My Project]>peridot
Database connection string [sqlite:db/trac.db]> #ここが
Repository type [svn]>
Path to repository [/path/to/repos]>/var/local/repos/peridot
これでtracそのものは完成。
以下のコマンドを打つと、8000番ポートでtracdが起動。
ブラウザで「localhost:8000」を打つと、肉球に会えます。
$ sudo tracd --port 8000 /var/local/tracs/peridot
4. apache2で動かすために所有者を変更
$ chown -R www-data:www-data peridot
この後、trac.cgiが見つからなくて思いっきり躓く。。。
/usr/share/doc/README.Debian.gzを確認したところ、tracのバージョンが0.11以上の場合、deployオプションつきのtrac-adminを実行しないとcgiスクリプトが生成されないらしい。。。
何じゃそら＜泣
/path/to/envの意味がよく分からなかったけど多分作ったプロジェクトのことだよね？
→とりあえずあとあと動いたので正解。
5. trac.cgiの生成
以下のようにコマンド実行！
$ sudo trac-admin /var/local/tracs/peridot deploy /usr/share/trac
無事、/usr/share/trac以下にtrac.cgi、trac.fcgiを確認。
一応、www-dataに所有者も変更しておいた。
$ sudo chown -R www-data:www-data /usr/share/trac
6. apache2の設定。
ほとんど説明書の丸コピ。
$ sudo emacs /etc/apache2/site-available/trac
ScriptAlias /trac /path/to/www/trac/cgi-bin/trac.cgi
SetHandler mod_python
PythonHandler trac.web.modpython_frontend
PythonInterpreter main
PythonOption TracEnv /var/local/tracs/peridot ＃プロジェクトの在り処
PythonOption TracUriRoot /trac ＃公開するURIパス
SetEnv PYTHON_EGG_CACHE /tmp
7. apache2での設定の反映
$ sudo a2ensite trac
$ sudo /etc/init.d/apache2 restart
よーやく動いたー！
もー日本語化はいいや。。。
以下作業メモ。
1. まずtrac本体をinstall
# aptitude install trac
2. 次に、trac用のsubversionリポジトリの作成
$ cd /var/local/
$ mkdir repos
$ cd repos
$ sudo svnadmin peridot
3. 公開するtracの作成
$ cd /var/local/
$ mkdir tracs
$ cd tracs
$ sudo trac-admin peridot initenv
Project Name [My Project]>peridot
Database connection string [sqlite:db/trac.db]> #ここが
Repository type [svn]>
Path to repository [/path/to/repos]>/var/local/repos/peridot
これでtracそのものは完成。
以下のコマンドを打つと、8000番ポートでtracdが起動。
ブラウザで「localhost:8000」を打つと、肉球に会えます。
$ sudo tracd --port 8000 /var/local/tracs/peridot
4. apache2で動かすために所有者を変更
$ chown -R www-data:www-data peridot
この後、trac.cgiが見つからなくて思いっきり躓く。。。
/usr/share/doc/README.Debian.gzを確認したところ、tracのバージョンが0.11以上の場合、deployオプションつきのtrac-adminを実行しないとcgiスクリプトが生成されないらしい。。。
何じゃそら＜泣
/path/to/envの意味がよく分からなかったけど多分作ったプロジェクトのことだよね？
→とりあえずあとあと動いたので正解。
5. trac.cgiの生成
以下のようにコマンド実行！
$ sudo trac-admin /var/local/tracs/peridot deploy /usr/share/trac
無事、/usr/share/trac以下にtrac.cgi、trac.fcgiを確認。
一応、www-dataに所有者も変更しておいた。
$ sudo chown -R www-data:www-data /usr/share/trac
6. apache2の設定。
ほとんど説明書の丸コピ。
$ sudo emacs /etc/apache2/site-available/trac
ScriptAlias /trac /path/to/www/trac/cgi-bin/trac.cgi
SetHandler mod_python
PythonHandler trac.web.modpython_frontend
PythonInterpreter main
PythonOption TracEnv /var/local/tracs/peridot ＃プロジェクトの在り処
PythonOption TracUriRoot /trac ＃公開するURIパス
SetEnv PYTHON_EGG_CACHE /tmp
7. apache2での設定の反映
$ sudo a2ensite trac
$ sudo /etc/init.d/apache2 restart
よーやく動いたー！
もー日本語化はいいや。。。
2009年6月18日木曜日
英語の推薦状
海外の学会に参加することになりました。
で、その学会、学生や開発途上国の研究者は旅費の補助を受けられるのですが、
そいつに応募するには、英語の推薦状が必要になるんですよ。
で、とりあえず指導教員に下書きして見せてみろ言われたので、
とりあえず、以下のサイトを参考に頑張って1ページ埋めました。
1.英文レターサンプル：担当教授からの推薦状
構成もまとまってて、いっちゃん参考になりました。
2.英文履歴書・カバーレター・推薦状
1との比較材料に。他にも履歴書とかもチラ見しました。
3.推薦状（その五） | 理系留学のススメ
書くときの心構え。何を書くべきか。
α.【海外】強力な推薦状が書ける教官【留学】
分野は違うが、日本人の現実を痛感･･･。
まず何が壁かというと、言葉の壁。。。
にーがーてー！英語は読めるけど書けん。。。
参考資料は結構、経済ものが多かったです。
やっぱりMBAが多いんだろうな。
にしても別に留学に使うような重要なものではないにせよ、
何で自分の推薦状を自分で書いてるんだろうな。
こっぱずかし！
で、その学会、学生や開発途上国の研究者は旅費の補助を受けられるのですが、
そいつに応募するには、英語の推薦状が必要になるんですよ。
で、とりあえず指導教員に下書きして見せてみろ言われたので、
とりあえず、以下のサイトを参考に頑張って1ページ埋めました。
1.英文レターサンプル：担当教授からの推薦状
構成もまとまってて、いっちゃん参考になりました。
2.英文履歴書・カバーレター・推薦状
1との比較材料に。他にも履歴書とかもチラ見しました。
3.推薦状（その五） | 理系留学のススメ
書くときの心構え。何を書くべきか。
α.【海外】強力な推薦状が書ける教官【留学】
分野は違うが、日本人の現実を痛感･･･。
まず何が壁かというと、言葉の壁。。。
にーがーてー！英語は読めるけど書けん。。。
参考資料は結構、経済ものが多かったです。
やっぱりMBAが多いんだろうな。
にしても別に留学に使うような重要なものではないにせよ、
何で自分の推薦状を自分で書いてるんだろうな。
こっぱずかし！
2009年6月17日水曜日
デスクトップに進めない。。。
少し前に、手持ちのサーバにDebianのlennyをインストールしました。
最初からGUIログインできる設定にしてショートカットキーを割り当てて…。
と、色々いじっているうちに、何故かGUIのログイン画面にて
ログインしてもログインしてもデスクトップにいけず、元のログイン画面に戻ってしまうと言う謎現象に＜涙
何故進めないの。。。
ググっても原因がなかなか見つからなくて困ったのですが、
詳しい友人に聞くと一発でした。
GUIログインの設定ファイル（.xsession）が間違っててそれで進めなかっただけ。
半角全角変換の切り替えを行うキーをキーボード左上のキーに割り当てようとした設定だったんですけど、どうもサイトから写すときにミスったみたいです。
とりあえずｄｅｌｅｔｅ。
$ rm /home/ユーザ名/.xsession
結果はばっちりでした♪
ちなみにgnomeの場合、GUI時のキー割当はGUI画面から設定できるそうです。
そりゃそうか。
一つ賢くなりました。
持つべきものはプロフェッショナルな友人ですねー。
ちなみに彼は学生ながらその手の専門雑誌に原稿を挙げたりしてるそうです。
すっごいなー。
うちも頑張らねば。
最初からGUIログインできる設定にしてショートカットキーを割り当てて…。
と、色々いじっているうちに、何故かGUIのログイン画面にて
ログインしてもログインしてもデスクトップにいけず、元のログイン画面に戻ってしまうと言う謎現象に＜涙
何故進めないの。。。
ググっても原因がなかなか見つからなくて困ったのですが、
詳しい友人に聞くと一発でした。
GUIログインの設定ファイル（.xsession）が間違っててそれで進めなかっただけ。
半角全角変換の切り替えを行うキーをキーボード左上のキーに割り当てようとした設定だったんですけど、どうもサイトから写すときにミスったみたいです。
とりあえずｄｅｌｅｔｅ。
$ rm /home/ユーザ名/.xsession
結果はばっちりでした♪
ちなみにgnomeの場合、GUI時のキー割当はGUI画面から設定できるそうです。
そりゃそうか。
一つ賢くなりました。
持つべきものはプロフェッショナルな友人ですねー。
ちなみに彼は学生ながらその手の専門雑誌に原稿を挙げたりしてるそうです。
すっごいなー。
うちも頑張らねば。
2009年4月24日金曜日
血を抜きにいってきました。
けど、断られました＜笑
大学に献血車が来ていたので、立ち寄ってみたところ、
残念ながら血の濃さが足りないということでアウト (>_<)
女性の場合、ヘモグロビンの量が12.5[g/dl]以上でないと
献血できないのですが、私は僅かに0.1届かず。。。
やっぱ最近の食生活がまずかったかぁ… orz|||
6月にもう一度来るらしいので、その時までに
ほうれん草とレバーを摂取しておきます。
そして献血車に描かれていたキャラクター。
・・・・・・。ポ○モン・・・？
大学に献血車が来ていたので、立ち寄ってみたところ、
残念ながら血の濃さが足りないということでアウト (>_<)
女性の場合、ヘモグロビンの量が12.5[g/dl]以上でないと
献血できないのですが、私は僅かに0.1届かず。。。
やっぱ最近の食生活がまずかったかぁ… orz|||
6月にもう一度来るらしいので、その時までに
ほうれん草とレバーを摂取しておきます。
そして献血車に描かれていたキャラクター。
・・・・・・。ポ○モン・・・？
2009年4月22日水曜日
2009年4月21日火曜日
なんばパークス
少し前になるのですが、友人となんばシティ、なんばパークスで
遊んできました。
学生なのでお手頃価格なシティの方が助かるのですが、
ちょっと味のある店は、やっぱりパークスに多いですね。
パークスの5F『Plants･Plants』で試験管で育てるランや
1Fの帽子屋さん『MAOZI』で緑のベレー帽を購入しました。
密閉された試験管内で育つ『In Vitro Garden（インビトロガーデン）』は
前々から注目していたので、今回購入できて大満足です。
日に当たるとすごくキレイ♪
半年から一年で鉢植えに植え替えが必要だそうで、
その後は一輪挿しにでも使ってくださいとのことです。
なるべくゆっくり育ってよ～。
それから購入はしませんでしたが、パズル屋『SOZ』も面白かったです。
プラスチック製の立体パズルで、動物や幾何学図形は勿論、
なんと椅子や机、壁まで作れてしまうというミラクル！
ただ店の位置が分かりにくくて、
てっきりパークスのショーウィンドウだと思ってた場所が店本体でした＜笑
おやつはタルト専門店『デリス デュ パレ』で頂きました。
私が食べたのは「季節のフルーツタルト」
果物がごろごろ乗ってて、大変おいしゅうございました☆
友人が食べたのが「赤い果実のタルト」
レアチーズ風味＆甘酸っぱさがなかなか♪
でも一番笑ったのは、シティの『グリーンデリ』のステッカー売り場でしょう。
あそこは笑える。
とりあえず、今隣の席に座ってるおにーさんにコレを送りたかった。
「肝心なところで噛みます」
…若干、後が怖いかも；；
遊んできました。
学生なのでお手頃価格なシティの方が助かるのですが、
ちょっと味のある店は、やっぱりパークスに多いですね。
パークスの5F『Plants･Plants』で試験管で育てるランや
1Fの帽子屋さん『MAOZI』で緑のベレー帽を購入しました。
密閉された試験管内で育つ『In Vitro Garden（インビトロガーデン）』は
前々から注目していたので、今回購入できて大満足です。
日に当たるとすごくキレイ♪
半年から一年で鉢植えに植え替えが必要だそうで、
その後は一輪挿しにでも使ってくださいとのことです。
なるべくゆっくり育ってよ～。
それから購入はしませんでしたが、パズル屋『SOZ』も面白かったです。
プラスチック製の立体パズルで、動物や幾何学図形は勿論、
なんと椅子や机、壁まで作れてしまうというミラクル！
ただ店の位置が分かりにくくて、
てっきりパークスのショーウィンドウだと思ってた場所が店本体でした＜笑
おやつはタルト専門店『デリス デュ パレ』で頂きました。
私が食べたのは「季節のフルーツタルト」
果物がごろごろ乗ってて、大変おいしゅうございました☆
友人が食べたのが「赤い果実のタルト」
レアチーズ風味＆甘酸っぱさがなかなか♪
でも一番笑ったのは、シティの『グリーンデリ』のステッカー売り場でしょう。
あそこは笑える。
とりあえず、今隣の席に座ってるおにーさんにコレを送りたかった。
「肝心なところで噛みます」
…若干、後が怖いかも；；
2009年4月19日日曜日
iPod touchを購入☆
実は購入したのは3月だったりましますが。
ちょっと忙しくて、なかなか使う機会がなかったのですが、
最近時間が取れるようになったのと、
前に注文していたiPhone兼iPod touchカバー（PIP-LCTPBR）が届いたので、
ようやくiPod touchを封切りました☆
（友人にiPodtouchは裏面がかなり傷つき易いと言われていたので、
元々ケースが届くまではしまっておくつもりでした）
まずは画面の保護シールを貼って、
購入したタッチペンつきのレザーケースにフィットイン。
ちなみにこのケース、立てても使えました。
ケースの手触りはなかなか♪
作りもしっかりしているし、表面を覆うカバーもついているので、
カバンにぽいっと放り込んでも安心です。
そしてWindowsと接続。
見事先の画面にすすみました。
が。
ここで予期せぬ問題が発生。
……タッチペンが反応せん。。。
どーゆーこと？
あれか、このケースのメーカーが出した保護シールじゃない保護シールで
表面を覆ってしまったのが駄目なのか！？
でも今更はがすなんてイヤだ。。。
……とりあえず、次に保護シールを取り替えるときに確認するとして。
しばらくはタッチペンが飾りとなることが決定した瞬間でした。(T_T;)
気を取り直して、iPod touchの画面をまず堪能。
[設定]からパスワードなどの基本的な設定だけして、
早速、iTuneストアへ☆
念願の英語PodCastをダウンロードしまくりました。
ついでに日経ニュースも。
さーこれで明日から通学時間に聞きまくるぞー！
遊びネタは、研究室の仲間から仕入れよ♪
ちょっと忙しくて、なかなか使う機会がなかったのですが、
最近時間が取れるようになったのと、
前に注文していたiPhone兼iPod touchカバー（PIP-LCTPBR）が届いたので、
ようやくiPod touchを封切りました☆
（友人にiPodtouchは裏面がかなり傷つき易いと言われていたので、
元々ケースが届くまではしまっておくつもりでした）
まずは画面の保護シールを貼って、
購入したタッチペンつきのレザーケースにフィットイン。
ちなみにこのケース、立てても使えました。
ケースの手触りはなかなか♪
作りもしっかりしているし、表面を覆うカバーもついているので、
カバンにぽいっと放り込んでも安心です。
そしてWindowsと接続。
見事先の画面にすすみました。
が。
ここで予期せぬ問題が発生。
……タッチペンが反応せん。。。
どーゆーこと？
あれか、このケースのメーカーが出した保護シールじゃない保護シールで
表面を覆ってしまったのが駄目なのか！？
でも今更はがすなんてイヤだ。。。
……とりあえず、次に保護シールを取り替えるときに確認するとして。
しばらくはタッチペンが飾りとなることが決定した瞬間でした。(T_T;)
気を取り直して、iPod touchの画面をまず堪能。
[設定]からパスワードなどの基本的な設定だけして、
早速、iTuneストアへ☆
念願の英語PodCastをダウンロードしまくりました。
ついでに日経ニュースも。
さーこれで明日から通学時間に聞きまくるぞー！
遊びネタは、研究室の仲間から仕入れよ♪
2009年4月12日日曜日
Debian(lenny)でルータ！
研究室のDHCP兼ルータサーバを引き継いだのですが、
時期が中途半端だったために、えらい苦労しました。
思うにサーバは構築途中で誰かが引きついじゃいけませんね。
資料が残っていても、実際その資料を書くまでに何を試して何をやってなかったかが
わからないので、ものすごい労力の無駄が発生します。。。
一から構築するなら、それも経験になるけど、
半端に引き継ぐと結局知識も体系的につかないので、あまり嬉しくない。
つまりは動作確認ぐらいしてから卒業して欲しかった(怒)ということで。
いや、せめて設定を変に飛ばさずに、順々にやってくれれば…。
閑話休題。
というわけで、Debian（Lenny）でルータを構築しました。
ルータにも色々種類がありますが、今回構築したのはNAT/IPマスカレードです。
N個のプライベートアドレスしかないのサーバが外にアクセスする際、
そのネットワークの元締め（ゲートウェイ）であるルータが持っているM個のグローバルに
それぞれ結びつけるというものです。
DHCP、iptablesのインストール、固定IPを持つホストの設定、
それからiptables設定スクリプトのの基礎設定までは前任者がやってくださっていたのですが、
iptablesの設定スクリプトをいくらいじってもルータとして機能してくれませんでした。
原因はカーネルモジュールの不足。
iptable_natというモジュールをロードしないと、Debianはルータとして動いてくれません(;_;)
まず以下のコマンドで、iptable_natをロード。
# modprobe iptable_nat
それから、以下のコマンドでロードされた結果を確認。
もし、iptable_natがなければ、何も出力されないので、上のコマンドをもう一回試しましょう。
# lsmod|grep iptable
>> 出力結果
iptable_filter 2560 1
iptable_nat 4616 1
似たようなのが何行か続く。
そして、起動時に自動でモジュールがロードされるように設定します。
# echo ‘iptable_nat’ >> /etc/modules
カーネルモジュールのロードに必要な作業はここまで。
次にNAT/IPマスカレードを有効にするために、以下の設定を行います。
# vi /etc/sysctl.conf
======================
net.ipv4.tcp_syncookies = 1 # syn攻撃対策
net.ipv4.ip_forward = 1 # NATを有効化
net.ipv4.icmp_echo_ignore_broadcasts = 1 # Smurf攻撃対策
net.ipv4.icmp_ignore_bogus_error_responses = 1 #
======================
ところで、ip_forwardは/proc/sys/net/ipv4/ip_forwardにもファイルがあるのですが、
どういう従属関係なんでしょう？？
後日、確認。
ここまで設定したら、マシンを再起動。
起動したら、ようやっと用意したiptables.shを実行する段階に移ります。
synフロッドなどのセキュリティ対策の設定を省くと以下のような感じです。
ユーザ定義チェーンを使ってINPUT（ルータへの外部からのアクセス）、FORWARD（転送）を
MYCHAIN処理に飛ばして、両者の処理を一括して書いています。
======================
#!/bin/sh
# 既存の設定をクリア
iptables -F
iptables -t nat -F POSTROUTING
iptables -X
# NAT/IPマスカレードのための設定
iptables -t nat -A POSTROUTING -s 192.168.0.0/16(自分のネットワークを書く) -o eth0 -j MASQUERADE
# 基本ポリシ
# OUTPUT（ルータから外部へのアクセス）はACCEPT許可する
# INPUT（外部からルータへのアクセス）とFORWARD（転送）は原則DROP禁止。
iptables -P FORWARD DROP
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
# INPUTとFORWARDの処理を一括して設定するために
# 両者をMYCHAINというユーザ定義チェーンに結びつける
iptables -N MYCHAIN
iptables -A FORWARD -j MYCHAIN
iptables -A INPUT -j MYCHAIN
#-------------------------------#
# MYCHAIN == INPUT and FORWARD access
#-------------------------------#
# 自分自身（ローカルホスト: lo）からのINPUT、FORWARDは許可
iptables -A MYCHAIN -i lo -j ACCEPT
# 内部LANからのアクセスも許可
iptables -A MYCHAIN -i eth1 -j ACCEPT
# 既に確立されたアクセスについても許可
iptables -A MYCHAIN -m state --state ESTABLISHED,RELATED -j ACCEPT
# 特定のポートに対するアクセスを許可する
# ここではSSH、DNS、HTTP、HTTPの8080番を許可
iptables -A MYCHAIN -p tcp -m state --state NEW --dport 22 -j ACCEPT
iptables -A MYCHAIN -p tcp -m state --state NEW --sport 22 -j ACCEPT
iptables -A MYCHAIN -p udp -m state --state NEW --dport 53 -j ACCEPT
iptables -A MYCHAIN -p udp -m state --state NEW --sport 53 -j ACCEPT
iptables -A MYCHAIN -p tcp -m state --state NEW --dport 80 -j ACCEPT
iptables -A MYCHAIN -p tcp -m state --state NEW --sport 80 -j ACCEPT
iptables -A MYCHAIN -p tcp -m state --state NEW --dport 8080 -j ACCEPT
iptables -A MYCHAIN -p tcp -m state --state NEW --sport 8080 -j ACCEPT
# icmpは原則OK
iptables -A MYCHAIN -p icmp -j ACCEPT
#------------------------------#
# MYCHAIN end
#------------------------------#
======================
MASQUERADEの行の位置は未だに良く分かっていない。。。
とりあえず動くのでOK。
最後にこのシェルスクリプトを/etc/network/if-up.d/以下にコピー。
これで毎回ネットワークが起動するたびに読み込んでくれる、と。
LAN内部から外部ホームページが見れることだけ確認してOK。
ルータサーバが完成しましたー♪
時期が中途半端だったために、えらい苦労しました。
思うにサーバは構築途中で誰かが引きついじゃいけませんね。
資料が残っていても、実際その資料を書くまでに何を試して何をやってなかったかが
わからないので、ものすごい労力の無駄が発生します。。。
一から構築するなら、それも経験になるけど、
半端に引き継ぐと結局知識も体系的につかないので、あまり嬉しくない。
つまりは動作確認ぐらいしてから卒業して欲しかった(怒)ということで。
いや、せめて設定を変に飛ばさずに、順々にやってくれれば…。
閑話休題。
というわけで、Debian（Lenny）でルータを構築しました。
ルータにも色々種類がありますが、今回構築したのはNAT/IPマスカレードです。
N個のプライベートアドレスしかないのサーバが外にアクセスする際、
そのネットワークの元締め（ゲートウェイ）であるルータが持っているM個のグローバルに
それぞれ結びつけるというものです。
DHCP、iptablesのインストール、固定IPを持つホストの設定、
それからiptables設定スクリプトのの基礎設定までは前任者がやってくださっていたのですが、
iptablesの設定スクリプトをいくらいじってもルータとして機能してくれませんでした。
原因はカーネルモジュールの不足。
iptable_natというモジュールをロードしないと、Debianはルータとして動いてくれません(;_;)
まず以下のコマンドで、iptable_natをロード。
# modprobe iptable_nat
それから、以下のコマンドでロードされた結果を確認。
もし、iptable_natがなければ、何も出力されないので、上のコマンドをもう一回試しましょう。
# lsmod|grep iptable
>> 出力結果
iptable_filter 2560 1
iptable_nat 4616 1
似たようなのが何行か続く。
そして、起動時に自動でモジュールがロードされるように設定します。
# echo ‘iptable_nat’ >> /etc/modules
カーネルモジュールのロードに必要な作業はここまで。
次にNAT/IPマスカレードを有効にするために、以下の設定を行います。
# vi /etc/sysctl.conf
======================
net.ipv4.tcp_syncookies = 1 # syn攻撃対策
net.ipv4.ip_forward = 1 # NATを有効化
net.ipv4.icmp_echo_ignore_broadcasts = 1 # Smurf攻撃対策
net.ipv4.icmp_ignore_bogus_error_responses = 1 #
======================
ところで、ip_forwardは/proc/sys/net/ipv4/ip_forwardにもファイルがあるのですが、
どういう従属関係なんでしょう？？
後日、確認。
ここまで設定したら、マシンを再起動。
起動したら、ようやっと用意したiptables.shを実行する段階に移ります。
synフロッドなどのセキュリティ対策の設定を省くと以下のような感じです。
ユーザ定義チェーンを使ってINPUT（ルータへの外部からのアクセス）、FORWARD（転送）を
MYCHAIN処理に飛ばして、両者の処理を一括して書いています。
======================
#!/bin/sh
# 既存の設定をクリア
iptables -F
iptables -t nat -F POSTROUTING
iptables -X
# NAT/IPマスカレードのための設定
iptables -t nat -A POSTROUTING -s 192.168.0.0/16(自分のネットワークを書く) -o eth0 -j MASQUERADE
# 基本ポリシ
# OUTPUT（ルータから外部へのアクセス）はACCEPT許可する
# INPUT（外部からルータへのアクセス）とFORWARD（転送）は原則DROP禁止。
iptables -P FORWARD DROP
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
# INPUTとFORWARDの処理を一括して設定するために
# 両者をMYCHAINというユーザ定義チェーンに結びつける
iptables -N MYCHAIN
iptables -A FORWARD -j MYCHAIN
iptables -A INPUT -j MYCHAIN
#-------------------------------#
# MYCHAIN == INPUT and FORWARD access
#-------------------------------#
# 自分自身（ローカルホスト: lo）からのINPUT、FORWARDは許可
iptables -A MYCHAIN -i lo -j ACCEPT
# 内部LANからのアクセスも許可
iptables -A MYCHAIN -i eth1 -j ACCEPT
# 既に確立されたアクセスについても許可
iptables -A MYCHAIN -m state --state ESTABLISHED,RELATED -j ACCEPT
# 特定のポートに対するアクセスを許可する
# ここではSSH、DNS、HTTP、HTTPの8080番を許可
iptables -A MYCHAIN -p tcp -m state --state NEW --dport 22 -j ACCEPT
iptables -A MYCHAIN -p tcp -m state --state NEW --sport 22 -j ACCEPT
iptables -A MYCHAIN -p udp -m state --state NEW --dport 53 -j ACCEPT
iptables -A MYCHAIN -p udp -m state --state NEW --sport 53 -j ACCEPT
iptables -A MYCHAIN -p tcp -m state --state NEW --dport 80 -j ACCEPT
iptables -A MYCHAIN -p tcp -m state --state NEW --sport 80 -j ACCEPT
iptables -A MYCHAIN -p tcp -m state --state NEW --dport 8080 -j ACCEPT
iptables -A MYCHAIN -p tcp -m state --state NEW --sport 8080 -j ACCEPT
# icmpは原則OK
iptables -A MYCHAIN -p icmp -j ACCEPT
#------------------------------#
# MYCHAIN end
#------------------------------#
======================
MASQUERADEの行の位置は未だに良く分かっていない。。。
とりあえず動くのでOK。
最後にこのシェルスクリプトを/etc/network/if-up.d/以下にコピー。
これで毎回ネットワークが起動するたびに読み込んでくれる、と。
LAN内部から外部ホームページが見れることだけ確認してOK。
ルータサーバが完成しましたー♪
2009年4月9日木曜日
外付けHDDのデバイスファイルをdmesgで調べる
マウントに使う外付けHDDのデバイスファイル（/dev/以下のsdaとか）の場所を
いつもは総当りで調べてるのですが＜汗
さすがに何時までもそれではヤバイだろう！ということで
ちゃんと調べる事にしました。
手順は以下の通りです。
---------
1. 外付けHDDを起動した状態で、サーバのUSBポートに差し込む。
その後、以下のコマンドを打つ。
# dmesg | grep hd
そうするとHDDのメーカーやHDDの容量と一緒にsdaやsdbという単語が出てくる。
こんな感じの行があるはず。
SCSI device sdb: 312581808 512-byte hdwr sectors (160042 MB)
これがデバイスファイル。
ただ、実際/dev/以下を調べてみると、sdbだけじゃなくてsdb1やらsdb2が作られている。
一番数字の大きいものが、ちゃんと繋がるデバイスファイルとなる。
2. マウントコマンドでマウントする。
マウントポイント（/mnt/hdd）は自分で勝手に作ったやつ。
# mount /dev/sdb2 /mnt/hdd
---------
何故、こんな簡単な操作に戸惑っていたかというと、
どうもHDDのフォーマットに失敗していたらしく、
dmesgが上手く出てくれてなかったんです。。。＜泣
今も、
VFS: Can't find a valid FAT filesystem on dev sdb.
とかいう警告を吐いてくれてます。。。
まあ、何とか繋がるんですけどね。
フォーマットした頃は完全ド素人。
しかも以前Windowsで使われてたHDDなので、どうやら操作ミスしてたみたいです。
160GB近くあるからデータの移行はあまりしたくないのになぁ。。。
いつもは総当りで調べてるのですが＜汗
さすがに何時までもそれではヤバイだろう！ということで
ちゃんと調べる事にしました。
手順は以下の通りです。
---------
1. 外付けHDDを起動した状態で、サーバのUSBポートに差し込む。
その後、以下のコマンドを打つ。
# dmesg | grep hd
そうするとHDDのメーカーやHDDの容量と一緒にsdaやsdbという単語が出てくる。
こんな感じの行があるはず。
SCSI device sdb: 312581808 512-byte hdwr sectors (160042 MB)
これがデバイスファイル。
ただ、実際/dev/以下を調べてみると、sdbだけじゃなくてsdb1やらsdb2が作られている。
一番数字の大きいものが、ちゃんと繋がるデバイスファイルとなる。
2. マウントコマンドでマウントする。
マウントポイント（/mnt/hdd）は自分で勝手に作ったやつ。
# mount /dev/sdb2 /mnt/hdd
---------
何故、こんな簡単な操作に戸惑っていたかというと、
どうもHDDのフォーマットに失敗していたらしく、
dmesgが上手く出てくれてなかったんです。。。＜泣
今も、
VFS: Can't find a valid FAT filesystem on dev sdb.
とかいう警告を吐いてくれてます。。。
まあ、何とか繋がるんですけどね。
フォーマットした頃は完全ド素人。
しかも以前Windowsで使われてたHDDなので、どうやら操作ミスしてたみたいです。
160GB近くあるからデータの移行はあまりしたくないのになぁ。。。
2009年4月5日日曜日
Afternoon Teaの時計を追加
サイドバーにAfternoon Teaの時計を追加しました。
Afternoon Teaは、私が今一番お気に入りの雑貨屋さんです。
小物のデザインがすごく綺麗で、品があるんですよね。
毎月発行しているペーパー(spice of a day)も可愛くて
ついつい手にとってしまう。
その月のカレンダーが付録になっているのが尚ヨシ☆
女性へのプレゼント探しなんかにも、本当にお勧めのお店です。
Afternoon Tea
http://www.afternoon-tea.net/main.html
Afternoon Teaは、私が今一番お気に入りの雑貨屋さんです。
小物のデザインがすごく綺麗で、品があるんですよね。
毎月発行しているペーパー(spice of a day)も可愛くて
ついつい手にとってしまう。
その月のカレンダーが付録になっているのが尚ヨシ☆
女性へのプレゼント探しなんかにも、本当にお勧めのお店です。
Afternoon Tea
http://www.afternoon-tea.net/main.html
万年筆☆LAMY
桜を観に両親が京都に来たので、ついでに万年筆を見に行きました。
買うならペン先の具合とか太さとか確認した方が良いとのアドバイスで、
験し書きさせてもらえる店を探したところ、
京都烏丸にあるVoltaireという時計・万年筆ショップにまず行ってみることにしました。
Voltaire
http://www.voltaire.jp/
地下鉄烏丸駅を降りて、烏丸通を北に歩いていくと、大きなペン先の看板を発見☆
迷う心配はなさそうだな、こりゃ＜笑
ウィンドウの雰囲気も良くて、期待して中に入ると、
実際、まるでブランドショップのような、お洒落な雰囲気のお店でした。
意外と広いなーと思って歩いていると、奥にある鏡に気付かずぶつかりそうに＜笑
広く見えたのはコイツのせいか。
置いてある万年筆も云十万クラスのものから、
数千円のお手ごろ価格まで様々。
Deltaが特に多めかな？
私が事前に見繕っていたPelikanやPilotも結構取り扱っていました。
両親を店内をぐるぐる見て回ってると、途中、
変なお客さんが来たらしく、店員のお姉さんが笑顔かつ過激(!)に対応してました。
ちょっと怖かったです…(((･Α･川)))ﾌﾞﾙﾌﾞﾙ
色々見て回った結果、機能云々は置いて、
まず直感的にデザインが気に入ったものにすることにしました。
気に入ってないとまず使わないしね、私の場合＜汗
それで候補に上がったのがLAMYのサファリ（SilverGreen）と
Watermanのメトロポリタン シィメリー（Green）。
書き味はメトロポリタンの方が柔らかくて書き易かったけど、細身なのが難点。
サファリは太さもデザインもモロ好みで
ペン先は若干固かったものの、こっちを買う事にしました。
で、笑顔でお客さんを撃退していた店のお姉さんが、話してみると結構面白い方で、
気軽に色々試し書きさせてもらえました。
最後の方は、インクの話で盛り上がって、
Pilotのインク名が和名（露草とか冬将軍、etc.）の色彩雫シリーズや、
おフランス産、香りつきインクのエルバンとか、色々挑戦させて貰いました。
めっちゃ楽しかった♪
今回はLAMY本体とカートリッジだけの購入でしたが、
いずれコンバータ(好きなインクを注入できるカートリッジ)と
お気に入りのインク瓶も購入したいものです。
家に帰ってから記念撮影！
愛用しまーす☆
買うならペン先の具合とか太さとか確認した方が良いとのアドバイスで、
験し書きさせてもらえる店を探したところ、
京都烏丸にあるVoltaireという時計・万年筆ショップにまず行ってみることにしました。
Voltaire
http://www.voltaire.jp/
地下鉄烏丸駅を降りて、烏丸通を北に歩いていくと、大きなペン先の看板を発見☆
迷う心配はなさそうだな、こりゃ＜笑
ウィンドウの雰囲気も良くて、期待して中に入ると、
実際、まるでブランドショップのような、お洒落な雰囲気のお店でした。
意外と広いなーと思って歩いていると、奥にある鏡に気付かずぶつかりそうに＜笑
広く見えたのはコイツのせいか。
置いてある万年筆も云十万クラスのものから、
数千円のお手ごろ価格まで様々。
Deltaが特に多めかな？
私が事前に見繕っていたPelikanやPilotも結構取り扱っていました。
両親を店内をぐるぐる見て回ってると、途中、
変なお客さんが来たらしく、店員のお姉さんが笑顔かつ過激(!)に対応してました。
ちょっと怖かったです…(((･Α･川)))ﾌﾞﾙﾌﾞﾙ
色々見て回った結果、機能云々は置いて、
まず直感的にデザインが気に入ったものにすることにしました。
気に入ってないとまず使わないしね、私の場合＜汗
それで候補に上がったのがLAMYのサファリ（SilverGreen）と
Watermanのメトロポリタン シィメリー（Green）。
書き味はメトロポリタンの方が柔らかくて書き易かったけど、細身なのが難点。
サファリは太さもデザインもモロ好みで
ペン先は若干固かったものの、こっちを買う事にしました。
で、笑顔でお客さんを撃退していた店のお姉さんが、話してみると結構面白い方で、
気軽に色々試し書きさせてもらえました。
最後の方は、インクの話で盛り上がって、
Pilotのインク名が和名（露草とか冬将軍、etc.）の色彩雫シリーズや、
おフランス産、香りつきインクのエルバンとか、色々挑戦させて貰いました。
めっちゃ楽しかった♪
今回はLAMY本体とカートリッジだけの購入でしたが、
いずれコンバータ(好きなインクを注入できるカートリッジ)と
お気に入りのインク瓶も購入したいものです。
家に帰ってから記念撮影！
愛用しまーす☆
2009年4月2日木曜日
2009年3月27日金曜日
apacheで.svn以下へのアクセス禁止
ホームページをSVNで管理するために、
リポジトリ、ワーキングコピーを作ったまでは良かったものの、
.svnディレクトリ以下を公開禁止にする設定でつまずいた。
.htaccessファイルで設定可能と思っていたんだけど、
どうやらapacheの設定ファイルじゃないと無理みたい。
.svnというディレクトリ名を正規表現でひっかけるために
ディレクティブの設定がいるんだけど、
これは残念ながら.htaccessファイルには書けない。
書くと恐怖の500を吐く(TmT)
しゃーないので、まず別のサーバのapache2.confに以下を追記。
<DirectoryMatch "/*/\.svn">
deny from all
</DirectoryMatch>
とりあえず、これで上手く行くのは確認したんだけど。
私が設定したいサーバは、私、設定ファイル触れないんですが。。。
管理者に依頼せな……めんどい～。
リポジトリ、ワーキングコピーを作ったまでは良かったものの、
.svnディレクトリ以下を公開禁止にする設定でつまずいた。
.htaccessファイルで設定可能と思っていたんだけど、
どうやらapacheの設定ファイルじゃないと無理みたい。
.svnというディレクトリ名を正規表現でひっかけるために
これは残念ながら.htaccessファイルには書けない。
書くと恐怖の500を吐く(TmT)
しゃーないので、まず別のサーバのapache2.confに以下を追記。
<DirectoryMatch "/*/\.svn">
deny from all
</DirectoryMatch>
とりあえず、これで上手く行くのは確認したんだけど。
私が設定したいサーバは、私、設定ファイル触れないんですが。。。
管理者に依頼せな……めんどい～。
2009年3月24日火曜日
卒業式
22日は大学の卒業式でした。
女の先輩、後輩はみんな華やかに袴姿＆振袖姿☆
男もひょっとして後輩が1人袴を着てくるんじゃないかと期待していたのですが
残念ながらスーツでした。
カッコ良いのになぁ袴。。。
卒業式の後は恒例の写真大会。
そして飲み会。
久しぶりに三次会まで出席してオールしました。
翌日、丸一日爆睡する羽目になり、
なんというか精神的な体力の低下を感じました。。。
閑話休題。
しかし、袴の値段を知らない男の子って結構多いんですね。
女後輩「3万くらいかかったわ～」
男後輩「ええっそんなにかかるん！？」
いや、3万ですめば安い方だって。
最近は購入費用や維持管理の手間のせいで
レンタルがほとんどなんですけど、それでも普通5万位はかかるのに。。。
突然脱線しますが、最近レンタルひいてはシェアリングが重視されてますよね。
ワークシェアリングにカーシェアリングといい。
個人的にはペット（出来れば猫！）のシェアリングとかやって欲しいんですけど
生ものはやっぱだめかぁ･･･(´･ω･`)ｼｮﾎﾞｰﾝ
これがホントの閑話休題。
私も袴のレンタルには五万くらいかかりました。
当の袴代、美容院での着付け、ヘアセット代、プラス写真代です。
写真だけで1万くらいかかるので、私はコースから外そうとしたのですが、
当日見に来れない親に「撮っといて！！」と押し切られました。
化粧については自分でやれますけど、着付けとヘアセットは絶対無理なので
これも大学からタクシーでいける距離の美容院を予約。
ただし、へアセットについては厳密に指定しないと美容院のおばちゃんに
「大盛り」「特盛り」にされたりするので（涙）、うっすらとでも希望がある場合、
写真を持って行かないと後悔します。。。
あと髪飾りについて用意していない美容院が最近多いみたいですね。
当日に後輩が髪飾りをつける場合は購入するように、言われて憤激してました。
どこの会社か知らんが、コースにちゃんと明記しておけよ。。。
予約をとったのは、10月ごろです。
かなり早めの予約でしたが、おかげで希望の時間帯を取れました。
遅くなると着付けしてくれる美容院の予約が真っ当な時間に取れないんですよ。
朝の六時とかざらです。
無理。そんな時間に美容院まで移動できない。。。
と、記憶がはっきりしている内にメモ。
来年の自分の卒業式でも早めに予約しないとなぁ。
今度は振袖かなぁ♪
そして絶対にヘアセット写真を用意しないとなぁ。。。
女の先輩、後輩はみんな華やかに袴姿＆振袖姿☆
男もひょっとして後輩が1人袴を着てくるんじゃないかと期待していたのですが
残念ながらスーツでした。
カッコ良いのになぁ袴。。。
卒業式の後は恒例の写真大会。
そして飲み会。
久しぶりに三次会まで出席してオールしました。
翌日、丸一日爆睡する羽目になり、
なんというか精神的な体力の低下を感じました。。。
閑話休題。
しかし、袴の値段を知らない男の子って結構多いんですね。
女後輩「3万くらいかかったわ～」
男後輩「ええっそんなにかかるん！？」
いや、3万ですめば安い方だって。
最近は購入費用や維持管理の手間のせいで
レンタルがほとんどなんですけど、それでも普通5万位はかかるのに。。。
突然脱線しますが、最近レンタルひいてはシェアリングが重視されてますよね。
ワークシェアリングにカーシェアリングといい。
個人的にはペット（出来れば猫！）のシェアリングとかやって欲しいんですけど
生ものはやっぱだめかぁ･･･(´･ω･`)ｼｮﾎﾞｰﾝ
これがホントの閑話休題。
私も袴のレンタルには五万くらいかかりました。
当の袴代、美容院での着付け、ヘアセット代、プラス写真代です。
写真だけで1万くらいかかるので、私はコースから外そうとしたのですが、
当日見に来れない親に「撮っといて！！」と押し切られました。
化粧については自分でやれますけど、着付けとヘアセットは絶対無理なので
これも大学からタクシーでいける距離の美容院を予約。
ただし、へアセットについては厳密に指定しないと美容院のおばちゃんに
「大盛り」「特盛り」にされたりするので（涙）、うっすらとでも希望がある場合、
写真を持って行かないと後悔します。。。
あと髪飾りについて用意していない美容院が最近多いみたいですね。
当日に後輩が髪飾りをつける場合は購入するように、言われて憤激してました。
どこの会社か知らんが、コースにちゃんと明記しておけよ。。。
予約をとったのは、10月ごろです。
かなり早めの予約でしたが、おかげで希望の時間帯を取れました。
遅くなると着付けしてくれる美容院の予約が真っ当な時間に取れないんですよ。
朝の六時とかざらです。
無理。そんな時間に美容院まで移動できない。。。
と、記憶がはっきりしている内にメモ。
来年の自分の卒業式でも早めに予約しないとなぁ。
今度は振袖かなぁ♪
そして絶対にヘアセット写真を用意しないとなぁ。。。
2009年3月20日金曜日
Excelの棒グラフの目盛に1日を使うには
バイトで久しぶりにExcel使うと関数かなり忘れてた。。。
さらに苦労したのが、グラフの作り方。
研究でグラフも扱うとはいえ、月単位とか株価グラフとかは完全に専門外(>_<)
特につまずいたのが、日々の変量を表す棒グラフを作るときに、
軸の目盛として月の始めの日（1日）だけを表示する方法。
忘れたときのためにメモっておく。
これでOKボタンを押せば出来上がり☆
さらに苦労したのが、グラフの作り方。
研究でグラフも扱うとはいえ、月単位とか株価グラフとかは完全に専門外(>_<)
特につまずいたのが、日々の変量を表す棒グラフを作るときに、
軸の目盛として月の始めの日（1日）だけを表示する方法。
忘れたときのためにメモっておく。
- グラフの軸をダブルクリックして「軸の書式設定」パネルを呼び出す
- 「目盛」タブを開く
- 「最小値」に開始月の1日を指定 => ”2008/4/1”など
- 「基本単位」は「日」でチェックを外す
- 「目盛間隔」は「1月」でやっぱりチェックを外す
- 「補助目盛間隔」は「1月」でこいつはチェックする
- 「Y/数値軸との交点」は当然ながら3で指定した「最小値」と同じ値
これでOKボタンを押せば出来上がり☆
2009年3月19日木曜日
ログアウト後もコマンド命令を実行
私が所属する研究室では自分が管理しているサーバを
年に一回、再構築するという決まりがあります。
んで、再構築＆移行を始めたものの、これがまたコピーするデータ量の多いこと。
私が管理してるのはファイルサーバじゃないんだよっヽ（｀⌒´♯）ノ
と愚痴っても始まらないので黙々と作業していたのですが
SSHでコマンド打ってたので、何かの拍子にうっかりログアウトすると
cpが途中で止まっちゃたりするんですよね。。。
2回それで泣いた後、
# nohup ログアウト後も実行したいコマンド > /dev/null &
というコマンドをようやく知りました。
nohupで、実行コマンドをプロセス化することによって
ログアウト後もコマンドが実行され続ける。
&で、コマンド実行中も同じコンソールで作業が出来る。
このとき > /dev/nul でコンソールへの出力を逃がさないと
ダーっと文字列が流れてきて面倒。
もっと早く知りたかった。。。
年に一回、再構築するという決まりがあります。
んで、再構築＆移行を始めたものの、これがまたコピーするデータ量の多いこと。
私が管理してるのはファイルサーバじゃないんだよっヽ（｀⌒´♯）ノ
と愚痴っても始まらないので黙々と作業していたのですが
SSHでコマンド打ってたので、何かの拍子にうっかりログアウトすると
cpが途中で止まっちゃたりするんですよね。。。
2回それで泣いた後、
# nohup ログアウト後も実行したいコマンド > /dev/null &
というコマンドをようやく知りました。
nohupで、実行コマンドをプロセス化することによって
ログアウト後もコマンドが実行され続ける。
&で、コマンド実行中も同じコンソールで作業が出来る。
このとき > /dev/nul でコンソールへの出力を逃がさないと
ダーっと文字列が流れてきて面倒。
もっと早く知りたかった。。。
2009年3月17日火曜日
Touch Lite
iPod touchを買う予定なのですが、
保護カバーですごく綺麗なのを見つけました。
MSY、メタリックな外観のiPod touch/iPhone用保護ケース
あまりの美しさに一目惚れしました。
特に下段のNoelがえらい好みのタイプです。
つか、買っても指紋付けられん(^m^;)
保護カバーですごく綺麗なのを見つけました。
MSY、メタリックな外観のiPod touch/iPhone用保護ケース
あまりの美しさに一目惚れしました。
特に下段のNoelがえらい好みのタイプです。
つか、買っても指紋付けられん(^m^;)
2009年3月9日月曜日
万年筆が欲しい
前回のエントリにも書いた通り、結婚式の返信は万年筆がマナー。
知らなかった過去は仕方ないとして、
知ってしまった以上、次回からはちゃんと書きたい！
というわけで万年筆、買おうかと考えています。
いや、今の若い子は万年筆なんてフツーに持ってないんですよ。
蛍光イエローの万年筆なら、何故かあったりしますが＜笑
とりあえず、色々メーカーの評判を聞き比べてみて、
良いかなと思ったのがパイロットとPelicanです。
パイロットはペン先の種類が多く、
Pelicanはインクの密閉性が高くて乾きにくい、らしいです。
こちらのサイトさんで勉強しました。
http://ameblo.jp/kuronavi/
http://www.mannenhitsu.info/fpenmap/2006/10/post_8.html
あとは実際に店に行って、握り心地を確かめてみます。
そして多分、ネットで安く買う(^m^;
http://kuronavi.com/
知らなかった過去は仕方ないとして、
知ってしまった以上、次回からはちゃんと書きたい！
というわけで万年筆、買おうかと考えています。
いや、今の若い子は万年筆なんてフツーに持ってないんですよ。
蛍光イエローの万年筆なら、何故かあったりしますが＜笑
とりあえず、色々メーカーの評判を聞き比べてみて、
良いかなと思ったのがパイロットとPelicanです。
パイロットはペン先の種類が多く、
Pelicanはインクの密閉性が高くて乾きにくい、らしいです。
こちらのサイトさんで勉強しました。
http://ameblo.jp/kuronavi/
http://www.mannenhitsu.info/fpenmap/2006/10/post_8.html
あとは実際に店に行って、握り心地を確かめてみます。
そして多分、ネットで安く買う(^m^;
http://kuronavi.com/
2009年3月7日土曜日
結婚式のお祝儀
結婚式のお祝儀は、奇数でなければならない。
とはよく聞く話ですが、1万じゃすくないし、3万じゃ懐が痛すぎるのがホンネ。
でもどうやら、２万でもやり方次第でマナー違反にはならないようです。
あなたを三ヶ月分とっていた元手は十分に取れました。
あとはお祝儀袋用意せなー。
私はてっきり水引＝お祝儀袋だと思っていたのですが、
今回ようやく水引＝飾り紐だということを知りました。
だって、それで今まで話通じてたんだよ。。。
けど、結婚式の返信には万年筆がマナーってのも後から知ったしな。。。
色々、常識の勉強が必要なようです。
そろそろ学生ってだけでは通用しない年になってきましたしね。
とはよく聞く話ですが、1万じゃすくないし、3万じゃ懐が痛すぎるのがホンネ。
でもどうやら、２万でもやり方次第でマナー違反にはならないようです。
「二万円には『ペア』という意味もあるので、しきたりは気にしなくて良い」耳寄りな情報をありがとう、日経新聞。
…一万円札を一枚、五千円札を二枚入れることで合計枚数で奇数にする方法。「マナー知らずの招待客と思われずに済む」というわけだ。
日経PLUS１ 2009/3/7 一面より
あなたを三ヶ月分とっていた元手は十分に取れました。
あとはお祝儀袋用意せなー。
私はてっきり水引＝お祝儀袋だと思っていたのですが、
今回ようやく水引＝飾り紐だということを知りました。
だって、それで今まで話通じてたんだよ。。。
けど、結婚式の返信には万年筆がマナーってのも後から知ったしな。。。
色々、常識の勉強が必要なようです。
そろそろ学生ってだけでは通用しない年になってきましたしね。
2009年3月6日金曜日
Evernote2日目
……重い。
何でこんなに重厚なんだ？(動作が)
2日目にして早くも挫折しそうです。
整理ツールとしては確かに有能なんだけど。。。
エディタ機能がこう、フラッシュ上に書き込んでいるような使い心地です。
びみょーすぎる。
何で先輩のみたいにサクサク動かないんだろう。
と思っていたら、どうやら元々Windows版は微妙という評判はあった模様。
http://masashi.biz/blog/archives/001193.html
http://www.mobile-bozu.com/mt/mt-search.cgi?tag=Evernote&IncludeBlogs=1
ホントこのもっさり感をどうにかしてー。
今度、メインパソコンをDebianに替える予定なのですが、
そっちではちゃんと動くのかなぁ？
…というかそもそもEvernoteにLinux版ってあるのかしら？？
何でこんなに重厚なんだ？(動作が)
2日目にして早くも挫折しそうです。
整理ツールとしては確かに有能なんだけど。。。
エディタ機能がこう、フラッシュ上に書き込んでいるような使い心地です。
びみょーすぎる。
何で先輩のみたいにサクサク動かないんだろう。
と思っていたら、どうやら元々Windows版は微妙という評判はあった模様。
http://masashi.biz/blog/archives/001193.html
http://www.mobile-bozu.com/mt/mt-search.cgi?tag=Evernote&IncludeBlogs=1
ホントこのもっさり感をどうにかしてー。
今度、メインパソコンをDebianに替える予定なのですが、
そっちではちゃんと動くのかなぁ？
…というかそもそもEvernoteにLinux版ってあるのかしら？？
shelveを使ってみる
shelveパッケージにより、Pythonオブジェクトをファイルで保存できる。
予想以上に簡単だった。
>>> import shelve
>>>
>>> sh = shelve.open("filename")
>>> sh['tree'] = bktree
>>> sh.close()
これでファイルがきちんと残る。
取り出すときも、同様にファイルをオープンして
ハッシュキーを引くだけ。
ただ、後から幾つかの欠点に気付く。
1. 複数のプロセスから同時読み出しは出来ない
2. LinuxとWindows間で同じファイルが使えない
まあ見るからに機種依存しそうな感じはしてたけど。
やっぱりきちんと作ろうと思ったら、DBの方が安全ねー。
2009年3月5日木曜日
統計について(訂正)
以前に書いた統計についてのグダグダ（2009年2月28日 統計について）ですが、
やっぱり間違ってましたねー。
検定手法、全っ然違いました。
私がやらなきゃいけないのは
「互いに従属な集団特性値の差の検定」です。
（参考：アンケート調査の方法 朝倉書店）
5段階でとった後、1、2(望ましい回答の組)と4、5(望ましくない回答の組)の
二通りに分けて、それぞれの個数をカウント。
それぞれ、全回答数に対する比率を出します。
その後、計算公式にあてはめて帰無仮説を検定。（式については上記文献を参照）
帰無仮説：「望ましい回答の比率と望ましくない回答の比率に差が見られない」
こいつが棄却できればOK。
という話だったようです。
やっぱ統計ややこしー。。。
やっぱり間違ってましたねー。
検定手法、全っ然違いました。
私がやらなきゃいけないのは
「互いに従属な集団特性値の差の検定」です。
（参考：アンケート調査の方法 朝倉書店）
5段階でとった後、1、2(望ましい回答の組)と4、5(望ましくない回答の組)の
二通りに分けて、それぞれの個数をカウント。
それぞれ、全回答数に対する比率を出します。
その後、計算公式にあてはめて帰無仮説を検定。（式については上記文献を参照）
帰無仮説：「望ましい回答の比率と望ましくない回答の比率に差が見られない」
こいつが棄却できればOK。
という話だったようです。
やっぱ統計ややこしー。。。
iPod touchの誘惑
友達がiPod touchを買いました。
休日中に購入したらしいのですが、
Myパソコンを研究室に忘れて帰ってしまったらしく、
今日大学に来るまで最初の画面から一歩も進めなかったそうです。
何て焦らしプレイだ＜笑
しかし、パソコンがないと動かないのね、iPod touchって。
ネットから直接ダウンロードできるとかいう触れ込みだったので
Wi-Fiさえ繋がる環境なら、別にパソコンいらんのかと思ってました。
危ない危ない。
さて、私はiPod touch派ではなく、iPhoneが欲しいのですが、
何せキャリアはずっとドコモを使ってるんですよね。
家族割とかもあるので、できればドコモから発売して欲しかったのですが。。。
もう通話機能は諦めて、iPod touchにしようかな。
やっぱり身近な人がもってるいるのを見ると、俄然欲しくなります。
さらにはこんなサービスを発見。
http://itpro.nikkeibp.co.jp/article/NEWS/20090304/325933/
日本語版が出たらもう即決しよう。
休日中に購入したらしいのですが、
Myパソコンを研究室に忘れて帰ってしまったらしく、
今日大学に来るまで最初の画面から一歩も進めなかったそうです。
何て焦らしプレイだ＜笑
しかし、パソコンがないと動かないのね、iPod touchって。
ネットから直接ダウンロードできるとかいう触れ込みだったので
Wi-Fiさえ繋がる環境なら、別にパソコンいらんのかと思ってました。
危ない危ない。
さて、私はiPod touch派ではなく、iPhoneが欲しいのですが、
何せキャリアはずっとドコモを使ってるんですよね。
家族割とかもあるので、できればドコモから発売して欲しかったのですが。。。
もう通話機能は諦めて、iPod touchにしようかな。
やっぱり身近な人がもってるいるのを見ると、俄然欲しくなります。
さらにはこんなサービスを発見。
http://itpro.nikkeibp.co.jp/article/NEWS/20090304/325933/
日本語版が出たらもう即決しよう。
2009年3月4日水曜日
Evernoteを使ってみる
「Evernoteの本旨は外部に脳を持つこと」と壮語するメモツール。
先輩が使ってて前々から憧れていたけど、
今回、とりあえず一ヶ月お試しで使ってみることにする。
Evernote ダウンロードサイト
http://evernote.com/about/download/
日本語化の手順
http://fkimura.net/application/1-evernote-japanese.html
Mac＆Windowsに対応。
Firefoxにアドオンが入って、Web上でデータがシンクロする。
しかも、画像中の文字も検索できるとか！
ただ、日本語化パッチの出来を見ると、
ちょっとあやしい感じもするな。。。
とりあえず、まずはこれで研究を進めるぞー！
先輩が使ってて前々から憧れていたけど、
今回、とりあえず一ヶ月お試しで使ってみることにする。
Evernote ダウンロードサイト
http://evernote.com/about/download/
日本語化の手順
http://fkimura.net/application/1-evernote-japanese.html
Mac＆Windowsに対応。
Firefoxにアドオンが入って、Web上でデータがシンクロする。
しかも、画像中の文字も検索できるとか！
ただ、日本語化パッチの出来を見ると、
ちょっとあやしい感じもするな。。。
とりあえず、まずはこれで研究を進めるぞー！
2009年2月28日土曜日
統計について
勉強したい今日この頃。
とりあえず、今やってる研究の関係で、
5段階でとったアンケートの検証方法について知りたい。
例えば、2つシステムがあって、両者の比較をするなら
同じ質問項目(i.e. 使いやすかったですかー？とか)に
それぞれ答えてもらって、その結果を符号検定すれば済むんだけど。
問題は質問が1回しかない場合なんだよね。
そもそもそういう風に実験をセッティングする事自体に
問題があるのかもしれないけど。。。
とりあえず、今はアンケートの5段階それぞれに1,2,3,4,5と点数をつけて、
本来の平均は3になりますが、
有意水準1％で左片側検定をした結果では…
とか言ってる。
サンプル数は100を超えてるから、
サンプル自体が大標本としては使えるんだけど。。。
果たしてこれは正しいんだろうか？？
とりあえず、今やってる研究の関係で、
5段階でとったアンケートの検証方法について知りたい。
例えば、2つシステムがあって、両者の比較をするなら
同じ質問項目(i.e. 使いやすかったですかー？とか)に
それぞれ答えてもらって、その結果を符号検定すれば済むんだけど。
問題は質問が1回しかない場合なんだよね。
そもそもそういう風に実験をセッティングする事自体に
問題があるのかもしれないけど。。。
とりあえず、今はアンケートの5段階それぞれに1,2,3,4,5と点数をつけて、
本来の平均は3になりますが、
有意水準1％で左片側検定をした結果では…
とか言ってる。
サンプル数は100を超えてるから、
サンプル自体が大標本としては使えるんだけど。。。
果たしてこれは正しいんだろうか？？
[Python] 条件付評価式
Python2.5から使用可能な条件付評価式 (Conditional Expressions) 。
とってきたBK Treeのプログラム中にあった。
つまりは一行で書けるif-else構文のこと。(代入限定)
>>> a = 1
>>> a = 2 if a == 1 else 3
>>> a
2
普通の表記だと、以下のようになる。
>>> a = 1
>>> if a == 1:
... a = 2
... else:
... a = 3
>>> a
2
Python2.5をいれているので実行は普通に出来るんだけど
Eclipseの自動構文チェックではエラー扱いになってる。
何でだろう？
Pydevが古いのかな。
そういや、アップデートをエラーのまま放置してる。。。
とってきたBK Treeのプログラム中にあった。
つまりは一行で書けるif-else構文のこと。(代入限定)
>>> a = 1
>>> a = 2 if a == 1 else 3
>>> a
2
普通の表記だと、以下のようになる。
>>> a = 1
>>> if a == 1:
... a = 2
... else:
... a = 3
>>> a
2
Python2.5をいれているので実行は普通に出来るんだけど
Eclipseの自動構文チェックではエラー扱いになってる。
何でだろう？
Pydevが古いのかな。
そういや、アップデートをエラーのまま放置してる。。。
2009年2月27日金曜日
[Python] 標準出力の文字化け対策 in Windows
今まで無視していた標準出力の文字化けを直す。
Windowsの標準出力で文字化けが起こる場合、
基本的にはShift_JIS(cp932)にエンコードすればOK。
ちなみにうちの開発環境はeclipse。
keyword = "図書館戦争"
print keyword.encode('cp932')
[出力]
図書館戦争
無事出力☆
でも、sitecustomize.py、defaultencoding、Eclipseワークスペース、
ソースファイル全てのエンコードにutf-8を設定しているのに
何でこんなことになるんだろう？？
答えはWindowsのMS-DOSで解決。
Windowsの標準コードはShift_JISなので、
標準出力についてはそっちに依存してたんだと納得。
C\:> chcp
現在のコード ページ: 932
実際、pythonの標準入力・出力系の文字コードを確認してみると、
cp932であることが確認できた。
>>> sys.stdin.encoding
'cp932'
>>> sys.stdout.encoding
'cp932'
>>> sys.stderr.encoding
'cp932'
内部でどうなっているかは分からないけど、
今後入出力はcp932で行なう事を意識する。
2009年2月26日木曜日
[Python] threadingモジュールを使ってみる
Pythonでスレッドを使う方法は
threadはスレッドの終わりを検知する機能が無い。
＝メインメソッドの実行が終わると、実行途中でも中断されてしまう。
（これを無理やり同期取ろうとするとwhile文でチェックし続けるとか
アホなコードになってしまいました。）
threadingではスレッドの実行終了のタイミングまで、実行を一時停止する機能がある。
[使用例]
import threading
import time
class testTreading(threading.Thread):
def run(self):
for i in range(1, 5):
print i
time.sleep(2)
r = registerRelationShip()
r.start()
r.join(1000) #スレッドの終了までの待ち時間
print "end"
[出力]
1
2
3
4
end
実行したい内容はrun()メソッドに書いて、
それをstart()メソッドで実行させる。
join()メソッドでスレッドの終了を待つので、
endが出力されるのは一番最後。
こっちの方が使い勝手良さそうかな。
- threadをimportしてthread.start_new_thread(func, args)にスレッドとして動かした関数を指定。
- スレッド化したいクラスで、threading.Treadを継承する
threadはスレッドの終わりを検知する機能が無い。
＝メインメソッドの実行が終わると、実行途中でも中断されてしまう。
（これを無理やり同期取ろうとするとwhile文でチェックし続けるとか
アホなコードになってしまいました。）
threadingではスレッドの実行終了のタイミングまで、実行を一時停止する機能がある。
[使用例]
import threading
import time
class testTreading(threading.Thread):
def run(self):
for i in range(1, 5):
print i
time.sleep(2)
r = registerRelationShip()
r.start()
r.join(1000) #スレッドの終了までの待ち時間
print "end"
[出力]
1
2
3
4
end
実行したい内容はrun()メソッドに書いて、
それをstart()メソッドで実行させる。
join()メソッドでスレッドの終了を待つので、
endが出力されるのは一番最後。
こっちの方が使い勝手良さそうかな。
[Python] __slots__の用法
メモリ節約＆実行速度向上のため、__slots__を使ってみる。
__slots__
[コード例]
class test(object):
__slots__ = ['foo', 'bar']
def printFoo():
print self.foo
def setFoo(_foo):
self.foo = _foo
t = test()
t.setFoo(20)
t.printFoo()
t.bar = 30
print t.bar
[出力]
20
30
__slots__
- クラスのアトリビュートの一種
- __slots__にString型で変数名を代入すると、それ以外のインスタンス変数が使えなくなる
[コード例]
class test(object):
__slots__ = ['foo', 'bar']
def printFoo():
print self.foo
def setFoo(_foo):
self.foo = _foo
t = test()
t.setFoo(20)
t.printFoo()
t.bar = 30
print t.bar
[出力]
20
30
- クラス内にメソッドも追加できる
- 書きこみも勿論可☆
登録:
投稿 (Atom)
投稿
