Pythonスタートブックにたどり着くまで

※この記事は12/23に書いたのですが、12/27に手違いで全文失念してしまいました。

原文も履歴も失われていたため、草稿を基に新たに書き起こしました。

そのため、オリジナルの内容とは大きく変わってしまいました。

前回「Pythonスタートブック＋Progate」は、たまたま自分には内容があっていたのと、タイミング的に良かったのだと思います。

Pythonの入門は、これまでも何度もトライしてきました。

ただ書籍ではなくWebサイトばかりです。

日本語の書籍を購入する際、近くの書店に置いてないので中身を確認する手段がないのと、　購入すると送料含めて1.5倍以上の値段になってしまうので手軽に手が出せるのは、Webサイトしかないのが理由です。

ネガティブな評価になっていますが、そもそも自分の目的に添わなかっただけで、そのサイト自体が悪いとは限りません。人によっては全然問題ないものも多いと思います。

Pythonを勉強するにあたり、自分がもっていた目的は以下のようなものです

１）オブジェクト指向がシンプルに理解できる。

２）Pythonの基本構文を必要最低限のシンプルな形で学べる

３）専門用語が少ない。

４）難易度が徐々に適切な程度で上がっていく。

初期のころは「Mayaで使う」という目的もありましたが、今はその目的は二次的

＜これまでの経歴＞

DigitalMatrix

MayaでのPython利用を目的としたチュートリアル。

元々はMelのチュートリアルが主流で、Melの勉強の時には大変お世話になったサイトです。

説明も丁寧でわかりやすい。

Melの時はなんでも目新しかったのですが、ある程度スクリプトをかけるようになっていたので、ジオメトリを作ったり並べたりのチュートリアルは退屈で興味が持続しなかった。

MelでできることをなぜわざわざPythonでやらなくてはいけないのか？

その意義が見いだせずやる気を失う。

Python公式チュートリアル

細かいことまで、詳しく説明。

正確に記述するために専門用語が多用される典型的なパターン。

基本的にはそれらの用語は理解しているものとして話は進んでいく。

ある程度プログラミング用語を理解している人なら、問題ないと思うが、自分には理解不能な言葉が多かった。

また一つの説明が多岐にわたるため、ある程度全体が理解できるようになるには時間がかかりすぎると思い、やめた。

Python -izm

有名なサイトですね。

サイトトップに「Python超入門」という書籍が紹介されているということはこの著者さんのサイトでしょうか。

「入門編」「基礎編」「応用編」とカテゴリ分けされていて、ステップ通りやっていけばかなりのことができるような気がします。

「基本構文」のエンコード宣言が自分の環境では正常動作せず、その後の例でもこの「エンコード宣言」が続けてつかわれているので、うまくいく気がせず、やる気がなくなった。

実用面では必要なのだとは思うが、初心者には、はっきり言って不要なようにも思う。

（Python2.7で日本語を使うには避けられないが…）

いきなり文字コードの処理で躓いては入り口で拒否されたような気分になる。

段階的に難易度の高い説明が初めのころにあったり、専門用語の説明が足りない気もした。

「萌えるmel読本の中の人が書くブログ」

MayaでのPython使用について書いていあるTips的解説

プログラム恐怖症のアーティストにもわかりように丁寧にステップ毎に書かれている。

Tips的内容なのでこれだけで入門になるかどうかはわからないが、ちょっとコマンドをつかってみるだけなら十分いける。

自分はもうすこし、プログラミングの基本がしりたかったので、ちょっと試しただけでやめてしまった。

Learn Python Visualy

インタラクティブ、かつ豊富なイラストレーションで学べるアプリということでこれなら頭固い自分でも理解できるのではないかと思い、Kickstarterで購入。

非常にきれいな構成になっているし、イラストもシンプルで美しい。

比喩で使われているイラストの必然性が理解できず、わかりづらく、すぐにやめてしまった。

著者がそのイラストで伝えいたい要素を読み手が必ずしも、著者と同じように理解するとは限らない。イラストが適切でなく解釈のしかたに、幅があると特ににその食い違いが大きくなるように思う。

普通の人ならすぐに理解できることが、理解できないのかもしれない、だとしたらADHD傾向があるのかな？？

ドットインストール

１つ１つのステップがシンプルでわかりやすい。

解説のお兄さんの声も心地よい。

動画だが説明をタイピングして文字で見せてくれるので聞き逃しがない。

ステップが細かすぎてある程度のことができるようになるには非常に時間がかかる気がした。

無料のステップでは、基本的な条件分岐の説明にも至らない。

CG業界でのスタンダードはPython2.7だがドットインストールはPython3.0なので、やってどうなる？という迷いが生じた。

