  |
はてなキーワード: コンポジションとは
ある音楽家が、これまでのリリース作品がすべてAIベースの制作環境で作られていたことを、その環境を商品として販売開始することで明かした。
この記事は、それを告発するものではない。むしろ、その製品が宣伝通り機能した場合にこそ私たちが直面する問い——「感動していた曲は、何によって作られていたのか」「作曲がプロンプト設計に移るとき、聴き手は何を聴いているのか」——について、ひとりの聴き手/作り手として考えたことを書いておく。
1～4節はその商品の分析がメインなので、ゴシップ的な話に興味のない人は5～7節だけ読めば十分。
Twitterで、気にかけていたアカウントがあった。フォロワーは二千人規模だが、Hyperpop以降の日本のシーンで頭角を現している一人、という認識が自分の中にあった。界隈の主要な音楽家たちからもフォローされている、といえば規模感が伝わるだろうか。リリースされる曲には、たんに「いい音楽」と片付けるのは難しい構成の巧妙さと音選びの新しさがあって、追ってはいないまでも名前は頭にあった。
そのアカウントが最近、自分の制作環境を商品として販売し始めた。価格は14,900円、「AI音楽制作環境」として売り出されていて、製品ページの宣伝文句はこうなっている——「『気持ちよくて驚きのある曲を作って』——そのくらいの指示から、コード進行・歌詞・Sunoプロンプトまで一貫して出力します。」さらに、既発のアルバムとEPは「全てこれを軸に制作されている」とも明記されていた。
最初に湧いた感情は、「ああ、そういう工程で作られていたのか」という、ある種の冷めの感情だった。AIを使っていることそのものへの反発ではない。SunoのようなAI音楽生成ツールの進化については以前から耳にしていた。出力自体のクオリティを否定するつもりもない。そうではなく、「何に対して感心していたのか」という、自分の受け取り方の根元が揺らぐ感覚、とでも言えばいいだろうか。
この感覚を、個人的ながっかりエピソードとして飲み込んで済ませてもよかった。けれど製品ページを読み進めるうちに、これは自分一人の話ではなく、いま音楽を聴く/作る側に共通してくる問題になっていくだろうと思い直した。以下はその整理になる。
製品ページから読み取れる範囲で、何が売られているのかをまず整理しておく。評価は後回しにする。
製品としての訴求は、おおむね三層からなる——(a)独自の音楽生成エンジンであること、(b)感覚的な指示から完成物が自動生成されること、(c)学習ツールとしても機能すること。
実際に買って触ったわけではないので、以下は推測の域を出ない。ただ、製品説明を読み解くと、構造的にいくつかの疑問が浮かぶ。
まず、''「Python疑似コード」という語の含意''について。「疑似コード」はPythonの形で書かれていても実行されないテキスト、つまり構造化されたプロンプト/参照資料のことを指すのが通例だ。Claudeプロジェクトに.zipをアップロードする形式である以上、これはClaudeが読み込むルール文書群であって、独立して走る独自エンジンではない可能性が高い。MIDI出力部分などは実行可能コードだろうが、「コードを選ぶ」「歌詞を書く」といった音楽的判断のコアは、Claude本体の自然言語推論能力が上限になる。これ自体は悪いことではない。よく練られたプロンプトパックは、Claudeの出力の一貫性と専門性を上げる。ただし「独自エンジン」という響きが含意するものとはかなりの距離がある。
次に、''Sunoへの依存度''について。製品の主要アウトプットのひとつが「Sunoプロンプト」である以上、最終的に音として鳴る部分——音色の質感、ミックスのバランス、演奏のニュアンス——を生成しているのは、この製品ではなくSunoのほうということになる。つまり、この製品の価値の相当部分は「Sunoを上手く使うためのプロンプト設計の職人技をパッケージしたもの」であって、Sunoが進化すればその層の価値は急速に目減りする。
三つ目に、''「all built by hand」の含意''について。86,000行という規模が、本当に人間が手で書いたものなのかは、製品説明からは判別できない。ジャンル研究ノートやStyle語彙データベースといった文書は、AIに「このジャンルについて詳細なルール文書を書いて」と指示すれば相当量が出てくる種類のものである。骨格は人間が作っていたとしても、肉付けをAIに任せている可能性は十分ある(そしてその場合、「手作業で書いた」という説明の重みはかなり変わってくる)。
繰り返すが、これらは推測にすぎない。実際に買って開ければ印象が変わる可能性は十分ある。ただ製品ページの記述だけを根拠に判断する限り、「独自の音楽生成エンジン」「作編曲の学習ツール」という訴求は、実態を控えめに言っても過剰包装しているように見える。
この製品に対する考えられる反応は、「宣伝通りに動くのか？」という疑問だろう。
しかし、立ち止まって考えると、本当に問うべきは逆側であることがわかる。
仮にこの製品が宣伝通りに機能するなら——「気持ちよくて驚きのある曲を作って」という指示一行から、コード進行・歌詞・Sunoプロンプト・MIDI・MP3まで一貫して出力されるなら——自分が感心していた曲は、その程度の指示から出てきたものだった、ということになる。下準備としての疑似コード整備や、出力に対する微調整は当然あるにしても、一曲一曲の制作工程の中心がそこにあったのなら、感心の源は作り手の耳ではなく、ツールの出力分布の中にあったことになる。たしかに創作物は優れていたかもしれないが、「それが優れていたのは上手くSunoを使いこなしていたから」という、エンジニアリングの問題だったということになる。
機能しないなら誇大広告の問題で済む。機能するならば、「聴き手は何を聴いていたのか」という、より根本的な問いが立ち上がる。皮肉なことに、製品としての完成度が高いほど、この問いは重くなる。
ここで思い出しておきたい話がある。2023年のゲンロンのイベントで、音楽家のtofubeatsが、Spotifyのサジェストで流れてきた曲に心を動かされ、作曲者を調べたらAI生成曲だと知って深いショックを受けた、という経験を語っていた。彼自身がオートチューンで声を加工し、歌声から人間性を排して作曲するタイプの作家でありながら、である。「非人間的な曲が、本当に人間によって作られていないこと」が判明したときの空虚さを、彼は正直に語っていた。
この空虚さが何から来るものなのかは、6節でもう少し踏み込んで考えてみたい。ただ先に言っておくと、それは「AIは音楽を作ってはいけない」という種類の話ではない。むしろ、「聴くとき、自分は何と対面していたつもりだったのか」という自己認識の問題になる。そしてそれは、作り手が工程を開示しないまま商品を売り始めた瞬間、聴き手の側で解決することが不可能になる種類の問いでもある。
誤解されたくないので、はっきり書いておく。この文章は、AIで音楽を作ることへの全面的な否定ではない。
作曲の歴史は、すべてを人間が設計し人間が作る歴史だけではなかった。偶然性、システム、自動化、外部の力を取り込む試みは、ジョン・ケージから、ブライアン・イーノ、アルゴリズミック・コンポジションまで、20世紀以降の音楽史の重要な部分を形作ってきた。AIの導入はその系譜の延長にあって、それ自体を否定するのは筋が悪い。
近年の例で言えば、菊地成孔は自身が主宰するギルド「新音楽制作工房」でAIを活用していることを早くから公言している。NHKドラマ『岸辺露伴は動かない』の劇伴ではMaxを用いたAI生成による弦楽四重奏が使われており、菊地本人が「作曲者のクレジットもないし、著作権のありかがわからない」という問題をNHK出版経由でJASRACと協議し、「新音楽制作工房」名義のクレジットで処理することで決着させた、という経緯まで公にしている。つまり、どう使い、どう扱い、誰の名のもとに出すかを、彼は工程ごと開示している。
ここでの違いは、「AIを使うか使わないか」ではなく、「どう使い、どう開示し、何を自分の名のもとに出すか」にある。「AIの使用は隠していない」という表明と、「どの工程をAIに委ねたかを開示する」こととの間には、大きな距離がある。
そしてもうひとつ、避けて通れない論点がある。Sunoを含む音楽生成AIが、何を学習データにしているかという問題だ。2024年6月、RIAA（全米レコード協会）はSony Music・Universal・Warner Musicを代表してSunoとUdioを著作権侵害で提訴した。Suno側は、レコード会社の著作権で保護された録音物を使用したことを概ね認めた上で、フェアユースを主張している。2025年末にはWarner MusicとSunoがライセンス提携で和解したが、訴訟全体はまだ決着していない。
つまり、いまSunoで曲を作って発表することは、その学習データが何で、どのような経緯で集められたかが法的に争われている状態のモデルを使うことを意味する。これは「使ってはいけない」と言いたいのではなく、「自分の作品がどういう供給ラインの上に立っているか」を無自覚なままにはできない、ということだ。そして、そのモデルを使って生成した曲で「作曲者」を名乗り、その制作環境を商品化して収益化する、という連鎖の倫理性は、まだ業界全体として合意が取れていない。
この記事の射程は、その倫理そのものを裁くところまでは届かない。ただ、「いい曲さえできれば制作過程はなんでもいい」という論法に、即座に頷くことはできない、という姿勢だけは明示しておきたい。
ここで、4節の末尾で保留にした問い——tofubeatsが味わった空虚さは何から来るのか——に戻ってくる。
創作物を聴く側は、作り手の工程をつねに見ているわけではない。それでも、作品を受け取るときには「制作への真摯さと、出来上がった作品のクオリティは、どこかで結びついている」という、いわば感覚的な信頼をもって聴いている。これは創作と鑑賞の間に長く存在してきた暗黙の契約のようなもので、あるシンガーソングライターが書いていた通り、手間暇掛けようが掛けまいが最後には一緒くたに扱われる時代でも、違いの分かる人はいるはずだと信じて丁寧に拵える——という姿勢を、作り手と受け手の双方が（明示的ではないにせよ）共有してきたから、音楽は単なる音の配列ではなく、作り手の痕跡を伴うものとして聴かれてきた。
AIが生成した音楽そのものにも、それ独自の良さがある。これは繰り返し強調しておく。作品としての良さは、工程とは独立に成立し得る。ただし、AI生成された曲を「ひとりの作家が作った作品」として提示し、その仮構された人格のもとに人気を集めることは、この暗黙の契約を根元から破壊する。聴き手が「これを作った人は、たぶんこういう感受性の持ち主なのだろう」と想像しながら聴いていた対象が、実は大部分がプロンプトから生成された出力だったとしたら、その想像は宙に浮いてしまう。作品が悪かったわけではない。悪かったのは、作品と作り手の人格の間にあったはずの関係について、聴き手が抱いていた前提が、工程を開示されないまま利用されていたことにある。
tofubeatsが味わった空虚さは、たぶんこれに近い。「AIが作ったから価値がない」ではなく、「自分は作品を通して誰かの感受性と向き合っていたつもりだったが、その『誰か』が自分が想像していたものとは違っていた」という、受け手側の文脈の宙吊り。この宙吊りは、作り手の側がAIの使用を大まかに表明するだけでは解消されない。「何を自分の判断で選び、何をツールに委ねたか」という工程の粒度での開示があってはじめて、聴き手は自分の感心の行き先を再設定できる。
この視点から見ると、今回の製品販売で起きたことの構造が少しはっきりする。14,900円という価格や、買った人にとっての有用性の問題はもちろんある。ただ、それ以上に大きかったのは、制作環境を商品化するという行為が、既発の作品群を「この環境の実例」として遡行的に位置づけ直してしまうことにある。以前から作品を聴いていた側から見れば、聴き手と作り手の間に結んでいたはずの暗黙の契約の内実が、後出しで書き換えられる感覚がある。
制作工程の開示は、法的義務ではない。ただ、制作環境を商品として売り始めた瞬間、この暗黙の契約を自分から前景化させたことになる。「この環境でこれだけの作品が作れる」という実例として既発のリリースが参照されているのなら、それぞれの作品がどの程度この環境の出力そのものなのか、どの程度は人間の介入によるものなのかは、買う人にとっても、これから聴く人にとっても、重要な情報になる。
最後に、聴き手として、作り手として、これからどうするかを書いておきたい。
聴き手としては、tofubeatsが味わった種類の空虚さを、できれば避けたいと思うひとが大半だろう。しかしtofubeatsがAI生成だと気づくことができたのはクレジットにそう明記されていたからに他ならない。今回の私のケースのように、AI生成であることが明かされていなかったり、将来的に（遡及的に）AI生成であることが明かされるようなパターンはますます増えていくだろう。私たちは、匿名性を保ったままクオリティで勝負して有名になっていくという同人音楽シーンの時代の終焉を目の当たりにしているのかもしれない。作り手と受け取り手の信頼関係が壊れていくなかで、聴き手側からできることはあまりにも少ない。界隈で有名なコンポーザーの多くも今回のアカウントをフォローしていたことも考えれば、制作過程の情報開示を積極的に求めていくこと、プロセスを明らかにしたうえでよいものを作っているひとを評価していくこと等も、その限界は大きいだろう。
作り手としては、自分がやりたいのは、プロンプト一行から出てくるものを受け取る側ではなく、一音ずつ選ぶ側である、とあらためて確認した。それはAIを使わないという意味ではなく、AIを使うにしても、どこで自分の判断を通すかを意識的に設計したい、ということになる。菊地成孔のやり方に近いと言えば近い。作編曲に限らず、これまであらゆるアートと呼ばれる領域について、過程を見せないことは作家の神秘性を増すための重要な要素だった。しかし上にも書いたように、その限界はもうすでに見えてきているように思う。過程を明らかにしたうえで、自身の武器がすべて明らかであるのにそれでも真似できない創造性を見せること。もちろん、あらゆる出力結果は機械学習の餌食になりうるという状況においてこれは綺麗事かもしれないが、成果物がいわゆるAIに食われうるのは変わらないのだとしたら、いかに自身の制作においては透明性を保ったうえでクオリティで受け手を納得させるか、こそが大事になってくるだろう。こうしたムードを作り手の側からも作っていくことが、今後の大きな課題になるのではないかと思う。
「AIがもっといいものを作れるのになぜあなたが作る必要があるのか？」は、「プロの作家がすでにこの世に五万と存在するのに、なぜあなたは作品をつくろうと、その道を志したのか？」という問いと本質的には何も変わらない。作りたいから、作る。伝えたいから、それを形にする。そうした初期衝動が、欲望が、「創造性」という言葉の本質であり、AIに模倣することのできない、あなただけの、私だけの創作物につながるのだから。
映画におけるミザンセーヌの主な構成要素（よく挙げられる6つ）セット（背景・環境・場所）
照明（光の当て方、影の作り方）
コンポジション（画面内の配置・構図・ブロッキング＝俳優の立ち位置や動き）
これらを監督が意図的に組み合わせることで、セリフを言わなくてもキャラクターの心情・社会的地位・物語のテーマ・雰囲気を視覚的に伝えるのがミザンセーヌの醍醐味です。
例で言うと古くてボロボロの部屋 → 登場人物の荒んだ生活や精神状態を表現
ウェス・アンダーソン監督の作品（『グランド・ブダペスト・ホテル』など） → 対称的な構図、鮮やかな色使い、パステル調の衣装・セットで独特の世界観を一瞬で伝える
暗い照明＋狭い部屋 → 閉塞感・孤独・緊張感を強調
module_name.pyみたいなモジュールごとにファイル分割して、インターフェイスだけ公開してその他はdef _funcみたいにprotected(or private)にしとく。
でも「共通性がありそうだから共通関数にする」はアンチパターンだな。たまたま共通してただけの場合は分岐コードが増えて共通関数の保守コストが上がる。
あとありがちなのは、php開発者が関数分割しないですべてメインコードにべた書きするケース。こういうのはやめないと保守が大変。
とっておきのクズがやりがちなのは、神オブジェクトを作るとかだな。Userクラスのフィールドに関係する機能が多いからといって、コンポジションなどによるクラス分割をせずにユーザークラスにあらゆるフィールドとメソッドを追加して、さらに進むとユーザーとは無関係な機能も含めすべてをユーザークラスに定義するアフォ。こうなってしまったら、後から修正するのが難しくなる。
先に手を打つことが、プログラマーの素質「怠惰」につながるのであり、面倒臭いといって後回しにするのは美徳でもなんでもない。
ボクサーを撲殺したのは僕さ
これから満で数つけるわ
ナンを何枚も食べるのなんて、なんでもないよ
新患の新幹線に関する新刊に新館を立てて震撼し信管が作動する。
ケニアに行ったら生贄や
柑橘類の香りに歓喜し、換気を喚起したが乾季が訪れたので、寒気がした。
塗装を落とそうか。
観光客がフイルムに感光させた写真を刊行することが慣行になった。
サボってサボタージュ
景気が良くなりケーキを食べる契機を伺う徳川慶喜（とくがわけいき）
夫を成敗するオットセイ
つまらない妻の話
竹の丈は高ぇなー
餅を用いて持ち上げる
ロストしたローストビーフ
サボテンの植え替えサボってんな
過度な稼働は可動範囲を狭める
伯爵が博士の拍手に拍車をかけて迫真の爆死をし白寿の白人を白紙にもどす。
紅葉を見て高揚する
甲子園で講師をする公私混同した孔子の実力行使には格子窓も耐えられない。
死んでんのか？「心電図を取ってみよう！」
夜祭で野菜を食べる。
信玄餅を食べながら震源を特定するように進言する新元素を発見した人。
蜂の巣（honeycomb）を見てはにかむ
五反田で地団駄を踏む
ようやく要約が終わった
海溝で邂逅
豪華な業
甲板で甲板をかじる
甲板で乾パンをかじる
店頭で転倒
大枚をはたいてタイ米を買う
醤油をかける人「えっっ？」
神田でした噛んだ
少食な小職
牛の胆嚢の味を堪能する
あの娘にはどう告っても（どうこくっても）慟哭する結果に終わるだろう。
キーンという高音の起因が掴めない。
こんな誤謬は秒でわかるだろ
壊疽した箇所が治るというのは絵空事だ
経口補酔液
痴的好奇心
セントーサ島に行くのは正恩が先頭さ
軽微な警備
冬眠する島民
ベットは別途用意してください
The deserted desert in desert desert.
九尾のキュービズム
罹災者へのリサイタル
画家の画架
不納が富農になるのは不能だ
理工がRICOHに利口な履行
I sensed tha it is in a sense sense.
私はそれをある面では扇子だと感じた。
鯖を食べている人と、それを見ている人の会話
鯖 ça va？
ça va 鯖
ça va
ゆめゆめゆめをみるわけにはいけない
早漏で候
凪に難儀
東上線に搭乗した東條が登場
高校を後攻で煌々と口腔で孝行
蝉が転んでセミコロン
道徳をどう説く
写真はフォトんど撮りません
ダリ「絵ぇかくのだりぃなあ」
華美な花瓶のカビに過敏に反応
檻に入っておりいった話をする
夏のおサマー
夜は寝ナイト
渦中のカチューム
渦中のカチューシャ
リスボンでリスがborn
どうないはどないなってんねん
苫小牧でてんてこ舞い
市内を復旧しないと
石狩の石を借りる
おが置いてあるのを見た人「おはおっかねぇーから置かねぇ方がいいぞ」
砂がどしゃーw
東上線に登場した東條が登場
飽きない商い
おなか吹田市
観劇で感激する
側転に挑戦し即、転倒
別件を瞥見
凹地のお家
魚を初めてみた人「うぉー」
カラヤンの頭の空やーんw
豚をぶった仏陀
只見線をタダ見w
菊名でそんなこと聞くなよ
五秒で死んで御廟に埋葬
がらんとした伽藍
有給を使いすぎて悠久の時が流れた
長谷に想いを馳せる
Thinkerの真価
不具の河豚
暗記のanxious
半世紀にわたる半生での藩政を反省
タンチョウが単調増加
ショック死内親王w
カルカッタの石軽かった
天皇のこと知ってんのー
蒋介石を紹介した商会を照会した商會の船で哨戒する
其方のソナタ
先王に洗脳される
防潮堤で膨張した傍聴人
砂漠で鯖食う鯖を裁く
筒に入った膵島
サイコロを使った心理テスト(psychological test)
カラシニコフが辛子個踏んだ
皇帝の高弟が公邸の校庭の高低差を肯定する工程に拘泥した記録を校訂
にようかで酔うか？
うるさい人が売るサイ
どんなもんだい、を、どんなムンバイ、と言い間違える人
透徹した饕餮の眼球
チャカで茶菓を破壊
slimyなすり身
ゆうほど広くない遊歩道
いにしえのイニシエーション
コーランをご高覧ください
K殻の傾角を測定する計画
協賛した共産党員に強酸をかける
負けたのは聖者の静寂のせいじゃ
裏地見るウラジミール
カミオカンデの上に紙置かんでw
県大会がおわり倦怠感を感じる
夕暮れのユーグレナ
ストライキをする公務員に呼びかける人「 Stay calm（公務）」
エド・はるみの穢
祭壇を裁断
腐卵ダースの犬
全然人が集まらないクラブの人「参加数人は我々の十八番ですから。だけに。」
四苦fuck
都バスが人を跳ね飛ばす
怒るカロテン「なにカロテンねん」
嫌がる慰安婦「いやんっ」
かえるがえる帰る蛙
沈厳な青梗菜
トリコロールの虜
布陣を組む夫人
栗けっとばすクリケット🦗
婉容と遠洋漁業
アマルガムで余るガム
ハラスメントの疑いを晴らす
滋賀を書けない人を歯牙にも掛けない
他意はないタイ人の鯛の態度
鯛が蛇足
ダジャレではない↑
割と面白い
ハラッパーの原っぱ
紫に関して思案を巡らす
Huluが夏の風物詩だと思っている人「Huluですなぁ」（風流）
下調べのムニエル
わからないので
意味ない諱
よく分からんリポーター「うわぁ〜美味しそうですね！少なくとも不味そうには全く見えません！」
どうしても下がりたくない人「黄色い線の内側は、境界を含みますか？？」
計算ができない人
着ていく服を決めた高橋是清「これ着よ」
enough、enoughは工夫がenough
負け負け山（カチカチ山）
薬師丸せま子
トーマス・マンの書いたふるさと「うさぎ〜おーいし、魔の山〜♫」
その心は
焼結が猖獗を極める
これはstaleだから捨てるか
衒学的な弦楽を減額
完全な勧善懲悪
イボ人の疣痔
イブに慰撫
（訳 ぬるぬるしてるありふれた魚）
盲いるのに飯いるの？
アーヘンで阿片を吸った人「あー変」
毒吐く独白
明借りるアスカリ（車）
丁寧な砂浜「Could you九里浜」
ゴーンと奉公
その心は
サンクチュアリに山窟あり
熟れたウレタンは売れたんか？
清澄な声調を静聴し成長
プエルトリコで増える虜
象さんを増産
兄弟が今die
Dose heで始まる疑問文に答える京都人、Yea, he どす
ソフィカルのソロカル
美人局に筒持たせる
十把一絡あげ
篤信な特進が涜神を得心
これは何という植物かな？ムユウジュでは？あそっか、なるほど。
クートゥを食うとぅいいよ
マイソールで昧爽に埋葬
ドクサは毒さ
暗殺で朝死んだ
クラシックについて語る人をそしる人「弦楽なんてペダンチックだなあ」
凛々しいリリシズム
衛生的な俳人
御髪も亂とはオクシモロンだ
コロナ後の世界を分析する学問→postcoronialism
影響が色濃いイロコイ諸族
あてのあてないアテナイ
わからない。
[追記]
ちょっとわかってきた気がする。
NexusにしろPixelにしろパートナーコーポレーションが持つテクノロジーとのフュージョンによってプロダクションされてる。
ベースレイヤーのコンポジションをオウンドブランドとするビジョンはそもそもインテンドされてないように見える。
故にGoogleがこの先生き残るにはソリッドステートデバイスをプロダクションできるインダストリーコーポレートがマストなニーズであるとともに
失敗したり成果の上げられないプロダクトはカンパニーごとパージして他の企業と乗り換えればいいので投資に関するリスクは結構他所に丸投げしている。
http://anond.hatelabo.jp/20130325172822 の続き
言語はJava7を想定。(Java8が迫っていますが、Lambdaなど関数型は、まだ早いと言うことで)
選定理由は、C++と比較して学べるところが大きく、安全でシンプルな言語だから。
※いきなりJavascriptはやめとけ、PHPは論外。
Ruby・Scalaでないのは、筆者が初心者には適切には教えられないから。
おもちゃ・ToyとしてjQueryで遊ぶのは、悪くは無いと思う。
これ以降は名著の紹介や学習方法の紹介が主体となります。名著のコンポジションという形が時間的限界ですね。
量については「初級になるなら、専門書を計3,000ページは修得することは覚悟してね」なんて言ったりしています。
Javaで初級のわかりやすい指標ですと、[amazon:Effective Java]とGoFまでの修得。
初級になるまでに登竜門への挑戦期間を含めて、３~４年はかかっても仕方が無いとも思います。
※逆に「一山いくらのコーダー」というのは、Effctive JavaやGoFが達成している技術も知らずに「自分がJavaプログラマー」だと誤解してしまっているような人達です。
そういったコーダーは何年経とうとも初級プログラマーにすら敵いません。
初級を目指して、プログラミングを楽しんでください。
ただ、学ぶべきことはべらぼうですが、「各分野毎に、エレガントな方法がある。だから探して修得する」ということが大切です。
※「一を聞いて十を知る」ような優秀な人に、50冊くらいドーンと本を置いてあげて、各本の目次を読ませるだけで、
底の見え無さを悟ってくれたりすると、嬉しくなってしまいます。
※余談ですが、その底の見え無さは数学という学問そのものですね。例えば、関数型言語の底流に「圏論」というここ100年の最新の数学があります。
また中級くらいで、Liskovの置換原則などが載っている本を紹介しますが、
そのLiskovの置換原則の周辺で出てくるcovariant(共変)って、圏論という数学の概念だったりします。
数学畑出身としては、数学が現実に活かされている嬉しい事例です。
「速く正確に大量の出力」という能力は、プログラミングをする上でも、ドキュメントを書く上でも、何より「つまらん仕事」の時間圧縮ができるようになるため、重要です。
スローガンとしては「思考のスピードで出力することを目指そう」です。
紹介するエディターはemacsやvimやExcelです。ついでにIMEとしてATOKを使用しているため、ATOKの操作をEmacsライクにする話も紹介します。
ExcelはWindows環境でMeadowすら入れさせてくれない場合の最後の砦という扱いです。
コマンドラインは、「コマンドラインというものがある」「時として非常に強力である」程度の紹介です。
※筆者はzshは全然使えません。使いこなしている方々と接する度に「勉強しなきゃな~、でも、あっちの方を先にやりたい・・・」とグズグズして、はや何年・・・
正規表現は置換を用いて、テキストの一括編集が重要です。後、遭遇したくない事態ですが、スパゲッティコードの解析をする上での最後の砦です。
※遭遇したくない例
ん?何か変なところで副作用のある処理があるようだなぁ(消沈)、SQLのInsertかUpdateか一応Mergeも使っているところから逆算して原因箇所を探すか・・・(諦念)
この糞コードがっ!!こんなところに書くんじゃねぇ!!(憤怒激高)
(ここで、他にやらかしていそうな似たようなコードを正規表現でgrep検索。改行コード込みにすれば複数文検索も可能)
わはは、予想通り共通化すべきロジックのメソッドがそこら中にある・・・
入門編で一つLinkedListというアルゴリズムを学びました。
少なくとも一つ本を読みながら自力でアルゴリズムを学べる人なら、大成できる可能性があります。
前に紹介した[amazon:C++実践プログラミング]には、LikedListやStackなど基本的なアルゴリズムが載っておりますが、
これに加えて、初級になるためにはこれくらいは知っておいて欲しいというものを紹介します。
※後、最初から必ずしも手を出さなくても良い上限も紹介いたします。
プログラムは、データを入力して、加工して出力・保存する処理の繰り返しです。
つまり、各一連の繰り返し毎に、「正しい入力」「正しい出力」を定式化する必要があります。
それを人間の手では無くコンピューターにやらせられるように、つまり自動テストできるようにテストをプログラミングします。
そこで処理の進捗を確認するためにロギングし、処理が想定通りであるかをアサーションでチェックし、
不正な入力・不正な出力=例外が起きたら、対処策をプログラミングします。
(ex 途中で処理を中断して、入力者に適切な入力のメッセージを伝えてあげる。入力の自動補正などもあり得る)
で、ここら辺をまとめてどうあるべきかとして「契約プログラミング」があります。
※余談。定式化・テストに際して、数学畑の人間としては、Javaだとequalsのオーバーライドでも必要になるし、同値関係・同値分割だけでなく、集合論・群論から学んで欲しい・・・(ここいらは数学科の学部１~２年の学習内容)
名著は英語で読みましょう。名著が名著たる由縁は、度々引用されることにあります。
つまり最新の技術書を読むときに、引用された名著のフレーズが、新旧のリンクをなし、理解の助けになります。
壁打ちといって、独り言で思考補助をするよりも遙かに有益です。
※素晴らしい師匠を探すなら、大学行くのが一番ですが、見聞を広げていく中で出会いを待つしかないとも思います。
マルチスレッドが難しいのは「バグを起こしにくいプログラミング」を求められるから。
つまりTry and Errorからの決別が求められ、今後の仕様変更・拡張も踏まえて慎重に慎重にデザインする必要があります。
できる限りステータス変数を持たずに安全に、でもマルチスレッドにするのだから、効率を追求しなければ本末転倒。
でも効率のためにはメモ化に代表されるキャッシングは必須と、アンビバレンツな要素のバランス取りが難しい。
このために、リエントラントな実装・抽象と実装の分離など様々なエッセンスを駆使することが必要です。
というよりも孔子曰く、知っているよりも好きであること。好きであることよりも楽しめることのほうが強く、
気づいたら日々時間が許す限りプログラミングをしてしまうのが理想です。
※仕事として嫌々スキルを磨かなきゃということが、これほど不幸な職業も無いですね。
学習の達成度を測るには、簡単すぎる不適切な問題ですね。
写経は数学の証明問題を、教科書のテンプレ通りに、数値や名称だけ変えて記述することしか出来ない人の発想。
つまり「矛盾無く一貫した論理モデル」の構築が自由に出来ず、テンプレの微修正しか出来ない人の発想。
また、外部の「矛盾無く一貫した論理モデル」の吸収が不自由で、アルゴリズムを「手順」としてしか捉えられないように見受けられる。
「連続」であること確かめるための「ε-Δ論法」(数学科の学部１年の学習内容)
事前知識無く、このモデルを理解できる人は、十分に「矛盾無く一貫した論理モデル」を構築できる人。
１.まず「連続」とは何ぞやと考えて概念を膨らませてください。
http://anond.hatelabo.jp/20110316202255
デザインパターン編を書いてたら99ブクマだと…。なんだかすみません。
あと増田で書くの初めてで記法がちとわかっていなくて見づらくて申し訳ないです。
＞おもしろい。でもJavaとJSとRubyじゃ同じオブジェクト指向でもまったく違った設計と思想になるのでまとめて説明は難しいかも
言語＝世界として、どんな世界がいいか考えましょうという話に持って行きたかったけど難しかったですね。
＞ASしらないけど classが使えるJSっぽいところみるとASなんですかねこれ
＞@shinout 面白い！けどいろいろ間違ってる！！コード動かしてみいや
それっぽい言語なので動きません。JavaとかASとかそのへんですねー。
その割に一部ちゃんと書いてるのが誤解しそうですね。
＞ OOPを習得したPGとそうでないPGとの生産性の差がドラゴンボールで言うところの戦闘力の差という比喩でたとえるとよい。初心者PGが何人集まってもかなわないところがある。
＞17号と18号が逆
＞セルはis-aはなくhas-aで実装した方がいいような気がする。
セルってチート臭いですよね。くらった技を覚えるブウの設計と、遺伝子を持っているから技が使えるセルの設計をどうするかは議論になりそうです。
＞なんか、むしろ分かり辛くなってると思うけど、心意気やよし！
＞かりやすいんだかわかりにくいんだか
無理がありました。
＞連載はextendされたけど、主人公の継承には失敗したよね
素晴らしいコメント。設計ミスで主役になれなかったのは運用でカバー出来ましたね。
＞セルはクラスの承継よりもオブジェクトのコンポジションの方がいいのか分からない。
http://anond.hatelabo.jp/20110316215156
で突っ込まれてる内容の方がいいかもしれませんね。
でも悟空やベジータは吸収じゃなくて細胞を合成してる？とかなので17号、18号とは別にする必要があったりします。
申し訳ありません…。
