  |
はてなキーワード: メソッドとは
叩いたり、傷口なめたりは他の人がやってるから任せるとして
死ぬことですら他人に許可を求め、失敗したら死にしか辿り着かない貧弱な思考回路を形成したこの国の教育体系は、なかなかの物ではないだろうか？
12年前ベネズエラを旅した時に、全く教育というものを受けていない子供（12～16歳位）が、商店に平気で強盗に入ってきたり、観光客をナイフ使って恐喝しているのを見たし、私自身もされた。
話を聞くと、彼らにしたら、こういう事（犯罪だとは本人は思っていない）をするのは、生きるためには仕方がなくて、こういう状況にした大人が悪い。僕らは悪くない！という論理だった。
しかし、それが同じ人間という種なのに6+3+3+4年の教育で、失敗や境遇を他人ではなく自身の責任として、こんなところで死ぬ許可を得てから、消えて行くようになるのか・・・
検挙や裁判、勾留費用、被害者の弁済がかからない合理的な退場の仕方をしてくれる。
なかなかメソッド化、パッケージ化はするのは難しいかもしれないが、これこそ日本が世界へ輸出できる知的資源になりえるんじゃないんだろうか？
一部で「nanapiと家入さんが実は裏で手を組んで〜」みたいな話も出てるようだけど、それはkensuuさん本人が否定しているように事実では無いはず。それは筋の悪い陰謀論。論点はそこじゃない。
Studygift騒動でついに自分に火の粉がかかって来た途端、騒動のきっかけとなったnanapi記事の修正に走るってどうなの？それまでは知らない顔しておいて自分が批判され出すと臭いものにフタをし始めるというのは、いささか遅すぎないかと。
当時nanapiに所属していて記事を実際に書いたライター(岡田ゆかたんさん)があの時点で真相を見抜けるかといえば難しいだろう。でもStudygift問題が持ち上がった時点で、すぐに記事の信憑性について運営側は対応できたはずだ。そうすべきだった。昨日kensuuさんに火の粉がかかって、ようやく件の記事に
この記事は、事実と違うとおもわれる箇所があります。ただいま事実確認を行なっておりますので、記事の内容に関しての信憑性に関しては、保証できない状態にあります。申し訳ございません。2012/05/29
と記載されるようになったがこの姿勢について僕は仮にもメディアを運営する態度として適切ではないと感じる。
これ自分(nanapi ＆ kensuu)の保身のために修正宣告してるんだよね。ごちゃごちゃ言う奴らが現れたから修正してます態度を示しておこう！と。それどうなんだろう。Studygift騒動のピーク時に散々nanapi記事の信憑性について声が上がっていたにもかかわらず一切無視しておいて、自分に火の手が迫って来たら対応するという姿勢。僕はおかしいと思う。
何のための修正宣言？事実追求のための修正ではなく、保身のための修正じゃないか。
ごちゃごちゃうるさいネットユーザーを黙らす為の修正。そう受け取れる。
約一年ぶりに自分への言及は一言一句逃さずに反論する「けんすうメソッド」が発動しているようだけど、そんなことする暇があったら記事の中身の信憑性について調査して修正することを優先させて欲しかったというのは正直なところ。Studygift騒動においてnanapi記事が果たした役割は決して小さく無かったのだから、自分の保身よりも優先するべきことがあったのではないでしょうか。
http://anond.hatelabo.jp/20120527012755
クラウドシティに金を払ってる岡田信者だが、必死にテンプレにマジレスする。
俺は社員じゃないので、FREEex内のこととかバベルのことは知らない。できるだけ中立に書く。
・「理屈民族」、「大人ばっかり」と言いながら、中核社員が、クラウド市民を装いクラウドシティで荒らし行為、市民に責任転嫁。岡田も「FREEexは完全でも健全でもなく内部に問題のある人物をかかえ苦しんでる組織」であることを認めるが、会社の案内には明記せず。
「FREEexは完全で健全で問題のない人間しかいません」と案内として明記しているならともかく、構成員個人の問題を会社の案内として明記する必要はあるのか？
「つまりFREEexには問題のある人間しかいないんだろ」とか「問題のある人間を生みだす組織なんだろ」というのは、単なるレッテル張りで客観的な説得力はないように思う。
・「オタキングexは、働き放題」と言いながら、裏では、「何もしなくてお金だけ払ってくれる社員が一番良い社員」と発言し欺く。
実際に発言があった前提としても、「働き放題」といってぜんぜん働かせないのは明らかな問題だけど、岡田が内心どう思おうが仕事をさせてくれるのであれば、欺いてることにはならない。
発言内容についても、働く社員がいなくなれば社員を増やす活動までできなくなって、結局、金だけ払ってくれる社員すら集められなくなるんだから、常に「社員は金だけ払っていればいい」とは思っていないように思う。
・「参加している社員はすべて「大人」です」と言いながら、軽くex批判と心情を吐露した者を、「ここまで言うからには、覚悟はできてるよね？」と発言し、「お前は人様の前に出せるレベルじゃない！」と言い幽閉する。
もし、実際に発言があって、幽閉（これは比喩なのか？）まで実行したんだったら、かなり問題だと思う。知りたいから詳しく教えて欲しい。
・「岡田斗司夫がマンツーマンで指導します」と言いながら、「一部の社員以外は放置。ノウハウが身に付かない。新人はなんらやることない。」
これは放置されるような奴が悪いと思うけど。「仕事は権利」といってるくらいなんだから、黙ってれば仕事が勝手に割り振られるなんてことはないと思う。
「ノウハウが身に付く仕事」とか、「経験として役に立つ仕事」は、競争率が高くなって権利争いになるのは当然で、そのためにはつまらない文字起こしみたいな仕事をやるとか、他の社員との実力の差を示すとか、自分で工夫しないとダメなんじゃないのかな。
もし、「そういう実情を会社案内なりにちゃんと明記しろ」というのは、まあそうなんだけど、それくらいふつうわかるんじゃないの。
・「「社長」だけがちょっと偉いけど、他の人はみんなフラットで公平な立場です。」と言いながら、内部では「オタキングexは僕の独裁制だ」と明言。
これは内部どころかFREEexの会社説明会でも発言してた。別に隠してることじゃない。
「社長も社員もみんな公平」とか「社長と同じ権限を持つ人間が複数いる」とかいうのならともかく、「社長だけが優位にあって、他の人間はフラットで公平」というのは、そもそも「独裁だ」ってことじゃん。
そもそも、社員は「岡田斗司夫のやり方に従うこと」を基本として「ノウハウや経験を得る」とか「人類の苦痛を減らす」とかが目的なんだから、それが非効率だと思ったり、賛成できないという人は中にいても意味がない。だからそういう場合、岡田斗司夫はそいつをFREEexから追い出すんだと思う（追い出された奴がいるのかは知らないけど）。「自分のいうとおりに動かない奴は要らない」ってのもあるかもしれないけど、加えて、本人にとっても、他の社員にとっても意味がないし。
「婉曲するな、ちゃんと独裁だと明記しろ」というのは、これもまあそうだね。わからない人もいるし。実際、説明を極限まで丁寧に、細かくしていったらキリがないと思うけど。
・オタキングex社員が「ex入社したおかげで、1年で出世し、マンションとヨットを買い、１００年物ワインが１０００本持った」と虚偽を並べてexの宣伝（社員勧誘）。
これも事実関係がよくわからない。後半については日本語が成立してないように思う。
そいつが出世もしてなくてマンションもヨットも買ってないならともかく、それらが本当に起こっていて、それを「exのお陰」というのくらいは、別にいいじゃんと思う。ほんとにそうかもしれないし。これは、本人がどれだけ「exのお陰」というのを強調してるかによると思う。
・「岡田はいい事しか言わないから、これ以上、被害者が出ないようにしたい。」（元社員談）
・「けっきょく岡田さんに貢いだだけじゃん！って思ってしまうかもしれない。お金も労働力も提供したのに、何を得られたんだっけ？みたいな気分になるかもしれない。」（FREEexスタッフ）
「編集者と仕事がしたい」とか「他ではできない経験を積みたい」とか「人類の苦痛を減らしたい」と思っている人全員が、FREEexで思った通りのものが得られるわけではないし、
「頭のいい人の話がききたい」とか「理屈っぽく話せる相手が欲しい」とか思っている人全員が、クラウドシティで思った通りのものが得られるわけではない。
だから、その辺の誤解をさせないようなアナウンスはある程度、しないとダメだと思う。
でも、頭ごなしに「被害を受けた」とか「騙された」とか、一方的に「絶対的に価値が低い」という言い方をするのは、どうなのかなと思う。現に、FREEexやクラウドシティに入って、そこに価値を見つけてうまく活用している人もいるし、まだ入ってない人で、そこに価値を見つけられる人っていうのもいるはずだから。
・「岡田斗司夫をFREE（無料）にする」と言いながら、有料電子出版を行っている。
これは俺も変だと思う。電子版の配信会社と癒着があるんじゃないの。無料で配れよな。
・「クラウドシティもバベル（社内SNS）も異常に雰囲気が悪い。
皮肉好きなオタクと弱者が渾然一体となって異常な雰囲気を醸し出している。」
「皮肉好きなオタク」とか「弱者」とか「渾然一体」とか、なんか表現が曖昧でなにがどう異常なのかよくわからない。
クラウドシティに限っていえば、俺が見た感じ、そんな印象は受けないけど。
・「金に余裕があって面白い人ほどコミュニティのレベルの低さに呆れて辞めちゃう。」
どういう実証なんだろう。「金に余裕があって面白い俺は、コミュニティのレベルの低さに呆れて辞めてやったぜ」っていう証言なのかな。それとも、誰かが「金に余裕があって面白い」と評価した人が、「コミュニティのレベルが低いから辞めた」と言ったのかな。
「金に余裕がある」はまだいいとしても、「面白い人」なんて人それぞれ違うんだから、まずそれを指標とすること自体がすごく主観的だし、その人が「コミュニティのレベルが低い」なんて言ったところで、だからどうなんだろう。
別に、「コミュニティのレベルが低い」という感想をもつのはいいと思うけど、「低いレベルのコミュニティには関わらない」と思う人よりは、「低いレベルのコミュニティを、自分の力で高くする」という実験場だと思える人のほうが、俺はその人を「面白い」と思えるけど。
・「exもクラウドシティも、岡田の精神的なパワハラという被害を受ける。」
そうなの？本当なら問題。具体的にどういうことをされたのかきかない限り、わかんないけど。
ただ、毎日「お前は使えない社員だ」ってメールが送られるくらいなのか、たまに「その考え方はおかしい」と指摘を受けるくらいなのかによって、違うよね。
・「社員は確実に減っている。ほぼ全員が岡田の人間性に嫌気がさして辞めているのだが、岡田は「大半が円満退社。だからキミも入っておいで」とクラウドシティで大嘘をついて勧誘している。」
これもよくわかんないけど、「ほぼ全員が岡田の人間性に嫌気がさして辞めている」と「大半が円満退社」のどっちにも客観的なデータがない以上、どちらかに対して「大嘘をついている」と断言することはできない。
お互いが「ほぼ全員が」とか「大半が」とか使ってる時点で、どっちにも説得力はない。
・社員数の変化「２２２人 → １７１人 → １５０人 → １１０人」（これだけ減っていることを明示せず。）
変化推移はともかくとしても、今現在の社員数くらいはどこかで教えて欲しい。
またこういう論法になるけど、「社員は増えてます」と明言してない限り、減っていることを明示しないのは問題じゃないと思う。
上でもいったように、社員の退社理由の主なものが「社員が岡田斗司夫に嫌気がさした」だと断定できる客観的なデータがない限り、「新入社員の勧誘に力を入れなくなった」、「入社の審査を厳しくするようにした」みたいな制度上の理由とか、「岡田メソッドのお陰で本業で出世してFREEexの活動が続けられなくなった」とかいう信者丸出しの理由とか、いくらでも決めつけが可能になるから、岡田斗司夫を叩くにしても、崇めるにしても、「ほれみろ、減っているということはFREEexが○○だということだ」っていうのは、推測の域を超えないんじゃないのかな。
・「理屈民族とか言ってるけど、クラウドシティもバベルにも理屈できちんと話せる人なんてほとんどいないし、大半の人間が最低限の議論(＝対話でもなんでもよい)のルールすら知らない。だからバベルもクラウドシティも多くの人間が辞めている。」
「理屈できちんと話せる人」とか「最低限の議論のルール」が、もっと具体的に明示されていたらいいんだけど、これも曖昧で主観的だからよくわからないし、それと、バベルとクラウドシティの退会理由と結びつけるのは、この発言者の推測でしかないんじゃないのと、俺は思う。
「どっからどうみても、明らかにそうだろ」というんだったら、退会者が何割がそういう理由をもって退会しているのかっていう客観的なデータが欲しい。
「匿名掲示板2ちゃんねるの、それもID表示のないスレッドでの被害者を名乗る人間の数」を体感として「明らかにそうだろ」というのは、俺はどうかと思う。
・「一部の有能社員は既に退社あるいは距離を置き、残りは変なのばかり。」
「有能社員」と「変なの」が曖昧でよくわからないし、「有能社員が退社あるいは距離をおいた理由」がなんなのかわからない以上、なんともいえない。
・「最近、マジでオウムとかに近くなってきたんだよね。岡田斗司夫は独裁でイエスマンしか近くに置かない。」
独裁だというのは明言してるし、そういう場合は、きちんと客観的で説得力のあるデータとか説得方法を持っていない人を除いて、イエスマンにならないと岡田斗司夫には気に入ってもらえないだろうなとは思う。
でも、そもそも「岡田斗司夫に対してイエスマンで振る舞うことで得られるもの」を欲している人こそがFREEex社員になるべきなんじゃないのかな。
自分の頭で考えられる人で、それが岡田斗司夫よりも有用で効果のあるものなんだったら、FREEexで岡田斗司夫に従うんじゃなくて、どこか別のところで自分の頭を効率よく使ったほうがいい。そこまでの力がない弱者が、岡田斗司夫に全面的に頼って、すがって、「岡田斗司夫とは何者なのか」を得るのが、FREEexなんじゃないの。
それが良いのか悪いのか、カッコいいのか気持ち悪いのかは、人それぞれであってどう評価しようが勝手なんだけど、そうしたほうが普通に生きるよりはマシだという人もいる。
【クラウドシティ関連 その他】
・社員がろくに配当実績の無いクラウドシティに投資の勧誘・宣伝。
クラウドシティへの投資が「1万円と時間を費やすこと」なんだとしたら、応じて得られるものは人それぞれであって、「配当」なんて、分配されるべきものみたいな言い方をするのがそもそも間違ってないか。
「人それぞれ」という文言を言い訳にしている、とかいわれてしまいそうだけど、実際、得られるものの内容も程度も活用する人で変わるし、「偏差値を20上げます」みたいな誰がどう見てもわかるような効果が欲しいと思っている人は、そもそも何も得られないような仕組みになっている以上、仕方がないような気がする。
岡田斗司夫と編集者が本を執筆しているやりとりをみられただけで元がとれると思う人もいれば、岡田斗司夫ファン同士で馴れ合うのが楽しいって人もいれば、レベルの低い市民を自分の手でレベルアップさせることで自分の力を上げる人もいれば、様々だから。
だから、「リターンは曖昧だし、まったく保証できません。利用するあなた次第です」っていうアナウンスは、きちんとするべきだと思う。
・見習い社員が軽くクラウドシティ批判と心情を吐露したところ、岡田は、「ぽっと出の新人が俺は見切ったぜ！見たいな事を言っても痛々しいだけ」と話題をそらし怒りを必死で押さえて「社員一同、お前の性根をたたきなおしてやる」とモラルハラスメントをはじめる。
「ぽっと出の新人が俺は見切ったぜ！見たいな事を言っても痛々しいだけ」とか「社員一同、お前の性根をたたきなおしてやる」が要約されたものでなくて、原文そのままだとしたら、すごく問題。
その「見習い社員のクラウドシティ批判」の内容がどんなものかにもよる。
・クラウドシティの中では、複数の人間が無責任な中傷を行なっています。
そうなの？俺はみたことない。寧ろ、みんな無難なことしか書かないから、あんまり面白くない。
まあ、「無責任な中傷をやってる奴はいない」とはいえないけど、それだったら2ちゃんねるには負けると思う。
・理屈を使いこなせないので、気に入らない人が居ると屁理屈を捏ねて攻撃します。
これは市民がなのか、岡田斗司夫がなのかわからないけど、これも単なるレッテル張りな気がする。上でも言ったけど、日記を書いたりするのって、顔出ししてる人とか実名晒してる人ばっかりだから、無難なことしかやり取りされてない。
これも俺の主観なので、「気に入らない人が居ると屁理屈を捏ねて攻撃する奴はいない」とはいえない。でも、それについては2ちゃんねるには負けると思うよ。
・書き込みの質がどんどん落ちて、面白いこと書くやつから消えている。
・「わざわざ1万円も払って入ったクラウドシティが廃墟だと分かってきた時にはちょっと脱力した。」
・「自分みたいなクズしかいなかった。」
・「岡田さんが私の日記のコメントでワケのわからない説教をしてきて、すっかり私は腹を立ててしまった。」
・「理屈民族っていうか、オタクが集まって皮肉言い合ってるだけ。まともな人間もそれを見て去って行く。」
・「クラウドシティ内の言葉使いは慇懃な皮肉バトルは最低だったよ。2ちゃんねるのほうがずっとマトモだね。」
・「理屈戦闘民族がお互い屁理屈で相手をフルボッコにして覇権を争う修羅の国。岡田やその取り巻きにとっては理想郷。そうじゃない大多数の人にとっては騙された」「ついていけない」「金返せ」ってこと」
・「クラウドシティにおける1番面白いコンテンツが岡田斗司夫への批判」
・「クラウドシティというサービスは、その宣伝内容とは異なり、理不尽な振る舞い、不条理な言説、明らかな屁理屈や詭弁がまかり通る空間である、と理解しました。」
この辺は、ただの感想とか、もう反論したものとだいたい同じものだから別に反論するとかそういうのはしないけど、これを根拠に「絶対的に価値が低い」とするのはおかしいなと思う。
それぞれが抱いた「価値の低さ」は正しいと思うよ。
自分や岡田斗司夫やクラウドシティ市民やFREEex社員を「まともな人間」扱いする気はないです。
・「メルマガだって最初は社長の裏話日記が！と誇大広告で誘っておきながら蓋を開けたらは数分トーク動画。裏話なんか全然ない。」
これはまあそうだと思うけど、どんな裏話を期待してたのかよくわからん。「年収10倍になる方法が！」で、ただの世間話動画だったら俺も怒るけど。
・「岡田ゼミは「自分は頭がいい」と思い込んでいる人が、悩み相談の相談者を罵倒する場所だった。」
ちゃんとみたことないからわかんない。岡田斗司夫自身が「徹底的に相談者の味方になるように」って言ってるけど、そうじゃないのか。
何度も言ってるけど、アクティブな人はだいたい顔と名前晒してるから、相手を攻撃する目的でとか、腹いせにみたいな動機をもって活動することはあんまりないと思う。
これも俺の主観、感想でしかないから、そういう人がまったくいないわけじゃないと思うけど。
・「岡田斗司夫にとってのいい人にならないと、マイ仲間にして貰えない。岡田マイ仲間じゃないと、岡田日記はほとんど読めない。だから万歳コメントでも書いてみるしかないじゃん。」
・「岡田のマイ仲間になるには、顔の写ってるプロフィール写真にするなどの条件がある。」
これは今はルール変わってる。
「自分の情報を第三者によってクラウドシティ外部に公開されることを許可した者、且つ、岡田斗司夫が面白いと思った者」だけがマイ仲間（マイミクみたいなもの）になれる。
そんなルールより以前に、そもそも最近は岡田斗司夫は日記をぜんぜん書いてない。twitterとかfacebookのほうばっかり。
だから、岡田斗司夫のマイ仲間になることで得られるメリットが今やあんまりない。
ただ、「岡田斗司夫ゼミ」っていう、「条件をクリアした市民だけが参加できるコミュニティ」みたいなのがあって、そのゼミ生とそれ以外の市民の情報格差はけっこうあると思う。
その条件は「岡田斗司夫が作った性格判断テストの結果を明示しろ」「本人だと証明できるものの写真（顔写真じゃなくてもいい）を貼れ」「誕生月を設定しろ」「プロフィールをきちんと書け」「毎月日記を3日以上書け」の5つ。
条件の内容がどうこうじゃなくて、1万円払ったあとに更に条件が課せられるのは、事前に教えて欲しい。
・「何でコンテンツはフリーつってたのに、相談料2000円みたいなイベントやって金集めんの？しかも金取って相談に答えないって、そこらの占いより詐欺行為じゃね？ 」
・「すべての相談や質問に岡田斗司夫が答えます！」というイベントをするも、時間がなくなったら打ち切り。答えてもらえなかった者続出も未返金。
あれはマンツーマン対応じゃなくて、広い会場で事前に募集した質問をひとつひとつ読み上げながら答えていくという形式だったから、「岡田斗司夫を質問攻めにしよう」っていうイベントだと思ってたんだけど、「 Permalink | 記事への反応(1) | 21:56
Eclipseがemacsやvimより優れている点を挙げてみよう。
・CVSリポジトリの構成を直接覗ける →redmineとかを使ったほうがいいんじゃないのか
・設定できる警告メッセージの種類が豊富。→警告そんなにいるのか
・復元機能が非常に充実している。 →バージョン管理ソフトがあれば普通だし
CVSのように以前の状態に復元すること、以前の状態の →diffじゃダメか、というかなんでいまどきCVSなの
ソースコードとの比較も容易。CVS(Eclipse標準装備)/Subversionプラグインにもこの機能は存在する。
・プラグインの数が豊富、膨大。 → 数があってもつかえるのは少ない
・プラグイン開発環境もEclipse自体に用意されている。 →開発環境を使って作る程のものでもなく、バッチファイルとかスクリプトでよくね
・ライセンス形態がCPLであり商用利用もしやすい。 →eclipse組み込んで出荷するの？
・上位版にWSADが存在する。 →WSDADってなに、WebSpereの残骸？
・Smalltalkで有名なVisualworksの影響を受けているため、
JUnitプラグイン(Eclipse標準装備)によるテストファースト、リファクタリングの他、eXtreme Programming環境が充実している。→Jenkinsのほうがよくね
・SubclipseプラグインによりSubversionにも対応できる。これはCVSよりも強力！→コマンドラインから実行するsvnコマンドを覚えておくとはターゲットでも動いて便利だよ
・Call Hierarchyプラグイン(Eclipse3.0から標準装備)によりメソッドの呼び出し階層を調べることができる。この機能は強力だ！→スタック見るだけのことじゃないの
・プラグインによってはURLを指定するだけでプラグインの自動ダウンロード、自動インストール、
自動アップデートができるためプラグインのインストールが非常に容易。→勝手に変わったら怖くない
・Eclipse上から直接Tomcat, JBossなどを再起動できるSysdeoプラグイン、JBoss-IDEプラグイン
という強力なプラグインが充実している。→えー、今頃Tomcat
・EclipseUML Omondoプラグインによりクラス図などを書いたり、
UMLによるModel Driven Architecture, リバースエンジニアリング
・RSSリーダープラグイン、MP3プラグイン、All The Newsプラグイン、
など様々なプラグインが充実している。→それ開発ツールじゃなくて携帯でやったほうがよくね
・PHP開発が可能なTruStudioプラグイン、Perl開発が可能なPerl E.P.I.C. プラグイン、
C/C++開発が可能なCDTプラグイン、AspectJ開発が可能なAJDTプラグインなど
他言語プラグインが充実している。→Java以外は所詮おまけだけどね
・そのほかにD言語プラグイン、C#プラグイン、Pythonプラグイン、JavaScriptEditorプラグイン、
CSSプラグイン, HTMLプラグイン, XMLプラグイン、(Jakarta)Velocity UIプラグイン、
Apache Antプラグイン(Eclipse標準装備)、非常に強力なApache Mavenを使うことができるプラグイン、
ゲームができるプラグイン、メーラとしてつかえるプラグイン、Wikiプラグイン、Hibernateプラグイン、
FindBugsプラグイン、CheckStyleプラグイン、Jalopyプラグイン、Sobalipseプラグイン、ソロプログラマープラグイン、
など様々なプラグインが充実している。→それぞれ単機能のソフトのほうが充実してるんじゃないの
どうしてもeclipseというなら止めないけど
おお、気づけば学生を終えて、仕事について１年も経っているじゃないか。
女遊びもせず、一人の子とせっせと一途に付き合って
続けていれば、とせっせと読み積み上げてきた技術書の数々
さして力もついてない英語学習
VBで作ったアプリがiPadで動くと信じるような社長がいる職場
転職してやりゃいいや、とか考えてたけど、自分のショボさを考えると絶望的な気分になる。
「スマホアプリなんてすぐブーム終わるだろ」とか思って手を付けてなかったけど、やらない時点で俺の方が終わってるな。
ウェブアプリだって上辺だけ理解した気になって、何も作っちゃいない。
「基礎体力がそもそもないし」と思って続けてきた事に意味なんてあったんだろうか。
OSもコンパイラもデータベースもあるものを使えばいい、っていうのが当たり前で、当たり前が嫌で勉強してきたはずなのに、自分の無力さを知るばかり。
じょーほーしょりしけん（笑）を取るのには役立つかもしれないけれど（確かにうんちゃらスペシャリストとかの試験には役立ったけどさ。あれなんか意味あんの？w）
逆に会社で「資格だけ持ってる奴」みたいな目で見られてそうで嫌だ。
実際大したことできねーし。
頭よすぎだろ。学歴で優劣ってのは正しいかもしれん。Fラン卒じゃ無理だ。自分がゴミな気しかしない。
１メソッド最大１００行程度とか、テストはちゃんと書くとか、なんか本とかウェブでは色々あるけどマジで理想論だと思った。
そんなこと言ったら「何この新人キモいww」ってなること確定じゃねーか。（あ、もう新人でさえないからただのキモいやつだ）言えないし見た事もないよそんなの。
でも馬鹿じゃ頭に入りきらないから関数で処理小分けにしてたら「関数細かくて見にくいよ」とか注意されたよ。すいません。
マジすいませんしか言ってない気がしてきたよ。
「こんな職場でずっと過ごすのやだなー」とか思ってたら「どこへ行っても使えないやつ」になってる気がする。
マジ痛い奴の典型。最悪。
技術が好きでそれで飯を食うとか馬鹿げてると思った。趣味でやるって割り切らなきゃだめだ。っていうか能力がないとダメだ。
馬鹿は馬鹿らしく家で引きこもってオタオタと遊んでいるべきなのかもしれん。あーでも金も仕事もないしなー。
あれ、でもIT土方ってプログラミングできる事を抜いたら魅力なくね？なんで俺こんな事してんの？
あー、もうたまに早く帰れるとこれだよ。ろくな事考えない。何書きたかったんだろこれ
class MyClass constructor: -> name = 'unknown' @getName = -> return name @setName = (newName) -> name = newName MyClass:: = do -> _greet = -> console.log('どうも、' + @getName() + 'です。') return { constructor: MyClass greet: _greet } myInstance = new MyClass() myInstance.setName('純子') myInstance.greet() #どうも、純子です。
CoffeeScript で @なんとかのプロパティが全部パブリックになるのが気になってて。
四ヶ月前、ぼくはキレイな女の子を抱きたいと思った。いや、その前からずっと抱きたくてはいた。
その気持ちがバケツのなかに溜まっていって、縁から溢れ出したのがどうやら四ヶ月前だったらしい。
でも、まったく女の子の知り合いがいなかった。周りに女の子がいないんじゃ、口説けやしない。
ぼくはけっこうシャイだから、友人に紹介してくれとも言えないんだ。どうしようかと考えた。
結論は早かった。そうだ、ナンパをしよう──。
女の子と仲良くなりたい。でも、接点がない。だったら、ナンパするしかない。明快なロジックだろ？
そして、四ヶ月たった今、なんとぼくには二人のセフレがいる。どちらもとびきりの美人だ。
いったいどうやってそんなことが可能になったのか？ どんな魔法を使ったのか？
それをここに記したいと思う。女の子を抱きたいと思っている男の子はたくさんいるはずだ。そんな男の子たちの一助になってくれることを願う。
では、今から説明をしよう。だが、その前にちょっとだけきみの部屋にある本棚を眺めてみてほしい。女の子が抱きたくてたまらないときに買ってしまった、恋愛ハウトゥー本はないかい？ あったらそれはゴミ箱に投げ捨ててくれ。きみにそんなものは必要ない。
ナンパ師がよく言うメソッドに「100人に声をかければ１人はゲットできる」というものがある。
確かに多くの女の子に声をかければ、いつかはサクセスすることだろう。
しかしだからといって数をこなすことが目的になってしまえば、ナンパは単なる徒労になってしまう。
ぼくも「綺麗なお姉さんとエッチなことがしたい」という思いが空回りして、銀座で声をとにかくかけたことがある。
しかし、たくさん断られたらそのぶん傷つくし、女の子を探して歩きまわるのは、当然だが疲れてしまう。
それで女の子と仲良くなれたら言うことないだろうけど、心に傷を作ったうえに何もなかったら、わびしい気持ちでいっぱいになってしまう。
一日予定をあけて何時間もナンパをするだなんて、フルマラソンに出場するようなものだ。
訓練を積んでいないと身体がぼろぼろになって、最悪ケガをしてしまう。
ぼくが望んでいるのは何十人もの女の子とセックスをすることじゃない。
ひとりでもいいから甘えたい気分のときに抱きしめてくれて、ムラっときたときにエッチをさせてくれる、そんな優しい女の子が欲しいんだ。
だから、長時間ある場所に張って女の子に声をかけるなんていう方法はすぐにやめた。体力がもたないんだ。
そこでぼくのようなライトなセフレ待望者でもできる、フルマラソンじゃなくて短距離をランニングするようなナンパ方法を考案した。
ぼくがやった方法はとってもシンプル。普段どおりの生活のなかで、いい感じの女の子を見つけたら声をかける。これだけだ。
もうちょっと具体的に言おう。ぼくが声をかけるので一番多いのは駅の改札を数メートルでたところ。
これは大学やバイト先に行っているとき、もしくは家に帰っているときに電車内で見つけたステキな女の子をちょっとストーキングして声をかけているってことだ。
自分から無理やり探しに行くのは疲れるからしない。日常生活のなかで、思わず抱きたいと思うような女の子が通りすぎたときだけナンパする。
ナンパ師が声をかけるとき、いろいろと妙ちきりんなテクニックを考えだして実践しているらしい。道を聞くふりをしたり、だとかね。
だけど、ぼくはそんな面倒なこともしない。声をかけるときのセリフは完全にテンプレートで決めている。それはこんな言葉だ。
「すみません、さっき電車のなかで見かけて……一目ぼれしちゃいました！」
変な飾りつけはしない。ストレートに、シンプルにいく。そもそも技術がないんだ。テクニックに頼ることはしない。
ナンパするかを決める基準はぼくの好みに大きく依存しているが、ナイスな女の子に片っ端から声をかけても無駄だ。
さっきも言ったようにたくさんの女の子をナンパして、たくさん断られることは心の傷を深めるだけだ。そんな悲劇は避けよう。
では、どんな女の子がナンパに応じてくれるのか？ ズバリ言おう。20代後半～30代後半で、小奇麗にしている女の子だ。
ケバかったり、若い女の子に対抗しようとしている女の子は除外した方がいい。そういう女の子はやたら自分の価値を釣り上げてくる。ババアのくせに。
遊んではいないけど、異性の目を意識してしまう・・・そういう女の子が格好のターゲットだ。
移動中の電車のなかで年はいっているけど小奇麗ですてきな女の子がいたら、心のなかで問いかけてみよう。
「ちょっとシワはあるけど……うん、抱きたいな」
そう思えるなら声をかけるんだ。ぼくはそうしている。
実はナンパが成功するか否かは声をかけたときの反応でわかってしまう。
「一目ぼれをしました」と言った瞬間に、不意をつかれながらも女の子が「あはっ」と笑ってくれること。これが成功の絶対条件だ。
「は？」と反応が鈍かったり、こっちを怪しんでいたり、あからさまに嫌な顔をするときは、これは絶対に上手くいかない。そのあとにどんな言葉をかけたって、どんどん不快な気持ちにさせていくだけだ。こんなときは潔く諦めよう。
こちらのストレートな好意を嬉しがってくれる女の子。こういう女の子は話していると終始口元が緩んでいて、こちらも気が楽になるし、上手くいくことが多い。
第一声で笑ってくれたら、あとは普通に会話をすればいい。どういう人で、どんな趣味か聞いて、自分はどんな人間かを自己紹介するんだ。
ナンパ本には冗談をたくさん言って笑わせろだとか、女の子の持ち物を褒めていい気分にさせろだとか書かれているけど、ぼくの目的は普通に仲良くなることだ。そこに高度なテクニックは必要ない。
無理してハウトゥーに書かれている技を実践してみたってうまくいかないし、疲れるだけだ。
余計なことは考えずに、自然体に。それがぼくのモットーだ。
女の子が大好きだとつい知り合ったその場で抱きしめたり、キスをしたりしたいなって考えてしまうけど、そんなことをすれば逮捕されてしまう。
ナンパ師の自慢を聞いていると、会ってすぐに漫画喫茶に行って生でセックスしただとかいうエピソードが出てくるけども、そんなことは技術力を積んだその人だからできることであって、基礎を学んだ身ではないぼくにはできるはずがない。
一度だけ、ウォーキング中の主婦をナンパして、何時間もウォーキングに付き合っていたらちょうどよくホテルが見えてきたので、そのまま入ってエッチしたなんてことはあった。しかし、その子とはそれっきりだし、初対面で女の子を抱けるなんてことはその一回だけだ。
ナンパが上手くいったら、あとは普通にデートを楽しもう。すぐに身体を求めるんじゃなくて、相手が心を許すのを待って、もし向こうも望むのならばエッチをする。そのぐらいの気持ちでいいんだ。
ぼくはそばにキレイな女の子がいるだけで幸せな気分になれるので、結果的にその子を抱けなくても満足している。がっついたって良いことはない。むしろ、傷つく可能性のほうが高い。
ぼくが重視したことはとにかく疲れずにナンパできることと、抱けなくたっていいと目標を低く設定すること。
無理をしたって続かないし、高い目標を設定してしまうと、あとでがっかりすることも多くなってしまう。それは精神衛生に悪い。
そうやって、日常生活から半歩だけ冒険する形でナンパを続けてみて、何人かの女の子と仲良くなれた。
そう、たった数人の女の子だ。でも、ぼくはそれだけで満足だ。たくさんの女の子を抱くことが目的ではない。
いま、ぼくは幸せな気持ちでいっぱいだ。いつだってぼくを受け入れてくれる女の子が二人もいる。
その子たちはぼくが望んだらいつだって会ってくれるし、もちろんセックスをさせてくれる。
情けなく甘えたら頭を撫でてくれるし、身体のどこを触ったって怒らないし、何度も何度もチューをさせてくれる。しかも、美人。
二人とも働いているし、一人は結婚しているから予定が合わないこともあるけども、どちらかとスケジュールが合うときは必ず会って、幸せな気分にさせてもらっている。
ナンパを始める数カ月前とはほんとに大違いな、とってもハッピーな毎日だ。だって、そうだろう？ キレイな女の子を定期的に抱けるんだ。こんな幸せなことってない。
きみもこんな生活を送ってみたくないかい？ きみにもできるよ。ぼくの方法を実践すればね。
The show must go on. やりつづけるんだ、きみの夢をかなえるために。
http://anond.hatelabo.jp/20120313001659
ソーシャルゲームはまだ歴史が短いから焼畑商業方式で儲けられるからね
ネット上で焼かれるのは土地ではなく無知で金のあるユーザーだよ
同じゲームでもまだソーシャルゲームに比べて歴史が長いネトゲはその時代を過ぎ
儲けのみに走ったタイトルは以前の強さを失ってる
ある新しいサービスが生まれると、より無知なユーザー向けの焼畑商業方式のメソッドが儲かる
早いサイクルでサービスをリリースして新しい森を焼いた方が効率がいい
ただし森がなくなるまでは
だんだんとユーザーのリテラシーが上がったりして焼けるユーザーがいなくなると次第に顧客満足度の高いサービスが生き残る
作れなければその業界自体が滅びる
家庭用ゲームはとっくにその時期も過ぎてて滅びそうだ
グリーが本当に生き残れる企業なら、焼けるユーザーがいなくなった先のことももう考えてるんじゃないかな
でもそれまでは出来るだけ早い速度で焼けるだけ焼くだろうね
もう焼く森がない！となる前に、自らポストソーシャルゲームにあたるサービスを作って
既存のソーシャルゲームをぶち壊して肥料にするくらいの事はやると思う
別の打開策は次の森がどこにあるかってことなんだけども
毎日ぼーっとテレビを見るしか空いた時間の使い方がない現代の50代以上がターゲットにされるんじゃないかなぁ
あの世代って信じられないくらいテレビに依存してて一向にリテラシーが上がらないし操作されやすい
あれほど炎上しやすい世代も無い
ただあまりにもテレビ以外のメディアに触れる機会がないから、どうやってネットにつれてくるかが問題だけど
ここまで書いて思ったけど、どうやってテレビからネットにつれてくるかじゃなくて
おばちゃんたちが、テレビでドラマ見ながらテレビの画面でソーシャルゲームをテレビのリモコンでできるようになったらたいへんだ
何で嫌ってるの？と問われたから答えただけで、普段ソーシャルゲームを批判したりはしてないですよ。
えげつない重課金が自分らの趣味（MMOなりFPSなり）に影響しそうになったら重課金モデルの問題点を話題にはするし、その過程でソーシャルゲームの話が出てくることはあり得るだろうけど、なんの突拍子もなくソーシャルゲーム批判するのはよほどの暇人だと思います。基本的に違うジャンルだからきっかけがないかぎり接点がない。
Twitter でソーシャルゲームの批判したこともないかな。pixiv のアマチュアにソーシャルゲームの製作会社がありえない低価格で依頼してるというような話題について話したことはあるくらい。大体自分の好きなもの主張するのに他を叩くメソッドを選択するなんていい大人のすることじゃないし、効率が悪いです。
指摘されてるパッケージ販売型の行き詰まり感ですが、これはネットゲーマーも同じように考えてるんじゃないでしょうか？ネットゲーマー間では昔買ってたタイトルを買わなくなったという話を良く聞きますし、自分もそうです。
この問題はソーシャルゲーうんぬんというよりも、ネットや派生する情報戦略を生かせてるメーカーとパッケージを問屋に卸して終わりの時代から卒業できないメーカーの対比になると思います。
行き詰ってるパッケージ販売型は全くオンライン関係ないタイトルならまだしも、オンライン謳ってるタイトルでも、売ったら終りなメーカーがある。
パッケージ型販売だとタイトル先行というかネームバリュー先行というかそんな感じですよね。これがネットがベースのゲームだと参入コストは低めか 0 で、欲しいサービスができた時にお金を払う。これに慣れてしまったユーザーが、パッケージ型販売から遠のくのは当たり前かと。
ゲーム業界外だと、パッケージ販売型の問題点はサービスを売ることで改善してます。ソフトは低価格や無料のバージョンもあって、企業向けのサポート付きが有料といったやつです。オンラインを使えるゲームにも同じことが言えます。
一方で、殆どオンライン要素がなくてもこれだけ良く出来てるなら買ってみようかな、ネットでとても面白いプレイ動画を見たからやってみようかな、Twitter で話題になってるから・・・と言ったタイトルはたまーにあるので中身と戦略次第だとは思います。少なくとも有名タイトルが、新作だというだけで義務感で売れる時代は終わってるでしょう。
Eclipseがemacsやvimより優れている点を挙げてみよう。
ソースコードとの比較も容易。CVS(Eclipse標準装備)/Subversionプラグインにもこの機能は存在する。
・上位版にWSADが存在する。
・Smalltalkで有名なVisualworksの影響を受けているため、
JUnitプラグイン(Eclipse標準装備)によるテストファースト、リファクタリングの他、eXtreme Programming環境が充実している。
・SubclipseプラグインによりSubversionにも対応できる。これはCVSよりも強力！
・Call Hierarchyプラグイン(Eclipse3.0から標準装備)によりメソッドの呼び出し階層を調べることができる。この機能は強力だ！
・プラグインによってはURLを指定するだけでプラグインの自動ダウンロード、自動インストール、
自動アップデートができるためプラグインのインストールが非常に容易。
・Eclipse上から直接Tomcat, JBossなどを再起動できるSysdeoプラグイン、JBoss-IDEプラグイン
という強力なプラグインが充実している。
・EclipseUML Omondoプラグインによりクラス図などを書いたり、
UMLによるModel Driven Architecture, リバースエンジニアリング
などを即座に実現できる。
・RSSリーダープラグイン、MP3プラグイン、All The Newsプラグイン、
など様々なプラグインが充実している。
・PHP開発が可能なTruStudioプラグイン、Perl開発が可能なPerl E.P.I.C. プラグイン、
C/C++開発が可能なCDTプラグイン、AspectJ開発が可能なAJDTプラグインなど
・そのほかにD言語プラグイン、C#プラグイン、Pythonプラグイン、JavaScriptEditorプラグイン、
CSSプラグイン, HTMLプラグイン, XMLプラグイン、(Jakarta)Velocity UIプラグイン、
Apache Antプラグイン(Eclipse標準装備)、非常に強力なApache Mavenを使うことができるプラグイン、
ゲームができるプラグイン、メーラとしてつかえるプラグイン、Wikiプラグイン、Hibernateプラグイン、
FindBugsプラグイン、CheckStyleプラグイン、Jalopyプラグイン、Sobalipseプラグイン、ソロプログラマープラグイン、
など様々なプラグインが充実している。
MsgBox Range("A1").FormatCondition(1).Formula1
と、式の内容を読む分には問題ないんだがな。
代入しようとすると
「Public Let 'Formula1' は型 'FormatCondition' に見つかりませんでした。'CallType.Set' と共に 'CallByName' 関数を使用してください。」
となる。
Modifyメソッドで設定せよ。とある。組み合わせで設定する必要があるわけだ。
http://msdn.microsoft.com/ja-jp/library/microsoft.office.interop.excel.formatcondition.modify.aspx
ついでに
というのも、あれはやってると脳内麻薬的なモノがドバドバ出る。
当たる･･･当たれッ！当たれェ！的なあのメソッドは、脳にかなりガシっとくる強烈な刺激で、
パチンカスはカスである、という前提を受け入れた上でもモノスゴく気持ちいい。
同様に、出会い系なんかを駆使して女の子と会ってヤるというのも、かなり良い。
人間の本能的なアレを全力で揺さぶる、まさに底辺、馬鹿のための娯楽だ。
しかし、これらには当然問題がある。
残り財産8000円、給料日まで1週間の状態で打つパチンコはヤバイほど面白い。
女に関してもそうだろう。「あー、こいつに深入りしたらヤバイよなー･･･」って時ほど面白いのだ。
ぶっちゃけて、友人の彼女を口説くのが一番楽しいのだ。人妻だったりすると更に良い。
そういうわけで、この手の娯楽はもうだめだ。
学生時代、バイト代で遊んでいるくらいなら許されたが、社会人かつフリーランスという
社会的制約の少ない状況で、これ以上この手の遊びにかまけていたら間違いなく人生が破綻する。
なにより、この手の遊びは絶頂時は恐ろしく楽しいが、その後のゆり戻しもキツいのだ。
「あー、俺死ねよ･･･」と「イヤッハァ！」の往復をいい加減断ち切りたい。
俺は多趣味な方だ。読書もするし、筋トレもする。語学もやる。料理もする。音楽もやる。
仕事自体も趣味の延長で得たものなので、それもやる。部屋に閉じこもって延々やる。
しかし、こういった「淡々と続ける」ことが続くと、放埓な遊びがしたくてどうしようもなくなる。
セックスしたいしギャンブルしたくなる。おそらく、セックスやギャンブルは本質ではなく、
脳内麻薬的なあれが欲しくて仕方ないのだろう。射精とか、大当たりとか、そういうのに付随するあの多幸感。
しかも、最近ヤバイことは「カネがある」ということだ。パチンコ屋で1万円遊んで満足できていた
ころはまだ良かった。しかし、最近はふと遊びに行った海外でバカラにハマってしまった。しかも大勝。
今もやりたくてやりたくてやりたくて仕方がない。仕事はケリがつきそうだ、一週間くらいの休みがもうじきくる。
しかし、ここでやらかしてしまったら間違いなく人生は転げ落ちる方向に行くだろうという気がしてならない。
かつ脳内麻薬がドバドバ出る。そんな娯楽がこの世にはないものか。
学生時代に格闘技やってた頃はこれが該当していた。他人を殴り倒すっていうのはモノスゴく楽しい。
KO勝ちが一回あれば、一ヶ月はその余韻に浸って暮らせた。それに咥えて、スポーツによる発散はかなり効き目がある。
ギャンブル欲も性欲もかなり減衰させることができる。
しかし、身体を壊した現在ではハードに身体をいじめる類のスポーツはできない。
Python vs Ruby vs PHP vs Haskell プログラミング言語バトル part1
http://anond.hatelabo.jp/20120118220204
Rubyistってなんであんな小学校の図書室で毎日読書してそうな
顔面オジサン、オバサンばっかなの？
Scalaer: 鼻持ちならない、モヒカン
Lisper: マジキチ
Rubyist: ネクラ、オタク、キモメン、いじめられっこネクラチビメガネ、色黒、キモオタ、顔面オジサン、オバサン
Rubyのブロックが便利すぎて、Pythonをやめたくなった。
いちいちtemporaryな関数を作成してから目的の関数に渡していたのがばからしくなった。
リストやジェネレータ式の内包表記が便利過ぎて
どうせ廃れる。
609
＞リストやジェネレータ式の内包表記が便利過ぎて
おれもそう信じてたけど、Rubyの、メソッド呼び出しを続けて書けるほうが便利だわ。
まるでjQueryみたい。といってもjQueryのほうが後発だけど。
たとえば「xsから0以上のものを選んで、その二乗の和を求める」場合
sum([ x*x for x in xs if x > 0 ])
これだと、後ろから読まないといけないんだよね。でも
xs.select{|x| x > 0}.map{|x| x*x }.sum
これなら頭からひとつずつ読めばいいから、わかりやすいし、考えたとおりに書きやすい。
まさにスクリプトって感じがする。
Python: [[x,y] for x in xs for y in xs]
Ruby: xs.map{|x| xs.map{|y| [x,y] } }.flatten(1)
いっぽうメソッドチェーンは
orz.sage().hage().hoge().hige() タイプの問題には向いている
つまり向いている方向がちがう
(まあHaskellなら hige . hoge . hage . sage と書くだけだというのは置いといて）
強い弱いということで言うと、問題を解くのに必要な一番能力が弱い
（限定された）道具を使うという考え方があるようだよ
ベタ再帰は強い（汎用的）、がそれゆえ読むのに注意を必要とする
foldrは再帰よりは弱いが、foldrで表現可能な問題のクラス（原始再帰）はかなり
広いので、mapやfilterで済むならもちろんそのほうが望ましい
ではこの問題は弱いmapやfilterを結合させるほうがいいかというと、
俺はlist comprehensionのほうが集合表記そのもの=whatを表現していて好きだな
Pythonのlist comprehensionのsyntaxはあまり好きではないが
それは大きな問題じゃない
メソッドチェーンってバグをわかりにくくするだけだと思うなあ。もちろん性能面もあるし。linqとかは良いと思うけど。
同じメソッドチェーンでも、linqなら良いけどrubyなら悪い .....
一言で言うと「俺はRubyが大嫌いなんだぁーー」ということですな
内包表記は構文でサポートしないと難しい（マクロがあれば別だが）
メソッドチェーンが関数型の方法に比べて特に優れている点があるようには思えないが
パイプ順に書きたければ書けるし
680,663
Pythonには関数型として致命的な弱点があるから、メソッドチェーンでは簡潔なコードが書けない
たとえば「(1) Rubyは 条件判定が(文ではなく)式」だから以下のようなコードが書ける
if test
if test_1 then test_1_1 else test_1_2 end
else
if test_2 then test_2_1 else test_2_2 end
end
}
あるいは「(2) Rubyはブロック内で局所宣言が可能」だから上のコードを以下のように書き換えてもいい
cond_1 = if test_1 then test_1_1 else test_1_2 end
cond_2 = if test_2 then test_2_1 else test_2_2 end
if test then cond_1 else cond_2 end
}
関数型言語であれば「(1) 条件判定(if/case)が式」で「(2) 局所宣言(let .. in .. end)が可能」なの当たり前
ところが残念な事に、どちらもPythonには欠落しているから、上の例はストレートにコード化できない
だからPythonではメソッドチェーンは使われないし、「酸っぱい葡萄」に見える
Rubyでもリスト内包表記が言語として組み込まれてくれると嬉しい
だと思う
頭に浮かんだロジックをすばやくコード化するのはメソッドチェーンが適しているし、
じっくり腰を据えてコード設計するならリスト内包表記のほうが美しい
自分は、たぶんこのスレもRubyコアの中の人も見ているだろうから
そのうちRubyにもリスト内包表記が実装されるんじゃないかと期待しているw
メソッドチェーンは書き易い
内包表記は見た目が整ってて綺麗、最終的な型がわかり易い
いじょ。
Pythonの方が弄れる対象が多いのに、なんでウェブ系だとPHPの方が流行ってんだろ
端末からのテキスト処理も楽だし、数値計算周りのライブラリも充実しているのに
PHPが優遇されているのって歴史的な経緯以外に何か他の理由でもあるのか？
けどまぁ、情弱な文系SEが大半を占めているバカだらけの日本じゃ別にPHPで困ることもないか
数値計算や端末からのテキスト処理なんてWeb系じゃ大して使わないからなあ…
Pythonに関しては、ZopeさえコケていなければWebサーバ用LLとして大成功していたはずなのに、
Railsなんかが登場したおかげで、すっかり影が薄くなってしまいますた....
ってか、railsにインスパイアされたフレームワークって今じゃ幾らでもあるよね
djangoとかCakePHPとか。rubyってRoRを使いたいユーザを除くと、
pythonやPHPの方がユーザー数は圧倒的に多いと思うんだけど
本家のrailsって、他を遥かに越えるほど良いものなんだっけ？
44
Zopeが登場した当時、「RDB+PHPはもう古い、これからはOODB+ZopeがWebの中軸になる！」と
少なくとも自分はZopeからPythonという言語を知ったし、その時点でRubyは知らなかった
そして、その後のORM(RDB)+Railsの出現と華々しい革新性への注目は、誰もが知っているだろう
今でもZopeの開発は継続されてはいるが、結果的に当初の期待が大きく裏切られたという事実は動かしがたい
djangoとCakePHPについては実際に触っていないので憶測になるが、おそらく技術水準ではRailsと同等だろう
しかしRailsはRailsでコミュニティの活動が活発だし、その進化は異常に早い
Railsに何か致命的なトラブルが発生して開発が停滞する、あるいはdjangoやCakePHPから
何かのイノベーションが提示されでもされない限り、後発のdjangoやCakePHPがRailsに追いつくのは無理
Railsは決して技術的に完璧なWebフレームワークではないんだけどね....（たとえばSeaSideのような.... ）
だからこそ「もしもZopeが....だったなら」という「たら・れば」感はPythonコミュニティの潜在認識になっている
C a k e P H P は う ん こ
CakePHP使ってんの？
可哀そうにw
でもやっぱりいつもの使い慣れたLL(Python/Ruby)で
Webサービスを書きたいってのがある
求人数は
Ruby on Rails＞＞＞＞＞＞＞＞Django
http://www.indeed.com/jobtrends?q=django%2Cruby+on+rails&l=
どういうことなの？
求人数が多いのはそのためだと思うよ
なんかのミスかと思ったがアメリカでもRuby on Railsは人気があるのかなあ・・・
Pythonのほうが使いやすいと思うのだがフレームワークはRailsが優位なんだろうか
Djangoは周辺ライブラリが微妙だし本体も鈍くさい感じがする。
でも、FlaskはSinatraより好きだから、Pythonが嫌いってわけではない。むしろ好き。
ただ、いざ作り始めるとやっぱりRailsが楽だなあってなって、Railsを使い続けている。
同感だ
同じように思っている人が他にもいて安心した
PHPはフレームワークが乱立しすぎているから、RailsをPHPで実装してみようというやつが出てきた。
それに比べてPythonは、Zopeというデファクトスタンダードが既に存在していたけど、
ただ、どうやってもRailsもどきがRailsを超えることはできないのは間違いない。
パクリはオリジナルを超えられない(ｷﾘｯ って定型句だけど、
これってｷﾘｯって言いたいだけだと思う。
D言語って超えたって？
B言語って超えたって？
PHPで同じ事をできないわけではないだろうけど、Ruby on Railsほど簡潔にはできない
まあくだらねえWEBサービス作って喜んでる情弱は早く死ねって事だよ
そういう理由じゃなくてRailsのほうが単純に情報もプラグインも多いからでしょ
linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
わざわざ不合理で不完全な言語を使うなんて
もしも
＞linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
真実であるのなら、今頃はdjangoの情報とプラグインが溢れかえっているはず
yumや、gdbとgnomeの拡張がpythonであるからといって、それをwebアプリでも使いたいと思う人は少ないというだけのこと。
ソースからインストールする必要があったとしても、web開発ではrubyを使いたいという人が多いというだけのこと。
というか、世界中のPythonプログラマが Remeber Zope!! を合い言葉に
打倒RailsたるWebフレームワークを開発しているはずだけど、
Railsも登場してから、かなりの年月が経過しているんだけどなぁ....
その間にもRailsはRails 3が登場して、REST/AJAXの強化等の進化が継続しているよ
Ruby では
ary.map {|x| x**2}
map(lambda x: x**2, ary)
となり、lambda の本体が1つの式では表現しきれなくなると
.....
と書き換える必要があります。
f = lambda x:(x and f(x-1)*x)or 1
RubyにはPythonのように「lambda本体は式でなければならない」という限定がありませんから、
f = lambda{|x|if x == 0 then 1 else x*f.call(x-1) end}
または
f = lambda{|x|x == 0 ? 1 : x*f.call(x-1)}
と書けます。lambda内でreturnが使えますから、書きたければ
f = lambda{|x|if x == 0 then return 1 else return x*f.call(x-1) end}
でもOKです。
348
これはPythonをdisっているように見せかけてRubyをdisっているのか？ と一瞬思ってしまったｗ
だってRubyのほうが長くない？CLのfuncallみたいなcall()がちょっとうざいし…
そしてどっちもlambda式の中で束縛変数の名前で再帰可能、と
print [x*2+100 for x in [1,2,3,4,5] if x > 2 and x < 5]
暗号のように見える。
puts [1,2,3,4,5].select{|i| i > 2 and i < 5}.map{|i| i*2+100}
思考の流れと、コードの流れが一致しているので書きやすい。
map(lambda x: x*2+100, filter(lambda x: x > 2 and x < 5, [1,2,3,4,5]))
pythonて可読性が高いのをうたってる割にはそこいまいちだよね
Rubyの場合には、左から右へと無名関数がデータフローあるいは
関数型プログラミングに不慣れな初心者でも、参照透明性のあるコードが自然に書ける
プログラマにとって優しい or プログラミングの楽しさを教えてくれるのがRuby
それと比較すると、Pythonのコードは、関数型プログラミングというものが
いかに高度で難解なものであるかという事をもったいぶってプログラマに押し付ける
もしもPythonしか知らないプログラマであれば、関数型 = 難解 という印象を持つだろう
階乗計算くらいだと単純すぎて、ナゼ重要なのかが分かりづらいと思うのでコードで示す
result_list = source_list.map { |elem|
x = foo(elem.x) # ここが局所宣言を書く部分
x + y # 最後に評価された式の値が、無名関数のリターン値になる
}
Rubyでは、map等に与える無名関数の中で局所的な環境(クロージャ)が作られるから、
x = foo(...) のような代入文がいくつでも(= 複雑な処理でも)書ける
このポイントは、実用的なプログラムを関数型風で書こうとした時に、威力を発揮する
余計分かりづらくなった
高卒ドカタなんだろうなぁと可哀想になる
集合の表記に似せてることが分かるから
355
＞map/filterはfor/ifと同じだと言っているだけだから、難解という印象は持たない。
関数型プログラミングに慣れた、あるいは得意な人であれば、そういった印象なんだろね
Rubyの魅力はこれから関数型プログラミングを学ぼうとする初心者、 あるいはそんな初心者へ教える立場から見た、優しさ or 分かりやすさなんだ
[1,4,3,2].sort.reverse.map{|x| x.to_s}.join('-')
Pythonだと読みにくい。
'-'.join(map(str, reversed(sorted([1,4,3,2]))))
Pythonでは思考の流れと一致しないばかりか、「カッコだらけ」のコードになると.....
カッコだらけのコードを分かりやすくする基本的な方法は静的単一代入じゃないか
Rubyのやり方は基本ではなく玄人のやり方だろ
Pythonでは組み込みの型でメソッドチェインはやって欲しくないな
似たようなコレクションtuple,deque,array,queue等にも同じメソッドが必要になってくるし。
372
外部のライブラリでも列挙可能なものは、たいていEnumerableモジュールをimportしてますね
Rubyユーザーは列挙可能なものはmapやselectできて当然だろって思ってる気がします
Pythonは「何かを便利に書くためのしわ寄せ」をはっきり寄せてくる
得意と不得意を言語レベルではっきり主張するのでメリケン好みと言えなくもない
Rubyは全方位になんとなく八方美人なので、全体的になんとなく書きやすくてなんとなくキモくて遅い
「書きにくいってことはその処理に向いてないってことだから諦めろ」を地で行く
無名関数が文を使うほど複雑なら名前を付けるのが Python 流と想像。
これを読みづらいと感じるのは、左から右に流れる
もしかしてアラビア語ネイティブな人からすると逆に読みやすいのか？
「人を呪わば穴二つ」
そんなマジックワードに踊らされて、自分の内面に原因があると思い込まされて
生きる気力を奪われて自殺する善良な人々多いよね
生きる気力を奪われたらその意識をコントロールできている以上は人を憎んでも呪っても構わないと思う
嫌なことをされて魂の尊厳を奪われその回復の見込みが立たない時は、相手を自分と同じ位置かそれ以下まで引き下げないと
癒されないこともある
傷つけられ、傷つけ、傷つけられ返されることが分かっていながら憎むことでしか前に進むことができなくなった人達もいる
尊厳を奪われたまま泣き寝入りして生きるというのははたからみて「負け犬乙」としかいいようがない状況を見るたびに
強がって平気なふりをする人たちに
「お前の中では魂は傷ついてないつもりかもしれないけど、いい人ぶって我慢しつづけて人格はボロボロにされて後一押し誰かが押せば
魂が歪んで元に戻らなくなってしまいそうじゃないかい？」「あなたを不幸にしたことであの人たちは楽しそうな顔をして
あなたがつぶれるか消えれば忘れ去るかまた次の嫌がらせする対象を探し出すんだ」
とつぶやきたくなる
やりきれない気持ちをどうやってやり過ごすのか、それは同じ事をすること
特定の誰かに向ける言葉でなく、憎しみを薄めてジワジワと流して後は忘れること
大きな枠にはめて「レッテル」を貼って見下したり、「ほのめかしメソッド」使ったり
ネット以外の世間一般で認められてる範囲なら他人を憎んでも構わないのですよ？
他人からちょっと嫌なことをされたら、誰かにちょっとだけ甘えて嫌なことをする
愚痴でもいいし嫌味でもいい お互い様だ それでやっと相手からされた嫌なことも
自分がした嫌なことも受け止められるようになってくる
何でも自分１人の内面で嫌なこと受け止めようとして外に出さないといつかその魂壊れて
修繕できなくなる恐れがありますよ？
いつも集団で毎日嫌なことを言われている人達に、人を憎むな呪うななんて言葉は
「呪い」に人生振り回されずに「呪いたい」という感情と付き合うというには
Twitterで個人特定されない程度にぼかして毒舌のつぶやき吐くのもいいんじゃないでしょうか
「ポジティブ教」の信者から見れば、ネットに「呪い」の言葉があふれているのは気に入らない
みたいだけど、人生良いことばかりが常に続くわけでもないしね
「実は厳しいトレーニングはしていません。太らないメカニズムを知って生活するだけで、体は自然とやせていくんです」と語るのは、2012ミス・ユニバース・ジャパンを指導するアスレチック・トレーナーの金塚陽一さん。ひたすらゆるくて楽チンな方法でみるみる変われるという金塚陽一式ダイエットの入浴に関するメソッドを紹介しよう。
金塚式メソッドの要となる自律神経。それを整えるのに欠かせないのが入浴だ。
「自律神経には体の働きを活発にする交感神経と、体を休める副交感神経の2種類があります。このバランスがうまく保たれていると、健康でやせやすくなります。湯船につかると副交感神経が優位になり、リラックスして精神状態もよくなるので、免疫力もアップ。入眠しやすい状態にもなるので、どんなに疲れていても、夜は湯船につかることをおすすめします」と金塚さん。
また自律神経を整える効果だけでなく、入浴時は、直接的に“やせる”テクニックも駆使すべき。
「風呂上がりには、一度冷やすことで体温を上昇させる褐色脂肪細胞を冷水で刺激することも忘れずに。このひと手間で、エネルギー燃焼率のいい、やせやすい体を作ることができます」(金塚さん)
脂肪には、エネルギーを蓄える「白色脂肪細胞」と、エネルギーを燃やす「褐色脂肪細胞」の2種類がある。「体が寒さを感じると褐色脂肪細胞が活発化し、体温が上昇。エネルギーを燃やす代謝のいい体になります」。ダイエット効果の高い金塚式入浴法を、順を追って紹介しよう。
【1】水は入浴前に飲む
入浴前にコップ1杯、入浴中は500mlのペットボトル1本、入浴後もコップ1杯の水を飲むのが理想。常温か白湯が◎。
【2】体温にも近いぬるま湯に
37～39℃の体温に近いお湯のほうが発汗しやすい。湯船には10～30分、トータルでも30分～1時間はいるとよい。
【3】上がるときは冷水を
わき、股間、背中、ひざの裏部分が、エネルギーを燃やす褐色脂肪細胞の多い箇所。心臓に遠い部分から少しずつ冷水をかけて。
【4】1時間以内に寝る
第1章 プログラミング概念入門 1.1 計算器 1.2 変数 1.3 関数 1.4 リスト 1.5 リストについての関数 1.6 プログラムの正しさ 1.7 計算量 1.8 遅延計算 1.9 高階プログラミング 1.10 並列性 1.11 データフロー 1.12 明示的状態 1.13 オブジェクト 1.14 クラス 1.15 非決定性と時間 1.16 原子性 1.17 ここからどこへ行くのか？ 1.18 練習問題 第1部 一般的計算モデル 第2章 宣言的計算モデル 2.1 実用的プログラミング言語の定義 2.1.1 言語の構文 2.1.2 言語の意味 2.2 単一代入格納域 2.2.1 宣言的変数 2.2.2 値格納域 2.2.3 値生成 2.2.4 変数識別子 2.2.5 識別子を使う値生成 2.2.6 部分値 2.2.7 変数の，変数への束縛 2.2.8 データフロー変数 2.3 核言語 2.3.1 構文 2.3.2 値と型 2.3.3 基本型 2.3.4 レコードと手続き 2.3.5 基本操作 2.4 核言語の意味 2.4.1 基本概念 2.4.2 抽象マシン 2.4.3 待機不能な文 2.4.4 待機可能な文 2.4.5 基本概念再訪 2.5 メモリ管理 2.5.1 末尾呼び出し最適化 2.5.2 メモリライフサイクル 2.5.3 ガーベッジコレクション 2.5.4 ガーベッジコレクションは魔術ではない 2.5.5 Mozartのガーベッジコレクタ 2.6 核言語から実用的言語へ 2.6.1 構文上の便宜 2.6.2 関数(fun文) 2.6.3 対話的インターフェース(declare文) 2.7 例外 2.7.1 動機と基本概念 2.7.2 例外を持つ宣言的モデル 2.7.3 親言語の構文 2.7.4 システム例外 2.8 進んだ話題 2.8.1 関数型プログラミング言語 2.8.2 単一化と内含(entailment) 2.8.3 動的型付けと静的型付け 2.9 練習問題 第3章 宣言的プログラミング技法 3.1 宣言的とはどういうことか？ 3.1.1 宣言的プログラムの分類 3.1.2 仕様記述言語 3.1.3 宣言的モデルにおいてコンポーネントを実装すること 3.2 反復計算 3.2.1 一般的図式 3.2.2 数についての反復 3.2.3 局所的手続きを使うこと 3.2.4 一般的図式から制御抽象へ 3.3 再帰計算 3.3.1 スタックの大きさの増加 3.3.2 代入ベースの抽象マシン 3.3.3 再帰計算を反復計算に変換すること 3.4 再帰を用いるプログラミング 3.4.1 型の記法 3.4.2 リストについてのプログラミング 3.4.3 アキュムレータ 3.4.4 差分リスト 3.4.5 キュー 3.4.6 木 3.4.7 木を描画すること 3.4.8 構文解析 3.5 時間効率と空間効率 3.5.1 実行時間 3.5.2 メモリ使用量 3.5.3 償却的計算量 3.5.4 性能についての考察 3.6 高階プログラミング 3.6.1 基本操作 3.6.2 ループ抽象 3.6.3 ループの言語的支援 3.6.4 データ駆動技法 3.6.5 明示的遅延計算 3.6.6 カリー化 3.7 抽象データ型 3.7.1 宣言的スタック 3.7.2 宣言的辞書 3.7.3 単語出現頻度アプリケーション 3.7.4 安全な抽象データ型 3.7.5 安全な型を備えた宣言的モデル 3.7.6 安全な宣言的辞書 3.7.7 資格とセキュリティ 3.8 宣言的でない必要物 3.8.1 ファイルを伴うテキスト入出力 3.8.2 グラフィカルユーザインタフェースを伴うテキスト入出力 3.8.3 ファイルとの状態なしデータI/O 3.9 小規模プログラム設計 3.9.1 設計方法 3.9.2 プログラム設計の例 3.9.3 ソフトウェアコンポーネント 3.9.4 スタンドアロンプログラムの例 3.10 練習問題 第4章 宣言的並列性 4.1 データ駆動並列モデル 4.1.1 基本概念 4.1.2 スレッドの意味 4.1.3 実行列 4.1.4 宣言的並列性とは何か？ 4.2 スレッドプログラミングの基本的技法 4.2.1 スレッドを生成すること 4.2.2 スレッドとブラウザ 4.2.3 スレッドを使うデータフロー計算 4.2.4 スレッドのスケジューリング 4.2.5 協調的並列性と競合的並列性 4.2.6 スレッド操作 4.3 ストリーム 4.3.1 基本的生産者／消費者 4.3.2 変換器とパイプライン 4.3.3 資源を管理し，処理能力を改善すること 4.3.4 ストリームオブジェクト 4.3.5 ディジタル論理のシミュレーション 4.4 宣言的並列モデルを直接使うこと 4.4.1 順序決定並列性 4.4.2 コルーチン 4.4.3 並列的合成 4.5 遅延実行 4.5.1 要求駆動並列モデル 4.5.2 宣言的計算モデル 4.5.3 遅延ストリーム 4.5.4 有界バッファ 4.5.5 ファイルを遅延的に読み込むこと 4.5.6 ハミング問題 4.5.7 遅延リスト操作 4.5.8 永続的キューとアルゴリズム設計 4.5.9 リスト内包表記 4.6 甘いリアルタイムプログラミング 4.6.1 基本操作 4.6.2 ティッキング(ticking) 4.7 Haskell言語 4.7.1 計算モデル 4.7.2 遅延計算 4.7.3 カリー化 4.7.4 多態型 4.7.5 型クラス 4.8 宣言的プログラムの限界と拡張 4.8.1 効率性 4.8.2 モジュラ性 4.8.3 非決定性 4.8.4 現実世界 4.8.5 正しいモデルを選ぶこと 4.8.6 拡張されたモデル 4.8.7 異なるモデルを一緒に使うこと 4.9 進んだ話題 4.9.1 例外を持つ宣言的並列モデル 4.9.2 さらに遅延実行について 4.9.3 通信チャンネルとしてのデータフロー変数 4.9.4 さらに同期について 4.9.5 データフロー変数の有用性 4.10 歴史に関する注記 4.11 練習問題 第5章 メッセージ伝達並列性 5.1 メッセージ伝達並列モデル 5.1.1 ポート 5.1.2 ポートの意味 5.2 ポートオブジェクト 5.2.1 NewPortObject抽象 5.2.2 例 5.2.3 ポートオブジェクトに関する議論 5.3 簡単なメッセージプロトコル 5.3.1 RMI(遠隔メソッド起動) 5.3.2 非同期RMI 5.3.3 コールバックのあるRMI(スレッド使用) 5.3.4 コールバックのあるRMI(継続のためのレコード使用) 5.3.5 コールバックのあるRMI(継続のための手続き使用) 5.3.6 エラー報告 5.3.7 コールバックのある非同期RMI 5.3.8 二重コールバック 5.4 並列性のためのプログラム設計 5.4.1 並列コンポーネントを使うプログラミング 5.4.2 設計方法 5.4.3 並列性パターンとしての機能的構成要素 5.5 リフト制御システム 5.5.1 状態遷移図 5.5.2 実装 5.5.3 リフト制御システムの改良 5.6 メソッド伝達モデルを直接使用すること 5.6.1 1つのスレッドを共有する複数のポートオブジェクト 5.6.2 ポートを使う並列キュー 5.6.3 終点検出を行うスレッド抽象 5.6.4 直列依存関係の除去 5.7 Erlang言語 5.7.1 計算モデル 5.7.2 Erlangプログラミング入門 5.7.3 receive操作 5.8 進んだ話題 5.8.1 非決定性並列モデル 5.9 練習問題 第6章 明示的状態 6.1 状態とは何か？ 6.1.1 暗黙的(宣言的)状態 6.1.2 明示的状態 6.2 状態とシステム構築 6.2.1 システムの性質 6.2.2 コンポーネントベースプログラミング 6.2.3 オブジェクト指向プログラミング 6.3 明示的状態を持つ宣言的モデル 6.3.1 セル 6.3.2 セルの意味 6.3.3 宣言的プログラミングとの関係 6.3.4 共有と同等 6.4 データ抽象 6.4.1 データ抽象を組織する8つの方法 6.4.2 スタックの変種 6.4.3 多態性 6.4.4 引数受け渡し 6.4.5 取り消し可能資格 6.5 状態ありコレクション 6.5.1 インデックス付きコレクション 6.5.2 インデックス付きコレクションを選ぶこと 6.5.3 その他のコレクション 6.6 状態に関する推論 6.6.1 不変表明 6.6.2 例 6.6.3 表明 6.6.4 証明規則 6.6.5 正常終了 6.7 大規模プログラムの設計 6.7.1 設計方法 6.7.2 階層的システム構造 6.7.3 保守性 6.7.4 将来の発展 6.7.5 さらに深く知るために 6.8 ケーススタディ 6.8.1 遷移的閉包 6.8.2 単語出現頻度(状態あり辞書を使用する) 6.8.3 乱数を生成すること 6.8.4 口コミシミュレーション 6.9 進んだ話題 6.9.1 状態ありプログラミングの限界 6.9.2 メモリ管理と外部参照 6.10 練習問題 第7章 オブジェクト指向プログラミング 7.1 継承 7.2 完全なデータ抽象としてのクラス 7.2.1 例 7.2.2 この例の意味 7.2.3 クラスとオブジェクトを定義すること 7.2.4 クラスメンバ 7.2.5 属性を初期化すること 7.2.6 第1級メッセージ 7.2.7 第1級の属性 7.2.8 プログラミング技法 7.3 漸増的データ抽象としてのクラス 7.3.1 継承グラフ 7.3.2 メソッドアクセス制御(静的束縛と動的束縛) 7.3.3 カプセル化制御 7.3.4 転嫁と委任 7.3.5 内省 7.4 継承を使うプログラミング 7.4.1 継承の正しい使い方 7.4.2 型に従って階層を構成すること 7.4.3 汎用クラス 7.4.4 多重継承 7.4.5 多重継承に関するおおざっぱな指針 7.4.6 クラス図の目的 7.4.7 デザインパターン 7.5 他の計算モデルとの関係 7.5.1 オブジェクトベースプログラミングとコンポーネントベースプログラミング 7.5.2 高階プログラミング 7.5.3 関数分解と型分解 7.5.4 すべてをオブジェクトにすべきか？ 7.6 オブジェクトシステムを実装すること 7.6.1 抽象図 7.6.2 クラスを実装すること 7.6.3 オブジェクトの実装 7.6.4 継承の実装 7.7 Java言語(直列部分) 7.7.1 計算モデル 7.7.2 Javaプログラミング入門 7.8 能動的オブジェクト 7.8.1 例 7.8.2 NewActive抽象 7.8.3 フラウィウス・ヨセフスの問題 7.8.4 その他の能動的オブジェクト抽象 7.8.5 能動的オブジェクトを使うイベントマネージャ 7.9 練習問題 第8章 状態共有並列性 8.1 状態共有並列モデル 8.2 並列性を持つプログラミング 8.2.1 さまざまな手法の概観 8.2.2 状態共有並列モデルを直接使うこと 8.2.3 原子的アクションを使うプログラミング 8.2.4 さらに読むべき本 8.3 ロック 8.3.1 状態あり並列データ抽象を構築すること 8.3.2 タプル空間(Linda) 8.3.3 ロックを実装すること 8.4 モニタ 8.4.1 定義 8.4.2 有界バッファ 8.4.3 モニタを使うプログラミング 8.4.4 モニタを実装すること 8.4.5 モニタの別の意味 8.5 トランザクション 8.5.1 並列性制御 8.5.2 簡易トランザクションマネージャ 8.5.3 セルについてのトランザクション 8.5.4 セルについてのトランザクションを実装すること 8.5.5 トランザクションについてさらに 8.6 Java言語(並列部分) 8.6.1 ロック 8.6.2 モニタ 8.7 練習問題 第9章 関係プログラミング 9.1 関係計算モデル 9.1.1 choice文とfail文 9.1.2 探索木 9.1.3 カプセル化された 9.1.4 Solve関数 9.2 別の例 9.2.1 数値例 9.2.2 パズルとnクイーン問題 9.3 論理型プログラミングとの関係 9.3.1 論理と論理型プログラミング 9.3.2 操作的意味と論理的意味 9.3.3 非決定性論理型プログラミング 9.3.4 純粋Prologとの関係 9.3.5 他のモデルにおける論理型プログラミング 9.4 自然言語構文解析 9.4.1 簡単な文法 9.4.2 この文法に従う構文解析 9.4.3 構文木を生成すること 9.4.4 限定記号を生成すること 9.4.5 パーサを走らせること 9.4.6 パーサを「逆向きに(backward)」走らせること 9.4.7 単一化文法 9.5 文法インタプリタ 9.5.1 簡単な文法 9.5.2 文法のコード化 9.5.3 文法インタプリタを走らせること 9.5.4 文法インタプリタを実装すること 9.6 データベース 9.6.1 関係を定義すること 9.6.2 関係を使って計算すること 9.6.3 関係を実装すること 9.7 Prolog言語 9.7.1 計算モデル 9.7.2 Prologプログラミング入門 9.7.3 Prologプログラムを関係プログラムに翻訳すること 9.8 練習問題 第2部 特殊化された計算モデル 第10章 グラフィカルユーザインタフェースプログラミング 10.1 宣言的／手続き的方法 10.2 宣言的／手続き的方法を使うこと 10.2.1 基本的ユーザインタフェースの要素 10.2.2 GUIを構築すること 10.2.3 宣言的座標 10.2.4 リサイズ時の宣言的振る舞い 10.2.5 ウィジェットの動的振る舞い 10.3 対話的学習ツールPrototyper 10.4 ケーススタディ 10.4.1 簡単なプログレスモニタ 10.4.2 簡単なカレンダウィジェット 10.4.3 ユーザインタフェースの動的生成 10.4.4 状況順応時計 10.5 GUIツールを実装すること 10.6 練習問題 第11章 分散プログラミング 11.1 分散システムの分類 11.2 分散モデル 11.3 宣言的データの分散 11.3.1 オープン分散と大域的ネーミング 11.3.2 宣言的データを共有すること 11.3.3 チケット配布 11.3.4 ストリーム通信 11.4 状態の分散 11.4.1 単純状態共有 11.4.2 分散字句的スコープ 11.5 ネットワークアウェアネス 11.6 共通分散プログラミングパターン 11.6.1 静的オブジェクトとモバイルオブジェクト 11.6.2 非同期的オブジェクトとデータフロー 11.6.3 サーバ 11.6.4 クローズド分散 11.7 分散プロトコル 11.7.1 言語実体 11.7.2 モバイル状態プロトコル 11.7.3 分散束縛プロトコル 11.7.4 メモリ管理 11.8 部分的失敗 11.8.1 失敗モデル 11.8.2 失敗処理の簡単な場合 11.8.3 回復可能サーバ 11.8.4 アクティブフォールトトレランス 11.9 セキュリティ 11.10 アプリケーションを構築すること 11.10.1 まずは集中，後に分散 11.10.2 部分的失敗に対処すること 11.10.3 分散コンポーネント 11.11 練習問題 第12章 制約プログラミング 12.1 伝播・探索法 12.1.1 基本的考え方 12.1.2 部分情報を使って計算すること 12.1.3 例 12.1.4 この例を実行すること 12.1.5 まとめ 12.2 プログラミング技法 12.2.1 覆面算 12.2.2 回文積再訪 12.3 制約ベース計算モデル 12.3.1 基本的制約と伝播子 12.3.2 計算空間の探索をプログラムすること 12.4 計算空間を定義し，使うこと 12.4.1 深さ優先探索エンジン 12.4.2 検索エンジンの実行例 12.4.3 計算空間の生成 12.4.4 空間の実行 12.4.5 制約の登録 12.4.6 並列的伝播 12.4.7 分配(探索準備) 12.4.8 空間の状態 12.4.9 空間のクローン 12.4.10 選択肢を先に任せること 12.4.11 空間をマージすること 12.4.12 空間失敗 12.4.13 空間に計算を注入すること 12.5 関係計算モデルを実装すること 12.5.1 choice文 12.5.2 Solve関数 12.6 練習問題 第3部 意味 第13章 言語意味 13.1 一般的計算モデル 13.1.1 格納域 13.1.2 単一代入(制約)格納域 13.1.3 抽象構文 13.1.4 構造的規則 13.1.5 直列実行と並列実行 13.1.6 抽象マシンの意味との比較 13.1.7 変数導入 13.1.8 同等性の強制(tell) 13.1.9 条件文(ask) 13.1.10 名前 13.1.11 手続き抽象 13.1.12 明示的状態 13.1.13 by-need同期 13.1.14 読み出し専用変数 13.1.15 例外処理 13.1.16 失敗値 13.1.17 変数置き換え 13.2 宣言的並列性 13.2.1 部分停止と全体停止 13.2.2 論理的同値 13.2.3 宣言的並列性の形式的定義 13.2.4 合流性 13.3 8つの計算モデル 13.4 よくある抽象の意味 13.5 歴史に関する注記 13.6 練習問題
デヴィ夫人のブログを読んで本気で気持ち悪くなった。ああいった意見を持った人間がいること自体はともかく、それに対して｢よく言った！｣｢日本人の誇りだ！｣みたいなコメントがついてるのを見るとぞっとする。痴漢冤罪は被害者立場を利用した女性からの迫害だから女が悪い！痴漢は性欲を催させるような格好をしているような女が悪い！という免責をしてミソジニー丸出ししてる浅い思考が透けて見えて本当に気持ち悪い。おまけにそれをそのまま強姦に適用しているあたり、女にとって名誉ある男に犯されるのはどういった形であれ幸福であり、それを盾にああいった騒ぎを起こすなんてとんでもない、というような視線まで感じられる。ひっでぇ。それで、朝からそんなものを見かけたせいでテンション下がりまくりな状態で俺は考えたわけである。セックスとは何ぞや。性欲とは何ぞや。もちろん実際に経験がない人間なわけだから限界はあるだろうけれど、それを考えることは無意味じゃないだろうってことで。
そもそも俺が今まで性について触れてきたのって、大体はエロゲや官能小説、エロマンガ、AVというものが殆どで、学校の性教育は全然薄かった。せいぜいが性病の感染に気をつけてくださいねーくらいで、それ以外の部分については一切なし。だから自然とそういうメディアで興奮するようになっていたわけだけど、やっぱりどうしてもそれはオナニーでしかない。セックスではない。セックスっていうのは二人の関係の中で起こる行為だからだ。単なる性欲の発散以上の意味合いを持っていて欲しい、と思う。しかし男にとってそれが難しいのは、どうしても性欲というスイッチがあることだ。それなりに単純なこのスイッチは割と簡単に入るし、条件次第ではそれのことしか考えられなくなる。股間でものを考えてしまう状態というのがどうしてもそこにあるわけだ。ただ、そういった本能のまま、衝動のままの性欲を人間を相手にぶつけるってのは、俺はどうしても肯定できない。だって相手は人間なのだ。自分と同じように考えたり感じたりする人間相手にありのままの性欲をぶつけるってことがどうしても耐えられない。性欲は乱暴な面もあるし、おまけに男はチンコ突っ込んで射精してあーきもちよかった、で済ませられてしまう。それってセックスじゃねえじゃん、と思うわけだ。生身の人間の膣を使ったオナニーでしかない。人間はオナホールじゃないんだぞ。もちろん、そういった性欲の存在は否定しないし、発散する手段はあっていい。そのためにポルノメディアはあるんだと思う。オナニーに際してそれを用いることには俺は賛成だ。確かに「悔しい、でも感じちゃう(ﾋﾞｸﾝ」なメソッドには興奮する。するよ。ちんぽギンギンだよ。でもそれを、もし生身の相手のにんげんにやって、おまけに相手が嫌がってたら、それ、やめるべきでしょ？
あと、恋愛は性欲をデコレーションしただけのことだ、なんて言葉に浸って恋愛の不可能性を指摘した気になっているような奴はどうにかしたほうがいいと思う。恋愛に性欲は不可欠だけど、それをどう運用していくかってことが大事であって、セックスのないプラトニックな恋愛＝清純＝理想、セックスのある恋愛＝生々しい＝現実、みたいな稚拙な二項対立に持ってくのだけは童貞として避けていきたい。セックスのあるプラトニックな関係だってあっていいし、セックスのない生々しい関係だってあっていいじゃないですか(そこんとこどうなんですか恋愛経験者の皆さん)。
大事なのは、セックスっていうのは二人のものだってこと。だから普段は仲が良いのに彼氏から乱暴なセックスされてつらいだとか、別れるのが怖くてしたくもないセックスばっかりさせられた、みたいな話を聞くたびに俺はもうやるせなくなってくる。なにやってんだよと。せっかく相手に触れていい、そういうことをしていいっていう関係を築けてるのに、どうしてそこでそうやってしまうんだよ、と。別にうらやましいんじゃなくて(まあ嫉妬だといわれたらそうなってしまうんだろうけど)、なんというか、悔しい。ある程度人と関わっていくことができるような人間にとって、恋愛やセックスって、傷つくことも嫌なこともたくさんあるけど、それと同じ、それ以上に嬉しいことや喜ばしいことがあっていいはずじゃないか。なんでそこで傷つけるだけで終わらせてしまうのかがわからない。なんでだよ。
もちろん性に対しておおっぴらにしろってわけじゃないけど、でも、たとえばセックスが終わった後に、お互いに自由に感想を交わせるような習慣があっていいんじゃないか。女性の側も男性の側も、痛かっただとか、もうちょっと優しくして欲しいだとか、そこを触られたのは気持ちよかっただとか、そういうことをやって、二人でセックスを作り上げていくべきだろ。そうじゃなきゃセックスじゃねぇって。形だけの同意とってんじゃねえよ。悔しくても感じてるって勝手に信じるなよ。本当にセックスできるのか考えろよ、性欲を上手に乗りこなせよ。ポルノメディアみたいなセックスのことを考えるなら、そうでないセックスのことを考えてもいいじゃないか。男が女にセックスしてやる、チンポ突っ込んでよがらせてやるよ、みたいなセックスじゃなくて、清濁併せ呑んで二人だけのセックスを試行錯誤して作り上げていけよ。そうであってくれよ。
だから、こういうレイプだとか性犯罪に関して、セックスを通じて性暴力という形で人が人を傷つけてしまった、不快な思いをさせたってのはだめだ。しかも今回は立場とかの問題も絡んでる。それなのにデヴィ夫人のブログとかそこにつくコメントみたいな意見が支持されるのはやるせない。鈍感にもほどがある。俺はそう思う。
……そう思うんだけど、なんつーか、あくまで童貞の理想論であることも認める。ので、セックスしたことある人、嫌だったセックスをさせられたことのある人、俺みたいな意見って、どうなんでしょう。以上。
