「計算機科学」を含む日記 RSS

はてなキーワード: 計算機科学とは

2017-04-17

知能を上げる方法

わたしの知っている知能の高い人たち(wais-iiiでIQ140~くらい出す人たち)はみんな興味のないことが全然できない。

好きなことばっかりやってて、どうでもいいことに対してはすごく冷淡。

でこれまでわたしは彼らのそういう性質は知能の代償なのかなって思ってたんだけど、実は因果の向きが逆で、好きなことしかできないから彼らは知能が高いんじゃないかって思うようになった。

そう考える理由ちょっと説明してみたい。

まず人類学問の体系は、だいたいどんな分野であれ似たような方法論に依っている。

物理学でも文化人類学でも計算機科学でもやっていることはだいたい同じだ。

で、知能というのはそこで共通する一般的思考の枠組み、もの見方だと思われる。

少なくとも知能検査で測られる知能っていうのは、そういう性質抽象して測るために作られているはずだ。

そしてこの方法論を学ぶには、浅く広く物事を知るよりも、ひとつ分野を定めて深く掘り下げるほうが効率が良い。

というのも、分野に関係なく、ある程度の深さまで達しないと現れてこず習得もできない思考の仕方というものがあるからだ。

そう考えると、一つの興味をひたすら追求しそれ以外を無視するような知性のほうが、広くこつこつと学んでいく知性よりはやく高度な思考法を獲得するのは当然だということになる。

というわけで、賢くなりたい人はいろんな分野に浮気せず、ひとつ学問を究めてみると良いんじゃないかな。

おすすめ数学哲学です。

(追記)

なんか誤解されているみたいだけど、頭の良い人がみんな専門馬鹿だと言ってるわけではなくて、

一度一つのことを深く追求して得た一般的方法はわりと応用が効くよ、知能ってつまりそういう能力じゃない?ということが言いたかった。

で興味が偏ってる人はそういう発達過程を経やすいんじゃないか、というのがわたしの推論。

もちろん万能っぽい人も中にはいるけど、彼らは興味の幅がそれなりに広いだけで、

やっぱりそれ以外のところでかなり欠落してたりする。

それから、waisでほんとの知能を測定できるかって話になると、そもそも知性とはなんぞやという議論になってしまうわけだけど、

それはあまりに複雑な話題から書かない。

ただしwaisで高いスコアを出す人たちの能力思考法が傍から見ていてそれなりに便利なものであるのは間違いなく、

彼らがそれをどうやって身につけてきたのか、なにが要因としてあるのか考えるのには意味がある、と思った。

知能に直接関与する遺伝子は見つかってないみたいだしね。

2017-03-23

http://anond.hatelabo.jp/20170323162129

ここに書かれていることは概ね正しい.この方は自分モチベーションが低下したことを嘆いておられる.そういう方々は大学に多くいる.しかし,日本大学にはこのような劣悪の環境の中で,モチベーションが低下せずに生き延びている集団も一部存在する.それは最近流行りの言葉で言えば,サイコパス教授だ.学生ポスドク助教そのすべてを人間として扱わず自分出世or地位or名誉のために利用する.そのため,この劣悪な日本環境の中でもそれなりの成果が出る.その業績を元手に,大型予算が当たる.更に悲劇が拡大する.私の少ない知り合いである若手研究者と話しただけでも,医学系や生命科学系,工学系(の中のどの分野でも),農学系.どこにでもいる.比較若い分野である情報/計算機科学にもいる.

最近の若手研究者は目が死んでいる.最近医学の発展により,これらの教授寿命は長い.国立大退官後も院政を引いて分野内で君臨する.偉い先生基調講演をさせるためだけの謎のシンポジウム企画される.下々の者が奔走する.ポスドク助教が偉い先生パワポをつくったり,大型予算提案書や報告書をつくったりしている.そして,外部向けには「うちのラボ生産性の高さの秘訣は若手研究者自由環境を与えることです」みたいなことを言っちゃう.若手研究者マジで国外研究機関に行った方が良いと思う.

ちなみに私は,飲み会の場で(直接の上司ではない別の教授に)口が滑って,「海外大学で働きたいっすわ.研究だけしたいっすわ.(研究上ではない上司の尻拭いの)雑用もう嫌っすわ」と言ってしまい,(直接の利害関係がない)その教授にブチ切れられた.いま思えば,自分がそういうことをしたら,周りの若手が真似をする負の外部効果があるからだろう.

海外大学研究者と話すたびに「日本大学ってなんであんなにヒエラルキー構造なの?バカなの?死ぬの?」と言われる.そのたびに儒教の影響じゃないっすかねと言っている.(とはいえ,私はよく知らないが,バイオ化学であれば,海外ラボも完全なヒエラルキー構造なのだろうと思う)

念のために書いておくと,私は海外大学で働くことを決めた.じゃあ,いいじゃんと言われるかもしれないが,自分母国に愛は当然あるし,母校にも愛はある.なので,国内大学の質が上がったり,生産性が上がることは素直に嬉しい.どうにかしたいとは思う.が,個人の力でできることは本当に少ない.ただただ悲しい.

2017-01-18

プログラミングって「得体がしれない」よな

プログラミングって、これから始めてみようっていうとき、なんだか「得体のしれない行為」っていう感覚がありませんか?

ぼく自身は、プログラムを書いてる側の人間で、いまでこそ少しはプログラミング本質的な難しさをわかってる気になってます。でもつい数年前までは、プログラミングは難しくはないけど得体がわからない、という感じでした。

そのへんのコードを組み合わせて動くものはできるけど、何がどうなっているのかは知らんし、ググって分からないものはできない、という方向で、「プログラミングは難しい」と思ってました。

最近になって、プログラミング義務教育必修化の話題とか、コピペプログラマー話題とかを目にするたびに、かつて自分プログラミングに対して抱いていた「得体のしれない行為」という感覚が思い出されてしまい、少しざわざわした気持ちになったので、ちょっとここに書きなぐらせてください。

だいたいが個人的な話なので、そういうのがうっとうしい人は無視してください。

ぼくが世の中にパソコンという道具があることを知ったのは、たぶん中学生ときです。30年くらい前。当時、電気屋の売り場ではけっこうな床面積を使ってワープロ文章入力する専用マシン)が陳列されてました。文章を書くのは好きだったけど、字を書くのが死ぬほどめんどくさかった自分は、ワープロさえあれば自分小説とか書くのになあと思いながら指をくわえて電気屋の店内をうろうろしてました。しかし、ファミコンすら買ってもらえなかった家計ではワープロなんぞ買ってもらえるわけもありません。そのうち巡回してた電気からワープロが消え、それに代わってパソコンのコーナーが広がっていきました。このパソコンというのは、よくわからないけどワープロとして使えるっぽいし、どうやらファミコンを持っていない僕にもゲームができるらしい、おれに必要なのはこれだ、というわけで、中学生だった自分パソコンという存在に興味を抱くようになったのでした。

