2010-11-13 Sat

2010-11-13:青空だけど黄砂がまってるのかスッキリしない青色だし昼も肌寒い

昨日、空気が悪いなぁと思っていたのは黄砂の影響みたい。


11:00

起床。

11:30

朝食という名の昼食。
はは。

12:30

美容室の予約と歯医者の予約をした。

12:40

しかし、直後に予約した歯医者の評判がとんでもなく悪かったので、あわてて違う歯医者を予約した。
予約を取ったときに、2時間後に診療してもらえる空き状況と、ものすごくお金のことを言われたのが強烈に気になった、のであった。

代わりに長期にわたって評判が良さそうな歯医者は、反対に予約がとりにくく、平日の夕方になってしまった。
まぁ、仕方がないだろう。
最悪の場合、どちらも同じ程度の史上最低のヤブ医者である可能性がある。
しかしその場合、多くの人が行っている病院の方が最悪の病院である可能性が低い気がする。
その日は早めに作業に着手するぞ。

17:30

恵比寿から湘南新宿ラインで下る。

18:30

東戸塚で髪をカット。

19:40

ご飯食べる。
はればれ、でうどん。

21:00

恵比寿のTSUTAYAでCDを物色。
在庫は少ないけれど、渋谷のTSUTAYAで借りられっぱなしな感じなCDが残っている。
聞いたことがないアーティストをまとめ聞き。

22:00

とある2組のアーティストのCDを年代別に聞いた。

片方は20年前からほぼ全く同じなスタイルを貫いている。
片方は10年かけて少しずつ自分独特のスタイルを見つけている。

前者はスタイルの元になるバックグラウンドをもっており、その後徹底的に基礎を身につけた。
後者は前半その時代ごとにスタイルを換えている。
正直なところ、明らかに模倣しているアーティストが分かってしまう。
しかし後半は、気に入ったスタイルを数年かけて消化し、最初は密な音で構築していた世界を、疎な音で構築するように少しずつ変化している。
スタイルから本質を取り出して、自分の好みや経験と混ぜ合わせると独自のスタイルがでるようだ。
独自のスタイルが売れるか、っていうのは、また難しい話だけど。

24:00

ようやく借りたいCDを4枚見つけた。
それにしても借りたい物が無いのはツライなぁ。

24:30

渋谷のやよい軒で、しょうが焼き定食を食べた。

25:30

帰宅。

30:00

寝る。ぐったり。

投稿者:としのり  日時:23:59:59 | コメント | トラックバック |

2010-11-12 Fri

2010-11-12:今日は青空なのだが空気があまり綺麗じゃないようだ


9:15

起床。
頭痛がおさまっていない。
そして鼻水がとまらない。

10:00

作業場に到着。
昨日の作業の続きに着手。

それにしても出来上がった部分に関しては
処理がとても速くて嬉しい。

10:30

謎のアンケートの解答締め切り。僕はかなり前に答えた。

このアンケートに解答する人の大半が持つべき物を持っていないのではと思う。
アンケートの結果を元に効率よく改善できると思うのはどうかと思う。
日常的に利用することで発生する記録を元に改善した方が効果的だろうに。

- ふと思いついた駄目なアンケートの答え方
-- 持ってない!と開き直る
-- 質問文を読まないで解答を書く
-- 便乗して持論をだらだらと書く
-- 中身のない肯定的な意見を書く

11:00

朝食。
食欲が出ないが、おにぎりを1つ頑張って食べた。

イチローカレーの話題を見かけた。
自分がカレーを食べることを想像し、それだけでお腹いっぱいになった。

11:45

ちょっと爪が伸びてる。
切りたいな。夜切ろう。

12:00

REGZAのポータブルズーム機能を見せつけられた。
これはすばらしい。

12:45

2つのドメインを契約更新。
次に契約が必要になるのは[2014-01-01]ごろ。

13:00

昼食。
@tmaesaka さんとすれ違う。
元気そうでなによりです。

フランス料理のランチ。
あさりとエビのドリアうまい。

13:30

「ごきげんよう」、のサイコロトークはすごい。
お昼時にネガティブな話題が出ないようにコントロールできる。
今後「ごきげんよう」を見る機会があったら、そういうとこに注目してみよう。

14:30

午後の作業開始。

15:00

椅子の高さがあっていない。
バッチリ体のハマる椅子がほしい。
足の疲れや、腰や背中に疲労がたまると、集中力が切れる。

15:15

作ってた機能ができた。
あとは、いくつか調整したら次の機能の作成。

気のせいか頭の重さが半分くらいになってる。
ご飯食べたから?
油断すると悪化するので調子に乗らないようにしよう。

15:50

@machy さんに次の方針の相談。
使い慣れた道具は探すことから始まり、新しい道具は諦めることから始める。
はやく諦めて腕立て伏せを始めるのが早道。

16:00

仲間がG級クエストに旅立って行く。
彼らはそのクエストを完了することができるのだろうか。
僕は見事に飛び去られたなぁ。

16:50

G級クエストの結果

- 1人目:深追いせず
- 2人目:ブラックジョークで締め
- 3人目:材料を剥ぎとった
- 4人目:緊急クエストが発生した

討伐できなかったか。残念。

17:00

体調が微妙に悪くなってきた。
良くなったとか、やはり気のせいか。

17:30

思いのほか、今やってることをやろうとしているコードが見つからない。
こういう問題に困っている人の数が限られているということなのかな。
とりあえず週明けにGoogle Codeをあさってみる。

18:30

周囲の希望をとりまとめる雑用をした。
家と作業場の間を持ち歩くのは自分のノートPCだけにしたいですね。

19:00

ちょっと休憩。
オレンジジュースを飲みつつ
立ち回り方を教えてもらう。
ノンビリやるのがコツなのかもしれない。

21:00

「この商品はものすごく不便そうなのに、なんで棚から消えないんだろう」みたいに感じる商品は、棚から消えないなりの理由をもっている。

21:30

眼精疲労の原因は何となく心当たりがある。
数日前に流行った、視力が向上する眼球運動だな。
1日遅れで目の筋肉痛になったんじゃないかなぁ。

22:00

ドラマ「SPEC」をみた。
なんか分かんないけど映画化しそうだね。
堤幸彦さんの作品だったねぇ。

23:15

CDをスキャンし終わったのでTSUTAYAに行ってこよう。
8枚借りてるから、もしも返さなかったら1日で2000円も取られる。。

23:30

爪を切った。外出。

23:45

今日の渋谷はいつもよりも悪ノリしている人が多かった。

24:30

帰宅。寝る。

投稿者:としのり  日時:23:59:59 | コメント | トラックバック |

2010-11-11 Thu

2010-11-11:かなり青空だが昨日よりは少し寒い


9:15

起床。
今日はこの3ヶ月の平日でもっともよく寝られた。
風邪をひいたという口実ができたからだろうか。
喉の痛みは昨日より少ない。鼻水は昨日よりひどい。

10:00

作業場に到着。
朝からありえないことが続いている。