Learn Python Hardway

個人的に、初心者は簡単なタイプミスや、基本構文を忘れたりしてエラーに悩まされることが多々あるので、そういったことは、繰り返し入力するだけで向上すると思う。

考える必要もなく、ただひたすらドリル形式で繰り返す訓練を自分は体力系と呼んでいる。

このサイトはそういう繰り返しのエクササイズがあるし、ほかのチュートリアルとは目の付け所が異なる。（良いかどうかではなく異質）

たとえあ論理演算を単語帳に書いて、その計算結果がTrueかFolseかを即答できるようにする訓練とか。

ステップごとに一つか二つのことをとりあげるだけでシンプルにしてあるのは好感がもてるが、説明は必要最低限のことしか書かれておらず、ググれが基本か。

場合によってはこのページを見ているよりも、ググっている時間が長かったりした。

エクササイズも、あまり面白いエクササイズではない。非常に時間がかかり、場合によっては１つのエクササイズに１週間をかけたりもする。

Pythonを習うというよりは、プログラマーの訓練という感じ。

Ex37で完全にやる気をなくした。

Paizaコード・ガールコレクション

楽しくできれば、長続きできると思いやってみたが、そもそも萌え系のアドベンチャーゲームに興味はないのでゲーム要素が邪魔でイライラしてくるという本末転倒な状況に。

肝心のコードの勉強はペースが遅く感じる。

－－－－－－－－－－－－－

他にもいろいろと試したものがあるのですが、今思い出せるのは以上です。

また思い出したら後日追加するかもしれません。

振り返ってみて思うのは飛行機に例えると、滑走路を走っているのが入門書を読んでいる段階で、その後ある程度自信をもって基本的なことができる段階に問うと断つするのが「離陸」だとするとその離陸に至るまでの時間が非常に重要に思います。

滑走路が凸凹（難解）だったり、長すぎたり（各段階のステップアップが適切に設定されていない）して離陸までに時間がかかりすぎると、途中で失速（やる気の喪失）になってしまい離陸に至ることができないように思います。

今回は今まで試してみたチュートリアルサイトで、なぜ自分の場合はうまくいかなかったのかを書いてみました。

人によっては、上記のサイトでも、全然問題ないかもしれませんが、私のようなケースもあるということで何らかの参考になればと思って書いてみました。

次回は学習者としての基本事項「動機」について書いてみたいと思っています。

Pythonスタートブック ＋ Progate

ひさしぶりの投稿です。
Melの勉強は、もうほとんどしてないのでブログ・タイトルも変えました。
（*Melとは３DCGソフト「Maya」で使われるスクリプト言語Maya Embedded Languageの頭文字です。Mayaのメニューから操作できるコマンドはほとんどがMelで実装されており、製作作業の効率化やより複雑な処理をするためにアーティストやエンジニアによって使われます。
MayaにPythonが実装されてからは徐々にPythonが一般化しつつあります。）

プログラミング言語でいうと、Arduinoとか、Processingを触っていましたが、最近はPython一択となりました。

そのきっかけとなった本が「Pythonスタートブック」だったのですが、なかなかの良書だったので感想含めて、おすすめな理由などを書いておきたいと思います。


Pythonの入門書の定番というと「Pythonスタートブック」と「みんなのPython」です。
どちらを選べばよいか悩む人も多いと思います。
  　　　  

「みんなのPython」はAmazonの書評で見て誤字誤植の多さが指摘されているとともに無料公開されている「みんなのPython　Webアプリ版」を少し読んでみたのですが、後述するように専門用語が多すぎる感じがしました。
（ちなみに最近、みんなのPython 第4版が出版されたようです。）
プログラミングをある程度経験している人でPythonをいじるなら「みんなのPython」でも問題ないと思います、むしろそのほうがまわりくどくないかもしれません。

ただ自分の場合はできるだけ小さなノイズは取り除いたものを理想としていました。
少し迷ったのですが、@spx808さんのおすすめもあり、「Pythonスタートブック」に決めました。
この本は自分が今まで読んだプログラミング言語入門書では一番良かったです。
その理由は以下の二点です。
１）専門用語をむやみに使わず、平易な言葉で書いてある
２）必要な専門用語は概念的理解ができるようにしている。

普通の入門書では説明がされなしで、専門用語が使われていたり、あっても数行でおわることがほとんどですが、専門用語は初心者には鬼門だと思っています。
専門用語がしっかりと把握できてないことで学習に大きな影を落とすことは少なくないです。

このことを理解してない入門書は意外と多いというか、ほとんどがそうだと言っても過言ではないかも。
読む側も、解説する側も、一冊ですべてを解説できるとも思ってないようですし、ほかのサイトや書籍でわからないことを補っていくという勉強は不可欠という暗黙の了解もあるような気がします。

