プロフィール

suurizemi

Author:suurizemi
はじめまして。私の名前は松崎遥です。
2010年現在、東京大学大学院総合文化研究科の2年生です。
最近いろいろ総合しすぎてよく解っていません。
e-mailアドレスは、blckcloistergmilどっと混むです。出会い系サイトの攻撃によりコメント機能は使えませんので、こちらにご連絡下さい。

私の好きな言葉だけ・・・
「証明の海の中にこそ数学の生命が宿り、定理や予想は大海に浮かぶただの泡である(よみ人知らず)」
「曖昧な知識は何の役にもたちません。自戒を込めて(神保道夫)」
「連続関数以外では、微分積分法はむずかしい!(高木貞治)」
「10代で共産主義にかぶれない人間は情熱が足りない。20を過ぎて共産主義にかぶれる人間は知能が足りない。(よみ人知らず)」
「だから、あの人自身がアトラクターなんだよね(金子邦彦教授評。)」
「われわれは、ほとんど知識をもっていないことほど固く信じている。(モンテーニュ)」
「現代文明の根源であり象徴である近代科学は,知的に非凡とは言えない人間を温かく迎えいれ,その人間の仕事が成功することを可能にしている.
 その原因は,新しい科学の,また,科学に支配され代表される文明の,最大の長所であり,同時に最大の危険であるもの,つまり機械化である.物理学や生物学においてやらなくてはならないことの大部分は,誰にでも,あるいはほとんどの人にできる機械的な頭脳労働である.科学の無数の研究目的のためには,これを小さな分野に分けて,その一つに閉じこもり,他の分野のことは知らないでいてよかろう.方法の確実さと正確さのお陰で,このような知恵の一時的,実際的な解体が許される.これらの方法の一つを,一つの機械のように使って仕事をすればよいのであって,実り多い結果を得るためには.その方法の意味や原理についての厳密な観念をもつ必要など少しもない.このように,大部分の科学者は,蜜蜂が巣に閉じこもるように,焼き串をまわす犬のように,自分の実験室の小部屋に閉じこもって,科学全体の発達を推進しているのである.・・・(中略)・・・大部分の科学者は,自分の生とまともにぶつかるのがこわくて,科学に専念してきたのである.かれらは明晰な頭脳ではない.だから,周知のように,具体的な状況にたいして愚かなのである.(オルテガ)」
「幾何学(=数学)について腹蔵なく申せば、私は、これを頭脳の最高の訓練とは思いますが、同時にそれが本当に無益なものだということをよく存じていますので、、、(パスカル)」
「犬っころなら三日も四日も寝ていられようが・・・寝て暮らすにゃあ、人間てのは血が熱過ぎる・・・(村田京介)」
「小泉純一郎は朝食をたくさん食べる。ヒトラーも朝食をたくさん食べた。だから小泉はヒトラーと同じだ(朝日新聞)」
「畜生、今日もまた Perl でスクリプトを書いてしまった。ああもう、 Python がデフォルトでインストールされないシステムはゴミだよ。いや、それではゴミに対して失礼だ (リサイクル可能なものが多いからな) 。よし、こうしよう。 Python がデフォルトでインストールされないシステムは核廃棄物だ。いや、核廃棄物の中にも再利用できるものはあるな。なんて事だ、俺は本当に無価値なものを発見してしまった・・・(プログラマー)」
「ヨーロッパかアメリカの気候のよいところで、
のんびりぜいたくに遊んで一生を暮らすこともできるだろうに・・・それがお前たち下等なブルジョワの最高の幸福だ。」
「もし二人がいつも同じ意見なら、一人はいなくてもよい。(チャーチル)」
「悉く書を信ずれば、即ち書無きに如かず。(孟子)」
「一般的に、時間が経てば経つほど、バグを直すのにかかるコスト(時間とお金)は増える。
例えば、コンパイル時にタイプか文法エラーが出たら、それを直すのはごく当たり前のことだ。
バグを抱えていて、プログラムを動かそうとした最初のときに見つけたとする。君はわけなく直せるだろう。なぜなら、君の頭の中でそのコードはまだ新鮮だからだ。
2、3日前に書いたコードの中にバグを見つけたとする。それを追い詰めるのには少し時間を要するだろう。しかし、書いたコードを読み直せばすべてを思い出し、手ごろな時間で直せるだろう。
でも、2,3ヶ月前に書いたコードの中のバグについては、君はそのコードについて多くを忘れているだろう。そして、直すのはこれまでよりずっと大変だ。このケースでは、君は誰か他の人のコードを直していて、書いた本人は休暇でアルバ島(訳註:ベネズエラ北西カリブの島・リゾート地)に行っているかもしれない。この場合、バグを直すことは科学"science"のようなものだ。ゆっくり、順序立てて慎重にやらなければならないし、直す方法を見つけるのにどのくらいかかるのか、確かなところがわからない。
そして、すでに出荷されたコードのバグを見つけたら、それを直すには途方も無いコストを招くだろう。(Joel on Software)」
「男と女には春夏秋冬がある。
春にしっかり育てて、
夏に燃え上がり、
秋に”情”という実がなり
冬はそれを食べて生きていく。(柳沢きみお)」