はいえ、だからといってパソコンを買ってもらえるような家計ではなかったわけなので、カタログを熱心に眺めるだけの毎日が続きました。その当時の自分にとって、パソコンが欲しいといったら、それはNECを買うかエプソンを買うかという選択でした。冨士通からパソコンが出ていることは知りませんでした。マッキントッシュっていうやつもあって、このPerformaっていうやつはなぜか安いとか、よくわからないけどシャープとかソニー独自パソコンを作っているぞとか、そういう情報パソコンに対する認識のすべてでした。当時の自分にとってのパソコンは、電気メーカーから発売されている商品一種であり、ラジカセとかテレビと同列の存在でした。

なんでこんな話がプログラミングにつながるかというと、ひょっとして自分プログラミングにずっと感じていた「得体のしれなさ」の源泉の一つは、こんなふうにパソコン電化製品として見ていた当時の感覚の延長だったのかもなあと思ってるからです。

ラジカセなら、CDだのテープだのを入れて再生タンを押せば、そのハードウェア機能物理的に体感できます。それに対してパソコンは、プログラミングちょっとやってみても、その行為と、そのハードウェアとが、感覚的に結びつきません。もちろん、プログラミングというのは、物理的なデバイスに結びつけて考えなければできない行為ではありません。しかし、パソコンを「カタログ商品」として見るところから入ってるばかりに、そこでやるプログラミングという行為ハードウェアとの結びつきが見えにくい状態に、なんとなく居心地の悪さを感じていたように思うのです。

もし自分スタート地点が、パソコンを使って文筆やゲームをするところだったら、パソコンは文筆やゲームのための箱だったでしょう。その後でプログラミングを始めていたなら、プログラミングという行為を、文筆やゲームに関連した創造的な活動として学べたかもしれません。

ところが実際には、自分はつい数年前まで、パソコンという電化製品に対する漠然とした行為としてプログラミングを捉えてた気がします。

プログラミングを始めたのは、高校生になって誰も使わないFM77が部室に置いてあったので立ち上げてみたらF-BASICインタプリタが起動したからでした。とくに何をプログラミングすればいいかもわからなかったので、教科書雑誌コードを転記したり、ループで線画を書いたりして遊んでいました。大学に入ってからも、授業でFORTRANとかLispをやらされたけど、基本的自分目的をもってプログラミングするのは数値計算くらいのものでした。そのころになると、本で情報を探して(まだインターネット検索は使い物にならなかった)適当コードをつなぎ合わせるのがプログラミングだと思ってました。そんなん面白くないなあ、とも思ってました。

この感覚、完全に、いま揶揄されているコピペプログラマーのそれだったと思いますちょっと話はそれますが、ブロック遊びとか砂場遊びって、ほとんどの人はわりとコピペプログラミングと似たような感覚でやってるんじゃないでしょうか。パーツを勘で組み合わせたり、とにかく砂を盛っていったりすれば、家みたいなのができるよね、という感覚プログラミングは、自分にとってそれに近い作業でした。学生のころは、内心、自分にもパソコンサンプルコードさえあれば何かすごいものを作れるかもなあ、くらいに思っていたふしもあります

自分バカでした。パソコンがあるとかないとか、関係ないのです。パソコンさえあれば、なんて思う者に、本当のプログラミングがわかるはずがありません。

そんなこんなで、自分はまともにプログラミング経験しないまま社会人になったわけですが、幸いにもプログラミングに対するこの感覚は、仕事パソコンを日々使うようになってから徐々に変わっていきました。

具体的には、パソコンが、自分の中で「カタログ商品から武器」へと変わりました。それと同時に、プログラミングという行為が、武器開発という位置づけになりました。

武器というのは言い過ぎだとしても、ちょっとしたプログラミングは確かに業務上課題を打開しました。それなりに計算機科学教科書を読んで勉強をしたこともあって、いつのまにかプログラミングに対する「得体のしれなさ」も解消してました。

結局のところ、自分にとっては、プログラミングという行為の「得体のしれなさ」から解放されるまでにずいぶん長い時間必要だったことになります自分がそうだったからといって他人もそうだとは限らないですが、たとえば小学校で形だけプログラミングを教わっても、分かるとかわからないとか、好きとか嫌いとか以前に、なんかモヤモヤした気持ちになるだけの子もも少なくないんだろうなあ。それは不憫だなあ。

かといって、自分がいまプログラミングで少しは戦えてるのは、そのむかしパソコンに憧れがあって、得体がしれないなりにプログラミングをする機会が若いときたまたまあったからでもあるので、そういう機会になるなら小学校で形だけでも教えるほうがいいのかなあとも思います

オチがないので、このへんで。

2016-06-17

Winnyは悪だろ

Winnyはもう今は誰も使ってないツールだ。

作者である金子氏が故人となって久しい。

彼の早すぎる死は日本計算機科学界の大きな損失だが、それでもWinnyは結局、悪だ。

Winnyについての話題になると、必ず出てくるのは包丁の話だ。

結局使う者の責任だという、あれだ。

しかWinnyはそれとは違う。

彼が2ちゃんねる47氏と呼ばれていた頃のレスを見れば明らかだ。

次世代WinMXとなる為、権利侵害された著作物児童ポルノを、より広く安全に共有する為に作られたのがWinnyスタートだ。

彼は裁判無罪を勝ち取った。

しかし、だとしても彼は悪意をもってWinnyを作りバラ撒いたのは事実だ。

その悪意が、単に法の裁きを受けない性質のものだったというだけだった。

結局彼は死によって悲運な天才となり、全てを肯定された。

しかしだとしても、少なくともWinnyは悪だったのである

俺は彼に生きて欲しかった。

長く生き、年老いた時に実はあれは悪だったと認めて欲しかった。

お尻ぷりんセスより

2015-11-17

http://anond.hatelabo.jp/20151117013512

プログラミング世界では semantic に構文的という訳語を当てることになっているのか」

これは単純ミスかな…。計算機科学において意味(semantics)と構文(syntax)は明確に区別される概念。そもそもSchemeとAlgol 60が構文的に似てるとは思えんし。

2015-07-22

http://anond.hatelabo.jp/20150722001956

競技プログラミングというより、計算機科学実践できるかどうかを問うているんだと思う

全員が計算機科学を修めている必要がある業界はあまりないと思うけど、

計算機科学の知見が足らないと不合理な状態に陥りがちなのでは、とも思う

2015-05-27

