「読み、書き、プログラミング」は、OtOMOやCoderDojoなどでプログラミングをこどもに教える活動をしている人たちの間で繰り返し使われているスローガンです。

しかし、メディアでの取り上げられかたや第三者から見た場合、「読み、書き、プログラミング」を、こどものうちから学んで将来はプログラマーを目指そう！みたいな文脈で誤解されがちで、僕も自分がソフトウェアを開発している職業柄から、油断すると知らずにそうした考えに陥ってしまうことがあります。

「スクラッチ」(OtOMO や CoderDojo でも教えている教育用プログラミング言語)を開発したミッチェル・レズニック氏は、「読み、書き、プログラミング」をそのまま英語にした「Reading, Writing, and Programming」と題しておこなったスピーチで、そうではない、と言っています。

一部のプログラマーの素養がありそうなこどもたちにだけに必須のスキルなわけではなく、よりインタラクティブな方法で自分を表現したり、より創造性を発揮したり、あるいは他の人と協調して何かを成し遂げたいすべての人のためのスキルなんだということがわかります。



» Reading, Writing, and Programming Mitch Resnick \| TEDxBeaconStreet 2012

氏の83歳の母親が、レズニック氏の誕生日を祝うためにスクラッチで動くバースデーカードを作った、というエピソードがとても印象的。彼女がプログラマーやコンピューターサイエンティストを目指しているわけはないのは明らかで、ただ息子に喜んでもらおうと、楽しんで新しいことを学び、そしてインタラクティブに表現するためにプログラミングしている。

誰もがプロのライターを目指すために「読み・書き」を学ぶのでないのと同様に、プログラマーを目指すために「プログラミング」を学ぶわけではないのです。

また、プログラミングをおこなうことで、プログラミング以外の様々なことをこどもが自発的に学んでいく様子を、スクラッチでゲーム作りに挑戦するこどものエピソードで紹介している。あるゲームに得点をつけたいけれどやり方がわからなかったこどもに変数の概念を教えたところ、「Thank you, thank you, thank you!!」ととても感謝されたという話だ。変数を教えることで生徒から感謝されるなんてことは、普通の授業ではありえない。なぜなら、授業で変数を教わるとき、こども達はいったいなんで変数を教わる必要があるのかわからないからです。

これは実際、スクラッチをこどもたちに教えたことがある人なら誰でも体験できます。ゲームづくりの基本といえるキャラクターを画面内で自由に動かすときに、半周は180度、一周させるには360度回転させるという角度の概念や、横方向はx座標を指定し、縦方向はy座標で指定するという座標軸の概念やプラス/マイナスの概念なんかも、小学校低学年のこどもでさえもすすんで学ぼうとする。学校で習った、習っていないというのは関係なくて、彼らはただただ面白いゲームを作ろうとしているだけなのだ。

「あなたもプログラミングを始めてみませんか？」という言葉でレズニック氏はスピーチを締めくくっています。

身近にこどもがいたら一緒に始めてみるのがいいかもしれません。

» OtOMO – オトモ

では毎月スクラッチのワークショップをおこなっています。

またこどもたちに教えながら、自分も学ぶという手もあります。

» CoderDojo Tokyo

は、ボランティアで小中学生にプログラミングを教えることができるメンターを探しています。

そして、独学で学び始めようという学生や大人には

» 3分動画でマスターする初心者向けプログラミング学習サイト - ドットインストール

をいつもすすめています。

CoderDojo Tokyo や OtOMO – オトモ を通して、こどもにプログラミングを教えてきましたが、継続的にそして意欲的にプログラミングを続けるこどもとそうでないこどもがいます。

僕にとってはその違いはあまりに明白で、もちろん例外もありますがだいたいのケースで「親が一緒にやっているかどうか」です。

プログラミングと似ている面があるのが英語で、自分は必要とはしてこなかったけれど将来こどもには必要になりそうだから、ということで、こどもを英会話教室に小さい頃から通わせていたりする、ということをよく聞きます。ですが、それって本当に長続きし、そして身についているのでしょうか？

おなじ習い事で、野球とかサッカーを考えてみましょう。だいたいこの場合は父親だと思いますが、親がキャッチボールやパスの練習につきあってあげない環境でこどもがうまくなるとはとても考えられません。