解説する人はその業界で慣れているので、当たり前の前の前ぐらいの言葉なんでしょうけど、
初心者には、そうでないってことがわからなくなっている人も多いようで、温度差は感じます。

この本では複雑になりがちな解説を、要点を絞り、段階を踏んで解説してあるので、理解しやすいです。
自分はこの本のおかげで長年の謎であった「オブジェクト」について少し理解ができました。
「オブジェクト」を使いこなせるようになったわけではありませんが、しっぽはつかめた感じがします。


あと「たとえ話」がわかりやすかった。
読む側に伝わらない「たとえ」は、定義の揺らぎがあったりするのですが、何度読んでもつかみどころがない場合は、だいたいそこから読み進めることができなくなります。
この本では、そのあたりも注意深く「例」を選択している印象があります。


この本の前半は、初心者にも手取り足取り解説してくれます。
後半はやや加速しますがでてくる新しいコマンドをひとつひとつりかいしていけば9章までは理解しやすいと思います。
10章は数学的な知識が必要となる事例がでてくるので、そこはネットなどで調べる必要があるかもしれません。


＜補助教材＞
難点をいえば、説明が丁寧なのでその、理論的な部分の説明が多くなり実践的な部分は比較的弱い感じがします。
それを補うためにProgateというオンラインプログラミング学習サービスを利用しました。

似たようなオンラインサービスはたくさんあるのですがProgateを選んだのは
１）１つのステップの内容が簡単明瞭
２）スライド式
３）図解がわかりやすい

ステップをよく考慮して、一つ一つのステップで要点をしぼってあり、簡潔にまとめてあるのは
「スタートブック」と似ています。
ただ解説は必要最低限で、アプリを作る作業を通して学んでいくやり方でちょうど真逆で、お互いに足りないところを補ってくれます。
ダブっている部分もありますがそこは簡潔なので読むのは苦にならない程度なのもよいです。

順番としては「スタートブック」で勉強して「Progate」で復習というのが一番良いように思います。
逆もやってみましたが、自分の場合は理解が進むのは、まず「スタートブック」でした。

「スタートブック」でもコードを入力したりするのですが、本を読みながらやるのとみないでやってみなさいというのは大きな差があります。
カッコの使い方ひとつとっても、いざやるとなると細かなルールを覚えておらずエラーになったりします。
そのあたりを「Progate」で確認しながら学習することもできました。


ただループや分岐の解説がでてくるタイミングはやや異なります。
おおよその対応は以下のような感じです。
スタートブック１～３章　：　Progate PythonI
スタートブック４～５章　：　Progate PythonII

スタートブック６～９章　：　Progate PythonIII

（ProgatePythonIVは2017年公開予定）

PythonII以降は有料になりますがプラス会員なら一ヶ月で980円と安いです。

Progate自体の利点は開発環境を気にすることなくいつでも始められる。

動画ではなくスライドなので、見たい場所へのアクセスが素早くできる。

スライド1ページあたりの情報量が１～２点にしぼってあり、理解しやすい。よみやすい

イラストがわかりやすい。

問題点としては例題の文字列を一文字打ち間違えただけで、答えあわせはエラーになってしまうことです。

Print文で表示するだけならその内容は何であれ構文があっていれば通常はエラーになりません。

Progateでは回答の文字列は厳密に一致してないと不正解になりますが、それが「エラー」という形で帰ってくるので、最初の内は間違いをさがすのに見当違いなところばかりを見ていて時間がかかりました。

エラーが出たら構文だけでなく、出題との文字列の違いも確認したほうが良いです。

運営サポートにも連絡をしましたがそこは認識されているようで、近々修正されるかもしれません。

以上のように「Pythonスタートブック」＋「Progate」で勉強を進めましたが、個人的には非常に良かったです。

これでプログラムが、作れるようになったかというと、そんなことはありません。

まぁFor文やIf文をつかった10数行のものならできますが、きちんとしたものを作れるようになるには、まだまだいろいろな方面の勉強が必要です。
今は別の方法で、そのあたりを強化していっています。

「Pythonスタートブック」＋「Progate」からの一番の成果は、これまで見てもよくわからなかった、Webや書籍にあるPythonに関する解説が理解できるようになったことでしょうか。

少しづつですが前に進むようになったという感じです。

そんなわけで、「Pythonスタートブック」おすすめです。

次回「Pythonスタートブックにたどり着くまで」は以前にやってきた（そして失敗した）「Python」の勉強履歴を公開します。

 

北田モデリング・チャレンジ サイコロ編

＜前置き＞