11:00

ようやく一段落。
朝食。
今日は暖かい食事を食べたかったのでスープを飲む。

11:30

昨日の続きに着手。
2つの道具の扱い方の違いに戸惑う。

12:00

周囲の人がゴホゴホと咳をしている。
フロアを見回すと1分間の間に咳やクシャミが聞こえないことがない。
密閉度がとても高く、「外気がうまい」と感じるくらい息苦しい(酸素濃度とか関係あるのかな?)作業環境なので誰かが病気にかかると広がるのは速い。
集団感染の予感。
今がインフルエンザの季節じゃなくて助かった。

12:15

急遽召還された。
作業が中断。悲しい。

12:30

まだまだ電子的なやりとりが嫌いな人って多いんだなぁ。

12:45

より優先度の高いことを終わっていないのに、
新しいことに着手することはできないよなぁ、
という言い訳を見つけて自分を納得させられそうなので、
より優先度の高いことを確実にやることにした。
苦渋の決断というのはこういうことを指すのだなぁ。

13:00

お昼。

15:00

とある相談を受けた。
なぜ僕なのか分からなかったけど、分かる範囲で真剣に対処した。
世の中には考えても解決しないこともあるものだ。

17:00

いよいよ風邪の頭痛がきた。これは酷い。
今日もはやく寝たいな。
作業には着手している。
積み木を積み上げるとこまでは、あと少し。

17:45

水を買ってきた。
控えめに見積もっても400円くらいすると思う。
もったいない。

19:30

もうこんな時間だし帰宅。

20:00

あきらかに食欲が落ちている。
あっという間にお腹いっぱいになってしまった。

21:00

体調がしんどい。
風邪と、眼精疲労からくる頭痛で起きてられない。
しかしフォント選びをすることにしていたので選ぶ。

22:00

だがブラタモリは見た。

24:00

使う画像の修正とかをしてた。
とにかく目に負担がくるとつらい。
とりあえず、今日やると決めたことは終わらせた。

24:30

風呂入った。寝る。

投稿者:としのり  日時:23:59:59 | コメント | トラックバック |

2010-11-10 Wed

2010-11-10:多少曇があるが青空で日中あたたかい

9:15

起床。
やる気が溢れ出てこない。

10:00

作業開始。
来年や再来年度のことを考えなきゃいけない。

12:30

お昼ご飯へ旅立ちたい。

14:00

午後の作業開始。

15:00

「マタイ効果」という名前のメカニズムが社会学の分野で指摘されていることを知った。
恥ずかしながら初耳だった。

「おおよそ、持っている人は与えられて、いよいよ豊かになるが、持っていない人は、持っているものまでも取り上げられるであろう」(マタイ福音書第13章12節)

そのとおりになってるね。

16:00

同じことでも書き方はいろいろ。
身につけたいスタイルを定めたので、まずはモノマネから。

16:30

どうやら風邪をひいた。
鼻とノドにきている。
ノドが軽く痛いし、鼻水もズルズル。
帰宅したら七度煎を飲んで寝る。

17:30

@machy さんに相談。
バイト単位の処理から行単位の処理に切り替え。
それにしても全然分からん。どうなってんのか。

18:00

@uchumik さんの発表、かなりうまくいったみたいだ。
おつかれさまでした。
世界の技術的進歩のために、ちゃんと論文書いてください。

18:30

こんなことにいったい何時間使っているんだ。
もっと力を付ける必要があるぞ。

と思ったが、使い慣れた武器を使えばあっという間なのだ。
しかし、武器を変えないと強大なモンスターを倒せない日がくるし。

19:00

ちょっと休憩。
オレンジジュースうまい。

20:15

帰宅する。

21:00

ごはん。

22:00

黄金の豚、というドラマの第4話を見た。
毎度毎度決まったオチなのだが、それがいい。
あと、もたいまさこの演技も好き。

25:30

ねる。

投稿者:としのり  日時:23:59:59 | コメント | トラックバック |

2010-11-04 Thu

「入門 自然言語処理」をいただきました

オライリーさんから「入門 自然言語処理」をご献本いただきました。
どうもありがとうございます!!

P1160135

本書は「Natural Language Processing with Python」という本の翻訳です。
原著には「入門」という語は入っていないのでオライリーさんの思慮が込められていそうです。
基本はNLTKというPythonのライブラリを使って自然言語処理の入門的な課題をこなしていく形式です。

入門 自然言語処理

[Amazonで詳細を見る]


実は、この本の12章を僕と、@echizen_tmさん、@uchumikさん、@nokunoさん、@tsubosakaさんと、@machyさんの6人でチェックに参加させて頂きました。(もちろん他にも査読者はいます。)
著者で機会をくださった@mizuno_takaakiさんと@mhagiwaraさん、どうもありがとうございました。

発行スケジュールの関係で締め切り寸前だったため、10月上旬の数日間にみんなで大急ぎで簡単にチェックしました。
僕たちが12章の原稿を受け取った段階で、12章はほとんど出来上がっていました。
なのでおもに誤植チェックをさせていただきました。まだ残ってるかなぁ。。。

本書の価値を原著よりも高めているのは12章。
この章は日本語版のオリジナルの章。
元バイドゥ社員でいまは楽天技術研究所(NY)に所属している@mhagiwaraさんがメインで書いた章だそうです。
12章だけでこんなに分厚いです。

P1160136

11章までの英語だけを扱う場合と比べると、日本語を扱う12章では考慮すべき点が多いです。
12章は日本語自然言語処理にありがちな課題を解決する「方法の一例」を示しています。
問題解決の方法は沢山あるので、Python的に本書での解決方法がベストなのかは分かりません。
ですが、いままで何もやったことが無い人にとって大きな助けになると思います。

さて、この12章の目次を引用してみます。

- O'Reilly Japan - 入門 自然言語処理
-- http://www.oreilly.co.jp/books/9784873114705/

12章	Pythonによる日本語自然言語処理
Pythonにおける日本語の取り扱い
    12.1 日本語コーパスの取り扱い
        12.1.1 平文コーパス
        12.1.2 タグ付きコーパス
        12.1.3 依存構造解析済みコーパス
        12.1.4 コーパスを用いたテキスト処理
        12.1.5 日本語WordNet
        12.1.6 その他の日本語コーパス
    12.2 日本語形態素解析
        12.2.1 形態素解析アルゴリズム
        12.2.2 文字単位分かち書きを使う
        12.2.3 MeCabを使う
        12.2.4 JUMANを使う
        12.2.5 そのほかのトピック
    12.3 日本語構文解析
        12.3.1 句構造解析
        12.3.2 文節チャンキング
        12.3.3 CaboChaを使う
        12.3.4 KNPを使う
        12.3.5 係り受け解析
    12.4 日本語意味解析
        12.4.1 格フレームとその獲得
        12.4.2 日本語LFG
        12.4.3 日本語句構造文法(ICOT JPSG)
        12.4.4 その他の日本語HPSG
        12.4.5 述語項構造解析
        12.4.6 照応解析
    12.5 さらに学ぶために
        12.5.1 ウェブサイト
        12.5.2 一般的な教科書
        12.5.3 形態素解析
        12.5.4 仮名漢字変換
        12.5.5 構文解析と意味解析
        12.5.6 機械翻訳
        12.5.7 情報検索
    12.6 演習問題