プログラミングや英語も同じなのに、スキル自体の特殊性があって、親が習得というか理解することをあきらめてしまっていることが多いのだと思います。でも、こどもは親を抜こうとして頑張るのであって、その親があまりに簡単に抜かれてしまってはこどもは頑張らないと思うのです。

「そりゃあ、あなたは仕事としてプログラミングをやっているのだからそういうことが簡単に言える」と言われてしまうと、まあ僕も正直プログラミングをまったくやったことがない人の気持ちというのはわからないので返答には困ります。ですが、こども達に一番最初に教える「スクラッチ」は、小学校低学年のこどもでもプログラミングできるのを大人が理解できないとは思えないのです。

始めからあきらめてしまうのではなく、一緒に学ぶのでもいいので、努力はすべきなのではないでしょうか。

もし、このエントリーを読んで、自分もこどもと一緒にプログラミングをやってみようと思っていただけたら、以下の動画でスクラッチとはどんなものなのか見てみて下さい。

» Scratchの基礎 (全22回) - ドットインストール

CoderDojo Tokyo や OtOMO – オトモ、あるいはほかの団体のワークショップなどで、プログラミングがどういうものかに触れることはとてもいいことだと思います。その上で、こどもが興味を持ったのなら、ぜひ親子で続けてもらいたいと思っています。

スクラッチに関しては、自分が作った作品を共有して公開するという、モチベーションを維持する仕組みがきちんと用意されているのでそれをぜひ利用してみてください。そして、スクラッチでは、「親が一緒にやっているかどうか」が一目瞭然で、続けているこどものアカウントの友達には、だいたいお父さんかお母さんのアカウントが登録されています。（つまりお父さん（お母さん）もやっているということ）

さて、気が付けばあっという間に2013年が明けてしまい、はやくも一日目が終わろうとしています。

初日が終わらぬうちに今年の抱負を宣言しておこうと思います。

胸がすくズバッとした主張が好きで愛読している「Chikirinの日記」の

» 来年の抱負）　やらないことを３つ決めよう！ - Chikirinの日記

に書かれていた方法がとてもいい方法だと思いました。

一日は24時間と限られています。優先順位を決め、自分の時間を何に使うのかがとても大事で、そのためにはやらないことを決めるのがいいというのがその主旨です。

昨年僕は40歳を迎え、なんだか急に人生の残り時間が少なく感じられるようになって、正直少しあせりを感じて始めていたときに、上記エントリがとても心に響いたのです。

というわけで、僕も3つのやらないことを決めました。

やらないことその1: 0:00 以降仕事をしない

最近朝がとても弱くて、まともに起きることができません。午前中にやるべきことをやるのが効率がいいとはわかってはいるのですが。。

その原因は、まあ夜が遅いからなのですが、早起きしよう、という目標だと守れそうにないので、0:00 以降は PC に向かって仕事をしない、という目標にしておき、仕事しなければ、やることはあまりないので寝てしまいますから、それで早起きしようというねらいです。

やらないことその2: URL が入っていない新規ツイート、Facebook の近況アップデートをおこなわない

これまでさまざまな影響を受け、尊敬してやまない「百式」田口さんの、セルフブランディングには「ハッキリ言ってブログしかない」という主張を僕はいまでも強く信じています。

(詳しくは

» 人気ブログ『百式』を運営する田口元さんが語るセルフブランディングセミナーの内容全部まとめ

にまとめられています)

Twitter の 140 文字では短すぎるし、Facebook では会ったことがある友達や知人にまでしか自分の主張を伝えることはできません。

とはいえ、Twitter Facebook の便利さは否定できず、完全にやめることはできそうにありません。

そして、ツイートしてしまうと、自分の言いたかったことを言った気分になってしまい、数年前に比べるとブログを書く頻度が激減しています。

そこで、ツイートしたくなったら、グッとこらえてその内容をブログに書き、自分のエントリーの URL を載せたツイート、近況をおこなうようにする、というのがURL のない新規ツイート、Facebook の近況アップデートをしない、という趣旨です。

他人のツイートに反応してリツイートしたり、メンションするのは URL 付きとみなせて、これは続けていくつもりなので、良しとします。

いま作っているWebサービス以外の個人サービスに着手しない

ウェブサービスを作るのが好きで、これまでいくつも個人サービスを作って来ましたが、しばらくはいま開発中のものに専念します。

