  |
はてなキーワード: 計算機科学とは
世の中「プログラミング言語」を説く本はごまんとあれど「プログラミング」を説く本やブログはあまりない。
いや実際に "ない" というのはかなり語弊があるかもしれない。
しかし、通常この種の説明している本に辿り着くまでには多くの時間が必要だ。
普通の人は、多くの間違った方法を試し、その都度試行錯誤を重ね、プログラミング経験を経ることよって、重要な概念を獲得するのだと思う。
例えば、「計算機プログラムの構造と解釈」や「実用 Common Lisp」、「コンピュータプログラミングの概念・技法・モデル」などの書籍は現実の問題に対し "プログラム" をどう書くかという問題に正面から取り組んでいる良書だ。
しかし、どれだけ”普通の”プログラマが上記のような書籍を読んでいるのだろうか。
そして、"普通のプログラマ" がプログラミングを学ぶ書籍として、それらは果たして適切と言えるだろうか。
僕はそうは思わない。
というのも、多くの人は計算機科学を学び、効率のよいアルゴリズムとデータ構造、美しい階層化・モジュール化されたプログラム、などを作るためにプログラミングするのではない。目の前の問題を解決するためにプログラミングを行うからだ。
授業で出された宿題だったり、人それぞれだろう。
このような目の前の問題を解決したい人達が、わざわざ Lisp や Mozart など何の役に立つのか分からない言語を、根気よく勉強するのだろうか。（ちなみに、Lisp や Mozart は上記の書籍で実際に使われている言語である。）
新しいプログラミング言語を学ぶことや、プログラミングの種々の概念を獲得することではない。
もちろんプログラミング言語を上達するためには一つでも多くの概念を会得する必要があるので、あるレベル以上を目指すのであればこれらの書籍を読むことや、抽象化を実現するための様々なツールを手にすることは必須だと思う。
純粋にプログラミングを楽しんでいる人やハッカーを目指したい人はこのような文章を読むのではなく、ぜひ上記に挙げた本を実際に購入し、自分の手で動かして確かめてみることを勧める。プログラミングに対する考え方や姿勢が変わるのは間違いないと思う。
今回はそのような”純粋にプログラミングを楽しんでいる人”に向けた文章でない。
現実の問題をプログラミングを用いて取り組んでいる人に向けて書いた文章だ。
そのような人の中で、なかなかプログラミングが上達しないという人に向けた文章である。
もしプログラミングの学習に限界を感じているのであれば、プログラミングの学習方法が間違っている可能性が高い。
そして残念なことに、初学者向けの書籍では、"プログラミング言語の文法" を説く本はあれど、"プログラミングの学習方法や上達するための正しいスタンス" を説く本はほとんどない。
できるだけ多くの人にプログラムをする楽しみを知ってもらうためにも、
より多くの人がより生産的にプログラムが出来るようになるためにも、
そして特に、右も左も分からなかったプログラミングを始めたばかりの過去の自分に対して、
効果的な学習方法やプログラムする際の指針を書き記したいと思う。
それらは単に指針を示しているだけなので、
どんなプログラミング言語を使っていようとすぐに実践に移せるはずだ。
後はどれだけそれを実践に移し地道にプログラミングしていくだけである。
正しい努力と、ちょっとしたコツさえ知っていれば驚く程生産性を挙げられるはずだと確信している。
プログラマのレベルを以下の 3 つに分けてそれぞれについて説明していきたい。
・使えるプログラミング言語は一つだけ
ただし以下のことは出来ない。
・500行以上のコードが書けない
2. 中級者レベル
・1つ以上のプログラミング言語は使える
・オブジェクト指向は理解している
ただし以下に当てはまる。
・自分が制作しているアプリケーション向けに "実用的なフレームワークやライブラリ" を書けない
・1万行以上のコードだとスパゲッティコードになり、保守不能になる
・適切なサブルーチン化できない
3. 上級者レベル
・プログラミング歴 3 年以上
・現実の問題に対して適切なデータ構造とアルゴリズムを選択できる
・抽象化について理解し、可変部分と不変部分を考慮した設計ができる
またそれぞれのレベルをクリアするには明確な壁がある様に思う。
これらの壁を超えるにはどうすればよいかを説明する。
前置きが長くなったが、以下ではまず初級者レベルの人に向けた具体的なアドバイスをする。
完全に初心者レベルの人はまずどのようにプログラミングを行えばよいのか分からない。一行も書けない。そのため、必然的に以下のような行動を取ると思う。
・本に載っているプログラムをそのまま書き写す（いわゆる写経）
上のような行動を行なっているだけでは、いつまで経っても自分でプログラミングが出来るようにならない。
なぜなら上記のプロセスでは決定的に重要なことが学べないからだ。
それは、【プログラミング言語のモデル】を自分の中に作ることである。
それは普通の言語と同じように文法が存在し、そのしきたりに沿って記述しなければならない。
そのしきたりを学べば書けるようになれる。非常に単純だ。
それなのに、なぜいつまで経っても書けないのか？
それは、”書き写す・コピーする” だけでは、そのしきたりが習得できないからである。
特に最初のうちのプログラミングは頭を作業使う作業でなく、むしろ "体で覚える" 類のものである。
それは例えば、日本語を話すことと似ている。
友達と会話する時、頭を使っているだろうか。
それは簡単な受け答えについては体が覚えているので、考えるより先に日本語が出てくるのではないだろうか。
プログラミングも同様に頭を使うのではなく、こうしたい時はこう書く、という反射神経を育てなければならない。
もちろん日本語話せるだけでは、ミーティングでプレゼン出来ないのと同様に、文法が出来ただけではプログラミングが出来るとは言えない。しかし、文法が出来ないと "現実の問題に対処するソフトウェアを作る" というレベルには到底進めない。そのために、まずそのような文法の反射神経やパイプラインを頭の中に作る必要があるのだ。
・"何をしたい時" に "どう書けば正しく動くか" というデータベース（プログラミング言語のモデル）を自分の中に作ること
このままでは抽象的すぎるので、このような "データベース" や "考える習慣" を自分の中に作るための具体的な指針を以下に挙げる。
1. エラーをたくさん出す
2. デバックの仕方を覚える
3. 小さく動かして確かめる
4. Google を使い倒す
つまり、小さく動かして、エラーをいっぱい出し、デバッグを素早く行なって、分からないことは google などの検索エンジンで解決する。これが上達のコツである。
これらについては以下で詳しく説明するとして、
無理して覚えなくてよい。
プログラマは覚えることが星の数ほどあるので、メソッドなどはリファレンス片手に検索できればよい。
よく使うメソッドなどについては自然に覚えていくので、積極的に覚える必要はなし。それこそ、"体" で覚えるはずである。
覚えられないメソッドについてはそもそもあまり使わないから覚えられないので、重要性は低く覚える必要はない。
むしろ実現したい処理が既にメソッドや関数として提供されていないか、調べる力の方が大事。
・エラーがいっぱい出てつらい
全く問題ない。
・写経をしなければならない
教科書や本の中に書いてあることをそのままエディタで書き写し、実行することを写経という。
上記でも述べたように、これからあまり無駄な努力をしないことを願って言えば、
写経して書いた 10000 行のプログラムより、自分で考えて書いた 100 行のプログラムの方が遥かに意義がある。
そこに "言語のモデル" や "思考" が伴わないと意味がない。
”思考” が伴わないとただの書き写す作業をしているだけだ。
自分の中に "モデル" が出来ていないので、いざ自分でプログラミングしようと試みても、写経をしているだけでは全く書き出せないだろう。
写経はそもそもプログラミングに対するスタンスやプロセスそのものを勘違いさせる危険性をはらんでいるいる。
写経する場合、書き写しの間違いがなければプログラムは問題なく動く。
しかし実際のプログラムではコンパイルや実行するまで、そのプログラムが期待通りに動くかどうか、は絶対に分からない。
そして通常は一気に全てを書き上げるのではなく、まず小さなコア部分を書き、少しずつ他のコア以外の部分を書き上げながらプログラムを完璧なものにしていく。
書き間違えさえなければ正しく動くと知っているプログラムを、上から一行ずつ書いていくプロセスとは正反対だ。
また、以下で述べるようにエラーが発生した場合のデバッグ作業は非常に重要であるだが、そのための作法も写経から学ぶことができない。
なぜならば、写経中にエラーが発生した場合、教科書と自分で書いたプログラムの間違い探しをまず一番最初に行うからだ。これはプログラミングに関する作業ではなく、むしろ間違い探し絵本とにらめっこしているに近い内容である。
それでは、デバッグ方法や言語のモデルを作るとても大切なプロセスを経験できない。
ゆえにそのようにして完成したプログラムもおそらく正しく動きはするが、得られる経験値は驚くほど低いはずである。
とは言え、いきなり自分で書けと言われても書けないと思うので、小さなプログラムを一旦は教科書通り写し、その後自分なりに改変していくのがよいと思う。この場合も写経にはほとんどが意味がないと思った方がよい。"自分なりに改変する" というプロセスこそ意味がある。
今度はどのように "言語のモデル" を自分の中に作っていくかについて説明する。
初心者はエラーを出さない様にと慎重にプログラミングしようとしがちだ。
なぜならば、エラーを出すごとに、その言語の新しいルールを１つずつ学んでいくことになるからだ。
PHP で例えると、
printf の書式だとか
文末に付けるセミコロンだとか
function はネストできないとか
変数には $ を付けなければならないだとか
グローバル変数を関数の中で使う場合は global 宣言するとか
などである。
初心者のうちは一切上のようなルールは知らないはずだからエラーを全て踏むかもしれない。
例え今回作っていたプログラムでエラーを踏まなかったとしても、回数をこなしていけばいくつかエラーに遭遇するだろう。
しかし、それでよいのだ。
エラーを修正することの繰り返しの中で、その言語のモデルが自分の中に出来てくる。
そのようなトライアンドエラーを繰り返えすことで、"言語のモデル" は文字通り体の中に染み込み、プログラムをだんだんと書ける様になっていく。
おそらくこれはは自転車に乗れるようになるプロセスと似たようなものだと思う。
誰しも最初は上手く走れずに転んでばかりいるけれど、何度も何度も転んで起き上がってを繰り返しているうちに少しずつ多くの距離をこげるようになっていくだろう。
そして最終定期には、難なく自転車を乗りこなせるようなっている。
それらのエラーを地道に１つずつ潰して間違いを訂正していくうちに、少しずつ多くの行数の複雑なプログラム書けるようになっていく。
そして最終的には、自由にプログラミング言語を使いこなせるようになっていることに気付くだろう。
自転車も本を読んだだけで乗れるようにはなれないのと同じで
プログラミング言語も本を読んだだけで出来るようになれると思わない方がよい。
それらはトライアンドエラーの繰り返しの中でしか得ることはできないし、誰かから教わる類のスキルでもない。
そして、プログラミングを行うからにはエラーとは一生付き合っていかなければならない。
早めにそれに気付いて受け入れる必要がある。
実際にエラーに遭遇した時に大事なのはエラーに遭遇した時にいかにその原因を突き止めるかだ。
期待しない動作をした時のデバッグという。
まずいちばん基本的で一番重要なデバック方法は printf デバックである。これをまず出来るようにする。
怪しい変数をとにかく printf で出力し、変な値が入っていないかを確かめる方法である。
僕が常々許せないと思っていることは、初学者向けの書籍にはデバッグの重要性やその具体的な方法論が非常に重要であるにも関わらず、それについては解説すらされていないことである。
初心者だからこそ、デバッグの方法論や開発環境をきちんと整えるべきである。
ほとんどの言語処理系では、デバッグ作業を支援する機能を提供している。
分からなければ、"言語 デバッグ方法" でグーグルで検索してみればよい。
例を挙げると、
javascript だったら firebug
各言語にはいわゆる"定石"と言われるデバッグ方法があるはずで、それらを検索し習得すること。
これは無益な時間を過ごさないためにも本当に重要な要素なので、面倒くさがらずに開発環境を整えや方法論をマスターすること。
最初の内は、基本的にプログラミングする時は小さな部品に別けてから1つずつ確かめながら作る習慣を付けるようにする。
その理由は簡単で、人間は正確無比に物事を進めるのは苦手な一方で、プログラミングでは正確無比に物事を進めることを要求されるからである。そのため、大きなプログラムを一度も実行せずに作成し、一気に確かめようとするとまず間違いなく正しく動作しない。
そして厄介なことに、大きなプログラムを作ってしまうとどこに問題があるのか切り分けすることが困難になるので、ますますデバックが難しくなってしまう。
そのためまず小さく作って小さく確かめ、部品を組み合わせてプログラムを作っていくことが大事になる。
一般的に言って、どんなに熟練したプログラマーであろうとも、一つのミスもせずに一定以上の大きさのソフトウェアを作り上げることは不可能である。そのため、ミスやエラーはある程度発生することを前提に、少し作っては実行して確かめる、というサイクルをたくさん回す習慣を付ける。
ソフトウェアは一行書き上げた瞬間から指数関数的に複雑性が増大し、気付いた時にはどうにもならなくなっていることも多い。そういう時は思い切って一から作り直すという選択肢も検討してみるべきだ。
"Small is Beautiful"
これは非常に有名な unix （という OS）の設計理念である。
unix の開発者は様々な失敗経験から、このようなソフトウェア開発のベストプラクティスを学んだに違いない。
まだプログラミング経験の浅い人も、これから偉大な開発者の経験から学ぶことができるはずである。"Small is Beautiful"。小さく作って動かすこと。
先ほどから何度も書いてあるように、プログラミングする上ではエラーとの付き合い方が非常に重要になってくる。
おそらく何らかの上手くいかない場合は何らかのエラーメッセージが出るはずだ。
原因がどうしても分からない場合は、エラーの文章をそのままコピーして検索してみる。そうすると、おそらくエラーの原因と対策方法などが表示されるので、それを足がかりに再度挑戦する。
現実のプログラミングは、どんなにスキルが伸びようとも、いつも上手くいかないことばかりだ。それこそ、何をしてもエラーが出てくるし、何をしても上手く動作しない。だから僕は初心者のうちで一番大事な能力とは、実は "忍耐力" だろうと少しばかり思っている。
でも悩んでるのはあなただけではなく、おそらく全てのプログラマーが通ってきて道だ。
そして、自分の思い通りに動くプログラムを見た時程うれしいものはない。
ぜひ初心者の人はこれを読んで少しでもプログラミングが出来るようになればと思っている。
つ
なぜかLINEでのやりとり。このあとTwitterでblockされた。
| A | hi |
| B | yeah |
| B | 学校祭わろた |
| A | おつ。 |
| A | 打ち上げ的なものはないの? |
| B | ない |
| B | 今学校祭中 |
| A | ああ、把握。わろたがおわたに見えた。 |
| B | 学校祭ェ•••• |
| B | パソコン部の展示なう 誰もけえへんやん |
| A | なるほど |
| B | パソコン部だけ学校祭雰囲気じゃねーww |
| A | そんなもんや… |
| B | あっちで音ゲー こっちでぽけも |
| B | 君もパソコン部かい？ |
| B | 友達こねーくそわろ |
| A | んにゃ、高校のときは※※と〒〒やってたねえ。 |
| B | 学校祭の新しい形ですね |
| B | 学校祭なんてお客さんが楽しむもので、生徒が楽しむものではない、生徒は楽しませる側です |
| A | 僕んところの高校のパソコン部とか何やってたんだろうねえ。 |
| A | Twitterとか見てると灘校のパソコン部展示とかは相当盛り上がってたみたいだけど。 |
| B | 君は神学校出身かい？ |
| B | 灘高は秀才やから |
| A | いや、ずっと公立だね。 |
| B | つくこま のパソコン部もハイレベルやで |
| B | 偏差値は？ |
| A | 僕の偏差値? 学校の入試偏差値? |
| B | 私は地方の進学校(笑)です |
| B | 学校と君の |
| A | 同じく地方の進学校ってとこだね。もっとも田舎だから高校入試は大した競争はないんだけど。 |
| B | 数学できんねやろ？ |
| A | 入試偏差値はさすがに新聞か高校入試情報誌のバックナンバーあたらんとわからんなあ。 |
| B | というか君札幌じゃん |
| A | んにゃ、札幌じゃないけど。 |
| B | え北海道？？ |
| A | 北海道。 |
| B | むろらんさかえ？ |
| B | くしろちょうりょう？ |
| A | ノー。 |
| B | かいせい？ |
| B | あさひがおか？ |
| B | 東西南北 |
| B | ？ |
| B | どれ？ |
| B | 帯広はくよう？ |
| A | ちゃうねん。 |
| B | どこ？ |
| B | 西？ |
| A | 柏葉とか〒〒強かったなあ。 |
| B | W |
| B | 君×高？ |
| A | No. |
| B | 俺×高www |
| B | わろたqwwww |
| B | ×高わろたwww |
| B | ×高わろわろわろたwwww |
| A | なにがおもしろいｗｗｗｗ |
| B | 君は？ |
| A | (そもそも高校生ではないんだけどね…) |
| B | 中学生？大学生？ |
| A | 大学出てるよ |
| B | 出身高どこ？ |
| B | 北海道ではないの？ |
| A | △△。 |
| B | もれ札幌×高。知ってる？私服やで！ |
| B | △△？ |
| A | 私服やで。 |
| B | △△高校？？ |
| A | yes. |
| B | ▲▲系？ |
| A | とは |
| B | 画像 |
| B | 偏差値67わろた ●●県かー |
| A | それ●●の男子校な。 |
| A | ●●の△△はたぶん私服じゃないぞ |
| B | ●●神やな |
| B | 何県？ |
| A | △△市知らんのか… |
| B | 画像 |
| B | しってるで！ |
| B | 理数科？ |
| A | 普通。 |
| B | なんで私服、 |
| B | ？ |
| A | なんでって言われても、校則に制服がないからだけど。 |
| B | わろた |
| B | この話やめよ |
| A | ( なんでいきなり学校の訊問から始まったんだ…? ) |
| B | Htmlの話にかえよう |
| A | うむ。 |
| A | で、HTMLって何さ? |
| A | 何だと思う? |
| B | はいぱーてきすとまーくあっぷらんげーじ 絵や歌と一緒で自分を表現するもの |
| B | メディア |
| A | ほむほむ。 |
| A | 「まーくあっぷ」って何? |
| B | 表現メディアの一種 |
| B | 記すこと |
| A | んー |
| A | じゃあ、ハイパーテキストは? |
| B | 特殊効果付属された文字列及び画像 |
| B | 及び記号 |
| A | 特殊効果とは? |
| B | 色つき、アニメ、 |
| B | この問答に終点はあるんですか？ゴールがみえてますか？ |
| A | ん、取りあえずHTMLがわかってないと話にならんしね。 |
| A | 満点はつけられないけど及第点じゃないかなー、と。 |
| B | はいぱーてきすと はネットにつながるやつですか |
| B | てへぺろ |
| A | 「ネットにつながるやつ」が正確な表現かどうかはともかくとして、それはハイパージャンプ。ハイパーテキストの特徴。 |
| B | ハイパーテキストとは |
| B | 模範回答 |
| B | は |
| B | なんや |
| B | なんやーなんやーなんややややややややややややや |
| A | 「ハイパーなテキスト」 |
| B | んーなるほど |
| A | 要するに、ただのテキストを超えてる。 |
| B | ○○高校のクズがおるで |
| A | って概念。 |
| B | 後ろに |
| B | それで |
| A | でだ、そこで |
| A | HTML5って何? |
| B | なんや |
| B | テキストを超越したものを創造するための道具 |
| A | No. |
| B | なんや |
| B | プログラミング言語 |
| A | そういう名前の「マークアップ言語」ってだけの話なんだけど。 |
| A | プログラミング言語ちゃうねん。 |
| B | しっとるわ |
| B | でいいたいことは？ |
| B | 要旨はなんや |
| A | 「マークアップ言語」ってことが重要。 |
| B | はい |
| B | それで |
| A | 言語であるからには規格があって処理系がある。 |
| A | ってことはおｋ? |
| B | うん |
| B | 規格？ |
| A | 規格。 |
| B | 処理系？ 説明せぇ言われても説明できない言葉やわ |
| B | おしえで |
| B | おしえてー |
| A | 要するに、"print A" って文字列を与えたら "A" って出力するような仕組。 |
| B | それが処理系 |
| B | きかくは？ |
| A | ざっくり言うとそう。 |
| A | 言語が言語として成立するための決まり。 |
| A | さっきの例だと "print A" なら「Aを出力しろ」という命令であるべし、みたいな。 |
| A | HTMLの場合は基本的には要素と属性の定義になってる。 |
| B | あーわかります |
| B | いえーす |
| A | 要素と属性はおｋ? |
| A | element と attribute 。 |
| B | 要素 属性width height |
| A | おｋ。 |
| B | 要素が親 属性が子 |
| A | それはちゃうねん。 |
| B | じゃあなんや |
| A | でもそれは脇道だから置いておく。 |
| B | いいす |
| B | いえす |
| B | そして |
| B | からの |
| B | からの？ |
| A | てっとり早く言うなら、HTML5で定義されてる要素の集合に font や center は入ってない。 |
| B | ふむ |
| A | 集合は? |
| B | じゃあそれらはなんや |
| B | ドモルガンの法則 |
| B | 要素の集まり |
| A | おｋおｋ。問題ないね。 |
| B | なめてんのか、て感じですよ |
| A | で、つまるところ何を見て font とか center を使ってんのよ、ってことになる。 |
| B | しらん |
| B | 理由なくても動くから |
| B | ね |
| A | ってことは、HTML5を知ってることにはならん、と。 |
| B | た(^-^)/な |
| B | だね |
| A | "理由なくても動くから" niceだね! |
| B | だろぅ？ |
| B | ワイルドだろぅ？ |
| B | で使っちゃダメな理由があんの？ |
| A | さっきの話に戻すと、HTMLの処理系って何? |
| A | いっぱいあるよ！＜だめな理由 |
| B | 命令の内容とそれに対応する文字 |
| A | ノー。 |
| B | なんや |
| B | ユーザーの命令に対してのコンピュータが処理する内容 |
| A | 入力に対して応答する「仕組」が処理系。 |
| B | しすてむ |
| A | nice |
| B | 入力に対して応答する仕組み=処理系 |
| A | 日本語の「系」は "system" に対応する。 |
| B | おつす |
| A | で、HTMLを与えて、それをよしなに処理してくれるシステムって何? |
| B | 処理系 |
| A | 具体的には? |
| B | Htmlの処理系 |
| A | HTMLの有名な処理系は何? |
| B | html5 |
| A | それは規格。 |
| B | やー |
| B | こんぱいらー？ |
| A | コンパイラも処理系。 |
| A | (の一部 |
| B | Htmlの処理系てなんや |
| B | コンピュータ |
| A | 大雑把すぎる |
| B | cpu |
| A | ノー。 |
| B | めもり |
| B | なんやねん |
| A | ノー。 |
| B | Os |
| B | web |
| B | ブラウザ |
| A | iPhoneにもWindowsにも処理系が入ってるからWebが見られる。 |
| A | 正解。 |
| B | プレインストールされてすか |
| A | されてるね。 |
| B | なるほどね |
| A | 「HTMLの有名な処理系は何?」の模範解答は InternetExplorerとかMozilla FirefoxとかOperaとかGoogle Chromeとか。 |
| B | で |
| A | で、どうして規格を守る必要があるのか、の話。 |
| B | ブラウザの名前をあげればいいんですね |
| A | それはもう終った。 |
| B | exactly |
| B | ね |
| B | で |
| A | HTML5では文書の先頭に って書くことになってるけど、これはどういう意味か。 |
| B | 宣言 |
| A | DOCTYPE宣言 |
| A | 宣言してるのに規格守らなかったらだめじゃん |
| A | やーいうそつきうそつきー、ってことになる。 |
| A | (まじで |
| B | どういうこと |
| B | Doctype宣言してんのにcenter、fontを要素として使うのはだめだということですか？ |
| A | 「HTML5の」宣言してんのにcenter、fontを使うのはだめー、ってこと。 |
| B | へー |
| A | HTML 4.01 Transitional とかならおｋ。 |
| B | 規格守らないとどういう弊害が？ |
| A | おｋだけど、なんでそんな古いの使ってんのや、ってことになる。 |
| A | あらゆる意味でめんどくさい。 |
| B | で |
| B | 規格守らないと誰か困るの？ |
| A | ユーザも困るし、処理系を作るひとも困る。 |
| B | なんで？ |
| A | 困ったちゃんは絶滅しないから有名な処理系は古い規格をサポートし続けることになるのは確定的に顕かなんだけど。 |
| A | たとえばちょっと処理系を自作しようとしたときに規格を守ってない文書に当たると、例外的な処理をしなければならなくなる。 |
| B | 新しいhtmlの規格がでても 古いバージョンのサポートをやめられないのですか |
| A | そんなことをしたら、君のページを表示できるブラウザがなくなるよね。 |
| A | (HTML5のサポート外の要素を使ってるから |
| B | なるほど |
| B | center、fontに変わる要素はなんや |
| B | 何を使えばええんや |
| A | そもそもそれを要素で指定するのがナンセンスである、って話になってくる。 |
| A | つまり「中央揃え」とか「フォント」とかって意味の要素がナンセンス。 |
| B | 最初Css使ってたけど他人のコードよんでfontていうやつ見つけたんで使ってみた |
| A | 「他人のコードよんで」←まちがい |
| B | cssでcolor: ; |
| A | 「規格書を読む」←せいかい |
| B | 辞めてfont color使うことにした |
| B | 他人のページのソースコード読んででええやろ |
| A | 赤の他人はだいたい間違ってる |
| A | (僕の言ってることも間違ってる可能性があるから規格書を読むべき |
| B | なんや |
| B | 表現が間違ってるわけじゃねぇんだよな |
| B | そういえや |
| B | 規格書をよめってことか |
| A | 暇なときにね |
| A | html5.jp とかで良い。 |
| B | web |
| B | なるほどね |
| B | 偏差値nn |
| B | ？ |
| A | ? |
| B | 君の偏差値は？？ |
| A | さあ |
| B | 教えてや |
| A | そもそも偏差値の基準とは |
| B | 模試の偏差値とか教えて |
| B | 偏差値の基準は？？？ |
| B | 偏差値の基準？なにをいいたい？ |
| A | 模試って言われても高校出て何年も経ってるから数値自体に何の意味もないんだが。 |
| B | 君は賢いかどうか知りたいだけよ。それを知るために偏差値は聞きたい |
| B | はを |
| A | 僕が賢いかって言われたらそりゃ賢くはないねえ。 |
| B | 俺より？ |
| B | プログラミングの大会とかでたことある？？ |
| A | 偏差値が良ければ賢いって価値判断がそもそも相当賢くない気がするんだけど。 |
| A | プロコンは趣味程度にもやってないね。 |
| B | ぉーわかってないねー |
| B | 賢い奴は、学校の勉強くらいできるのよ |
| B | 学校の勉強程度はってことね |
| A | さっきの偏差値nnって何の数字? |
| B | プログラミング技能と偏差値関係ねぇはずだけど、優秀なプログラマーは有名大学出身ばっかさ |
| B | ん？ |
| B | んとね 君の高校の偏差値ね |
| B | 今のね |
| A | 把握。 |
| A | 「優秀なプログラマーは有名大学出身ばっか」の統計的根拠はあったりする? |
| B | ない。俺が感覚的に感じた |
| B | アメリカね |
| B | れいおじー |
| A | 「実際に会った優秀なプログラマと出身大学の関係」とかでも良いんだけど。 |
| B | レイ オジー、マークザッカーバーグ、ビルゲイツ、ポールアレン、 |
| B | 下村努 |
| B | スティーブ ウォズニアック |
| A | おお、そりゃあ有名人だ。 |
| A | で? |
| B | こいつら全員アメリカのトップ高校ばっか |
| B | なんや、小さい頃から理系型天才エリートか、。？ |
| A | そもそもその世代は有名な大学にしかまともな計算機がないんだけどね |
| B | 日本Google、グリーの幹部は東大東工大京大の情報工学ばっか |
| B | なんだ、理系エリートか |
| B | なんやー |
| B | そういうことかー |
| B | 所詮 有名企業は高学歴の巣窟か、 |
| A | ってことで、勉強がんばれ |
| B | 君はこの事実をうけとめられるか |
| A | そういうもんだからねー |
| B | 学生のうちは勉強をすべきなんだ....... |
| B | だから勉強を.........!!!!!! |
| A | するべき。 |
| A | 僕はまともに学校の勉強はしてこなかった人間だからねー |
| B | しろわ |
| B | しろやいま |
| A | んー、いまさら大学入試受ける予定もないしねえ。 |
| B | 君どんな仕事してんの？ |
| A | 自宅を警備するお仕事をしてるよ☆ ってTwitterのbioにも書いてる |
| B | ニート |
| B | か |
| A | こんな夢見がちな大人になっちゃいけないよ☆ |
| B | 仕事する予定は？ |
| A | ないない |
| B | しろや |
| B | 家でなにしてんの？ |
| A | お勉強 |
| B | なんの？ |
| A | SICP |
| B | 親が生活費だしてんこ？ |
| B | だしてんの？ |
| A | んにゃ、自分のお金でだけど |
| B | ふりーたーか？ |
| B | アルバイトはしてる？ |
| A | ないない。アルバイトなんてしたら自宅を警備できないしね。 |
| A | そんな大人になっちゃいけない |
| B | 自分の金てなに？お前が稼いだ金？ |
| A | いえーす |
| B | どこで？ |
| B | 働いてないのに |
| A | 不思議だ… |
| B | お前なんやねん |
| B | 何者やねん |
| A | 自宅警備員 |
| B | ばか？ |
| A | Twitterのbioに書いてる以上でも以下でもない感じ。 |
| B | ごみ？ |
| B | 社会のゴミ？ |
| A | 少なくともいまの君よりは計算機科学に詳しい、ってことでおｋ? |
| B | おーけー |
| A | ってことで、こんな社会のゴミなんか秒速で追い抜いてみせろ、ってことでひとつ。 |
| B | まあ俺がお前の歳だったら、お前より知識あるがな。俺×高やし、北大いくし |
| A | おーすごいすごい。 |
| A | さっきの学歴を持ち出すなら北大じゃいろいろ物足りない気がするけど。 |
| A | 素直に京大とか東大とか行っとけ |
| A | 北大の教授で京大や東大ではしてない研究をしてるのが居てその分野を專攻したいー、とかなら別だけど。 |
| A | 知ってる範囲の北大の学生でものすごいのって、□□□□出てて高校時代から一人でばりばりプログラム書いてる、とかそんな感じだから |
| B | まあお前よりは高等だから |
| B | こめん |
| B | ごめん |
| A | 僕より偏差値高いだろうってことは知ってるから、いまさら確認することじゃないなｗ |
| A | ただ、具体名は避けておくけど、GoogleとかMSだけに優秀なプログラマが集まってると思ってるなら、それは間違ってるねー |
| A | 「高学歴=優秀なプログラマ」が真なら、国内のメーカーはどうしてこんな惨状なのか… |
| A | 僕がこの2年くらいで会ってきた、そこそこ多めな数の高校生とか大学生たちから見るに、優秀な高校生が良い大学入ってるってのはおよそ間違ってないね。東大とか京大とか筑波とか東工大とか。 |
| A | s/優秀な高校生/優秀な高校生プログラマ/ ね |
| B | そう吠えんな |
| B | ごみなんだからお前は |
| B | 情報オリのメダリストは全員高学歴だろ |
| A | それはまったく否定しない |
| B | 高学歴=優秀なプログラマーとはいってないよくず |
| B | 優秀なプログラマーは高学歴であることが多いてことな |
| A | で、情報オリンピックとか挙げちゃうとお前はどうなのよ、って話になってくる。 |
| B | それ俺より馬鹿なクズがいうセリフじゃないぞ |
| A | 情報オリンピックのメダリストになりたいの? 高学歴になりたいの? |
| B | 最終目標は金持ちやね |
| B | 金持ちになるにはいい大学いったほうが確実だろ？ |
| B | プログラミングは興味本位かな |
| A | 確実って言うには出身大学は要件としていささか貧弱な気がするんだけど |
| B | 金持ちになるには、いい大学いくことが近道 |
| A | 僕は読みたい本が買えるだけの儲けがありゃ良いから金持ちとかあんまり関係ない話やね |
| B | くずめ |
| A | 上位の大学の方が平均年収が高い、とかって水準の話ならまったくその通り。 |
| B | 金持ちなれねぇやつが かっこつけんなくず |
| A | 君が儲ける金は君のものだし、僕が儲けた金は僕のものだから、まったく関係がないよね |
| B | きも |
| B | くずだw |
| B | お前は負け犬だ |
| B | 可哀想に |
| A | 別に君のおこぼれに与ろうってことは期待してないから、君が勝っても負けてもどうでも良いんだけど。 |
| B | くずめ死ね |
| B | お前らはくずなんだから今すぎ死ね |
| A | 今すぎ |
| B | お前みたいな奴が日本の足引っ張んだよくずwww |
| A | 内心蔑みながらも日本の未来を案じるさまは立派です。 |
第1章 有限オートマトン D.Perrin：橋口攻三郎 1. 序論 2. 有限オートマトンと認識可能集合 3. 有理表現 4. Kleeneの定理 5. 星の高さ 6. 星自由集合 7. 特殊なオートマトン 8. 数の認識可能集合 第2章 文脈自由言語 J.Berstel and L.Boasson：富田 悦次 1. 序論 2. 言語 2.1 記法と例 2.2 Hotz 群 2.3 曖昧性と超越性 3. 反復 3.1 反復補題 3.2 交換補題 3.3 退化 4. 非生成元の探求 4.1 準備 4.2 生成元 4.3 非生成元と代入 4.4 非生成元と決定性 4.5 主錐の共通部分 5. 文脈自由群 5.1 文脈自由群 5.2 Cayleyグラフ 5.3 終端 第3章 形式言語とべき級数 A.Salomaa：河原 康雄 1. 序論 2. 準備 3. 書換え系と文法 4. Post正準系 5. Markov系 6. 並列書換え系 7. 射と言語 8. 有理べき級数 9. 代数的べき級数 10. べき級数の応用 第4章 無限の対象上のオートマトン W.Thomas：山崎 秀記 序論 Ⅰ部 無限語上のオートマトン 記法 1. Buchiオートマトン 2. 合同関係と補集合演算 3. 列計算 4. 決定性とMcNaughtonの定理 5. 受理条件とBorelクラス 6. スター自由ω言語と時制論理 7. 文脈自由ω言語 Ⅱ部 無限木上のオートマトン 記法 8. 木オートマトン 9. 空問題と正則木 10. 補集合演算とゲームの決定性 11. 木の単項理論と決定問題 12. Rabin認識可能な集合の分類 12.1 制限された単項2階論理 12.2 Rabin木オートマトンにおける制限 12.3 不動点計算 第5章 グラフ書換え：代数的・論理的アプローチ B.Courcelle：會澤 邦夫 1. 序論 2. 論理言語とグラフの性質 2.1 単純有向グラフの類S 2.2 グラフの類D(A) 2.3 グラフの性質 2.4 1階のグラフの性質 2.5 単項2階のグラフの性質 2.6 2階のグラフの性質 2.7 定理 3. グラフ演算とグラフの表現 3.1 源点付きグラフ 3.2 源点付き超グラフ 3.3 超グラフ上の演算 3.4 超グラフの幅 3.5 導来演算 3.6 超辺置換 3.7 圏における書換え規則 3.8 超グラフ書換え規則 4. 超グラフの文脈自由集合 4.1 超辺置換文法 4.2 HR文法に伴う正規木文法 4.3 超グラフの等式集合 4.4 超グラフの文脈自由集合の性質 5. 超グラフの文脈自由集合の論理的性質 5.1 述語の帰納的集合 5.2 論理構造としての超グラフ 5.3 有限超グラフの可認識集合 6. 禁止小グラフで定義される有限グラフの集合 6.1 小グラフ包含 6.2 木幅と木分解 6.3 比較図 7. 計算量の問題 8. 無限超グラフ 8.1 無限超グラフ表現 8.2 無限超グラフの単項性質 8.3 超グラフにおける等式系 8.4 関手の初期不動点 8.5 超グラフにおける等式系の初期解 8.6 等式的超グラフの単項性質 第6章 書換え系 N.Dershowitz and J.-P.Jouannaud：稲垣 康善，直井 徹 1. 序論 2. 構文論 2.1 項 2.2 等式 2.3 書換え規則 2.4 決定手続き 2.5 書換え系の拡張 3. 意味論 3.1 代数 3.2 始代数 3.3 計算可能代数 4. Church-Rosser性 4.1 合流性 4.2 調和性 5. 停止性 5.1 簡約順序 5.2 単純化順序 5.3 経路順序 5.4 書換え系の組合せ 6. 充足可能性 6.1 構文論的単一化 6.2 意味論的単一化 6.3 ナローイング 7. 危険対 7.1 項書換え 7.2 直交書換え系 7.3 類書換え 7.4 順序付き書換え 7.5 既約な書換え系 8. 完備化 8.1 抽象完備化 8.2 公平性 8.3 完備化の拡張 8.4 順序付き書換え 8.5 機能的定理証明 8.6 1階述語論理の定理証明 9. 書換え概念の拡張 9.1 順序ソート書換え 9.2 条件付き書換え 9.3 優先度付き書換え 9.4 グラフ書換え 第7章 関数型プログラミングとラムダ計算 H.P.Barendregt：横内 寛文 1. 関数型計算モデル 2. ラムダ計算 2.1 変換 2.2 計算可能関数の表現 3. 意味論 3.1 操作的意味論：簡約と戦略 3.2 表示的意味論：ラムダモデル 4. 言語の拡張 4.1 デルタ規則 4.2 型 5. 組合せ子論理と実装手法 5.1 組合せ子論理 5.2 実装の問題 第8章 プログラミング言語における型理論 J.C.Mitchell：林 晋 1. 序論 1.1 概論 1.2 純粋および応用ラムダ計算 2. 関数の型をもつ型付きラムダ計算 2.1 型 2.2 項 2.3 証明系 2.4 意味論と健全性 2.5 再帰的関数論的モデル 2.6 領域理論的モデル 2.7 カルテシアン閉圏 2.8 Kripkeラムダモデル 3. 論理的関係 3.1 はじめに 3.2 作用的構造上の論理的関係 3.3 論理的部分関数と論理的同値関係 3.4 証明論的応用 3.5 表現独立性 3.6 論理的関係の変種 4. 多相型入門 4.1 引数としての型 4.2 可述的な多相的計算系 4.3 非可述的な多相型 4.4 データ抽象と存在型 4.5 型推論入門 4.6 型変数をもつλ→の型推論 4.7 多相的宣言の型推論 4.8 他の型概念 第9章 帰納的な関数型プログラム図式 B.Courcelle：深澤 良彰 1. 序論 2. 準備としての例 3. 基本的な定義 3.1 多ソート代数 3.2 帰納的な関数型プログラム図式 3.3 同値な図式 4. 離散的解釈における操作的意味論 4.1 部分関数と平板な半順序 4.2 離散的解釈 4.3 書換えによる評価 4.4 意味写像 4.5 計算規則 5. 連続的解釈における操作的意味論 5.1 連続代数としての解釈 5.2 有限の極大要素と停止した計算 6. 解釈のクラス 6.1 汎用の解釈 6.2 代表解釈 6.3 解釈の方程式的クラス 6.4 解釈の代数的クラス 7. 最小不動点意味論 7.1 最小で唯一の解を得る不動点理論 7.2 Scottの帰納原理 7.3 Kleeneの列と打切り帰納法 8. プログラム図式の変換 8.1 プログラム図式における同値性の推論 8.2 畳込み，展開，書換え 8.3 制限された畳込み展開 9. 研究の歴史，他の形式のプログラム図式，文献ガイド 9.1 流れ図 9.2 固定された条件をもつ一様な帰納的関数型プログラム図式 9.3 多様な帰納的関数型プログラム図式 9.4 代数的理論 9.5 プログラムの生成と検証に対する応用 第10章 論理プログラミング K.R.Apt：筧 捷彦 1. 序論 1.1 背景 1.2 論文の構成 2. 構文と証明論 2.1 1階言語 2.2 論理プログラム 2.3 代入 2.4 単一化子 2.5 計算過程―SLD溶融 2.6 例 2.7 SLD導出の特性 2.8 反駁手続き―SLD木 3. 意味論 3.1 1階論理の意味論 3.2 SLD溶融の安全性 3.3 Herbrand模型 3.4 直接帰結演算子 3.5 演算子とその不動点 3.6 最小Herbrand模型 3.7 SLD溶融の完全性 3.8 正解代入 3.9 SLD溶融の強安全性 3.10 手続き的解釈と宣言的解釈 4. 計算力 4.1 計算力と定義力 4.2 ULの枚挙可能性 4.3 帰納的関数 4.4 帰納的関数の計算力 4.5 TFの閉包順序数 5. 否定情報 5.1 非単調推論 5.2 閉世界仮説 5.3 失敗即否定規則 5.4 有限的失敗の特徴付け 5.5 プログラムの完備化 5.6 完備化の模型 5.7 失敗即否定規則の安全性 5.8 失敗即否定規則の完全性 5.9 等号公理と恒等 5.10 まとめ 6. 一般目標 6.1 SLDNF-溶融 6.2 SLDNF-導出の安全性 6.3 はまり 6.4 SLDNF-溶融の限定的な完全性 6.5 許容性 7. 層状プログラム 7.1 準備 7.2 層別 7.3 非単調演算子とその不動点 7.4 層状プログラムの意味論 7.5 完全模型意味論 8. 関連事項 8.1 一般プログラム 8.2 他の方法 8.3 演繹的データベース 8.4 PROLOG 8.5 論理プログラミングと関数プログラミングの統合 8.6 人工知能への応用 第11章 表示的意味論 P.D.Mosses：山田 眞市 1. 序論 2. 構文論 2.1 具象構文論 2.2 抽象構文 2.3 文脈依存構文 3. 意味論 3.1 表示的意味論 3.2 意味関数 3.3 記法の慣例 4. 領域 4.1 領域の構造 4.2 領域の記法 4.3 記法上の約束事 5. 意味の記述法 5.1 リテラル 5.2 式 5.3 定数宣言 5.4 関数の抽象 5.5 変数宣言 5.6 文 5.7 手続き抽象 5.8 プログラム 5.9 非決定性 5.10 並行性 6. 文献ノート 6.1 発展 6.2 解説 6.3 変形 第12章 意味領域 C.A.Gunter and D.S.Scott：山田 眞市 1. 序論 2. 関数の帰納的定義 2.1 cpoと不動点定理 2.2 不動点定理の応用 2.3 一様性 3. エフェクティブに表現した領域 3.1 正規部分posetと射影 3.2 エフェクティブに表現した領域 4. 作用素と関数 4.1 積 4.2 Churchのラムダ記法 4.3 破砕積 4.4 和と引上げ 4.5 同形と閉包性 5. べき領域 5.1 直観的説明 5.2 形式的定義 5.3 普遍性と閉包性 6. 双有限領域 6.1 Poltkin順序 6.2 閉包性 7. 領域の帰納的定義 7.1 閉包を使う領域方程式の解法 7.2 無型ラムダ記法のモデル 7.3 射影を使う領域方程式の解法 7.4 双有限領域上の作用素の表現 第13章 代数的仕様 M.Wirsing：稲垣 康善，坂部 俊樹 1. 序論 2. 抽象データ型 2.1 シグニチャと項 2.2 代数と計算構造 2.3 抽象データ型 2.4 抽象データ型の計算可能性 3. 代数的仕様 3.1 論理式と理論 3.2 代数的仕様とその意味論 3.3 他の意味論的理解 4. 単純仕様 4.1 束と存在定理 4.2 単純仕様の表現能力 5. 隠蔽関数と構成子をもつ仕様 5.1 構文と意味論 5.2 束と存在定理 5.3 隠蔽記号と構成子をもつ仕様の表現能力 5.4 階層的仕様 6. 構造化仕様 6.1 構造化仕様の意味論 6.2 隠蔽関数のない構造化仕様 6.3 構成演算 6.4 拡張 6.5 観測的抽象化 6.6 構造化仕様の代数 7. パラメータ化仕様 7.1 型付きラムダ計算によるアプローチ 7.2 プッシュアウトアプローチ 8. 実現 8.1 詳細化による実現 8.2 他の実現概念 8.3 パラメータ化された構成子実現と抽象化子実現 8.4 実行可能仕様 9. 仕様記述言語 9.1 CLEAR 9.2 OBJ2 9.3 ASL 9.4 Larch 9.5 その他の仕様記述言語 第14章 プログラムの論理 D.Kozen and J.Tiuryn：西村 泰一，近藤 通朗 1. 序論 1.1 状態，入出力関係，軌跡 1.2 外的論理，内的論理 1.3 歴史ノート 2. 命題動的論理 2.1 基本的定義 2.2 PDLに対する演繹体系 2.3 基本的性質 2.4 有限モデル特性 2.5 演繹的完全性 2.6 PDLの充足可能性問題の計算量 2.7 PDLの変形種 3. 1階の動的論理 3.1 構文論 3.2 意味論 3.3 計算量 3.4 演繹体系 3.5 表現力 3.6 操作的vs.公理的意味論 3.7 他のプログラミング言語 4. 他のアプローチ 4.1 超準動的論理 4.2 アルゴリズム的論理 4.3 有効的定義の論理 4.4 時制論理 第15章 プログラム証明のための手法と論理 P.Cousot：細野 千春，富田 康治 1. 序論 1.1 Hoareの萌芽的な論文の解説 1.2 C.A.R.HoareによるHoare論理のその後の研究 1.3 プログラムに関する推論を行うための手法に関するC.A.R.Hoareによるその後の研究 1.4 Hoare論理の概観 1.5 要約 1.6 この概観を読むためのヒント 2. 論理的，集合論的，順序論的記法 3. プログラミング言語の構文論と意味論 3.1 構文論 3.2 操作的意味論 3.3 関係的意味論 4. 命令の部分正当性 5. Floyd-Naurの部分正当性証明手法とその同値な変形 5.1 Floyd-Naurの手法による部分正当性の証明の例 5.2 段階的なFloyd-Naurの部分正当性証明手法 5.3 合成的なFloyd-Naurの部分正当性証明手法 5.4 Floyd-Naurの部分正当性の段階的な証明と合成的な証明の同値性 5.5 Floyd-Naurの部分正当性証明手法の変形 6. ライブネスの証明手法 6.1 実行トレース 6.2 全正当性 6.3 整礎関係，整列集合，順序数 6.4 Floydの整礎集合法による停止性の証明 6.5 ライブネス 6.6 Floydの全正当性の証明手法からライブネスへの一般化 6.7 Burstallの全正当性証明手法とその一般化 7. Hoare論理 7.1 意味論的な観点から見たHoare論理 7.2 構文論的な観点から見たHoare論理 7.3 Hoare論理の意味論 7.4 構文論と意味論の間の関係：Hoare論理の健全性と完全性の問題 8. Hoare論理の補足 8.1 データ構造 8.2 手続き 8.3 未定義 8.4 別名と副作用 8.5 ブロック構造の局所変数 8.6 goto文 8.7 （副作用のある）関数と式 8.8 コルーチン 8.9 並行プログラム 8.10 全正当性 8.11 プログラム検証の例 8.12 プログラムに対して1階論理を拡張した他の論理 第16章 様相論理と時間論理 E.A.Emerson：志村 立矢 1. 序論 2. 時間論理の分類 2.1 命題論理 対 1階述語論理 2.2 大域的と合成的 2.3 分岐的 対 線形 2.4 時点と時区間 2.5 離散 対 連続 2.6 過去時制 対 未来時制 3. 線形時間論理の技術的基礎 3.1 タイムライン 3.2 命題線形時間論理 3.3 1階の線形時間論理 4. 分岐的時間論理の技術的基礎 4.1 樹状構造 4.2 命題分岐的時間論理 4.3 1階の分岐的時間論理 5. 並行計算：その基礎 5.1 非決定性と公平性による並列性のモデル化 5.2 並列計算の抽象モデル 5.3 並列計算の具体的なモデル 5.4 並列計算の枠組みと時間論理の結び付き 6. 理論的見地からの時間論理 6.1 表現可能性 6.2 命題時間論理の決定手続き 6.3 演繹体系 6.4 モデル性の判定 6.5 無限の対象の上のオートマトン 7. 時間論理のプログラムの検証への応用 7.1 並行プログラムの正当性に関する性質 7.2 並行プログラムの検証：証明論的方法 7.3 時間論理による仕様からの並行プログラムの機械合成 7.4 有限状態並行システムの自動検証 8. 計算機科学における他の様相論理と時間論理 8.1 古典様相論理 8.2 命題動的論理 8.3 確率論理 8.4 不動点論理 8.5 知識 第17章 関係データベース理論の構成要素 P.C.Kanellakis：鈴木 晋 1. 序論 1.1 動機と歴史 1.2 内容についての案内 2. 関係データモデル 2.1 関係代数と関係従属性 2.2 なぜ関係代数か 2.3 なぜ関係従属性か 2.4 超グラフとデータベーススキーマの構文について 2.5 論理とデータベースの意味について 3. 従属性とデータベーススキーマ設計 3.1 従属性の分類 3.2 データベーススキーマ設計 4. 問合わせデータベース論理プログラム 4.1 問合わせの分類 4.2 データベース論理プログラム 4.3 問合わせ言語と複合オブジェクトデータモデル 5. 議論：関係データベース理論のその他の話題 5.1 不完全情報の問題 5.2 データベース更新の問題 6. 結論 第18章 分散計算：モデルと手法 L.Lamport and N.Lynch：山下 雅史 1. 分散計算とは何か 2. 分散システムのモデル 2.1 メッセージ伝達モデル 2.2 それ以外のモデル 2.3 基礎的概念 3. 分散アルゴリズムの理解 3.1 挙動の集合としてのシステム 3.2 安全性と活性 3.3 システムの記述 3.4 主張に基づく理解 3.5 アルゴリズムの導出 3.6 仕様記述 4. 典型的な分散アルゴリズム 4.1 共有変数アルゴリズム 4.2 分散合意 4.3 ネットワークアルゴリズム 4.4 データベースにおける並行性制御 第19章 並行プロセスの操作的および代数的意味論 R.Milner：稲垣 康善，結縁 祥治 1. 序論 2. 基本言語 2.1 構文および記法 2.2 操作的意味論 2.3 導出木と遷移グラフ 2.4 ソート 2.5 フローグラフ 2.6 拡張言語 2.7 その他の動作式の構成 3. プロセスの強合同関係 3.1 議論 3.2 強双模倣関係 3.3 等式による強合同関係の性質 3.4 強合同関係における置換え可能性 3.5 強等価関係上での不動点の唯一性 4. プロセスの観測合同関係 4.1 観測等価性 4.2 双模倣関係 4.3 観測合同関係 4.4 プロセス等価性上での不動点の唯一性 4.5 等式規則の完全性 4.6 プロセスの等価性に対するその他の概念 5. 双模倣等価関係の解析 5.1 等価性の階層構造 5.2 階層構造の論理的特性化 6. 合流性をもつプロセス 6.1 決定性 6.2 合流性 6.3 合流性を保存する構成子 7. 関連する重要な文献
とっくに自覚してんじゃん。仕事ってのは意味のある仕事であるうちは嘘で、単に食うための無意味な仕事になってからが本当なのかもしれないね。でも、じゃあ、本当に仕事を変えてやっていけるか？給与の額にかかわらず、辛いのは変わんないかもよ。
職場に Halabi と Stevens と Rose 持ち込んでも誰もその中身には興味がない時代だよ。知識つけたって評価されない仕事が増えて苦しくなるだけだから。つまんないから ACM の個人会員になってみたけど、なんかCACMって毎号毎号計算機科学に未来はあるのか？みたいな記事が1つは載ってて、げんなりして、更新、やめた。
色々教えてください偉い人。
自分で考えろってのはご尤もですが、色々な方の意見が聞いてみたいのです。
・Struts（ver2じゃないほう）上でのJava（max2000行程度）
・perl（max7000行程度）
・c/c++（ちょっと）
・Haskell（ほんの少し）
・VisualBasic（.NETじゃないほう）（ほとんど忘れた）
・HTML/CSS（セマンティック厨）（HTML5は勉強中）（バイトでWEBデザイン経験有）
・javascript（簡単なものなら）
・MovableType（CMSとして利用。ちょっとした企業サイトレベルくらいのものの構築。簡単なプラグインの作成とかも）
・Apache（セットアップと最低限の設定くらい）
・Tomcat（同上）
・Linux（CentOSとUbuntu。セットアップとちょっとした設定程度）
・AdobeのDTP系製品（CS2）（雑誌編集経験有、ただし学生レベル）
・Oracle（10g）（Bronzeレベルの知識とちょっと触ったことがある程度の経験）
・postgreSQL（ちょっと触ったことがある程度）
・会計関連の知識（日商簿記2級）（大学で管理会計をかじった）
・数学系の知識（論理とか集合やらの基礎。大学で計算機科学をかじった）
・印刷物/WEBサイトのデザイン（独学だけどそれなりに。一般人よりはそれっぽいデザインが作れるかと）
そろそろ四月ということで、職業としての「プログラマ」になる方も、はてな界隈では多いでしょうか。なにはともあれおめでとうございます。マの世界へようこそ。私も４月になるので、心機一転頑張りたいなと思い、働いて学んできたことや言われてきたことなどをつらつらと書き出します。
仕事のルールはたくさんあります。その中で座右の銘ではありませんが、指針となるような一つ目標があるといいでしょう。私が念頭に置いているのは「三年後に気持ちよく転職できるようにする」ということです。結構移り気が激しいタイプなんですよね。でも人には嫌われたくないという。「気持ちよく」というのがポイントで、会社を「気持ちよく」辞めて転職するのは今までに辞めていった先輩をみていてもなかなか大変そうです。「気持ちよく」辞めるための仕事術を「上司」「同期」「後輩」「自分」という点であげてみました。大切なのは「気持ちよく転職できるようにする」ために周りの人を気遣いそれを示すことで「あいつはよく頑張ってくれた」「次も頑張ってもらいたい」「また一緒に仕事をしたいな」と思ってもらい惜しまれつつ転職できるようにすることです。
あなたの上司は仕事全体の進捗の管理とメンバーの割り振りを考えます。そのために各人に割り振った仕事の進み具合や仕事量に無理がないかを把握する必要があります。あなたはそれを考えて、自分が行っているタスクの状態をきちんと上司に報告しましょう。現状に無理があるようなら、その状態と代替策を上司に相談しましょう。
大抵の人は忙しいのと、別の問題で頭を使っているため、きっとあなたが頭を悩ませて質問したいと思っている、その特定の問題について、あなたほど深く考えていないでしょう。そんな時にただ質問も投げられても、相手も一から考えてしまうので、お互いに負荷が高くなってしまいます。それで相手のことを考えて、技術的な質問や方針などの相談の際には質問の後に「こうしてみようと思う」「この点が問題なのでこうすれば解決するはず」など、それなりに自分の答えをもって、質問や意見をすべきです。そうすれば相手もそれをベースに自分の意見や経験を考えながら伝えることが出来るため、あなたの質問に答えることがそれほど重荷ではなくなります。
楽しく笑顔で働きましょう。笑う門には福来るではないですが、多くの人は笑顔に惹き付けられるものです。また上司も基本、自分の舵取りでメンバーが楽しく仕事出来ていると思いたいものです。それに応えましょう。
会社には多くの場合、コーディングルールやドキュメント規則があります。「こうしたほうが早いのになあ」とか「こんなのクールじゃない」とか考えることもあるでしょうが、ルールに従いましょう。３年後に後輩に「ここはクールじゃなかったらこうした」と説明するのは大変ですし、きっと３年もたてば、その「クール」も変わっているはずです。もしどう考えても効率が悪いようなら会社のルール自体の改善を訴えましょう。
上と矛盾するようですが、急ぎ仕事（こればかりやる会社もある）をやる場合は、ドキュメント不要ということもあります。そんな場合でも最低限の仕様等のドキュメントの記録を残しておきましょう。引き継ぐ後輩に口頭で伝えるのは手間というより、忘れている部分も増え、伝言ゲーム状態になります。これは、人日を割当られていないのにやるわけですから、ちょっと大変ですが、意識しておきましょう。
自分がどう考えて、どう上司とやり取りをしていたかを簡単な記録でいいので毎日つけましょう。将来の後輩が見た時にきっとそれが、励ましや何かのヒントになるはずです。
自分についてはこのひとつだけ。失敗をしないのは仕事をしない人だけです。三年後にはどうせ転職するのですから、失敗をおそれずルールを守りながらも常に新しい何かを探して創りだしていきましょう。そうすれば転職の際に自分はこういう挑戦をしてきたという自信が出来ますし、以前の会社で思い切れば未練なく辞めることが出来ます。
失敗は怖いですが、それを少し減らす方法として「失敗を想定する」プログラマ的に言えば「例外処理」を考えておくというのがあります。人はわからないものは怖いですが、失敗した、間違いを犯した場合はこうすればいい、最悪こうなるということがわかっていれば、その恐怖は減るものです。そしてその「例外処理」を書きおわったなら、明日のことを考えて、思い悩むのは辞めて、その日、その日の仕事を頑張りましょう。
仕事の進め方について書いてみましたが、冒頭でも述べたように、プログラマは一サラリーマンである以上に一職人です。プログラムについての勉強を常にしましょう。勉強は会社をやめても人を裏切りません。プログラム言語についてはもちろんですが、それだけではありません。仕事をしているとついつい忘れがちになりますが、基本的なデータ構造とアルゴリズムやデータベースの仕組みやネットワークの仕組み等の計算機科学を知っておくことが大切です。またプログラムの組み方については、デザパタやエンタープライズアーキテクスチャパターンなどを知っておくと仕事をすすめやすいでしょう。
私のおすすめは「勉強会駆動勉強」です。何か勉強したいな、身につけたいなあと思うことがあったら、それをテーマに近くのコミュニティの勉強会の発表申し込みをします。人に教えようとすると自分のものにしなければいけませんから必死に勉強します。するとその知識が身に付くのはもちろんこと、その分野について詳しい人と周りに思ってもらえるかもしれず、また第一人者からアドバイスを受けることもできます。なかなかの一石三鳥です。
勉強のことについて、最初と逆になりますが私たちは一職人ですが一サラリーマンです。ハッカーといえど、社会人としての基本的な知識である英語や数学や経済学をおさえておきましょう。経済学は感覚とは違う部分で社会が動いていることがわかり、おもしろいです。私のおすすめは「スティグリッツ入門経済学」ですね。また習慣として毎日のニュース（日経）や週ペースの経済雑誌（東洋経済等）を読んで、基本的な現代経済をおさえておきましょう。自分の仕事を社会の目から客観的におさえることが出来ます。
最後に。仕事のことや勉強のことをたくさん書いてきました。しかし、仕事に最適化しても人生はおもしろくありません。運動を適度にし、自分の趣味を見つけて興味を持ち（私はアニメとラノベ読み）、いろいろなことを学んで、楽しみながら人生を過ごしましょう。
http://readingmonkey.blog45.fc2.com/blog-entry-171.html
読書猿（くるぶし）さんによれば
Atkinson & Hilgard's Introduction to Psychology 15th ed. by Susan Nolen-Hoeksema、Barbara L. Fredrickson、Geoff R. Loftus、 Willem A. Wagenaar (ペーパーバック - 2009/6/15)
英文平易。解説丁寧。要約簡潔。心理学史的視点を維持しつつ、現代心理学の分野のほとんど全ての重要項目を網羅したオールラウンドの『王道』的教科書。邦訳『ヒルガードの心理学』(2005)は、一つ前の版の訳になってしまった。
らしいよ。
臨床心理と計算機科学はわからない。
プログラムの高級言語(特に古典的なBASIC)は、命令が英単語そのままだったりする。
いくつかの基本的な英単語と少しの数式が分かれば、簡単なプログラムの読み書きができる(はず)。
圧倒的に、知ってなきゃいけない単語数や文法の知識量が違うから。
最近は知ってなきゃいけない命令や概念が増えてきたけれど、それでもIDEの補完機能を使えばなんとかなる。それに、文法ミスがあってもコンパイルエラーで分かるし、その間違った場所のヒントもコンパイラやIDEがくれる。
英語はそういうのも、全部自分で処理しないといけない。似ているけどニュアンスの違う単語だとか、適切な単語・文法選択だとか。そこが、そもそも知っていて、自分で即座に判断できる能力もないと使えないので苦しい。