拝啓 岡部健

以下のエントリ、読ませて頂きました。

関数型プログラミングと私の著書の正確性についてきちんと議論(論争)します。

http://kenokabe-techwriting.blogspot.jp/2015/05/blog-post.html?m=1

私は岡部健様の学説にいたく感銘を受けております

匿名ダイアリーなど読まれていらっしゃらないかも知れませんが、もしお目に止まりましたら一読くださるよう、お願いします。

また、昨今の岡部健様への風当たりや今後の研究活動について、一つの方針を具申致しとうございます

まず、岡部健様は、今ネット上で繰り広げられている論争に、一切反論をするべきではないかと思われます

なぜなら、岡部健様のご高説は全て正しいものからでございます

しかし、時代の先を行き過ぎていまして、それが正しい形を持って具現しないだけでございます

丁度、チャールズ・バベッジの階差機関が当時の技術で実現できなかったのと同じでございます

100年、200年先において、岡部健様の学説が再評価され広く普及することは間違いのないことでございます

しかすると20年もしたら、どこぞの権威のある学者岡部健様の理論を再発明するかもしれません。

権威主義に取り憑かれた凡骨どもの目が覚めるまで、慈悲の心を持って辛抱強く待つ必要があるかと思われます

言いたい奴には言わせておけばよいのです。

最後に逆転することは目に見えているのですから、何も今躍起になる必要などないではないですか。

ですので、岡部健様の学説により一層の磨きをかけることに尽力するのが人類未来のためであるかと具申いたします。

また、一プログラマとして、益のない批判合戦よりも、岡部健様が岡部健様だけに見ている『論理』の世界について、

一言でも、一文字でも多く語る姿を見ていたく思います

では、なぜ岡部健様の学説が正しく聴衆に伝わらないのか、愚考しましたので申し上げます

岡部健様の見ている『論理』の世界は、完全に、全て、オリジナルのものであり、

アリストテレスデカルトスピノザも、誰も手に入れることのできなかった、真なる物の中の真、究極の真理だからでございます

それを表現する言葉は『イデア』でも『遅延評価』でも『関数』でもなく、完全にオリジナルな物でございます

人類は未だかつて、岡部健様の頭の中にある理論体系を記述する言葉を持たないのでございます

ですので、既存計算機科学における、全ての専門用語を省いた言葉で、全く新たに理論を書き上げて頂きとうございます

誤解を恐れず申し上げれば、岡部健様の提案するプログラミング手法関数型プログラミングではございません。

これは、岡部健プログラミングでございます

プログラミングという言い方も正確ではございません。

岡部健型の真理の記述法とでも呼ぶべきものでございます

なぜなら、プログラムとは「現存する計算機をいかに利用するか」の利用方法を記したものからです。

岡部健様の提唱する理論は、そのような矮小適用範囲に収まらないかと愚考いたします。

現在計算機科学が、現存する計算機をいかに利用するか、などという、矮小範囲に留まっている限り、

岡部健様の見ている世界を、この世に具現化することなど、夢のまた夢でございます

ましてや脳の血の巡りの悪い、権威主義者どもを啓蒙するなど。

ですが、プログラムには岡部健様の理論の一部が顕現しているものと愚慮いたしております

それは、形式的言語である、というただ一点のみにてのことと思います

岡部健様のご考案なされたspinozaもその一つかと思われます

しかしそれも、現存する計算機上で動かなければならないという、極めて瑣末な事情により、

岡部健様の思考を完全に書き下すには、全く不十分なものになっているかと、愚慮愚考いたすものでございます

ですので、岡部健様には、現存する計算機上で動くことを前提としない、全く新しい形式言語をもって、

問題論理』を書き下す手法をご教授願えないかと、お願いするものであります

そうすれば、必ずや岡部健様の学説は後世に評価されることと信じております

重ね重ね、この蒙昧な具申をお読み頂き、感謝いたします。

少しでも偉大なる岡部健様のお力になれたらと、その一念にて出過ぎた真似を致しました。

しかし、これは偽らざる私の本心でございます

どうかお心苦しくなららぬよう、お願い致します。

2015-01-28

http://anond.hatelabo.jp/20150127003906

http://anond.hatelabo.jp/20150127035153

この件、はてな民向きには「計算機科学におけるニセ科学トンデモ案件」と言えば通じるんじゃねえかな。

実際、苦言を呈してた人たちの中にはその分野の専門家研究者が少なからず含まれてる。

相対論とか量子論に湧いてくるようなアレなんだよ、要は。

関数型言語ユーザー)に難アリみたいな反応はちょっと悲しいなあ。

2014-05-13

http://anond.hatelabo.jp/20140511211552

F欄卒の社畜男子です。私も数学勉強中です。

1) 極限と微分

AAが好きなら以下をどうぞ。楽しく読めると思います

http://yaruomatome.blog10.fc2.com/blog-entry-371.html

2)積分

微分の反対と言われますが、よくわからないと思います。残念ながら上記のスレッドにも出てきません。

わかりやすい説明を以前どこかで見たのですが、忘れてしまいました。

3) 行列

xとyの方程式を別の書き方で表したものです。

http://www.eisaijuku.join-us.jp/renritu-houteishiki-no-gyoretu-kai.html

4) なぜ必要

いろいろ意見があると思いますが、工学するためだと思います

微分形式、積分形式で表せる現象は現実世界にとても多いです。

逆に工学しないなら、あまりいらないと思います

工学けが理系じゃないし、確率に興味が出れば統計学の方に進み、

計算機科学に進んでも面白いと思います


ようはなんとなくわかればいいんです。

2014-03-25

http://anond.hatelabo.jp/20140325220012

ウェブ以外のものも急速に簡単になっていくとおもう。

これも増田の言う通りですよ。

計算機科学とか数学とかアセンブラがどうとか、

あんまり関係ない話だと思うんですけど・・・

「難しいことを簡単にすることがお金を儲ける一つの方法」で

あることは間違いないです。

ただし、「その難しいこと」、が

需要が少ない場合、もしくは、技術的に本当に難しい場合のみ、

なかなか簡単になりません。

ということは、

自分需要が多いと思う、のであれば、または

自分ならば技術的に難しくない、と考えるならば、

それは立派なビジネスチャンス、ということですね。

http://anond.hatelabo.jp/20140325221535

君その何も分かってないのに思い込みだけで断定して論を進めようとすんのやめろ。

計算機科学の基礎なり数学の基礎なりを少しは勉強してみてから口を開け。

2013-10-26

http://anond.hatelabo.jp/20131026142229

いやD-waveマシンは実際に販売されてるから

その程度も理解してない人間は「あらゆること」なんて言っちゃだめだよ。