ちょうどこの「3つのやらないこと」ができたかどうかを Twitter アカウントさえあれば毎日記録できる 3Wont というサービスを年末に思いつき、着手してしまいそうになって、さっそく目標を破りそうになってしまったのですが、なんとか思いとどまりました。

以上、僕の3つのやらないことです。

とりあえず2013年、最初の一日は3つとも達成で終われそうです。

いまさらながら、iPhone アプリではやっているらしい「パスドラ」をやってみた。

» 私がパズドラで遊ばなくなった理由 - もとまか日記

で挙げられている遊ばなくなった理由がはっきりとしなかったので、自分で試して確かめてみたいというのが理由。

さすがに人気があるだけあって、僕が以前ちょっとやってみたソーシャルゲームにありがちな単にタップするだけの単調なバトルとは違って、パズルを組み合わせたバトルは若干のゲーム性があり、バトルのエフェクトだったり効果音などはきっちり作られていて操作していて気持ちがいい。

が、知らない人のモンスター（序盤だからか自分のモンスターよりも段違いに強い）を仲間で連れて行き、その仲間のモンスターにばかり攻撃させていれば、序盤のノーマルのステージではまったくこちらがやられることはない。なんか飽き始めてきたので、ちょっとスペシャルステージを覗いてみたところあえなくやられてゲームオーバー。

そこで、冒頭で紹介したエントリーにでてくる、魔法石（App Store で1個85円で買える）を使わないとコンティニューできませんよ、という画面がでてきて、納得。

「パズドラ」含め、ソーシャルゲーム全般に自分が感じる違和感は、それをクリアする（クリアするという概念があるのかわからないが。。）のにいったいいくらお金がかかるのかがわからない点だとあらためて確認した。

パズドラが普通のゲームとして人気があり、800円とか1200円でダウンロードできるゲームだったとしたら僕は買うかもしれない。なぜなら、800円とか1200円以上はもう払わなくて良いという安心感がある。

コンティニューで85円は序の口で、ゲームが進んでいくうちに、魔法石5個とか10個必要ですよ、といった仕掛けが用意されているかもしれない。今後果たしていくらかかるかというところが未知数なので、最初は無料だとしてもトータルでいったいいくらなんだという点が見えない。

こどもたちがソーシャルゲームをやりたい、ともし言い出したら、そのあたりをちゃんとわかりやすく説明して、クオリティも料金も確定している他のゲームをやらせることにする。

というわけで、僕も静かにホームボタンを押してパズドラを閉じ、ブルブル震わせて削除した。

\#666666 といった hex 指定の色の明るさを求める方法を調べたのでメモしておきます。

Python で書くと以下の通り。



上記関数を使って、brightness("#666666") = 0.4 のように 0 〜 1 で表される明るさを求め、たとえば 0.5 より大きければ明るい色なので、その上に表示するテキストの色は黒、0.5 より小さければ暗い色なので、テキストの色は白、というように自動的に決めることができる。

参考:
colors - Hex Code Brightness PHP? - Stack Overflow

NPO法人CANVASさんがおこなっている「プログラミングワークショップin東北」に講師として参加し、宮城県の亘理小学校の6年生たちにスクラッチを教えてきました。

普段こどもたちが参加していて、僕もお手伝いしている三軒茶屋で毎月スクラッチのワークショップをおこなっているOtOMOが協力している関係で、内容はいつもOtOMOで初めての子向けに教える時におこなう「ネコから逃げろ！」というゲームをつくるというものでした。

東北のこどもたちにプログラミングを教えるという取り組みの今回が2回目、前回の様子は

» 石巻や仙台などの小学生にプログラミング教室、NPO法人CANVASが開始：ITpro

で紹介されています。

東京からはCANVASのみなさまと亘理小OBのデラさん、現地からは亘理小に娘さんが通われていて自身はフリーでプログラマーをされている Praise First の砂金（イサゴと読むと初めて知りました）さんとその奥さま、こどもたち自身が取材し石巻のことを伝える
「石巻日日こども新聞」を発行しているキッズ・メディア・ステーションの太田さん、といったメンバーに助けられながらも、2日間で40人弱のクラスを3クラス教えるという、人前で話すのはどちらかというとあまり得意でない僕にはなかなかにハードな内容でした。