ダブルネガティブでご活躍のモデラー、北田さんによるモデリングチャレンジ「サイコロ編」。

今回これに挑戦させて頂きました。

http://eijikitada.blogspot.com/2012/05/cg4.html

この課題はすでに2年以上前にだされたものですが、なぜ今更ながらのチャレンジなのか？

実は、ここ2年ほどの間にモデラーとしての仕事をいくつか経験する中で、モデリングに関する知識の無さと、要領の悪さが致命的だと実感したからです。

時間をかければある程度の仕事はこなせるのですが、それは素人のやり方で仕事として好きなだけ時間掛けていては、いまの時代、自分を殺すか会社を殺してしまいますｗ

殺すってのは文字通り、睡眠時間を削り健康を害することになることでもあり、固定給の場合、時間当たりの単価は非常に悪い物になります。

これらは両方ともフリーランスとしては深刻な問題で、致命的というのはそういう意味です。

会社で仕事をしているとしても、やはり同じ結果を得るには人件費がかかるということになります。

同じレベルの物を作れるなら、早くできても単価が高い人間か、時間がかかるけど安い人間かと言うことになります。

さきほど「今の時代」と書きましたが、CG業界は単価が安くても質の良い結果をだせる人が増えてきています。

そんな中で、競争力を保つことができなければ職自体が得られないって事にもなりかねませんね。

＜課題をやる上での目的＞

何かを学ぶときには、その必要性を感じているときに学ぶのは一番、多くの事を吸収できると思います。

実はそういう状態になるまで待ってからやってみようと思っていたのもあります。

今回、目的としていたのはプロのモデラーがどういったことに気を配ってやっているのかを、見いだし、心に植え付けること。

これ言葉で書くと簡単ですが「記憶」しようとすると忘れます、実際何度も聞いてますが出来てません（汗）、この課題を終えた後、モデリングしようとするときには、いつもそれをこころがけて「いる」ようになるのが、第一の目的でした。

とくにどういった順番で作っていくのかという、設計図的な部分。

モデリングはこの部分で、時間のかかりかたがかなり違ってくるように思います。

いわば素人からの脱皮への足がかりをつかむことが目的です。

まぁさすがに、すでにモデリングの経験もあるので、エッジループとか、その他のツールの使い方に関してはさほど問題はありません。

今回この課題にチャレンジしたのは別にサイコロが作れないからとか作りたいとかそういうものではありません、その作業の裏にある思想をたどることができるからです。

サイコロはシンプルな形状なので、その思想が、わかりやすいというのもあります。

単に同じ物作るだけならもっと楽しい物がたくさんあります（笑）

＜How＞

なにかを心に植え付けるには、やはり感動というか強い実感があると効果的です。

「あぁそうか！」とか「おおっ！」と思わず声に出てしまうような経験をするとその事柄はなかなか忘れないですよね。

このサイコロの課題はすでに北田さんがブログ上で解答を後悔しており、そこで注意するべき事、重要な事など多くのノウハウが公開されています。

それを読むだけでも「おおっ」って思うこともあるのですが、概念的な説明ってのは具体性を伴わないとその時感動しても、意外とすぐに忘れてしまいます。

実践的なことは行動を伴わないで文章だけで読むとそれもまた忘れてしまいがちです。

全てを忘れてしまうことはないとは思いますが、少なくとも応用性が限定されたものになってしまいます。

この課題の解答では、モデリングのスキル、サイコロを作るための手順を説明しているだけではなく、「モデリングとはどのような作業なのか？」という根本的な部分まで説明されています。

読むときに、その部分をより吸収するためにはやはり同レベルの問題意識を持った上で読む事が必要となってきます。

具体的には、まず自らの（できるかぎり最大限の）力でモデリングしてみる。

そのモデリングの過程について、細かなデータをとっておく。

そしてそれについて、北田さんの作業と比較して無駄な点、効率化できる点などを洗い出す。

これにより自分の力の及ぶ範囲、その自分の意識を超えた所にある工夫に気がつくことができると考えました。

そのため、ブログにある説明や、ワイヤフレームはほとんど見ないで、まず今の自分ならどのように作っていくかを考えて作業を進めてみました。

ちなみに形状の細かな違いは、何をリファレンスにするのかによってことなるので角の丸みとかベベルの具合とか穴の大きさとかは、Googleで見つけたサイコロの画像を参考にしており、北田さんの見本モデルとは異なります。

＜作業＞

自分がとったアプローチは以下の順序です。

１）穴と面とのつながり、ベベルの具合を確認しながらベースとなる穴を一つ作る

２）各面を作成（穴は「１」を流用）

３）各面の相互接続のトポロジを修正する（必要に応じて各面のトポロジを修正する）