その調子だとラムダ計算とか圏論とかの計算機科学の基礎すら怪しそうだな。

「あらゆること」なんてぶち上げるくらいだから流石にその程度はマスターしてるんだろうと思って触れなかったんだけど。

ちなみにクリフォード代数とかconformal algebraとかは分かってる?

CGとかやるとき結構重要なんだけど。

2013-07-04

計算機科学学問じゃない

http://anond.hatelabo.jp/20130703205623

知り合いの話を聞いた感じでは、計算機科学研究って数学基礎論二次創作みたいな感じなんだな。

なんかのロジックについて延々論文を書くだけで研究になるんだから

少なくとも学問じゃないよね。

別に趣味ならいいけどさ、国の金もらってやることか?

税金二次創作やるって恥ずかしくないんだろうか?

生きていることが恥ずかしくなったりしないんだろうか?

金回すべきところは他にいくらでもあるだろ。

まああの人たちは、本質()とか真理()とか分かってるから世界が違って見えるんだろうな。

幸せそうで羨ましいことだ。

2013-04-30

http://anond.hatelabo.jp/20130430233611

その中でも数学なんて食えない筆頭だろ

数学金融でも保険でも使われてる。

計算機科学やその他の工学の基礎だし、社会科学でも欠かせない。

純粋数学でも、暗号理論のように巨額の富を生むことがある。

女は現実的なのでそういうのを好まない、同じ学ぶなら「手に職」を付けられる実学を好む

それだと、文学部や国際関係女子人気が説明できない。

2013-03-28

科学技術計算Python

科学者必要とするもの

必要ものの列挙

現存する解法

どの解法が科学者にとって役に立つのか?

コンパイラ言語:C, C++, Fortran, 等
スクリプト言語Matlab
他のスクリプト言語Scilab, Octave, Igor, R, IDL, 等
Python はどうなの?

2013-03-26

http://anond.hatelabo.jp/20130326050224

プログラミング出来ない奴ちょっと来い」http://anond.hatelabo.jp/20130322031333

う~ん、この人の日記意見は、駄目だな~

特に駄目だと感じるのは、

「というのも、多くの人は計算機科学を学び、効率のよいアルゴリズムデータ構造、美しい階層化・モジュール化されたプログラム

などを作るためにプログラミングするのではない。

目の前の問題を解決するためにプログラミングを行うからだ。」

学んだ計算機科学の知識や、効率のよいアルゴリズムデータ構造、美しい階層化・モジュール化は

「手段」であり、「手段」として使いこなせないならプログラマーじゃないね

あと捉えている「上級者レベル」が低すぎ。

2013-03-22

プログラミング出来ない奴ちょっと来い

プログラミング出来る方法教える。

世の中「プログラミング言語」を説く本はごまんとあれど「プログラミング」を説く本やブログはあまりない。

いや実際に "ない" というのはかなり語弊があるかもしれない。

しかし、通常この種の説明している本に辿り着くまでには多くの時間必要だ。

普通の人は、多くの間違った方法を試し、その都度試行錯誤を重ね、プログラミング経験を経ることよって、重要概念を獲得するのだと思う。

例えば、「計算機プログラム構造解釈」や「実用 Common Lisp」、「コンピュータプログラミング概念技法モデル」などの書籍現実の問題に対し "プログラム" をどう書くかという問題に正面から取り組んでいる良書だ。

しかし、どれだけ”普通の”プログラマが上記のような書籍を読んでいるのだろうか。

そして、"普通プログラマ" がプログラミングを学ぶ書籍として、それらは果たして適切と言えるだろうか。

僕はそうは思わない。

というのも、多くの人は計算機科学を学び、効率のよいアルゴリズムデータ構造、美しい階層化・モジュール化されたプログラム、などを作るためにプログラミングするのではない。目の前の問題を解決するためにプログラミングを行うからだ。

それは自分の作りたいアプリだったり、

クライアントから発注されたプロジェクトだったり、

上司から頼まれた仕事だったり、

業務を効率化させるための Excel マクロだったり、

授業で出された宿題だったり、人それぞれだろう。

このような目の前の問題を解決したい人達が、わざわざ LispMozart など何の役に立つのか分からない言語を、根気よく勉強するのだろうか。(ちなみに、LispMozart は上記の書籍で実際に使われている言語である。)

目的現在の問題を解決することであって、

新しいプログラミング言語を学ぶことや、プログラミングの種々の概念を獲得することではない。

もちろんプログラミング言語を上達するためには一つでも多くの概念を会得する必要があるので、あるレベル以上を目指すのであればこれらの書籍を読むことや、抽象化を実現するための様々なツールを手にすることは必須だと思う。

純粋プログラミングを楽しんでいる人やハッカーを目指したい人はこのような文章を読むのではなく、ぜひ上記に挙げた本を実際に購入し、自分の手で動かして確かめてみることを勧める。プログラミングに対する考え方や姿勢が変わるのは間違いないと思う。

今回はそのような”純粋プログラミングを楽しんでいる人”に向けた文章でない。

現実の問題をプログラミングを用いて取り組んでいる人に向けて書いた文章だ。


そのような人の中で、なかなかプログラミングが上達しないという人に向けた文章である

もしプログラミング学習限界を感じているのであれば、プログラミング学習方法が間違っている可能性が高い。

そして残念なことに、初学者向けの書籍では、"プログラミング言語の文法" を説く本はあれど、"プログラミング学習方法や上達するための正しいスタンス" を説く本はほとんどない。


できるだけ多くの人にプログラムをする楽しみを知ってもらうためにも

より多くの人がより生産的にプログラムが出来るようになるためにも

そして特に、右も左も分からなかったプログラミングを始めたばかりの過去自分に対して、

効果的な学習方法プログラムする際の指針を書き記したいと思う。

それらは単に指針を示しているだけなので、

どんなプログラミング言語を使っていようとすぐに実践に移せるはずだ。

後はどれだけそれを実践に移し地道にプログラミングしていくだけである

正しい努力と、ちょっとしたコツさえ知っていれば驚く程生産性を挙げられるはずだと確信している。

プログラマレベルを以下の 3 つに分けてそれぞれについて説明していきたい。

1. 初心者レベル

プログラミング半年未満

・使えるプログラミング言語は一つだけ

ただし以下のことは出来ない。

・500行以上のコードが書けない

エラーが出た時の対処方法が分からない

写経は出来るが、自分プログラムが書けない

2. 中級者レベル

プログラミング半年 〜 3年

・1つ以上のプログラミング言語は使える

オブジェクト指向は理解している

ただし以下に当てはまる。

自分制作しているアプリケーション向けに "実用的なフレームワークライブラリ" を書けない

・1万行以上のコードだとスパゲッティコードになり、保守不能になる