それでも、いつものように、こどもたちの「わかった！」という瞬間に立ち会えること、楽しんでいる笑顔が見られることで、慣れないことをする大変さは吹っ飛びます。

特に今回は、「iPhone とかのアプリを作っている人です」と紹介してもらうと、「おお」とか「すげー」と生徒さんたちがどよめいてくれたり、プログラマーになりたいという女の子を担任の先生に紹介してもらったりと、気恥ずかしいですがうれしいことの連続でした。

極めつけはワークショップすべてが終わったあとに、先生、生徒さんたちからのサプライズで、合唱のプレゼント。これにはホントやられました。

感謝のお手紙まで生徒さんたちからいただいて、「いやいやこちらの方が何倍も感謝です」という思いです。

亘理小のみなさんの素晴らしさが少しでも伝わるといいなと思い、手紙への返事をあえてブログで紹介します。

説教じみた部分もありますが、まあ一応40年生きてきたので、少しくらいえらそうなことを書かせて下さい。

Ruby on Rails をこれから始める人向けの情報

Ruby on Rails をこれから始めたいのですが、どんな本がおすすめですか？と聞かれたので、ちょっとまとめておきたいと思います。

» 僕が Ruby on Rails を絶賛する理由 - 僕は発展途上技術者

というエントリーを2007年に書きましたが、その後状況はいろいろと変わり、僕自身 iOS アプリや Android アプリを開発するようになったり、Web サービスでも Python on GAE を触るようになったりして、当時ほど Ruby on Rails 一色というわけではなくなりました。

また、Ruby on Rails の環境を自分の開発マシンに用意するのも

» Mac OS X 10.8 Mountain Lion に Ruby on Rails 環境をセットアップする - 僕は発展途上技術者

で書いたように、最近はちょっと面倒になりました。

それでも Web サービスをつくる、それもユーザー向けで毎日サービスを運用しながら、少しずつ改善していき手を入れ続けるような性質の Web サービスならば、いまでも Ruby on Rails を絶賛おすすめ中です。

さて、その Rails を学ぶためのおすすめ本ですが、2007年から変わらず



がおすすめです。

僕の手元にあるのは第2版までの日本語版と第3版の英語版で、上記第4版は正直言うと中身をみていないのですが、変わらず良書であることは間違いないでしょう。

Rails のみならず、デプロイ方法やテストの書き方など Web サービスを作る上でのベストプラクティスを学ぶことができるので、2007年にこの本を最初に手をとるまでPHPで断片的な知識でもって Web サービスを開発していた僕にとっては、それらが一気に整理されて大変ためになったことを覚えています。

Rails 以前に Ruby の基本的な知識が必要という場合（Ruby on Rails を始めたいという方はたいがいそうだと思いますが）は、



を Rails 本を読む前に読んでおいたほうがいいでしょう。 Ruby を使う人達が言っている「Ruby がたのしい」という言葉の所以がわかると思います。

順番としては「たのしいRuby」を読んでから「RailsによるアジャイルWebアプリケーション開発 第4版」を読むのがおすすめですが、この2つを読み通すにはそれなりの時間がかかるでしょう。

もっと手っ取り早く学びたい、あるいは先にざっと概要を知っておきたいという場合は、今は動画で学ぶという方法があります。

» Rubyの基礎 (全32回) - ドットインストール

» Ruby on Railsの基礎 (全46回) - ドットインストール

ドットインストールは動画でプログラミングを学習できるサイトで、すべての動画を無料で観ることができる素晴らしいサイトです。ひとつの動画が3分弱なので、上記2つをぶっ通しで観れば、4時間くらいで概要をつかむことができます。その上で書籍を読めば効率的に学ぶことができるのではないでしょうか。

Ruby on Rails でとりあえずアプリが作れるようになった人向けの情報

さて、ここまでの基本情報を身に着け、ちょっとした Web アプリを作れるようになって初学者を卒業した段階で必要そうな情報も紹介しておきます。

この段階になると、具体的にやりたいことが出てきて「こういうことがしたいんだけれどどう書けばいいんだ？」といった疑問が多く出てくるようになると思います。そういうときに役立つのが以下のレシピブックです。





英語ですが、知っておくと便利な Tips を動画で紹介している

Ruby on Rails Screencasts - RailsCasts

もおすすめです。