最近の記事

最近のコメント

最近のトラックバック

月別アーカイブ

カテゴリー

ブロとも申請フォーム

この人とブロともになる

自主セミナー やって候
もはや自主セミナーの補助ページではなくなって久しいモノ。
スポンサーサイト
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

 
aozora.gr.jp 東大生ブログランキング
snow leopard
Snow Leopardを3,300円で生協で買って、macに適当に入れておいたら、iPhoneがmacで認識されない問題が解決された。これで普通に開発が再開出来る。丁度SDKは3.1.2になったところだ。

これは、単なる偶然というには利得が大きい。
iPhoneのリストア(結構危険)
iTunesのアンインストール
iTunesのいろいろな設定ファイルを漏れなく削除すること
iTunesのリインストール
それでも解決しないので再度原因を考える
という一連の作業にかかる10時間程度の時間を再度ロスすることを防いでくれたのだ。それだけで利得は15,000ぐらいあるんじゃないかなあと思う。

単なる偶然でないというのはどういうことかというと、AppleがiPhone問題に対応せず、製品交換ですませていたのは、長期的(半年単位)に考えればこの問題はSnow Leopardの導入に伴って解消されるとしっていたからではないだろうかということだ。つまり、バグの処理作業を一元化したのだ。知識の無いソフトバンクショップでテクニカルな問題に対処するのは、知識の伝達コスト(人件費)がかかりすぎるが、それを定量的に処理出来ているということである。もちろん、Appleの誰かがこのような絵を描いていたとしても組織としての実行は難しいから、このような事件を抽象的に効率的に処理する仕組みをAppleは(無自覚的に)育てていたのだろう。

まあ自分の参考になるのかはわからないのだが、Snow Leopardの新機能もうがった目で見てみたい。
 
aozora.gr.jp 東大生ブログランキング
スポンサーサイト
達人プログラマー/エディタの章
プログラムをはやく書くための勉強はこれで終わりだ。時間切れだから。結局、最後の関門は、エディタを使いこなせなければ突破出来そうにない。それは実地で鍛えればいい。

VS2005を使っているが、マクロが実行出来ないバグがあるっぽい(microsoftのサイトによれば。)のでこの機会にVS2008に切り替えようかと。しかし、それにはパソコンも買い替える必要があって、先輩の持っていたVaioTypeZがやたらかっこ良かったのでそれをちょっと考えています。Blu-rayも少し見たい(見る時間はないのに)。最近、時間が無いという意味の捉え方がわかって来たと言うかちょっと捉え方が変わってきました。いまの方がより真理に近いような気がします。その理解は、言葉で書けるものではなく何となく内臓のあたりに座ってるような感じです。でも、太って内蔵脂肪がついただけかもしれません。

とりあえずVSはEmacsバインディングに切り替えて、ウォッチ式はばんばん使って、出来る限り無駄な時間を短縮してロケットで突き抜けたいと思います。
 
aozora.gr.jp 東大生ブログランキング
実習
達人プログラマーのエディターの章を読んでから、VisualStudio上での指運びを工夫するようになった。
IDEがいまいちな時代の本なのでIDEが不当に貶められているが、確かにUnixのようにシャープで鋭いツールを使うことが出来ないのは物足りないところだ。それでも、このウォッチ式やデバッガ、インテリセンスからは離れられない。

遊びでHebb則をテストするプログラムを書いたら、3時間で使い物になった。
実際やってみると、ベイシンに偏りがかなりあることがわかったりしてもっと知りたくなる。

ただ、3時間を30分にすることは出来なくても、1時間にすることは出来そうだ。

また、結果のプロセッサ(ヒストグラム化など)をHaskellで書くと楽そうな予感がする。データは欲しい時に検索できなければ意味が無いが、MySQLは少し大掛かりで(演算機能を使わない場合)、またプレーンテキストに触れないのが欠点なような気がしてきたからだ(少し達人プログラマーの影響を受けてしまった)。
なので、下処理をするプログラムがあったほうがいい。

嫌いなsedも視野に入れたほうがいいかもしれない。

つづく。
 
aozora.gr.jp 東大生ブログランキング
マーチン リファクタリング3
第三章

P76コードの自己記述性、共有、選択という間接層によるメリット
????