モデリングは1の目から開始して以下の順序です。

1→4→6→5→3→2

「1の目」を選んだのは大きいので作りやすい、そしてデュプリケートしていけば増やすのが簡単だと思ったからです。

もう一つの理由は、シンプルなので面の分割をそれほど増やさなくて良い、すなわちローレゾに保てるということです。

（この時点で、出来る限りローレゾにするのが一番良い事だと考えていました）

穴の部分は六角形と八角形を試してみましたが、穴の形の良い八角形にすることにしました。

まずエッジを落としたキューブを作成し、そこに穴をつくりました。

これでできた「1の目」の面が下図になります。

ここまでの作業時間は、試行錯誤の作り直しも含めて40分ぐらい。

（画像はクリックで拡大）

この穴を他の面を作るのに流用して作ったのが以下のものになります。

各面のサイズが微妙に違うのはスクリーンキャプチャの問題で実際は同じサイズです。

また縮小したため一部の線が消えてしまっています。

面と面とのつながりは、各面のトポロジがどのように変化していくのか推測が出来なかったのと、

そのあたりのつながりを考えながら作業していると、時間がかかりすぎるので各面独立して最初に作りあとからトポロジの整合性をとることにしました。

この時点では、各面のトポロジは独立しており他面との接続部分は考えないことにしています。

作業時間は一つの面につき平均15分です。

（画像はクリックで拡大）

「6の目」までは、トポロジーも複雑ではなく、面の分割を増やすだけで対応可能だったので、ささっと片付けた感じ。

「6の目」の後に「5の目」をやっているのは、5を片付ければ3と2の目はそこからすぐに作る事ができるから。

各面ができてから、相互の面の接する部分のトポロジーをつなげていく。

6と5、1と5、5と2、1と2、1と4、1と3、6と3

その過程でエッジの数が合わず多角形になっている事があり、修正する必要がありました。
 れで作成した自分のサイコロのトポロジーが下図です。

この修正作業に要した時間は1時間20分

（画像はクリックで拡大）

「1の目」は複雑になり、2や5の目も上下でエッジの数が異なっています。

自分でやってて、「これじゃない」感を感じてます（苦笑）。

ここまでの合計作業時間は3時間20分

全てのポリゴンはクオッドです。

＜まずは自分の作業を反省してみる＞

まずは一つの面を作成後、もう一度トポロジを変更するためにいろいろとポリゴンの流れを変えています。

いわば作り直しに近いことをしているわけです。

仕事をする上で結果を得るための作業を、2度別のやり方で繰り返すのは効率が良いとは言えません。

もう一つは、行き当たりばったりな面。

最初から最後まできちんとした計画があってやっているとは言えません。

むしろどうやってよいのか分からないので、とりあえず手を付けて問題があったら対処するという米国式ですｗ

＜答え合わせ＞

いよいよ答え合わせです。

北田さんもおっしゃっているように、モデリングにはこれといって正解があるわけではないのですが、より効率的、より効果的であれば、良いというのは間違いないことです。

そういう点では、北田さんの見本回答は勉強になる事がたくさんあります。

※ここからはネタバレになるので、この課題にチャレンジしようと思っている方は、先にチャレンジを終えてから読んだほうがよいかもしれません。

その場合は、この「＜答え合わせ＞」はとばして「＜終わりに＞」へ進んでください。

この問題の答えは北田さんのブログに詳細が書かれています。

http://eijikitada.blogspot.com/2012/03/cg.html

北田さんの回答を読んでみて気がついたのは、最初のステップから大きく違うという点です。

北田さんは「1の目」は個別に考え、他の目はすべて共通点が多いので「5の目」から発展させて作ることができると考えています。

自分は工業製品や、印刷関係の仕事をしていた関係か、かなり細かな事にこだわる傾向があります。

たとえばサイコロの目などだと1以外の目はサイズ的に同じだと判断するかもしれませんが、

その目で見たときにバランスが取れるようにサイズは一様ではないというふうに考えてしまいます。

たとえばロゴなどのの文字間隔は一様ではなく、間隔が同じように見えるように微調整しますが、そんな間隔です。

工業製品は、会社によってアプローチが違うので一様である場合と、一様でない場合があり得ます。

ただ自分の場合はこの細かなこだわりが、実質的に目に見える効果としてあらわれないこともあり、結局作業を複雑にしてしまうだけで終わることがあります。

今回もそのパターンでした...orz

まぁこの辺りは最初にどう捉えるかという事でもありますが、たとえそういった微妙な調整が必要だとしても先に北田さんのやり方で作って後で調整したほうが圧倒的に早くて楽です。