日本語処理を真っ正面から行なおうとしている様子が伺えます。
すばらしいですね。

本書は、機械学習の入門ではなく、自然言語処理の入門書として見た場合に、
入門書として十分な内容を含んでいると思います。
# 機械学習関連のトピックは割と省略されている場合があります。

これから自然言語処理をはじめたい人が手に取って大丈夫な本だと思います。
# もちろん、この本を読んだあと別の本も読むことすることが前提だと思います。

ああ、あと本書はPython の勉強に調度良いのかもしれません。
# Perlユーザ向けに、NLTKのPerl版とかも公開されたらNLP with Perlとか出てくるのかな?

入門 自然言語処理

[Amazonで詳細を見る]


ともかく、もうそろそろ書店に並ぶということですので、
みなさまお買い求めいただき、そして是非、自然言語処理に入門してみてください。

関連記事


- [O] YAPC::Asia Tokyo 2010 2日目で発表してきました
-- http://diary.overlasting.net/2010-10-16-1.html
# 「Perlで自然言語処理」という発表をしました。入門書の紹介をしています。

関連リンク


- O'Reilly Japan - 入門 自然言語処理
-- http://www.oreilly.co.jp/books/9784873114705/

- 手軽に自然言語処理を学ぶには「入門 自然言語処理」の第12章がお勧め - 生駒日記
-- http://d.hatena.ne.jp/mamoruk/20101027/p1

- オライリーの入門自然言語処理をご献本いただきました! - nokunoの日記
-- http://d.hatena.ne.jp/nokuno/20101104/1288883355

投稿者:としのり  日時:23:59:59 | コメント | トラックバック |

2010-11-02 Tue

目を閉じ耳をふさぎ口をつぐむ、だけでは足りない

『世の中に不満があるなら自分を変えろ。それが嫌なら耳と目を閉じ、口をつぐんで孤独に暮らせ。それが嫌なら、、』

という台詞が攻殻機動隊のアニメで出てきてたけれど、集団の中で孤独に作業をするときには、

- パーティションで視界を限定し、
- ノイズキャンセル機能付きヘッドホンで音を消し
- メッセンジャーやメールのアラートを切って作業の中断回数を減らす

だけでは足りないのではないか。

何が足りないかと言うと「鼻をつまむ」ことだ。

作業環境に流れてくる自分の匂い以外の鼻で受ける刺激は、
意外なまでに集中力を切らせる原因になる。

例えば、喫煙所に行って帰ってきた人が、僕の真後ろでため息をつくと、僕の鼻はタバコの煙の匂いを感じてしまうし、ペプシコーラのマロン味の匂いがすれば何事かと思ってしまうわけだ。

ということで、「マスクなどをして匂いを遮断する」、というのも孤独に作業するうえで大切なのではないか。

投稿者:としのり  日時:09:38:15 | コメント | トラックバック |

2010-11-02 Tue

パッケージメンテナの憂鬱

パッケージ管理ツールでインストールできると、アプリケーションやライブラリの利用者は便利。
アプリやライブラリの開発者もパッケージ化すると利用者が増えて嬉しい。
、、、と昔は思っていた。

現実には一旦パッケージメンテナになると、メンテナになった人は何かとパッケージの更新作業で時間を取られるようになる。

複数のプラットホームで動くようにコードを書くのは開発者の担当領域だと僕は思う。
他方、開発者がメンテナになると、やりたいことはコードを書くことなのに、パッケージ化のための作業で忙殺される。
もちろんパッケージング作業は勉強になるので、開発者ならしばらくやった方が良いと僕は思う。
だけど、一生メンテナやって欲しいが大丈夫か、と言われたら、一番良いメンテナをくれ、と答えたい。

メインの開発者とパッケージメンテナはなるべく分けた方が良い。
そして責任感の強い人にメンテナを担当してもらえると最高。

無責任なメンテナとコンビを組むと「メインの開発者の環境じゃないとビルドできないんです」とか訳の分からない理由でパッケージング作業を開発者に押しつけたりする。これでは、何のためのメンテナなのか分からない。
メイン開発者が降りたら、他の開発者によって開発が続いていてもパッケージの更新が止まるやん。。

世の中のパッケージメンテナのみなさまに改めて深い感謝の気持ちが生まれた。ありがたやありがたや。

投稿者:としのり  日時:09:00:44 | コメント | トラックバック |

2010-11-02 Tue

「苛立つリマインダー」というアイディアはどうか

ふと思いついたけど
「送られてくるとイライラするようなリマインダーが、もうそろそろ来るから、そのリマインダーが来る前にやることをやろう!」
と思うようなリマインダーって需要があるのでは。

人間は快感をともなわない苦痛が嫌いなので、一回苛立った後は「苛立ちたくない」という理由でリマインダーが来る前にやることをやるようになります。(実体験)

投稿者:としのり  日時:07:55:51 | コメント | トラックバック |

2010-11-02 Tue

ネタが無くても何か書くのが大切かも

@tsubosaka さんから
「ランチで何を食べたかを書くだけの簡単なお仕事すらできないんですか?」
と言われる夢を見たので、今日くらいはランチで何を食べたのかを書きたいと思います。

なんで、ここしばらくブログ書かないのかというと、ネタが無いからです。
書けないけど飲み会なら言えるような話は豊富にですけど。

とはいえ、ネタが無いからブログを書かないよりは、
ブログを書いて、それからネタがあるように生きた方が良いはずですね。
いつも忘れがちです。

ネタがない日は

- 「ネタがない」
- 「今日もネタが無い」
- 「昨日に引き続きネタがない」
- 「もう4日連続ネタがない」
- 「いいネタがない日は店を開けない。これで5日目だが」
- 「こんな日もあるんですね。ネタ切れ6日目ですよ」
- 「もう7日もネタ切れじゃないか。だがそれでいい」

などと更新していけば良いのではないかな。

投稿者:としのり  日時:07:53:34 | コメント | トラックバック |

2010-11-02 Tue

自分は自分のために、みんなは各自のために

僕は、もう少し自分自身のことに集中した方が良い、と今朝起きて(AM1:30だが)改めて思った。

04:50


あんまり寝られないので、そのまま作業場へ移動。途中で朝食。

05:30


早朝は月初めの事務作業を消化。

07:30


メールを数通書いてから、すこし休んで、パッケージのメンテナンス作業。

12:00


どうでも良いことだがTwitterは恐ろしいツールだ。

例えば「毎日野球関連のサイトしか見ていないように同僚から見られている人」が
「明日は試合観戦なので、今日の仕事は頑張れる」とTweetしてるのを
会社の同僚から目撃されたとする。
すると、同僚は「その人の仕事は野球関連のサイトを閲覧することなのか!!すごい!!」と感じる。