P78巨大なクラスの解体-ローカル変数とスニペットをまとめてクラス化する、サブクラスの抽出をする
死と混沌よ・・・
P78グローバル変数にいたるワンクッションとしてのprotected member
今日のバイトでやった。login_timeだ。

jumpP260Example of NullCustomer?
斬新だった。ちょっとアスペクト志向っぽい。Customerの、nullでありうるというアスペクトだ。
デフォルト動作を埋めておくことの重要さを痛感できる。
また、isNullメソッドの代わりにinstanceofを使うというのもびびった。
正直こんな使い方があるとは思っても見なかった。javaはちゃんと継承を最低限にする工夫もユーザーによってされているんだのう。
しかも、このやり方ならば何種類もnullを作ることが出来るのだ。(Unknown, Undefined, Banned, etc)
return

P84temporal attributes
ヌルオブジェクトの応用(Null~=undefined)。素晴らしい。俺のような素人には神に見えてしまう。

P85メソッド名の変更によるシグニチャの統一
P86データクラスのカプセル化
データクラスは子供のようなものです。最初はプライベートな部分が無くてもよいのですが、
一人前のオブジェクトとして育っていくにつれて、責任を持つ必要が出てくるのです・・・
これは尤もな話で、パブリック属性がたくさんあると混沌としてクラスが読めない。
プライベート変数はまとめてコンテナに入れて、プライベートにすると読みやすい。
第四章

P90前のテストがうまく行っているので、バグは直前のテスト以降の作業で作りこまれたことがわかります。
JUnit固有の話
これはちょっときついかな。
個人的にjavaは最も研究で使いたくない言語かもしれない。
リファクタリングブラウザーならruby refactoring browserあるからそっちでいいや。
以後100+アルファページまでだるだる

こんなもんだろうか。一応僕が知りたかった知識やテクニックは得た。3日間ぐらいで読めるぐらいが実践チェックに適した量だとも思うので、この辺にして達人プログラマーに移ろうかな?


 
aozora.gr.jp 東大生ブログランキング
マーティン・ファウラーのリファクタリング2
第二章

リファクタリング中は新機能の追加をせず、新機能の追加中は既存のコードをいじる必要は無い
単純に、集中力が落ちるからだという気もする。
方向を決めたらリソースを集中しないと、最後のリソースで到達できるクオリティを得ることは出来ない。
例えば運よく普段のリソース100に対して今夜は120あるとすると、このときを置いて
クオリティ120のアルゴリズムに到達することは出来ない。
不可逆な部分を(突発事態の回避による平均化の影響を避けられるような、
すなわち低エントロピー状態(=レベルの低い開発者で書けるコードやアルゴリズム)
を避けること)を開発では優先しろということであろう。
自分しかかけないコードを持っている状態で、リファクタリングを追求する必要性は無いということかな。

テストの追加をしてはいけない理由は恐らく上記とは異なる。
テストの追加をすると、恐らくいままでの作業の信頼性は落ちる。
すると、余計な気を使わなければ成らず、結果的に集中力が散逸する。

設計の劣化という第二法則
全ての人間に不完全性が共有されていることから、設計の劣化=低エントロピー化は
第二法則のように確実だといえる。

臨界現象
全ての人間の短い記憶レンジは、まるで自己組織化臨界現象が起こることを保障しているかのようだ。
雪崩現象と、スパゲッティコードは似ているとみんな思っているはずだ。
なぜなら、短いスパゲッティコードなら読めるからだ(コンキリエみたいなモノだ)。

低エントロピーコードNOT EQUALS低容量コード
ここで低エントロピーコードと書いたのは、いわゆる「起こりそうに無いコード」のことだ。
それに対して低容量コードは、DRY原則に基づいたものを指し、
改善コストの少ないコードの事を指す。
以上は私の妄想であって本には書いていません。すみません。

P58機能追加できない時は機能追加しにくい設計である可能性がある。
P58バグの原因がわからないときは設計が悪い可能性がある。
両方悪魔の証明であると意識する必要がある。

P62ポリモーフィズムを使って条件分岐を柔軟かつ明確に表現できる。
ケースによって差が著しいswitch文は不恰好なのでその通りだ。

P63リファクタリングの欠点や限界については暗中模索である。
2000年発行か。ううむ。

P63スキーマの変更、DBの移行
オブジェクトモデルとデータベースモデルの変化を独立させる。
これはさっきのリソース集中の主張と似ている。し、
設計の良し悪しを論じた部分とも似ている。
さらに解像度を良くして、オブジェクトモデルで頻繁に変更される場所を、
残りから分離する必要がある。例えば、頻繁に変更される部分はアクセサーで対応すればよい。

P64リファクタリングによる恩恵の期待値はインターフェースの変更のリスクを上回るか
????