Ruby と Rails をやってて強力だなあと思うのは便利で豊富な gem と呼ばれるライブラリの存在なのですが、たくさんあり過ぎてどれを選んでいいか迷うときがあります。そういうときに上記 RailsCasts で紹介されているものを使うというひとつの判断基準になります。

どの gem を使うかの判断基準として

The Ruby Toolbox - Know Your Options!

を使うのもいいでしょう。Ruby Toolbox では各 gem のメンテされ具合や利用者数、評判などを比較することができます。

Rails の API ドキュメントを調べたいという場合は、インクリメンタルサーチができる

Ruby on Rails - APIdock

がおすすめです。

Ruby のコーディングスタイルが気になってきたら、

Rubyアソシエーション: コーディング規約

で紹介されている各コーディング規約を参考にするといいと思います。

いままで他の言語、フレームワークをやってきた人向けへのアドバイス

いままで他の言語、フレームワークをやってきて、Ruby on Rails で実際にアプリを開発し始めたときによく見る悪いパターンというのを紹介したいと思います。

Ruby on Rails では DB のスキーマ情報の変更を Migration という仕組みで綺麗に管理しているのですが、それを無視して sql ファイルで管理しようとするのはやめたほうがいいです。初期データ投入も、seed.rb に Ruby でわかりやすく書くというスタンダードな方法を取り、sql ファイルをインポートという方法は避けたほうがいい。

メソッド名や変数名の付け方を Ruby や Rails 流にあわせましょう。Rails ではモデル名を名詞の単数形で定義すると、自動的にその名詞の複数形で DB 内の対応するテーブルの名前がつけられるなど、英語のルールに従うことが必要なので、メソッド名や変数名を英語でつけるというのが特に必要です。その際の名前付けも、なるべく正確に、そしてスペルミスをしないように辞書で確認するなど気をつけたほうがいいです。

人が作ったものは信用できないということで、すでに Rails の機能にあるのに、あるいは同じ機能の gem があるのに、同等の機能を実現するライブラリを自作してしまう人がいるのですが、複数人が関わるプロジェクトではそれはできるだけやめたほうがいいでしょう。もし自作のライブラリを採用したいとしたら、github などで公開し、すでに世にでていて多くのユーザーを獲得している先行のライブラリと同等のドキュメントをそろえ、前述したThe Ruby Toolboxで見て、既存のライブラリよりも多くのユーザーを獲得していると証明できるくらいでないと、と思います。

Rails 3.2.3 での CSRF 対策について調べていて、ちょっとはまったポイントがあったのでメモを残しておきます。

Rails はデフォルトで特に何もしなくても POST/PUT/DELETE のリクエストに対して authenticity_token という hidden のパラメーターを利用して CSRF 対策をおこなってくれる仕組みを持っている。(Ruby On Rails ピチカート街道 - Rails 2.0・その１２(CSRFを勝手に防止) - などが参考になる)

しかしそれは Rails の form_for などのヘルパーを使った場合で、form タグを自分で書いた場合には、

<%= hidden_field_tag :authenticity_token, form_authenticity_token %>

のように手動で authenticity_token パラメーターを作って POST のパラメーターとして送る必要がある。

authenticity_token を送らない場合の挙動を確認したくて、適当に scaffold で model/view/controller 一式を作成し、form_for ヘルパーを使っている部分を以下のようにベタな html に書きなおし、あえて authenticity_token を送らないようにする。

<form accept-charset="UTF-8" action="/people" class="new_person" id="new_person" method="post">
    <div class="field">
    <label for="person_name">Name    <input id="person_name" name="person[name]" size="30" type="text" />
  </div>
  <div class="actions">
    <input name="commit" type="submit" value="Create Person" />
  </div>
</form>

これで、POST のリクエストをおこなってもエラーとなって、新しいデータは作成されないと思ったのだが、予想に反してデータは作成されてしまう。

あれ、これだと CSRF 対策にならないじゃないか、と思いいろいろと試行錯誤。

ログをみると authenticity_token を送らない場合は

WARNING: Can't verify CSRF token authenticity

という WARNING のメッセージは確かに出ている。でも POST のリクエストは通ってしまう。

Rails 2.x を触っていたころの記憶では、authenticity_token を送ってない場合にエラーで悩まされた覚えがある。

で、しばしはまった後にわかったのは、authenticity_token を送らない場合は、POST のリクエストは通るのだが session がリセットされているということだった。