むむむ。僕自身の日々の生活を改善しよう。

12:30


午前から取り組んでるメンテナンス作業はあんまり捗らず、午後もメンテナンス作業することが確定。
それにしても10時以降の作業場では、予想以上に作業が進捗しない。

14:00


午後の作業開始。
ブログを書いている方が頭の中が整頓されて作業が進む。
いろいろ浮かぶくだらないことを吐き出す場所があると楽。

15:30


いろいろ手法を検討した結果、メンテナンスコストを押さえる方法を見つける必要がでてきた。
しかし、その方法は個人で決定できないので、タイミングを計ることになった。よって作業を一時中断。
こんな時もあるよ。

16:00


とあるアプリの設計をする時間がとれたので、@echizen_tmさんに相談しながら設計。
いろんな方法があるけど、どうせ最初は失敗するので駄目なら全部書き直すつもりでやることにする。
コレから先のマイルストーンを3つ作れたので、今後達成するのみ。

19:10


まとめられるくらいの量の思いつきなら記事にできる。
でも実際に目に映るものをそのまま書くことは憚られるので、
目の前で面白すぎることがあるときに限って書くことが無くなる。

19:20


20:00くらいまでお茶。
@echizen_tmさんにティガさんの倒し方を見せてもらう。
が、倒せなかった。また今度みせてください。

20:15


新宿へ。ご飯食べて帰宅

23:00


バタリ。

投稿者:としのり  日時:01:30:00 | コメント | トラックバック |

2010-09-24 Fri

日本のどこかの竹やぶには1億円が落ちているという幻想

昨日は昼頃に起床。
作業を祝日の月曜日にやったので代わりにお休みした。


ぶらりと外に出て、恵比寿のうどん屋でかけうどんを食べて新宿で用事をこなした。

その後、新宿の紀伊国屋で気になる本を物色した。
目的の月刊の本は既に売り切れ。
来月から定期購読した方が良いかな、と思い詰めたりした。

書店で技術書を眺めてると、やけにScalaの参考書が目立っていた。
今まで目に付いていなかったけど、情報科学若手の会に参加して水島さんの話を聞いたからかも。
既に5冊もScalaの参考書ってでていたことに驚き。
周囲でScalaを使っている人がそんなにいなかったけど、これからScalaユーザが増えるのかな?

Scalaスケーラブルプログラミング(Programming in Scala)

[Amazonで詳細を見る]

Scalaプログラミング入門

[Amazonで詳細を見る]


新宿駅方面に向かって、タワーレコードで気になってたCDを物色したりした。
気になってたのは「凛として時雨」の新しいアルバム「still a Sigure virgin?」。

still a Sigure virgin?

[Amazonで詳細を見る]


これは傑作。個人的には8曲目と9曲目が好き。

夕方


夕方は渋谷でお茶を飲んでいら、隣のテーブルで男性二人が大声で興味深い話をしていた。
要約すると「すべての問題は、他人によって既に利用可能な状態になっている既存のアイディアで解決できる」という話だった。

僕は、すべての問題を既に利用可能な状態になっている既存のアイディアで解決できる、という考えは幻想だと思う。
もちろん、解決できる場合もある。
しかし、解決でない場合もあるということだ。

また、すべての問題を誰か他人が完璧にスッキリ解決してくれる、ということは今までの人生でほとんどなかった。
たぶん、これからも何事に関してもそうだと確信している。

そもそも何かを実行するときに、既存のアイディアで解決できる場合とできない場合がある。
誰も体験した事がないような状況を解決するアイディアは世界中を探しても見つからないだろう。

また既存のアイディアが何か形になっている場合となっていない場合がある。
さらに形になっていないアイディアの実行を他人に任せて、うまく行く場合といかない場合がある。

状況を慎重に見分けたうえで、もしも「既に利用可能な状態になっている既存のアイディアで解決できない問題」に対処する場合には、
腰を据えて長期間まじめに自前で妥協しないで筋の良い新しいアイディアに基づいて対処した方が長期的には利益があると思う。

そして、アイディアを実行をする人は長期的な利益が出るように行動して当然だと思う。
短期的な利益を追い求めると、結局ボロが出てそのボロを修復する作業で忙殺されがちだ。


というようなことを考えてしまうイベントがあった後、ブックファーストとブックオフで本を物色した。
久々に本屋を回ってみて思ったことだけど、1日に1冊自分が気になるジャンルの本を読むのは悪くないかも。

今日は『「時短テク」より「時間戦略」で生産性を上げる! ハイペース仕事術』をサラリと読んだ。

「時短テク」より「時間戦略」で生産性を上げる! ハイペース仕事術

[Amazonで詳細を見る]


本書は、仕事と生活のバランスが崩れがちの僕にピッタリの本だったかも。

・1章の「時間をかけて結果を出す事で辻褄をあわせると一時的に効果はあるが、後でツケが回ってくる」という表現には同意。
・3章の「スピード重視」と「質重視」の使い分けの話は、普段から意識しているけれどさらに気をつけたい。本書には質をそこそこでもリリースしてしまうという言葉は実際に運用するときに、妥協の温床にもなるかもしれない。しかし早くリリースすることは心がけたい。バランス感覚が大切だなぁ。
・5章の「平日の夜は1つか2つのことを確実にやる」という表現は気持ちが楽になる。僕はやりたいことが沢山あるので、つねにやりたい事だらけで一晩に消化できることが少なすぎることに苦しむことが多い。1つか2つ確実に、という気持ちは是非持ちたいと思った。
・「本を雑誌のように、雑誌をチラシのように読む」は心がけたい。最近読書の量が減りすぎていて、精読し終わっている本が少ないことよりも、絶対的な量が足りない事が僕の内面的には問題になってきている。
・「娯楽をゼロにすると絶対に失敗する」は、心あたりがある。精神的に疲れてダラダラと頻繁に小休止するよりは、その時間分「ちゃんと遊んだ」と思える遊び方を選んで遊んだ方が、強い心を保てるかもしれない。


とてものんびりとした1日だった。

投稿者:としのり  日時:23:59:59 | コメント | トラックバック |

2010-09-23 Thu

気温が昨日より10度くらい下がったみたい

おとといから日記を眠くても書いているのだけど、眠いときに日記を書いていると日中なら書かない自重が足りない表現が含まれる場合があって、自分で書いてるのに翌朝ドキドキする。

今日は朝から横浜まで用事を消化するために外出。

それにしても今日は寒い。
その寒さのせいか、昼ご飯を食べたそば屋のおばちゃんが
「今年は秋が無くていきなり冬になるみたいよ」
という噂を別の従業員に吹聴してた。マジすか。

