画像認識もくるとこきたな、という感じ。日本の鍵も油断ならない。
そろそろシリンダー錠の時代が終わると思ったら、カードキーを非接触で読み取り、なんてことにならないかな。ならないよな。
久しぶりに「スパゲッティの木」を見て笑った。
日本発だと 旧石器捏造事件 なんてのがあったなあ。
ニセ科学は違う意味でちょっと前に問題になっていたが、研究者としてどうかと思うくらい悪質な捏造になれば、悪い意味で歴史に残る。嫌だ嫌だ。
身近な話題で驚いた。聞こえが悪いからと言って、すぐに店を畳んで倒産ですというわけではなく、これから復活に向けて頑張るらしい。
ツクモRobot王国とか、楽しいんだけどな。
これからHD/DVDが主流となる、VHS終焉の区切りとなった。
2002年4月頃に買ったビデオデッキ(三菱製)が一応まだテレビの下に置いてあるのだけれど、テープが無いから全然使っていないという状態。『カウボーイビバップ』のエピソードにあった様に、レア物ファンに好まれる品になるのかな。
結構遅いと思ったが、まだ25歳なので何とも言えない。
しかし、10秒間で指先を叩き続けるという動作は疲れそうだ。
まだまだ脳を使いこなせると思うと、前途洋々。プラシーボではないが、やる気が湧いて性能も上がるというものだ。
何となくこういう数列があるというのは知っていたが、名前を知らず(覚えず)、初めてちゃんと学んだ。
定義としては、定規として測れない数値があっても良いが、存在するマークが全て必要で、任意のマークx、y、x'、y'(x > y、x' > y'、x != x'、y != y')について x - y != x' - y' である必要がある。
色々な分野で使えるそうで。
偽薬もまた薬なり。偽善もまた善なり。
嘘で崩れる信頼関係で嘘を手段として選択するのは間違いだと思うが、医師が心理効果を期待するところを見ると、やはり思い込みというのは馬鹿に出来ないものがあるんだろうなと思った。
統計ソフトではないという事だな。会計ソフトとしても使い難いし、やっぱり、表組みソフトなんだろうなあ。
グラフはpylab/matplotlibで描けるし、家計簿はOpenOffice.org Calcを使っているけれど精々集計だけだし、統計を真面目に使う機会は最近無いなあ。騙されない様に、ということは心掛けているけれど。
クリエイティブ・コモンズ提唱者であるローレンス・レッシグ教授の話。
アマチュアを阻害して、未来のプロが生まれるのだろうか。盲目的に権利を振りかざす者に従い、当初の崇高な目的さえ見失い兼ねない姿勢で存在するサービスに、これから何を変えられるというんだ。
どうやら、大人というのはどこまでも汚い様だ。
その時大学が動いた。
これまで1度も就職活動をしたことがない僕から見ると、学部3、4年とか、修士1年終わり頃の人達とか、本当に齷齪していて、傍目から見ると大変に見えて、いやはや、ああいう事は出来るだけしたくないと思っていた。
まあしかし、それが終わった人達はそれなりに研究していたし、どっちが先になるかの問題じゃないかなあ。
各神経細胞をガラスで絶縁して、接着剤で配置し、パターンを彫って細胞で回路を作った、らしい。
細胞から作るより、今の技術の方がコストが小さいと思う。
この技術が進歩して、細胞で集積回路が設計出来るということか。次に、脳に作用出来るマイクロマシンだ。
電脳化万歳。
ボトムアップ型とトップダウン型、それぞれの戦術について解説。
「ユーザの元へ適切な情報が伝わり易くなる」というのは、情報の範囲をどこまでに定めているのだろう。勿論、「全て」の情報にメタデータ(あるいはそれに通じる様なマシンリーダブルなデータ)が付与されていれば、良い環境になるだろうが、現状の様な、大してメタデータが使われず、従って積極的にメタデータが生まれない環境だと、適切な情報も穴だらけになりそうな気がする。
「分かり易さ」よりも「簡易さ」「便利さ」を伝えないと。2chの皆さんに「誰得」と聞かれて答えられるような流れを作るのが、これからの課題だろう。
真実が変わろうとも、事実が正しければ良い。
まあ結局のところ、烏合の衆が書き連ねたWebページの価値など、利用者の取捨選択の結論に委ねざるを得ないということだろう。
おー。テープを剥がす瞬間の摩擦のときのエネルギィが、X線領域に入っているということらしい。真空中に限る。摩擦ルミネセンス。
X線自体は珍しいものではないが、随分簡単に出せたなあという感じ。調査をした研究者の発想が良い。
外部のサービスに依存していて、サービスの仕様変更で気に入らないことがあると、泣き寝入りか、時間を掛けて移動するか、という選択肢になる。さてどちらが良いかは、場合によるのだけれど、そういう転ばぬ先の杖を考え出すと、結局データを置くのはローカルが一番で、配信だけを外部に任せたいとも思える。
Yahoo! Japanのプロフィールページは、旧プロフィール情報も残してあるのだけれど、仕様変更でプロフィール名が1つに制限されていたり(サービスで使い分けられない)、不満が少しある。
音声データを解析して、不適切な箇所を改変する技術。何とも面白みの無い。
最近、MSが色々特許を取っているらしい。
外部の環境で脳の働きが異なり、無意識にも差が出るということか。
因みに僕は、夢に現実の人が出てくることは少なく、大抵カラーアニメ調。後、ラストは僕が落ちるか、痛い思いをすることが多い。起きても大体覚えているが、得るものは少ない。
履歴なんて取られてナンボだとは思っていたが、ここまで見窄らしい方法で搾取していたとは。
始めることに対して倫理云々というより、利用者に伝えているかどうかだろう。
ストリーミングは対象外。ダウンロードのターゲットは委員会の性質上、違法録画・録音物辺りにある模様。
遂に来たか、という感じ。逃げ道も作らず、抜け穴だらけのものをこしらえて、矛盾にも程があるというか。頭ごなしに中身零な、見せしめ逮捕が出来れば、ほら見たことかで万々歳なのだろう。君子危うきに近寄らずがベター。
中身も知らず、根源を知らず、文化を見下しているとしか思えない。
津田氏が、2chのVIP板でスレ立てて、Q&Aっぽいことして、転載ブログで内容を配信させている。
1つのニューロンからの電気信号を与えられて、麻痺した手首の筋肉を操作する猿。
細胞細胞で制御が解析、応用されていけば、本当に脳の限界を使い切れる超人が生まれそうだ。
専らパソコンはキーボードメインで使っていて、マウスはほとんど使っていないのだけれど、さてこういうカメラインタフェースが実用的になったらどうなるかな。
キーボードのカタカタ、マウスのカチカチ、こういう、道具からの固い返答を手に受けるっていうのに結構安心しているのだけれど、これが無くなるとなると、使い始め暫くは不安というか、ふわふわした感じだろうなあ。
簡単なものを求めないから(まあ間違ってはいない)、日本の一般的な投票にこういうシステムが実用化されるのは相当先の話になると思う。といっても、最近の選挙を全く知らないから的外れかもしれないが。
データの改竄とか、課題を挙げればキリが無い。やってみるか、という気は無いのか。
明確な敵が定義されている環境というのは、進化を辿り易いということ。AI技術が発展しているなら良い事だ。
ところで、 いたちごっこ という表現は、当事者以外使うべきじゃないだろう。
Ubuntuのお陰で一般化してきたLinuxデスクトップで使う、デスクトップアプリケーション集。
scribus はOpenOffice.orgと連携して使っている。ポスタ作成に良い。
成功のための方法。戦略を立て、コミュニケーション能力を最大限に使う。
僕は今居る環境になって(大学院博士1年目)、漸くコミュニケーションの大切さが分かってきた気がするが、頭のどっかで分裂して反発してる。
名付けて「それでも無線LANにWEPを使いますか?」キャンペーン。
既存の複数の暗号推測アルゴリズムを組み合わせ、IPパケットからWEPキィを解読する。安価に構築出来る環境でこれが出来る、というのが怖い。
Debian化していない玄箱HGはnfs/samba(先日3.0.32にバージョンアップ)によるファイルサーバとなっていて音楽ファイルや論文等雑多ファイルが格納されている。玄箱PRO(Debian化済み)はnfsを用いてHGを参照している。因みにUbuntuを入れたノートパソコンはcifsでHGとPROを参照出来る。
音楽サーバにするのは、(今のところ)音声出力ハードウェアを搭載していない玄箱PROである。
素直にするならドキュメントが豊富な(先人の知恵が詰まった)方法である、 Icecast を使う。手持ちの音楽ファイルはほぼ全てmp3なので、Icecastに音声データを送るのにはIces0を使う。クライアントの選択肢は多い。
しかし、Icesはプレイリストを読み込めばただ再生をするだけなので、一時停止だとかスキップだとか、再生制御が出来ない。外部からサーバの再生制御が出来て、かつ、Icecastに音声出力を渡せる再生ソフトがサーバ側に欲しい。
MOC - music on console | console audio player for Linux/UNIX ( Music on Console - Wikipedia ) は、クライアント/サーバモデルの音楽再生制御ソフトウェアなのだが、リモート制御は出来ない(クライアント/サーバは同一マシンに配置する、SSHで繋げば出来るけど)、Icecastに音楽を渡せない、という特徴に利点と欠点を等しく併せ持った何だかよくわからないソフトウェアだった。
色々調査したところ、 MPD: Music Player Daemon ( Music Player Daemon - Wikipedia ) が目標とする環境構築に最も適している選択肢の様だ。リモートで再生を制御出来、音声出力をIcecastに渡せる。
配信ソフトウェアとして、Icecastではなく、長年の相棒ソフトと化した PeerCast ( PeerCast - Wikipedia ) を使うことも考えたが、個人範囲で音楽を扱いたいので、想定規模が違うということでリジェクト。
まだ試していない。玄箱の貧弱リソースでもそれなりに動くという報告がWebに幾つかあるので、多分大丈夫だろう。カーネルのアップデートに成功してからだ。
海野螢『マは小悪魔のマ』読了。
海野螢の誕生日である9月29日に発売された2冊の単行本その1。
不破太一の前に突然現れた悪魔のメフィスト。ただし、彼女は俗に知られる悪魔と違い、良い事しかしない。望みは、太一の夢を叶えることだと言う。太一の片思い相手の日暮まりか、魔女の先生を巻き込んで、SFチックに事は進む。
波動関数だとか因果律とか、SFな使い方をされ易い単語が出てくるが、まああんまり関係無い。よくある、セカイが絡んだボーイミーツガール。
太一の流され易い性格と、色々関係してHシーンが毎話あり。勿論全員貧乳。
メフィストのコスプレ癖が良い!
今の段階で、僕がTwitxrにポストしたメッセージ数は1216、もう少し前から使っているTwitterのメッセージ数は4194、となっている。Twitxrは未確認だが、Twitterは1ページ20個メッセージ表示で http://twitter.com/laclefyoshi?page=41 より古いメッセージを参照することが出来ない。Twitterが提供している検索サービスを使っても出ないし、どうやら古いメッセージはデータベースから削除しているか、どこかに隔離する仕様の様だ。
この手のサービスはマイクロブログ(micro-blogging)と言うのだから、メッセージはサービス上にあるが自分のログであるわけで、消されるのは面白くない。自分でバックアップを取って自分で再利用出来るようにしておくべきだろう。
Pythonで、TwitxrのAPIメソッドの1つであるgetUserTimelineを叩いて最新20個のメッセージ(XML)を取り出し、 lxml で解析、 sqlite3(pysqlite2) でデータベースに保存する。画像はバックアップしていない。
SQLiteのデータベースに保存するのは、XMLのまま保存するとかCSVに変換することも考えたが、ある程度サイズが大きくなることを考慮したため。
#!/usr/bin/python
import urllib
import lxml.etree
import sys
if sys.version_info[:2] >= (2, 5):
import sqlite3
else:
from pysqlite2 import dbapi2 as sqlite3
DB_FILE = 'twitxr_backup.db'
def init_db(con):
con.execute("""CREATE TABLE twitxr(
id INTEGER PRIMARY KEY,
url TEXT,
timestamp INTEGER,
text TEXT,
lat TEXT,
lon TEXT,
place TEXT)
""")
print("create db '%s'" % DB_FILE)
def update_db_fromxml(con):
url = 'http://twitxr.com/api/rest/getUserTimeline?user=laclefyoshi'
res = urllib.urlopen(url)
t = lxml.etree.fromstring(res.read())
for udelm in t.xpath('//update'):
id = udelm.xpath('./@id')[0]
cur = con.execute('SELECT * FROM twitxr WHERE id == %s' % id)
if cur.fetchone() == None:
url = udelm.xpath('./url')[0].text
timestamp = udelm.xpath('./timestamp')[0].text
text = udelm.xpath('./text')[0].text
lat = udelm.xpath('./location/lat')[0].text
lon = udelm.xpath('./location/lng')[0].text
place = udelm.xpath('./location/place')[0].text
con.execute("INSERT INTO twitxr VALUES(?, ?, ?, ?, ?, ?, ?)",
(int(id), url, int(timestamp), text, lat, lon, place))
con.commit()
print("insert %s: %s" % (id, text))
else:
continue
cur.close()
def main():
con = sqlite3.connect(DB_FILE)
try:
init_db(con)
except sqlite3.OperationalError:
print("db '%s' is existed" % DB_FILE)
update_db_fromxml(con)
con.close()
main()
最新20個以前のメッセージは、HTMLを辿って、lxml.htmlで解析して取り出した。
これをcrontabで15分程度毎(メッセージのポスト数が20を越えないであろう時間間隔)に実行すれば、メッセージのバックアップが取れる。
ここまでするなら、Djangoでも使って自分専用マイクロブログサービスを作った方が安心で有意義なんじゃないかと、一瞬思った。
最近HaskellのParsecで遊んでいて、Pythonの方のパーサライブラリが気になったのでGoogleで検索したら、ビンゴなページがあった。2004年9月に作成して、2008年7月に更新している。偉い。
Pythonで書かれているもの、多言語インタフェースを持っているもの、古いもの当たらしいもの列挙状態で、選択は利用者に委ねられている。
安かろう悪かろう。
軍事関連ということで、力の加減云々が関わって、世界情勢に影響を与える事情なので、適切な判断をしてほしい。
ブログ、人肉捜索、海賊版コンテンツ、メッセンジャ、オンラインショッピング。
人の多さ故に、一度注目されれば相当数の利用者数が確保出来るので、サービスは案外展開し易い。例えば、中学校や高校で友人間で伝わっていたツールやサービスがいつの間にか、学校に居る学生全員、終いに近所の学校、国中の学校に居る学生のスタンダードツールになっていたりすることもあらるらしい。
だが、お世辞にも情報リテラシィが日本に比べて高いとは言えないので、情報社会として発展するにあたり、少々難しい面もある。
こっちが、しっかり教えてやらないと。
携帯電話のGPS機能による位置取得は、 この記事 を参考に。
次に、GPSから取得した緯度/経度から住所文字列を取得するために、 Yahoo!デベロッパーネットワーク - Yahoo!地図 - ローカルサーチAPI を用いる。この様なWebサービスは、Reverse Geocodingと呼ばれるらしく、他にも似たサービスを提供しているところがある。
以下は、Pythonによる操作例(xml.dom.minidomを使わずにlxmlを使えば良かった。まあ、標準ライブラリで動作しているというメリットがあるが)。
import urllib
import xml.dom.minidom
def yahoo_localsearch(lat, lon):
url = 'http://map.yahooapis.jp/LocalSearchService/V1/LocalSearch'
opt = urllib.urlencode({
'appid': YAHOOAPPID,
'lat': lat,
'lon': lon,
'dist': 3,
'category': 'address',
'n': 1,
'datum': 'wgs',
'al': 3,
})
res = urllib.urlopen(url, opt)
res_doc = xml.dom.minidom.parseString(res.read())
res_address = res_doc.getElementsByTagName('Item').item(0).getElementsByTagName('Address').item(0).firstChild.data
return res_address
def main():
lat = "35.44.10.14261"
lon = "139.44.48.14127"
address_str= yahoo_localsearch(lat, lon)
print address_str
$ python yahoo_localsearch.py 東京都豊島区駒込2丁目
Twitxrはポストメッセージに緯度/経度を加えると、Google Mapsの地図位置にマッピングして表示してくれるが、流石に住所までは出ない。Twitterは勿論、位置情報は扱わない。後々ログとして役立つかもしれないので、住所文字列をメッセージの中に残しておくことにした。
学級崩壊したクラスの児童にも付けてみたいもんだ。
群れのリーダはどうやって選別するんだろう。
センサ系でほぼ必ず問題になるのは、電力供給の問題で、そのために消費電力削減とかの方法が研究されている。けれど、小さければそれなりに時間はもつ一方、機能が制限されたりしてどっちもどっち。動物に取り付けることで、動物の動きによる自己発電が出来れば、何とかならないかなあ。
問題は、「ネットワーク上のノードの認証ができないシステムであ」ったこと。
既に実装はあるので、認知と浸透が課題かな。
ソーシャルハッキングの様な方法に対する解決策、というのは難しい。人が完全であることは不可能だし、ものを管理をするのはこれからも人の役割だろう。
文庫カバーの様な革/布で出来たノートカバーは幾つもあったが、これはポケットやしっかりとした作りに惹かれた。
ただ、ペーパレス運動進行中で、大学の事務作業等以外には紙やペンを使用しないことにしているので、どうしようかなあ、というところ。紙にものを書くとしたら、文字よりも絵だろうなあ。
単位にし易そうな名前の人はぜひ。但し二番煎じだけど。
Google電卓で単位換算出切ることもだが、オモシロ単位を作った人が標準化団体に属していることに一番笑った。適材適所。
東京新幹線車両センター内自動進路制御装置のHDDで読み取りエラー。バックアップシステムに切り替えせず。
設計ミス。テストが足りない。
第1回重要科学技術史資料(未来技術遺産)の登録は、23件。
現存最古、世界初、日本初等の先進度の他に、貢献度やインパクト度も考慮されている様だ。
データの共有と蓄積のみならず、解析を提供している辺りがSemantic Webアプリケーションらしさ。
結局、semanticっていうのはこうやって床下配線の如く縁の下の力持ちとして働くべきなんだろう。それに拘っていては上にのるものがいつまでも出来ないし、疎かにしては上のものが崩れる。
人間にフレンドリィでない書き難さが付きまとうので、後々の扱い易さはあっても、Web 2.0の様にユーザ側が初期段階から積極的な姿勢にならないという。
TOM-Skypeは検閲可能の改造が施されていて、検閲データサーバに脆弱性があって、クラックされていたとか。
そこまでしないと国を安定に出来ないと思えるほど大きい、と思っているのだろうか。完全な上から目線が気に入らない。
ポーカーだそうで。
統計の勝利。時々グラフを用いるプレゼンテーションに対する問題点が指摘されるが、やはりグラフ(図)はインパクトが強い。
趣味程度のカジノにイカサマ持ち込んで大損なんて、やってられんだろう。目先に飛び付くもんじゃない。
竹箒『空の境界 未来福音』読了。
小説版『空の境界』(及び進行中の映画版)の合間に挿入されるエピソード。小説と漫画からなる。
未来視を持つ瀬尾静音と倉密メルカ。互いに接点は無く、その異能は予測と測定に分かれる。そしてもう1人の未来視、「御布子の母」という占い師の存在。
式☆最強。死の概念の広い適用っぷりに笑いさえ出た。文章袈裟斬りは良いなあ。
幸せな温かく明るい未来を見て、心地良い。
同人誌のため、ISBN無し。
サーバと言うよりコンセントレータだとか。
久しぶりにジャンクネタを見た。昔は、中古のHDDにデータが入っていたりとか、この手のネタはいつもあった気がする。
使うための設定の手間は惜しまないが、捨てるための設定も横着しないように心掛けよう。
店内でも携帯電話カメラを自由に使えるような空気が必要。
QRコードが使われている場面もプルな気がするが、その辺は言い様で何とかなるもんだ。