・重複するコードが多く存在する

・適切なサブルーチン化できない

3. 上級者レベル

プログラミング歴 3 年以上

現実の問題に対して適切なデータ構造アルゴリズムを選択できる

抽象化について理解し、可変部分と不変部分を考慮した設計ができる

全てのプログラマはどれかのレベルに属するはずである

またそれぞれのレベルクリアするには明確な壁がある様に思う。

これらの壁を超えるにはどうすればよいかを説明する。

前置きが長くなったが、以下ではまず初級者レベルの人に向けた具体的なアドバイスをする。


初心者レベルの人に向けて

完全に初心者レベルの人はまずどのようにプログラミングを行えばよいのか分からない。一行も書けない。そのため、必然的に以下のような行動を取ると思う。

検索エンジンで似たプログラム検索コピーペーストする

・本に載っているプログラムをそのまま書き写す(いわゆる写経

上のような行動を行なっているだけでは、いつまで経っても自分プログラミングが出来るようにならない。

なぜなら上記のプロセスでは決定的に重要なことが学べないからだ。

それは、【プログラミング言語モデル】を自分の中に作ることである

プログラミング言語ルールの塊である

それは普通言語と同じように文法が存在し、そのしきたりに沿って記述しなければならない。

のしきたりを学べば書けるようになれる。非常に単純だ。

それなのに、なぜいつまで経っても書けないのか?

それは、”書き写す・コピーする” だけでは、そのしきたりが習得できないかである

特に最初のうちのプログラミングは頭を作業使う作業でなく、むしろ "体で覚える" 類のものである

それは例えば、日本語を話すことと似ている。

友達と会話する時、頭を使っているだろうか。

それは簡単な受け答えについては体が覚えているので、考えるより先に日本語が出てくるのではないだろうか。

プログラミングも同様に頭を使うのではなく、こうしたい時はこう書く、という反射神経を育てなければならない。

もちろん日本語話せるだけでは、ミーティングプレゼン出来ないのと同様に、文法が出来ただけではプログラミングが出来るとは言えない。しかし、文法が出来ないと "現実の問題に対処するソフトウェアを作る" というレベルには到底進めない。そのために、まずそのような文法の反射神経やパイプラインを頭の中に作る必要があるのだ。

それには以下の点を意識してプログラミングすればよい。

・"何をしたい時" に "どう書けば正しく動くか" というデータベースプログラミング言語モデル)を自分の中に作ること

このままでは抽象的すぎるので、このような "データベース" や "考える習慣" を自分の中に作るための具体的な指針を以下に挙げる。

1. エラーをたくさん出す

2. デバックの仕方を覚える

3. 小さく動かして確かめ

4. Google を使い倒す

まり、小さく動かして、エラーをいっぱい出し、デバッグを素早く行なって、分からないことは google などの検索エンジンで解決する。これが上達のコツである


これらについては以下で詳しく説明するとして、

まず最初初心者ありがちな間違いをいくつか列挙してする。


関数メソッドをたくさん覚えなければいけない

無理して覚えなくてよい。

プログラマは覚えることが星の数ほどあるので、メソッドなどはリファレンス片手に検索できればよい。

よく使うメソッドなどについては自然に覚えていくので、積極的に覚える必要はなし。それこそ、"体" で覚えるはずである

覚えられないメソッドについてはそもそもあまり使わないから覚えられないので、重要性は低く覚える必要はない。

しろ実現したい処理が既にメソッド関数として提供されていないか、調べる力の方が大事

エラーがいっぱい出てつらい

全く問題ない。

以下で述べるようにエラーとどう付き合うかが非常に重要

写経をしなければならない

教科書や本の中に書いてあることをそのままエディタで書き写し、実行することを写経という。

上記でも述べたように、これからまり無駄努力をしないことを願って言えば、

写経にはほとんど意味がないと思って取り組んだ方がいい。

写経して書いた 10000 行のプログラムより、自分で考えて書いた 100 行のプログラムの方が遥かに意義がある。

なぜならば写経は "作業" だからだ。

そこに "言語モデル" や "思考" が伴わないと意味がない。

”思考” が伴わないとただの書き写す作業をしているだけだ。

自分の中に "モデル" が出来ていないので、いざ自分プログラミングしようと試みても、写経をしているだけでは全く書き出せないだろう。

写経はそもそもプログラミングに対するスタンスプロセスのもの勘違いさせる危険性をはらんでいるいる。

写経する場合、書き写しの間違いがなければプログラムは問題なく動く。

しかし実際のプログラムではコンパイルや実行するまで、そのプログラムが期待通りに動くかどうか、は絶対に分からない。

そして通常は一気に全てを書き上げるのではなく、まず小さなコア部分を書き、少しずつ他のコア以外の部分を書き上げながらプログラム完璧ものにしていく。

書き間違えさえなければ正しく動くと知っているプログラムを、上から一行ずつ書いていくプロセスとは正反対だ。

また、以下で述べるようにエラーが発生した場合デバッグ作業は非常に重要であるだが、そのための作法写経から学ぶことができない。

なぜならば、写経中にエラーが発生した場合教科書自分で書いたプログラム間違い探しをまず一番最初に行うからだ。これはプログラミングに関する作業ではなく、むしろ間違い探し絵本とにらめっこしているに近い内容である

それでは、デバッグ方法言語モデルを作るとても大切なプロセス経験できない。

ゆえにそのようにして完成したプログラムもおそらく正しく動きはするが、得られる経験値は驚くほど低いはずである

とは言え、いきなり自分で書けと言われても書けないと思うので、小さなプログラムを一旦は教科書通り写し、その後自分なりに改変していくのがよいと思う。この場合写経にはほとんどが意味がないと思った方がよい。"自分なりに改変する" というプロセスこそ意味がある。

さて初心者が陥りやすい部分については説明したので、

今度はどのように "言語モデル" を自分の中に作っていくかについて説明する。

1. エラーをたくさん出す

初心者エラーを出さない様にと慎重にプログラミングしようとしがちだ。

はっきり言うと、それは間違ったプログラミングスタイルだ。

特に最初のうちは、エラーをなるべく多く出した方がよい。

なぜならば、エラーを出すごとに、その言語の新しいルールを1つずつ学んでいくことになるからだ。

PHP で例えると、

printf の書式だとか

文末に付けるセミコロンだとか

function はネストできないとか

変数には $ を付けなければならないだとか

グローバル変数関数の中で使う場合は global 宣言するとか

などである

初心者のうちは一切上のようなルールは知らないはずだからエラーを全て踏むかもしれない。

例え今回作っていたプログラムエラーを踏まなかったとしても、回数をこなしていけばいくつかエラーに遭遇するだろう。

