  |
はてなキーワード: メソッドとは
頭よくなりたい。筋肉ムキムキになりたい。
人には実に色々な願望がありますが、ほとんどが実現されないのが現実ではないでしょうか。
ちなみにお察しの通り、上に書いたものはすべて私の今の願望です。
こういった願望を抱くという事は、現状はすべて逆であるということです。
でもどうしても願望を実現し、現状を変えたいという強い思いだけはあります。
そして強い思いだけもって特に何も変わらない、悶々とした日々をすごしてきました。
が、昨日我が家の本棚に「引き寄せの法則」「ザ・キー」という2冊の本を見つけました。
これは母が何年か前に買った本で、今まで特に気にしていなかったのですが
昨日なぜか急にこの本が目に入ったのです。
母に聞いたところ、「結局宗教っぽくてあんま面白くなかったよ」といわれました。
しかしとても気になってしまい昨晩と今朝で一気に2冊読んでみました。
確かに宗教っぽい。でもこれ全部マジだったら俺も変われるかもｗ
とりあえず「引き寄せの法則」よりも「ザ・キー」の方が自分にはわかり易かったので
こっちに書いてあったメソッドとかを一通りやりながら願望を実現してみる。
本当はもっと書いてありましたが、自分の中で印象に残った部分だけ抜粋しました。
では、順に実行していきます。
まず、引き寄せの法則とは、僕らが何か思考すると、それを宇宙が受け取って あとは勝手に現実にそれを物質化して叶えてくれる。 ボールを真上に投げたら、重力によってまた自分のとこまで戻ってくるのと同じように 例外なく自分の思考はすべて現実のものとなっている。という法則のことです。 これがなかなか実現出来ないのは、例えば「超絶美人なお姉さんとHな事したい！」と思考したときに 「でも俺ブサイクだし、そんなお姉さんにすかれるわけがない。」とか「第一出会いがねーし！」みたいな 思い込みによってこの願望は実現を阻まれているそうです。 だから、この思い込みをクリアにすれば願い事はすべてかなうのです！ というのが一番最初に書かれてました。
まず1億円くらい手にする。 免許を取って車とバイクを買う。 顔が向井理みたいにイケメンになる。 体がジェイソンステイタムのようにマッチョになる。 スポーツ万能になり、フットサル・テニス・ボーリング・ゴルフ・ダーツなどの 大会で全て優勝する。 1ヶ月で10カ国以上を旅する。移動の飛行機は全てファーストクラス。 頭がよくなり、業界で世界的に有名な人間になる。 かわいい子にモテるようになり、セフレが５，６人くらい出来る。 風俗に週２で通う。
結構遠慮しませんでしたが、1億円は「さすがに10億は行きすぎだろ」 とか考えてたので、1000億くらい手にする。に変更。 あと、スポーツの大会は「外人には勝てないよね」って思って国内を想定してたので 世界大会で優勝に変更。 旅行の部分は「10カ国とか時間的にキツいかな？」とか考えてたので 1ヶ月で30カ国に変更。
著者の友人はこんなことを言ったそうです。
多くのひとはその瞬間を生きていない。
常に、つぎの契約、つぎの車、つぎの家、つぎの昇給について考えていて、
パワーの基点、つまり、真の奇跡がいまここにあるということに気づいていない。
「ザ・キー」P75より
確かに、僕も今足りないものばかりだから、これが満たされたら幸せになれると思ってました。 でも、つぎばかり求めてると、つぎが来た時にはまた「つぎのつぎ」を求めるようになり 結局いつまでたっても幸せになれないのだそうです。なるほど。 で、ここでは自分が今感謝できることをひたすら書いていきます。 特に大きな病気もなく健康に暮らせている。 家族もみな健康である。 毎日行く場所がある。 毎日おいしいご飯が食べれている。 適度に遊べている。 面白い友人達に毎日会える。 たくさん寝れてる。 帰る家がある。しかも駅から近くて綺麗で広い。 車も原付もほぼ好きな時に寝れる。 書き出してみるとかなり恵まれてると思ったｗ
「愛してる」って言う。というか心で唱えるだけでも問題を解決することを
妨げているものを除去することが出来るらしい。
これからはよく唱えるようにしよう。
自分が望むことをシナリオのように、既に起こったこととして書くと
その通りになるらしい。
私は、はてなの匿名ダイアリーを書いていました。そこには自分が願望実現を リアルタイムで実践していく様子を記していました。 一度書き終えてから、たまたま通りすがった宝くじ屋でスクラッチタイプのくじを2枚購入。 その際には先ほどの教えに従って、売り場のおばちゃんに「愛してます」といいました。(心のなかで) しばらく歩いていると、後ろから急に「おにーさん！」と肩を叩かれ、驚きながら振り返るとめちゃくちゃ可愛いギャルが・・・ きっと美人局に違いないと思った僕は「すいません」と言い残し足早にその場を去ろうとしました。 しかしギャルは「今何してるのー？？どうせ暇なんでしょー！カラオケでも行こうよっ☆」と満面の笑みで誘ってきます。 「か・・・可愛い・・」それでもまだ美人局の可能性を完全には否定できないと思った僕は「ごめんないさい。用事があるので」と ギャルの誘いを断ってしまいました。これが引き寄せの法則の力だとしてもさすがにいきなりは怖いと思ったので自分的には 正しい判断だと思います。結局メアドだけ交換してギャルは去っていきました。 生まれて初めての逆ナンにテンションがあがった僕はまたもや目に入って来た宝くじ屋で今度は5枚 スクラッチタイプのクジを購入しました。 近くにあった漫画喫茶に入り、買った7枚のスクラッチクジを一つ一つ丁寧に削っていきます。 この時、なぜか高額当選が当たり前かのような気分に浸っていました。 そして4枚目のクジを削ったときに見事1等当選！！！ 当たり前とは思っていたものの、思わず叫びそうになるのを必死に押さえ、喜びをかみしめます。 残りの3枚を削ってみると、ほかにも3等と200円の当選が各1枚ずつまぎれていました。 自分の身に起こったシナリオ通りの事態に足を震わせながら換金へと向かいました。 換金後はもちろん先ほどのギャルに連絡し、早速遊びに行っちゃいました。
さて、とりあえず今から、気持ちい気分で最後に書いたシナリオの場面を想像し
※購入後につづきを書きます。
待っていた人などいないと思いますが、皆様お待たせいたしました！
結果報告！！
逆ナン：されず・・・でも可愛いギャルとたくさんすれ違いました。
スクラッチ：購入しましたが、今の気持ちだと何か当たらないような気がするので
正確にはわかりませんが、少し調べた結果エゴが原因なんじゃないか。
という仮説にいたりました。
では、逆ナンされるのを期待しながら歩いてたときの自分の思考を振り返ってみます。
「可愛いギャルからナンパされるかな～」 「いくら引き寄せの法則とは言えど、ありえないかなぁ」 「ありえないとかって感情を抱いた時点で無理かな」 「いや、ありえなくない！でも逆ナンされたときの気持ちい感情を味わえって書いてあったな」 「そもそも逆ナンされたことないから感情とかワカンなくね？」 「とりあえずワクワクしてみよう！！」 「ワクワク・・・これでいいのかなぁ・・」 と、いう具合に自分の中のエゴが 「逆ナンなんてありえない！引き寄せの法則などあったとしても お前のやり方は間違っている！」 って言ってる気がして、自信を喪失してたようにも思います。
そこで、エゴにはそんな能力すらないのだから、否定的な気持ちになるのを
理解してあげつつ、さよならと言って消し去ればよいらしい。
ちなみに、調べてたら「100%バカになる方法」というのを見つけた。
初めて風俗に行ってきたので考えたこと、感じたことをつらつら書いていこうと思う。
以下感想。
※ブコメで頻出している「1万6千円って安すぎだろう」という突っ込みに対する応答も含め、補足を書いたのでそちらも参照してもらえると幸いです。
横だけどそれはなんかちょっと違うと思うよ
アニメの売り上げで「爆死ｗｗｗｗ」とか「爆売れ大勝利ｗｗｗｗ」とか言ってるアニオタは確かに見るけど
あれは半分以上はネタだと思う
みたいなね
好きなアニメがヒットと言える売り上げを叩き出したら祝うけど
「こんなにたくさんの人から認められているアニメのよさがわかる自分は凄い」みたいな
何かと競争して大勝利ってことじゃない
ここまで押し上げたい、っていう気持ちでお金注ぎ込むんでしょ
似て非なるもんだよ
っていうかアニオタはアニオタで条件が合致すれば凄い額を作品に注ぎ込むメソッドはあるんだから
Web屋のネタ帳( http://neta.ywcafe.net/ )様の
これからの「パスワード」の話をしよう( http://neta.ywcafe.net/001184.html )で
紹介されているパスワードのハッシュ化のバグについて突っ込んでみる
「１回ハッシュ化を解読できただけ、プレーンパスワードを入手することが可能である」
というものである。
問題の部分はここ
/**
* 平文のパスワードをハッシュ＆stretchするメソッドです。
* loop回数は1000としていますが、999でも1001でもお好みでどうぞ。
* ただしループ回数は処理時間に直結しますのでほどほどの数値で。
*/
private static final String hashAndStretch(String plainPasswd, String salt) {
int loop = 1000;
String hashedPasswd = "";
for (int i = 0; i < loop; i++) {
hashedPasswd = DigestUtils.sha256Hex(hashedPasswd + plainPasswd + salt);
}
return hashedPasswd;
}
＜凡例＞
ソルト：SSSSSSSS
＜トレース＞
XXXXXXXX ← DigestUtils.sha256Hex("YYYYYYYY" + "PASSWORD" + "SSSSSSSS")
クラッカーがXXXXXXXXXのハッシュ値を解析し、元の文字列が「YYYYYYYYPASSWORDSSSSSSSS"」と判明したとする。
この時点で元文字列の中にプレーンパスワードが含まれていることになる。
また、ハッシュ化された文字列には「0123456789abcdef」の文字しか含まれておらず、
「それ以外の文字が含まれていた場合容易にプレーンパスワードではないか」
一般的なパスワードには少なからず「0123456789abcdef」以外の文字が含まれているだろうし、
上記のことをふまえてプログラムを修正すると。。
/**
* 平文のパスワードをハッシュ＆stretchするメソッドです。
* loop回数は1000としていますが、999でも1001でもお好みでどうぞ。
* ただしループ回数は処理時間に直結しますのでほどほどの数値で。
*/
private static final String hashAndStretch(String plainPasswd, String salt) {
int loop = 1000;
String hashedPasswd = DigestUtils.sha256Hex(plainPasswd + salt);;
for (int i = 0; i < loop; i++) {
hashedPasswd = DigestUtils.sha256Hex(hashedPasswd + DigestUtils.sha256Hex(salt + i));
}
return hashedPasswd;
}
「ファッションそのものに大して興味はないけど、対人メソッドとしてそれなりに小ぎれいにしておきたい」って感じの布陣だな
たぶん、脱オタぐらいにちょうどいい感じ
男性のみなさんこんにちは。今日は「スレンダー巨乳」という夢のような女性との暮らしを手に入れるための、4つの簡単なメソッドをご紹介します。
ここは頑張ってなんとかしてください。この時点で女性が「スレンダー巨乳」である必要はありません。
「ちょっとぽっちゃりぐらいが健康的ですてきだよ」とかなんとか言っておけば、女性は大喜びでスイーツ()をmogmogします。うまく誘導すれば「寛大な彼氏 / 旦那」という評価もゲットできるでしょう。
膣内射精はとてもきもちいい、という嬉しいオマケがついてきます。なお、妊娠が発覚した時点で入籍しておいたほうが社会的に無難でしょう。
授乳期間中、女性の胸は相当大きくなります。しかもカロリーはほとんど母乳に行くので、相当量食べても痩せ続けます。
しかも、赤ん坊が激しく吸い付くので、乳首が一皮むけてピンクになる、という嬉しいオマケがついてきます。
授乳期間が終わっても同じペースで食べつづけると、あっという間に「スレンダー」は失われてしまいます。そうなったら、3番目のメソッドから繰り返しましょう。
いかがでしたでしょうか。スレンダー巨乳との暮らしを手に入れた上に、かわいい子供までできました。もうしばらくしたら、近所の児童館でお会いするかもしれませんね。
２０ミリシーベルト問題だが、実は放射線医学専門家は引き下げを主張したが、
文部科学省側が２０ミリシーベルト維持を押し切った、という未確認情報がある。
真相は未確認だが、私見では「さもありなん」という気がする。
より深刻なんじゃないか、と思う。
「自分たちが気付きあげた教育メソッドこそ最高」と固執して方針転換が遅れたり、
他学会から「教育界の常識を否定」された際にも直視しなかったりする。
例えば「教室の天井高は高ければ高いほうがいい」と教育界では信じられてきて、
文部官僚は地方自治体から申請あった「天井高の規制緩和」をかたくなに拒否してきたが、
しぶしぶ埼玉県で認めたところ、「かえって天井高が低くした方が、児童は心理的に落ち着く」という
あるいは「教育効果を上げるには少人数教室が最善」と教育関係者（文部官僚も日教組も）は主張し続けているが、
経済学者から「少人数教室にすると、トップ層が切磋琢磨しなくなり、かえって全体の平均学力は落ちる」と
今回の件についても、文部官僚は「屋外での体育活動が重要」とか
「子を疎開させて親と別離することは精神的に問題」という「もっともらしい理由」で
「できるのであれば２０ミリシーベルトを貫いて、中通りで極力平常どおりの教育をしたい」という思惑を貫こうとしている。
彼らは「体育活動が重要」「親子のコミュニケーションが重要」という「従来からの教育メソッドの固執」という発想しかできない。
緊急時には、それこそ体育授業の１年間停止とか学童疎開という非常手段も求められるのに、
そういう「従来の延長線上からかけ離れた措置」を文部官僚は非常に嫌がる。
前例踏襲主義、という点では、文部科学省、もっと言えば旧文部省こそ、「官僚の中の官僚」である。
福島の児童の不幸は、官僚の中の官僚に学校運営権を牛耳られたことである。
http://anond.hatelabo.jp/20110422235719
ブコメで「エヴァに呪われている」とか「エヴァ脳の恐怖」とか「エヴァをアニメの物差しにしている」といったコメントを見て、なるほど的を得ているなと。
そして残念ながらid:kyo_ju、ネタじゃない。マジで書いた内容なんだ…orz
てか自分でもマジでエヴァ脳だと思う。じゃなきゃ増田で書かない。
俺がこんなコメントを普通のブログに投稿してる奴をみたら、とりあえず全力で叩く。
何でだ？
自分なりに考えてみたんだが、エヴァに前のめりで楽しんでた人達、というか後ろに引いて見ることが出来なかった人達は、
エヴァが終わった後の娯楽としてそれぞれ別個の道に進んで行ったかと思う。
まずアニメという枠に傾倒する道。
アニメは当時の世相を反映してか「自分探し」のような内容か、あるいは「萌え」に特化した内容ばかりだった。
自分探し的な部分は十分エヴァで堪能したし、萌えは視聴者が勝手に後付けするものであって主食として作者が提供するものじゃないものと考えているので無理だった。
SFは─漫画だろうと小説だろうと、作者の設定自慢ばかりで人の営みが希薄なのが多かった。「イカにSの面白さを最大化するか？」が最大の関心事になっている世界だった。
Fだけでいいから人間ドラマが欲しくてSFの道には進まなかった。
※その中で何故か『BLAME！』だけは面白いと思ってた。我ながらかなり謎。
「設定？誰がんなもん語るか。察しろ。」というスタンスがよかったのかも知れない。
あるいは設定の説明がない分、人間(と愉快なクリーチャー達)の営みに思考が集中できたせいかも知れない。
自分は娯楽なしで生きられるような人間ではない。おそらくは他の人もそうだと思う。
大人になって仕事や家事に忙殺されても、アウトドアや人付き合い以外の何かしらの娯楽を大なり小なり楽しんでるんじゃないか。
人によって、それが映画だったり、ドラマだったり、推理モノだったり、歴史モノだったりすると思う。
自分は「エヴァの次の娯楽」として、最終的に「古いモノ」を選んだ。
小説に手をだし、散々色々な誇大広告に騙された結果、最低10年以上「これは良い」と語られる小説は、少なくとも個人の趣味で好き嫌いはあっても外れはないことに気づいたからだ。
そしてこの単純な法則が、小説という枠だけでなく他の枠にも当てはまることを知った。
「古いモノ」を楽しむコツとして、「その当時の世相や時代背景を同時に知る」ということ。
今ではやや物足りない部分があったとしても、当時としては革新的な技術や手法、あるいは独自の視点が盛り込まれていたために長らく語り草になることが多い。
それと同時に他人の解釈をガン無視すること。例えるなら、どれだけ権威ある人が「このキャラはツンデレだから萌え」と言っても自分が「ツインテールだから萌えであってツンデレなのはどうでもいい」なら自分の直感に従って楽しむこと。
こんな風に古いモノ、かつ娯楽として時代の振り落としを生き抜いたモノを、自由気ままなオレオレ解釈で楽しみ、アニメを見なくなった結果、自分はアニメの物差しはエヴァとジブリと千年女優だけになったorz
敢えて弁明、というか開き直らせていただければ…
だって仕方ないじゃん！1年間で1割より少ない程度で面白いアニメは出てると思うよ？
けどその1割弱を探すためだけにアニメの世界に飛び込めば、まさに「渡る世間は萌えばかり」、あるいは「前門の厨二アニメ、後門の監督が厨二の自称芸術unkoアニメ」ばかりじゃん！
アニメの作り手にしても、ちょっと成功して有名になるとすぐ芸術気取りしたり宮崎駿の後継者気取りしてばっかじゃん！
そんな中途半端なことをするくらいなら、いっそワーグナーみたく「アニメはただの芸術じゃない。神聖な祭事だ！」ぐらい突き抜けつつ「よろしい！私に投資する権利をやろう！」的なノリで資金調達＆製造とかやれるだけの実力と人間としてゲスな気概を持って挑めよ！＞ヤマカン、細田
特に'00年代は酷かったよ！観客の声を聞かずに監督が見たいアニメか、大向うの観客の声しか聞いていないアニメばっかだったよ！
「そもそも今客席にいない人を、どうやって小屋に来てもらうか」を考えている人なんて皆無だったよ！
00年代はまだブロードウェイ- ミュージカルの方が観客を呼ぶためのモノ作りをしてるよ…
例えば「Wicked」はファンタジーで低年齢児を釣り、女の友情で少女を釣り、あげくに社会派的要素で親を釣り上げる万能釣り竿だよ。
「Next to Normal」なんて狂気の中から家族愛を導き出すーそれも母親が主役でーっていう化け物ミュージカルだよ。
ミュージカルってさ、親しみが無い人には「子供が見るモノ」あるいは「軽いモノ」ってイメージがあるんだ。
酷いと「演劇と歌が同居する必要性がないんじゃねーの？」って言われる始末www
まぁ当然だよね。舞台としては戯曲という枠が、歌劇としてはオペラという枠が、ダンスはバレエという枠が、技巧も歴史も名作も持ってる。
けどミュージカルが子供やミュージカル自体にマニアックな人ばかり相手にしてたってお金にならない。
彼らが飯を食っていくためにミュージカルという枠のファンを増やすしか無かった。
かと言って技巧だけで挑めば間違いなく他の枠に負ける。
だから彼らはあらゆるものを取り入れ名作を作り上げた。
例えば古典の悲劇の恋愛をベースに、彼らの身近にあるダンスや風俗、そして身近にありすぎるマイノリティへの差別問題を注入したWSSとかね。
そういったことを繰り返し繰り返し続けた結果、今のブロードウェイミュージカルの地位が出来上がった。
アニメを作ってる側の人からも、「売れない、売れない」という声ばかり聞こえた。
けど自分からしたら、なんでアニメを作ってる人は「今、テレビの前にいない人」を捕まえようとしないんだろうと思ってた。
筋を古いモノから流用し、装飾や人々を今の時代に合わせ、最後の結末に自分たちのメッセージを盛り込む。
これだけでも十分面白いモノが出きるのに。
「守破離」の全部が大事なのに、今のアニメは「守」だけ「破」だけ「離」だけみたいに、個別の実装しかないものが多い気がする。
「魔法少女」っていう小さな視野で見ても、かなり綺麗に守破離してる。もちろん違う角度から見たときにも様々な守破離があるのがまどまぎの魅力。
けど、きっともう後16年くらいは守破離をしっかり出来たアニメは出ないんだろうなぁ…
まどまぎの脚本の人は「ロボットものを書きたい」って言ってるらしいから、おそらくロボットを書くのに夢中になって客席を見なくなるか、大向うの客席しか見なくなる。
そうすると悲劇が好き過ぎる人みたいだし、シェイクスピアを消化しないままシェイクスピアの再発明を得意気にしちゃったりするんだろうなぁ…
かといって他のアニメの作り手は、まどまぎのパラメーターだけみてメソッドを見ず、もっと酷いものを作るんだろうし…
「処女厨がウザい・怖い」的な発言をよく作り手側のコメントで見かけるけど、
なら小デュマみたく処女厨を逆手にとって、ビッチであることが生きるために必然である椿姫を処女厨の目の前に置いて、
「それでもお前らこいつを罵れる？」といけしゃあしゃあと言ってのけるような人は今までいなかったし…
HTMLはわかるけど、サーバーサイドはお遊びでphpを触ったぐらいだったので、会員制でデータをためこむサイト作りに初めて挑戦した。
今回重視したのは、「いかに個人情報をお漏らししないようにして、万が一漏らしても被害を少なくするか」ということ。
世の中、有償サービスでもパスワードを平文で保存してるサービスが意外と多いらしいので、流出した時のリスクを少しでも減らせる対策として書きます。
サーバー：ロケットネットのキャンペーンにでレンタルサーバ年１０００円ポッキリプラン クライアント側の処理：HTML+CSS+jQuery（とプラグインもろもろ） サーバ側の処理：PHP Webサーバー：Apache データベース：MySQL
俺も巻き込まれたところでは、サミータウンがメールアドレスとパスワードセットでお漏らししてお詫びに１ヶ月無料なにそれこわい。
サミータウンだけならまだいいけど、メアドとパスワードを他のサービスで共通化して使ってる情弱なので、
共通化してメアドとパスワードをどこかのサービスが一箇所でも漏らすと、ヤフオクID乗っ取り事件みたいなことになる。
http://internet.watch.impress.co.jp/cda/news/2008/09/26/20967.html
俺だってできれば人様のメールアドレスとパスワードとか預かりたくない。
万が一、肉親のメールドレスを発見してパスワードにrapemeとか入ってたら明日からどういう顔すればいいかわからない。
ググってみてもどこにも情報のってない。うーん困った。ダメもとで「個人情報ってどうやって保存したらいいんだろう。。。」
って、twitterでつぶやいたら、「住所とかは可逆暗号化でいいけど、パスワードはハッシュで不可逆化しないとだめだよ！」
「住所とかは可逆暗号化でいいけど、パスワードはハッシュで不可逆化しないとだめだよ！」
何のことかわからなったので、調べてみると、
・ハッシュ＝ハッシュ値を使った、元のデータに戻せない暗号化方式
うーん。。。よくわからん。。。
電話番号とか住所は、第三者が使用する情報なので、可逆が必要。パスワードは、認証にしか使わないので、
ハッシュ値の結果が一致すれば元のデータがわからなくてもOK、という方式なのでこういった暗号の使い分けをする。
●可逆暗号のイメージ（もとにもどせる） 暗号化キーは開発者が指定する。 090-xxxx-xxxx →（暗号化）→ !'&amp;%($% →（復号化）→ 090-xxxx-xxxx ●ハッシュのイメージ（もとにもどせない） 登録password（DBに保存）→（ハッシュ値抽出）→!"$#'$#=" ログインpassword →（ハッシュ値抽出）→!"$#'$#=" ※二つのハッシュ値が合っていれば、パスワード一致として認証する。
今回はMySQLの関数で実現した。encode関数で暗号化して、decode関数でもとに戻す。
例えばtel_noという項目だけあるテーブルがあるとすると、
//データベースに保存する時 insert into テーブル名 (tel_no) values (encode(tel_no,'暗号化キー')); //データベースから取得する時 select decode(tel_no,'暗号化キー') from テーブル名;
これで、データベース格納時は暗号化（バイナリ化）されて、データベースから取り出してHTML表示する時に復号化はされる。
＜ユーザ登録時＞
$password=（フォームから取得） $hash=hash('sha512',$password) //ユーザ登録時は、ここで生成した$hashをデータベースにぶっこむ。
ユーザ認証時は、入力されたパスワードと、データベースのパスワードが一致するかチェック。
//フォームから入力されたパスワード $input_password=（フォームから取得） $input_hash=hash('sha512',$input_password); //MySQLに保存されたパスワードを取得（略） $db_hash==（データベースから取得） //判定 if($input_hash==$db_hash) echo 'ログインしますよ！'; //ここにログイン処理を書く else die('メアドとパスワードがあってないよ！');
これでもしSQLインジェクションとかでデータが流出しても、ハッシュ暗号のパスワードに関してはまず解析されないはず。。。
可逆暗号のデータもphp側の暗号化キーが盗まれない限りバレない。。。はず。。。
何でもかんでも暗号化するとコードが煩雑になるし、パフォーマンスにも影響でそうなので、
住所データの都道府県とか、漏れても良いような情報は暗号化しませんでした！！
個人情報保護法 2条による定義 「個人情報」とは、生存する個人に関する情報であって、当該情報に含まれる氏名、生年月日その他の記述等により特定の個人を識別することができるもの（他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む。）をいう。
これで、もし漏れても、俺、ウンコ漏らして臭いけど、パンツから出てないからいいよね？というレベルにはなった。はず。
万が一漏れても大丈夫！と書いたけど、そもそも漏らすなというお話になる。色々調べた結果、以下の対策をほどこした。
・当初jQuery側でSQL組み立ててPHPに渡してたので、これだと任意のSQLが実行できて漏らし放題なのでやめる。
・GETとかPOSTでDBに渡すパラメータを扱ってる場合、ちゃんとエスケープする。
例えばログイン認証するPHPで、GETメソッドでフォームからデータを取得するような場合、
$id=$_GET['id'] $pwd=$_GET['pwd'] $sql="select * from ユーザーテーブル where uid='$id' and pwd='$pwd'
とかやってると、login.php?id=admin'&pwd=' OR '1'='1とかパラメータを渡されるとあら不思議！
select *from ユーザテーブル where uid='root' and pwd='' or 1=1
で、誰でもログイン出来ちゃう！ので、mysql_real_escape_stringでエスケープしたり、渡されたパラメータが想定した値かどうか（例えば数値かどうか、とか）のチェックをいれたりする。
・保存するデータにタグやJavascriptを埋め込まれないように、保存されたデータを出力する場合はPHP側でhtmlspecialchars関数使ってエスケープするようにする。
こんな感じでお漏らし対策をした。間違いがあったら教えて欲しい。
ちなみに出来上がったサイトはこれ。
こいつらが何を言い争ってるのか把握したのでまとめた
まずkurahitoが執拗にFrancesco3にセクハラを続けている
「Francesco3とはファックしたくないファックファック」と狂ったように騒ぐkurahito
''kurahito" 因みに実母とファックしたいと思った事はありますが､F子みたいなのが母親だったら
ファックしたいとは思わない｡客観的にw親密に見えたとしても｡ 2010/12/15
"kurahito" 私がファックしたいと思う基準は親密性もさることながら責任能力｡
F子みたいに電波な母親とファックしたら後々面倒に決ってるので桑原という感じ｡教員もしかり。 2010/12/15
ひとりはてブタワーをのぼりながらファックの話を続けるkurahito
みんな遠巻きにしている誰も止められない
ここでNATSU2007登場
"NATSU2007" あーはいはい 貴方の発想って一事が万事「女が俺に欲望されないから嫉妬してる」
しかないんだね。だから「ファックしたくない・お前には欲望しない」と見当違いに吠える。
珍しい心性じゃないが。むしろ何度目だナウシカ。 2011/03/21
"kurahito" これは一般論だが｢夫がロリエロ/近親姦漫画を隠してました。おぞましいです」は嫉妬だと思うが｡ 2011/03/22
嫉妬脳の恐怖wwwwwww
なぜか女から欲望されている事を疑わないのは
キモヲタ全般に共通するが
こいつらの自意識過剰の理由を誰か説明してくれwwwwwwwwww
"NATSU2007" それら全て「欲望されない女の嫉妬」と定義するならゲイ男性も当然忌避される筈だが
逆に好かれてる位だ。さーどうする理屈に合わないな。「ホモが嫌いな女子はいません」が
二次に限るとしても「おこげ」も存在する。 2011/03/23
"kurahito" 浅っ｡腐女子やオコゲは「ヘテ男に欲望されねばならない｣という心的負担のない
安全圏からゲイ男性を視姦してるだけでしょう。 2011/03/23
"NATSU2007" メタブ え、小児性愛者や人形愛者は「ヘテ男」で括られるわけ？幼少年しか欲望しないペドは？
ゲイ男性と同じ立場の筈だが幼女を欲望するペドと同じように"おぞましがられている"と思うんだけど。 2011/03/24
"NATSU2007" メタブ あとこれ"kurahito氏自身"が「ヘテ女に欲望されねばならない｣
痛い所を刺されkurahito泣きながら逃亡wwww
"kurahito" ↓｢異性愛⊃人形愛､近親姦､小児性愛｣なんだが｡私のことを知りもしない癖に
知ったような書方するし､知ってほしいとも思わないし､他者に敬意を払えない
自称ライターさんもウザイからこれ以上レスしません。 2011/03/24
"NATSU2007" メタブ, 性 これじゃ父息子・兄弟の近親姦や少年性愛者も「ヘテロ」となる。
「ヘテ男に欲望されたい女の嫉妬」メソッドではそれらが忌避される説明がつかない。
どこまでもヘテロ目線だから破綻するんだよ。底が浅いのはどっちよ 2011/03/25
(私も散々ナツと呼び捨てにされ失礼な事書かれた)、
知りもしない他人の事を知った様に書いてきたのは貴方じゃないの。
ついでに
知りもしないFrancesco3のことを知ったように論評するkurahitoと
それをブーメラン返しで自覚させるNATSU2007
"kurahito" 私が見聞きした限りではF子は娘に対して異常に他人行儀な気がするんですよね。
異常に距離感が掴めてないというか。｢親子は他人の始り｣をどこかで認識し損ねたかのような。 2011/03/10
"NATSU2007" メタブ, 転移 私が見聞きした限りkurahito氏は母親への恨みを母の表象の
以上
堪忍バッグの緒がきれたNATSU2007がバッサリ斬った構図だが
イメージ操作したがっているid:kanoseやそのお仲間の遣り口の薄汚さには
ノドにスッパい物がこみ上げてくるのを抑えきれねえ。まるwwwwwwwww
http://anond.hatelabo.jp/20110401162030
上記に目を通したのち、言及されていたブログを読みに行ってみた。
タイトル横には、
と、あったけれど、ブログには割と建前的なことが書いてあったので、
まず、最初にあなたがするべきことは、ブログの記事をやみくもに増やすことではない。
また、記事の中身を充実させることでも、はてブでホッテン入りしやすいまとめ記事を書くことでもない。
どんなにあなたが気合を入れて書こうが、誰も見にきたりはしない。
人気ブログのメソッドを利用して書こうと、成果はそんなに変わらない。
変わったとしても、気のせいだっつーの。まずは、そこを認めろ。
あなたが最初にすべきことは、Twitterで知り合いを作ることだ。
たた単に知り合うだけでは、意味がない。特に、「頻繁にブクマする傾向にある人」「リツイート大好きな人」
「フォローされている人の数が100人以上」を狙い内にして知り合え。
あ？ どうやって探すかって？
ライフハックやITやまとめ記事で、ホッテン入りしているような記事のブクマコメント覗いて、
よく同系統の記事をブクマしていたり、Twitterと連携している奴を探せばいいだろ。
もし相手が何か記事を書いたらブクマしたことが相手に分かるようにして感想を送れ。
これを繰り返したら、相手は次第にあなたに信頼を抱く。そう、これは布石だ。
将来、あなたが記事を書いたときに、ブクマしてもらう、あるいは広めてもらうための布石だ。
嘘も方便。誉めろ。相手に価値があると、称えろ。そして、敬え。あなたに、価値を感じてもらえ。
そして、それを一か月繰り返せ。
そうすることで、下地ができる。今後、あなたが記事を書いたよ、とツイートしたら、
みんなが言及してくれる、ブクマしてくれる、リツイートしてくれるようになるだろう。
今まであなたがどんなに頑張って、ライフハック記事を書いても、せいぜい一桁ぐらいしかブクマされなかったのが、
当たり前のように、数十、数百軽くいくようになるだろう。そう、例え今までと同じ記事を書いたとしても、
ブログのアクセス数は軽く20倍は行くようになる。「・・の方法」「・・の理由」「・・のまとめ」のような
タイトルを連発しろ。何でもいい。ありがちでもいい。寄せ集めた知識で、「SEXで確実に相手をイカせる方法」なんてのを
書いたら、軽く300はブクマされる。中身はパクれ。そもそも、多くブクマされるような記事にオリジナリティなんていらない。
寄せ集めろ。寄せ集めて上げろ。あ？ 効果なさそう？ 貧乳でも寄せて上げれば、それなりに見えるだろ！？
あなたも、騙されたことや騙したことの1つや2つあるだろ？ 童貞と処女は部屋でスルメでも齧ってろ。
→少なくとも4年前には解決していない
http://netbeans.org/bugzilla/show_bug.cgi?id=114689
→Norway today」を改造して、City Lightsに似たオリジナルを作る。
→クラスの色は「Norway today」と同じになるが、バックが黒に文字が黒よりは見やすい。
凡例 前景 背景 その他
・デフォルト 緑 黒
・URL 継承 継承 →エフェクト:下線付き エフェクトカラー:青
・エラー 白 赤
・コンストラクタ 継承 継承 →フォント:継承+ボールド-イタリック
・セパレータ 継承
・フィールド 9,134,24 継承 →フォント:継承+ボールド-イタリック
・メソッド 継承 継承 →フォント:継承+ボールド-イタリック
・使用されていない要素 グレー 継承
・公開要素 全継承
・列挙 全継承
・数値 黄 継承
・文字 黄 継承
・空白 全継承
・識別子 全継承
・公開限定要素 全継承
・静的要素 継承 継承 →フォント:継承+ボールド-イタリック
・非公開要素 全継承
ペロペロ
1. htmlのはき出しがあるやつは?>を書いたほうがいいよ。それ以外は最近はかないのがはやりだねさらに昔はevalとかで書いてた
2. configこれはwwwやpublic_html以下にしかconfigを配置できないクソサーバーがあるので、phpにしておいたほうが安全。なぜなら丸見えにしてあれこれパスをさらけ出すバカがいるかもしれないからだ。オープンソースなら特に。
3. コメントは挨拶だ。必要以上に挨拶を繰り返す必要もないし、それ以上でも以下でもない。
4. eclipseのせいと、phpとかが出始めたころのコーディング規約がスペースにするように求めた。{を改行してから書くか、続けて書くかのこれは宗教戦争だ。だが正直スペースは気に食わない。LLのくせに何バイトつかってるのだとおもう。あとスペース２文字インデントのやつは旅立て！
5. phpの0と""の違いは緩すぎる。そういう意味でナンバーの取り扱いにだけは気を配るべきだ。あとはtmpでもbufでもretでもなんでもいい。
6. nullはつっこむな、nullで初期化はすんな。初期化されてないからnullなんだ。issetは有効につかえ。とくに$_系の変数
7. 本当はerrorprocをかけといいたいがLLにそこまで望んでもしゃーない。エラーを投げると鯖ログにまで場合によっては落ちたりしてやっかいだからfalseを返せばいいというものでもないが、trueで初期化するやつは滅びていいと思う。あとarrayを返すようなfunctionの場合、phpのなんだっけisarray?だっけ？がクソすぎて萎える
8. つかダブルクオートのなかに$を書くコードは滅びていい。コンストはすべて大文字でという昔ながらのルールだけ守ってくれればいい
9. 出力系のラップ関数ぐらいつくっておこうぜ。あと、var_dumpとかのほうが見やすい。あと、get_defined_varsとかをラップしておくと便利
10. 三項演算子はつかうな。ifの{}を略すな。可読性がおちるのとしんたっくすで原因の特定がめんどくさい。
12. ++iなんていうコードを書くな。あと、roopの条件文で計算すんな
13. むしろこういうのは文字列の連結以外で使うようなスチュエーションをつくっちゃだめ
14. あら上で言っちゃったよ。ここまでやるんだったらlogファイルに吐き出すところまで拡張しとけば?
15. んー。エラーメッセージを定数化するときは外国版をつくるあてまである時だけだな
16. これも上でいってしまったな。あとリロードされてもいいように初期化でクリアしておくといいぞ。
17. ああそうだな、関数が１スクロールに収まらないときは大抵正規化に失敗してる。つくりをみなおせ
18. えー、こんな風に書くのはどうかしている。public二つチェインで呼び出すぐらいなら、内部でprivateを呼び出すか、継承させてparentにしておくべきか、それともシステムとして共通のstaticで呼び出せるかにしてくほうがいいのでは？$this->setThis()でいいじゃないか。なぜpublic functionをそういくつも定義する必要がある？ 外部からの入り口出口は絞れ
19. グローバルなラッピング関数は最低限にとどめるべきで他は機能ごとにクラスつくってメソッド化しとけ。p(var)じゃねぇよDEBUG::p(var)とかにしとけってことだ
20. 眠くなったからねる。つまりはそんなもんだってことだ。気に病むな。満足してもらえるもんをしっかりつくればいいだけだ
http://1-byte.jp/2011/03/20/20_tips_you_need_to_learn_to_become_a_better_php_programmer/
良いPHPerだって？そんなものは丸めてゴミ箱にでも捨ててしまった方が資源の再利用になる分いくらかマシだ。
つまり俺たちがしなくちゃならないことは「より良いPHPerにならないため」に何ができるかってことなのさ。
それじゃ、始めよう。
?>なんて使っちゃいけない。そう俺たちはBAD PHPer。
無駄なホワイトスペースの出力に悩まされるくらいなら対称性なんて丸めてゴミ箱にでも捨てた方がまだマシだ。非対称性こそが賛美。
require_once("config.php");
未だにこんなことやってるやつがいるのかいベイベー。絶対にダメだ。この一行を見たら俺は悶絶する。
ダメだ、早く何とかしないと。
大抵このconfig.phpの中身はこうなっている。見て絶望だ。
$hoge_path = ''; if (!LOCAL) { define('FOO_FLAG', 1); if (HONBAN) { define('HOGE_FLAG', 1); } else if (TEST) { define('HOGE_FLAG', 2); } } else { $hoge_path = '/local'; define('FOO_FLAG', 2); define('HOGE_FLAG', 3); } define('HOGE_URL', $hoge_path.'/hoge/');
こういうのが延々と続くわけだ。もういやだ。もう見たくない。
本番環境とテスト環境でどういう値の違いがあるのか、ローカル環境だとどうなるのか、まったく把握できる気がしない。
なまじPHPな設定ファイルのせいで、処理をついつい書いてしまう。そしてどんどん複雑になってしまう。
やはり設定データは基本的にYAML等のデータしか定義できない形式のもので用意すべきだ。そして環境ごとに設定ファイルを分けるべきである。
そうすることで何にどういう違いがあるのかすぐにわかるし、diffすれば一度にすべて把握することができる。
# 本番環境設定ファイル foo_flag: 1 hoge_flag: 1 hoge_url: '/hoge/'
# テスト環境設定ファイル foo_flag: 1 hoge_flag: 2 hoge_url: '/hoge/'
# ローカル環境設定ファイル foo_flag: 2 hoge_flag: 3 hoge_url: '/local/hoge/'
// ここで後の処理のためにhogeメソッドを呼び出しておく $q->foo(); // $a['foo']はここに来る時点で真のはず // 2010-03-10 判定がおかしいので修正 // 2010-06-21 やっぱり値が入ってる方が正しい if ( !isset($hoge[0]) ) { }
コメントは保守されない。そう、それは真実。こんなコメントを発見したら即効削除しよう。コメントは基本信じるな。
俺たちにちょっとしたヒントと大きな損害を与えてくれる、それがコメントの役割なのだ。
わかる。いいたい事はとてもわかる。俺たちはしばしばインデントにスペースを使うはずだ。一方でIDEのしっかりした言語ではタブも使うことがある。しかし悪いことに、両者を混同しているプログラマも一定数いるのだ。
タブを画面上で認識しにくいエディタが世の中には存在する（何とは言わないが）
そして画面上で認識しにくいことを理由にタブを気にしないプログラマがいる。
この二つの条件が重なると、タブとスペースの交じり合ったインデントが完成する。もうぐちゃぐちゃだ。これは永遠に続く戦いだ。
私たちが勝利を掴むためにできることなどせいぜい、常にスペースしか使わない。タブを見つけたらその都度スペースに変換する。そういった地道な活動が明日へとつながるのだ。
われわれがプログラムをするとき、何に一番時間がかかってるか。実は変数の命名なのである。ここで拘り過ぎて時間をかけ過ぎては何も進まない。
御託はイイからさっさと書け、だ。しかしとはいっても変数名は重要。日頃からどういうときにどんな名前を使うかを決めておくといい。
そして変数名に型はまったく必要ない。型宣言のないPHPにおいて、型の変数名をつけること自体ナンセンスだ。
$iNumber = 'aaa';
になんの意味もない。コメントを信じるなでも言ったが、これはプログラマを混乱させるだけの害悪なものだ。
変数を使う前に初期化するのは、警告を出さないという意味でも良い癖だ。しかし具体的にどこでやるかが問題だ。
$foo = null; $foo = $q->foo();
こんな初期化に意味はない。よくあるのはやはり、if文で値を振り分けるケースだろう
$foo = null; if ( $hoge ) { $foo = 1; } else if ( $bar ) { $foo = 2; }
このときの初期化はとても有効だ。もしnullの初期化を忘れたまま$fooを使うと警告が出るが、ちゃんと初期化してるので出ない。基本中の基本だ。
function getStatus() { $bReturn = false; if ($i == 2) $bReturn = true; return $bReturn; }(中略)
もし、何かしらの理由で、あなたの書いたif文が間違っていたら？
この書き方をしていれば、間違った値に対して、常にfalseが返る。
私たちが、PHPでsensitiveなデータを取り扱うなら、正しいデータが入力されるまでは、動かないコードを書くべきだ。
trueとfalseの条件がいまいち明確ではないが、本当に動かないコードを書けというのであれば以下のようにすべきだ
function getStatus() { $bReturn = false; if ($i == 2) $bReturn = true; else if ($i == 1) $bReturn = false; else throw new Exception("bad status! $i"); return $bReturn; }
中途半端にfalseを返して生存させる必要性はまったくない。今すぐ死ね！
連想配列のキーを指定する場合だけ定数と間違わないようにクオートで囲まなければならない。そして逆に定数を使いたい場合はクオートで囲ってはいけない。
更に後世のプログラマが処理を見たときに、定数が使いたかったのか、文字列が使いたかったのかを明確にしたい場合はconstantを使うと良い。
// 定数のFOOを使うよということが明確になる print $a[constant('FOO')];
もし、文字列を変数の値と一緒に出力するとき、PHPではコンマの代わりにprintfを使うことが使える。
printf( “Hello, my name is %s“, $sName);
以下の代わりに上記のコードを使う。
echo “Hello, my name is “, $sName;
出力すべき変数が増えれば増えるほど、有効になっていく。とにかく迷ったならば、printfを使え、だ。
三項演算子はとても有効だ。しかし優先順位に難があるせいで、三項演算子をネストしようとすると以下のようなコードになってしまう
$n = (($i == 1) ? 2 : (($i == 2) ? 3 :$i));
括弧だらけで読みにくいったらありゃしない。三項演算子を使うなら一回まで。約束守れないやつは丸めてゴミ箱にでも捨てちまえ。
if ( $flag ) { }
仕様をちゃんと把握しているなら真偽値のチェックなどこれで十分。
もし事前にbool型だというのが確定してるのなら「$flag === true」を使えばいい。
インクリメント、デクリメント演算子は前に付くか後ろに付くかで意味が変わるので慣れるまでは非常にややこしい。
わけがわからなくなるくらいなら初めから使わないほうが良い。見極められないなら使うな。それがPHPerなのだ。
文句なしだ。これは文句がない。
他にも色々あるので覚えておこう
$a %= 1; $a &= 1; $a |= 1; $a ^= 1; $a <<= 1; $a >>= 1;
てっとり早く画面に表示する際にpreはよく使うが、デザインの関係上画面の文字が見えないときがある。
なのでdivを使って以下のようにしとくと便利だろう。
function p($var) {
echo "<div align='left' style='background-color:white;color:black;'><pre>";
print_r($var);
echo "</pre></div>";
}
君らが通常作るアプリケーションなんぞに、定数なんぞ必要ない。いいか、もう一度言う、お前ら程度のもんが、定数使おう何ぞ、おこがましいわ！
大丈夫。なんでもかんでも定数にする必要はない。結局設定ファイルに定数をずらずら作りまくってわけがわからなくなってるパターンが多い。
貴様みたいなもんに、定数は制御できん。いいか設定ファイルはYAML等のデータで持つようにし、その連想配列のデータ構造を一つ持ってるだけで定数の変わりになる。
このメリットに比べれば、定数だと書き換えられなくて良いという利点などこの歯のカスほどのものだ。そんなものは丸めてゴミ箱へ捨ててしまうといい。
認識を改めろ。俺たちはより良いPHPerにならないために努力している。
class Request { private $parameters; private $method; function __construct () { $this->method = $_SERVER['REQUEST_METHOD']; if ( strtoupper($this->method) === 'POST' ) { $this->parameters = $_POST; } else { $this->parameters = $_GET; } } function param ($key) { return isset($this->parameters[$key]) ? $this->parameters[$key] : null; } }
これだけでもいい。たったこれだけでもとても便利だ。ここから拡張してGETやPOSTを明示的に取るメソッドとかも作ってみるといい。自分の手を動かすのだ！
例が良くない。こんなのは引数が20個ある関数から、setを20回呼ぶオブジェクトに変わっただけではないか。
そもそもこの20個の引数とはなんなのか。何かのデータ構造なんであれば連想配列にして引数一つとして渡すべきだし、それぞれまったく異なる用途の変数なのであればWindowsプログラミングじゃあるまいし、20個も引数取る時点で設計が間違えている。
何がいいたいか。別に関数でもオブジェクトでもどっちでもいいということだ。
そんなことで悩んでる暇があったら設計を見直せ。
スキあらば自分自身を返せ。スキあらばオブジェクトを返せ。配列はArrayObjectのARRAY_AS_PROPSで返せ。
ひたすらメソッドチェイン。来る日も来る日もメソッドチェイン。とにかくメソッドチェインを使い続けろ。そこに未来はある。
どんなコードも繰り返すな。もし、少しでも同じコードを書いていたなら、それは関数に置き換えてしまえ。
・・・と、いうのはやめなさい。
一見同じように見えた処理でも前後の流れでまったく違うものということが往々にしてある。
まとめ方にも問題があるケースもある。何でもかんでも関数化すると、関数が膨大に増えていく。君は見たことがあるだろうか。common.phpやfunction.phpの恐ろしさを。
確かに細かく関数化はされているが、適切に関数化していないのである。結合度が非常に高い。なんでもかんでも盲目的にまとめれば良いという話ではないのだ！
あまりに極度に意識しすぎると、プログラムそのものができなくなる。そういう状態に陥る。
気を抜いて。そう気を抜いて。所詮あなたのコードなんてすぐに消えてなくなるよ。きっともっと偉い人が作り直すよ。だからまずは思うが侭にやるといい。
結合度を減らすというのは非常に難しい。何度も何度も失敗し続けて、ようやくここは分けた方が良かったんだなと気付く。次に活かそうと心に決める。そしてまた同じ過ちを繰り返していくわけだ。
まずは実装することだ。これが一番の早道だ。まずはがっつり結合した関数をあえて作るといい。何も考えずに作ろう。
そしてその後に、一部分使いまわしたいとおもうことがあるはずだ。その時に関数に切り出そう。それを繰り返すといい。そのうち初めから分けた方が良いと気付く。
何事も経験が必要である！経験を積まないプログラマは丸めてゴミ箱に捨ててしまえ。
さて、先の例で言うならば、私ならadd_result_outputという関数を作ってしまうだろう。だって、addとresultを連続して呼ぶのはめんどくさいんだもん。一連の流れをいつも使うのなら、その流れをやってくれる関数を作ればいいじゃないか。
function add_result_output ($iVar, $iVar2) { $r = add($iVar, $iVar2); echo result($r); }
もっと言えばクラス化してしまってもいいかもしれない。どんな感じになるかは君の手を動かして確認しよう！
このTipsはとてもわかりにくく、ニッチ過ぎる部分も多いかもしれない。
あくまでも「より良いPHPerにならないための20Tips」なのだ。
君はこの記事を鵜呑みにしてはならない。PHPをPHPと見抜けないPHPerはPHPを使うのは難しい。
もし、あなたがPHPプログラマなら、公式のPHPドキュメントはあなたのケツの穴を拭くための紙になるだろう。
私は、それぞれのセクションを眺めて、各関数でどんなことが出来るかなんぞ、歯クソのゴミ程に役に立たないとおもっている。動けばいい。はは。
あなたは、PHPで用意された既製関数で多くのことが実現できることに、（俺の仕事を減らすなと）驚くはずだ。
この記事があなたの役に立たない事を。
ふざけんな！
これは http://anond.hatelabo.jp/20110316202255 の続編です。
GTをやる前に改を書いてくれている人がいてとてもしっかりした内容なのでちゃんと勉強したい人はそっちを見てね！
d:id:ryoasai:20110317 - ドラゴンボールで学ぶオブジェクト指向 改 | 達人プログラマーを目指して
またオブジェクト指向については
d:id:m-hiyama:20080109 いまさらながらだけど、オブジェクトとクラスの関係を究めてみようよ | 檜山正幸のキマイラ飼育記
がとても詳しいです。合わせて読むとかなりしっかりと理解出来ると思います。
ホットエントリに行くとは思っておらず、皆様ありがとうございます。
「ドラゴンボールをオブジェクト指向にする」というコンセプトではなく、「オブジェクト指向を（無理矢理）ドラゴンボールで説明する」という遊びだったので
プログラマーの方々にはツッコミを受けてしまいましたがここは遊びだと思って楽しんで下さい…。
ドラゴンボールは小さい頃から大好きでしたが流石にうるおぼえ過ぎました。
それはさておき「説明する題材を決める→好きな漫画から無理矢理当てはまりそうな例を考える」という思考実験なので、気が向いた方は色々考えてみると楽しいと思います。僕は楽しかったです。
これは難易度が高そうです。
やっぱりドラゴンボールで例えると分かりやすいな！
無理がある！
デザインパターンとはドクターゲロが考えた「こうやって設計すれば色々捗るぞ」という例のことです。実際はGoFという人たちが考えたもので23個のよくあるパターンに名前を付けて整理してくれたわけですね。
23個の中にはブルマさんですらわからないものが多いので（さすがドクターゲロですね）良く使う、代表的な物をいくつか紹介します
Singletonは世界に一つだけしか存在出来ないようにする方法です。
balls = new DragonBalls(); //これでは誰でもドラゴンボールを作れてしまう！ balls.callShenron();
クラスの中にはいくつかのメソッドがありますが、簡単に言うと外から呼べるもの、外からでは呼べないものの
二種類があります。そうやってメソッドを保護することで世界の崩壊を防ぐわけですね。
基本的な戦闘力をアップさせるには本人の努力が必要になり、外から簡単に挙げられてしまうとジャンプの三本柱が外れてしまいます。
ただナメック星の最長老や界王神などはかなり偉いので、本人の才能を引き出すことが可能でした。
現実には思いつきのような仕様を後から言われることが多々あります。困ります。
//地球上にひとつだけ存在するドラゴンボールをつくろう class DragonBalls{ private DragonBalls(){ //ドラゴンボールを作れないように生成メソッドを保護します。 } static function sagasouze(){ static singleton_dragonball; //ドラゴンボールを生成。 //DragonBallsクラスの中なので、保護してある「new DragonBalls()」を呼べます。 if(!singleton_dragonball)singleton_dragonball = new DragonBalls(); return singleton_dragonball; } }
地球のみんなは地球語しか話せませんが、ナメック星にいるクリリンを通して願いを叶える必要があります。
クリリンももちろん地球語しか話せませんが、ナメック語を話せるデンデがいるため、地球のみんなは願いを叶えることが出来ます。
class Kuririn{ private dende = new Dende(); function request( wish1, wish2, wisth3){ this.dende.request(wish1); this.dende.request(wish2); this.dende.request(wish3); } } kuririn.request( "ピッコロを生き返らせてくれ", "ピッコロをナメック星へとワープさせてくれ", "ナメック星にいる孫悟空とフリーザ以外を全員地球へとワープさせる" );
この場合のメリットはデンデが何をやっているかクリリンをプログラミングした人が知る必要が無いということです。
地球の人はナメック星にいるナメック星人が「デンデ」であることを知る必要もありません。
それでも願いは叶うんです。
本来であればデンデやクリリンは願いが叶うのを待つ必要がありましたが、地球の人は一気に伝えることが可能なように設計しました。
//デンデクラス。ナメック星人は英語でNamekianらしいです。 class Dende extends Namekian{ function translate(word){ namekian = *****//ナメック語に翻訳します。 return namekian; } function request(wish){ static polunga; if(!polunga){ polunga = DragonBalls.spell("タッカラプト ポッポルンガ プリピット パロ"); } polunga.ask(this.trasnlate(wish)); } }
大まかなアルゴリズムだけ決めておいて、実装はサブクラスに任せる設計がTemplate Methodです。
ナメック星に行く方法を考えた時いくつかの方法がありました。古い宇宙船を探してきて直して載せて…っていちいち書くより同じメソッドでナメック星に行けたほうが便利ですね。
abstract class WayToNamek{ abstract function prepareSpaceShip(); abstract function launchSpaceShip( ship ) ; function gotoSU839045YX( people ){ ship = prepareSpaceShip( ); //船を修理します ship.load(people); //人を載せます this.launchSpaceShip(ship); //船を出発します。 } }
ナメック星に行く方法を定義したので「ブルマ、クリリン、悟飯」組と「悟空」をそれぞれナメック星に連れて行きましょう。
way = new WayWithKamisamaShip(); way.gotoSU839045YX( buruma, kuririn, gohan ); way = new WayWithSaiyajinShip(); way.gotoSU839045YX( goku );
と簡単に方位SU83、距離9045YXまで乗員を連れて行くことが出来ます。
二つの方法を実装します。神様の船を修理して行く方法と、サイヤ人の船(悟空が乗ってきた船)で行く方法の二つです。
//神様の船で行きます。 class WayWithKamisamaShip extends WayToNamek{ function prepareSpaceShip(){ return new KamisamaShip(); //船を準備します。神様の船を使います。 } function launchSpaceShip(ship){ ship.inputByVoice("ナメック星に出発"); // } } class WayWithSaiyajinShip extends WayToNamek{ function prepareSpaceShip(){ return new SaiyajinShip(); //船を準備します。サイヤ人の船(フリーザの船？)を使います。 } function launchSpaceShip(ship){ //audio = new HighSpecAudio(); //ship.setAudio(audio); ship.turnOnCenterButton(); //真ん中のボタンを押すだけ } }
元になる船も違いますし、発射の仕方も違いますが同じ呼び出し方が出来ます。
オーディオの位置が決まりませんでしたが、今回の運用では不要とのクライアントからのご意見でしたのでだったので
せっかく用意したオーディオも無駄になりましたが、コメントアウトしてあります。
http://anond.hatelabo.jp/20110316202255
亀仙流やつ鶴仙流など、世の中にはいくつかの流派があり、それぞれ カメハメ波やドドン波、舞空術などの技（メソッド）がある。 実際に技を使う場合、技を覚えているZ戦士（インスタンス）が必要。
クラス = 流派
メソッド = 技
インスタンス = Z 戦士
というのはおもしろいと思うし, 例えばゲームを作るなら実際にそういう実装になると思う.
例）セルを作りましょう。 class Cell extends Goku,Veget,Picoro,Tenshinhan,Kuririn{ .... } cell_inst = new Cell(); cell_inst.shotKienzan(); //Kuririnをextendsしているので気円斬が使えます。
しかし, ここではクラス = Z 戦士になってしまっているので, 混乱を招くだろう.
むしろ, 「JavaScript における prototype」 に絞って説明するのはどうだろう.
(ついでに「撃つ」の現在形は shot でなく shoot ですね)
var Goku = function () {};
Goku.prototype.shootKamehameha = function () {
console.log("波!!!");
};
var goku = new Goku;
goku.shootKamehameha(); // 波!!!
var Gohan = function () {};
Gohan.prototype = new Goku;
var gohan = new Gohan;
gohan.shootKamehameha(); // 波!!!
そしてセルによる吸収は, 動的な継承として考えるのがより自然だろう.
var Goku = function () {};
Goku.prototype.shootKamehameha = function () {
console.log("波!!!");
};
var Vegeta = function () {};
Vegeta.prototype.shootBigBangAttack = function () {
console.log("ビッグバンアタック!!!");
};
var Cell = function () {};
// 吸収メソッド
Cell.prototype.absorb = function (target) {
for (var method in target) {
this[method] = target[method];
}
};
var goku = new Goku;
var vegeta = new Vegeta;
var cell = new Cell;
cell.absorb(goku); // 悟空を吸収
cell.absorb(vegeta); // ベジータを吸収
cell.shootKamehameha(); // 波!!!
cell.shootBigBangAttack(); // ビッッグバンアタック!!!
そして次にクロージャの使用例として挙げられた次の例.
例）連続エネルギー波 var shotRenzokuEnergy = function( count ){ var shotEnergy = function(){ //エネルギー波を放ちます }; for(var i=0;i<count;i++){ shotEnergy(); } };
この実装では, shotRenzokuEnergy を実行するたびに shotEnergy が毎回定義されてしまい, 非効率である.
以下のように書き換えることで, shootEnergy の定義は, shootRenzokuEnergy の定義時の 1 回のみとなる.
var shootRenzokuEnergy = (function () {
var shootEnergy = function () {
console.log("エネルギー波!!!");
};
return function (count) {
for (var i = 0; i < count; i++) {
shootEnergy();
}
};
})();
shootRenzokuEnergy(10); // エネルギー波!!! x 10
亀仙流やつ鶴仙流など、世の中にはいくつかの流派（＝クラス）があり、それぞれの流派にかめはめ波やどどん波、舞空術などの技（メソッド）がいくつかあります。
実際に流派にある技を使う場合、技を覚えているZ戦士（インスタンス）が必要になります。
例）亀仙流を覚えた孫悟空を使ってかめはめ波を放って敵を倒す goku = new KamesenRyu("goku"); goku.shootKamehameha(teki);
Z戦士によっては複数の流派の技が使えたり、自分の技を人に教えることが出来ます（継承）。
また悟空とクリリンのように同じ流派でも同じ技で違う性能を持っていたり、オリジナルの技を持っているなどの違いがあります。
クラスはセルを作るためのZ戦士達の遺伝子情報と言っても良いかもしれません。
例）セルを作りましょう。 class Cell extends Goku,Veget,Picoro,Tenshinhan,Kuririn{ .... } cell_inst = new Cell(); cell_inst.shootKienzan(); //Kuririnをextendsしているので気円斬が使えます。
世界（プログラミング言語）によってはただの人を後付でZ戦士にすることが可能です。
(JavaScriptやRubyなど）
noumin = new Hito();
noumin.kougekiKuwa = function(){
//戦闘力たったの5…ゴミめ！
};
noumin.shootKamehameha = function(){
//な、なんだと！？
};
農民がいきなりかめはめ波をうつようになったら危険ですね、危ないです。
このように後付でメソッドを追加出来るタイプは危険性を含んでいます。
とても良いつっこみが来たので追記します。
前半部分ではZ戦士をインスタンスとしましたが、セルを作るにはZ戦士がインスタンスでは出来ないので
何をインスタンスにして、何をクラスにするかが「設計」なんですね。
セルの第一段階ではGokuなどのZ戦士の遺伝子があれば作ることが出来ました。
cell_inst = new Cell(); //このセルは第一段階
cell_inst.absorb(17gou); //第二段階に変身 cell_inst.call18gou(); cell_inst.absorb(18gou); //最終段階に変身 class Cell ....{ function call18gou(){ if(!this.17gou)return error(); //17号を吸収していないと失敗する this.17gou.speak("＊＊＊＊略＊＊＊＊＊ドクターゲロ様＊＊＊＊略＊＊＊＊"); } }
17gouを吸収したので、17号の声で18号を呼ぶことが出来るようになりました。
でもドクターゲロ「様」って言ったのでセルだってバレバレですね。
http://anond.hatelabo.jp/20110316224648
クロージャについてちゃんと書こうと思って挫折。どなたか良いアイディアを下さい。
変数のスコープを解説する必要があるかなと思ったんですがオブジェクト指向からは外れるような気がします。
エネルギー波→連続エネルギー波がどこかに使えそうな気がしましたが、気のせいだったぜ…
結局プログラムなんて手数勝負なんだとつくづく思う。
逆説的な話だが、プログラムを書くときは「書かないで済ます」のが仕事なのだ。
「なんで書かなきゃいけねーんだよめんどくせーなー」
と思っていた方がうまく行く。
実際、書いたら書いた分だけずっと自分一人で面倒見るとかうざいし。
なので、同じことは2度と書かないように心血を注ぐ。
書き直すことで消えて無くなってしまうことが喜びになるのだ。
結局、なんも考えずやたらめったらコードを書くのと同じくらいの工期になったりするが、
後腐れは無いので楽だ。
更に言えば、あらゆる言語も、開発手法も、ミドルウェアも、ツールも、ライブラリも、フレームワークも、
詰まるところ可能な限り書かないで済ますためにあるのであって、
というか自分に限って言えば、自分が末永く楽できるかどうかだけで選んでいる。
一度でも横着することに味を占めると、誰でもそうなるはず。
自分はこれからも、短気で怠け者なプログラミング人生を送ろうと思う。
というか怠けられるのなら、人生の半分くらいはプログラミングだって構わない。
もはや怠けるのが好きなのかプログラム書くのが好きなのか分からなくなっているが、
どっちでもいいや。