今日は「5章:ウィンドウを使いこなす」と「第6章:ファイルや色を選択する」をやった。
今回初めて「選択ウィンドウ」(「ファイルを開く」、「ファイルの保存」や「色を選択」「フォントの設定」)
を使った。
何らかの選択を行うから「選択ウィンドウ」という名前になっているのだが、それがそのままコマンドではなく「開くファイルを選択」とか「色を選択」というのがコマンドなので最初はすこしややこしいと感じた。
いままでボタンやウィンドウを作るだけだったが、
この機能を使うだけで本格的なソフトをつくっている気持ちになってくる。
またWindowsにもともと備わっている機能(ライブラリ)が、
とてもソフトの開発にとって役に立つ物だとわかる。
それらの部品(関数?)を使いこなし、必要な情報(戻り値)を自分のソフトにとりこむ
ことで、たくさんの開発の手間がはぶける。
おそらくこれはMELでも同じ事だろう。
いままでの勉強では、なかなかここまでは行きつかなかったが、
やってみると意外と簡単。
しかも関数の便利さに気づかせてくれた、やはりTTSneoをやってよかったと思う。
こんなことをすごいこと、難しいことのように考えていては到底、先へすすめないのも当然だろう。
プログラムは意外と簡単と感じた。
もちろん、これはあくまで部品化されている部分だし、なにかを表示するかしないかの動作なので
わかりやすいだけで、いろいろな複雑な物理計算や、情報の処理が入ってくると
当然考えることも増えるだろう。
だが、すでに作られている部品を使うことでそれが簡略化できるというのが、
知識だけでなく実体験としてわかってきたように思う。
これはプログラミングという作業を俯瞰でみるための、大きな一歩だ。
これにより他のソフトとのデータの連携がしやすくなるかもしれない。
そうなると、なんとなくPythonにも興味がでてきた。
将来、RealFlow SDKでtranslaterも作れる?!
----メモ----
ところで「抜ける」命令でよくわからなかったのが、
手順内で、「もし~なら抜ける」を使ったら、
「手順から抜ける」と同等なのか?
「もしから抜ける」と同等なのか?
「抜ける」のあとに「~のファイル名を表示」を実行するようにして実行してみたら、表示されなかったので手順自体をぬけるようだ。
この辺は、なんとなくあいまいで例が悪いように思う。
「選択ウィンドウのキャンセルは オンなら 抜ける」の行で、
「キャンセル」というのは設定項目であり、クリックしたときのみ「1(オン)を表す。
「選択ウィンドウのキャンセル」とう文が一つの変数とみなすとよいだろう。
この表記は、「連想配列」と同じだな、もしかしたら連想配列は
こういうふうに使うのか、なるほどよく知った名前なら、便利かもしれない。
また今さらながらわかったことは、
ウィンドウに関する手順(たとえば「ウィンドウ1のボタン1をクリック」)
は通常の手順と違い、これが手順(関数)名ではないので、
プログラム本体内では、とくにその手順(関数)名を書く必要はない。
勝手にウィンドウ操作をしたことが反映される。
(もちろん、ウィンドウを表示しておくことは前提だが。)
2009年1月31日土曜日
2009年1月29日木曜日
いままでの経緯
このブログはMELを初めて勉強したころから考えるとずいぶん経過して始めたので、それまでの経緯にはあまり触れていない。
最初にMELに触れたのは学生のころで、5~6年前だった。
そのときはコマンドの多さと決まり事の多さに圧倒されて、見よう見まねですこしエクスプレッションを書いたぐらいだった。
ただ当時から感じているのは、高校生のころにやったベーシックでもFor~Nextとか、ifとか変数とか似たようなことは勉強したなと思った。
もちろんMayaのクラスを受ける前、以前の仕事をしていたころにも
Javaにもトライしたことがあった。(クラスの説明を読解するところでくじけたが。。)
最近では、MELの本を読んだり、WebのDigitalMatrixで勉強したりもしたが、いずれもいつのまにかやらなくなっていた。
仕事の合間にちょこちょこMELのヘルプをみたり、仕事で少しづつ他の人のプラグインをつかうことで少しづつなれてきたのは前に書いたとおり。
なぜ、そんなに抵抗があるのかわからないがまともに組み合うにはかなり抵抗がある。
ベーシックをやったときに、「人のまねをして、入力していればいつのまにか覚える」みたいなことがいわれていたが結局、ブラインドタッチができるようになっただけだった。
ただベーシックでもmelでもpythonでも、はては、C++やJavaでも共通することがある。
しかもそれを身につければ他の言語を覚えることはそれほど難しくないのではないのかと思ってる。
それはアルゴリズムかもしれない、数学かもしれないと関連書籍を購入したが
いずれも難しい上に、おもしろくなく(興味がわかない)最初少し読んでおわり。
段階が高すぎるのだろう、高校(中学)の数学からやりなおす必要がある。
でもそれ以外にもなにか共通点、普遍的な考え方がある、それを見つければ
MELもPythonも自由になると思って、今も自分なりの勉強の仕方でアプローチしている。
感覚的には、TTSneoに出会ったことで、なんとなく糸口がみつかりそうな気持ちがしている。
またハードウエアとしてのコンピュータを計算機の歴史からひもといていくことを
7~8年前に図書館にかよって調べたことがある。
そのころのコンピュータは今とくらべて大変遅くなにかソフトをつかうにしても
中途半端な長さの待ち時間がとても多く、思考が妨げられるのでとてもイライラさせられていた。
また、高校生のときに初めて買ったコンピュータ富士通FM7も何か一つやるにしてもコンピュータが立ち上がるのを待ち、テープから情報をロードするのにまた4~5分まち、メニューが表示されるのを1分待ちと、コンピュータに対するイライラは当初からあった。
なぜ歴史から勉強したのかというと、コンピュータのブラックボックス部分(CPU)を解き明かし、ハードウエアとソフトウエアの関連をみつけることでよりよく理解し、中で何がおきているのかをわかるようにすればイライラも減るだろうと思ったからだ。
目的は自分なりに「コンピュータとは何か」という回答を出すこと。
PCを自作することから始め、数字の歴史(ゼロの発見)、ブーリアン、論理回路の設計、機械式計算機から電子計算機への移り変わり(そろばん、ライプニッツの歯車式計算機、微積分機、解析機関、ENIAC)、コンピュータが開発された目的(弾道計算)、などいろいろと調べた。
坂村健氏の痛快!コンピュータ学も読んだ。
このころ知ったことはいまでも役に立っている。
最初にMELに触れたのは学生のころで、5~6年前だった。
そのときはコマンドの多さと決まり事の多さに圧倒されて、見よう見まねですこしエクスプレッションを書いたぐらいだった。
ただ当時から感じているのは、高校生のころにやったベーシックでもFor~Nextとか、ifとか変数とか似たようなことは勉強したなと思った。
もちろんMayaのクラスを受ける前、以前の仕事をしていたころにも
Javaにもトライしたことがあった。(クラスの説明を読解するところでくじけたが。。)
最近では、MELの本を読んだり、WebのDigitalMatrixで勉強したりもしたが、いずれもいつのまにかやらなくなっていた。
仕事の合間にちょこちょこMELのヘルプをみたり、仕事で少しづつ他の人のプラグインをつかうことで少しづつなれてきたのは前に書いたとおり。
なぜ、そんなに抵抗があるのかわからないがまともに組み合うにはかなり抵抗がある。
ベーシックをやったときに、「人のまねをして、入力していればいつのまにか覚える」みたいなことがいわれていたが結局、ブラインドタッチができるようになっただけだった。
ただベーシックでもmelでもpythonでも、はては、C++やJavaでも共通することがある。
しかもそれを身につければ他の言語を覚えることはそれほど難しくないのではないのかと思ってる。
それはアルゴリズムかもしれない、数学かもしれないと関連書籍を購入したが
いずれも難しい上に、おもしろくなく(興味がわかない)最初少し読んでおわり。
段階が高すぎるのだろう、高校(中学)の数学からやりなおす必要がある。
でもそれ以外にもなにか共通点、普遍的な考え方がある、それを見つければ
MELもPythonも自由になると思って、今も自分なりの勉強の仕方でアプローチしている。
感覚的には、TTSneoに出会ったことで、なんとなく糸口がみつかりそうな気持ちがしている。
またハードウエアとしてのコンピュータを計算機の歴史からひもといていくことを
7~8年前に図書館にかよって調べたことがある。
そのころのコンピュータは今とくらべて大変遅くなにかソフトをつかうにしても
中途半端な長さの待ち時間がとても多く、思考が妨げられるのでとてもイライラさせられていた。
また、高校生のときに初めて買ったコンピュータ富士通FM7も何か一つやるにしてもコンピュータが立ち上がるのを待ち、テープから情報をロードするのにまた4~5分まち、メニューが表示されるのを1分待ちと、コンピュータに対するイライラは当初からあった。
なぜ歴史から勉強したのかというと、コンピュータのブラックボックス部分(CPU)を解き明かし、ハードウエアとソフトウエアの関連をみつけることでよりよく理解し、中で何がおきているのかをわかるようにすればイライラも減るだろうと思ったからだ。
目的は自分なりに「コンピュータとは何か」という回答を出すこと。
PCを自作することから始め、数字の歴史(ゼロの発見)、ブーリアン、論理回路の設計、機械式計算機から電子計算機への移り変わり(そろばん、ライプニッツの歯車式計算機、微積分機、解析機関、ENIAC)、コンピュータが開発された目的(弾道計算)、などいろいろと調べた。
坂村健氏の痛快!コンピュータ学も読んだ。
このころ知ったことはいまでも役に立っている。
注意力をコントロールして集中する
<<Lifehacker 「ネット時代の成功は、ハードワークより注意力から」より>>
「他のネットの誘惑に負けず、どのように注意力をコントロールするかにかかっているんです。ちゃんと仕事に集中できていますか?」
これは勉強するときにも言える、つい思いついたことを、blogに書き留めておこうとしたり、
単語をしらべているうちに、徐々に脱線して関係ない記事を読み始めていたり。。。。
そういった脱線にきがついたら、すぐ元に戻って、勉強に集中するようにしよう。
<<もうひとつITmediaの 「仕事時間を賢く楽に節約する10の方法」より>>
(2. 気を散らすものを遮断し、タイマーをセットする)
「電子メールとIMクライアントを閉じて、キッチンタイマーを持ってくる。タイマーを10分後にセットし、タイマーが鳴るまで作業をする。それから休憩して、また同じことを繰り返す。」
「私はこのやり方に絶対の信頼を置いている。この方法をおかげで、ベッドの下に隠れたいと思いながらも、400ページのLifehackerの本を書き上げることができた。」
これもよさそう。
「他のネットの誘惑に負けず、どのように注意力をコントロールするかにかかっているんです。ちゃんと仕事に集中できていますか?」
これは勉強するときにも言える、つい思いついたことを、blogに書き留めておこうとしたり、
単語をしらべているうちに、徐々に脱線して関係ない記事を読み始めていたり。。。。
そういった脱線にきがついたら、すぐ元に戻って、勉強に集中するようにしよう。
<<もうひとつITmediaの 「仕事時間を賢く楽に節約する10の方法」より>>
(2. 気を散らすものを遮断し、タイマーをセットする)
「電子メールとIMクライアントを閉じて、キッチンタイマーを持ってくる。タイマーを10分後にセットし、タイマーが鳴るまで作業をする。それから休憩して、また同じことを繰り返す。」
「私はこのやり方に絶対の信頼を置いている。この方法をおかげで、ベッドの下に隠れたいと思いながらも、400ページのLifehackerの本を書き上げることができた。」
これもよさそう。
TTSneo ソフト作り編 (2)
今日は3章と4章をやった。約一時間、けっこう集中して出来たと思う。
Lifehackerの方法、注意をコントロールしてできるだけ今、勉強していること以外は手を出さないようにした。
思いついたことを後で、ブログにまとめるためにメモをとっておいたぐらい。
今回はプログラムでオブジェクトを配置したウィンドウを作成するというのがテーマだった。
4章のイベントにより、手順を実行するというのがよくわかった。
基礎編の「手順」と混同していたがオブジェクトのイベントの「手順は」書き方が違っていることがわかり、納得。
テキスト欄に入力されたパスワードの確認をするプログラムを練習問題で作ったが。
なんとかできた。
MELでウィンドウを作ったときはとても大変だったが、
ウィンドウやオブジェクトのサイズや位置に煩わされることがなければ意外とポイントとなる箇所は少なそうだ。
要は各オブジェクトの働きとそれに関連したイベント処理が重要なポイントということだ。
またTTSneoでは「その」で直前のオブジェクトが指定できるので、
これは考えるときも、いちいちオブジェクト名を確認するなどの思考をさまたげる作業がないので、
プログラミングに集中できるし、新しいことではない(通常の会話や読書で使っていることばであり、
意味するところも同じなので、直感的に使える。
これをMELで使えないのは残念だが、
TTSneoを使って、プログラミングに親しみ、アルゴリズムに親しむには、
こういった文法にわずらわされないのは助かる。
Lifehackerの方法、注意をコントロールしてできるだけ今、勉強していること以外は手を出さないようにした。
思いついたことを後で、ブログにまとめるためにメモをとっておいたぐらい。
今回はプログラムでオブジェクトを配置したウィンドウを作成するというのがテーマだった。
4章のイベントにより、手順を実行するというのがよくわかった。
基礎編の「手順」と混同していたがオブジェクトのイベントの「手順は」書き方が違っていることがわかり、納得。
テキスト欄に入力されたパスワードの確認をするプログラムを練習問題で作ったが。
なんとかできた。
MELでウィンドウを作ったときはとても大変だったが、
ウィンドウやオブジェクトのサイズや位置に煩わされることがなければ意外とポイントとなる箇所は少なそうだ。
要は各オブジェクトの働きとそれに関連したイベント処理が重要なポイントということだ。
またTTSneoでは「その」で直前のオブジェクトが指定できるので、
これは考えるときも、いちいちオブジェクト名を確認するなどの思考をさまたげる作業がないので、
プログラミングに集中できるし、新しいことではない(通常の会話や読書で使っていることばであり、
意味するところも同じなので、直感的に使える。
これをMELで使えないのは残念だが、
TTSneoを使って、プログラミングに親しみ、アルゴリズムに親しむには、
こういった文法にわずらわされないのは助かる。
2009年1月28日水曜日
漸化式 (ぜんかしき)
結城氏のインタビューに出てきた「漸化式」という言葉を調べてみた。
高校勉強攻略ノート(漸化式って何?)
MSN相談箱(漸化式)
勉強するなら
漸化式(自力で再学習する人のためのテキスト
この人のサイトはなかなかためになりそうなので、ほかのページも
姉妹編:高校で学べない人のための数列
高校で学べない人のための数学2 (log:指数など)
高校で学べない人のための数学B (ベクトル、複素数など)
高校勉強攻略ノート(漸化式って何?)
MSN相談箱(漸化式)
勉強するなら
漸化式(自力で再学習する人のためのテキスト
この人のサイトはなかなかためになりそうなので、ほかのページも
姉妹編:高校で学べない人のための数列
高校で学べない人のための数学2 (log:指数など)
高校で学べない人のための数学B (ベクトル、複素数など)
結城浩にインタビュー 『プログラマの数学』
結城浩にインタビュー 『プログラマの数学』
この本は、以前買ったのだが、自分には少し難しかったのと、
あまり興味はわかない内容が多かったので、
少し読んだがそのまま戸棚の奥に鎮座してしまった。
今日、いろいろと天才プログラマの記事を検索してさがしているときに
このページもみつけたので、少し自分の興味を引き起こすためにこのインタビューを読んでみた。
「プログラマとコンピュータは共同で問題を解きます」
「プログラマの仕事の1つは、問題の中から「構造を見いだす」ところにあります。」
「とにかく複雑でややこしいものを目にしたときに(中略)いろんな技法を使って解きほぐします。 」
なるほど、何かを処理させたいとおもったら、まずその処理させたいことが何か(問題は何か)を
明確にし、それから「構造」を明確にする必要があるのはスクリプトでも同様だと思う。
「構造・規則性・性質・まとまり・グループ・仕組み…」
これは問題の構造を解き明かすときに、指標として使えるキーワードだろう。
「構造を見抜け、パターンをあばけ」
「論理を使うかもしれません。小さい数を使って実験して周期性や規則性を見つけるかもしれません。あるいは再帰的な構造を見抜いたり、漸化式を作ったりするかも。」
「さまざまな方法でややこしいものを分解し、把握しようとする。それが、プログラマにとって重要な仕事」
スクリプトやプログラミングをしているときいろいろと考えながらプログラムを入力する。
そこで行われていることはなんだろう?!
1)構造を見抜き
2)パターンをはっきりさせ
3)それをプログラミング言語の法則を使って、記述している
結城氏の言葉を借りれば上記のようなことではないかと思う。
この本は、以前買ったのだが、自分には少し難しかったのと、
あまり興味はわかない内容が多かったので、
少し読んだがそのまま戸棚の奥に鎮座してしまった。
今日、いろいろと天才プログラマの記事を検索してさがしているときに
このページもみつけたので、少し自分の興味を引き起こすためにこのインタビューを読んでみた。
「プログラマとコンピュータは共同で問題を解きます」
「プログラマの仕事の1つは、問題の中から「構造を見いだす」ところにあります。」
「とにかく複雑でややこしいものを目にしたときに(中略)いろんな技法を使って解きほぐします。 」
なるほど、何かを処理させたいとおもったら、まずその処理させたいことが何か(問題は何か)を
明確にし、それから「構造」を明確にする必要があるのはスクリプトでも同様だと思う。
「構造・規則性・性質・まとまり・グループ・仕組み…」
これは問題の構造を解き明かすときに、指標として使えるキーワードだろう。
「構造を見抜け、パターンをあばけ」
「論理を使うかもしれません。小さい数を使って実験して周期性や規則性を見つけるかもしれません。あるいは再帰的な構造を見抜いたり、漸化式を作ったりするかも。」
「さまざまな方法でややこしいものを分解し、把握しようとする。それが、プログラマにとって重要な仕事」
スクリプトやプログラミングをしているときいろいろと考えながらプログラムを入力する。
そこで行われていることはなんだろう?!
1)構造を見抜き
2)パターンをはっきりさせ
3)それをプログラミング言語の法則を使って、記述している
結城氏の言葉を借りれば上記のようなことではないかと思う。
「真のゆとり教育」が生んだ18歳天才プログラマー
「真のゆとり教育」が生んだ18歳天才プログラマー
この人も英語が小さいころからできたという。
プログラミング言語は英語の文法が基本にあると思うので、英語が得意であれば
プログラミングの習得も興味さえあればそれほど苦にはならないのかもしれない。
それと天才的な才能とは別の物だろうが、
小、中学生でも難解なアルゴリズム(この人の例ではレンダラー)を
理解することは可能であるということがわかる。
それは天才という言葉で片付けることもできるが、
理解までの段階が順序立ててそろえられていれば実はもっと多くの人が獲得できることかもしれない。
アルゴリズムは数学に属することであり、数学は記号を使ってなんらかの思考や概念をあらわす。
言葉での説明(国語)であれば、覚える単語が数学よりもたくさん必要となり、限界があるが、
数学はある程度のものを知っていれば、あとは思考を読み取ることであり、
それは本来、子供達がもっている才能かもしれない。
この人も英語が小さいころからできたという。
プログラミング言語は英語の文法が基本にあると思うので、英語が得意であれば
プログラミングの習得も興味さえあればそれほど苦にはならないのかもしれない。
それと天才的な才能とは別の物だろうが、
小、中学生でも難解なアルゴリズム(この人の例ではレンダラー)を
理解することは可能であるということがわかる。
それは天才という言葉で片付けることもできるが、
理解までの段階が順序立ててそろえられていれば実はもっと多くの人が獲得できることかもしれない。
アルゴリズムは数学に属することであり、数学は記号を使ってなんらかの思考や概念をあらわす。
言葉での説明(国語)であれば、覚える単語が数学よりもたくさん必要となり、限界があるが、
数学はある程度のものを知っていれば、あとは思考を読み取ることであり、
それは本来、子供達がもっている才能かもしれない。
Cyanを設計した高校生、5カ月で5つの言語を習得
Cyanを設計した高校生、5カ月で5つの言語を習得
この記事で日本語プログラミング言語のTTSneoの存在を知った。
TTSneoのホームページを見ると意外と簡単そうだったので、
天才とはいえ中学生にできるなら、
自分でもある程度はできるかもしれないと思って始めることにした。
この記事でおもしろかったのが、この人が、文系の発想だということ。
プログラミング言語の文法をながめているだけで、おもしろいという。
いままで思わなかった視点かもしれない。
自分にとってプログラミング言語の文法は必要なものという認識しかなかったが、
純粋な言語(日本語や英語)の構造(文法)を学ぶことで、プログラミング言語の理解も深まるの
ではないかなと思った。
この記事で日本語プログラミング言語のTTSneoの存在を知った。
TTSneoのホームページを見ると意外と簡単そうだったので、
天才とはいえ中学生にできるなら、
自分でもある程度はできるかもしれないと思って始めることにした。
この記事でおもしろかったのが、この人が、文系の発想だということ。
プログラミング言語の文法をながめているだけで、おもしろいという。
いままで思わなかった視点かもしれない。
自分にとってプログラミング言語の文法は必要なものという認識しかなかったが、
純粋な言語(日本語や英語)の構造(文法)を学ぶことで、プログラミング言語の理解も深まるの
ではないかなと思った。
2009年1月27日火曜日
TTSneo ソフト作り編
基本編はまだ100%使えるようになったわけではないので、おさらいをかねて、何度かやったほうがよいのかもしれないが、同じ事を繰り返すのもおもしろくないので、とりあえず「ソフト作り編」へ進むことにした。
今日はそのうちの「1.ウィンドウをデザインする」をやってみた。
はっきり覚えていないが、以前「VisualBasic」を手探りでいじってみた時だったか、
「できるExcel!」で勉強したときに、でいろんなオブジェクトをつくったことがあったのを思い出した。
それよりはるかに決まり事や説明が簡略化されていてわかりやすい。
「設定」タブに表示される項目は、本当の初心者ならこれでもとまどうのかもしれないが
とりあえず今のところは抵抗なし、ほぼ直感的に操作できる。
実際に作ってみて、非常に便利だと思った。
これでMayaのプラグインが作れたら便利なのになぁと思う。
プラグインは無理でもMELのウィンドウをこのように作れるだけでも非常に助かるのだが。。。
UIを数値で作るなんて非人間的で時間の無駄に思えてしまう。
たしかHighend3dにそのようなMELスクリプトがあったような気がしたが、今探しても見つからない。
気のせいだったかな。。。。
今日はそのうちの「1.ウィンドウをデザインする」をやってみた。
はっきり覚えていないが、以前「VisualBasic」を手探りでいじってみた時だったか、
「できるExcel!」で勉強したときに、でいろんなオブジェクトをつくったことがあったのを思い出した。
それよりはるかに決まり事や説明が簡略化されていてわかりやすい。
「設定」タブに表示される項目は、本当の初心者ならこれでもとまどうのかもしれないが
とりあえず今のところは抵抗なし、ほぼ直感的に操作できる。
実際に作ってみて、非常に便利だと思った。
これでMayaのプラグインが作れたら便利なのになぁと思う。
プラグインは無理でもMELのウィンドウをこのように作れるだけでも非常に助かるのだが。。。
UIを数値で作るなんて非人間的で時間の無駄に思えてしまう。
たしかHighend3dにそのようなMELスクリプトがあったような気がしたが、今探しても見つからない。
気のせいだったかな。。。。
2009年1月26日月曜日
変数の宣言 :MEL
変数の宣言 :MEL
1)変数を使用する前に、変数を宣言する必要があります。;
(変数の使用前に変数を宣言しなければならないのは、変数のスペルミスや誤りなどのよくある問題によって発見が困難なバグが生じるのを防ぐためです。)
a)型のキーワードを明記 (float, int, string, vector,matrix)
b)その後に変数名を記述
2)変数名の決まりは、
a)常にドル記号($)で始める。
b)文字(大文字と小文字は区別されます。)を使用可。
c)アンダースコア(_)を使用可。
d)最初の文字($ の後)でなければ数字を使用可。
例:
vector $position
float $floaty5000
string $longDescriptiveName
string $name_with_underscores
int $_line
1)変数を使用する前に、変数を宣言する必要があります。;
(変数の使用前に変数を宣言しなければならないのは、変数のスペルミスや誤りなどのよくある問題によって発見が困難なバグが生じるのを防ぐためです。)
a)型のキーワードを明記 (float, int, string, vector,matrix)
b)その後に変数名を記述
2)変数名の決まりは、
a)常にドル記号($)で始める。
b)文字(大文字と小文字は区別されます。)を使用可。
c)アンダースコア(_)を使用可。
d)最初の文字($ の後)でなければ数字を使用可。
例:
vector $position
float $floaty5000
string $longDescriptiveName
string $name_with_underscores
int $_line
記憶と理解
少し前に記憶力についてふれたが、
それは理解と深い関係がある。
今は、Mayaのヘルプファイルはすべて日本語化されWeb上でも閲覧可能となったし、
いろんなひとがTipsやチュートリアルを公開している。
その中でも阿部知弘氏によるDigital Matrixには大変お世話になったし、いまもお世話になっている。
普通の人ならこれを読んで学習するだけでもある程度は、習得できるんだろうと思う。
そういった様々な日本語のWebサイトや英語のサイトと本で勉強してみてわかったのは、
暗記すれば簡単にできるようなことでも、無条件に暗記することに非常に抵抗があり、
ひとつひとつのコマンドや、考え方の根本にある概念が明確にわかっていないと
それらを使うのに非常に抵抗があり、やる気がなくなるのである。
サイトを読んで、教えられたことと似たような働きをするスクリプトを作ったり、改良したりは
少しならできるようになる。
ただ何も見ないで一から自分なりのアイデアでスクリプトをつくることはできない。
たとえ同じような働きをするもので結果が同じであっても、
コマンドの順番などは自分なりのアイデアでちゃんと考えながら作りたい。
暗記に優れた人はひとつひとつのコマンドを記憶してすぐにできるようになるのだろうが、
自分が納得していないと、あるコマンドを使う気にもならないのでは、何も進まない。
ただ、広く求められるのは前者である。
現在の教育社会は記憶力重視の知識偏重といわれている。
弊害として思考力の無さ、判断力の欠如が問題として上がっているのはよく知られているところ。
最近では、その知識さへ低下してきていると聞く。
自分がなりたいアーティスト像は、自分の考えと判断で行動をおこすことである。
そうでなくては、価値のあるアーティストにはなれないだろうし、
その雇う側からしても、そのようなアーティストでなくては信頼がおけないだろう。
自分の考えと判断で行動を起こすというのはMELスクリプトを作る上でもいえることだ、
底に求められるのは、いろいろなコマンドに関する知識だけでなく、それに対する理解が必要だ。
理解は、コマンドに限らず、コンピュータ全体、プログラミング全体の基本的な概念にも及ぶ必要があると思う。
基本的な概念というのは、そもそも「コンピュータとは何か」、「プログラミングとは何か」
「For~Next文とは何か」そういったことだ。
そういった基本をしっかり理解しておけば、知識は生きたものとなると思う。
それは理解と深い関係がある。
今は、Mayaのヘルプファイルはすべて日本語化されWeb上でも閲覧可能となったし、
いろんなひとがTipsやチュートリアルを公開している。
その中でも阿部知弘氏によるDigital Matrixには大変お世話になったし、いまもお世話になっている。
普通の人ならこれを読んで学習するだけでもある程度は、習得できるんだろうと思う。
そういった様々な日本語のWebサイトや英語のサイトと本で勉強してみてわかったのは、
暗記すれば簡単にできるようなことでも、無条件に暗記することに非常に抵抗があり、
ひとつひとつのコマンドや、考え方の根本にある概念が明確にわかっていないと
それらを使うのに非常に抵抗があり、やる気がなくなるのである。
サイトを読んで、教えられたことと似たような働きをするスクリプトを作ったり、改良したりは
少しならできるようになる。
ただ何も見ないで一から自分なりのアイデアでスクリプトをつくることはできない。
たとえ同じような働きをするもので結果が同じであっても、
コマンドの順番などは自分なりのアイデアでちゃんと考えながら作りたい。
暗記に優れた人はひとつひとつのコマンドを記憶してすぐにできるようになるのだろうが、
自分が納得していないと、あるコマンドを使う気にもならないのでは、何も進まない。
ただ、広く求められるのは前者である。
現在の教育社会は記憶力重視の知識偏重といわれている。
弊害として思考力の無さ、判断力の欠如が問題として上がっているのはよく知られているところ。
最近では、その知識さへ低下してきていると聞く。
自分がなりたいアーティスト像は、自分の考えと判断で行動をおこすことである。
そうでなくては、価値のあるアーティストにはなれないだろうし、
その雇う側からしても、そのようなアーティストでなくては信頼がおけないだろう。
自分の考えと判断で行動を起こすというのはMELスクリプトを作る上でもいえることだ、
底に求められるのは、いろいろなコマンドに関する知識だけでなく、それに対する理解が必要だ。
理解は、コマンドに限らず、コンピュータ全体、プログラミング全体の基本的な概念にも及ぶ必要があると思う。
基本的な概念というのは、そもそも「コンピュータとは何か」、「プログラミングとは何か」
「For~Next文とは何か」そういったことだ。
そういった基本をしっかり理解しておけば、知識は生きたものとなると思う。
モチベーション (2)
「モチベーションが低い状況で、いかにMELスクリプトを習得するか?!」
いま、おもえばこれは自分には不可能ではないかと思う。
モチベーションが低いものをわざわざやる気にはならないからだ。
仕事に必要だったにしろ、強制されたにしろ、それらもなんらかのモチベーションとなり得る。
結局の所、モチベーションが低いならば、それを高くするための工夫が必要であり、
それはその人の資質、正確、置かれた状況によってことなると思う。
株トレーダーになりたい人がいくらMELスクリプトを勉強してもむりである。
モチベーションが違うところにあるので、MELスクリプトの勉強は目標をさまたげるものであり、苦痛でしかない。
そういう人はさっさとCG業界から足をあらったほうがよいだろう。
いま、おもえばこれは自分には不可能ではないかと思う。
モチベーションが低いものをわざわざやる気にはならないからだ。
仕事に必要だったにしろ、強制されたにしろ、それらもなんらかのモチベーションとなり得る。
結局の所、モチベーションが低いならば、それを高くするための工夫が必要であり、
それはその人の資質、正確、置かれた状況によってことなると思う。
株トレーダーになりたい人がいくらMELスクリプトを勉強してもむりである。
モチベーションが違うところにあるので、MELスクリプトの勉強は目標をさまたげるものであり、苦痛でしかない。
そういう人はさっさとCG業界から足をあらったほうがよいだろう。
モチベーション (1)
なにかを勉強には、モチベーションが重要だが、
私の場合、MELスクリプトの勉強するにあたりモチベーションがあまりなかった。
「そもそもMELスクリプトがなくても終わらせられる仕事だった」。
「MELスクリプトがなくてはできないことはシニアレベルの人がやっていた。」
「パーティクルもそれほど使う機会がなく、エクスプレッションもあまり縁がなかった。」
のでMELスクリプトの必要性をあまり感じなかった、それに加えていざ勉強をはじめても
覚えることが多すぎた。
暗記は小学生のころから大嫌いで、いまだに大嫌い。
ただ記憶力が悪いわけではない、一度行った道をしっかりとおぼえていたり、
一度あっただけの人をちゃんと覚えていたりする、イメージや印象、での記憶は確かなようだ。
苦手なのは、人の名前を覚えたり、特定の言葉や名前をおぼえること。
そういったものをおぼえるには、それにまつわるストーリーを知り、イメージや印象を
広げるようにしていた。
たとえば「南極点」という言葉を知るには、アムンゼン探検隊のストーリーや、南極での生態系、
観光ツアーの内容などを読むことで、はっきりと記憶できる。
ただこの方法、MELやプログラミング言語を習得するにはやることが多すぎて間に合わない。
当然ながら人が書いたMELを分析するよう努力もしたが同じ理由で、自分には合わない。
それがひとつのネックになっていた。
それらのモチベーションと記憶という二つの障害を克服するためには、
ここ1~2年実行してきたことがある。
とりあえずMELの便利さ、重要性に気づき、やる気をださせるためにやり始めたことは、
1)Highend3Dなどで、他の人の作ったMELスクリプトを使ってみる。
2)Shelfに自分が使ったコマンドをスクリプトとして保存してみる。
3)いろんなMELスクリプトのチュートリアルなどを試してみる。
5)気が向いたときにHELPファイルを拾い読みしてみる。
6)パーティクルを使う機会を増やす
7)MELに限らず、コンピュータの仕組みやプログラムの基本的な概念を知るために情報を集める。
ここでの要点は、何かを記憶することではない。
記憶を助けるために、MELスクリプティングをとりまくいろいろなコンピュータの概念をえることであり、
プログラミングという作業の生い立ちと、その考え方を知ることである。
また、モチベーションを高めるために「その利点を感じ、抵抗を少なくするために慣れ親しむ」ということであった。
そのおかげか、最近は、MELスクリプトに対して抵抗が前より少なくなってきた。
ダウンロードしたスクリプトを使う機会も増え、Shelfにコマンド登録することも増えた。
未だにMELスクリプトと呼べるほどのものは作れないが、
パーティクルエクスプレッションがなくてはできない表現も、過去のスクリプトのコピペで
少しならできるようになった。
それに従いパーティクルをつかったショットの数も増えてきた。
ま、以前に比べたら給料も少し増えた。
最大のモチベーションは別の所からやってきた、子供のために収入と蓄えを増やさなくてはならない
ということだ。
よりよい職場、ポジションを手に入れなくいてはそれらの実現は不可能。
(可能かもしれないが、仕事に見合わない給料をもらって幸せを感じられるかどうか疑問に思う。)
これが、今の動機となっている。
実現のためには
1)仕事をより早くできる。
2)よりよい質の仕事ができる。
(それぞれの具体例はまた今度。。。)
コンピュータの力を、より利用できるようになればそれらを達成する大きな助けとなる。
MELスクリプトはそれにかなっている。
私の場合、MELスクリプトの勉強するにあたりモチベーションがあまりなかった。
「そもそもMELスクリプトがなくても終わらせられる仕事だった」。
「MELスクリプトがなくてはできないことはシニアレベルの人がやっていた。」
「パーティクルもそれほど使う機会がなく、エクスプレッションもあまり縁がなかった。」
のでMELスクリプトの必要性をあまり感じなかった、それに加えていざ勉強をはじめても
覚えることが多すぎた。
暗記は小学生のころから大嫌いで、いまだに大嫌い。
ただ記憶力が悪いわけではない、一度行った道をしっかりとおぼえていたり、
一度あっただけの人をちゃんと覚えていたりする、イメージや印象、での記憶は確かなようだ。
苦手なのは、人の名前を覚えたり、特定の言葉や名前をおぼえること。
そういったものをおぼえるには、それにまつわるストーリーを知り、イメージや印象を
広げるようにしていた。
たとえば「南極点」という言葉を知るには、アムンゼン探検隊のストーリーや、南極での生態系、
観光ツアーの内容などを読むことで、はっきりと記憶できる。
ただこの方法、MELやプログラミング言語を習得するにはやることが多すぎて間に合わない。
当然ながら人が書いたMELを分析するよう努力もしたが同じ理由で、自分には合わない。
それがひとつのネックになっていた。
それらのモチベーションと記憶という二つの障害を克服するためには、
ここ1~2年実行してきたことがある。
とりあえずMELの便利さ、重要性に気づき、やる気をださせるためにやり始めたことは、
1)Highend3Dなどで、他の人の作ったMELスクリプトを使ってみる。
2)Shelfに自分が使ったコマンドをスクリプトとして保存してみる。
3)いろんなMELスクリプトのチュートリアルなどを試してみる。
5)気が向いたときにHELPファイルを拾い読みしてみる。
6)パーティクルを使う機会を増やす
7)MELに限らず、コンピュータの仕組みやプログラムの基本的な概念を知るために情報を集める。
ここでの要点は、何かを記憶することではない。
記憶を助けるために、MELスクリプティングをとりまくいろいろなコンピュータの概念をえることであり、
プログラミングという作業の生い立ちと、その考え方を知ることである。
また、モチベーションを高めるために「その利点を感じ、抵抗を少なくするために慣れ親しむ」ということであった。
そのおかげか、最近は、MELスクリプトに対して抵抗が前より少なくなってきた。
ダウンロードしたスクリプトを使う機会も増え、Shelfにコマンド登録することも増えた。
未だにMELスクリプトと呼べるほどのものは作れないが、
パーティクルエクスプレッションがなくてはできない表現も、過去のスクリプトのコピペで
少しならできるようになった。
それに従いパーティクルをつかったショットの数も増えてきた。
ま、以前に比べたら給料も少し増えた。
最大のモチベーションは別の所からやってきた、子供のために収入と蓄えを増やさなくてはならない
ということだ。
よりよい職場、ポジションを手に入れなくいてはそれらの実現は不可能。
(可能かもしれないが、仕事に見合わない給料をもらって幸せを感じられるかどうか疑問に思う。)
これが、今の動機となっている。
実現のためには
1)仕事をより早くできる。
2)よりよい質の仕事ができる。
(それぞれの具体例はまた今度。。。)
コンピュータの力を、より利用できるようになればそれらを達成する大きな助けとなる。
MELスクリプトはそれにかなっている。
2009年1月25日日曜日
TTSneo基本編 終了
TTSneoの基本編マニュアルを一通り終わった。
「13」(ローカル変数と再帰処理)は中級者向けということなので、ざっと目を通しただけ、ローカル変数はわかるが、再帰処理は、おいかけていくのが大変で少し混乱してくる、自分にとっては段階が高いと感じた。
「14」はおさらいなので、また後ほど呼んでみる事にする。
マニュアルに12で基本編は一通りおわりと書いてあるのでこれでよいだろう。
「1」からはじめて約1週間かかったが、なんとか終わった。
おもったより時間がかかるというか、呼んでて集中力が続かない。
実際にマニュアル読んで、実際にプログラムを入力してる時間は長くて1時間だと思うが、
気になる言葉や仕組みを調べはじめると。
だんだん、脱線していき、ふと気がつけば、オバマさんの任式のニュースを読んだり、ホロコーストの情報をしらべたり、はては、子育て情報や、木工情報、レジャー情報などと関係ないことをして
2~3時間がたってしまっている。
こころの底では、プログラミングの勉強などやりたくなくて、ついつい避ける方向にむかっているのだろう。
ほんとうに集中して勉強できればもっとはかどると思うけど。
これをどのように克服して、プログラムの習得をするのが、課題でもある。
「13」(ローカル変数と再帰処理)は中級者向けということなので、ざっと目を通しただけ、ローカル変数はわかるが、再帰処理は、おいかけていくのが大変で少し混乱してくる、自分にとっては段階が高いと感じた。
「14」はおさらいなので、また後ほど呼んでみる事にする。
マニュアルに12で基本編は一通りおわりと書いてあるのでこれでよいだろう。
「1」からはじめて約1週間かかったが、なんとか終わった。
おもったより時間がかかるというか、呼んでて集中力が続かない。
実際にマニュアル読んで、実際にプログラムを入力してる時間は長くて1時間だと思うが、
気になる言葉や仕組みを調べはじめると。
だんだん、脱線していき、ふと気がつけば、オバマさんの任式のニュースを読んだり、ホロコーストの情報をしらべたり、はては、子育て情報や、木工情報、レジャー情報などと関係ないことをして
2~3時間がたってしまっている。
こころの底では、プログラミングの勉強などやりたくなくて、ついつい避ける方向にむかっているのだろう。
ほんとうに集中して勉強できればもっとはかどると思うけど。
これをどのように克服して、プログラムの習得をするのが、課題でもある。
連想配列 その2
会社のエンジニアに連想配列がどのぐらい使い道があるのか聞いてみた。
帰ってきた答えは、「very useful!! almost everytime I'm using it!!」ということだ。
わざわざ説明もしてくれたが、以前自分でしらべたことと同じだったのであいかわらず
何かはっきりと理解できたわけではないが、英語力がないので、つっこんだことを聞くこともできず
そのままで終わった。
それでも彼が、とても便利だと感じ、いつも使っていると言うことは、かなり良さそうだ。
MELにそのような機能があるのかどうかはわからないがPythonには「辞書」として
実装されているので、使い方を習得しておいて、損はないことがわかって安心した。
帰ってきた答えは、「very useful!! almost everytime I'm using it!!」ということだ。
わざわざ説明もしてくれたが、以前自分でしらべたことと同じだったのであいかわらず
何かはっきりと理解できたわけではないが、英語力がないので、つっこんだことを聞くこともできず
そのままで終わった。
それでも彼が、とても便利だと感じ、いつも使っていると言うことは、かなり良さそうだ。
MELにそのような機能があるのかどうかはわからないがPythonには「辞書」として
実装されているので、使い方を習得しておいて、損はないことがわかって安心した。
MELスクリプトの勉強
昨日、少しだけ、Mayaのマニュアルを開き、MELスクリプトの項目を読み直してみた。
読んだのは変数とかのあたり。
最近、TTSneoをやっていたせいか、MELスクリプトの複雑性が以前よりはっきりとわかるようになってきた。
一度に覚えなくてはいけないきまりも、たくさんあり、それのひとつひとつの重要度もあいまいだ。
その点、TTSneoは、覚えるべき事が少ないため、プログラミングの基本となる要点だけに集中できる。
少ない決まりでもちゃんと稼働するプログラムができるのだ。
これは、プログラミングのコマンドや文法に煩わされずに、プログラミングに必要な考え方や視点を経験することが出来る。
もちろん、MELでもそうだが初心者の私には、なにが最重要で、なにが不要なのか実行するまで、
わからず、ビクビクしている。精神衛生上も、よくない。
これでわかったのがプログラミングの学習で欠けているものとして、
1)重要度の段階(絶対かかせないこと、使っても使わなくても良い物)が区別されていない。
2)基本を充分に習得するまでの時間が割かれていない。
(最低限のルールを駆使し、それらを習得する機会がなく、いきなり複雑な機能の説明と使用例が示されている)
覚え切れていない機能を見直そうと思っても、ポイントとなるところをみつけるまでに時間がかかり、あきらめてしまう。
ようするにモチベーションが続かない。
と思った。
以上のことを理解すると、TTSneoのような簡単なプログラミング言語の勉強は無駄ではなかったと思う。
むしろ、MELを学習するときに、情報の重要度のランキング付けが自分でできて、
マニュアルに一様にかかれた情報の評価が自分でできるようになる。
そうすると、あれほど、抵抗のあったMELの学習もなんだかそれほど、苦にはおもえなくなってきた。
(2010年8月11日 一部改訂&加筆)
読んだのは変数とかのあたり。
最近、TTSneoをやっていたせいか、MELスクリプトの複雑性が以前よりはっきりとわかるようになってきた。
一度に覚えなくてはいけないきまりも、たくさんあり、それのひとつひとつの重要度もあいまいだ。
その点、TTSneoは、覚えるべき事が少ないため、プログラミングの基本となる要点だけに集中できる。
少ない決まりでもちゃんと稼働するプログラムができるのだ。
これは、プログラミングのコマンドや文法に煩わされずに、プログラミングに必要な考え方や視点を経験することが出来る。
もちろん、MELでもそうだが初心者の私には、なにが最重要で、なにが不要なのか実行するまで、
わからず、ビクビクしている。精神衛生上も、よくない。
これでわかったのがプログラミングの学習で欠けているものとして、
1)重要度の段階(絶対かかせないこと、使っても使わなくても良い物)が区別されていない。
2)基本を充分に習得するまでの時間が割かれていない。
(最低限のルールを駆使し、それらを習得する機会がなく、いきなり複雑な機能の説明と使用例が示されている)
覚え切れていない機能を見直そうと思っても、ポイントとなるところをみつけるまでに時間がかかり、あきらめてしまう。
ようするにモチベーションが続かない。
と思った。
以上のことを理解すると、TTSneoのような簡単なプログラミング言語の勉強は無駄ではなかったと思う。
むしろ、MELを学習するときに、情報の重要度のランキング付けが自分でできて、
マニュアルに一様にかかれた情報の評価が自分でできるようになる。
そうすると、あれほど、抵抗のあったMELの学習もなんだかそれほど、苦にはおもえなくなってきた。
(2010年8月11日 一部改訂&加筆)
2009年1月23日金曜日
いらいら
プログラムは作るのが非常に面倒で、いらいらしてくる。
if文の説明をみてるとなんとなく、その理由がわかってきた。
普段、いちいち意識しないで結論づけていることを、コンピュータに演算でやらせようとすると
ことこまかにいろんな状況をリストアップし、さらにひとつひとつ、YesかNoで判断していくように
文法にしたがって記述しなくてはならない。
ひとつのIf文は、
小さな子供(二、三歳児)に一つ判断することをおしえるようなもので、
非常にかみ砕いて、わかりやすくし、明確におしえなくてはならない。
しかも複雑な判断をさせようとすると、複数の子供をそろえてそれぞれに自分が判断すべき事をおしえ、
自分の答えを次の人に渡すように、順序よくならべてあげないといけない。
これを大人が普段やっているレベルまでまとめなくてはいけないのだから大変だ。
かみ砕いて説明しなくてはいけないことが多すぎる (>o<;)
こんなことをプログラムをつくるごとにやるなんてめんどうくさすぎる!!
If文の説明をみていると少し救いがあった。
条件の一覧表だ。
「同じ」「大きい」「小さい」などの比較。。。。
これをガイドとしてプログラムに必要な要素を考えていけばよいとうことだ。
なにもガイドなしで考えているよりは少し目標ができて整理しやすい。
「何と」「何を」比較したいのか。
そのあたりを基準にかんがえていけば、余計なことをかんがえなくてすみそうだ。
その結果によって「○○を実行する」もしくは「しない」ようにする。
少しプログラムが簡単におもえてきた。
関連エントリ:「スクリプト言語の学習におけるミッシング・リンク」
if文の説明をみてるとなんとなく、その理由がわかってきた。
普段、いちいち意識しないで結論づけていることを、コンピュータに演算でやらせようとすると
ことこまかにいろんな状況をリストアップし、さらにひとつひとつ、YesかNoで判断していくように
文法にしたがって記述しなくてはならない。
ひとつのIf文は、
小さな子供(二、三歳児)に一つ判断することをおしえるようなもので、
非常にかみ砕いて、わかりやすくし、明確におしえなくてはならない。
しかも複雑な判断をさせようとすると、複数の子供をそろえてそれぞれに自分が判断すべき事をおしえ、
自分の答えを次の人に渡すように、順序よくならべてあげないといけない。
これを大人が普段やっているレベルまでまとめなくてはいけないのだから大変だ。
かみ砕いて説明しなくてはいけないことが多すぎる (>o<;)
こんなことをプログラムをつくるごとにやるなんてめんどうくさすぎる!!
If文の説明をみていると少し救いがあった。
条件の一覧表だ。
「同じ」「大きい」「小さい」などの比較。。。。
これをガイドとしてプログラムに必要な要素を考えていけばよいとうことだ。
なにもガイドなしで考えているよりは少し目標ができて整理しやすい。
「何と」「何を」比較したいのか。
そのあたりを基準にかんがえていけば、余計なことをかんがえなくてすみそうだ。
その結果によって「○○を実行する」もしくは「しない」ようにする。
少しプログラムが簡単におもえてきた。
関連エントリ:「スクリプト言語の学習におけるミッシング・リンク」
なぜ気が進まないか
なぜプログラムやスクリプトの勉強は、やる気が起きにくく、やってもいらいらしてくるのか?
よく言われる「文系」というのは理由にならない。「慣れが必要」というのもちゃんと説明になっていない。
実際にとりかかってみると覚えることが多い。
また情報が整理されていない。
まとめてみると、
1)説明内容がレベルに会わせた段階的なものになっていない。
2)いきなり高度な知識(たとえば「演算」という単語)が出てくるが
説明は数行で簡単におこなわれて終わり。
しかもちゃんとした定義にすらなってないことがある。
実際わかった気にはなるが、適用することができない程度の理解でとどまってしまう。
3)近視眼的な知識が多く、応用や、俯瞰的な知識があまり説明されない。
ま、こういったことを個々にしらべていくのが、本来の勉強ってもので、
そういったことをしないで一冊の「Melスクリプト入門!」という本で
すべて身につけて熟練しようというのがおかしいのかもしれない。
暗記が得意な人は命令や文法をおぼえて、勧めていけるのだろうが、
私は暗記が大嫌いで、しかも裏付けがしっかりわからないとやる気も起こらないので、
地道にやっていくしかないかな。
自分がおもっていたよりプログラミングというのは、ずっと複雑で、奥が深いもののようだ。
心してかかっていかないと、できるようにはならないはずだ。
よく言われる「文系」というのは理由にならない。「慣れが必要」というのもちゃんと説明になっていない。
実際にとりかかってみると覚えることが多い。
また情報が整理されていない。
まとめてみると、
1)説明内容がレベルに会わせた段階的なものになっていない。
2)いきなり高度な知識(たとえば「演算」という単語)が出てくるが
説明は数行で簡単におこなわれて終わり。
しかもちゃんとした定義にすらなってないことがある。
実際わかった気にはなるが、適用することができない程度の理解でとどまってしまう。
3)近視眼的な知識が多く、応用や、俯瞰的な知識があまり説明されない。
ま、こういったことを個々にしらべていくのが、本来の勉強ってもので、
そういったことをしないで一冊の「Melスクリプト入門!」という本で
すべて身につけて熟練しようというのがおかしいのかもしれない。
暗記が得意な人は命令や文法をおぼえて、勧めていけるのだろうが、
私は暗記が大嫌いで、しかも裏付けがしっかりわからないとやる気も起こらないので、
地道にやっていくしかないかな。
自分がおもっていたよりプログラミングというのは、ずっと複雑で、奥が深いもののようだ。
心してかかっていかないと、できるようにはならないはずだ。
2009年1月22日木曜日
連想配列
今、勉強中の「TTSneo」のマニュアルにでてきた、「連想配列」。
疑問に思ったのは、
1)普通の配列や変数となにがちがうのか?
2)利点がわからない。下手すると変数より使いにくい(配列名と項目名の両方がひつようなので)
3)順番に並んでるわけでもないのになぜ、「配列」なのか?
さっそく検索。
--------------------
「配列は同じキーワードでいくつもの値を格納できるのですが、
連想配列はキーワードに対して一つの値しか格納できません」
これは疑問1の回答になるけど、これって逆に使いにくくなっているんでは。。。。
--------------------
beginnersCGI
このページにある図はわかりやすかった。
当然ながら、小難しい理論と、プログラム部分は読み飛ばしているので、ちゃんと理解できたわけではないが、
「連想配列はフォームからの値の受け取りなどの項でも使われており、非常に便利なので・・・」
ということで、「フォーム」とうものと組み合わせると便利らしい。
使い道がないわけでもないんだなと思う。
あと疑問3の答えにもなっているかな。
ようは名前のついた箱がならんでいると考えれば、これも配列。
おそらく変数とちがって、コンピュータ内部での処理の仕方が配列と同じようになっているんだろう。
プログラムの説明などをみると「変数」も「連想配列」も「文字の集まり」なので、そのあたりのことがわかりにくかったのだろう。なんとなく納得。
--------------------
Flashで遊ぼう
「すごく便利な連想配列
なにかと重宝する連想配列。
price["apple"]=98;
price["orange"]=48;
price["banana"]=105;
こういう感じで配列の添え字のところが文字列になってるやつですね。
なにが便利って、連想配列ではなく単に配列でデータがあるとしたら、、、
fruit[0]="apple";
fruit[1]="orange";
fruit[2]="banana";
yen[0]=98;
yen[1]=48;
yen[2]=105;
と二つの配列があり、いざappleの値段が欲しい時、まずappleの添え字が何番か全数から調べ、そこから得た添え字により値段を得ることになります。
つまり、いちいち値段を調べるのにたくさんfor文なりwhile文をブンブン回す必要がでてきます。
データ数が少ないのならともかく、これが多くなると精神的にまずいよなあ~っと気分がブルーになってしまうわけです。え?私だけ?
それが連想配列だと最初に書いたようにダイレクトに得ることができるのです。(^^)v」
もう少し便利さがわかったような気がする。
●添え字(項目名)を使うことで直接その情報を得ることができる。(変数も同じじゃないのか?)
●For文、while文を使わなくて、簡単になるらしい。精神的にも良いらしい。
--------------------------
Perl/CGI研究室 'PERL-LABO'
フォームデータを連想配列化
「連想配列っていうのはPerlにもともと用意されている、「名前=値」というペアを格納するのに凄く便利な機能です。「名前=値」っていうと、フォームデータの形そのまんまですね。ですから、フォームデータを格納しておくのにもとても都合がいいんです。 」
なるほどフォームデータに便利なのか。。。今の自分には関係ないか。。。。
そろそろ考えるのが面倒になってきたので、連想配列を追求するのはここまで。
疑問に思ったのは、
1)普通の配列や変数となにがちがうのか?
2)利点がわからない。下手すると変数より使いにくい(配列名と項目名の両方がひつようなので)
3)順番に並んでるわけでもないのになぜ、「配列」なのか?
さっそく検索。
--------------------
「配列は同じキーワードでいくつもの値を格納できるのですが、
連想配列はキーワードに対して一つの値しか格納できません」
これは疑問1の回答になるけど、これって逆に使いにくくなっているんでは。。。。
--------------------
beginnersCGI
このページにある図はわかりやすかった。
当然ながら、小難しい理論と、プログラム部分は読み飛ばしているので、ちゃんと理解できたわけではないが、
「連想配列はフォームからの値の受け取りなどの項でも使われており、非常に便利なので・・・」
ということで、「フォーム」とうものと組み合わせると便利らしい。
使い道がないわけでもないんだなと思う。
あと疑問3の答えにもなっているかな。
ようは名前のついた箱がならんでいると考えれば、これも配列。
おそらく変数とちがって、コンピュータ内部での処理の仕方が配列と同じようになっているんだろう。
プログラムの説明などをみると「変数」も「連想配列」も「文字の集まり」なので、そのあたりのことがわかりにくかったのだろう。なんとなく納得。
--------------------
Flashで遊ぼう
「すごく便利な連想配列
なにかと重宝する連想配列。
price["apple"]=98;
price["orange"]=48;
price["banana"]=105;
こういう感じで配列の添え字のところが文字列になってるやつですね。
なにが便利って、連想配列ではなく単に配列でデータがあるとしたら、、、
fruit[0]="apple";
fruit[1]="orange";
fruit[2]="banana";
yen[0]=98;
yen[1]=48;
yen[2]=105;
と二つの配列があり、いざappleの値段が欲しい時、まずappleの添え字が何番か全数から調べ、そこから得た添え字により値段を得ることになります。
つまり、いちいち値段を調べるのにたくさんfor文なりwhile文をブンブン回す必要がでてきます。
データ数が少ないのならともかく、これが多くなると精神的にまずいよなあ~っと気分がブルーになってしまうわけです。え?私だけ?
それが連想配列だと最初に書いたようにダイレクトに得ることができるのです。(^^)v」
もう少し便利さがわかったような気がする。
●添え字(項目名)を使うことで直接その情報を得ることができる。(変数も同じじゃないのか?)
●For文、while文を使わなくて、簡単になるらしい。精神的にも良いらしい。
--------------------------
Perl/CGI研究室 'PERL-LABO'
フォームデータを連想配列化
「連想配列っていうのはPerlにもともと用意されている、「名前=値」というペアを格納するのに凄く便利な機能です。「名前=値」っていうと、フォームデータの形そのまんまですね。ですから、フォームデータを格納しておくのにもとても都合がいいんです。 」
なるほどフォームデータに便利なのか。。。今の自分には関係ないか。。。。
そろそろ考えるのが面倒になってきたので、連想配列を追求するのはここまで。
登録:
投稿 (Atom)