しかし、それでよいのだ。

エラーを修正することの繰り返しの中で、その言語モデル自分の中に出来てくる。

そのようなトライアンドエラーを繰り返えすことで、"言語モデル" は文字通り体の中に染み込み、プログラムだんだんと書ける様になっていく。

おそらくこれはは自転車に乗れるようになるプロセスと似たようなものだと思う。

誰しも最初は上手く走れずに転んでばかりいるけれど、何度も何度も転んで起き上がってを繰り返しているうちに少しずつ多くの距離をこげるようになっていくだろう。

そして最終定期には、難なく自転車を乗りこなせるようなっている。

プログラミング言語を学ぶ時も同じである

最初は何度やってもいろいろなエラーが出てくる。

それらのエラーを地道に1つずつ潰して間違いを訂正していくうちに、少しずつ多くの行数の複雑なプログラム書けるようになっていく。

そして最終的には、自由にプログラミング言語を使いこなせるようになっていることに気付くだろう。

自転車も本を読んだだけで乗れるようにはなれないのと同じで

プログラミング言語も本を読んだだけで出来るようになれると思わない方がよい。

それらはトライアンドエラーの繰り返しの中でしか得ることはできないし、誰かから教わる類のスキルでもない。

そして、プログラミングを行うからにはエラーとは一生付き合っていかなければならない。

早めにそれに気付いて受け入れる必要がある。

2. デバッグの仕方を覚える

さてエラー重要性については上で強調した。

実際にエラーに遭遇した時に大事なのはエラーに遭遇した時にいかにその原因を突き止めるかだ。

期待しない動作をした時のデバッグという。

まずいちばん基本的で一番重要デバック方法printf デバックである。これをまず出来るようにする。

怪しい変数をとにかく printf で出力し、変な値が入っていないかを確かめ方法である

僕が常々許せないと思っていることは、初学者向けの書籍にはデバッグ重要性やその具体的な方法論が非常に重要であるにも関わらず、それについては解説すらされていないことである

初心者からこそ、デバッグ方法論や開発環境をきちんと整えるべきである

ほとんどの言語処理系では、デバッグ作業を支援する機能提供している。

からなければ、"言語 デバッグ方法" でグーグル検索してみればよい。

例を挙げると、

C言語だったら、gdb

PHP だったら Xdebug

Ruby だったら pp モジュール

Schemegauche)だったら #?= デバッグ

javascript だったら firebug

言語はいわゆる"定石"と言われるデバッグ方法があるはずで、それらを検索し習得すること。

これは無益時間を過ごさないためにも本当に重要な要素なので、面倒くさがらずに開発環境を整えや方法論をマスターすること。


3 小さく動かして確かめ

最初の内は、基本的にプログラミングする時は小さな部品に別けてから1つずつ確かめながら作る習慣を付けるようにする。

その理由は簡単で、人間は正確無比に物事を進めるのは苦手な一方で、プログラミングでは正確無比に物事を進めることを要求されるからである。そのため、大きなプログラムを一度も実行せずに作成し、一気に確かめようとするとまず間違いなく正しく動作しない。

そして厄介なことに、大きなプログラムを作ってしまうとどこに問題があるのか切り分けすることが困難になるので、ますますデバックが難しくなってしまう。

そのためまず小さく作って小さく確かめ部品を組み合わせてプログラムを作っていくことが大事になる。

一般的に言って、どんなに熟練したプログラマーであろうとも、一つのミスもせずに一定以上の大きさのソフトウェアを作り上げることは不可能である。そのため、ミスエラーはある程度発生することを前提に、少し作っては実行して確かめる、というサイクルをたくさん回す習慣を付ける。

ソフトウェアは一行書き上げた瞬間から指数関数的に複雑性が増大し、気付いた時にはどうにもならなくなっていることも多い。そういう時は思い切って一から作り直すという選択肢検討してみるべきだ。

"Small is Beautiful"

これは非常に有名な unix (という OS)の設計理念である

unix開発者は様々な失敗経験から、このようなソフトウェア開発のベストプラクティスを学んだに違いない。

まだプログラミング経験の浅い人も、これから偉大な開発者経験から学ぶことができるはずである。"Small is Beautiful"。小さく作って動かすこと。


4 Google を使い倒す

先ほどから何度も書いてあるように、プログラミングする上ではエラーとの付き合い方が非常に重要になってくる。

おそらく何らかの上手くいかない場合は何らかのエラーメッセージが出るはずだ。

原因がどうしても分からない場合は、エラーの文章をそのままコピーして検索してみる。そうすると、おそらくエラーの原因と対策方法などが表示されるので、それを足がかりに再度挑戦する。




現実プログラミングは、どんなにスキルが伸びようとも、いつも上手くいかないことばかりだ。それこそ、何をしてもエラーが出てくるし、何をしても上手く動作しない。だから僕は初心者のうちで一番大事能力とは、実は "忍耐力" だろうと少しばかり思っている。

でも悩んでるのはあなただけではなく、おそらく全てのプログラマーが通ってきて道だ。

そして、自分の思い通りに動くプログラムを見た時程うれしいものはない。

ぜひ初心者の人はこれを読んで少しでもプログラミングが出来るようになればと思っている。





2012-07-15

Twitterで知り合った自称Geekの子HTMLの話をしてみたら

なぜかLINEでのやりとり。このあとTwitterでblockされた。