そして下図は北田さんのブログから許可頂いて転載させていただいたものですが、（北田さんありがとうございます）トポロジーがビックリするほど綺麗。

複雑な要素はありません。

次に気がついたことは、北田さんは一つの面を作るのでも、以下に少ない手順で作れるかを絶えず考えています。

たとえば「5の面」ですが自分だとそれぞれの穴をデュプリケートして5回同じような作業を繰り返して作ってしまいます。

でも北田さんのやり方では面の1/4を作りそれをミラーリングで一気に仕上げてしまう。

「1の面」だと自分だと一気に全体を作ろうとします、北田さんはこれも1/4を作りミラーリングで仕上げています。

一面だけ作るなら、そんなに時間差はないかもしれませんが、こういう考え方が積もり積もると大きな時間差になるだろうなというのは容易に想像がつきます。

北田さんも述べているようにこれがただ一つの正解というわけではないとお思いますが、自分の目的には十分すぎるほどの回答例でした。

「どうすれば早く、綺麗に作れるのか？それを常に考えることが重要です。」とおっしゃっていますが、このモデリングチャレンジで、それを実際にどのように考えて行くのか、その思考過程の違いを見ることが出来ました。

自分の場合は、思考停止して、行き当たりばったりになってしまっています。

北田さんの場合はほぼ最終的な状態までのステップが、見える状態で作業がすすめられています。

気付いたからと言ってすぐに、同じレベル出作業が出来るようになるわけではないのですが、この辺りの思考の違いってのをはっきりと自覚することができたのは、自分にとっても大きな収穫でした。

ちなみにこの解答のとおりに自分でもやってみたところ作業時間は大幅に短縮して40分でした。

3時間20分が40分。五分の一になりました。

トポロジの違いは下図をみれば一目瞭然です。

同じ左上のポリゴンからのポリゴンの流れを選択してみると北田さんのは横一列。

自分のは迷走していますｗ

（画像はクリックで拡大）

この理由の一つは穴の底部分の形状が影響しています。小さな所ですが、そういうところも大きく影響をしていると言うことが分かりますね。

自分のやり方（図の右側）を見ると「5の目」の中心は北田さんと同じですが、他の四つは斜めになっていますね。統一性にも掛けています。

＜終わりに＞

答えを見て、正直なんだそんな簡単なやり方で良いのか？と思いましたが、全体の複雑性をいかにシンプルにして、少ない手順でできるようにするのかという視点は自分にかけていたものだと思います。

自分のやり方は、アナログ的思考に裏付けされていますが、デジタルのツールの利点を生かし切れていません。

アナログの連続し、かつランダムなデータをサンプリングし、規則性のある情報にまとめていくというのはプログラミング的な思考でもあります。

まさかモデリングで、そこまで考えてやらなくてはいけないとは思いませんでした。

そしてこの弱点は、先に北田さんの回答を見てから真似していただけでは、はっきりと意識することなしに通り過ぎていたかも知れません。

Aruduinoはじめました。

ここ1週間ほど、Aruduinoを触っています。
あーついにCGあきらめたのかとかいわれそうですが、そうではありません。
CGに必要なプログラミングの勉強へのモチベーション維持のための導入です。
（半分趣味ですがｗ）

始めてコンピュータに興味を持ったのはロボットを作りたいと小学生のときに思った時です。
小学3-4年製のころだったと思うのですが学校の図書館でコンピュータのしくみが書かれた本で
磁気コアメモリの説明を読んだ記憶があります。
当時はちんぷんかんぷんでしたがｗ

その後、高校生になりFM-7などを手に入れ写経などしてましたが、ずーっと外部ハードをコントロールする機会はなく、いつしかその夢も、マンガや映画を含む様々な仮想世界のメディアにかかわる中で、いつしか心の片隅に埋もれていってしまいました。

いや一度だけときめいたことがありました。

当時購入していたOh!FMというコンピューター雑誌の中で、ロボットアームの自作記事があり、これがやりたい！と思ったのですが、まぁやっている内容が高度すぎるのと金もないので自分には無理と早々にあきらめました。
今思い出すと、忘れていたようでずっとロボットをやってみたかったんだろうなと思いますｗ


さて、Arduinoの存在自体は以前から知っていましたが、昨年、入門用キットのInsectBot Miniを発見、いろいろ遊べそうだし、安いし、よさげだなと思って購入しました。

これは切手サイズのArduino Leonardo互換機「Beetle」を使います。


この簡単なロボットを作るための全部品、Beetle、サーボ、センサ、その他がついたキットで約$29と格安。
このBeetleだけに限って言えば1個あたり$7という安さです。