朝に渋谷駅で電車に乗ったときには、雨が降っていたけどTシャツでも寒くなかった。
だけど昼前に1つめの用事が終わって移動する際に外に出たときには寒過ぎて鳥肌もの。
しかも大雨と強風で寒さ倍増。
その場しのぎにユニクロで何か長袖のシャツを買おうかと思ったけど、
寒さと大雨で傘をさして移動することもままならないので、それも実現できず震えつつ移動。

全ての用事をおえて、帰宅して落ち着いた後、気象庁のWebサイトで関東地方の気温を確認して驚いた。
9月23日の0時の渋谷あたりの気温は16.7度程度。
9月22日の0時の気温が27度だったので、1日でだいたい10度位気温が下がってる!!

20100922_01

これは気温が下がるペースが早過ぎ。ちゃんと洋服を調整しないと間違いなく風邪をひきます。
今日寝るときは、長袖シャツ&長ジャージズボン着用、クーラー無しで寝よう。

なんでこんなに寒いのか、を調べてみると、気象庁が寒候期予報を発表したという記事を見つけた。

- 今冬、気温「平年並み」だが寒く感じる 気象庁予報:日本経済新聞

「冬支度は念入りに」。気象庁が22日発表した寒候期予報(10月~来年2月)によると、気温は10月まで全国的に高めだが、寒気の影響を受け、徐々に平年並みに落ち着く見込み。同庁は「ここ数年暖冬が続いたため、今年の冬は特に寒く感じそう」としている。


「平均並みの気温になったときに、今年の夏の平均気温が高めだった影響で、感覚的に例年より寒く感じる」ということらしい。
冬の寒さも厳しく感じるのか。うーん。つらいっすね。

関連リンク


- 気象庁 アメダス:関東地方
-- http://www.jma.go.jp/jp/amedas/206.html?elementCode=2

投稿者:としのり  日時:23:59:59 | コメント | トラックバック |

2010-09-22 Wed

モチベーションが一番大切

朝は友人からの深刻な人生相談をされる。あまり立ち入れないから分からないことも多いけど、なかなか深刻な状況っぽい。
結論としては、相手の能力・将来性の価値を信じてくれて自らの生活力に応じた相対的なコミットをしてくれる人を見つけるべき。と思った。

ランチ後は友人らと秋の作業予定を固めた。
みんな、各自やりたいことがあって良いと思います。
秋もなかなか厳しいことになりそうだけど、何かきちんと形に残したい。

夕方早くに作業を切り上げて外の空気を吸ったので、
体調も良くモチベーションも維持できていた。

調子が良いので、夕方から夜にかけて考えごとをした。

ふと頭に浮かんだことは、やりたい事がありすぎてストレスになっている気がする。ということ。
足りない能力、身につけるべき能力、やっておくべきことなど、
いろいろ思い浮かぶけど、限られた時間の中で全部やるのは無理。

何をやるのか、何を絶対にやらないのかを選ばないと。

たとえば、もっとも優先度の高そうな作業を列挙してみる。

- 英会話の経験値を稼ぐ
- 基礎的な知識の反復練習
- 2〜3個の実務で使ったことのないプログラミング言語を使う
- いま作っているものを形にする

この数ヶ月はこういうことを考える余裕すらなかった。(笑)。
たぶん、今年の年末までにコレらを全部満足できていれば、いちおう合格な気がする。
あと夏の間は読書が滞りまくったので、明日から作業をやりつつ消化していきたい。

そういえば先日、以下の本をAmazon.comで注文した。

Flexible Pattern Matching in Strings: Practical On-Line Search Algorithms for Texts and Biological Sequences

[Amazonで詳細を見る]

Statistical Machine Translation

[Amazonで詳細を見る]

Information Retrieval: Implementing and Evaluating Search Engines

[Amazonで詳細を見る]


Flexible Pattern Matching in Stringsは友人に借りて、すでに一部を読んでいる。
他の2冊はまだ読んだ事が無い。早く手元に届いて欲しいな。

Information Retrieval: Implementing and Evaluating Search Enginesは多数の友人が買っているので輪読するかも。

投稿者:としのり  日時:23:59:59 | コメント | トラックバック |

2010-09-21 Tue

夏の作業が区切れた

昨日で夏の作業が区切れたことになった。だけど後味が悪すぎる。

この夏は、いろいろやり直したいと思うような酷いシーズンだった。
僕が1年間取り組んできたことのうち、自分が一番思い入れがあったことは実を結ばないままだ。
しかも、また大人の事情ってやつで再来年までは高い確率で実を結ばないことも何となく分かった。
こういう「大人の事情を体験する」という目的も数年前にもっていたので、ともかく、それは多分達成できた。

一応区切れで、丁度良い機会なので、今日から昨日までの生き方と少し違う生き方をするようにする決意をした。

より自分や自分の家族を大切にし、より自分の友人に配慮しつつ、より真剣にまじめに集中して生きたい。
この1年間は色々あったけど、目指している能力の伸びを達成できなかった。足踏みしてしまった一年だった気がする。
僕より厳しい状況でも、能力を伸ばしている人は沢山いるように僕からは見える。
僕を取り巻く環境はすぐには変えられないので、僕自身の時間の使い方を変えることで解決する必要がある。

ときどき、僕の発言を参考になる、と冗談でも言ってくれる人がいる。
僕自身は自分の足りない部分を知っているので、なんとも申し訳ない思いがあるが、とても励みになる。ありがたい。
最近は、ありがたい、と同時に、何らかの責任の取り方がある気がしてきた。
その責任の取り方がどういうものなのかは、まだハッキリとは分からない。
だけど、今よりも強く確信をもった発言をしたり、フォローをしたりできるようになりたい。

ものを作る時に使う道具に変化を付けたいとも思っている。
普段使っているプログラミング言語、知識の幅からはみ出た道具のうち、自分の尊敬する友人が使っている道具を積極的に使いたい。
僕は何事も最初は形から入るタイプで、それでうまくいっているので多分間違ってないと思う。

自分の内面は、とげとげの剣山のような状態を少なくしたいし、流れる水のような柔軟さと強さを持ちたい。
水のように流れるためには、普段から自分を鍛えている必要があると思う。まだまだ僕は訓練が足りない。
周囲にいる柔軟性の高い友人を見ていて、そう思った。

僕はこれらのようなことを考える程度に落ち着いてられない状況に置かれているし、すごく焦っている。
秋は、落ち着かないのは諦めるとして、焦りが減るように動く。ぞ。

投稿者:としのり  日時:23:59:59 | コメント | トラックバック |

2010-07-22 Thu

朝の日比谷線が停電

朝、日比谷線に乗ったら車内の電気がバババッと消えました。
そのあと急激に車両の速度が減衰して停車。車内がザワザワ。

何事かと思いましたが、社内アナウンスで停電と分かりました。安心。

P1140917

5分くらい停車したあと動き出しました。

地下鉄が駅以外で止まると、災害のときに自分がどうなるか想像してしまいます。怖いなぁ。地下鉄。

停電の夜に

[Amazonで詳細を見る]


関連リンク


- 東京メトロ ホームページ
-- http://www.tokyometro.jp/index.html