Ahi
Byeah
B学校祭わろた
Aおつ。
A打ち上げ的なものはないの?
Bない
B学校祭中
Aああ、把握。わろたがおわたに見えた。
B学校祭ェ••••
Bパソコン部の展示なう 誰もけえへんやん
Aなるほど
Bパソコン部だけ学校雰囲気じゃねーww
Aそんなもんや…
Bあっちで音ゲー こっちでぽけも
B君もパソコンかい
B友達こねーくそわろ
Aんにゃ、高校のときは※※と〒〒やってたねえ。
B学校祭の新しい形ですね
B学校祭なんてお客さんが楽しむもので、生徒が楽しむものではない、生徒は楽しませる側です
A僕んところの高校のパソコン部とか何やってたんだろうねえ。
ATwitterとか見てると灘校のパソコン部展示とかは相当盛り上がってたみたいだけど。
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柏葉とか〒〒強かったなあ。
BW
B 君×高?
ANo.
B俺×高www
Bわろたqwwww
B×高わろたwww
B×高わろわろわろたwwww
Aなにがおもしろいwwww
B君は?
A(そもそも高校生ではないんだけどね…)
B中学生大学生
A大学出てるよ
B出身高どこ?
B北海道ではないの?
A△△。
Bもれ札幌×高。知ってる?私服やで!
B△△?
A私服やで。
B△△高校??
Ayes.
B▲▲系?
Aとは
B画像
B偏差値67わろた ●●県かー
Aそれ●●の男子校な。
A●●の△△はたぶん私服じゃないぞ
B●●神やな
B何県?
A△△市知らんのか…
B画像
Bしってるで!
B理数科?
A普通
Bなんで私服
B
Aなんでって言われても、校則制服がないからだけど。
Bわろた
Bこの話やめよ
A( なんでいきなり学校の訊問から始まったんだ…? )
BHtmlの話にかえよう
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でだ、そこで
AHTML5って何?
Bなんや
Bテキストを超越したもの創造するための道具
ANo.
Bなんや
Bプログラミング言語
Aそういう名前の「マークアップ言語」ってだけの話なんだけど。
Aプログラミング言語ちゃうねん。
Bしっとるわ
Bでいいたいことは?
B要旨はなんや
Aマークアップ言語」ってことが重要
Bはい
Bそれで
A言語であるからには規格があって処理系がある。
Aってことはおk?
Bうん
B規格?
A規格。
B処理系? 説明せぇ言われても説明できない言葉やわ
Bおしえで
Bおしえてー
A要するに、"print A" って文字列を与えたら "A" って出力するような仕組。
Bそれが処理系
Bきかくは?
Aざっくり言うとそう。
A言語言語として成立するための決まり
Aさっきの例だと "print A" なら「Aを出力しろ」という命令であるべし、みたいな。
AHTML場合は基本的には要素と属性定義になってる。
Bあーわかります
Bいえーす
A要素と属性おk?
Aelement と attribute 。
B要素 属性width height
Aおk
B 要素が親 属性が子
Aそれはちゃうねん。
Bじゃあなんや
Aでもそれは脇道だから置いておく。
Bいいす
Bいえす
Bそして
Bから
Bからの?
Aてっとり早く言うなら、HTML5定義されてる要素の集合に font や center は入ってない。
Bふむ
A集合は?
Bじゃあそれらはなんや
Bドモルガンの法則
B要素の集まり
Aおkおk。問題ないね
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しすてむ
Anice
B入力に対して応答する仕組み=処理系
A日本語の「系」は "system" に対応する。
Bおつす
Aで、HTMLを与えて、それをよしなに処理してくれるシステムって何?
B処理系
A具体的には?
BHtml処理系
AHTMLの有名な処理系は何?
Bhtml5
Aそれは規格。
Bやー
Bこんぱいらー?
Aコンパイラ処理系
A(の一部
BHtml処理系なんや
Bコンピュータ
A大雑把すぎる
Bcpu
Aノー。
Bめもり
Bなんやねん
Aノー。
BOs
Bweb
Bブラウザ
AiPhoneにもWindowsにも処理系が入ってるからWebが見られる。
A正解。
Bプレインストールされてすか
Aされてるね。
Bなるほどね
AHTMLの有名な処理系は何?」の模範解答は InternetExplorerとかMozilla FirefoxとかOperaとかGoogle Chromeとか。
B
Aで、どうして規格を守る必要があるのか、の話。
Bブラウザ名前をあげればいいんですね
Aそれはもう終った。
Bexactly
B
B
AHTML5では文書の先頭に って書くことになってるけど、これはどういう意味か。
B宣言
ADOCTYPE宣言
A宣言してるのに規格守らなかったらだめじゃん
Aやーいうそつきうそつきー、ってことになる。
A(まじで
Bどういうこと
BDoctype宣言してんのにcenter、fontを要素として使うのはだめだということですか?
AHTML5の」宣言してんのにcenter、fontを使うのはだめー、ってこと。
Bへー
AHTML 4.01 Transitional とかならおk
B規格守らないとどういう弊害が?
Aおkだけど、なんでそんな古いの使ってんのや、ってことになる。
Aあらゆる意味でめんどくさい。
B
B規格守らないと誰か困るの?
Aユーザも困るし、処理系を作るひとも困る。
Bなんで?
A困ったちゃんは絶滅しないから有名な処理系は古い規格をサポートし続けることになるのは確定的に顕かなんだけど。
Aたとえばちょっと処理系自作しようとしたときに規格を守ってない文書に当たると、例外的な処理をしなければならなくなる。
B新しいhtmlの規格がでても 古いバージョンサポートをやめられないのですか
Aそんなことをしたら、君のページを表示できるブラウザがなくなるよね。
A(HTML5サポート外の要素を使ってるから
Bなるほど
Bcenter、fontに変わる要素はなんや
B何を使えばええんや
Aそもそもそれを要素で指定するのがナンセンスである、って話になってくる。
Aまり中央揃え」とか「フォント」とかって意味の要素がナンセンス
B最初Css使ってたけど他人のコードよんでfontていうやつ見つけたんで使ってみた
A「他人のコードよんで」←まちがい
Bcsscolor: ;
A「規格書を読む」←せいか
B辞めてfont color使うことにした
B他人のページのソースコード読んででええやろ
A赤の他人はだいたい間違ってる
A(僕の言ってることも間違ってる可能性があるから規格書を読むべき
Bなんや
B表現が間違ってるわけじゃねぇんだよな
Bそういえや
B規格書をよめってことか
A暇なときにね
Ahtml5.jp とかで良い。
Bweb
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なんの?
ASICP
B親が生活費だしてんこ
Bだしてんの?
Aんにゃ、自分お金でだけど
Bふりーたーか?
Bアルバイトはしてる?
Aないない。アルバイトなんてしたら自宅を警備できないしね。
Aそんな大人になっちゃいけない
B自分の金てなに?お前が稼いだ金?
Aいえーす
Bどこで?
B働いてないのに
A不思議だ…
Bお前なんやねん
B何者やねん
A自宅警備員
Bばか?
ATwitterのbioに書いてる以上でも以下でもない感じ。
Bごみ
B社会ゴミ
A少なくともいまの君よりは計算機科学に詳しい、ってことでおk?
Bおーけー
Aってことで、こんな社会ゴミなんか秒速で追い抜いてみせろ、ってことでひとつ
Bまあ俺がお前の歳だったら、お前より知識あるがな。俺×高やし、北大いくし
Aおーすごいすごい。
Aさっきの学歴を持ち出すなら北大じゃいろいろ物足りない気がするけど。
A素直に京大とか東大とか行っとけ
A北大教授京大東大ではしてない研究をしてるのが居てその分野を專攻したいー、とかなら別だけど。
A知ってる範囲の北大学生ものすごいのって、□□□□出てて高校時代から一人でばりばりプログラム書いてる、とかそんな感じだから
Bまあお前よりは高等だから
Bこめん
Bごめん
A僕より偏差値高いだろうってことは知ってるから、いまさら確認することじゃないなw
Aただ、具体名は避けておくけど、GoogleとかMSだけに優秀なプログラマが集まってると思ってるなら、それは間違ってるねー
A高学歴=優秀なプログラマ」が真なら、国内メーカーはどうしてこんな惨状なのか…
A僕がこの2年くらいで会ってきた、そこそこ多めな数の高校生とか大学生たちから見るに、優秀な高校生が良い大学入ってるってのはおよそ間違ってないね東大とか京大とか筑波とか東工大とか。
As/優秀な高校生/優秀な高校生プログラマ/ ね
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内心蔑みながらも日本未来を案じるさまは立派です。

2011-09-30

ネット業界に見る理系文系価値

現在国内外インターネット企業が頑張っている。

やっぱ技術

ただ最近の傾向として、技術力がある会社が強いなーというのがあると思う。

特にGoogleFacebook

ラリー・ペイジセルゲイ・ブリンエリック・シュミットという計算機科学スペシャリストがトップにいて、創業期から理系天才達を採用してきた。

もはや学者研究資金のために会社をやって資金を調達してるんじゃないかってぐらいのイメージ

Facebookも圧倒的な技術ですごいスピードで成長してきた

理系文系

これは愚問だし大雑把すぎるカテゴライズなので先に謝っておく。ただ、ネット業界ってやっぱ理系の人が強いんじゃないかと。

技術があってこその業界だし、そう考えると数学的思考が有利になると思う。

プログラミング数学はあまり関係ないというけど、理系の人の考え方は絶対にプラスになる。

それになんだかんだ理系の人の方がプログラミングを始めるきっかけが多い。

これらは文系自分が周りの状況を含めて実感してる。

そう思うとネット業界において文系メリットってなんなんだろう。

文系ができて理系ができないことってある?

自分上司バリバリ理系だ。

大学では計算機科学を主に学んでいた。

プログラマーとしても凄く優れている。

それなのに営業なのだ。しかもトップ。

まぁMBA公認会計士を持っていたりもするのだが、何故プログラマーなどの技術職に行かないのかという経歴と能力

彼を見ていると理系でも文系仕事できんじゃん!って思ってしまう。

文系は営業職などしかない。しかし、理系は本職のプログラマー(これも語弊はあるが)がある上に営業もできる可能性がある、と。

戻れるなら・・

自分は営業が向いていると思うし、仕事は順調だ。

しかし、自分でつくってみたいという思いもあり技術勉強している。

からかわからないが、プログラマーに凄く尊敬の念を抱いてる。

文系プログラマーもいるだろうが、やはり理系出身のプログラマーが圧倒的に多い。

そういうことを思うと、過去自分にちゃんと理系分野勉強しておけよと言いたくなる。

プログラム理系文系関係無い」「文系プログラマーもいっぱいいる」という人はいるだろうが、今回はわかりやすくそういう分け方をしてみた。

まぁ自虐的なんだけど・・ただ自分は諦めたわけではないので、これから勉強していこうと思っている。

2011-09-15

コンピュータ基礎理論ハンドブック2 形式的モデル意味論」の目次

第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. 関連する重要な文献

2010-09-30

http://anond.hatelabo.jp/20100930003333

とっくに自覚してんじゃん。仕事ってのは意味のある仕事であるうちは嘘で、単に食うための無意味仕事になってからが本当なのかもしれないね。でも、じゃあ、本当に仕事を変えてやっていけるか?給与の額にかかわらず、辛いのは変わんないかもよ。

職場に Halabi と Stevens と Rose 持ち込んでも誰もその中身には興味がない時代だよ。知識つけたって評価されない仕事が増えて苦しくなるだけだから。つまんないから ACM の個人会員になってみたけど、なんかCACMって毎号毎号計算機科学未来はあるのか?みたいな記事が1つは載ってて、げんなりして、更新、やめた。

まあ、G社が潰れて、抱え込んだ人材ノウハウバーゲンセールをやる日までこの業界進歩が止まるんだろうなと思っている。

2010-09-07

IT系とかそれ以外のスキル列挙するから何ができそうか教えて欲しい

色々教えてください偉い人。

自分で考えろってのはご尤もですが、色々な方の意見が聞いてみたいのです。

純粋Java(max5000行程度)

Struts(ver2じゃないほう)上でのJava(max2000行程度)

perl(max7000行程度)

c/c++(ちょっと)

Haskell(ほんの少し)

VisualBasic.NETじゃないほう)(ほとんど忘れた)

HTML/CSS(セマンティック厨)(HTML5勉強中)(バイトWEBデザイン経験有)

javascript(簡単なものなら)

XML/XSL自作プログラムI/Oに利用)

MovableTypeCMSとして利用。ちょっとした企業サイトレベルくらいのものの構築。簡単なプラグイン作成とかも)

Apache(セットアップと最低限の設定くらい)

Tomcat(同上)

LinuxCentOSUbuntu。セットアップとちょっとした設定程度)