P67設計は簡素化するべきである
これによって設計変更に伴うコストを削減できる。ここは重大なメッセージに見える。
もうひとつ削減できるコストは、設計に固執する場合に柔軟性を失うかもしれないというリスクである。
つまり、設計が簡素であれば、設計を維持する場合に他にトレードオフを押し付ける場合でも、被害が少ない。

P70あるプロセスで集中的にリソースを消費している場合、的確な修正が可能である。
どうやってプロファイラを書けばいいんだ??XCodeは偉い。

P72キャッシングの重要性
キャッシングはどうやればいいかわから無いために僕のカーネル計算のプログラムの中で
ほっときっぱなしのところになっている。このせいで実行速度がとれないのはわかっているのに、
なぜかやる気にならないのは十分な経験が無いからだろうと思う。
僕は、小さい例で経験をつむことにした。
キャッシングの一種として、ファイルストリームを使ってもいいかもしれない。
スレッドを使ってもいいかもしれないが、スレッドについても小さい経験をつむ必要があるのだ。僕はまったくど素人だ。

 
aozora.gr.jp 東大生ブログランキング
マーティン・ファウラーのリファクタリング1
ついに待望のマーティンファウラーが手に入りました。自戒のためにレビューを投稿していこうと思います。ポリシーは、なるべく疑問点を持ち越さないよう、再考を加えながら書くことです。


第一章

p26までは納得できる。whileループの長さは、約60%も削減された。
p26で、whileループの数を3倍に増やしてまで、一次変数を排除している。
パフォーマンスが落ちているわけで無いというのは納得できる。
これを自分で思いつくかというとここは慣習に反するので難しそうだ。
しかし、一次変数を問い合わせメソッドに置き換えたことで、
問い合わせメソッドがpublicで利用できるという、
拡張性に対する計り知れないメリットを生み出したことになる。
ここに、僕のコードが機能追加しにくい理由を見出せるかもしれない。

また、この問い合わせメソッド化により、チューニングが容易になる。


p32htmlStatementメソッドの追加
whileループが4行しかなかったせいで、トータルで10行の書換ですんでいる。
スマートにhtmlは実装できないので、これが最小変更であることは明らかだ。
しかも、問い合わせメソッドさえ直せば、statementとhtmlStatementの両方を直せる。
早くもリファクタリングの効果が見えてきた!!

gang of four・・・ポリモーフィズムによる条件記述の置き換え
switch文が、仕様変更に対して妨げになるという話だとおもう。これは、今まさに僕のプログラムsolverが陥っている罠であり、迷路の構造が変わって上下左右に進めるようになったら、絶望的だ。javaはこういうところはidiomだが、c++ではどうしたらいいのだろうか・・・。delegateを使うという手もあるが、以前ビールゲームでやったときはコードが煩雑になっただけだったのだ(結局クラスを作っているわけだし)。また、delegateは継承で無いので、スーパークラスにデフォルト動作を保存する、ということは出来ない。

p50Stateパターンにはかなりの手間がかかりましたが、それだけの価値があるのでしょうか・・・
これは正直実感できない。
何のためにやっているのかも正直よくわからない。あやふやだ。。。

つづく
 
aozora.gr.jp 東大生ブログランキング
Code Complete p75
・グローバルコンテキストで変数参照の意味論を実装する

ここしばらく悩んでいたけれど、netbsd/stdlibのコードとrogueのコードを見て考えるに、やはり結論としては、日本語版初版の75頁(3.1.7)の記述は不合理。グローバル変数が、コード内で現れる場所によって与えられる意味がまったく変わると言う話なのだから、『fptrはsrrandom内では~、一方、rrandom内では~のように使われる』と訳さないと意味が通らない。

意味論とはsemanticsの事だと思うが、semanticsっていうのは『様々な場所で現れる同一のデジタルデータであるプログラムの命令文が、前後の流れに置かれたときにふと役割を持つかのように見える現象』を表しているのだと思う。つまり、単一のデジタルデータが複数の意味を含意するという現象に対し、その写像先である各意味のことをsemanticsとよんでいるのだと思う。

『論』というのはhow to assignであり、コンテキストに応じて命令文にどのような意味を付加するか、つまりこの写像が具体的にどうなっているか、ということである。写像の値域の元がsemanticsなのであるから、semanticsの訳は写像の詳細でなく元を指すべきで、『意味論』と訳すと意味が通らないのは当然なのだ。コンピュータ関連の翻訳の悪習だと個人的には思うが、皆どう思っているのだろう。


あとすみません、エロサイトのコメントを100件ずつ削除していたら皆のコメントまで消えちゃいました。申し訳ございません...
 
aozora.gr.jp 東大生ブログランキング

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。