投稿者:としのり  日時:23:59:59 | コメント | トラックバック |

2010-07-18 Sun

上達に向けた努力の成果は受け止め方を工夫するべき

最近は何故か、いろんな職業の人と話す機会に恵まれるようになりました。
そうすると言葉にならないけど感じることが多くなります。
今日は「上達に向けた努力」に関する考え方の工夫について、まとまったのでメモっておきます。

結論としては「上達に向けた努力の成果はアウトプットである。アウトプットされてれば質はともかく万事よし。」と考えよう、ということです。

アウトプットの質だけ見ると、解決方法がない辛さを感じるときがある


上達に向けた努力には様々な形があると思います。努力の成果を計る尺度の一つはアウトプットの量です。アウトプットの量が増えると、徐々にアウトプットの精度が上がり、独自性が増し、成果も沢山出て良いことだらけです。

上達に向けて努力しているときに、自分よりも上手な人のアウトプットを見て自分のアウトプットの貧弱さに打ちひしがれることが、個人的には多々あります。
打ちひしがれるのは楽ですし、いろいろ言い訳を考えて自分の貧弱さから目をそらすのも悪くはないのですが、数時間後に何も解決してないため、さらに愕然としたりします。

上達目的のアウトプットは質はさておき、量で評価しよう


最近、自分よりもある種のアウトプットが圧倒的に上手な人を沢山見て、他人のアウトプットを見てもショックを受けないことが大切ではないか、と思うようになりました。

ミスもOK。稚拙でもOK。好奇心を沢山もって、とにかくアウトプットする。そういう姿勢の人が個人的に素晴らしく見えます。

アウトプットの成果を自ら「アウトプットの質で評価する」とした場合、世の中には様々な上級者がいるので、いつどこから高品質なアウトプットをひっさげて目の前に現れるか分かりません。
自信をもって出力したものが一瞬で無価値になるようなことを繰り返すと、どんなに強靭な精神をもっていても折れてしまうものです。少なくとも僕は万策尽きた時点でボッキリと折れます。

他方、アウトプットの成果を自ら「アウトプットの量で評価する」とした場合、周りにどんな上級者がいようとも、それ自体はあまり関係ありません。
自分のアウトプットの質が自分で許せるラインに到達していなくても問題は起きていません。起きていないと考えます。
これでアウトプットする度に無力感に襲われる負の連鎖に落ちることもなく、明るく出力ができます。

上級者はアウトプットの量が多い


しかし、そのときに気がつくことは「上級者は圧倒的にアウトプットが多い」ということです。
アウトプットの量だけで見ても、上級者に勝てないことが多々あることに気がつきます。
上級者はアウトプットの精度が高いだけでなく、いつのまにかアウトプットの速度が速くなっており、同じ時間で大量にアウトプットできます。

しかし、そのようなアウトプットの量で負ける問題は努力で解決できます。出来ない場合もありますが、できる場合がかなり多いのでは。
小粒で良いからとにかくアウトプットし、寝る間を惜しんで出し続ければ、量で勝てる可能性はあります。
相手も人間なので風邪をひくこともあるし、用事もあるし、やる気が無い日もあるので、相手が完全に止まってる日ならちょっとやるだけでもアウトプットの量で負けません。

量での評価は自分との戦い


量で評価するようにすると、全ては自分の内側での自分との戦いになります。
子供のころにラジオ体操のスタンプを押してもらいましたが、あれも行くことに意義がありました。
上手にラジオ体操ができたか、とか、ちょっと遅刻したか、とか、そういうのは関係ありませんでした。
毎日一個ずつ「毎日えらいね」とスタンプを押してもらえました。
子供心にあのスタンプはとても達成感があったなと思い、何が良かったのか時々考えています。

では、どの程度アウトプットすることを自分に課すべきか、というと、たぶん自分が負けたくない人よりも多くアウトプットすれば良いのではないかと思います。
どういう人に負けたくないか、というと、職業でアウトプットしている人は素人には負けたくありませんね。
例えばレストランのシェフの1日に料理をつくる回数が専業主婦に毎日毎日負けていたら何か嫌です。
まぁ、そんなに急激に腕は衰えないと思いますが。

おわり


ということで、上達を円滑にするには「出力の量を増やし、出力の質には一旦目をつぶり量だけ見よう。量の目標はライバルを見つけてそれ以上に出力するようにしよう」と考えてはどうかな、と結論づけて、一旦終わります。眠い。

投稿者:としのり  日時:23:59:59 | コメント | トラックバック |

2010-07-18 Sun

ソースコードを private なレポジトリから github やレンタルサーバ上の git へ移動

とある事情から、ずっと手元のVM上のgitで一元管理してるソースコード管理を、状況に応じて別のレポジトリで管理するように切り替えることにしました。

僕以外の人には、ほとんど関係のない話です。

以前からコードを外部のリポジトリで管理しても、手元に全部のコードが残るので問題は無いし、そもそも僕の書くコードを流用する奇特な人はそんなにいないと思うので問題なさげ、と思っていました。
でも、手元のVMで管理が間に合ってるため外部公開とか面倒くさいし、CodeReposも最近は全然使ってないし、僕のコードは万人が頻繁に使う公共性の高いものではないのでユーザも居ないし、あんまり気持ちよく感じないなと思ってました。

今回の件は @mamoruk さんから、かなり背中を押されてやっとやり始めました。感謝。やりはじめると不思議と手が動きます。

状況に応じて管理方法を分けることにした


ソースコードは公開して平気なコードから、公開したら絶対駄目なコードまでいろいろあるので、自分でコントロールする必要があるコードはよりプライベートなgitレポジトリで管理することにした。

レポジトリ管理するコード
github公開して大丈夫で、とくにパッケージにもなってないコード
レンタルサーバ上のgit公に公開できないけど、知人に見せたいコード
手元のVM上のgit絶対公開できないコード
自分のサイトかGoogle Codeアプリケーションがまとまったらパケ化して上げておく

アプリケーションについてはアプリケーションごとにWIkiやトップページが欲しいので、自分のサイトで管理するかGoogle Codeで管理しようと思う。
多分、僕のサイト上に置いてあるよりもGoogle Code上にあった方が嬉しい人が多そう。

github の用意


実は github にアカウントを持ってなかったのでアカウント作りからやった。
自分のまとまってないコードを積極的に開示する状況に陥ることは予測してなかった。

20100718_1

アカウントを作ったあとは、以下のように作業をした。

- overlast's private - GitHub
-- http://github.com/overlast/private
Global setup:
 Download and install Git
  git config --global user.name "Your Name"
  git config --global user.email メールアドレス
  Add your public key
        
Next steps:
  mkdir private
  cd private
  git init
  touch README
  git add README
  git commit -m 'first commit'
  git remote add origin git@github.com:overlast/private.git
  git push origin master
      
Existing Git Repo?
  cd existing_git_repo
  git remote add origin git@github.com:overlast/private.git
  git push origin master