＜なぜArduinoか？＞
将来的に子供がコンピュータを学習するときにArduinoを使った電子工作からやらせようと思っていました。
子供のプログラミング教育というとグラフィックスが多用されたアニメーションを使ったり、Wordやエクセルを勉強したりとかそういうことが多いんですが、それって何か違うんじゃない？といつも疑問を持っていました。

といって自分はプログラミングの知識がそれほどあるわけでもないので、何が間違っているかもはっきりとは言えない。

ひとつだけ言えるのは「仮想現実」


モニターで起きていることはすべて「仮想現実」なんですよね。
現在の子供は自分の親の世代と比較すると、かなり現実から離れた世界にいる。
それがいいか悪いかは別として、現実のことを充分に理解する前から仮想現実だけですごすってのは、何か1ステップとばしているような気がします。
人と実際に話をすることで人の感情や考えがわかり、 海に飛び込むことで水の冷たさや浮遊感の楽しさを実感する。
 写真で見た海がたのしそう、CGゲームの海の揺れがおもしろい。
そういったこととは異なる「実感」があるからこそ、本当に人に役に立つ事を考えられるようになるのではないかということです。

 そして、実感を伴ってコンピュータの操作を学ぶには、やはり現実世界の様々なものとかかわりあうフィジカルな部分が重要。
現時点で、それが簡単にできて事例も多い物がArduino。
教育関連の資料も充実してます。


もちろんArduinoのボードだけでプログラミングが出来るわけでないので別途コンピューターは必要になりますが、基本RaspberryPiのようなものでいいかなと思ってます。

さて子供が勉強を始めたとき、何か問題にぶつかったら最初に頼る者は親です。
子供は、ささっと解決しないと、興味を失いかねません。
さらに 特定のカリキュラムをこなしているのではなければその道も親が作ってやる必要があります。
少なくとも、特定のカリキュラムに参加するのであれば それが子供にあったものなのかどうかそれを判断する目がなくてはいけません。

そういったことができるようになるには、自分のペースだと2年ぐらいかかりそうなので、今からでもやっておかないと子供が始めるときに間に合わないなと思ったのがArduinoを今始めた理由の一つです。


もう一つの理由は自分のプログラミングの勉強に活かすこと。

自分はプログラミングの勉強をしていても、すぐに飽きてしまう事が多いんですよね。
細かな事をじっくりと考えて、解決までみちびくという根気が続かないことが多く、けっこう深刻な問題です。

CG仲間には怒られそうですが、そもそも画面に絵を描いてもあまり感動がないんですよね。
誤解を招きますがすばらしい映像を作る人はもちろん居ます、ここで言っているのは自分が作っているものですｗ

やっぱり現実の物に変化をもたらすもののほうが興味が続く。

仮想現実よりも現実！

そういった理由などがありArduinoをさわってみることにしました。




＜＜InsectBot Mini＞＞
このキットは非常に簡単でハンダ付けも含めて1時間もあれば作る事が出来てしまいます。
キット自体は9-10歳ぐらいの子供なら一人でもできるかもしれません。
キットの箱には6歳以上と書かれていますが6歳ではさすがに無理だと思いました。
しかし一番問題だったのは、Arduinoのプログラミングの部分でした。
説明書には、このキットを動かすための最低限の事しか書かれておらず、
ArduinoIDEの使い方などは書かれていません。
入門者向けのキットとは言っても、学習のための懇切丁寧なマニュアルではないのです。

まぁよく考えてみれば当たり前なのですが、Arduino入門ではなくてロボット作成のハード面での入門キットということですね。
Aruduino含めての入門キットで、丁寧な説明書がついていると勝手に期待していました。

付属のArduino「Beetle」はピンの形状も違い一般的なWebでみつかる事例でつかわれているArduinoとは大きく違います。
ある程度なれたら理解はできるんでしょうが、まったく触ったことがない初心者ではそのギャップをうめながら理解するのは難しすぎます。

これは駄目だと思い急遽、ArduinoUNOをRadioShackから買ってきました。

InsectBotは少し動いただけですが、動きも気に入らないし、パーツとしてつかわれる日が来るまでこのまま眠ることになるでしょうｗ


＜＜ArduinoUNO ＞＞
 
今のところ、やってみたのはLチカとブザーならしたぐらいで、なにも複雑なことはやってません。
LチカってのはLEDをチカチカ点滅させることです。
Arduinoを始めて使う人はだいたいみんなやることです。


でも、楽しいです。
仮想世界でちまちまやっているのとは違って簡単なことでも、がっつり反応がかえってくるのでおもしろいです。



＜＜プログラミングの勉強にどのように役に立ったか？＞＞
まだ一週間ほどしか触ってないので、たいしたことは言えませんが以下のような事を感じています。


