プログラムの面白さについて考えるスレ

「プログラム」する事の面白さについて考えるスレ
好きでソフト組んでるヤツ！一度この面白さはいったいなんなのか考えようじゃないか

ｒ――――――――――――――――
|　 ２ゲットズザー
| 　　　　　＿＿.ｒ――――――――――――――
.＼　　／ 　　　.|　氏のう
　　∨　　　　 　|　 ＿＿＿＿ｒ――――――――
　　　　　　　　　 ∨　　　　　｜氏にたくないよ。
日　ロ　∩　日　凸　�U　日｜ 　 ＿＿＿＿＿＿
≡≡≡≡≡≡≡≡≡≡≡｜ 　/　.　∧ ∧　　／￣￣￣￣￣
　凸 　目　�U　∩　［］　凵　　∨％　（ﾟ∀ﾟ ;） ＜ 俺はゴミかよ
＿　∧∧ ＿＿∧∧＿＿　 ∧∧ 　　|つ∽）_　 ＼＿＿＿＿＿
　　(　　 ,,)日　(ﾟДﾟ,,)　.皿 （　　,,,)　∇
― / 　 | ―　/ 　 |つ｝―φ.|　　 |―――
＼(＿_.ﾉ　＼(＿_.ﾉ　　 　　　(＿_.ン
　━┳━ 　 ━┳━ 　　 ━┳━
￣　┻ ￣￣　 ┻ ￣￣￣　┻￣￣￣￣

あれ？なんか面白そうなスレがたったね。

>>3そんなことないよ　プンプン＊

数学や物理を解くときの面白さに似てる

物は作り上げるまでが楽しいものだ。
金を取ろうとか、どこぞに掲載しようとかいうのは
二の次の話である。

故に、作り終わると熱意も冷めるのである。

- ジョージ・俺

>>6
作る作業に対して、
腐った部分の尻拭いの割合がどのくらいまで増えれば、
作る作業への楽しさ、熱意は薄れていくんだろうね。

デバッガでバグ追ってる時が一番幸せでふ。

仕様書（計画書）をシュレッダーにかける瞬間が最高でふ。

>>7
その問題は割合というよりも、熟練度の問題かも。
初心者にとっては何もかもが未知だから新しい発見に面白がるかもしれない。
でも熟練者はいい加減嫌になる、って感じかもな。

そして今日もまたリンカエラー・・・。

予想通りになるところが好き。

俺が組んだとこのバグが出る
↓
「ほ〜ら、な？ここでこのバグ出ると思ってたよ。さすが俺だな。ははは。」

プログラムの良いところは半田付けも配線もしなくても
板金も溶接も細かな部品を集めなくても
からくりが作れるところだ

>>12
それはあるな。どうもあのハンダの焼ける臭いが嫌だ。

俺は半田付けも配線も好きだな。Ｈ／Ｗおこして、それを制御する。
思い通りに動いたときに幸せを感じる。Ｈ／Ｗ制御が絡まない販売管理の
システム等も面白いと感じている。考えてみると、みんな面白い。
ﾃﾞﾊﾞｶﾞﾒ根性旺盛だから、何でも面白く感じることができるんだと思ふ。

１つのプログラミングにどのくらいの歳月を費やしますか？（average）

さあ、少し早いが飯にしよう。

フリーなら3日
シェアなら1ヶ月〜
Ver1.00リリースまでの期間
月間各タイトル2本づつくらいのペースで売れてるよ・・・

たとえばお前ら、プログラムすること意外ですきな事ってなに？

>>18
ありません。


このレスはあなたの希望を満足しましたか？　[YES]　[NO]

希望を満足？

プログラムの希望を満足について考えるスレ

>>18
綺麗な映像をみること。
(ものによるが)ＳＦアニメが好き。
ＳＦやファンタジーの映画が結構好き。
新国立劇場で音楽聴くのが好き。

　 ∧＿∧
　（　´∀｀）＜　ぬるぽ

「こんなん無理だよ〜」と思ってたものを、
無事作り上げることができた時ものすごく嬉しい。
大変だっただけ喜びも倍増。
あとチームで作業やってると嫌なこととかあるけど
やっぱ楽しいな。

フリーゲームプログラマの折れは
自分が作り上げた世界、法則、ルールで
遊んでいる人をみるのがすごく楽しい
自分の仕掛けたイベントに驚いてくれたりするともう最高だな

新しい分野のプログラムを目の前にして挫折して。
しばらく忘れて久しぶりに紐解いたら、何故かすらすら理解できた時の感動ったらもう。

age

子供がくるくる回ってて、白いパンツがチラッと見えたときはもう最高だな

ｿﾚﾊ ﾀﾉｼｸ ﾅｲｯ!!
　 （　・∀・）　　　|　|　ｶﾞｯ
　と　　　　）　 　 |　|
　　 Ｙ　/ノ　　　 人
　　　 /　）　 　 < 　>__Λ∩
　 ＿/し'　／／. Ｖ｀Д´）/ 　
　（＿フ彡　　　　　 　　/ 　←>>23

作りかけのプログラム動かしてて、ここはヤヴァいんちゃうかな〜？と思ったところでぴたっとぬるぽが出ると、やや気持ええな。
思わず「ｶﾞｯ」とか口走ったりして

バグの原因が見つけられなくてものすごい悩んで、
ちょっと気分転換しようと休憩してたらふと
思いついて試したらドンピシャリうまくいった時。
かなり嬉しい。

必死で仕様通りに作って客先に持っていってデモしたら
「あ、ここはこういう意味じゃなかったんですよ、こうしてください」
「え〜〜〜、そうだったんですかぁ！？」
って展開になると、凄いヘコむ。苦労して作った部分だと特に。

最近は完動したときの感動は薄れつつある。
もう慣れすぎたのかなぁ。

ここのところのヤリガイは、
・難易度の高い、他人のコードを理解できた時
・自分が(間接的にでも)関わった製品を街中で見かけた時
・開発チームの一体感を感じた時
かなぁ。

>>32
わかるなあ。
苦労して作った部分を
「うーん、ここはいらないかな」とあっさり却下されたりすると
へこむ。まあ仕事だから仕方ないけど・・

仕事なら人も殺しちゃうタイプ↑

>>34
そのうちパンチドランカー状態になるって(w
日常茶飯事すぎて気にもならないよ。

>>34
あんたら、作る前にきかないの？仕事なのに？ｵｲｵｲ

>>37
聞いてるよ。
作る前は必要だと言っていてもその後
「やっぱりいらない」って結論になった時。

>>37
客：「これこれこんな感じで。」
俺：「分かりました。じゃあそうします。」
↓完成
俺：「作成中ですがこちらが一応動作する分です。」
客：「こんな感じになるんですか。・・・それじゃあいらないなあ。」

>>39
本番系プロトタイピング

まず、以下のプログラムを組んでみることだな。

int main(){
tinko();
}
int tinko(){
tinko();
}

Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
tinko.c:
警告 W8065 tinko.c 2: プロトタイプ宣言のない関数 'tinko' の呼び出し(関数 main )
警告 W8070 tinko.c 3: 関数は値を返すべき(関数 main )
警告 W8065 tinko.c 5: プロトタイプ宣言のない関数 'tinko' の呼び出し(関数 tinko )

警告 W8070 tinko.c 6: 関数は値を返すべき(関数 tinko )
Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland

>>42
ワーニングだけなのか。

>42
ﾜﾗﾀ

VC++6.0
--------------------構成: TestProgram - Win32 Debug--------------------
ｺﾝﾊﾟｲﾙ中...
TestProgram.cpp
C:\zzz\CppProg\TestProgram.cpp(2) : error C2065: 'tinko' : 定義されていない識別子です。
C:\zzz\CppProg\TestProgram.cpp(3) : warning C4508: 'main' : 関数に戻り値の型が指定されていません。戻り値を void 型と見なします。
C:\zzz\CppProg\TestProgram.cpp(4) : error C2373: 'tinko' : 再定義されています。異なる型修飾子です。
cl.exe の実行ｴﾗｰ

TestProgram.exe - ｴﾗｰ 2、警告 1

>>38
それは、世間で言うところの「聞けてない」なんだが。

客の要望を聞いてくるのと、客の言うことを聞いてくるのは
大いに違うんだよ。
ウチの営業もそんな感じなんだが・・・

>>46
お客が一番、何が欲しいのか分かってないからねえ。

御用聞きしかできない能無しがコンサルタントを名乗って高給
盗っていると、絞め殺してやりたくなるね。

>>47
>お客が一番、何が欲しいのか分かってないからねえ。

当たり前だ。
お客はやりたいことはわかってても、どんなソフトが欲しいかわかるわけがない。
やりたいことを聞いて、どんなソフトを作るかをきめるのがソフト屋の仕事。

>>48
作るソフトウェアによってお金が違ってきますから、
どんなソフトを作るかを決めるのはお客さまです。
ソフト屋には、「こんなソフトに作ると、このくらいお金がかかる」
と言う情報を提示する事しかできません。

本当にそのソフトでお客さまの抱えている問題を解決できるのかどうか、
そのためにはどのくらいお金をかけられるのか、
これらについては、お客さまとソフト屋で話し合って決めるのです。

48のようなことを言う上司がいる会社の社員は大変だね。

>>49-50は営業経験無しですか？
プログラマでも営業は経験しておいたほうがいいよ。
ソリューションできないとSEになれない。

>>48
かな〜り希望的な観測のようです。
お客様は、ご自分のやりたいことが何なのか す ら 分かっていないことが多いんです。

わかっていないので、
・話を聞かなければならない。でも、まとまってなくて冗長。聞いただけでは足りないことがいくつも。
・なので、何回か打ち合せる。でも、その度に結論が変わったりする。
・内容をきちんと詰めようとして話が長くなると、その分内容のまとめに時間がかかるし、意味もなく細かい仕様が膨らんで、けっきょく訳が分からなくなる。
・話を聞くのに時間がかかってしまい、けっきょく作る時間が削られる
んです。

もちろん、こちらが聞き取ってまとめる能力に欠けているという点も大いにあります。
でも、お客様の側にも、もう少しだけこちらの事情に御理解を頂ければ、お互いに幸せになれるのになぁ、と思うことがなきにしもあらずでして。
コンピュータ導入は、結果として多かれ少なかれ業態の変化＝痛みを伴うものなんだということがどーしても納得できないお客様がいらっしゃるんですよ。
最終的に、作ってる側から見て筋の通らない仕様になることが多いですね。
顧客第一ですし、予算と時間が余っているなんてこと今の時代にはあり得ませんから、けっきょくそれを許すことになってますけど、そういうほころびのない仕様にするのが本来の仕事だとは思うんですよ。

>>52
の言っている問題を克服することが楽しいと感じられたらいいんだがな

俺は本当に客が欲しがるものより、「俺が客の立場だったら、こんなソフトが欲しい」と自分本位なソフトをつくろうとしてしまうな、その場合は自分の欲しいものを作るわけだから作ってて楽しいんだよな。

客が欲しがるソフトを忠実につくるのは「こんなクソソフトつくりたくねーよ」と思いながらいやいや作る作業になるな。

　 ∧,,∧　　ちょっといい話。
　ミ,,ﾟДﾟ彡　　ここまで、読んだ。
　ﾐつ[|lllll］).
〜ﾐ　　 ﾐ
　 ∪''∪

>>>52
>の言っている問題を克服することが楽しいと感じられたらいいんだがな
↑この辺の事が楽しいと感じられるPGは素晴らしいSEとなる事が多いよね

>>52
私はあまり上流には携わってないですけど…

> 話を聞くのに時間がかかってしまい、けっきょく作る時間が削られる

はどうでしょうね？
インタビュー、要求定義、仕様検討のあたりにかけられてる時間は
今の大抵の現場ではむしろ少なすぎると思いますよ。
もっともっとそのあたりに時間をかけておけば下流工程が
ずっと少ない時間で終わるのではないかと。

>>56
それはプログラムに入る前に仕様をがっちがちに固めてしまうという意味ですか？

>57
そーです。納品物のコーディングを始めるのは全行程の
1/2くらいのところからでもいいのではないかと。

…うーん、やっぱりちょっと古い考え方かも。
イマ風にアレンジすると、上流工程でも技術調査用のツールや
プロトタイプをどんどん作ってそれらをネタにしつつ
お客様と話をして仕様を固めていくような形になるかな。

>>56
XPって言葉ご存知？

上のほうにプログラムのほかに好きな事・・って話があったけど
俺は昔バンドやってた。
何かの本にＰＧは元バンドマンってのが以外に多いっていうのが載ってて
その本の見解としては「おそらく彼らはノモを使いこなすのが楽しいんでしょう」という事だったが
俺としては、「自分の創造したものを作る」のが楽しい。
バンドでコピーやるのはオペレータやるとの同じでまったく興味ないから最初からオリジナルでやったし。

自分の考えは，おおかた間違っていないと証明された瞬間がやっぱうれしいねぇ．
つまり，うまくプログラムが走った瞬間．

大体みんなそうなんじゃないの？

>>61
なんか俺は違うな。
どちらかというと
>>60 派かな
作ろうとするものがだんだん形になっていくのが楽しい

俺も基本的に60派だね
あと、仕事の上でとなると
自分の工夫で入れた機能をお客が気に入ってくれたときかな

俺も60派、
最近は何でもオブジェクト指向で綺麗に設計する時代だけど、
なんかやってて面白くないよね、あれ。
スパゲティーソースになっても即効動かして張りぼてて機能拡張が作る側は楽しいと思うんだけど、どうよ？

ユースケースとかアクティビティー図とかそんなのがはびこる昨今、
つまんなくなりました。
オブジェクト指向くらいまでは楽しさがあった。

>>65
ユースケースとかアクティビティ・・・オブジェクト指向そのものなんですけど？？

趣味で作るプログラムでは目標を高く高く持って、それに向かって突き進むのが好き。
業務の場合では、客先からの要求に答えるのは最低限で、「＋α」の部分を提供するのが好き。

>>64
きさまか！
このシステムのコーディング担当者は！
おまえのせいで俺が苦労しとるんじゃーー！

>>60
その、ものを使いこなすのを楽しんでいるらしい元バンドマンが
作ったコードってオブジェクト指向どころか構造化手法も使っていなさそう・・。
ライブラリ厨と化して、自分でパターンに沿ったフレームワークやAPIも
作らず、コーディング規約も守らず、ソースコードも読みにくくなって、
引継ぎのことも考えないでとにかく使えればいいんだ、
職人みたいに使えればいいんだ、
他人が読みやすいコードなんかどうでもいい、という方向に・・・・。

昔はプログラムを譜面にたとえて算譜といっていたんだね。
楽譜はオブジェクト指向ではとても考えられない喩えとなってしまったけどね。
音楽だったら再生する、演奏すればバグがどこにあるか耳でわかる。
けどプログラムはそうはいかない。そこで構造化手法やオブジェクト指向が生まれた。

>>65
アクティビティは昔のフローチャートみたいな感があって控えめにしたい。
けどUMLでクラス図や、コンポーネント図、配置図などで
自分の世界を描くのって楽しい。

よく、アイディアがひらめいたときクラス図や配置図で描くことが多い。

>>68
それはわかる。

>>60見たいな人は本人だけは楽しそうだけど
ライブラリも既に存在するのにわざわざ自作しそうだ。
知識の共有と言う概念もなくて、本人にソースコードを独占されそう。
自分にしかわからないようなプログラミング、
大規模プログラミングではまじでああいうのは避けて欲しい。

ちゃんとXP(eXtreme Programming)やRUP(Rational Unified Process)
を実践して欲しい。

俺の意見は少数派だったのか・・・
でもよくよく考えてみると，創ることへの快感も結構あるなぁ．

>>69
音楽理論は頭痛がするくらい複雑な幾何学だよ。
楽器の構造は物理法則に忠実だしね。
バンドも音楽も意外に構造化された世界なんだな。
聴くに耐えん厨房バンドと見るに耐えんスパゲッティとに共通点は多いな。
どちらも道具に溺れて基本を忘れてしまっている、と。

真剣に音楽した香具師なら分かるはずだが、
ビシッと音がハマった瞬間はソースのロジックの美しさに似てるし、
わざと音やリズムを外す気分は、例外処理をソツなくキメた感覚に近いな。
音楽はある線越えると理系領域でつ。

うははは！漏れはジャズメンだったからいつもコンパイラとインプロビゼーション
だヨ！！

なんて言えるようなものってないかな。

何が楽しいかって話をしただけであって
仕事でどんな風にやってるかはまったく別問題なんですけど・・

あ、でもソースコードは芸術だと思うけどね。
シンプルイズベストな論理の芸術、ＯＯにも処理負荷の分散配分にも相当こだわる方だと思うよ、俺

ちなみに61の言っている瞬間は、楽しいというよりホッとするな

>>73
幾多のユーザのレコードロックをかいくぐり、
ｺｿｰﾘと作ったストアド走らせて不正データを補正する瞬間。
正に息詰まるアドリブ、これぞ瞬間の芸術！



つか、不正データをコミットさせるなタコ。
楽しそうにみえるのは君への気遣いなんだよ、冷や汗かいてるソコの新人君よ。

75の補足。
今日、75のような場面に出くわしますた。鬱。
でも処理中はわくわく。

たかだかロマン派前後で止まってる音楽理論をいつまでも引きずっているヤツはアフォだ！
今すぐ、現代音楽へレッツアンドゴー！

>>77
言わんとしてることは分かるが。
現代音楽よりピタゴラス時代の音楽の方がよほど前衛的に思えるんだな。
ところで、ビートルズからメタリカあたりまではロマン派以前の音楽理論で収まったりする。
あふぉは言い過ぎかと。現代音楽も幅広い音楽ジャンルの一つって意味では、雅楽や賛美歌と等価なんだから。
で、現代音楽的なコーディングって可読性はどうなんだろ。
ふと、「ジョンゾーンが書いたJAVAソース」と言う恐ろしい連想をしたのだが。

ケージの「４分33秒」なら数行で書けて可読性抜群

どうでもいいが、プログラムはともかく音楽に理論的な美しさを追求するのは糞だろ
そりゃあ一通りの知識はいるだろうが、作曲するときに大切なのは心だし、出来上がった曲の良し悪しはその曲が理論的に美しいかとか、理論的に高度かとか、そんな事が決めるわけじゃないからさ

　　 ,.´ / Vヽヽ
　　　 ! i iﾉﾉﾘ）) 〉
　　　 i l l.´ヮ｀ﾉﾘ　＜先生！こんなのがありました！
　　　 l く/_只ヽ 　　　
　　|￣￣￣￣￣|
http://saitama.gasuki.com/aomori/

>>80
あなたは今、バッハや一部の前衛を全否定してしまった訳ですが。それはそれとして。
プログラムだって美しいロジックのために書く訳じゃないだろ？
いちいち分かりきったことを得意気に書くな。
ここは楽しみを語るスレであって本質を語るスレじゃない。
つー訳で80はスレ違いな上に、話の意図をつかめていない日本語不自由君なんだな。

>>80
>音楽に理論的な美しさを追求するのは糞だろ
音楽作品は広義の「美」を追求して生まれる芸術だから、優れた音楽は理論的にも優れている。
（複雑＝高度ではない。基本と言われる３コードだって本当に極めるのはとても難しいぜ！）
音楽理論は作曲のための構築理論だけでなく、存在する音に対する解析理論の側面もある訳で、
優れた音楽作品の長所を理論的解析することこそが音楽理論の役割なんだがな。

>作曲するときに大切なのは心だし
ﾌﾟ。あんた音楽は素人だね。素人は「糞」だとか大きな口を叩かないこと。
数多い要求定義と制約条件がつきまとう音楽製作現場で「心」なんて厨房言う暇ねぇぜ。
せいぜい「感性」や「イマジネーション」にしておくべし。

>出来上がった曲の良し悪しはその曲が理論的に美しいかとか、理論的に高度かとか、
ある音楽が理論的に高度かどうか、理論的に美しいかどうかなんて、それこそジャンルによって千差万別、
作曲者固有の主観的な価値観の出るところだからさ、作曲するときに「好みの理論的美しさ」を指向するのも
イマジネーションの再現手段として有効と思われ。

>>80は理論知識が中途半端な香具師がよく言う台詞なんで過剰反応してしまった。
仕様・設計とコーディングの間にも、同じような誤解と断裂があるよな。

何が楽しいのかって？

　人　の　バ　グ　を　見　つ　け　る　の　が　楽　し　い

んじゃないか！

音楽理論でバッハ大聖堂が作れるんだよねえ。あの大七不思議好きなんだよ。

>>84
絵負恵不８とか、目が未転成とか、露没吐大戦をやってみなさい。
あなたならきっと楽しめますよ。

>>86
遊んでいるものについては実害あるから楽しくねーよ

　知り合いが一生懸命組んで自身満々な
　プログラムのアホくさいバグを見つけて
　指摘してへこますのが楽しい

んじゃないか！



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・・・・・・・・俺って・・・(´・ω・｀)

アホくさいバグを指摘されても、へこみませんが何か？
バグを発見してくれた人には素直に感謝だろ

バグ発見したしたヤツは死刑です。

プログラム好きな奴は、理論が好きで音楽まで理論で聞くやつが多いんだなと思った
音楽くらい心で聞こうよ。。多分意味通じないと思うけど

>>90
ようわからへんけど、そらジャンルにもよるんちゃうか？
理論などどうでもええなんて香具師に、ジャズをプレーすることは無理やと思うしな
まあ仕事以外の話やからどうでもええわい

プログラム以外はナンパにしか興味ありませんが何か？

>>92
それ正常だろ

生殖器にしか興味ありませんが何か？

俺、プラグラムは好きでもゲームまったく好きじゃないんだけど
そういうヤツいる？

心で聞いて、本当に好きになったから楽譜を買って、
楽譜を読みながら聞いているうちに構造的美しさを発見するのであった。

そうして構造的に完璧を期している曲をあまた聴いているさなか、
突然現代音楽と出会う。その、衝撃。
新しいパラダイムを構築しようとする作曲家たちの熱い魂を
君は発見することになる。

心で聞くからこそ、
構造的美への探究心や脱構築へのもがきが
目の前に立ち現れては消えていくのである。

あぁ、>>90よ。オマエの心は音楽を聴いていない。

>>90
音楽理論について、中途半端な素人さん特有の誤解があるようだね。
音楽理論はルールではなくて自然法則なんだ。
ある意味ではすべての可聴音に適用され得るんだよ。
そこには最適解なんてありゃしねぇ。

野球観戦で選手のデータを暗記して楽しむ奴がいる。
ゲームをしていて処理が想像できてもゲーム自体を楽しめるだろ？
聴いた音を自然に譜面化して解析できても、泣ける曲は泣ける。
音楽理論が感動の邪魔になるなら、理論にコダワリすぎか、知識不足だな。
理論を知っているから感動の理由の一端が分かる。それだけさ。

80はもう少し謙虚になれ。
音楽理論は物理や数学を使った「美の分析手法」なんだよ。
理論的美しさと音の美しさは比例するんだ。
美は主観的なもの。音の数学的整合性≠音楽の理論的美しさ、だからな。

APIや既存アルゴリズムのつぎはぎがコーディングの全てではないように、
音大入試に出るような堅牢な各種手法の組み合わせで作曲する訳ではない。
そんなの常識以前。当たり前だ。

音楽理論はソースジェネレータでもライブラリ関数でもない。
もっと基底にある法則だ。厨房な理解で知ったかレス書くな。タコ。

>>97
> 音楽理論はルールではなくて自然法則なんだ。

自然法則に逆らった現象は起こりえないから、音楽理論に逆らった
曲は存在し得ないのだな？

音楽理論は法則ではない。
ある特定の音楽において定石とされる音の使い方を集めたにすぎない。
さらに、それを覚えやすいように名前を付けて体系化した。

音楽理論に美しさも数学的整合性もない。
ただ、対象とした音楽の音の使い方を集めて、覚えやすいような
体系にしただけ。

Musical Low ではなくて、Musical Theory なのは、法則ではないからだな。

Lydian Chromatic Low ではなくて、Lydian Chromatic Concept なのは、法則ではないからだな。

>>99-101
馬鹿は「理論」と「法則」とを同じに捕らえる。
「理論」は theory であって、数学のように閉じた系での theory は low そのもの
になるけれど、野球のバットの振り方や音楽の音の使い方、器楽形式などの
theory は concept や experience となる。low じゃあない。
物理学などの theory は lows of nature と数学の low との組み合わせで、
若干整合性に欠ける「理論」になる。
「高めの球にはこうバットを振るのがセオリーだよ」の「セオリー」は
「理論」である。
こんなことも知らないから、音楽理論が自然法則になったりしちゃう。
「セオリー」と「理論」とに違う意味を感じている人は、
「音楽セオリー」と言い直すと、より的確に理解できるだろう。

音楽理論は整合性もないもんね。Low ではないね。全然。定理も証明もないし。
再実験して 100% 再現するわけでもないし。
ほんとに、覚えやすいように体系化したって当たってるよ。

>>99
音が物理現象である以上、音楽理論も自然法則と等価なんだが。
音階の成り立ちからやり直してね。楽典の最初の方に書いてあるよ。

定石？はぁ？
それは例えば和声進行法など理論の応用手法であって、理論「全体」ではないよ。

99はツールをハリボテで組み合わせたコーディングしかしないのかい？

構築と脱構築、各種の民族音楽との融合や変異を繰り返しながら、
今なお音楽と音楽理論の世界は進化してるんだ。
リットーミュージックあたりの入門書読んだぐらいで知ったかするな。
VBしか知らないPG並にお粗末な反論だったぜ。

たとえば、「古典派」の「音楽セオリー」は、モーツァルトやヘンデルたちの
「好み」を、モーツァルトやヘンデルじゃない人が覚えやすいように体系化
しただけだからね。

>>104
馬鹿だなあ。
音は物理現象そのものだけど、音楽は、物理現象が、聴覚器官に入って
人間の体の都合に合わせて変換されて、そこで情報の欠落が起きて、
さらに脳が、アタック、音色、経時関係の相対音度、同時関係の相対音度、
その他、ある特定の音の断片にしか反応しない脳細胞によりバラバラに
しょりされて、最後にまとまった音として主観的な体験の場にのぼる、
それがわれわれが体験する音楽なんだよ。
だから、音は物理現象だけれど、音楽は生理現象と心理的現象なんだ。
さらに、それらはすべて解明されているわけじゃなくて、ほとんど
解明されていない。
そんなことも知らないのか。
それに悪いが、おれはバークリー音楽院を主席で卒業している。

なるほどね。
音楽は物理現象じゃないんだね。
コンピュータは自然法則にしたがって動くけど、音楽は自然法則にしたがって
感動するわけじゃないんだね。

>>104 は音は知っているのだろうが、音楽は知らないのでしょう。

>>106 さんに追加して言えば：

脳がそうやって処理する過程で、聴き手の個人的体験、過去の記憶や将来への
夢なども相互作用して、聴き手独自の only one な音楽として体験されます。

あんまりマ界に関係ない話題ならsage進行してくれんかの？

>>104
音楽を「人間として」聴くのではなく、測定器を使って聞くんだったら
おっしゃるとおりですな。

>>104
> 構築と脱構築、各種の民族音楽との融合や変異を繰り返しながら、
> 今なお音楽と音楽理論の世界は進化してるんだ。

じゃあなおさら自然法則じゃないじゃん (w

>>103
再現性がないのは演奏であって、音の法則ではない。
レベル低い反論だな。
1オクターブの定義は音波sin(x)とsin2(x)の数比。
きちっと物理法則と経験則の一致点から紬ぎだされてるの。
ちょっと入門書かじった程度の知識で芸術を冒涜するな、春厨よ。

>>104
物理であれ何であれ、自然法則も全ては明らかにされていない。
1+1=2は経験則から導かれた定理であって、仕組みを論理で証明できない。
理論や法則自体が人間知の範囲で共有できる仮説の集合である。音楽理論も同じ。
音響には詳しいみたいだが、教養に欠けるようだな。

>>104
> 定石？はぁ？
> それは例えば和声進行法など理論の応用手法であって、理論「全体」ではないよ。

「和声進行」って意味不明だが。「和声」または「和音進行」のことだろ。
リットーミュージックあたりを読んで知ったかするな。すっこんでろ。

>>113
1+1=2 は経験則じゃないの。加算の定義よりそうなるの。
数学を知らないようだけど、数学では、あらかじめ演算の定義を行うの。
それから、いくつかの定義を組み合わせて、必ず成り立つ定理を見つけるの。
つまり、自分でルールを作って、そのルールを破らないで成り立つものを
たくさん見つけるわけ。
だから、数学は閉じた系なの。

>>113
物理学と数学とを混同しているね。

> 物理であれ何であれ、自然法則も全ては明らかにされていない。
> 1+1=2は経験則から導かれた定理であって、...

物理学は、観測から現象がなんらかの数学的な表現として表せないかということを
やっていて、わりと数学で表すことに成功しているわけ。
だから、物理学の「理論」は完全な整合性はないの。矛盾もたくさんするの。
観測には誤差がともなうし、表した数式も、それがよく成り立つだけだから
当てはめているだけで、近似式かもしれないし。
実際、近時式の方が多いし。
観測できないばかりに理論が作れないこともある。

ところが、数学は、自分で足し算はこう定義する、複素数はこう定義する、
と定義が先にあって、その定義に完全にしたがって演算をするから、
100% 矛盾がないわけ。
矛盾するような結果が出たらその数学理論は破綻しているわけ。
破綻したら、その数学理論を捨てるか、定義を修正する。
数学の場合は、観測といったあいまいな要素が入らないから、定義がしっかり
していれば矛盾も不整合もまったく起こらないわけ。

http://www.agemasukudasai.com/bloom/

これって遠大な自作自演？

>>113
> 再現性がないのは演奏であって、音の法則ではない。

音の法則は音楽の法則じゃないの。
音は物理現象そのものだけど、音楽は、物理現象が、聴覚器官に入って
人間の体の都合に合わせて変換されて、そこで情報の欠落が起きて、
さらに脳が、アタック、音色、経時関係の相対音度、同時関係の相対音度、
その他、ある特定の音の断片にしか反応しない脳細胞によりバラバラに
しょりされて、最後にまとまった音として主観的な体験の場にのぼる、
それがわれわれが体験する音楽なんだよ。
だから、音は物理現象だけれど、音楽は生理現象と心理的現象なんだ。
さらに、それらはすべて解明されているわけじゃなくて、ほとんど
解明されていない。

>>113
> 教養に欠けるようだな。

君のレベルの低さは、許容できないな。

>>119 さんに追加して言えば：

脳がそうやって処理する過程で、聴き手の個人的体験、過去の記憶や将来への
夢なども相互作用して、聴き手独自の only one な音楽として体験されます。

全レス面倒。整理して片づける。

○音楽の感動と音楽理論の関係は>>97-98で書いた通り。
感動の本質について異論はないが、
そこに法則性を見出す営みを糞扱いするのは筋違い。

○音の構成の類型化であるという反論について。
それらは理論から導かれた手法であって理論全体ではない。よって誤り。

○再現性について
音楽理論は感動の忠実な再現を主目的としていない。

○自然法則について。
自然法則から演繹された理論と正確を期すべきであった。すまぬ。
音楽理論に拡散と未知の領域があるのは、他の自然科学の理論と同じ。

>>122
> ○音の構成の類型化であるという反論について。
> それらは理論から導かれた手法であって理論全体ではない。よって誤り。

いろんな音楽の類似性からたとえば Cadence の理論ができたんじゃないんですか？

>>122
ピュタゴラスは 12 個の完全 5 度を重ねて、コンマをうまい具合に処理して
完全 8 度の中に収めこんで音階を作ったのですけれど、それが美しい証拠に
なるとは、そのときは誰も思わなかったのではないですか？

>>122
法則って言うのは、いついかなるときにも成り立つもののことですよね。

>>125
そうか。じゃあ、>>112 さんのいう音楽の法則に当てはまる曲を作れば、
すごいいい曲ができるわけか。
それはどこで勉強できるのかな。

音楽理論に精通していたビートルズがあんなにいい曲をたくさん出せたのは、
そういうわけだったのですね！

>>115-116
なるほど。俺の書き方悪かったな。
一部前衛では音の物理法則と既存音楽理論との垣根を払いつつあるから混同した。
その通り。音の物理法則を数学よろしく定義づけて音楽理論が存在する訳だ。

あと、和声進行をわざわざ和音進行に言い換えた揚げ足鳥のバカへ。
ホモフォニーの進行なら和音進行だろうが、ポリフォニーなら和声も進行するんだな。
がんがれよ。

で、未知の部分や人間の感覚器の限界についてコピペするバカ、
それは認知心理学の話であって音楽理論の話ではなかろう。

ということは、電子の波動方程式のエキスパートになれば、
すげー面白いゲームを書けるプログラマになれる、ひいては
大金持ちになれる青年実業家になれるんですね。
頑張ろうぜ、みんなぁ！

>>124-127
美しいとかイイ曲とか、主観的美意識を保証するものではない、と反論済。ガキだな。
わざわざ、72と捨てコテ使ってかいてるんだ、全文読んでから反論してくれ。
単に俺を叩きたいだけの暇つぶしなんだろうから、読む時間くらいあろう。

>>128
認知心理学は、人間の言語的な思考から感情がどう誘発されるか、同時に、
ある感情からどんな言語的な施行が誘発されるかを扱う学問なの。
感覚器官も音楽も関係ないの。

>131
反論すると揚げ足とるんだな。では逆に尋ねよう。
体験や教育によって主観的な美意識を構築する課程を扱う心理学や生理学の分野教えれ。

>>132
あ、破綻したな。答えられなくなってる。

>>123
鋭いな。
詭弁になるから反論止めて認めよう。
音楽理論は、物理や自然法則と違い人間の経験則を基に
数学、物理など諸学の財産を援用して構築されたものです。

が、しかし、感動や美という主観的認識の再現が可能な理論とは、
俺は一言も言ってないからな。
んなアホな読み違いは勘弁しろよ。

>>133
破綻？
俺の言いたいことは、
音楽聴くときの感動は、理論の「俺が感じる」美しさも一部含まれてるってこと。
理論で聴くのは糞だ、心で聞け、なんて煽られたから答えたまで。

そもそも音楽理論の本質を議論するつもりなどない。
ま、わざと揚げ足取って例外処理させて破綻させていく手法は見事だがな、
誰一人コテ背負わなかったところをみると、
煽り返されると反論できない単なる野次なんだろうな。

それよりどうよ。感覚器官と文化的価値観の形成はなんつー心理学なんだ？

>>128
> ホモフォニーの進行なら和音進行だろうが、ポリフォニーなら和声も進行するんだな。

大嘘。
ポリフォニーは、複数の異なる調または旋法の和声が同時に存在するだけのこと。
和声は進行しない。

>>132
揚げ足？　違うね。
あなたの言っていることが、間違いだらけだから、突込みどころ満載なの。
理論とか法則とか言っているけど、何を言うにしても言葉が正しくないの。

糞共。ｸｿして寝ろ。

ならば137なりの音楽理論の定義を書け。
理論と感動の相関性を書けよ。
それが全く俺の論旨と異なりかつ正しい文章であれば、俺の負けだよ。

議論の趣旨に無関係な間違い探しを揚げ足取りとは言わないのかね？

ここしかないでしょ？
http://homepage3.nifty.com/digikei/

●音楽理論なんていらねーよ！！バーカ！！●
http://music2.2ch.net/test/read.cgi/compose/1039718651/

ここにでも行ってくれ。

ふーん。136にとっては複数の旋律は和声を形成しない訳でつか。
勉強になりますた！ﾌﾟ
あんたの書いているのは、ポリフォニーの定義であって応用手法ではなかろう。
揚げ足鳥。ぴよぴよ鳴け。大嘘つきめ。

あのさー、
俺も作曲とプログラミングを両方やってるんで、
音楽とプログラムの比較みたいな話は興味あるけど、
音楽理論の話はやめろって。
絶対に喧嘩になるから。

オレの立場：

ソフトウエア工学は必要
（もちろん、広い意味で実践的な意味での｢ソフトウエア工学」ね。
プログラミングは極めて理詰めの世界だから）
音楽理論はいらん。
(ポップス作るのに音楽理論はいらん。それ以前に分からん(笑））

つか、今夜揚げ足取った人たちで、何人が72を読んだんだろう。
議論の趣旨がズレていく一方。

で、本題のプログラミングと音楽の類似と相違だが、
これだけ音楽に対する認識が違うとテーマにならないな。
残念。興味深い話題だったのに。

煽り入れた80に分かるよう答えたら原理主義者と厨房の反発買っちゃったな。
図らずも釣り大会になったが、
115と116と123の反論には納得した。ありがとう。
自分の説明で誤解与えた部分を是正できた。

あとの厨はすべて却下かな？

>>1
「作る」行為自体が楽しい。
バグを取るのも「作る」ことの一環だと思う。

実装の楽しさはやりつくされた
オブジェクト指向設計の楽しさもマンネリ化しつつあるか
XPみたいな珍奇な開発プロセスの探求でもするか
これを食べながらプログラムすると能率が上がる！みたいな

>>142
大昔、対位法をやっていて、たてのラインを見ると偶然に和音ができていて、
それを逆手にとって和声法ができたのと同じ。
対位法自体は和声が目的ではない。
ポリフォニーの旋律同士は和声が目的ではない。
「知性が高い」とは、物事をより細かく識別できること。

>>142
それだと「和声が進行する」のですか、それが何？

>>72
> 音楽はある線越えると理系領域でつ。

和声やオーケストレーションは他人に教えることができるが、
メロディの作り方は教えることはできない。
和声やオーケストレーションは技法だから、凡人でも一所懸命
練習すればそれなりのものはできる。
肝心のメロディは魂の奥の方から湧いてくるものなので、教える
ことはできない。
−−モーツァルト

それがどう理系ですか？

>>143
> 音楽理論はいらん。
> (ポップス作るのに音楽理論はいらん。それ以前に分からん(笑））

それでいいんだよ。
まず、聴いていて違和感がないサウンドが得られればいい。
理論は、あなたが理論を知らないで作った曲を体系化するために、
あとづけであなたがやった音の使い方をまとめたもの。
そういう順序でよい。

>>78
雅楽といえば東儀秀樹！！！！！秀樹マンセー、秀樹イカス！

プログラミングは気持ちが良い、ある種の変態だと自覚してる。

>>72 >>96-97
おまんは音響工学と聴覚心理学とディジタル信号処理と制御系でもやってればいーんだーー、とおもた。
音楽理論とオブジェクト指向は相容れない関係なんかー？

>>85 Civilizationやってた？

>>87
アルバイトでそれやったことあってマジで楽しかったけど一部の社員にかなり嫌がられた。

>>90
音楽理論は絶対音感を持ったものにのみ極めることができる宿命。

>>146
オブジェクト指向がマンネリ？
フレームワークの作り方次第、パターンをどれだけ知っているか次第だと思われ。

音楽楽しむのにそんな小難しいこと知らなければならんのか？
俺はそんなこと知らなくても十分楽しめると思うんだが・・・．
アラン・ケイが抱く現在のPCに対する不満を思い出したよ・・・．

>>154
一部の作曲家と音響を研究しているものだけ

>>153
音楽は、相対音感のためにできているから、絶対音感は必要でないばかりか、
音楽を楽しむ妨げになります。
音楽理論も相対音感の持ち主のためにできています。

プログラマーとシステムエンジニアの違いってなですか？ＳＥの概念がよくわかりません。

いずれ音楽理論に基づいた作曲プログラムが作られ、
カス作曲家は駆逐される。

>>154
楽しみ方による。

>>158
そんなプログラムあるじゃん。

>>157
古いスタイルの開発方法において、仕様書作成と実装やコーディングとを
分業していた頃の役割分担のこと。

>>158
すると、古典派からロマン派に発展したような、スイングからビーバップに発展したような、
従来のサウンドを超えた、または解釈をし直した音楽は詣でてこなく鳴っちゃうんだね。

再三になるが、音楽理論を糞扱いする>>80に対する反論が趣旨だからね。

>>147-148
な、和声進行するんだよ。
で、それは理論の原理や理論成立課程の重要なポイントではなく、
単なる応用手法にすぎん、と。なるほどね。
>>104で俺が書いた通りじゃん。
対位法や和音進行の原理を「応用手法」の例にあげるほど識別能力低くないからな。
最初からそう言ってるんだ。揚げ足鳥に夢中になって俺の論旨を忘れたんだね。

>>149
中世ヨーロッパにおいて理系科目だったんだよ。
それで十分だろ？反論のための反論みたいだから。

>>154-155
そう。理論など知らなくても楽しめるよ。
だからといって理論の主観的な美しさを楽しむことを糞扱いされたくはない。
それが俺の言いたいこと。

で、理論を用いた作曲というなかには、
禁則と知っていてあえて音を外すことも含んでいいと、俺は思う。
MethodとTheoryは区別したい。

だから自動作曲ツールの創造能力より人間の能力に期待するし、
理論が新しいサウンドを阻害するとは思わない。
知識に溺れて本質を履き違えたら意味がない。
だからと言って理論知識は糞ではない。
一面だけ抽出して全体を語るのは危険だぜ。

>>163
> >>147-148
> な、和声進行するんだよ。

しないじゃん。

>>163
> 中世ヨーロッパにおいて理系科目だったんだよ。

嘘。
音楽も物理学も数学も宗教も絵画も彫刻も、中世ヨーロッパでは哲学だった。

>>165
あほ。
よく読んで反論しろ。

>>166
Seven Liberal Arts か？
大きくは人文科学と称されていたな。だから何だ？
そのなかでは理系に属しているぞ？
音楽は自然科学に属すると言った訳ではなく、文理の区別を論じただけ。

揚げ足鳥はぴよぴよ鳴けよ。タコ。

>>167
ポリフォニーって転調のことだと思ってんだろ。
ハ長調からヘ長調に転調。
だとすれば、ハ長調の和声からヘ長調の和声に「進行」するかもな ( ゜○ ゜)

それより、>>72 は、作曲版で相手にされないから、門外漢が多いマ板で
自説を疲労しているんだろうよ。

>>167
あのう、なぜ「ぴよぴよ」なんでつか？
「コケコッコー！」じゃだめなのれつか？

念のため167の補足。
中世ヨーロッパにおいて自然科学に属していた、とは一言も書いていない。という意味。

くだらない曲解ばかりされるので萎えてくる。

間違いを書いたときは認めるが、
浅薄な知識振り回したり、原理主義的な宗教論争は目的ではなかろうに。

>>171
理屈はいいとして、あなたが悪態をつく言葉を書くから荒れるんじゃないでしょうか。

>>172
うんうん、「僕ちゃんなんでも知ってるもんね〜　ほかのやつはひよこで
ぴよぴよ〜だっぴょ〜ん」みたいな態度がいけないのでしょう。

>>72はオブジェクト指向についてどう思う？
音楽理論ができればプログラミングがうまくなるってのはオブジェクト指向の世界では
どうも違和感があるのだが。

>>168
そんなアホな勘違いする奴いるんか？＞ポリフォニーと転調
俺は転調には一言も触れていない。叩きが目的の決めつけは止めろよな。
何度も言うが揚げ足への反論であって理論知識の宗教論争じゃないの。

>>169
俺の目的か？>>60-168を全部読め。
理論知識を披露するのが主目的なら門外漢は相手にしない。

>>72や>>83で書いたように、プログラミングの面白さと音楽の共通点の有無が書きたいの。

>>170
お好きなように。

>>175
ポリフォニーは同時関係。
和声は経時関係。
和声は進行しない。
Chord Progression はあっても Harmony Progression なんてものはありえない。

まあいいや。
「和声が進行する」って書いてある本のタイトルと著者を上げてくれ。
自分で勉強するから。

>>171
はじめに糞と言ってきた>>80の>>90の失礼さに噛みついた。
以後は煽りを捌いただけ。確かに荒れるな。気をつけるようにする。

>>172
反論揚げ足に回答してるだけ。
知識の披露をしたいなら私塾開くか自費出版でもするさ。
知らんことも分からんこともイッパイあるから、それどころじゃないけどな。
現に>>123の意見に、俺は表現のマズさや思慮の浅さを悟り、訂正してるよ。

>>174
音楽の理論知識とプログラミングの巧さは比例しないと思う。
ライブラリ厨やツール厨と中途半端な音楽理論知識に頼る奴は似ているけどな。

で。音楽に対してオブジェクト指向なアプローチは可能かも知れないが、
作曲に関しては適用できないかも知れない。
俺は全ジャンルの音楽を極めた訳ではないから、個人的な考えとして話す他ないんだが。

難しいな。

本の件、実家にあると思う。
友人に確認するから、しばし待ってくれ。

>>180
よろしくお願いしまつ。

>>180
ちなみに、
http://www.google.co.jp/search?q=%E5%92%8C%E5%A3%B0%E9%80%B2%E8%A1%8C&ie=UTF-8&oe=UTF-8&hl=ja&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja
とかで出てくる「和声進行」って、「和音進行」の誤用の方が多いでしょ？
意識あわせのために、よろしくです。

了解。
誤用か否かを踏まえた上で紹介しよう。時間をくれ。
明日は出勤日だしの。

本論と関係ない箇所の字句の揚げ足に粘着する君に、敬意を表して必ず答えるよ。
音楽理論の知識があることは間違いなさそうだし。
知識の面では俺より上かもな。

・・・・・ここって何のスレですか？

↑
バークリー主席で卒業してもＰＧにしかなれない、というバークリーがいかにダメなものかを
再認識するスレ。

あららまさか、ここまで盛り上がってるとは・・

例えば理論や法則で計算つくされて作られた曲があったとしたら、俺はそんなの興味ないの。
俺は音楽やってるけど、音楽理論なんて興味もないし、はっきりいってどうでもいい。
率直に言って、よくそんなクソの役にもたたない音楽理論について勉強して
熱く語れるわと思ったよ

芸術に感動して、それをなぜ理論で考えようとするのかわからん
プログラムはともかく何でもかんでも理論で考えたらバカだよ

あんたら恋愛も理論でやってるんとちゃうの？？？？？？

何だか話がおかしな方向へ。。。。


本題に戻すと
やっぱ音楽もプログラミングも｢モノを作る楽しさ」っていうのがあるから
好きなんだよね。
でもプログラミングと音楽は作ってる時の思考回路がまるで違う。

プログラミングは常に論理的必然性を追い求める分野だと思うわけ。
オレはコードを書く時は常に｢この書き方が正しいのか？」
｢こう書く論理的必然性はあるのか？」と自問自答してる。
そして時々デザインパターンなどの技法を学ぶ。
｢どっちが正しいのか？」
そういう理詰めの世界の楽しさなんだよね。プログラミングは。

それに比べ音楽に論理的必然性なんてあるわけない。
｢このメロディの後に何故このメロディを続けるのか？」なんて
理由があるわけないんだからね。聞いて気持ち良ければそれでいい。
感覚が全ての世界。
｢音符が並んでるだけなのになぜいい曲と悪い曲があるんだろう？」
その感覚の不思議さを楽しむ世界なんだよね。音楽は。

オレ的には、プログラミングと音楽は論理と感覚の対極にあるようなジャンル。
（文系的な楽しみと理系的な楽しみ、と言い換えてもいい）
両方とてつもなく面白い。

>>187
超激しく同意！

んで
理論で恋愛やってる奴いたらカミングアウトしてねん
今日はとりあえず寝る

念のためだが、バークリー主席卒業君は俺に煽り入れた方ね。

で、>>186よ。あんたが例えばジャズやバッハなどを嫌いなのは分かった。
もちろんバッハだって全部が理論で計算されて作られている訳ではないだろうがな。

しかし、理論嫌いは80君の個人的好みの範疇だろ？
音楽理論がクソなどとは言われたくないね。
音楽にはいろんな聴き方や楽しみ方があるはずだが、
理論をも楽しむ聴き方を言下に否定するのは視野狭乍。
他人の感性にクソだとか厨なケチをつけないで頂きたい。

>>186
>プログラムはともかく何でもかんでも理論で考えたらバカだよ

俺が80君の意見に同意できるのは、この部分だけ。
80君には80君の見解があっていいが、他人の見解や趣味嗜好を糞バカ呼ばわりするな。

>>187
>それに比べ音楽に論理的必然性なんてあるわけない

これも同意。>>97で俺も明言している。
音楽理論をいかに極めようと、次の「音」の感覚的な美しさの論理的必然性なんてありゃしねぇ。
美しさが感覚や主観である以上、最適解すらもないだろう。

再三になるが、俺は「音楽理論が音の論理的必然性を保証するもの」という偏見を、誤解だと言いたいのだ。
俺のこれまでの発言の中で、（俺以外の人が書いたことはパスな）
「理論を知らなければ作曲できない」とか
「理論を知らなければ音楽は楽しめない」などとは書いていない。

俺が>>72で批判したのは、「知ったか音楽理論」でツギハギな曲を作る人についてであって、
音楽理論を知らない人間についてではない。別に音楽理論が神だとも思ってない。

ただ、音楽の楽しみ方には「主観的に感じる理論的美しさ」【も】ある。>>96に同意。
さらに、音楽そのものも存外構造美をもった世界であるように思う、と述べたまで。

>>72の言いたいことを>>80の表現で書くなら、

どうでもいいが、プログラムに理論的な美しさを追求するのは糞だろ
そりゃあ一通りの知識はいるだろうが、
プログラミングするときに大切なのは心だし、
出来上がったプログラムの良し悪しは
その設計が理論的に美しいかとか、
理論的に高度かとか、そんな事が決めるわけじゃないからさ

ってことかね。
プログラマーならこの表現が糞なのは自明だと思うけど、
そうじゃない人なら思わず納得してしまう文章だよね。

「音楽は感覚でなくてはならず、
　プログラムは理詰めでなければならない」
と決め付けることが>>80の心の狭さを表してるんだと思うよ。

音楽だって、恋愛だって、理論を持ち込むことは「できる」よ。
もちろん、本能だけで恋愛する事も不可能では無いだろうけどねぇ。


で、>>72の目的は、この前提が理解出来る人と、
理解できない人によって結論が出てしまいそうで怖い。

>>191
>どうでもいいが、プログラムに理論的な美しさを追求するのは糞だろ

俺はこんなこと一言も言ってないですよ。

>>>72の言いたいことを>>80の表現で書くなら、

えーっと。「>>80が>>72に言ってることをプログラムと音楽を入れ替えるなら」
ということですよね？？？
梨さんの意図は伝わるのですが（ありがとです）、誤解されると叩かれるので念のため。

俺は、プログラムも音楽も「主観的な」理論的美しさを求めています。
音楽において「禁則」を犯して脱構築することにも、パラドックス的な美を見出しています。
美を見出す根拠は言うまでもなく感覚ですが、しかし、理論的な側面を否定しません。そゆことです。

>>「音楽は感覚でなくてはならず、
>>　プログラムは理詰めでなければならない」

ふむ。コレは俺の経験から学んだ考えでもあるし、一般的な見解だと思うんだけど
音楽を理詰めで書いて成功した事例でもあるんかい？？

>>音楽だって、恋愛だって、理論を持ち込むことは「できる」よ。

これは判ってるよ、しかし・・・

>> 本能だけで恋愛する事も不可能では無いだろうけどねぇ

これこれ、この言葉を待ってた！
これってみんなどうよ？
理論を持ち込んで恋愛するのがデフォルトで
本能で恋愛するのがイレギュラーだという考えかた

これがプログラマーの恋愛なの？？？

>>192
禁則って禁じ手のことじゃないよ。やっちゃいけないと言っているわけでもない。
だから「犯す」のでも「パラドックス」でもない。
禁則といっているのは、特定の意図なしには使われない音の使い方、というだけの意味。

>>194
うんうん、平行 8 度は禁則だけど、tutti でやると効果的だよね。
うっかりやると変だけど。
その際立った効果がうかつに出ちゃうと困るから禁則にしてあるだけだし。

つーか。
プログラムのおもしろさはどこに逝った。(w

俺はソースやロジックの簡潔さとかには感動できるが、
音楽は感覚で聞いてるから、理論とか考える気になれないなぁ…。

>>194
>禁則って禁じ手のことじゃないよ。やっちゃいけないと言っているわけでもない。
>だから「犯す」のでも「パラドックス」でもない。
うん。そう。よくご存知ですね。話しやすい。
ただ、誰も「禁則＝パラドックス」とは言ってない。
単に俺の使い方が、俺自身が「パラドックス的」な美を見出す嗜好があるだけ。
禁則についての定義を書いたわけでなく、主語は俺で個人的見解。
そこは、当然理解していただけてますよね。

>>193
>これがプログラマーの恋愛なの？？？
どちらがデフォとも書いていないだろ？
よほどプログラマを特殊な存在と蔑みたいようだが。世の中、いろんな人がいるんだよ。

勘違いされると厄介なんでハッキリしておくが、俺、恋愛は本能派。
あまりに学習能力なくて、相手選びに何度も同じ失敗するくらい。

恋愛を理論化してる人たち、例えば水商売の方はそんなこと言ってたなぁ。

で、音楽理論の知識が豊富な方達に敢えて尋ねますが、
あなたがたは>>80のように理論を糞と思っているの？
理論知識が面白い音楽の楽しみ方を否定するの？
音楽理論を学ぶ行為はバカだと思いますか？

>>197
じゃあ、平行 8 度の tutti にパラドックス的なびを感じるんですね。

板違い。どっかいけ。

結論

　音楽理論はオブジェクト指向には勝てなかった。
　音楽理論は最新ソフトウェア工学には勝てなかった。
　音楽理論をプログラミングに持ち込むことは
　　は現代ソフトウェア工学から衰退した伝統的構造化手法支持者向けであった。
　音楽理論はパターン(デザインパターン、アナリシスパターン、アーキテクチャーパターン)
　　に勝てなかった。

どうだ＿＿？
　

まあ、>>80が、知性でも知識でも、圧倒的に>>72に負けていることは明らかだろう。
こんな場合、たぶん、感性とやらも負けてるんだと思う。

なんで？
音楽のことになると必死のやつが多いのか？（それとも一人かｗ？）
この業界はミュージシャンのおちこぼれでも多いのか（わら
過去を忘れれらないやつはしょせんこの業界でもおちこぼれ確実やろな（ｗ

>>200

俺は195にレスつけてない上に、具体例語ってはいない。
部分的言葉の無理矢理な一般化、目的は揚げ足かな？見苦しい

>>202

理論の目的が違うので、
ソフトウェア的観点からみた結論、そんなふうになるかも知れないな。
つか、優劣ではなく、構造の違いだろうな。
他の人はどうかな？

>>204

PGも音楽家も、一般の人に愛されるモノを作ろうと、
若干自己満足な、一般には分かりにくいこだわりを秘めて、
一生懸命に、しかし楽しく苦しい創造の日々を送ってるわけだよな。
その点だけは、理論派、感覚派を問わず共通だと思う。
マ板の真の住人なら、職人特有のこだわりを否定できないはずさ。
こだわり過ぎもまた良くないけどな。

正直、どうでもいい。

>>205
一般化じゃなくて、具象化、つまり特定化したわけだな。

>>201
禿堂

>>72 さん、あなたが突っ込まれるのは、書いてあることが論理的にもろい
からなんだよ。
理論理論といっているわりには、主張の文章に緻密さがない。
それは、あなたの中に一貫性がないからだ。
一貫性がないから、突っ込まれても整合性のある答えができない。

論理的に強靭な主張をするには、正しい言葉を正しい意味で使うことからだな。

>207
すまん。悪かった。
俺の挙げた一事象を一般化した上で具体化した訳だな。

で、揚げ足だけを取り続けるあんたの主張はなんだ？
単に感情的に俺がウザいだけなら、読まなきゃよい。
揚げ足晒しageな煽り目的なら他の住人に迷惑。
俺の主張に対峙したいなら捨てコテ背負って正面から論旨で論破してくれ。
そちらの方が勉強になるし、バンドマンが構造化以前のDQNかどうか>>60-69、
プログラミングと音楽の類似や相違について、有意な議論のきっかけになる。

寂しいのなら、もっと愉快なキャラに粘着した方がよい。

いったいぜんたいなにごとなんだ…

>>59
XP、名前だけ知ってます。教科書は読んだことないです。
（コーバーンの本は買った）
知らないのにいうのもなんだけど、正直懐疑的です。
ユーザーの要望のいわば「核心」が分からないうちに
ソフトウェアのアーキテクトを決められるものだろうか、と。

スレの本筋に即した話題に行くなら、ユーザーと話して
仕様検討したりするのはあまり楽しみではないです。

目的とする機能を汎用的なやり方で実現するような
設計を考える方が面白い。ただしそこで仕様の核心が
つかめていればこそ、後の仕様変更にも耐えられるように
設計することができるので仕様検討も大事なんですが。

>>213
>知らないのにいうのもなんだけど、

あなたへの反論はすべて、XPにあります。いますぐ読みましょう。

>>210
だから、お前が糞なんだよ。

>>213
> ユーザーの要望のいわば「核心」が分からないうちに
> ソフトウェアのアーキテクトを決められるものだろうか、と。

XP ではそんなことはしません。
ユーザの要求が決まらないうちに設計を始めたりはしません。

>>231
> 目的とする機能を汎用的なやり方で実現するような
> 設計を考える方が面白い。ただしそこで仕様の核心が
> つかめていればこそ、後の仕様変更にも耐えられるように
> 設計することができるので仕様検討も大事なんですが。

YAGNI. - You Aren't Going to Need It. どうせいらないって。

XP では、たとえ明日必要となるとわかっていても、明日のための設計はしません。
変更が確定となってから設計します。
こんな機能が必要そうだ、こんな拡張が考えられる、などと、客でもない
のに将来の仕様を予想してプログラムを組むような、社内リソースの無駄遣いは
しません。
拡張性を考えて設計せずに、顧客の要求を実現するのに特化した設計をします。

足し算のできる Money クラスを作っていて、将来掛け算が必要になりそうな気がしても、
掛け算をするやり方をわかっていても作ったりしません。
顧客が仕様を変更してきた時点で設計を変更します。もちろん、そのために
1 イテレーションいただきます。

>>231
これでも読み名よ。
http://objectclub.esm.co.jp/eXtremeProgramming/IsDesignDead.html

単純さの価値について
http://objectclub.esm.co.jp/eXtremeProgramming/IsDesignDead.html#N141

>>210-211
なかなか慧眼。感服する。
言葉が正確でない者と、文脈無視した言葉の揚げ足取りと。
確かにお似合いだよな。
突っ込む方は俺一人に的を絞って数行書くだけだから、緻密に正確に書けるよな。正直、羨ましい（ｗ。

だからなんだ？
一部の方のように横文字まで用いて正確かつ緻密な文章を書いて、
理論を糞と言い切る80に届くような反論ができるのか？
伝達のためには精確さを放棄して方便をも使う。
論に関係ない煽りは、適当に捌くよ。板違いだからな。

論理的必然性にコダワリ過ぎ。あなたと会話するには辞書が必要だな。

>>220
> 伝達のためには精確さを放棄して方便をも使う。

それがよくない。

>>220
> あなたと会話するには辞書が必要だな。

ぜひそうしてくれ。言葉の力を知ってくれ。

あ、ごめんなさい。
すっかりXPの話になってたんだ。
揚げ足君と日本語を語るより、こちらの方がいいや。
まだ未実践なので、大人しくROMしますね。

なりゅほど。
適切な言葉を選ぶと、最小の単語で強力なパワーを得られるからな。
そのためには、特に言葉を知らない人は、折に触れ辞書を友にするのがよいな。

XP。キーワードは、シンプル。アジャイル（註：アジャコングいる？と質問しているわけではない）。

215さんありがと。前言撤回、最後に駆逐しておくわ。

>>221
例えばC言語しか知らないが、C++は糞だと断言した奴に、
オブジェクト指向の必要を説明するには、
まず構造体の有用さから説明するだろ？
それがC++の観点から如何に理屈に隙があっても、だ。
まずは共通の土台を整備しようと試み、順に話さねばならん。
会話の基本だな。論文じゃないんだよ。

加えて音楽理論の用語や解釈には宗教論争も多く、これを語るには板違いだ。

222は女を口説く時−言葉に力が必要な瞬間−にも辞書並に精確な単語を使うのかな？
222的な揚げ足。

音楽＝気持ちよければいい
プログラム＝動けばいい
恋愛＝子供が出来なければいい

俺が取られた揚げ足手法の応用その2
>>223

「なりゅほど」って言う単語、辞書には見当たりませんが、
あなたは他人に辞書を推奨する前に、自分が辞書をひく習慣をつけた方が良さそうですね。

ぷぷぷ。

しかし。こうした揚げ足に議論を有意義に進める働きは全くない。
このレスの下らなさがその証明だ。

このレスに価値認めるなら誤字脱字隠語だらけで、不正確な日本語だらけの2chから去れ。

以上。

>>227　ﾜﾗﾀ。うまいね。

>>226
> 例えばC言語しか知らないが、C++は糞だと断言した奴に、
> オブジェクト指向の必要を説明するには、
> まず構造体の有用さから説明するだろ？

しないね。
知りもしないで糞だと判断するようなやつには言うだけエネルギーの無駄。
心を開いて学ぼうとするやつにだけ教える価値がある。

>>230
禿胴

>>230 禿同
別に教えなくとも俺は困らんし。

>知りもしないで糞だと判断するようなやつ
が五月蝿くのさばることができる時間は非常に限られている。ほっといても
すぐに消えるよ。

このスレ用に話をまとめると

>>72
は音楽理論に興味があり、
音楽とプログラムに共通する面白さは理論だと考えている

>>80
は音楽理論に興味がなく音楽は感性の産物と考えており
音楽とプログラムで共通する面白さは「ものをつくること」だと考えている

で両者よろしいか？

>234

上手いまとめかただね。
オレは72でも80でもないんだが
>187でも書いた通りオレは80よりの考えだね。

オレの意図はというと、
音楽とプログラミングを対比させることで
それぞれのジャンルの特徴とか面白さが浮き彫りになるだろうということ。

2chとかでプログラミングについて議論してる(時々煽りつつ(笑））と
｢そういう考え方があるのか」と知的な部分が刺激されて楽しい。
その一方で音楽を作ったり聴いたりしてると｢何でこの曲はいい曲に聞こえるんだろう？」と
感覚的な面で刺激されて楽しい。(音楽は言葉で語りづらいのが難だが）
とにかく両方楽しいんだよ（笑）。

プログラムって楽しいことだと思えてきた

>>234

ありがと。そんな感じかと。
どちらも楽しさや美しさは主観的、感覚的なものだから、どっちも似たり寄ったりかも。
ただ俺は音楽の理論的な構築美と、システム全体の論理整合性の美に共通点を見るのね。
チームのメンバー間のアレコレだとか、なんかにも。

対極という考え方も否定しないし、そんな側面もあるけど、類似性を感じたりもする。

>>234
ＯＫだす。

たとえば、俺はかっこいい建物とか見ると「あぁ、こんなん俺がつくったって言ったらかっこいいだろうなぁ」とか思うし、
クラブやライブの照明がかっこよかった時「あぁ、こんな風に光を操れたらいいなぁ」とか思う
あと、花火見てすげーと思ったら「あぁ、こんな風に花火を操って人を感動させれたら面白いだろうな」とかも思う
他にも色々あるけど

建築も照明も花火も、「ひとりじゃとてもできない」し、金がかかるよね

音楽はギター一本、キーボード一つあれば、ひとりでできるし
しかもそれだで下手したらプロを超えるものがつくれるかもしれない

プログラムも同じで、パソコン一台あれば、これまで誰も考えられなかったような凄いゲームや、ツールが作れるかもしれない。

そういうお手軽さと広大なロマン（？）が音楽とプログラムに共通する楽しさだと思う

やっぱり「創る」喜びかな。
基本的に何かを創るって楽しい作業なんだけど
プログラムはその敷居が低いと思う、創りやすいとでもいおうか。
PC一台あればその中限定といえいくらでもプログラムは創り出せる。
日曜大工だと道具があっても材料の調達が面倒とか失敗したときのダメージが大きいとか。

あー、いまいちよくまとまらん。

ＰＧにロリが多いのも「創る」喜びからだな

あんただけです。

飽きちゃった。ぎゃはっ！

作曲もプログラミングも人をあっと驚かせたいってのがある。
だから職業ＰＧは向いてないと悟ったさ。けど、惰性でやるのも嫌なんでなんとか楽しもうとして
やってるんだけど。勉強するのもそのためだね。
>>238、>>239 も言ってるように音楽もプログラミングもその「敷居の低さ」から両方やってる人が多いのかな？とは思う。
私は敷居が「低い」だけで両方足突っ込んで泥沼だけどね（それはそれでいいんだけどｗ）
なんか>>80と>>72って実際にお互いあってみたら意外と馬が合うんじゃないかと思って書きました。

80君がどう感じてるか知らないが、
音楽理論否定するのｲｸﾅｲ、意外に音世界の構造も美しいぜ、
って言いたかっただけで、揚げ足が酷かったんで一時荒れたものの、
239には実は同意できたりもする。
ま、音楽が商売になると感覚ばかりでは食えなくって、
クソ設計のタコソフトをコーディングするような苦しみを、
よりによって音楽で味わう羽目になる。
それもファンの要求じゃなくてDQNマネジメントの命令で。
で、この際どちらが妥協できるかと言えば、末端ユーザの手応えが分かるPGの方、
んな訳で商売変えて数年経つ。

DB構築時に正規化を理屈通りやっちまうと
パフォーマンスが低下したり不要なindexが増えたりするように、
中途半端な知識で音楽理論や定石に金科玉条の如く縛られちゃうと
悲惨な曲ができたりもするんだ。

そういう意味で理論揚げ足鳥さんたちには、知識面では尊敬できるものの、
試験や論文でもない「面白さを語るスレ」で正確さを求める姿勢に？と感じた。
プログラムは感傷を許さないが音楽にはそのキャパがあると思う。
理論的な厳密さを求めるのではなく、理論のゆとりを楽しめる、
そこが作り手にとっての音楽の良さかと思う。

普通はDB設計前に徹底的にベンチマーク取らないか？
机上で正規化して後から速度が云々とか言い出すやつは素人確定。
業界去れ。

>>246

とはいえ、どういうデータの取り方するかにもよるんだから
（更新が少なくてよく参照されるから、メモリにとっておいて更新するときだけDBにアクセスしよう、とか）
後から云々っていうのはよくあることではあるよ。

それくらい気にせずどんどんリファクタリングしましょう。

>>246
たとえ話に揚げ足ご苦労さん。
マ板で素人扱いされれば真剣に答えるべきだろな。
仕事によっては、アカの他人が構築したDBを見せられてギョッとするシーンがあるんだよ。
245のDBの喩えはｲｸﾅｲ例を書いた。俺がしたこととは一言も書いてない。
勝手に素人扱いされると困るな。
つか、新規構築が案件の全てと決めつける246の視野の狭さこそ危ういよ。
世間は広いからね。

>>247
フォローありがとう。
現場によっては、柔軟に対応しないといけない罠。

スレ違いだからこれ最後にするけど
>>72
そもそも音楽はじめたのが、あるバンドを聞いて感動したからなんだけど
　あの時の涙が止まらないくらいの感動は絶対に理論や計算では得られないと思うんだよ
何故かというと、感動したのは旋律としての音楽ではなくて「曲を通して伝えようとしている内容」だと思うから。
↑みたいな経験したやつなら絶対わかると思うんだけど。音楽で大切なのは理論じゃない、理論そのものに興味があるなら勉強するのは結構だけど、音楽にとって全然大切なものではない。

・・と俺は思ってて俺の中では常識

>>72は自分が普通だと思ってるだろうけど、俺から見ると、凄い音楽的な挑戦をしているように見える
そこまで音楽理論に執着あるヤツって俺シラネーよ、マジ>>72の作った曲とか興味あるけどね

俺は絵に感動したことないけど
ピカソやゴッホ見て涙流すツレがいるよ。そのツレは絵に対して俺が今音楽に対して言ったような事言ってたな。

>>245
> 中途半端な知識で音楽理論や定石に金科玉条の如く縛られちゃうと
> 悲惨な曲ができたりもするんだ。

音楽理論は、より自由になるために勉強するのに、縛られちゃう人がいるんだね。
法律じゃないんだからね。

どう読んで>>234のようには読めん。
たんに>>80は、音楽への思い入れにみせかけた「俺ってえらいだろ」を
ウマシカな人がやってるようにしか見えん。
ま、>>72がなっとくしてるんならいいが。

ていうかよそでやれ

じゃあげるな。

漏れも>>80はやっぱり理解できん。
漏れのたとえ>(>191)に72氏がフォローを入れてくれたにも関わらず、
80氏にはその意図が伝わってないように思える。

端的にね、もしも、
「プログラムの面白さは理屈じゃねーよ！
　プログラムを通して伝えたい内容が感動するのであって、
　それは理屈じゃ絶対に手に入らない物だね！！」
と主張する厨房が一人いたら、
このスレが成り立たなくなる事を示してるような気がするぞ。

「面白さについて考える」というんだから、
何故面白いのかの原理を論理的に解明していくのが筋では無いのかね。

たとえば、「思ったとおりに動けばいい。理屈なんかいらない」
というだけが「プログラムの面白さ」なら、
こんなスレに書き込んで考える必要すら無いと思うぞ。
理屈無しに、バグっても書いて書いて書きまくればいい。

漏れは恋愛を成り立たせるのは心だけじゃないと思うよ。
たとえば恋愛相談をして、異性の考えを理解してる。
それは、本能だけじゃなくて理性で相手を論理的に捉えようとするからだよね。

「●●は心で捉えなければならず、理屈で考えたら馬鹿」
という閉鎖的な考え方を持っている人の性格自体が、
ある要素に対して理屈を求めるのに不適切な気がするよ。

俺も80氏と同じ体験したよ。
80氏と俺とは単純に理論に対する見解の相違なんだな。
俺は>>250にビタっと禿銅で、
創作や演奏に自由が欲しくて理論に行き当たった。
理論意識しない音楽創作も否定はしないよ。それもアリ。
それに80氏と俺が音合わせしても、多分見解の対立は音には出ない。
これまた不思議だよな。

で、本題だが、
プログラムは知識がつくほどに「次の一行」が最適で美しくなると思うが
音楽は理論知識がつくほどに「次の音」の選択肢が増えていく。
（俺好みって意味での最適解はあるんだが）

てな感じだな。

という訳で、俺の中では>>60-69に始まるこの話題、
このスレの範疇では一応の完結をみますた。
あとは180での宿題だけだな。

というかね、実際に仕事していると結構顧客とのギャップに悩むのよ。

顧客が捉える「プログラムの面白さ」ってのは、
頼んだ物が思ったとおりに出来るだとか、
欲しいと要求した製品が仕上がってくる事だけだよね。

けれど、開発者が捉える「プログラムの面白さ」ってのは、
構造の洗練だとか成果物の再利用性だとか、
既存概念の打ち破りみたいな物も含めて、
「言われた物を言われた通りに作る」以外の何らかの価値があると思う。

でも、顧客から見たらYAGNIもいいとこな訳で、
開発者の技術力ってのは、もちろん正しく出来る事を前提としたら、
「早く出来る」「安く出来る」くらいしか評価されるところが無い。

そもそも、漏れ自体の思う「プログラムの面白さ」が、
80氏の言う「モノづくりの面白さ」では無いんだろうね。
ただ作ることでは無くて、良いものを作る事に面白みを感じるよ。

XPも同じで、XPという方法論を学ぶことは面白いけど、
XPを使って仕事する事がさほど面白いとは思えないな。
やる事が分かっちゃってるのでやっつけ仕事になるというか。

あと、>>254で馬鹿って書いたけど、糞の間違いでした。ｽﾏｿ。

>>254

やっぱ書いておこう。
80氏のような音楽理論に対する見解の持ち主が
理論で作曲始めると>>69のような状態になるんだな。
これは80氏に対する個人攻撃ではなくて、理論に対するアプローチの差だから、
80氏個人の音世界では、確かに理論は不要で良いと思う。
その音も知らぬ間に理論に支配されてはいるんだが。
音楽へのアプローチ法は多岐に渡っていても良いだろう。

ただ、>>257の言う細部へのこだわりが出てくると、
感性が音楽の仕様書とすれば、
やはりロジカルな面白さにプログラムとの共通点があるような気がする。

適当に組んで適当に動くプログラムが最高です。

koanみたいな音楽に対する認識を刷新するソフトウェアが書きたいです。
みんなクセナキスコンプレックスでもあるのかな？ｗ

ところで、一流の建築家には教養の高い人が多いけど
プログラマにはそういった人はいないね。電波なら沢山いるけどｗ
やっぱりプログラマってその程度の存在なのかな。

>>261
教養高くなると理論的な美しさと現実の悲惨さのギャップに耐えられなくなるんだよ、きっと。


小さな民間企業でPGやってなくても研究所とかそんなところに行けばゴロゴロしているような気もする。

>>260
「クセナキスコンプレックス」って何ですか？
愚愚ったけど見つかんないです。

プログラムの面白さ、なのかプログラミングの面白さ、なのか、どっちなの？
なんかROMってると、「曲を聴く行為」と「作曲する行為」とごちゃごちゃになってるような気がするんだけど。

>>261
> ところで、一流の建築家には教養の高い人が多いけど
> プログラマにはそういった人はいないね。電波なら沢山いるけどｗ
お前の勘違い。まぁ、君の周りにはそういった人がいなそうなのには同意しよう。
類は友を呼ぶからな。以下の人達ってプログラマだろ？
ドナルド・クヌース、デニス・リッチー、ラリー・ウォール、
リチャード・ストールマン、リーナス・トーバルズ、坂村健、etc

>>265
*一流の*プログラマじゃないことに注意。

>>265
そういう人たちが文化についていくらか喋っているのは
知ってるけどちょっと違う気がするんだよね。政治的な
臭いのする議論を綺麗に避けている。

ttp://ime.nu/mypage.naver.co.jp/2ko657ih/img12356850
これウイルスなんですけど踏んでしまいました
駆除方法教えて下さい
ＰＣにウイルス駆除ソフト入ってないです（´・ω・`）ｼｮﾎﾞｰﾝ

ttp://www.free-av.com/

>>261
建築家の生み出す建造物は工学的観点は勿論のこと、
例えば都市機能や都市空間、美術的価値など多分野から批評を受ける。
建築物自体の歴史も、文明の変遷や同時代の文化と軌を一にして展開してきたから、
一流ともなると自他ともに人文科学を意識せざるを得ない。
時代精神や思想哲学。経済効率や地政学なんかも。

これに対し、単一のプログラムは建物ほど多方面から評価されていない。
文化や文明との接点も端緒についたばかり。
文化の構成要素として批評の対象となるには、4半世紀は必要かも。
世間がPGに高い教養を求めてない。

上記はまだ実験的な試論にて。
ある種問題提起です。

設計に拘るのはＰＧのサガ
テキトーな安くてもろいパーツでつくれるものでも、高級な部品でつくりたいわけさ
コストあげてでも

>>272
だからＰＧはブランド指向が多いんですね？

>>255
とにかく、理論を考えずに潜在意識から出てくるメロディや和音をつらつらと
譜面に書いていく。
後から見ると、Cadence に従っていたり、Dorian の曲だったり、陰旋法だったりと
解釈できる。
メロディ的にも、ここはアプローチ・ノートで、これが骨格の音で、と後付けで
説明できたりする。
誰かの演奏をコピーするときも、とりあえずただ、ぐっと来るからひたすら
手癖になるまで指が動くようにコピーしていたりして、後から見てみると、
Altered だったなあとかなる。
そういうのが、最近、楽しい。

>274
プログラミングする時にクラス設計に悩む。
そしてやっとある設計を捻り出した。

その後。。。。デザインパターン本を見て
｢ああ、○○パターンじゃん！」

プログラミングに置き換えるとこんな感じ？

>>275
そんな感じ。
だけど、プログラミングでそういうことはあまりないな…
最近は、クラス設計に悩むってことはほとんどなくなってきた。

276
そっか、そだよな。
音楽はより自由で、より楽しい曲をゲット（潜在意識？の中から）したいわけで、
プログラミングの場合はより制約を厳しくしたところに当てはめる感じだからね。

>>270
大規模で巨大なプログラムを作るために使われる
オブジェクト指向、パターン、フレームワークは
建築と共通するところがあると思うのだが。

高層ビルを建てるために先に部屋の椅子やテーブルの配置や
レイアウトを決める馬鹿はいないのと同じように
オブジェクト指向では先に設計図を描き土台を決める。

しかしな、マ板やム板を見るとオブジェクト指向を否定している香具師が
多くて、こいつらは先に部屋の椅子の配置などを先に決めてプログラミング
する馬鹿なのかと。

>>278
とりあえず一階だけでも作ってもらって、
中を見せてくれないと実感がわかない。

と言われるのが現実だものね。
で、プロトタイピングの工数が必要になってくる。

モデルルーム見物代を見積もりに含める訳にはいかないので、
プロトタイプの再利用性とかに余計な気を遣ったりする。

というか、
「こんだけ出来てるんだからあと●●すれば使えるでしょ」
という事を要求されてしまうのが実情では。鬱。

家具やなんか並べたモデルルーム見られて、「じゃあ、これでいいよ。後は電気と水道とガスでOKでしょ？」
なんて言われて配管・配線全くしてないようなものか。

>>279-280
XP みたく、イテレーションごとに小さなプロトタイプを見せていけばいいんだね。
XP の小さなリリースはプロトタイプであるけど、イテレーションの要求仕様を
すべて満たしている（受け入れテストを通れば）。

漏れは暫くXP肯定派に対してXPの意義を問いかけていこうと思った。

>>280
イメージとしてはそんな感じ。
「配管？　配管するだけなら簡単じゃないの？」とか平気で言ってくる。

>>281
もっと言えば、「高層ビル建設プロジェクト」で、
一つの部屋の内装を「小さなリリース」した後に、
顧客は「この部屋を3階の東側に配置して欲しい」と言ったりすると思う。

で、YAGNIでは、あとで高層ビルになる事がわかっていても、
第2イテレーションでは3階建ての建物として建設を終えなければならない。

それが終わった後に言われるのは、
「じゃあ6階にして。ただし、今建てた3階は立ち退かないからね」
という事でしょ。

XPのイテレーションは「将来性」を要求仕様に含める事が出来ない。
言い換えれば、顧客にもYAGNIを強要するのでは無いだろうか。


っていうか、脱線してしまった。

>>261が脱線の原因かなｗ

「理論を楽しむ行為は、教養が高いか、教養が高い状態を
　自ら望んでいないと成就しない」
というニュアンスを暗に含んでいるなら、煽りっぽいけど同意。

無知は恥ずべき、だよね。
異性の事とかももっと知った方が面白い恋愛が出来ると思うよ。

真面目にイテレーションしようものなら、
最初からRUPみたいな重苦しい体制敷いとかないと
早々に破錠する。
問題はどのレベルぐらいから、RUPのような方法論で
挑まなければいけないのか、その見極めが難しいこと。

ところで、建築の技術、プロセス技術は部外者にも
はっきりとみえる。だからよそのやり方を叩き台に
することができる。だけどソフトウェアの場合は
そうじゃないよな。密室での開発が前提。これじゃ
進歩の度合いにも限度があるってもんだ。

>>282
> それが終わった後に言われるのは、
> 「じゃあ6階にして。ただし、今建てた3階は立ち退かないからね」
> という事でしょ。

まさにその通り。
建築はハードウェアだから、設計した後に建築しなくちゃならないけど、
ソフトウェアは柔らかいから、そういうことがたやすくできてしまう。

>>284
> 密室での開発が前提。

それを排除したのが、顧客もチームにしたオンサイト顧客。
それから、イテレーションの終わりごとに必ずレビューしているね。
顧客からは、専門的なことはわからなくても、何が行われているのかよく見える。

>>284
> 真面目にイテレーションしようものなら、
> 最初からRUPみたいな重苦しい体制敷いとかないと
> 早々に破錠する。

RUP は重量級だけど、プラクティスはそんなに厳しくないよね。
XP は軽量級で、プラクティスは厳格に守らないとならない。
どういったわけか、XP は自由なハッキングというイメージが一人歩きしているけど、
厳密なルールの下で行われているし、そうしないと破綻するんだね。

RUPを実践、もしくは参考にしてる人っている？
XPと比べて情報量少ないからなのか、
紹介記事とか読んでもどーにもイメージが湧かん。

>>287
少ないといっても、オージス総研監修の RUP 本はたくさん出ていると思うけど。
何冊か買ってみたら。
けど、あれは、RUP 本がフロントエンド（セールス用語で餌のこと）で、セミナーや資格試験、
そしてサポート契約がバックエンド（セールス用語で本命商品のこと）なんだな。

>>288
そっかサンキュ。今度見てみるよ。

でもサポート契約とかも入ってくると提案とかしにくそうだね。
「金払えば・・・」的な考え方にはとことん疑心暗鬼になってるような気もするし。

>>285
> そういうことがたやすくできてしまう。

たやすく？　誰にでも？

>>290
建築士が家の図面を書き直したりするのと同じぐらい。

ギコ猫XP劇場 〜集団的所有権〜
http://objectclub.esm.co.jp/eXtremeProgramming/angya/dorama/syoyu_img.html

>>290
次のような Core Practice を守っていれば。
　　シンプルなデザイン(Simple Design)
　　ペアプログラミング(Pair Programming)
　　テストファースト開発(Test-First Development)
　　設計の改善(Design Improvement)

誰にでもできるかは、まともな技術者かどうかによる。それに、XP は軽量級で、
プラクティスは厳格に守らないとならないから、協調性のないチームにはできない。
現場監督と職人さんたちが強調しないと建物が建たないぐらい同じだ。

>>292
どっかにXPのAAネタやってたスレなかったっけ？

>>294
結城さんとこのサイトでなくて？

>>291
家の図面って、開発における仕様書と同義じゃないの？
XPは野暮ったい仕様書を持たないことは言及してるけど、
ソースを仕様書と同等の負担で書ける事は保証してないと思うけど。

>>293
今のXPって14のプラクティスだっけか。4つ守るだけでいいの？
軽量級というけど、XPの肝って、開発自体の工数を軽減させる事で、
開発のフットワークを向上して、再開発のリスクを軽減するんだよね？

常にデザインをシンプルに保てて設計の改善が出来て、
チームワークにも問題のない開発者ってのは、
「たやすく」はいないと思うんだけどなあ。

少なくとも息抜きに2ch見る人には実践不可能よね。
それともペアの相手が後ろで「さすがだな、兄者」とか言うんだろうか。

XPというのは方法論というより「実力として目指すべき指標」なんだろうか。
PGに対して「あんたもSE職を経験しときなさい」というのに似てる？

方法論と理想論がごっちゃになってる気がする。

>>295
> 今のXPって14のプラクティスだっけか。4つ守るだけでいいの？

は、

>>282
> それが終わった後に言われるのは、
> 「じゃあ6階にして。ただし、今建てた3階は立ち退かないからね」
> という事でしょ。

に必要な Core Practice。
14 って古い情報だね。もっとあるよ。

>>297
いまは http://www.xprogramming.com/Practices/xpractices.htm だけのプラクティスが
あるね。


>>295
当初の 12 のプラクティスで説明すると、それぞれ次の目的のためにある。

顧客の欲しいものを作るためには、次のプラクティス。

Core Practices: チーム全体(Whole Team)

次にすることを決め、プロジェクトがいつ終了するかを予測するためのトラッキングを
する。顧客のビジネスにぴったりとした開発をするためには次のプラクティス。

Core Practices: 計画ゲーム(Planning Game), 小さなリリース(Small Releases), 顧客テスト(Customer Tests)

いつでも現在の要件にぴったり合うように設計を保ち続けるために、次のプラクティス。

Core Practices: シンプルなデザイン(Simple Design), ペアプログラミング(Pair Programming), テストファースト開発(Test-First Development), 設計の改善(Design Improvement)

絶えず統合でき、全員がコードを理解し、いつでも改善できるようにするためには次のプラクティス。

Core Practices: 継続的インテグレーション(Continuous Integration), コードの共同所有(Collective Code Ownership), コーディング標準(Coding Standard)

チームがいつまでも続けられるようにするために、次のプラクティス。

Core Practices: メタファー(Metaphor), 持続可能なペース(Sustainable Pace)

13 でしたね。ははは。

>>295
> 結城さんとこのサイトでなくて？

「ギコ猫とデザインパターン」だよね。

> それともペアの相手が後ろで「さすがだな、兄者」とか言うんだろうか。

「！」と思ってログ検索かけてみたらﾊｹｰﾝ。
ギコ猫のじゃなくて単発だったけど。いずれにせよサンキュ。

こんなはずじゃなかったよな、俺達…
http://pc.2ch.net/test/read.cgi/prog/1028037584/ (DAT落ち）

415 名前：仕様書無しさん 投稿日：02/12/03 19:09
　　どーせアイツラ作っても作っても思いつきで
　　仕様変更しやがるから適当にやっとけ、ってことか

　　　　　∧＿∧
　　　　 （　´_ゝ`） ∧＿∧
　　　　／　　　＼（´<_｀　）　Kentもつらかったんだろうな
　　　 /　　|＼_/|ヽ 　　 ⌒＼
　 ＿_(__ﾆつ　|| ⊂)＿と￣　）
..　　　　　　＼||/ 　　　￣￣

>>297-298
じ、情報ありがと。
プログラミングをシンプルにすればするほど、
開発方法論やプラクティスは肥大化するのね。

言い方悪いかもしんないけど、
ありとあらゆる業務に関するライブラリをすべて用意した開発環境があれば、
業務アプリを書く事自体は物凄く速くて簡単に出来るよね。

けれどその環境で開発する事が、
果たして「面白い」プログラムなのかというと、ちょっと自信無いなあ。

とはいえ、とりあえず最近のXPは勉強しなおしてきます。。。
XP自体が進化を遂げているのは良い事だけど、
XPを段階的に導入するのって難しいよね。

>>300
あ、漏れ、そこまで読んでない。343で止まってる。小さく鬱だ。。。

>>300
> こんなはずじゃなかったよな、俺達…

それだっ！
このネタは秀逸でしたね。

>>301
> ありとあらゆる業務に関するライブラリをすべて用意した開発環境があれば、
> 業務アプリを書く事自体は物凄く速くて簡単に出来るよね。

そういったライブラリが本当にあって、安く手に入れられれば、商売として
やっていけるかもしれないね。まあ、同業者もライブラリを買っちゃうだろうけど。
そういった万能ライブラリは多分ないし、作るのは桁外れにお金と時間とが
必要だろうから、現実的な商売ができる範囲でやるには、顧客の欲しいもの
そのものだけを作るのが、低コストで利益も出るやり方だよ、というのが
XP の考え方です。
XP のやり方は、きわめてビジネスよりの手法でありながら、職人の性質も最大限に
発揮させるようにできているし、これからも改良されていくのでしょう。

ついでに言うと、XP では、すでに作ったコードをライブラリとして再利用するよりも、
小さなイテレーション＋こまめなリリースで、まず一巡の経験をしてしまい、
過去の経験から新しい局面を乗り切るアイディアを再利用する、あの時どうやって
作ったか、手法、ノウハウを再利用することの方を重要視していますね。

>>301
> プログラミングをシンプルにすればするほど、
> 開発方法論やプラクティスは肥大化するのね。

そうかもしれないですね。

>>303-304
こうやって見ると、XPは高レベルな言語と相性が良さそうよね。
低レベルな言語だと、どうしてもコードによる財産がある程度必要だもの。

そして、実力の低いプログラマへの救済策は無いよね。
たとえば新人にXPを教育させる事は極めて難しい。
必要な分だけの開発知識しか付かないから、
言語や環境やシステムという物を見渡すことが難しいんじゃないかな。

となると、「何を使えばどんなことが出来るか」がわからないから、
必然的に概算見積もりは取れないよね。やってみた時間を計るしかない。
うーん。

既に技術力のあるプログラマの目を業務に向けさせるのには良いと思うけど。。。

>>305
困ったらスタンドアップ・ミーティングをしたり、ペアプログラミングをしたり
するから、実力が低い人や新人への知識や知恵の伝達は起こるでしょう。実力の
ある人も、教えることで理解が深まります。

> 必要な分だけの開発知識しか付かないから、
> 言語や環境やシステムという物を見渡すことが難しいんじゃないかな。

XP のチームに入る前に何も知らなくて、XP のチームに加わってからも、開発に
関係のある短期的視野の勉強しかしない技術者だけだったらそうなりますね。

>>306
新人とベテランの開発ペースが違うから、
レベルの差がある人をペアプログラミングさせると、
ベテランの持ち時間が減少してプロジェクトの総時間が上昇する。

「仕事の中で（開発方法論ではなく）プログラミングを覚える」
という工程をXPでは想定していないんだよ。
それでいて、見積もりの取り方にはほぼ即断を要求される。


それと、漏れの古い情報だと、開発スキルの根本的な向上を図る仕組みは
無かったと思うのだけれど、最近はそういうのが追加されてないのかなと。

つまるところ、チーム自体が新しい技術に挑戦するケース
（もっと端的に言えば研究）では、XPは不向きという事かな。


XPは「出来る人の仕組み」を説明しているのかも知れないが、
（出来る人が教えればいいってんじゃなくて、あくまで出来ない人の視点で）
「出来ない人を出来るようにする」為の方法論は用意されてないよね？(Y/n)

通常のOJTよりペアプロの方が技術移転は早いのではないかと
想像していたのだが、現実はどんなもんだろう？

新人への技術移転の遅さをなんとかしたくて、XPに期待して
いたりするんですが・・・

　ミ,,ﾟДﾟ彡かなり速いですよ。

口頭や本を読ませるより
ソースを実際にみながら
話をして、挙動を見せるほうが
学習効果はかなり高いです。

>>307さん
実際は、わかっている人間だけが孤独に
新しい技術に挑戦せざるおえなくて
XPな思考(ﾍﾟｱﾌﾟﾛ除く)は
そういう作業はあまり楽になんないです。

そういえばペアプロの本が出るね。
amazonにデータ出てたのでさっき注文したーよ。

ペアプログラミング―エンジニアとしての指南書
ローリー・ウィリアムズ (著), ロバート・ケスラー (著), テクノロジックアート (翻訳)
価格:3000円
出版社: ピアソンエデュケーション
ISBN: 4894716992

XPの意義は腐れウォーターフォール命のクソ上司をぶっとばした事

>>309後半
了解。ありがと。
XPがあれば何でもうまくいく的な風潮があるから、
どこで従来の方法を適用するかの線引きを具体的にやっていかんとね。

>>308-309
技術の継承が速いとしても、
それと同時にプロジェクトのベロシティは落ちるよね。

となると、顧客と開発に効果を生むXPというのは、
開発の基礎を把握している人達だけで構成されるチームが、
XPを完全に学習した上で臨まないといけないって事よね。

チームはまあいいとして、顧客にXPを学習させるのって大変そう。

>>311
禿同。

>>312
理解のある顧客だけ相手にすればいい。

顧客の認識が高いとイイなぁ。

>>313
それって営業もプログラマーがやれってこと？

>>315
大体、ソフトウェア開発の受注市場は成熟期になっているのに、こちらから売り込み
をかけるというような成長期のアプローチで営業しているからだめなんだよ。
わがままな顧客は取らない。お客様は神様だと思っている顧客は取らない。
そういうのは質の悪い顧客。
一度、顧客のわがままを聞いてへーこらやると、顧客はそれが当然だと
思い込み、どんな無茶な要求でも当然とばかりにしてくるようになる。
いちいち答えていると、こちらの会社は火の車になる。
そんな顧客はライバル会社と取引してもらえばいい。

>>316
引手数多な会社が正直うらまやすぃ。

>>317
違うよ。こちらから売り込むと漬け込まれるの。
こちらから取引相手を除外していくと、真剣にビジネスを考えている優良な顧客は
ぜひ仕事をやってもらいたい、チャンスを逃したくないと向こうの方から寄ってくるの。
除外する姿勢を見せれば見せるほど。
単に、セールスの技術論。

>>316
マジすか？願望すか？

こちらから売り込む: 顧客 = （こちらに対して）取引してやってるんだ。なんでもしろ。
こちらは不適切な顧客を除外する: マジな顧客 = （こちらに対して）ビジネス・パートナーとして対等な相手。

>>319
本当。
こちらから売り込むと、冷やかしでも雑魚でも、質の悪い顧客でもなんでもかんでも
取引してしまう。
相手が、こちらのビジネス・パートナーとしてふさわしい相手であるかどうか、
優良な見込み客であるかどうかを、いくつもの質問で洗い出して除外していく。
無理に話をあわせて契約を取ったりしない。残った相手とだけ顧客として取引する。
これは固定客にまで育つ優良な新規顧客となる。しかも、無理に相手に合わせないから
こちらのコストは低い。無理に相手を自分に合わせようとしないから、顧客の
満足も高い。

さらに、無理に相手を自分に合わせようとしないから、「やっぱり解約」がまず起こらない。

>>321
そそ。いい集客なんてきわめてメカニカルにこなしていけばいいだけ。
そこをなんでもかんでも契約を取っちゃうから資金繰りに困ったりする。
成長期の営業マンは成熟期の営業の仕方を習っていないからね。
根性で契約を取れ！　とにかく広い範囲を歩き回れ！　と精神論になっちゃう。
それじゃあ、コストはかかるし、時間も損するし、営業マンはうつ病になる。
まあ、成長期は顧客がそこにいたから、そんなんでもなんとかなった。
いまは、顧客から食いついて来たくなる営業をしないとだめなのに。市場の
成熟ぐあいによって違うんだよ。

　　　 ！　　　　　　＿＿＿＿＿＿＿＿＿＿＿＿＿
　　 ∧,,∧　　　 ／をぉ。
　　ミ,,ﾟДﾟ彡　＜　うちはダメ客を押し付けられた側です
　　ミ.,,Ｏ),,ﾐ 　　＼
　＠ﾐ　 　ﾐ 　　　　 ￣￣￣￣￣￣￣￣￣￣￣￣￣
　　 ∪''∪　ﾋﾞｼﾞﾈｽの基本は営業やね

全く金にならないのに仕事ばかり発生して
よくまあ投資するなー。って日々驚きます。
いわれたことは
仕事だから、働くけど、僕の働いた分は
どこの利益になっているのかしら？

ほんと。その客はライバル会社に
押し付けた方がビジネスに勝利できるのじゃないか？
と俺みたいな一兵卒に思われる程
ひどいありさまです。

金ももらえないのに、客先常駐SEを配置して
これまた、そのSEが客の利益しか考えないし。

年間何億かの赤なんだろうか･･･

>>323
>顧客から食いついて来たくなる営業

どんな営業！？俺はＰＧだからあんま関係ないけど、気になる

「営業が積極的で無くても何とかなる」って条件を、
満たす事の出来る企業が少ないってこったね。

>>316の言葉を借りて言うなら、
開発方法論は成熟期に入っているのに、
企業間の開発契約が未成熟のままなんだと思う。

でも、残念ながら大抵の会社は客を選べる状況では無いと思うよ。
そして、大抵の個人は、客を選ぶ余裕のある会社に転職出来ないのでは。

それを踏まえて助言戴けるなら、神と呼ばせて戴きます。

　 ∧,,∧　　梨さんとこは苦労が多いんですか？
　ミ,,ﾟДﾟ彡　
　ミつ日(ﾐ　
>てこったね
てこったと、言えるほどの
話題は出ていないかと。

>でも、残念ながら大抵の会社は客を選べる状況では無いと思うよ。
そうかしら？

>そして、大抵の個人は、客を選ぶ余裕のある会社に転職出来ないのでは。
まだまだ売り手市場じゃないかな。
ASP開発者がいないって、
学生時代の友人SEが嘆いてたよ。

こういう時は2chのもどかしさを感じるなあ。

> それを踏まえて助言戴けるなら、神と呼ばせて戴きます。

こんな事言ったって、助言の内容は、
「開発者が糞。レベルが低いから転職できないんだ」
と煽られて終わりな気がした。

まあ、営業がむやみに頭下げずにいい条件で仕事を取るべきってのは、
「営業のレベルが低いから糞」と言い換えれるしいいんだけど、
あくまで会社規模でこの現象を見たときに、体制転換はどこでするのかと。

「だめな奴はなにをやってもだめ」という結論以外を求めるのが甘いのかねぇ。

　ミ,,ﾟДﾟ彡　誰かに翻訳してもらいたい紀文

>>329
>>328は「まともな返答を期待してすいませんでした」って意訳で。

漏れが開発方法論に求めるのは「現状打破」であって「理想」では無い。
とりあえず、スレ違い甚だしいので、XPの話はもうやめます。

ペアプロで新人がいるから遅いと言うなら、XP じゃなくても
新人がいれば遅くなりますよ。
XP をすると新人がベテラン並に速く開発できるようになるわけじゃない。
ペアプロじゃないところで教えるか、ペアプロで教えるか、
どっちが早いか、エンジニアリングなら測定しないと。

>>330
> 漏れが開発方法論に求めるのは「現状打破」であって「理想」では無い。
ならば、「上流」（仕事の取り方）を変えるべきだな。
上流が腐っているのに下流を清くしようとしても無駄。
XPは「下流」（仕事のやり方）に過ぎず、仕事の取り方は書いてない。

普通に真面目に仕事してるとご指名がかからないか？
「現状打破」をする為には取りあえず自分の力を見せ、顧客に信頼されなければならない。
そこでXPを漸進的に導入していく。今のところ、俺は「XPもどき」は実践できている。

>>332
生じか、まじめにいい仕事をしていると、それに甘えて営業努力をしなくなる。
-> 不況になると成約しない。
いい仕事をするのはあたりまえ。どこもいい仕事をしていると言っている。
客がいかにあなたのところと契約したくなるかが問題。

>>333
> それに甘えて営業努力をしなくなる。
それは君のとこの営業がヘボなだけだろ？
> 客がいかにあなたのところと契約したくなるかが問題。
それが「指名がかかる」ことだと思っているのですが何か？

>>334
指名がかかるのは既存客。
見込み客を集められないと会社は伸びないんだ。

微妙なとこで煽りスレにならずおもしろい展開だと。




思ってるロマーが一人ここにいるわけだが。

（＾＾）

　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）

すまん。
確認したが、和声進行はやはり誤用であった。
誤用を真に受けた俺もかなり恥ずかしいな。
さんざん抵抗してすまんかった。
ついでにご教示有難う。
何でもブランク長いとダメだね。ｶｺﾜﾙｲな。吊ってくるわ。

━―━―━―━―━―━―━―━―━[JR山崎駅（＾＾）]━―━―━―━―━―━―━―━―━―

あげてみる

で？

　　　 　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）