push するために追加する必要があるSSH の public キーは ssh-rsa だと怒られたけど、ssh-dss だと怒られなかった。

今後は dotfile など毒にも薬にもならないコードから順にアップしていく。

レンタルサーバ上に git をインストール


さくらのレンタルサーバにgitをインストールしてレポジトリを作った。
サーバの容量の上限が10GByteになったので、やろうと思えば、手元のコードは全部レンタルサーバでも管理できる。

さくらのレンタルサーバにgitをインストール

さくらのレンタルサーバに git の一番新しそうなのをインストール。
今日の段階では 1.7.1 っぽかったので、これをインストール。

実は自分の環境では、gmak中にエラーが起きた。

- @さくら
$ mkdir ~/src
$ cd src
$ wget http://kernel.org/pub/software/scm/git/git-1.7.1.tar.gz
$ tar xfvz ./git-1.7.1.tar.gz 
$ cd git-1.7.1
$ mkdir $HOME/local
$ ./configure --prefix=$HOME/local 
$ gmake 
(中略)
    SUBDIR perl
/usr/bin/perl Makefile.PL PREFIX='/home/overlast'
Only one of PREFIX or INSTALL_BASE can be given.  Not both.
gmake[1]: *** [perl.mak] エラー 255
gmake: *** [perl/perl.mak] エラー 2


たぶん、perlbrewを使っているからかな。
このエラーはINSTALL_BASEを指定して、perlbrewでprel5なモジュールが入るディレクトリを指定すれば解決できる。
あと、このperlモジュールをインストールするときに、manを/share以下にインストールしようとするので、それをローカルフォルダに入れてくれるようにSITEPREFIXも指定。

別途perlモジュールをコンパイルして、続きをgmake。

- @さくら
$ cd perl
$ perl ./Makefile.PL SITEPREFIX=$HOME/local INSTALL_BASE=${HOME}/perl5
$ gmake  SITEPREFIX=$HOME/local INSTALL_BASE=${HOME}/perl5
$ cd ../
$ gmake  SITEPREFIX=$HOME/local INSTALL_BASE=${HOME}/perl5
$ gmake  SITEPREFIX=$HOME/local INSTALL_BASE=${HOME}/perl5 install


.bashrcのPATHに「$HOME/local/bin」を追加して、source ~/.bashrc。

あとは、--bareをつけてinitする。付けないとpushできない。

- @さくら
$ cd $HOME
$ mkdir repos.git
$ cd repos.git
$ git init --bare
Initialized empty Git repository in /home/you/repos.git/


これでローカルからpushするリポジトリはできた。

bareなリポジトリはデータ格納場所なので開発はできない。
cloneして、そこで開発する。まっさらだったら手元のgitリポジトリをadd & pushする。

まずは、ローカルなPC上にディレクトリを作ってgit initしてcommitしてみる。

- @ローカル
$ mkdir repos
$ cd repos
$ echo "This is my git repository" >> README
$ git init
Initialized empty Git repository in /home/you/repos/.git/
$ git add README
$ git commit -m "first commit"
[master (you-commit) 8d0baee] first commit
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 README


今度は、これをレンタルサーバ上のリポジトリに突っ込んでみる。
SSHでpushするとレンタルサーバ上のgit-receive-packを見つけられないので、receive-packオプションでgit-receive-packの絶対パスを与える。

- @ローカル/repos
$ git remote add origin ssh://you@you.sakura.ne.jp/home/you/repos.git
$ git push --receive-pack=/home/you/local/bin/git-receive-pack origin master 
Public key aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa blacklisted (see ssh-vulnkey(1)); refusing to send it
you@you.sakura.ne.jp's password: 
Counting objects: 3, done.
Writing objects: 100% (3/3), 231 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://you@you.sakura.ne.jp/home/you/repos.git
 * [new branch]      master -> master


問題無いので、再度READMEを編集してadd、commitして、pushする。

- @ローカル/repos
$ echo "I'm very sleepy" >> README
$ git add README
$ git commit -m "second commit"
[master 8044db5] second commit
 1 files changed, 1 insertions(+), 0 deletions(-)
$ 再びpush
うまくいった


うまくいく。

つぎは今度は自分のPCの別のディレクトリでcloneする。
レンタルサーバの$HOME/local以下にgitをインストールしたので、SSHでアクセスするとパスが通っていないことになる。
なので、--upload-packオプションでgit-upload-packの絶対パスを与える。

cloneしたら3回目のコミットをclone先でやってpushもしてみる。

- @ローカル/repos
$ cd ../
$ mkdir repostest 
$ cd repostest
$ git clone ssh://you@you.sakura.ne.jp/home/you/repos.git repos --upload-pack /home/you/local/bin/git-upload-pack
Initialized empty Git repository in /home/you/repostest/repos/.git/
Public key aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa blacklisted (see ssh-vulnkey(1)); refusing to send it
you@you.sakura.ne.jp's password: 
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (2/2), done.
Receiving objects: 100% (6/6), done.
remote: Total 6 (delta 0), reused 0 (delta 0)
$ cd repos
$ ls
README
$ less README
This is my git repository
I'm very sleepy
$ echo "I'm hungry" >> README
$ less README
This is my git repository
I'm very sleepy
I'm hungry
$ git add README
$ git commit -m "third commit"
[master e4fb5a1] third commit
 1 files changed, 1 insertions(+), 0 deletions(-)
$ git push --receive-pack=/home/you/local/bin/git-receive-pack origin master 
うまくいった


うまくいった。
今度は、最初に作ったreposを更新する。

- @ローカル/repostest
$ cd ../../repos
$ git merge origin/master
Updating 68abac3..e4fb5a1
Fast-forward
 README |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
$ less ./README
This is my git repository
I'm very sleepy
I'm hungry


どうやら大丈夫。
clone、push、mergeが動いているので、多分なんとかなるはず。

ローカルで何かミスったら「git reset --hard ORIG_HEAD」すれば、直前のcommitに戻れる。

こっちでは活発な開発をおこなって、ある程度まとまったら知人にお試し公開する場所にする。

関連リンク


- GitHub
-- https://github.com/

投稿者:としのり  日時:23:59:59 | コメント | トラックバック |

2010-07-18 Sun

SUFARY の任意な index を 64bit OS 上で構築するとき

ハマったのでメモ。

結論:後でとくに問題が起きないなら sufary.h を編集して SA_INDEX 型を int 型にすれば良い。

SUFARY の mkary で作れない索引を作る方法


SUFARY 付属の mkary を使うと「ファイルの全ての文字の位置」か「行頭の位置」を索引付けするなら簡単に array ファイル(SUFARY の索引ファイル)を作れる。

他方、各行の一部について部分に含まれる各文字ごとに索引付けしたい(例、CSVファイルの第Nカラムだけ索引付け)場合には、任意の部分の文字位置のポインタをバイナリで吐き出して 、最後に「mkary -so」することが多い。(-so を使うとソートだけ)