１）Processingと相互に使う事で理解が深まる。
ArduinoIDEはハードのコントロールのための独自の関数を多用しますが、基本的にはProcessingと同じ言語です、そのため導入もスムースで、ArduinoIDEだけを使っているからといってProcessingの使い方を忘れることはありません。（CG的処理は忘れることはあるかも知れませんが）

実際にはArduinoの傍らでProcessingを立ち上げて計算結果の確認に使っています。
それによりArduinoとProcessingの違いをいつも意識することになり、混乱はほとんどありません。
Arduinoを触っている内にProcessingのスキルも向上し、その延長でプロシージャルなCGスキルも向上させたいと思っています。
 （注：「ArduinoとProcessingは似ているようで違う。混乱する」という方もいます。
自分の場合は、その違いを意識することで、「混乱しないようにしているので問題がない」 と言った方が正確です。）

　　

２）一つの事柄を解決までもっていくモチベーションが違うCGのスクリプトってちゃんとした事をやろうとすると、結構複雑なのでやることが多く、道も長くてくじけやすいですが、Arduinoは目的をしぼりやすい上に、その目的で満足できやすい。

CGで入門用の簡単なスクリプト作っても、自分はまだこんなことしかできないんだなぁというふうに、なかなか達成感がえられなかったのですが、Arduinoだと簡単なことでもある程度の達成感がある。

やっていることがまだ単純だってのもあるんですが、やはり「現実世界」に関わっていけるってのは大きです。　　
同じようなプログラム（スクリプト）作っても、Mayaの画面の中でランバートシェーダーのスフィア動かしても感動は薄い。
どれだシミュレーションやったところで現実世界の髪の毛一本うごかせない。
でもLEDだと点滅しているだけで、非常に明確で心理的インパクトがある。
サーボモータ動かせば、こんなことやあんなんことと想像力も広がります。
やはり現実のもつパワーはでかいなと思います。
ArduinoはC/C++のスキルも生かせるようです、それらの言語を勉強しようという意欲はますます高まりました。

　　

３）プログラムをシンプルにするという考え
 Melスクリプトをやっているときは処理を軽くするとかあまり考えてなかったんですが、最近いろいろな人と話をしたり、書籍「プログラムはこうして作られる」 を読んだりしている中で、「処理を軽くする」と言うのはプログラミングにおいて非常に重要な位置を占めることだなということを理解しはじめました。

Arduinoはメモリ制限もあり、あまり巨大なプログラムは使えません。
またハードの反応速度なども考慮したプログラムが必要な事もあり、効率化に関してよい勉強になるのではないかと思いました。
「プログラムはこうして・・・」はゲーム業界の方が書いていると言うこともあり、非常にハードを意識するプログラミングの説明がされています。
そういう意味では、Arduinoも近い考え方があり、実際書籍に書いてあったとおりの考え方がつかわれていたりしました。
そのためこの本の内容がぐっと身近に感じられました。
この本は本当、良書です。



４）オブジェクト指向

Processing/Aruduinoではオブジェクト指向のプログラミングも出来るようです。
参考：http://yoppa.org/proga10/1190.html
（注：　Aruduinoでも使えると思うのですが未確認、もちろんC++を使えば出来ます）
C++を勉強するころには、その経験は生きてくると期待。



＜＜これから＞＞
まずは単純な1つのものを動作させるところから、これはLEDの点滅とかサーボモータを動かすとかそういうことですね。
 LEDの点滅一つとってもいろいろなやり方が、見せ方があります。

ある程度馴れたら複数のものを同時に動かす。
これはLEDグリッドとかLEDキューブとか。センサーによる自動制御とか。
こういうことをやるときにオブジェクト指向なプログラミングは役に立つんじゃないかなと思っています。

次のステップとしてはAruduinoをProcessingと連携させていきたいと考えています。
これはどういうことかというと、たとえば温度センサーでProcessingのグラフィックスの色を変化させるとか、Processingで作ったGUIからLEDの調光をするとか。
現実世界との連携ができるようになります。

将来的にはLeapMotionとか、Kinectのようなシステムとの連携（たぶんそうなるとPCを介在してArduinoをコントロールするような感じになるんですかね）、ロボットの作成なども、できたらうれしいですね。

でも、そういった複雑なことができなくても、たのしそうな電子工作はたくさんあります。
「自由な発想」 そういう部分をリハビリするのににも役立ちそうです。

あれ？プログラミングの勉強から離れていってる？
否定はしませんがｗ複雑なことを本格的にやろうと思えば（たぶん）CやC++が必要になってきます。
まぁそういった勉強を避けてもArduinoは使えるんでしょうけど、自分はCやC++を勉強するための動機付けとして積極的に使っていきたいと思っています。