はてなキーワード: 拡張とは
http://anond.hatelabo.jp/20110707195830
初音ミクLAライブについて、各所で話題になっていたマサチューセッツ工科大サイトの感想も翻訳してみた。初音ミク現象を基に、情報を巡る様々な活動の基盤となるメディア・プラットフォームのあり方について考えたもので、書き手はミクが市民主導のメディア作りをするうえで参考になると考えているようだ。残念ながら一ヶ所、fro-ducerなる意味の分からない用語があったのでそこは翻訳していない。意味を知っている人がいたらご教授願いたい。
urlは以下の通り。
http://civic.mit.edu/blog/condry/miku-japans-virtual-idol-and-media-platform
7月2日土曜日、私は普通じゃないライブショー、日本から来たヴァーチャル・アイドルの米国デビューを見に行った。彼女は市民メディアについて私たちに何かを伝えられる存在だと思う。
初音ミクはアニメ・エキスポにおける催しの一つとして、ロサンゼルスのノキア・シアターで公演した。完売したコンサートには、多くがコスチュームに身を包んだ4000人を超えるファンが訪れ、ステージ上で生の演奏家の横に投影された「人間サイズ」の映像であるミクが床からせり出してくると、彼らは叫びケミカルライトを振った。
ミクは甘く歌い、幅20フィートある放物線状の鏡に沿って跳びはね、大半は熱狂的なテクノダンス・ポップな曲目を駆け抜ける間、決して汗をかかなかった。ステージの脇には彼女と他のバンドメンバーをクローズアップした映像がスクリーンに映し出されていた。彼女はちょっとしたおしゃべりもした。「はじめまして、初音ミクです」。そしてバンド(ギター、ベース、キーボード、ドラム)と6人の弦楽器奏者たちを紹介した。私たちは彼女に拍手を送り続けた。
「あたしたちは歴史を作っているのよ」と、私の隣に座った若い女性が友達に話しかけていた。たしかにそんな気がした。そして政治とポピュラー音楽について私が知っていると考えていることについて、改めて考え直した。
誰もが喝采しているが、何に対して? ステージ上、私たちの注目が集まる場所には誰もいない。単に仮想アバターが存在するだけだ。何のアバター? 一体誰の? それは私たちの。
大衆文化は政治と同様、しばしばステージ上の(あるいはスクリーンに映された)リーダーを前提としているように見えるが、その影響力や、しばしば創造性そのものが、どう転んでもより幅広い分散型の集団行動から生まれてくることを、ミクは示している。ミクは未開拓の可能性を孕む世界、クラウドソースな動員モデル、そして一部はソフト技術(ボーカロイド)、一部は文化的なアイデア(ミクというキャラ)からなるメディア・プラットフォームに関する有益な事例について、言外にほのめかしているのだ。
ミクはYAMAHAが開発し2004年から販売を始めたボーカロイドと呼ばれる音楽合成ソフトウエア・パッケージの声として作られた。ボーカロイドはガレージバンド[音楽制作ソフト]同様、演奏用の道具として音楽を作ることができるが、その際にメロディーと同じく歌詞を書けるという特徴も持っている。別の企業、クリプトン・フューチャー・エンターテインメント[ママ]が2007年、漫画風の画像と経歴設定(16歳、身長、体重、その他)と一緒に、追加音声であるミクを発売した。
http://www.crypton.co.jp/mp/pages/prod/vocaloid/cv01_us.jsp
重要なことに、クリプトンは画像に対する著作権を強く主張しない方針を定め、キャラクターが彼女自身の生命、より正確に言えば私たち自身の生命を持てるよう制限を解いた。いわば私たち誰もがレディー・ガガのために音楽を作り、それを彼女が私たちのために演じてくれるようなものだ。ミクがリアルじゃないってことが問題だって? それじゃレディー・ガガはどのくらい「リアル」なんだい?
ファンはそれにこたえ、さまざまな共通の服装及び像(たとえばネギ)を共有しながら数百数千の音楽ビデオをオンライン投稿した。以来、日本の動画シェアサイト、ニコニコ動画への投稿及びコメントを通じて増幅されたファンの取り組みのおかげで、ミクはスターの座へ駆け上がった。いわゆる「Nicodo」[ニコ動]はユーチューブと似ているが、動画を見ていると利用者のコメントがスクロールしていくところが違っており、それによって参加者の視点というレイヤーが追加されている。
今日ではミクのP(『プロデューサー』)は彼らの作品をオンラインで販売し、日本のカラオケスポットでは好きなミクの歌をダウンロードして歌うことができる。クリプトンは、彼ら曰くクリエイティブ・コモンズの模倣であるPiaproというオンライン・サイトを持ち、連携促進とライセンス供与をするシステムを作っている。ファンの作品は他の販売経路を通じても売られている。2010年11月、東京・池袋で開かれ私を含めた7000人の参加者を集めた完売のファン・コンベンションでは、集められた500のファングループがボーカロイド関連の音楽、ポスター、DVD、イラスト本、テレビゲーム、装飾品その他を販売した。
こうしたファンの興奮ぶりを踏まえると、ビッグ・ビジネスが仲間に加わろうとするのも不思議はない。2009年以来、SEGAはProject Divaというタイトル名でミクの携帯機及びアーケード向けゲームを作成している。トヨタも今や広告シリーズでミクを使っており、彼らはミクのロサンゼルス・デビューの前にCMを公開したほどだ(いくらかの非難も浴びたが、おそらくは善意に基づいて作られていた)。とはいえ究極のところミクはファンの取り組みによって命を吹き込まれており、ミクが商業主義の世界に足を踏み入れるのを見るのが興味深いのもそれこそが理由だろう。
ミクは、以前から知られていた市民メディアのための教訓のいくつかを補強する存在だ。人々が参加するには本当の開放性が感じられることが必要であり、共有と対話がコミュニティー形成のカギになる。管理された知的財産権システムよりも自由な文化の方がより何かを生み出す力があり、新規参入と商業主義化は、特に人気が高まった場合は常にリスクとなる。
だがミクは分散型の創造性について、ウィキペディアとも人間のセレブとも異なる特殊な図式を提示している。ミクにはバックグラウンドが欠けている。彼女には予め定められた人格はない。彼女は唯一の完成した空想世界に存在しているのではない。このウィキ=セレブは、将来がプラットフォームに在る時代において、昔ながらの人間のセレブを白物家電のように見せてしまう。
この事実は民主主義と参加についての考え方にも別の道筋を提供するのだろうか? 行動と人気を生み出すのがリーダーたち以外の社会的現実だとしたら、メディアに関する問いは表現される内容よりも、プラットフォームのあり方、それがどれほど開放的であり、それが許す創造性の形式がどんなものであるかに振り向けられるだろう。
クリプトン社長の伊藤博之は2011年10月、ミクと計画されている英語版を含む関連プロジェクトについて議論するため[MITの]比較メディア論を訪れる。彼はこの現象を、エンターテインメント産業について再考する機会だとみている。「これは普通ではない形の創造性です」と、コンサート前にLAで短時間出会った際に彼は言った。「私たちはコンテンツを作成する過程を作り変えているのです」。ミクが機能するのは分散型のファン=製作者グループの関与があるからだ。おそらくこれはプロ=シューマー[生産消費者]の終焉であり、fro-ducer[残念ながら意味不明]の台頭なのだ。
大衆文化は、市民メディアを分析・設計する際に利用できる社会的力学を照らし出すものだ、と私は信じている。大衆文化は政治的参加のための媒体になり得るのみならず、特に人々に行動を促すという観点からどのようにアイデアが流れ影響をもたらすかについて把握するモデルも提供してくれる。
アニメに関する研究において、私は仮想のキャラクターがそれ独自で生成力のある創造性のプラットフォームになっているとの結論に達した。そこからより多くの種類のプラットフォームが出てきそうであり、創造され、築かれ、共有され、分配され、リミックスされ拡張されるのを待っていることを、ミクは明白に示した。ミクについて考えることで、私たちが未来において行動するコミュニティーを創造するための新たなアプローチについて思い描けるようになること、それが私の望みだ。
http://anond.hatelabo.jp/20110707195830
初音ミクLAライブ、外国人感想その2「再生の約束」フリーダム訳
http://anond.hatelabo.jp/20110708223459
初音ミクLAライブ、外国人感想その3「ミクノポリスのボカレタリアートたちよ、団結せよ!」
http://anond.hatelabo.jp/20110709211718
初音ミクLAライブ、外国人感想その4「仮想の歌姫:初音ミクの人気と未来の音色」
http://anond.hatelabo.jp/20110710234300
初音ミクLAライブ、外国人感想その5「オレはAXには行ってないけど、まあとにかく……」
http://anond.hatelabo.jp/20110711212701
初音ミクLAライブ、外国人感想その6「ミクノポリス:7月のクリスマスと世界征服」
http://anond.hatelabo.jp/20110712205546
初音ミクLAライブ、外国人感想その7「AX11:ミクノポリスの印象」
http://anond.hatelabo.jp/20110713211501
初音ミクLAライブ、外国人感想その8「ミクノポリス:コンサート・リポート」
http://anond.hatelabo.jp/20110714210122
初音ミクLAライブ、外国人感想その9「アニメ・エキスポ:初音ミク」
http://anond.hatelabo.jp/20110715222900
初音ミクLAライブ、外国人感想その10「アニメ・エキスポ2011(抄訳)」
http://anond.hatelabo.jp/20110716194029
初音ミクLAライブ、外国人感想その11「世界は彼女のもの:初音ミクはいかにして全てを変えたのか」
http://anond.hatelabo.jp/20110717201147
初音ミクLAライブ、外国人感想その12「アニメ・エキスポ2011でのボーカロイド体験」
http://b.hatena.ne.jp/t/キ印?sort=eid
誰だかしらんけど人のはてブページを「キ印」「残念な人」というタグでブクマしまくってるやつがいる。
おまえがry
何がウゼェって、Safariの機能拡張のせいで自分のブクマ開くたびに赤く①って左上に出てて、それがまずうぜぇ。
それは要するに自分のブクマ開くたびに「ばーか、ばーかwww」と書いてあるのが目に入るってことだもん。
あとさ、たとえばこの先自分のブクマを誰かがお気に入りに入れようとしてくれたとして、
同じようにSafariつかってたりした時に「は?まじ?」ってなるのとかやだなぁ。
これってなんとかなんないのかなぁ。
まぁ「気にすんな」としか言いようがないだろうけどさ。
そんな僕は誰かのブクマに飛んだ時に同じように赤①を見つけると同情する。
顔真っ赤にして地団駄踏むのもシャクなので、もっぱら最近はキ印仲間のブクマを回る新しい遊びを楽しんでる。
追記:なんで非公開なのにブクマのタグがわかるかというと、同じようにブクマしようとするとお勧めタグに必ず「キ印」「残念な人」が表示されるからです。
された方、ご愁傷様です。
http://anond.hatelabo.jp/20110710091636 を書いて気になったので2ch検索使って調べてみた。
http://pele.bbspink.com/test/read.cgi/feti/1307659307/151
完全拘束・超拘束に萌える 6
151 :名無しさん@ピンキー:2011/07/09(土) 23:19:00.63 ID:1R0zWwXL0
http://2ch.cloudnote.jp/matome/9739
とりあえずここまでの流れ保守。
このツールいいな。
http://pele.bbspink.com/test/read.cgi/feti/1303198373/130
腹パンチフェチ集まれ!2
130 :名無しさん@ピンキー:2011/07/03(日) 05:22:21.45 ID:vvthJH530
http://2ch.cloudnote.jp/matome/9660
とりあえずここまでの流れまとめておいた。
http://pele.bbspink.com/test/read.cgi/feti/1305295753/270
270 :名無しさん@ピンキー:2011/07/02(土) 00:22:32.12 ID:VgxXxxXz0
http://2ch.cloudnote.jp/matome/9643
流れまとめました。
http://yuzuru.2ch.net/test/read.cgi/campus/1304596527/512
512 :学生さんは名前がない:2011/06/29(水) 01:19:44.25 ID:X0vW3Uht0
まとまってるな。
http://pele.bbspink.com/test/read.cgi/feti/1307732842/536
536 :名無しさん@ピンキー:2011/06/29(水) 01:18:18.59 ID:QDkhT5eW0
ここまでの流れめとめておきました。
http://pele.bbspink.com/test/read.cgi/ogefin/1158394332/351
http://pele.bbspink.com/test/read.cgi/avideo/1171119788/703
オナラのシーンがあるAV
703 :名無しさん@ピンキー:2011/06/27(月) 03:53:13.30 ID:azf1kpYU0
これ書いた奴でてこい
http://pele.bbspink.com/test/read.cgi/feti/1289370790/801
http://yuzuru.2ch.net/test/read.cgi/retro2/1175717336/257
くっだらねぇ裏技
257 :名無しの挑戦状:2011/05/21(土) 23:46:12.82 ID:q6Ab9TMg
とりあえず、ここまでの流れをまとめておいたぞ
http://pele.bbspink.com/test/read.cgi/sm/1305293905/185
185 :名無し調教中。:2011/06/19(日) 21:23:31.23 ID:gvk/nzqj
http://2ch.cloudnote.jp/matome/9156
ここまでの流れまとめておきました。
http://pele.bbspink.com/test/read.cgi/feti/1293796378/409
男だけどパンツは女物着用 16枚目
409 :名無しさん@ピンキー:2011/06/16(木) 20:03:34.99 ID:aNs9G7HY0
http://2ch.cloudnote.jp/matome/9014
ここまでの流れまとめましたー。
http://pele.bbspink.com/test/read.cgi/feti/1303399202/322
322 :名無しさん@ピンキー:2011/06/14(火) 22:35:13.70 ID:y0OhGnnx0
ここまでの流れをまとめておきました!
http://2ch.cloudnote.jp/matome/8928
えろいっすね。。
http://pele.bbspink.com/test/read.cgi/eromog2/1292859816/238
元チャットレディだけど何か質問ある?
238 :fusianasan:2011/06/15(水) 21:00:54.73
http://2ch.cloudnote.jp/matome/8971
とりあえず主要質問まとめましたー。
いやー、ほんといいこですね(キリッ
http://pele.bbspink.com/test/read.cgi/feti/1303254134/620
620 :名無しさん@ピンキー:2011/05/31(火) 02:47:02.99 ID:66qYUusA0
とりあえずここまでの流れをまとめておきました。
http://pele.bbspink.com/test/read.cgi/ogefin/1294048523/209
女のケツの匂いを嗅ぎたい
209 :名無しさん@ピンキー:2011/05/22(日) 19:48:43.61
http://2ch.cloudnote.jp/matome/7889
ここまでの流れまとめておきました。
http://pele.bbspink.com/test/read.cgi/sm/1264824259/74
74 :名無し調教中。:2011/05/19(木) 22:51:18.94 ID:bHj6g5dc
age
なんか、誰が書いてるか分かりづらかったので
http://2ch.cloudnote.jp/matome/7687
にまとめておいた。
もっと、色々おしえてー。
腐女子と一緒で、自称と他称をごっちゃにする言説見るたびに、げんなりする。
他オタが分類されてないなんて当たり前だ、興味もないし中身も知らない。
単に「特定の性質・言動」を「オタク的」だと定義して、そうした性質をもつ者や、言動を取る者をオタク(っぽい)と呼ぶ。
このオタク的なる定義は、「あいつオタクっぽくね?」という攻撃のための定義が先に来て、後付で拡張されることもあるし、
自分たちが利用するようになると、例外的に除外されたりもする。
自オタが分類されているのも必然。
自身を呼称するのだから、鉄オタなのか、ミリオタなのか、アニオタなのか、自身の属性を正確に把握してる。
もちろん、その中にイタイ奴が混在することにも自覚的。
行動としては大きく二分され、「あいつらとは違う」とそれらを切り捨てるタイプと、客観的な評価を受け入れるタイプ。
切り捨てるタイプは、同族にも攻撃的で、外からイタイと言われるような方向性を嫌う傾向にある。
受け入れるタイプの一部は、「ルイズコピペ」や「ペロリスト」などのネタを経て「萌え豚」に進化してる。
彼らは「自分の趣味を一般に認めてもらおう」という欲求を持たないのも特徴的。
ISを見て、素直にブヒィと言えたら一人前だ。(これは消費行動のネタ化)
自身を「オタクではない」と思うタイプの人間はイタイオタクを切り捨てるタイプの奴に多いが、「他オタ」の概念で考えている。
「いやいやお前はオタだ」と言う方は「自オタ」の概念で考えている。
今までCrCh2という拡張を使用。これはマウスオーバーでレス抽出ポップアップ機能がなくてかなり不便だった。
Firefoxのアドオンのchaikaみたいなライトユーザー向け2ちゃんねる閲覧の拡張機能を探していた。
2ch browser userscriptを入れてみた。OSがMacの場合、2ch browser userscriptがおすすめ。
もちろん画像URLのサムネポップ表示機能有り。ID、レス番をマウスオーバーでレス抽出機能有り。
WindowsだとNullpo 2ch ReaderがFirefoxのアドオンのchaikaに一番近くて使いやすいと思う。
今までAdBlockという拡張を使用。これは表示が崩れて読めないサイトがたまにある。
例えばYouTubeを見るとレイアウトが一部崩れて表示が読めない部分があった。
今回Adblock Plus for Google Chrome(Beta)を入れたらYouTubeの画面もちゃんと補正されて全部読める。
ただし、Adblock Plus for Google Chrome(Beta)はデフォルト設定のままでは、Japanese向けの広告をブロックしないので、設定でオプションにJapanese向けのリストを追加したほうがよい。
Japanese向けのリストのURLはググればすぐ出てくる。URLをコピペしたのをリストにブチ込むだけでいいので超簡単。
人の幸せを喜べるってそれ自体すごく幸せなことなんだね。余裕があったり、自分に納得していると言うことだから。私は人の幸せをふと邪魔してみたくなることがある。
羨ましい人やねたましい物事があったとき、「まあ幸せそうだけど見えないところでいろいろと苦労や苦痛があるんだろう」と考え、「だから羨ましがるのは辞めよう」と結論する。そう考えるから落ち着く。では、本当に見たまま幸せいっぱいで不幸の影などなかったとしたら、私は納得できるか。横目でほころびを探さないか。
とはいえ最近は、他人の幸せをいくら欲したって手に入らない、それは他人の人生だって分かりつつあるけれど。
憧れや願望だけでなく嫉妬だって自分を拡張する動力になるから有用だし、これしか自分の人生はないと早々決め付けるのも、妙な抑制だと思うけどそれはまた別の話。
私は心から誰かにおめでとうと言えたことがない。言えるようになるべきかな。それが成熟した大人かな。目指すべきだとしてできるようになるかな。わからないけど、冒頭の私の言葉が真ならやっぱり言えるようになりたい。
「公式 Chrome ウェブアプリ はてなブックマーク」でコメントページを表示すると、旧UIのようにコメントだけを一覧表示できていい感じ。
というわけで訓練されたはてブ民の間ではuser.jsなどで飛ばしたりアレするのが流行るものと思われるが、グリモンだかなんだかに馴染みのない私は、今さら誰も触れないであろうProxomitronを使った転送方法を記しておく。
適当ながらメタブ対策を盛り込んでみたのがチャームポイント。
#はてブのコメントページをChrome Web App版に飛ばす 2011/05/17 14:50 (^$OHDR(Referer:http://b.hatena.ne.jp/viewer\?))$URL(http://b.hatena.ne.jp/entry(/|\?mode=more?url=)(s/$SET(#=https://)|(http(s|)://)\#|(^(^[^/]++.))$SET(#=http://))(\#))$SET(9=$UESC(\@))$JUMP(http://b.hatena.ne.jp/viewer?entry=$ESC(\9)) ($OHDR(Referer:http://b.hatena.ne.jp/viewer\?))$URL((http://b.hatena.ne.jp/entry/*)\0)$SET(9=$UESC(\0))$JUMP(http://b.hatena.ne.jp/viewer?entry=$ESC(\9))
下の行はメタブのためのmatch。タイトル下のブクマ数カウンターをクリックするとメタブページへ飛ぶようになる。不要ならばコメントアウト。
不具合があればどこかでid:Falkyをidコールするか@Sizukenにmentionを飛ばすかすると直るかも。
UIの好き嫌いが分かれてる感じですが、好き放題CSSを流し込んで左ペインさんに消えていただいたり、jsいじくってインラインプレビューを無効化したり、ちょこちょこいじってやるとそこそこ快適なブコメビューワになりますよ。新UIよりはずいぶんマシな感じですね。http://img.ly/system/uploads/000/993/748/original_PrtSc_000114.png
新アップローダがかなりドイヒーなので転載。http://www42.tok2.com/home/proxo/4.html
<<< URLControlフィルタ >>> これはURLを扱うヘッダフィルタを1つにまとめるフィルタです。 ime.nuを飛ばしたり、他のサイトにジャンプさせたりと、指定の 仕方次第で様々なことが実現出来ます。 バージョン4.5以上推奨。 4.4以下で動くかは不明。(バージョンアップ推奨) (インストール方法) 1、オミトロンフォルダ内のListsフォルダの中に URLControl.txt という テキストファイルを作る。 2、このテキストファイルを 設定、BlockFile、追加 から URLControl と いう名前でオミトロンに登録する。 3、下のヘッダフィルタをオミトロンに追加する。 範囲選択で下のフィルタを選択、コピー、ファイル、設定フィルタの併合、 クリップボードからデータを併合、ファイル、デフォルトの設定に保存。 ----------------------- [HTTP headers] In = FALSE Out = TRUE Key = "URL: URLControl (Out)" Match = "$LST(URLControl)" ----------------------- 4 URLControl.txt にURLとその処理方法を登録すれば完成。 ( URLControl.txt の記述例 ) 書き方は $URL(http://付きのURL)行いたい処理 という感じです。 例、 # ヤフー上のページにアクセスしようとしたらgoogleのトップページに飛ばす。 $URL(http://www.yahoo.co.jp/)$JUMP(http://www.google.co.jp/) #------------------------- URLControl.txt ------------------------- # NOADDURL # 先頭に # がある行は無視されます。 # 2chでimeの広告ページを踏まずに直接リンク先に行く。 $URL(([^:]+:/+)\0(ime.(nu|st)/|pinktower.com/)(\1))$JUMP(\0\1) # したらばで、広告ページを踏まずに直接リンク先に行く。 $URL(http://jbbs.shitaraba.com/bbs/link.cgi\?url=\0)$JUMP(\0) # Livedoor ブログ検索 $URL(http://sf.livedoor.com/show\?blog_url=([^&]+)\0)$JUMP(\0) # 旧tripodにアクセスしようとしてたら移転先のinfoseekに飛ばす。(2種類) $URL(([^:]+:/+)\0(cgi|members).tripod.co.jp/([^/]+)\1\2)$JUMP(\0\1.at.infoseek.co.jp\2) $URL(([^:]+:/+)\0([^/]++.|)\1tripod.co.jp/)$JUMP(\0\1at.infoseek.co.jp\p\q\a) # Proxomitron-Jでウェブフィルタを無効にする。 $URL(http://www.pluto.dti.ne.jp/~tengu/proxomitron/)$FILTER(False) # Proxomitron User's Wikiでウェブフィルタを無効にする。 $URL(http://abc.s65.xrea.com/prox/wiki/)$FILTER(False) ### 以下はコメントアウトして無効になっています。 ### 有効にしたい場合はコード行の先頭の # を消して下さい。 # local.ptron/以下に接続するときはWEBフィルタを無効にする。 # Bypassリストから local.ptron/ を消してこれを使えば # local.ptron/ にもヘッダフィルタが使えます。 #$URL(http://local.ptron/)$FILTER(False) # アクセスするときにキーボードのSキーを押していたらページのソースを表示する。 #$KEYCHK(S)$URL(([^:]+:/+)\0\1)$RDIR(\0\xsrc..bypass..\1) # アクセスするときにキーボードのDキーを押していたらデバックモードでソースを表示する。 #$KEYCHK(D)$URL(([^:]+:/+)\0\1)$RDIR(\0\xdbug..\1) # pya! で「18歳以上ですか? はい、いいえ」ページをスキップ。 #$URL(http://pya.cc/pyaimg/han.php\?han=\0)$JUMP(http://pya.cc/pyaimg/spimg.php?imgid=\0) #------------------------- URLControl.txt ------------------------- ※ \k はマッチ欄では動かないのでこのフィルタでは使えません。 \kを使いたい処理は Kill-a-URL フィルタをご利用下さい。 更新情報 : 2004/4/14 -> 2006/4/18 リストを更新。
はてな匿名ダイアリーを見て思った、最速でプログラミング言語を覚える為の10か条。
最初に覚える言語は、目的が明確でない場合はJavaかPythonを推奨する。言語仕様が簡潔で、資料が豊富で、応用範囲が比較的広い。
http://b.hatena.ne.jp/register
こちらにもブックマークレットが複数載っていますが、なじみのはてブ追加ページを使いたいので書いてみました。
javascript:window.location='http://b.hatena.ne.jp/はてなID/add.confirm?&url='+escape(location.href);
もう一つは「ブックマークしてコメントする」をクリックするもの。
無言ブクマやコメントをするだけならば「追加する」ボタンでいいのですが、
タグを付けるのなら二つ目の方法が楽です。私はそちらを使っています。
PHPerの問題点は、視野が狭いこと。典型的には以下のような悪癖を持つ。
何も知らないからPHPを愛せるんだよ、PHPerは。だからまず、HTML、CSS、JavaScript、SQLを覚えろ。次に、Javaに移行しろ。そんなに難しくないよ、Java。特に大量にコードを書けるPHPerは、速度が出てライブラリ化が容易なJavaの方が向いている。今はVPSがあるので、小規模案件でも問題ない。
15年間ほどPHPはインターネットを支えてきたが、そろそろ設計の脆さが問題になっている。PHP 6の開発が振り出しに戻ったのは、不幸な事故ではない。ウェブで仕事をしていれば、PHPとJavaで共通する知識も多い。PHPerはJavaを覚えてPHPとさよならしろ。そして恥ずかしい悪癖を直すべきだ。
元記事 http://anond.hatelabo.jp/20110328213318 の引用がアレで読みにくいので
http://synodos.livedoor.biz/archives/1720131.html
キセイガー/カンリョーガー脳の恐怖である。
これに対して、市場メカニズムを活用すれば、効率性の高い企業を自然に選別することが可能である。ひとつのやり方は、池田信夫氏がかなり早い段階で提唱した「電力消費税」(http://news.livedoor.com/article/detail/5412902/)を導入することである。これは、電力需要を抑制するために税を課すというもので、実務的には電力料金を引上げるだけであるから、すぐに実行可能である。
この方法では、電力料金を引上げても、利潤が出る効率性の高い優良企業は生産をつづける一方、効率性の低いゾンビ企業は休業をすることになるから、自然に効率性による選別が可能となる。また、病院や老人ホームなど、効率性とは別の観点から重要性が高い施設は、そもそも電力料金を引上げなければ良い。
問題は、電力料金を引上げると東京電力の収入になってしまうと勘違いされ、消費者が納得しないという点であるが、最終的に東京電力の売上高から、政府が電力消費税を吸い上げることになるから、東京電力を儲けさせることにはならない。このことをきちんと政府が明言して実行すればよい。
電力料金引上げによる電力需要抑制の最大の問題は、消費者の納得なんぞではなく、電力の需要曲線の形状が不明な点にある。言い換えれば、いくら料金を上げたらどれだけ電力使用量が少なくなるかわからない、ということ。既に周知が進んでいるが、供給能力を上回る電力が使用されると、予測不能な大規模停電の確率が極めて高くなる。これだけ値上げしたらこれだけの使用で収まると思ったんだけど、思った以上に使われちゃいました、なんて事態が生じれば、ライフラインその他に甚大な障害が生じる。それに比べれば、
しかしながら、本来、計画停電や総量規制のような「社会主義的な手段」は、命の問題にとっても、生産活動にとっても、非常に「非効率」である。早い震災復興を望むのであれば、こうした手段をつづけたり、大規模に行うことは望ましくない。生産活動にとって非効率というのは、生産性の高い企業も、生産性の低い企業も一緒くたに休業させてしまうからである。
たとえば、同じ電力量で10の生産を行う優良企業と、2しか生産できないゾンビ企業(本来であれば死んでいる非効率な企業)があるとしよう。両方とも電力量を平等に半分にされると、各企業の生産はそれぞれ5(優良企業)、1(ゾンビ企業)となり、生産量がそれぞれ半分になる。両者の合計は6であり、元の12から生産量は半減する。
一方で、優良企業には休業させず、ゾンビ企業のみ休業させるということであれば、生産量は10である。つまり、優良企業は元の通り10の生産を行い、2しか生産できないゾンビ企業が休業して0になるから、元の生産量12に対して、事後的な生産量は10とわずかな生産減ですむ。
この程度の非効率性など、どうってことはない。また、
問題は、このように効率的な生産を行う企業とそうでない企業をどう選別するかということであるが、計画停電はすべてが一緒くたになるので、選別は不可能である。また、効率性は高くなくても、必要性の高い病院や老人ホームは電力供給をつづけることが望ましいが、そうした重要度に応じた選別も不可能である。
予測不能な大規模停電が起きてしまえば、病院等の選別もまた不可能である。事前に対策が講じられる分だけ、予測不能な大規模停電より計画停電の方がはるかに適切なのは、言うまでもない。
加えて、鈴木氏は、次のようなことを言っている。
これに対して、電力事業というものは、どのようなときにも安定的な電力供給を行わなければならないという「供給義務」が課されているため、夏場数日間の昼間における一番のピーク時に対応するために、きわめて過剰な発電所設備を保有しているのである。このためじつは、普段は、発電所はあり余っている状態なのである。
このような過剰設備を許しているのが電力会社への規制であり、「総括原価方式」の下、どのように過剰な設備をもっていてもすべて電力料金に転嫁でき、しかも地域独占によって競争相手にさらされずに、料金を引上げられることが、その背景である。
これを経済学ではアバーチ・ジョンソン効果と呼んでおり、過剰設備、非効率の典型例とされる。また、電力会社も、経済産業省の官僚も、発電所設備を拡大することで利権があるので、こうした規模拡大にさらに拍車がかかる。
その是非はさておき、
ついでにいえば、西日本と東日本で電力の周波数が違い、変電設備が貧弱で、1日100万キロワットしか電力会社間で融通しあえないことも、今回露呈した大きな問題である。これは、電力会社の地域独占を守ろうとする既得権保持行動にほかならないだろう。国が公費を投じてでも、変電設備を拡張してリスクを分散したり、電力会社間の競争を促すことは合理的であると思われる。
東西の周波数変換など、こうした事態でもなければ遊休化すること必定であり、過剰設備・非効率が不適切だというなら、周波数変換はそれ以上に不適切である(注1・2)。結局、本当に過剰設備・非効率性を問題にしたいのではなく、キセイガー/カンリョーガーと言いたいだけなのだろう。
もっとも、各家庭まですべてピークロード・プライシングをするというのは、消費者は驚き、反対も大きいであろう。東京電力の電力需要の過半は企業需要であるから、まずはフランスの電力公社(EDF)が1957年から導入しているように、企業に対して、季節別・時間別・業種別のピークロード・プライシングをはじめることが現実的である。
少なくとも、ヨーロッパ全土で電力が相互融通可能であることを前提としたフランスのピークロード・プライシングを日本に導入することの是非は、これほど単純な話ではない。繰り返すが、価格を上げた割に使用量が減らなければ、ヨーロッパなら他国から買ってくればよいが、日本ではそうは問屋がおろさず、大規模停電の確率が上がるのだ。
教訓:非専門家が思いつくようなことは、専門家がとっくに思いついた上で、利害得失を計算して採りえないとしたものがほとんどである。
(注1)
今回のようなケースとしては、2002年に東電で原発のデータ隠しが発覚し、東電の全原発17基がすべてストップしたことがあった(2003年4~6月)。夏場の大停電が危惧され、東西連系線の拡張などが論議されたが、「投資額が莫大で、それなら自前で発電所を建設した方がよい」(電力業界関係者)として頓挫した経緯がある。
http://wedge.ismedia.jp/articles/-/1285?page=2
(注2)
ピークが異ならなければ、地域間の電力流用によって全体の必要設備量は変わらないが、日本でピークが異なるのは、北日本に限られる。すなわち、東西の電力流用を推し進めても、東京電力の必要設備量は減らない。
http://synodos.livedoor.biz/archives/1720131.html
キセイガー/カンリョーガー脳の恐怖である。
>これに対して、市場メカニズムを活用すれば、効率性の高い企業を自然に選別することが可能である。ひとつのやり方は、池田信夫氏がかなり早い段階で提唱した「電力消費税」(http://news.livedoor.com/article/detail/5412902/)を導入することである。これは、電力需要を抑制するために税を課すというもので、実務的には電力料金を引上げるだけであるから、すぐに実行可能である。
>
>この方法では、電力料金を引上げても、利潤が出る効率性の高い優良企業は生産をつづける一方、効率性の低いゾンビ企業は休業をすることになるから、自然に効率性による選別が可能となる。また、病院や老人ホームなど、効率性とは別の観点から重要性が高い施設は、そもそも電力料金を引上げなければ良い。
>
>問題は、電力料金を引上げると東京電力の収入になってしまうと勘違いされ、消費者が納得しないという点であるが、最終的に東京電力の売上高から、政府が電力消費税を吸い上げることになるから、東京電力を儲けさせることにはならない。このことをきちんと政府が明言して実行すればよい。
電力料金引上げによる電力需要抑制の最大の問題は、消費者の納得なんぞではなく、電力の需要曲線の形状が不明な点にある。言い換えれば、いくら料金を上げたらどれだけ電力使用量が少なくなるかわからない、ということ。既に周知が進んでいるが、供給能力を上回る電力が使用されると、予測不能な大規模停電の確率が極めて高くなる。これだけ値上げしたらこれだけの使用で収まると思ったんだけど、思った以上に使われちゃいました、なんて事態が生じれば、ライフラインその他に甚大な障害が生じる。それに比べれば、
>しかしながら、本来、計画停電や総量規制のような「社会主義的な手段」は、命の問題にとっても、生産活動にとっても、非常に「非効率」である。早い震災復興を望むのであれば、こうした手段をつづけたり、大規模に行うことは望ましくない。生産活動にとって非効率というのは、生産性の高い企業も、生産性の低い企業も一緒くたに休業させてしまうからである。
>
>たとえば、同じ電力量で10の生産を行う優良企業と、2しか生産できないゾンビ企業(本来であれば死んでいる非効率な企業)があるとしよう。両方とも電力量を平等に半分にされると、各企業の生産はそれぞれ5(優良企業)、1(ゾンビ企業)となり、生産量がそれぞれ半分になる。両者の合計は6であり、元の12から生産量は半減する。
>
>一方で、優良企業には休業させず、ゾンビ企業のみ休業させるということであれば、生産量は10である。つまり、優良企業は元の通り10の生産を行い、2しか生産できないゾンビ企業が休業して0になるから、元の生産量12に対して、事後的な生産量は10とわずかな生産減ですむ。
この程度の非効率性など、どうってことはない。また、
>問題は、このように効率的な生産を行う企業とそうでない企業をどう選別するかということであるが、計画停電はすべてが一緒くたになるので、選別は不可能である。また、効率性は高くなくても、必要性の高い病院や老人ホームは電力供給をつづけることが望ましいが、そうした重要度に応じた選別も不可能である。
予測不能な大規模停電が起きてしまえば、病院等の選別もまた不可能である。事前に対策が講じられる分だけ、予測不能な大規模停電より計画停電の方がはるかに適切なのは、言うまでもない。
加えて、鈴木氏は、次のようなことを言っている。
>これに対して、電力事業というものは、どのようなときにも安定的な電力供給を行わなければならないという「供給義務」が課されているため、夏場数日間の昼間における一番のピーク時に対応するために、きわめて過剰な発電所設備を保有しているのである。このためじつは、普段は、発電所はあり余っている状態なのである。
>
>このような過剰設備を許しているのが電力会社への規制であり、「総括原価方式」の下、どのように過剰な設備をもっていてもすべて電力料金に転嫁でき、しかも地域独占によって競争相手にさらされずに、料金を引上げられることが、その背景である。
>
>これを経済学ではアバーチ・ジョンソン効果と呼んでおり、過剰設備、非効率の典型例とされる。また、電力会社も、経済産業省の官僚も、発電所設備を拡大することで利権があるので、こうした規模拡大にさらに拍車がかかる。
その是非はさておき、
>ついでにいえば、西日本と東日本で電力の周波数が違い、変電設備が貧弱で、1日100万キロワットしか電力会社間で融通しあえないことも、今回露呈した大きな問題である。これは、電力会社の地域独占を守ろうとする既得権保持行動にほかならないだろう。国が公費を投じてでも、変電設備を拡張してリスクを分散したり、電力会社間の競争を促すことは合理的であると思われる。
東西の周波数変換など、こうした事態でもなければ遊休化すること必定であり、過剰設備・非効率が不適切だというなら、周波数変換はそれ以上に不適切である(注1・2)。結局、本当に過剰設備・非効率性を問題にしたいのではなく、キセイガー/カンリョーガーと言いたいだけなのだろう。
>もっとも、各家庭まですべてピークロード・プライシングをするというのは、消費者は驚き、反対も大きいであろう。東京電力の電力需要の過半は企業需要であるから、まずはフランスの電力公社(EDF)が1957年から導入しているように、企業に対して、季節別・時間別・業種別のピークロード・プライシングをはじめることが現実的である。
少なくとも、ヨーロッパ全土で電力が相互融通可能であることを前提としたフランスのピークロード・プライシングを日本に導入することの是非は、これほど単純な話ではない。繰り返すが、価格を上げた割に使用量が減らなければ、ヨーロッパなら他国から買ってくればよいが、日本ではそうは問屋がおろさず、大規模停電の確率が上がるのだ。
教訓:非専門家が思いつくようなことは、専門家がとっくに思いついた上で、利害得失を計算して採りえないとしたものがほとんどである。
(注1)
> 今回のようなケースとしては、2002年に東電で原発のデータ隠しが発覚し、東電の全原発17基がすべてストップしたことがあった(2003年4~6月)。夏場の大停電が危惧され、東西連系線の拡張などが論議されたが、「投資額が莫大で、それなら自前で発電所を建設した方がよい」(電力業界関係者)として頓挫した経緯がある。
http://wedge.ismedia.jp/articles/-/1285?page=2
(注2)
ピークが異ならなければ、地域間の電力流用によって全体の必要設備量は変わらないが、日本でピークが異なるのは、北日本に限られる。すなわち、東西の電力流用を推し進めても、東京電力の必要設備量は減らない。
ペロペロ
1. htmlのはき出しがあるやつは?>を書いたほうがいいよ。それ以外は最近はかないのがはやりだねさらに昔はevalとかで書いてた
2. configこれはwwwやpublic_html以下にしかconfigを配置できないクソサーバーがあるので、phpにしておいたほうが安全。なぜなら丸見えにしてあれこれパスをさらけ出すバカがいるかもしれないからだ。オープンソースなら特に。
3. コメントは挨拶だ。必要以上に挨拶を繰り返す必要もないし、それ以上でも以下でもない。
4. eclipseのせいと、phpとかが出始めたころのコーディング規約がスペースにするように求めた。{を改行してから書くか、続けて書くかのこれは宗教戦争だ。だが正直スペースは気に食わない。LLのくせに何バイトつかってるのだとおもう。あとスペース2文字インデントのやつは旅立て!
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. ああそうだな、関数が1スクロールに収まらないときは大抵正規化に失敗してる。つくりをみなおせ
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で用意された既製関数で多くのことが実現できることに、(俺の仕事を減らすなと)驚くはずだ。
この記事があなたの役に立たない事を。
ふざけんな!
2年以上前に考えていて、まぁ自分なりには納得して終わったことになっていことなのだが、
はてな匿名ダイアリーの書き方をやっとわかったので、もしかしたら有用な考えかもしれないと思うので公開するだけ公開してみる。
以下には私が考える「ゲーム」と言うものに関して、面白さの分析をするための枠組みを整理した。
ただ、これらを満たしていないからダメだと言うものではなく、期待したものとその「ゲーム」が提供するものが
どの程度フィットしているか?と言う視点で分析すべきだと考える。
現在、様々な形式のゲームが存在し、多種多様な楽しみを提供するに至っている。
近年のゲームは洗練され、プレイヤーの参加意欲(モチベーション)を維持するために様々な工夫が施されている。本塙ではゲームの面白さについて議論する枠組みを提供するため、「ゲーム」および「ゲームにおける楽しみの分類」を以下のように設定する。
ひとり以上のプレイヤーが明示的もしくは暗黙的に定められたルールのもとで主体的に活動を行い、各々にとっての最適解に至るプロセスを専ら楽しむ枠組み
使いやすいようにゲームが提供する楽しみの分類6つについて名前を付けておく。なお、これらの用語はすべて私の造語である。
ゲームが提供する楽しみは以下の分類のどれかに大別できると考える。
ゲームにおいて、より最適な解を導くことに直結するゲームのルールのより深い理解や法則の発見や学習による自己成長などの楽しみ
ゲームにおいて、最適解を求めるに当たり、より有利な状況を得る楽しみ
ゲームにおいて、他のプレイヤもしくはその代替との間における駆け引きや協力、また単純な情報のやりとりなど、様々な形での対話による楽しみ
ゲームにおいて、ゲーム内での活動によって発生する反応の刺激によって感じられる楽しみ
ゲームにおいて、物質的もしくはデータとしての報酬によって得られる楽しみ
なお、上記の楽しみを阻害する要因を極力排除されていることが望ましいが、難易度とのバランスは適切に設定されるべきである。
また、これらはプレイヤーが何を最適解と捉えるかにより、多少の判断の違いは許容されるべきであると考える。
(一般的には「インタレスト」を「ゲーム性」ととらえていることが多いと思うが、そこにこだわらない等)
もし論議をする場合、最適解をどう捉えるかの前提を確認することを強く推奨する。
自分がゲームを選ぶ時にもこの分析を適用し、自分がどのような要素を期待しているのか、どのような要素は受け入れる準備があるのかを把握し、
選択しようとしているゲームはどのような要素が期待できるか考えて判断の基準に使うとよいだろう。
もし、批判する場合、当初の想定した要素と実際にはどのような要素が強かったかを整理すれば、より建設的な批判になると考える。
あまりにも投げっぱなしな気がしたので、適用の仕方について、ちょっと追記。
たとえば、「将棋」のようなゲームでは「インタレスト」が支配的で補足的に「サクセス」があるイメージ。
一般的な「ギャルゲー」は「エンタテインメント」や「コミュニケート」が支配的だが、メタ視点のプレイヤがシナリオを深く理解することにより、
行動を変化させ、それが最適解につながるような構造を持っている場合「インタレスト」性があると考えても良いだろう。
「ひぐらしのなく頃に」と言った特殊なものは、本編をプレイ後、ネット等を通じて他者と意見交換すると言う現実世界での枠組みまで拡張して
ゲームととらえることにより「エンタテインメント」だけでなく「コミュニケート」を持ったゲームとして解釈できる。
実例ありがとう。
言及された「元カレに尻穴まで開発されていた女」と結婚するかどうかを
自分に確認するチャンスが生まれるので
ただもしそれが嫌なら離婚という手はあるよね、子供がいたらハードルが上がるけれど。
それでも少なくとも自分の人生の伴侶を構成する性格要素に「都合の悪いことは言わない妻」というのがわかるだけで
心の痛みと引換えに、
これからの人生における状況判断できるファクターが増えてメリットも大きいじゃないかな。
それこそ浮気隠しを知らないほうがいいだなんてとても思えない。
人は「知りたくなかった」と感じるということだね。
で、もちろん心的ダメージに対する耐性は人それぞれ違うと。