せっかくお問い合わせ下さったのに、こちらから何の応答も無く、大変ご不快な思いをさせてしまった方々が多数いらっしゃった可能性がございます。
責任はホームページの維持管理を怠っていた当方にございます。心よりお詫び申し上げます。大変申し訳ございませんでした。
当教室のお問い合わせフォームは、レンタルをさせて頂いているロリポップ様のメールサーバーからGmailに転送することで運用しておりました。その際にGmail の迷惑メールやスパムメールを防止する「550-5.7.26 」と呼ばれるコードでメールの送付が止められていた様子です。
修繕する際に情報を集めようと少し検索を致しましたら同様の症状に出逢われていた方が多数いらっしゃいました。
どうも2022年の春先から起こっていた症状のようです。
なんと言っても春と言えば皆さん何か始めてみよう！と思われる季節ですから、うちの教室も毎年たくさんお問い合わせを頂いていたのですが、今年は全然無かったものですから、「どうしたのかなぁ。。コロナのせいかなぁ。。。」などなど思いつつも、現在の生徒様のレッスンとその準備に追われ、きちんと原因を考えることを怠っていました。
お問い合わせ頂いていた方々には本当に面目ありません。大変な不注意であったと反省しております。
うちの教室はオンラインのプライベート・レッスンで、基本的に1日おひとりさまだけ見させて頂く形でレッスンを行なっています。
講師は私一人ですので、同時期に見させて頂ける生徒様の数をかなり限らせて頂くことになり、毎年春から夏にかけては沢山のお問合せを頂き、タイミングによっては少し待って頂くこともございました。僕がもう1人いればと思うこともしばしばでございます。
しかし実は今現在、若干名ですが空きがございます。
もしもクリエイティブ・コーディングに取り組んでみよう！、最近話題のジェネラティブ・アートを自分もやってみたい！、などなどご興味をお持ちの方がいらっしゃいましたら、是非ホームページの（今しがた修理完了いたしました m(_ _)m ）お問い合わせフォームから、お気軽にご連絡下さいませ。
]]>こんにちは、「クリエイティブ・コード・サロン」の主人です。この「クリエイティブ・コード・サロン」の「サロン」の由来について少し前の記事で書かせていただきました。今回は「クリエイティブ・コード」についてです。
「数によるデザイン」に始まるクリエイティブ・コーディング
「クリエイティブ・コード」。「クリエイティブ・コーディング」。これは僕が作った言葉ではなく、Googleなどで検索するとすぐ分かる通り、今では広く使われている言葉です。厳密な定義があるわけではないのですが、アート+テクノロジーによる創作の世界で使われる言葉で、デジタル・テクノロジー、特にプログラミングによって創造的な表現を生みだす「運動」を指しています。
何がクリエイティブで、何がそうでないのか。これは主観に依存します。主観の数だけ何が「クリエイティブ・コード」かを決める基準があります。逆に言えば、「クリエイティブ・コード」は主観を重視させる言葉なので、そのことがコードによって自分の考えを表現するという意味を暗示していると言えます。
一方、人間の普遍的なテーマ、人間のクリエイティビティにつながる言葉であると同時に、「クリエイティブ・コード」は、もうひとつ特別な意味を含んでいます。
「クリエイティブ・コード」という言葉が明確に世に出たのは、ジョン・マエダ先生の著書『Creative Code: Aesthetics + Computation』(2004)だろうと思います。ジョン・マエダ先生はMITのMedia LaboratoryのAesthetics and Computation Groupを率い、アーティストやデザイナーが、コンピュータ・サイエンスやプログラミングの知識がなくても簡単なコードを書くことによって創作することができるアプリケーション『Design by Numbers』を1999年に発表します。その成果は2001年に書籍でも出版されます。（「だろう」と言いましたのは、マエダ先生がこのプロジェクトを始められたのが1990年代の前半なので、正確には1990〜2004年の間のいつかだろうという意味です。）
Design by Numbers。どんなものだったかと言いますと、簡単なコードを書くことでスクリーンに単純な図形を描くことのできるようにしたプログラムで、このビデオで分かる通り、プログラミングの知識がないアーティストやデザイナーでもコンピュータを創作のツールにすることができることを目指したものでした。
この『Design by Numbers』のコンセプトは、その後の世代に多大な影響を与え続けています。まず『Design by Numbers』の開発にあたった2人の大学院生、ケーシー・リース先生とベン・フライさんが、2001年から『Processing』の開発を始めます。ProcessingはDesign by Numbersと同じコンセプト・同じ言語Javaをベースに、よりパワフルな制作環境をアーティストに与えるようにしたもので、Design by Numbersの正当な発展形と言えます。
また、ザカリー・リーバーマンさんを中心に、Processingと全く同じ形式で、c++をベースにして2005年から開発されているのが『openFrameworks』です。
この他にも同じ考え方をベースにしたプログラミングの開発環境があらゆるプログラミング言語をベースにして数多く作られ続けています。このように、Design by Numbersにダイレクトに由来するProcessingやopenFrameworksを代表として、「アーティストやデザイナーが創作に使えるプログラミング・ツールを作る」という考え方を共有し、そうしたツールで創作活動を行うことが特に、「クリエイティブ・コーディング」と呼ばれています。
クリエイティブ・コーディングの起源
Logoによるタートル・グラフィックス（1967）
しかし、Design by Numbersはクリエイティブ・コーディングの起源のひとつであっても、全てではありません。なぜならコンピュータはその草創期からずっとアーティストの創作のツールとして捉えられてきたからです。
ジョン・マエダさんが所属していた、MIT Media Lab。1985年にそれを創設したのは、草創期のCADの研究者で建築家のニコラス・ネグロポンテ先生でした。ネグロポンテ先生は『Architecture Machine』というコンセプトのもと、1967年にMITでArchitecture Machine Groupを設立し、人とコンピュータのインタラクションを通して環境がデザインされるシステム、いわばAIによるCADを提案しました。そのArchitecture Machine Groupを母体に設立されたのがMedia Labなのです。例えば、MITの建築学部とMedia Labをまたいで活動された、建築家ウィリアム・J・ミッチェル先生による、Shape Grammerを用いて建築デザインをコンピュータに生成させる研究はよく知られています。
CAD、つまりコンピュータにドローイング=図面を描かせることと、コードによってドローイングを創作するDesign by Numbersに何の共通点があるのか、疑問に思われるかもしれません。それはコンピュータで絵を描くというと、マウスや最近であればスタイラス・ペンで、つまり仮想的な「手」で描くことをつい想像してしまうからです。現在普及しているほとんどのCADはそうした「手」で描く以外に、コマンド・ラインに命令をタイプすることでも描くことができるようになっています。例えば、現在世界のシェアの大半を支配しているAutoCadで線を描くコマンドはこんな感じになります。
LINE
Specify first point: 0,0
Specify next point or [Undo]: 20,20
これがDesign by Numbersであれば次のようになります。
paper 0
pen 100
line 0 0 20 20
別にDesign by NumbersがAutoCadの単なる模倣だと言っているわけではありません。ただしCADの開発がDesign by Numbersよりずっと以前に始まっていたことから考えると、そうした周辺領域で得られた果実を、「コードで絵を描く」というコンセプトで煎じつめていったものが、Design by Numbersだったとは言えると思います。
こうしたCAD以外にもMedia Labではコンピュータにドローイングをさせる研究がなされてきました。例えば、タートル・グラフィックス、タートル（今でいうカーソル）を動かすことによって、その軌跡でドローイングを描くLogo(1967)の発展版として、エージェント・システムを用いたシミュレーションを画面の上に鮮やかに描き出すStarLogoもやはり、Media Labのミッチェル・レズニック先生によって開発されたものです。さらにレズニック先生のグループはその後、現在日本でもこどもたちに大変人気なScratchを開発されますが、このScratchの中にも、ペンと名前は変わってはいますが、タートル・グラフィックスのシステムがきちんと備わっています。
このようにMedia Labの歴史をたどっただけでも、Design by Numbers,
またそれに続いたProcessingやopenFrameworksが、コンピュータの草創期から始まった、コンピュータをクリエイティブに使うための先人達の試みと、連続したものであることが分かってくると思います。さらに言えば、MITのようなアカデミックな城の外を見ても、例えば1980年前後に爆発的に広がったゲームやコンピュータ・ミュージックを考えれば、そしてゲームも音楽もどちらも「コード」による「クリエイティブ」な創作であることを考えれば、「クリエイティブ・コーディング」を何か特定のアプリケーション、何か特定の分野、何か特定の人たちにつながった運動と捉えるのは、アーティストたちが自己を希少化するあまりにデジタル・テクノロジーの歴史を矮小化しすぎていて、むしろ、デジタル・テクノロジーを創造的に使うこと、つまり人間のより普遍的なクリエイティビティをデジタル・テクノロジーを通して表現することとして捉えなければ、その歴史的な意義を損なってしまうように思います。
みんなに広がるクリエイティブ・コーディング
BBC micro:bit（2015-）– BBCが1980sのコンピュータ教育を牽引したBBC Microの再来を期待するマイクロ・コントローラ
このように「クリエイティブ・コーディング」を、2000年前後に始まった特定のアプリケーションの開発や、それが使われた特定の分野と切り離し、もっと大きな考え方、デジタル・テクノロジーを創造的に使うことと考えると、今現在起きていることとのつながりも容易に見つけることができます。
例えば、最近のいわゆるMakerムーブメント。僕はこれを見ると、コンピュータの草創期に、それで何ができるか未だ分からず、ワクワクと創造力を発揮していたことへのある種の郷愁のようなものなのかと感じることがあります。例えばArduinoを利用したポケット・コンピュータやゲームボーイのコピーマシンがインディーズのメーカーによって発売されたり、8bitゲームに似せたビットマップのキャラクターのゲームやゲームボーイのミュージック・チップをハッキングして作られたチップ・チューン・ミュージックが流行したり、といった現象にある種のセンチメンタリズムを感じます。
Arduino（2005-）– Makerムーブメントの「電子工作部門」の代表
VVVVVV（Terry Cavanagh, 2010）– 1980sのコモドール64 8bit コンピュータ・ゲームのグラフィック・スタイルとチップ・チューン・ミュージックの融合
僕はこのムーブメントに否定的では全くなく、逆にとても共感しています。でもそれはあくまでも草創期の「熱さ」を再体験し、次の創作に向かうための助走として捉えるべきだと思っています。今のテクノロジーで昔の草創期をコピーした後は、今のテクノロジーで同じ熱さを再び起こすこと、それが大事なんだろうと思っています。
先日、予定より半年遅れで、UKのBBCによる壮大なデジタル・テクノロジーの教育「実験」がようやく始まりました。『micro:bit』というマイクロ・コントローラーを全国100万人の子供に無償配布することで、一気に次世代のIoT時代のデジタル・カルチャーを牽引する計画です。その実験を企画したメンバーのインタビューがとても面白く、例えばこんな話がありました– 『Windows』は、コンピュータを創造的に使う態度を180度回頭させてしまった、Windowsは人をコンピュータの創り手ではなく使い手にしてしまったんだ。それをこのmicro:bitでもう一度反転させたいんだ–。
この考え方は、ジョン・マエダさんが『Design by Numbers』を作ったコンセプト、コンピュータをエンジニアだけは自由に使えるけれども一般の人にはただのルーチン・ワークのための退屈な機械から、アーティストが使う創造的な機械へと反転させたいんだ、という意志と全く同じです。ただし大きく違うことも起きています。それはDesign by Numbersの場合は、デジタル・テクノロジーで創造性を発揮すると考えられていた対象はアーティストやデザイナーだけでした。それがmicro:bitの場合は、すべてのこどもたち、今後の展開を考えればそれはすべての人が対象と考えられていることです。つまりクリエイティブ・コーディングとは、すべてのひとが自分の考えを、コードで表現すること、すでにそう言える段階にまで発展してきているのが現在だと思います。
みんながコードで自分を表現する日常
それでは、みんながコードで自分を表現し始めたらどんなことが僕たちの日常に起こっていくのでしょうか？例えば、
昨日までは保育園で先生に絵本を読み聞かせてもらっていたこどもたちが、
明日にはScratchで作った動く絵本を先生に発表しているかもしれない。
昨日までは水彩で絵手紙を描いていたご老人たちが、
明日にはJavaScriptで動く鯉や草花を描いたホームページのリンクをメールしているかもしれない。
昨日までは誰も見てくれないだんなさんへのグチをつぶやいていた奥さまたちが、
明日にはiPhoneでコーディングしたGifアニメをTweetして10万リツイートされて通知が鳴り止まないかもしれない。
昨日まではAAA企業に買わされたゲームに明け暮れていたゲーマーたちも、
明日からはAAAと勝負するゲームを作り始めているかもしれない。
昨日まではギークな趣味ねと苛まれていた電子工作少年たちも、
明日からは先生に代わって理科の授業でArduinoを教えているかもしれない。
昨日までは「クリエイティブ」村で「クリエイティブ」業界のための「クリエイティブ」な仕事に疲弊していたデザイナーやアーティストも、
明日からは膨大な数に膨れ上がった、コードの力を知ったオーディエンスを前に心ゆくまで先鋭化することができるかもしれない。
みんながコードを書いて働く必要など全くありません。
みんながコードを書いて自分を表現する可能性を手にできるだけで、どれだけ今と違うことを自分たちの日常の生活に起こせるのか、
それを創造するのがクリエイティブ・コードが今いるところ、だと思います。
ではでは〜。
]]>教室のレッスン準備で、久しぶりにDaniel Shiffman先生の『The Nature of Code』を読んでいます。僕がProcessingを覚える時に一番助けられた本、自信を持ってどなたにでもオススメできる教科書です。改めて全体に目を通したのですが、やはりとても丁寧で分かりやすいテキスト、特に本全体のコンセプトがはっきりしていて、初めのステップからラストに至るまで、きちんと筋の通ったストーリーのある教科書だと思います。今日は少しだけこの本の紹介を書いてみたいと思います。
シフマン先生はニューヨーク大学の先生なのですが、昔から授業のノートを全部ネットで公開されていました。僕が初めて『The Nature of Code』を読んだのはシフマン先生のホームページ上で、たぶん8–9年くらい前だったと思います。当時は章立てはできていても中身がまだ埋まっていない状態でした。それでも少ない例から、例えばたくさんのパーティクルをJavaのArrayListで効率よくコントロールする方法とか、こういうシミュレーションはこういうコードで実装すればいいんだ、という実践的な方法が学べるとてもいいサイトでした。それがもう全部完成しているのですから、今から学ぶ方がとても羨ましいです(^^)
この『The Nature of Code』、本としても出版されているし翻訳版もあるのですが、同じ内容がホームページでもやはり公開されていて無料で読むことができます。しかもホームページ上では教科書の作例がアニメーションで確かめることができます。またそれとは別にAmazonでも買えるし、e-bookではこちらの言い値（10ドル以上です）で買うこともできます。なぜこんなにヴァージョンが豊富かというと、これは本の最初の部分でおっしゃっていることなのですが、シフマン先生は以前に教科書を出版された時に、執筆以外のことを出版エージェンシー任せにしていた為に、とても法外な価格の本になってしまい、そのことをとても後悔されたそうです。そして、もっと安い価格で販売できて、かつ著者側も読者側も得するような出版ができないのか模索した結果、今のかたちに行き着いたそうです。こういうところが大学の先生の鏡という感じで僕は好きです。
さらに面白いのは、この本、現在も日々進化中、最新版も全てGitHubで公開されています。GitHubなので当然読者側から色々な情報、ここはこうしたほうがもっと良いのではとか、ここは間違っているのではないかとか、ダイレクトなフィードバックを送ることができます。本が日々進化して、読者もその進化に参加していくので、きちんとした責任者のいるwikiという感じかもしれません。本の内容だけでなく、作り方も面白いと思います。
小さなモノが知性を持った生き物に成長するまでをプログラミングする
Planks ( studio otoro )
©️studio otoro
さて肝心の内容のことです。一言でいうと、「小さなモノが知性を持った生き物に成長するまでをプログラミングする」、そんなストーリーでできている本です。
最初は○を動かすことから始まります。○に位置とか速さとか加速度とか、運動に関わるいろんな変数を与えて、○の振る舞いを関数で定義しながら、○をぐるんぐるんと自由に動かしていきます。実はこの『The Nature of Code』、オブジェクトとかクラスとか、オブジェクト指向の基礎は分かっていることが前提になっています。ただし継承とかポリモルフィズムなど、オブジェクト指向「らしい」考え方は本の中で丁寧に説明があるので、変数と関数を使ったクラスの作り方や、その実体化（インスタンス化）ぐらいを知っていれば、心配なく飛び込んでしまえるようにできています。
だんだん○を自由に動かせるようになると、今度はたくさんの○を使って○の「群れ」を作っていきます。映画やゲーム、またジェネラティヴ・アートでも良く使われる「フロッキング」です。当サロンのホームページでも使っている表現ですが、なぜかずーっと見ていても飽きないんです、このフロッキング。これが自由に扱えるようになるととても楽しくなります。ここあたりがこの本の前半のクライマックスかなと思います。
後半になると、より本格的に、たくさんのモノが関わりあってできてくる世界のシミュレーションに触れていくことになります。まず「複雑系」のシミュレーションの定番とも言える、セルラー・オートマータ、フラクタル。その次が、コンピュータで生物の進化を模倣する遺伝的アルゴリズム、そして最後が特に最近は、とうとうA.I.が囲碁で人間に勝ってしまったなど、一般メディアでも取り上げられることの多いマシン・ラーニングの基礎であるニューラル・ネットワーク。こんな感じで、最初の○から始まって、気づいて見れば現代の最先端の一端まで到着するので、プログラミング初心者がシミュレーションの世界について概観するにはとても良い構成だと思います。
この本のもう１つ良いと思うところは、各単元ごとに宿題と言えば良いのか課題と言えば良いのか、読者にこういうプロジェクトを作って見たら面白いんじゃないか、というコーナーがあるのですが、それを本を通してやり切ると、たくさんの○が群れて生きているひとつの架空の世界が作れてしまうところです。この本のサブ・テーマはおそらく、たくさんのモノが関わりあってできている世界のシミュレーションと言えるかなと思います。モノが例えば生き物であれば自然界のシミュレーションになるし、モノがデータであればいわゆる「ビッグ・データ」の世界にもなるので、大げさに言えば僕たちの世界をコンピュータで見る力の一端を与えてくれる本とも言えるのかなと思います。
さらにこの本の良いところは、作例がモノクロでミニマルに作られているので、それを元にして読者が自由に発想を展開していけるところだと思います。先日、webを散策していましたら、東京のstudio otoroさんのとてもキュートな作品に出会いました（上図参照）。説明を読ませて頂くと、『The Nature of Code』で与えられている課題を発展させていったそうなのです。センスの良いデザイナーの方が『The Nature of Code』を読むとここまで行けるんだなぁということが良くわかります。ぜひ訪れて見てください、僕は、ずーっと眺めていたい感じにいつもなります（トップページとそれからスクロール・ダウンしたところにある『planks』という作品です）。
そんな感じで、processingを始められた方だけでなく、他のプログラミング言語を学んでいらっしゃる方であっても、シミュレーションや、たくさんのオブジェクトがビュンビュン動くビジュアライゼーションに興味がある方に絶対オススメの『The Nature of Code』の紹介でした。
ではでは〜。
]]>スクラッチに待望のテキスト・ベースのプログラミング環境、toshがリリースされました。少しだけいじってみましたので、ご紹介します。
“tosh”はTim Radvanさんが開発され4月8日にリリースされました。
web版とMac.app版（$17）があり、windows版は現在開発中ということです。またファイルの入出力などが不十分であったり、他にも開発が進行形の機能もあるようです。Radvanさんはインディーズの開発者(Cambridgeの学生さんです)ですので、開発をサポートされたい方はdonation($15)を利用することができます。
まだほんの少ししかいじっていないのですが、僕の印象は◎です。簡単なグラフィックスが、ブロックで作るよりも確実に楽に速く作れます。
エディター画面はこんな感じです(ちなみにこれはiPad上です。iPadでの操作については後で書きます。)
一番左がスクラッチでいう「ブロック・パレット」。もうブロックは無いですので「アセット・エリア」といったところでしょうか。その右がスクリプト・エリア。ここにコマンドを打っていくことになります。そして一番右上にステージ、その下がスプライト一覧です。あとは一番上にメニュー・バーがあって、プロジェクトのopenとsaveができます。ミニマルなエディターです。
簡単にタートル・グラフィックスでサークルを描いてみました。
1枚目の画面ですぐに分かるように、コード・コンプリション（コード補完）が実装されています。スクラッチの場合、必要なブロックを探して、それをドラッグ&ドロップで持って来て、という一連の作業が必要でした。一度や二度なら良いのですが、たいていの場合、延々とこの作業を繰り返すことになるのでとても苦痛です（笑）。なのでこのコード・コンプリションはとても嬉しい機能です。初めてでもこのサークルを描くまでかかった時間は30秒くらいでした。
動作環境ですが、Web版は、デスクトップやラップトップならどれでも動くようです（当方Macユーザーなので確かめられません、悪しからず）。ただしSafariはsaveに問題があるので、chrome推奨とのことです。
次にモバイル環境の場合です。基本的にiPad・iPhoneは対象外です。これはアプリで使っているエディター・ライブラリーの仕様のようですので、設計が変わらない限り今後もダメかもしれません。ですが、上の画面は全部、iPadの「PUFFIN BROWSER」を使っています。実はiPadでも使えます！
この点、いろいろ試しました。結果、iPadのSafari, chromeともにスクリプトの入力に問題があります。カーソルが表示されない、タッチで入力位置を正確に指示できない、なぜかスペース・キーがホワイト・スペースとは認識されない（未調査ですがリターンと同じと解釈されているようです）。
ただし抜け道がありました。それが「PUFFIN BROWSER」です。これですと入力に問題はありませんでした。
次に「save」の問題です。これもPUFFIN BROWSERだとできるのですが、問題は「どこに」保存するかです。下の画面で分かる通り、僕のオススメの方法は、「Dropbox」を使うことです。
まずpuffinでDropBoxに保存。
次にSafariでDropBoxからファイルをオープン。
そして実行。
実はPUFFIN BROWSERは入力はスムーズだったんですが、実行が不安定でした。一方なぜかSafari, chromeは実行はスムーズです笑。ですのでiPadの場合は、入力と保存はPUFFIN、実行はSafariかchrome、という具合に使い分けるのが今のところ良さそうです。Dropboxを介せば、アプリ間のファイルのやり取りもスムーズですし、デスクトップやラップトップ上で、スクラッチに読み込んで実行する際も、ファイルのインポートが楽なはずです。
toshの仕組み
toshが何をやっているのか、ちょっとだけその仕組みをみてみましょう
toshはスクラッチの「ある種の」ラッパーwrapperです。スクラッチでは面倒なブロックを組む作業を、テキスト・ベースに置き換えることで簡単にしています。つまり、スクラッチで慣れたやり方を全く変えなければならないようには意図的に作られていません、そうなるとまた新しいことを覚えなければなりませんので。逆に、スクラッチに慣れた方が、次のステップに進む足がかり、テキスト・ベースの「普通」のコーディング・スタイルに進むことができるようになることが意図されています。同時に、テキスト・ベースにすることで、複雑な作業を楽に速くできます。
toshの要は、スクラッチが読み込める形式のテキストファイルを作ることです。スクラッチのプロジェクト・ファイルは「.sb2」という拡張子をつけられているのですが、実態はzipファイルです。ですので拡張子を.zipに変えてあげて解凍すると中身を見ることができます(スクラッチのwikiに詳しい説明があります)。幾つかの.pngファイルや.wavファイルのアセットとともに、project.jsonというファイルがあります。これがスクリプト本体、json形式のテキストでスクラッチのスクリプト・エリアで作られたブロックの集合の内容が書かれています。逆に言うと、このjsonファイルを適切なフォーマットでテキストエディタで作り、それとアセット・ファイルをまとめたzipファイルを作ってあげれば、スクラッチの環境で走るプログラムができるということになります。これがtoshの仕組みです。
具体的には次のような手順だと思います。
- toshの文法でテキスト・ベースでプログラムを作る。
- そのプログラムを、json形式にパース（parse）する。
- phosphorusを使って、パースしたプログラムをjavaScriptに変換し、htmlのcanvas上で実行する。
このようにテキスト・ベースにすると、プログラミングの作業効率をアップさせるだけでなく、もうひとつ重要な利点があります。実はスクラッチをブロック・ベースといいますか、MITが用意したGUIだけで作る場合、本来スクラッチができることに制限がかけられます。スクラッチの開発者の意図だと思うのですが、機能を少なくしてプログラミング初心者を戸惑わせないようにしているのです。それに対して、jsonファイルを直接作ると、この制限を外すことができます。ですので正確に言えばtoshは今までのGUIベースのスクラッチと同じことができるだけでなく、スクラッチの本来のパワーを使うことができることになります(詳しくは、スクラッチのwikiやフォーラム、またチート・シート1, 2をお読み下さい)。
スクラッチをテキスト・ベースにしなければならない訳 — ヴィジュアル・プログラミングの功罪
そもそもスクラッチはGUIベースだからポピュラーになったのに、それをテキスト・ベースにすることにどんな利点があるのか、疑問を持たれる方もいらっしゃると思います。実はそれがスクラッチの長所でもあり、短所でもあるのだと思います。
スクラッチの1番の特徴は、よく使う基本的なコマンドやそれらの組み合わせを、あらかじめブロックにまとめていることです。
- ブロックをエディター上のスクリプト・エリアにドラッグ&ドロップ。
- ブロックどうしをカチッとつなげる。
これらを繰り返すことで、１つのプログラムができます。
スクラッチのようなヴィジュアル・プログラミングが人気があるのは、ブロックを組んでいくと何か動くものができるというプロセスが、コンピュータ以外のものつくり（例えばお料理とか）と似ているために、プログラミングの初心者が感じる最初のハードルを下げるからだと思います。
しかし、この長所は同時に短所でもあると思います。プログラミングに慣れてくると、どんどんできることが増えていくので、かなり早い段階でプログラムが長く複雑になっていき、全体が把握できないようになっていきます。
これは多少の違いはあっても、全てのヴィジュアル・プログラミングが持っている欠点です。ヴィジュアル・プログラミングは長いプログラムよりも、スクリプト向き、小さなプログラムを実験的に作ることに向いていると思います。
このヴィジュアル・プログラミングから、次のステップに行くには他のプログラミング言語を覚えるしかありません。そしてそのハードルが高い！と感じている方が多いのではと思います。
実はヴィジュアル・プログラミングに慣れ過ぎてしまうと、やらなかった場合よりも一層ハードルが高く感じられてしまうのではないかとも思います。〝前はこんなに楽に作れたのに、次のステップがこんなに難しいなら、もうプログラミングはや〜めたっ〟、そんな感じです。
あるいはもっと残念な場合もあると思います。〝ヴィジュアル・プログラミング、ブロックをいちいち組むの面倒だし、もっと複雑で長いプログラムを作りたいのにできないから、もうプログラミングはや〜めたっ〟、そんな感じです(これについては、enchant.jsの開発元、UEI清水亮氏のエッセイ『プログラミング教育の落とし穴』が参考になります)。
じゃあいきなりオブジェクト指向についていけない人は、プログラミングやっちゃダメです、そういうことでもないと思います。今回ご紹介したtoshのようなツールは、スクラッチでのプログラミングを快適にするだけでなく、ヴィジュアル・プログラミングから次のステップに行こうとしていて少し躊躇している方に特にオススメだと思います(GoogleのBlockyやUEIのMOONBlockもよく似た考えを持っているのですが、このことはまた詳しく書きたいと思います)。
そんな感じのtosh。しばらくこれで遊ばせてもらおうと思っています(^^)。また気づいたことがあったらご紹介いたします。
ではでは〜。
]]>僕が最初にプログラミングを始めたのはBASICだった（1980年代です）。その時はたぶん「プログラミング」とみんな言っていた（昔のことなので自信がないが）。
今なら、例えばMayaとかRhinocerosのような3D CADにコマンドを打って形を作る時は「スクリプティング」と言う。最初は「プログラム作ってんだからプログラミングでええやん」と思ってたけど。
そして「コーディング」。これは自分ではあまり使わない（と言いつつ「クリエイティブ・コーディング」は許している。え？）、最近とてもよく見かける言葉。偏見で、プログラミングを少し気取って言っているのかな、と思っていた（今でも思っています）。
これらの違い、そもそも、何なのでしょうか？
気になっていたので少し調べた。
スクリプティング
スクリプト言語とは、
あるプログラムの実行時に、人力だと面倒な処理をサポートするプログラミング言語のこと。
wikipedia(english)よりかなり超訳
ちょっと幅のある定義。シチュエーションによって「サポート」の意味が変わってくるからかなと。例えばSafariなどのwebブラウザ。webページを表示するプログラム。例えばそれにアニメーションをつけるのに使われるJavaScript。その時のJavaScriptはまさしくスクリプト言語。だからそれを書く作業はスクリプティング、ということに。
僕は3Dモデルをプログラムで作る時に、いつもRhinocerosを使う。ちょっと前はVBScriptしか使えなくてクラスとかオブジェクト指向系の技が使えなくて大変だった。今はc#, VB.net, Pythonもあって、ガシガシ何でも作れる。3D CADの本来の用途はマウス入力した形を記録し画面に描くことで、幾何学演算のエンジンが主要なプログラム。そのエンジンにPyhtonなどでコード側から指令を送ってやると、マウス入力では作ることができない複雑な形も描くことができる。その時のRhinocerosに対するPythonはまさしくスクリプト言語、その作業はスクリプティング、ということに。
問題は、プログラミングvsコーディング。こっちはかなりねじれている。
プログラミング ⊃ コーディング
やっかいなので、またwikiから。
プログラミングとは、問題の設定から、それを解く実行可能なプログラムを作成することまでの一連のプロセスのこと。問題の分析、理解、アルゴリズムの開発、そしてプログラミング言語による実装までの全てを含む。
wikipedia(english)よりかなり超訳
そしてコーディングとは、
実際のソース・コードを書くこと。
wikipedia(english)よりかなり超訳
他にも色んなところを見たけど(例えばMicrosoftさんとか)、
プログラミング ⊃ コーディング
というのが公式的な解釈かなと。ソフトウェアを作るプロセス全体がプログラミング、実際にコードを作って打つのがコーディング。全体と部分。超ドライな区別。
仕事として考えれば、あるソフトウェアの全体を考える仕事であれば、その仕事はプログラミング、その全体の中でロジックをコードにしていく仕事はコーディングということに。
プログラミング ＞ コーディング
ただ現実にはこんなにドライに使われることもあれば、使う人の立場を反映した裏側の意味を持っていることもある。そして後者が問題を起こしている。
上の仕事の例をもう少し具体的にすると、例えばこんな感じ。
- プログラミング : プログラムの論理構成、その論理による全体の仕様を設計をすること
- コーディング : 決められた仕様に沿って論理をコードに置き直すこと
このプログラミングとコーディングを別々の人が担当すると、バトル、どっちがえらいねん、ということです。例えば、「コーディングなんて本当の苦労も知らないくせに流行の先端を気取ってるマネージャーの類が使う蔑称にすぎないぞ！（超訳）」というような感情の発露がいかにネット上に溢れていることか、検索すればすぐに分かる。コーダーなんて絶対呼ぶな！「コード・モンキー」も同じ類の蔑称でしょう。
プログラミング < コーディング
一方、これとは全く逆の意味をコーディングは持ちつつある。code.orgの教育プログラム・マネージャーをされているKiki Prottsmanさんのこの記事。意訳すると、
- プログラミングは元々、実際のコーディングからコンピュータ・サイエンスに至るまで、全てを含む言葉だった。
- その潮目を変えたのはハッカーの登場。自宅で独学でコンピュータを覚えたハッカー・タイプの人間は、自分たちの作ったものの単なる見かけよりも、そこに実際に込められたスキルやウィットに焦点を当てる傾向。
- つまりコードを創造しているのは、本当の意味でのプログラミングではなくて、コーディングなのだ。
- そして近年、Hour of Codeを始め、コーディングという言葉が再浮上してきた。その時のコーディングはもっとくだけた意味、プログラミングの最初のステップを学習することを意味している。
確かに「近年のコーディングの再浮上」は顕著で、前述のHour of CodeやYear of Codeに代表される、国家戦略としてのコーダー教育プログラムの影響から、“code”と名の付く教育機関が爆発的に増えている。主なものだけでも(下表は営利・非営利団体を含みますが、特定の団体を推奨するなどの意図は当方にはありません。また全く順不同です)
例えばCode.org, code club, CoderDojoは各国に支部がある。どれだけのcodeと名の付く教育機関があるのか見当もつかない。末席に、Creative Code Salonもある、、、。
これらの機関が、Prottsmanさんが指摘するハッカーが逆転させたコーディングの意味、現実のコーディングがコンピュータ・サイエンスよりも創造的である、という考えを継承するのか、それとも国家を支える「コード・モンキー」を意図的にあるいは無意識に育てているのか。そんな視点が必要か。
ハッカー – 創造的コーダー
Prottsmanさんの指摘する創造的なコーダー、それを実践することがどんな意味を持つのか、それを明確に宣言したエッセーがある。ポール・グレアムさんの『ハッカーと画家』(2003, 川合史朗 訳)。グレアムさんは、ハーバードでコンピュータ・サイエンスの博士号を取得すると同時に、アート・スクールでも学んだプログラマー、Lispで現在のYahoo Storeの原型を作られた方。そのエッセーから創造的なコーダーに関する節を引用。
ハッカーと画家に共通することは、どちらもものを創る人間だということだ。作曲家や建築家や作家と同じように、ハッカーと画家がやろうとしているのは、良いものを創るということだ。良いものを創ろうとする過程で新しいテクニックを発見することがあり、それはそれで良いことだが、いわゆる研究活動とはちょっと違う。
どうやれば出来るかを理解せずに何をするかを決めようとするのは、 間違いのもとだ。でも、ハッキングには確かに、ある仕様をどうやって実装するか決めること以上のものがある。ハッキングの最良の形態とは、仕様を創ることだ— ただ、仕様を創るいちばんの方法はそれを実装することだ、ということに過ぎない。
私が言えるのは、大学で教わったプログラミングのやりかたは全部間違っていた ということだ。作家や画家や建築家が、創りながら作品を理解してゆくのと同じで、プログラマはプログラムを書きながら理解してゆくべきなんだ。
ハッカーとアーティストが同じだと考えれば、創造的な作品を作るために必要なことは全く同じ、実際に現場で試行錯誤を繰り返すしかない。美しい作品を作るという目的の前では、プログラミング/コーディングの区別は、コーディングという実践によって統合されるべきだ———。日夜キーを叩き続ける人はどう感じるだろうか？少なくとも僕はこのエッセーにとても勇気づけられる。
プログラミングとコーディング。言葉の表面上の意味の裏側に、プログラムにかける人間の意志の違いが、確実にある。そして特にコーディングが、単なる蔑称やプログラミングの初歩を意味することに終わるのか、芸術行為を意味するのか、今はその分かれ目、そう思う。
]]>はじめまして。初投稿です。
このブログは滋賀県栗東市にある「クリエイティブ・コード・サロン」という、プログラミング教室の公式ブログです。2016年4月5日（大安です）に始まりました。私は主宰者で講師の美濃部幸郎（みのべゆきお）と申します。今後とも、どうぞよろしくお願いいたします。
このブログでは、いろんなお知らせはもちろんのこと、当サロンで教える「scratch」「processing」「openFrameworks」を中心に、HTML・CSSやJavaScriptといったwebテクノロジーまで含めたプログラミングの情報や、日々僕が感じたことを書いていこうと思っています。また、サロンの名前になっている「クリエイティブ・コーディング」やそれと関係の深い「ジェネラティヴ・アート」についても書いていこうと思っています。
「公式」ですので、基本的に真面目モードで書きますが、いつもそれですと読む方も書く方も疲れてしまいます。硬軟混じりますが、お付き合いのほど、よろしくお願いいたします。
今日は最初ですので、「クリエイティブ・コード・サロン」を設立した目的についてです。スーパー真面目モードです。
クリエイティブ・コード？
クリエイティブ・コード・サロンでは、プログラミングで何か新しくて楽しいものを作る人を支援するサービスを提供していこうと思っています。キーワードはアート+テクノロジー。アートだけでもなく、テクノロジーだけでない、2つが組み合わさってできる「新しい何か」を求めている人をサポートしていきます。クリエイティブ・コードというネーミングは、アート+テクノロジーによる創作の世界で使われる言葉に由来しています。少し聞き慣れない言葉かもしれませんが、クリエイティブ・コード、あるいはクリエイティブ・コーディングとは、デジタル・テクノロジー、特にプログラミングによるコンピュータの計算能力によって、創造的な表現=新しいアートを生みだすある種の「運動」です（このcreative codingについては、１回の記事では書けないので、また書きたいと思います）。
「アート」をベースにしたプログラミング教育
今のプログラミング教育に一番欠けていること、それは「アート」だと思っています。プログラミング教育に一番必要なのは、プログラミングのスキルではなくて、自分で考えたアイデアを自由に表現すること、だと考えています。
ここ数年、特にこどもを対象にしたプログラミング教室が氾濫してきています。そうした教育サービス産業が、一律に判を押したように挙げる、なぜプログラミング教育がいま必要なのか、その理由が、ITエンジニアの不足です。こんなにITテクノロジーが重要な世紀になったのに、将来的には数十万人単位でエンジニアが不足する、だから今のこどもにはプログラミング教育が必要だ、そういう論理です。
この論理、少しおかしくはないでしょうか？今までだって、少なくとも大学・専門学校や資格取得のためのスクール、場合によってはもっと低年齢の学校など、プログラミングを習う場所はたくさんあったのですから。とすれば、問題はプログラミング教育の時間的な「量」ではなくて、教育の「質」だと思います。
デジタル・テクノロジー、情報テクノロジーの最大の強みは、個人が表現する自由を広げてくれることだったのではないでしょうか？それは現在のインターネットやそれを支えるプログラミング技術が、個人の考えを外に広く伝えることの最初のハードルをグンっと下げていることから明らかだと思います。だから問題は、私たちひとりひとりがデジタル・テクノロジーが与えてくれた表現する自由を最大限に活かせているのか、プログラミング教育は個人の自由な表現の可能性を最大限に育ててきたのかどうか、ということだと思います。
僕がこれからのプログラミング教育には「アート」が重要だと考えるのは、アートは個人の自由な表現から生まれるものだからです。「アート」という言葉に少し抵抗がある方もいるかもしれません。それは「アート」という言葉に、社会のある特殊な階級や趣味の人間だけが所有できるもの、という2次的な意味がつけられてしまっているからだと思います。ここでいう「アート」はそういうものではありません。たとえ周りと違っていても自分はこう思うということを表現すること。もっと人間の初源的な欲求に従った行為を指しています。
「アート」をベースにすることで、デジタル・テクノロジーの本来のパワーを使って、個人の自由な表現活動を支援していくこと。それがクリエイティブ・コード・サロンのプログラミング教育の特色です。
サロン-自由な表現を求める場所
サロンというとみなさんは何を想い出すでしょうか？Googleの検索で「クリエイティブ コード サロン」と入力すると、まず出てくるのはたくさんの美容院の紹介です。それを少したどっていくと、やっとクリエイティブ・コード・サロンのリンクに行き着くのですが、、、。
僕が「サロン」に込めたのは、〝既成の体制に縛られた窮屈な世界から少しでも自由になりたい〟、そう思っている方が集まる場所になって欲しい、そういう想いです。ここでもベースにあるのは、個人の自由な表現を応援したい、そういう気持ちです。
アートの世界でサロンという言葉は２つの正反対の意味を持っているようです-ひとつは、既成の体制に選ばれた作品や作家が集まる場所。もうひとつは、それに抵抗し、新しい表現を求める作品や作家が集まる場所。クリエイティブ・コード・サロンはもちろん後者の側です。僕は印象派の絵画が好きで、中でもジョルジュ・スーラが大好きです。彼の初期の傑作「アニエールの水浴」(1884, 上図)が最初に紹介されたのは、アカデミックな体制側が主催する「サロン パリ」展に対抗して開かれた「アンデパンダン展」（Salon des Indépendants）でした。それに影響されています。
ただ、美容院をイメージされたとしてもまんざら悪いことではないと思っています。綺麗になった自分を鏡で見たり、マッサージをしてもらって気持ちよくなったり。美容院に来る前と比べて、少し軽く、少し違う自分に出会えた時の感じ。新しいプログラミングの方法に挑戦して、自分の頭の中や作品が、サロンに来る前と少し変わって、新しい自分、少し自由な自分に出会えるならば、それは美容院と同じなのかも知れません。
こんなことを考えて始めました、クリエイティブ・コード・サロンです。もしも興味を抱かれた方、ぜひホームページも見て下さい！
ではでは。
]]>