そうすることで、欲しい部分については柔軟に検索でき、不要な部分が検索結果に含まれなり、必要最低限のサイズの array ファイルを作ることができる。タスクによってはこのような索引付け方法が必須な場合がある。

このとき、バイナリはビッグエンディアンで出力する必要がある。
出力するバイナリのビット長は SUFARY のヘッダファイルである sufary.h において typedef されている SA_INDEX の型に依存する。

SA_INDEX の型が long だとハマる


sufary.h の SA_INDEX の型が標準だと long 型。

long 型のサイズは OS ごとに異なるが、手元の環境では 32bit long 型は4byteで、64bit long 型は 8byte だった。
もしも long 型のサイズが8byteなときに、4byte 長のビッグエンディアンなバイナリを mkary に入力すると、ソートできなくてSegment Faultする。

そのため特殊な array ファイルを作る際にバイナリを吐き出すプログラムは、環境ごとに異なる long 型のサイズに対応する必要がある。

SUFARY を 64bit OS 上でインストールする際はヘッダファイルを編集


とはいえ、環境ごとにことなる動作をする index 作成スクリプトはちょっと面倒くさい。
またプログラミング言語によっては 8byte 長のビッグエンディアンであるバイナリを出力するのが面倒くさい場合がある。

そもそも SA_INDEX の型が long で定義されているからややこしいことになる。
SA_INDEX の型が int でも、SUFARY を後で問題がとくに考えられない使い方しかしない場合には問題ない。

32bit OS上ののSUFARYでは索引づけできなくて、64bit OS上のSUFARYでは索引付けできるデータを扱うときだけ問題が起きる。
しかし、そのようなサイズのデータはそもそも接尾辞配列でindexするべきでは無いか、接尾辞配列の分散indexをつくるかすれば良い。

ということで、SUFARYの圧縮ファイルの lib/sufary.hを以下のように変更してからインストールする。

- sufary.h
- typedef long SA_INDEX;
+ typedef int SA_INDEX;


これでバイナリを出力するプログラムは 4byte 長のビッグエンディアンなバイナリを出力するようにするだけで、だいたいの環境で「mkary -so」できるようになる。

@echizen_tm さんに相談したら彼が過去に体験済みな問題で解決方法を教わった。ありがとうございます。

関連リンク


- SUFARY 臨時復旧ページ
-- http://nais.to/~yto/tools/sufary/

投稿者:としのり  日時:23:59:59 | コメント | トラックバック |

2010-07-10 Sat

渋谷川で短冊流しをやっていた

テアトルエコー前の渋谷川のあたりを歩いていたら、上流から短冊が流れてきました。七夕の短冊ですね。

P1140797

現代でも短冊を都会の川に流す人はいるんだなー。驚いた。

驚きすぎて写真が撮れなかったので、早足でより下流側の駒沢通りまで歩いて再び渋谷川を覗き込みました。お、追いついた。

P1140801

あの短冊、なんて書いてあるのかな??

P1140802

うーん、読めませんね。残念。

本当は、短冊に水で自然分解されにくい紙を使っている場合には、短冊流しをしちゃいけないと思います。
分解されない場合は露骨に残るゴミになるから、河川の清掃員の仕事が増えて、税金が無駄遣いされることになります。

近年は短冊を流すのではなく、燃やして、思いを天に届けようとするのが主流みたいなので、来年は燃やしてみて下さい。

関連リンク


- 渋谷川 - Wikipedia
-- http://ja.wikipedia.org/wiki/%E6%B8%8B%E8%B0%B7%E5%B7%9D

投稿者:としのり  日時:23:59:59 | コメント | トラックバック |

2010-07-08 Thu

「言語処理のための機械学習入門」が出版された

高村大也さんによる自然言語処理・機械学習の新定番本「言語処理のための機械学習入門」が発売されました。

言語処理のための機械学習入門

[Amazonで詳細を見る]


Amazonや楽天でも在庫が次々に掃けているようで、今日のところは売り切れの書店が続出みたいです。
この種の参考書に飢えている人が少なからずいる、ということですね。

ネットでは確かに売っていたのですが、筆者の高村さん自身が「今月か来月に発売なんだけど、よく分かってない」ということ(そんなことがあるのww??)みたいなので、どんな感じかな、と、新宿の書店に行ってきました!

おおお、ありました!
ちゃんと入荷してます。神々しいです。

P1140790

私と @echizen_tm さんと @uchumik さんの 3 人で買いに行きましたが、ちゃんと一人一冊ゲットできました。
買う前にパラパラとめくって読みましたが安いですよね。この本。2940 円とかありえません。

この教科書を研究室の勉強会などで使う場合には「最初に6章を読んで、その後2章以降を読みつつ、分からなくなったら1章を参照する」みたいな読み方の人もいるかな。
1章は本書で使う数学の基礎知識について解説する章で、結構なページ数があるから、飛ばす人はバッサリ飛ばしそう。

特筆すべきこととしては「'言語処理のための機械学習入門」は章末問題も充実しており、おまけに、章末問題の解答もあるんです。
信じられますか? はい。
それにしても、この手の教科書にしては優しい対応ですね。
アルゴリズムデザインとか解答が無いから時々涙で前が見えません。

そういえば、「言語処理のための機械学習入門」を買いに行ったら「計算機シミュレーションのための確率分布乱数生成法」という大変興味深いタイトルの本が出版されていました。

P1140793
計算機シミュレーションのための確率分布乱数生成法

[Amazonで詳細を見る]


パラパラめくると非常に濃い内容で、式の展開が丁寧だし、疑似コードも充実。
濃すぎるので、どれだけ売れるのかちょっと分からない本ですが、立ち読みレベルの判断では良書。
この本も一家に一冊的な書の予感。買わなきゃ。

ああ、横道にそれました。

高村さん、出版おめでとうございます。よかったよかった。

書籍の情報


- コロナ社|書籍詳細|機械学習入門
-- http://www.coronasha.co.jp/np/detail.do?goods_id=2728
自然言語処理シリーズ 1
言語処理のための 機械学習入門	

東工大教授 工博 奥村学 監修
東工大准教授 博士(工学) 高村大也 著

判 型:A5
予定ページ:224頁
ISBN:978-4-339-02751-8
予定価格:2,800円

自然言語処理における機械学習の利用について理解するため,
その基礎的な考え方を伝えることを目的としている。
広大な同分野の中から厳選された必須知識が記述されており,
論文や解説書を手に取る前にぜひ目を通したい一冊である。


関連する記事


- 「言語処理のための機械学習入門」が近日発売

ネットで買う


言語処理のための機械学習入門

[Amazonで詳細を見る]

楽天で「言語処理のための機械学習入門」を調べる。
計算機シミュレーションのための確率分布乱数生成法

[Amazonで詳細を見る]


関連リンク


- Hiroya's homepage
-- http://www.lr.pi.titech.ac.jp/~takamura/index_j.html
- 奥村研究室ホームページ
-- http://www.lr.pi.titech.ac.jp/

投稿者:としのり  日時:23:59:59 | コメント | トラックバック |