devise などで何らかのユーザー認証の仕組みをいれている場合に、POST/PUT/DELETE のアクションに対して、session に格納されているユーザー情報の値でもって認証をかけるのが普通だ。

これを scaffold でつくった簡単なフォームで擬似的に実現しようとすると、

class ApplicationController < ActionController::Base
  protect_from_forgery

  def authorize
    unless session[:login]
      redirect_to root_url, :notice => "not authorized"
    end
  end
end

のように session を確認する authorize メソッドを定義しておいて、PeopleController では、

before_filter :authorize, :only => [:create, :update, :destroy]

のように作成、変更、削除のアクションに対して authorize メソッドを before_filter でかける。

authenticity_token パラメーターを送らなかったり、値が違っている場合は session がリセットされるので、リクエスト自体は通っても authorize で蹴られてデータは作成されない。

「うーん、でもおかしいなあ、以前は確かにエラーではじかれた覚えがあるんだよなあ」と思って、もうちょっと調べていたら、Ruby on Rails Guides: Ruby On Rails Security Guideに

If the security token doesn’t match what was expected, the session will be reset. Note: In Rails versions prior to 3.0.4, this raised an ActionController::InvalidAuthenticityToken error.

security token が期待された値とマッチしない場合はセッションがリセットされる。Rails 3.0.4 以前は ActionController::InvalidAuthenticityToken error を出していた。

とちゃんと書いてありました。

ドキュメントをきちんと読んでなかった僕が悪い。

開発環境をセットアップするのが面倒なので、OS をアップグレードするたび Time Capsule からイメージをまるごとコピーしてきて、秘伝のタレのように使っています。そのため、一から環境構築というのはめったにやらないのですが、今回、いつも使っている MacBook Air とは別に自宅用に Mac mini を買ったので、久々に Ruby on Rails の環境をセットアップしました。せっかくなので、まっさらの Mac OS X 10.8 Mountain Lion に Ruby on Rails をセットアップする手順例としてその手順を記録しておきます。

最近の Rails の環境構築は、gcc 入れた後に Ruby やら RVM やら Git やらを入れなくてはいけなくて、相当面倒です。しかし、RailsInstaller はそれらを一気にインストールしてくれます。

リンク先の DOWNLOAD the KIT をクリックしてインストールファイル(RailsInstaller-1.0.3-osx-10.7.app.tgz)をダウンロードします。

ダウンロードしたファイルをダブルクリックして展開します。

展開したファイルをダブルクリックすればインストールが開始されます...

のはずなのですが、ここで「"RailsInstaller-1.0.3-osx-10.7"は、開発元が未確認のため開けません。」というエラーが出てしまいます。

Mountain Lion からなのでしょうか？デフォルトの設定では、Mac App Store と確認済みの開発元からのアプリケーションでないとアプリケーションの実行が許可されていないので、

[システム環境設定] > [セキュリティとプライバシー]

を選んだあと、左下の鍵マークを外し、[一般] タブの [ダウンロードしたアプリケーションの実行許可：] で、[すべてのアプリケーションを許可] を選びます。

このあと、もう一度先ほど展開したファイルをダブルクリックすればインストールが開始されます。

必要な方は、この後 [セキュリティとプライバシー] の設定を元の、[Mac App Store と確認済みの開発元からのアプリケーションを許可] に戻しておきます。

RailsInstaller のインストールについては、指示通り進んでいけば特に問題はないと思います。

インストール後、

$ ruby -v
ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-darwin11.4.0]
$ rails -v
Rails 3.2.8

のように ruby や rails の最新版がインストールされていれば成功です。

CoderDojo Tokyo は毎週日曜日下北沢オープンソースカフェでおこわれている小中学生にプログラミングを教える活動です。

小学生にはおもに教育用プログラミング言語のスクラッチ、中学生には HTML や Javascript を教えていましたが、最近は iOS アプリを作りたいというこどももでてきているので、実験的な試みで、iPhone アプリ開発を教えられるメンターを育てるメンター養成道場をおこないました。

実は、CoderDojo をきっかけにして、わが息子に教えたかったというのが本音のところで、本当にこどもでも iPhone アプリ開発ができるのかモニターの意味も含めて、長男も混ぜてもらいました。

「15歳からはじめる iPhone わくわくゲームプログラミング教室」をテキストにして、第一回目の本日は一時間で開発環境のセットアップ、xCode の使い方をざっと習い、iPhone シミュレーターにダイアログを表示して Hello World など好きなテキストを表示するまでをやってみましたが、なかなかの好感触でした。



結論としては、小学生上級生で、スクラッチなどでプログラミングの基本がわかっていればできそうという感じ。ほかのメンターの方たちもこのテキスト通りすすめるのであれば、教えられそうということでした。

それもこれも、テキストが非常に良く書かれていることに負うところが大きく、たとえば

• 最初にわかりやすく iPhone でゲームプログラミングをすることの概念的な説明（コンパイルとはどういうことかや、iPhone では使えるメモリ容量が制限されていることなど）が書かれている。


• 半角/全角文字を間違える、小文字と大文字を間違える、セミコロンとコロンを間違えるなど、あらかじめはまりそうなポイントを先回りして注意を惹起している。


• viewDidAppear といったメソッド名を view は「画面」、did は「した」、Appear は 「現れる」というように英語をくっつけたものですよ、というように丁寧に解説している。

といった点は、著者が実際にこのテキストの通りにこどもたちに教えている経験に基づいていることを感じさせます。

こどもに iPhone アプリを教えたいというかたに限らず、プログラミングは初めての大人でも今から iPhone アプリを開発してみたいという人にもおすすめの一冊ではないだろうか。

以下、養成道場をすすめ、これから CoderDojo で実際に iPhone アプリ開発を教えるとしたらを念頭にいれて、いくつか気づいたことやポイントを。

• 最初の Xcode のダウンロードやインストールなど、開発環境のセットアップは面倒かつ時間を食うので、できたら事前に済ませてもらうのがよい。


• iPhone シミュレーターで動かす分には、無料で済むが、作ったアプリを実機で動かすには、年間参加費 ¥8,400 の開発者登録が必要。シミュレーターだけで動かすなんて、きっとこどもは満足するわけはないので、この出費がかかることを必ず親に理解してもらう必要がある。


• 小学生は ( と ) の括弧しかしらない。Objective C には { と } の中括弧、[ と ] の大括弧も駆使する必要があるので、最初によく説明しておく。


• [追記] 特に英語の英才教育などやっていないため、英語がさっぱりわかりません。アルファベットは一応学校でやったのでわかっているようですが、大文字小文字の区別がおぼつかない。


• スクラッチはブロックを組み合わせるだけでよかったところが、Objective C ではすべて全部書かないといけないところで、はやくもうちの息子は萎えていた。けれども、Xcode の補完の機能を使いこなすコツをよく教えたら、なんかロボットに助けてもらっているような感覚で気持ちがいいと言っていた。


• テキストではプロジェクト作成のところで ARC(Automatic Reference Counting) を無効にしている。この通りに従わないと、release 文のところでエラーがでるので、この間違いに気づいたら早めにプロジェクトを作り直す。


• 大人のメンターから型宣言のところの * は何ですか、という質問が。。ポインタうんぬんの説明は難しそうなので、後回し。それとなくスルー :-) まずは動かしみて「動いた！」という感動を体験させてあげるのが重要。


• ダイアログを表示できただけでもうれしかったようで、帰ってから妻や弟にみせていた。まあ、見せられたほうは「え、こんだけ」という本心を隠すのに苦労していたようだが。。


• 最初のセットアップや Xcode の使い方で、慣れている人がガイドしてあげるのは大変重要だと思った。大人でも独学でやればおそらく4、5倍の時間を食ってしまうんじゃないかと思うほどはまりポイントが満載。


• こどもがスクラッチをやっていてプログラミングの基礎はわかっているのは大きい。変数に代入とかメソッドに命令を渡すというところは、スクラッチに置き換えて説明すればすんなりわかってくれる。


• 自分のこどもを他人と混ぜて教えるのは、家だとなかなかやらないところを教え始めるきっかけになったというのと、肉親同士だと険悪になるところを他人の目もあるのでやさしく丁寧に教えてあげることができる、という２つのメリットがあって、これは使えるライフハック！

↑ iPhoneで始めてのHello world!

今後も不定期ながら、iOS アプリ教室は続けていくので、もし興味がありましたら、Twitter で @jishiha をフォローしてくれるなり、CoderDojo Tokyo のページからたどれる Facebook のグループページなどで情報をウォッチしてみてください。