IPA資格ソフトウェアネットワークデータベース

Tex論文プレゼンテーション作成

AdobeDTP製品(CS2)(雑誌編集経験有、ただし学生レベル

Oracle10g)(Bronzeレベルの知識とちょっと触ったことがある程度の経験

postgreSQL(ちょっと触ったことがある程度)

会計関連の知識(日商簿記2級)(大学管理会計をかじった)

数学系の知識(論理とか集合やらの基礎。大学計算機科学をかじった)

印刷物/WEBサイトデザイン(独学だけどそれなりに。一般人よりはそれっぽいデザインが作れるかと)

・文章/記事作成(取材→記事執筆。文章校正経験有)(随筆みたいのは無理)

漫画ゲームが大好き

2010-08-15

http://anond.hatelabo.jp/20100815183855

純粋数学にはあまり興味ないです。興味の方向は自然科学ですね。

数学の中でも解析とかそっち系の分野なので、計算機科学と相性が良い離散数学にはやっぱりあまり興味が無いんです。

2010-08-04

この学習しないとこがダメなんだな

時間か前にeラーニングで「効果的なビジネスコミュニケーション」みたいなことをちょっと勉強した。

計算機科学学会の会員権でタダだったからだ。

曖昧な言い方はしない、具体的な資料を示しましょう、そんなことを学んだ。

それからロックバンドの素敵な曲の素敵なカバーを見つけたので、いつも使ってる日記

「このカバーは見事なんじゃないかな?」

ってタイトル日記を書いたら

「本のカバーかと思った」

ってコメントがあった。

学習したことが光の速さで左から右へ抜けてますね俺。

死ねばいいのに

この嫌な思いもテキストオーディオ英語であるせいにして忘れてしまおうwww

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん