Scratch Advent Calendar 2015 の 12/24 の記事として書きます。日付変わってしまってちょっと遅れてしまいました、ごめんなさい。

題名そのままですが、Scratch からミニドローンの Parrot Airborne シリーズのをコントロールできる Scratch2Airborne をつくりました。検証はしていませんが、たぶん共通のインターフェースである Rolling Spider シリーズも動くんじゃないかと思います。

注意(2015/12/27 追記) ミニドローンといえども、プロペラ部分など大変危険です。ワークショップなどでこどもと操作する場合には、長袖シャツ、保護メガネ、手袋を着用するなど、安全管理に十分ご注意ください。家の観葉植物をかすった際、写真のように、葉っぱがスパっと切られてしまいました。



ちなみに僕が買って動かしてみたのは黄色いボディの Parrot Aiborne Cargo Travis です。この記事を読んで欲しくなった方は以下のリンクから買っていただけるとうれしいです :)



いつものように Scratch のリモートセンサープロトコルの仕組みを利用し、Scratch から送られてきた命令を変換してドローンに渡します。(リモートセンサープロトコルについて詳しく知りたい方はこちら → Scratch（スクラッチ）を外部のプログラムなどとつなぐ「遠隔センサー接続」を解説する（その5）)

今回、ドローンに命令を送るライブラリとして、node.js のnode-rolling-spiderを使うことにしたので、Scratch2Airborne は node.js のプログラムです。

ソースコードはこちら↓

» Scratch2Airborne | GitHub

node.js が利用できる環境を準備し、上記ソースをダウンロードしたあと、必要なライブラリを以下のようにインストールします。

$ npm i noble
$ npm i rolling-spider

ミニドローンが起動されているのを確認した上で、

$ node find.js

これは、Bluetooth 接続でミニドローンにアクセスできる ID である uuid を確認するためのプログラムです。

この ID をひかえた上で、別の scratch2airborne.js の以下の該当部分にコピペします。



スクラッチの遠隔センサ接続を有効にした上で(やり方はこちら)、scratch2airborne を以下のように実行します。

$ node scratch2airborne.js

SESSION START というメッセージが表示されたら、接続成功です。

スクラッチの「送る」ブロックを使って、命令をドローンに送ります。

スクラッチのプロジェクトはこんな感じです ↓



送ることができる命令は以下の通りです。

• takeoff: 離陸


• land: 着陸


• forward: 前進


• backward: 後退


• hover: ホバリング（その場で静止する）


• right: 右に約90度旋回


• left: 左に約90度旋回


• flip: 前方宙返り


• backflip: 後方宙返り


• up: 上昇


• down: 下降

こんな感じで飛びますという動画を撮りました。こちらです ↓



今後は、スクラッチを経由して、Leap Motion や Kinect でドローンを動かしてみることに挑戦していきたいと思います。

Hour of Code@Microsoft に行ってきた、って話を書こうとしたのだけど、

イギリス、アメリカでの事例の話があって、アメリカだと、ビル・ゲイツやザッカーバーグみたいにコード書けて社会的にも影響力のある人がいるけど、日本にはそういうのがいないよね、とか、学校で「プログラミングやります」って云ったら「うちの子をプログラマーにするつもりはない」って保護者から云われた話とか、そういう意味ではまだまだこれからだね、って感じだわ。
音楽や図工だって、別に芸術家を育てようとしてる訳じゃないだろ。それを通してその先にあるものを感じて欲しいからやってるんだと思うんだけど、親からして、まだそういう状態じゃないってことだから、5年、10年かかる話かもしれない。

とか

Hour of Code自体は、これでプログラミングやりました、みたいになるのはどうなのよ、っていうのは周知のことだけど、小学校の低学年辺りへの導入としてはやる方も教える方も気楽に始められていいんじゃない。

» Hour of codeやってきた | とりあえずやってみる

とかほとんど言いたいことは、↑この記事 で先に言われちゃいました。にしても、@Peak パパは的確だし、文章がうまい。

Hour of Code については、数日前にスクラッチの生みの親 Mitchel Resnick 氏の下記の発言から、パズル形式のプログラミング教育に対する苛立ち、と読み取っていたことで余計な先入観を持ってしまっていたみたい。

We are strong proponents of children learning to code, but we have concerns about the motivations and methods underlying many of these new learn-to-code initiatives.

» A Different Approach to Coding — Bright — Medium

行く前から、心がザワザワしていたのだけれど、次男と実際に目にして体験してきた後、ようやく心が落ちついてきました。ちょうど昨日まで参加していた（残念ながらこちら優先して最終日は行けなかったのだけど）RubyKaigi の基調講演で Matz がネガティブな感情は伝染る、という話をしていたのだけれど、ちょうどそんな感じだったのかもしれない。

メインファシリテーター始め、スタッフの方々には直接伝えることができなかったのだけれど、帰り道次男にもし伝えるとしたら何て言う？と聞いたところ、「（スクラッチ歴、プログラミング歴はそこそこあるので）Hour of Code の教材自体は簡単過ぎて物足りなかったけれど、マインクラフトの世界観がうまく取り入れられていて楽しい。続きのもう少し上級向けのコースがあると良い」とのことだった。

面白いなと思ったのは、最短で何ブロックできますと表示されて、一度クリアしてもよりよい書き方を求められるところも面白いとコメントしていた点だ。これは動けば書き方には特にこだわらないとなりがちなスクラッチをやっているときにはない視点で、リファクタリングの考えにつながりそうな要素だ。

イベント中にはなんだかんだで時間がなくできなかったので、僕はあとからマインクラフト版 Hour of Code を全14ステージやってみたのだけれど、レッドストーンを取れとかってゴールが設定されておりマインクラフトの知識前提なのね、と感じた。ブロックを使わないで放置しておいたままにしておくと警告が出て実行できないというところが、トライアンドエラーを妨げているような気がして、少し気になったところだ。

僕もいいなと思った、アイスブレイクの自分がロボットになったつもりで、紙に書いた命令を実行する、ってやつは楽しかったようだ。コンピューターなしで情報科学を教えるアンプラグドコンピューターサイエンスというらしい。面白そうなので、関連書としてその場で以下の本を買っておいた。



マイクロソフトが作った、あるいは開発中の製品の紹介が最後にあり、以下の Hololens の紹介を見た次男はスゲーって興奮していたのだけれど、



その後に流れた1993年の AT&T のコマーシャルと、アラン・ケイ氏の「未来を予測する最良の方法は、それを発明してしまうことだ」 (The best way to predict the future is to invent it.) という引用の合わせ技で、僕は鳥肌立ってしまった。



ブレることなく淡々とやるべきことをやり、少しずつでも自分の変えたい方向に未来を変えましょうね、ってことだね。

今年も RubyKaigi の日がやってきた。

RubyKaigi が終わると、だいたい決まって皆、「あー、もっと英語ができたらなあ」とか言うのがお決まりだ。初めて Ruby 会議に参加したのはもう7年前になるのだけど、その頃から比べると、海外からの参加者がたくさん増え、セッションもほぼ半分は英語でのものになった。そんな中、僕も含めてだが、自分の英語の未熟さを改めて痛感する機会なのではないだろうか。

そんな人たちにオススメの方法を紹介したい。それは「インターナショナルなメンバーで構成される開発チームの会社で働く」ことだ。いま、コントラクターとして開発のお手伝いをさせてもらっている MediWeb での経験を実例に書いてみる。

9月から MediWeb でお世話になっており、Gold Sponsor 枠で RubyKaigi に参加させてもらったのでそのお礼という意味もあるが、あくまで個人の見解で、この働き方がエンジニアにとっては結構いいんじゃないかと思っているので、勝手に個人のブログで紹介しています。

英語に慣れることができる

まず、僕のバックグラウンドを紹介しておくと、2000年 - 2004年の4年間、サンフランシスコに本社を置くソフトウェアの会社で国際化やローカライズをおこなう QA のエンジニアとして働いていた。なので、一応英語でエンジニアとして仕事をすることは経験している。とはいえ、同僚はネイティブではなくロシアやウクライナ出身のソフトウェアエンジニアばかりだったので、一番聞き取りやすいのはロシア語なまりの英語という感じだった。普通の人よりは、そりゃあだいぶしゃべれるとは思うが、自分的には4年間住んでいたわりには、うーんあまりうまくなってはいないなあ、という自己評価だった。

さらに10年以上のブランクでだいぶ僕の英語力は落ちていたのだが、MediWeb で働き始めて3ヶ月経ち、だいぶ元に戻ってきたかなあと実感している。

3Beesというクリニック向けに予約管理や順番管理の機能を提供するクラウドサービスを Rails で開発しているのだが、本番環境にデプロイするコードは必ずペアプログラミングで書くということが徹底している。開発チームの出身は、フランス・ウクライナ・ポーランド・アメリカ・カナダなど国際色豊かで、そのメンバーと変わるがわるペアを組む。なかには日本語ペラペラの方もいるとは言え、ほぼコミュニケーションは英語、さらにランチも開発メンバーと一緒に行けば英語しばりなので、毎日英語のフリーレッスンを受けているのと同じだ。他にもソースコードのコメント、PRのコメントなど、デフォルト言語は英語だ。

正直最初の2週間とか知恵熱出そうだったが今はもうだいぶ慣れてきた。お金払ってフィリピン留学などして英語を勉強する人がいる中、お金もらっている上に英語も勉強できるなんて、なんともお得な環境だと思う。

今までにない笑いのセンスとかが新鮮、色々な価値観に触れることができる

開発はスクラムの手法にのっとって行なわれ、1週間が1スプリントなため、毎週金曜日にレビューをおこない計画をおこなったあとに、ときにはオフィスで軽くビールを1杯2杯飲んで祝ったりする。

ビールが入れば酔拳よろしく、僕もだいぶ話せるようになり、そんななかである時、フランス語の R の発音は日本人には難しい、みたいな話をしたら紹介された動画がこちら↓

いやあ、これだいぶツボに入って笑ったんだが、こうした笑いの感覚が日本人とはちょっと違っていて面白い。ほかにも北欧の国のどこかのコメディ番組でしかけるドッキリとかも見せてもらい新鮮だったり、CSS で手こずっているときには、Slack で「これ見ろ！」とか言ってこんな Gif 画像が送られてきたり。。こういうのを何と言えばいいのか、上品というかなんかウィットに富んでいる感じだ。

View post on imgur.com

なかには、え？まったくわからんよ、というものもあったりはするが、それも含めて楽しめることができる人には良いんじゃないかなと思っている。

日本的ブラックさが皆無

性格的に結構遠慮がちで、意外と気をつかってしまう。ちょっときついこと言われると気にしちゃったり、「あの人、僕のことどう思っているのかなあ？」とついつい気にしてしまう性格なのだが、そんな僕がアメリカで働いていたときは、正直相手がどう思っているのかとかまったく察しがつかないため、そうした気遣いがほぼ不要で、人間関係で悩むことなく、楽だったことを覚えている。

インターナショナルな開発チームだと、それとかなり似た感覚で仕事ができ、僕にとっては懐かしく心地よい。

新卒で入った会社はそれなりに日本的で、「飲みにいくぞ」と言われたら必ず行かないといけないみたいな上司部下、先輩後輩の間柄というのがあり、大学で一応体育会系の、例えばビール瓶はラベルを上に向けて注ぐといったしきたりを経験してきた僕にとっては、それはそれで楽しくもあり苦ではなかったのだが、継続的に心おだやかでいられるには、欧米式のいい意味でドライな関係というほうが向いている。たぶん多くのソフトウェアエンジニアと共通する価値観じゃないかと思う。

それぞれ自分の時間を大切にするという価値観を持っており、むしろ定時で帰ることがよしとされる。睡眠不足や働き過ぎ、体調崩して、普段のパフォーマンスが出ないのならプロフェッショナルではない、とみなされるようだ。

プロフェッショナルであるという感覚、チームで開発しているという意識が強い

コードは必ずペアプロでおこなう、Pull Request は必ずペアに入っていない別の人にレビューしてもらうなど、開発をすすめていく上でのルールをきっちり守るという雰囲気がある。アメリカで働いていたときにも良く思っていたことだが、決めたルールには皆ちゃんと従うんだなあという印象を持っていた。その理由ははっきりしないのだが、アメリカでもそしてインターナショナルなチームでも言えることであるが、価値観の違う様々なバックグラウンドを持つ人同士で仕事をするには、明文化されたルールだけが唯一の共通のよりどころになるため、よりきっちり守るのだろうかと思っている。

日本的感覚だと、「なにも杓子定規にきっちりしなくても」とか、「融通利かせようよ、こういうときは例外ね」とか言って、なあなあになってどんどん例外が増えていき、破綻し始めるということがある。一方、少しずつルールを最適化していきながら、それにはきっちり従うということを続けていくと、うまく回り始めた時に、特にソフトウェア開発ではとても効率的に物事が進むようになる。

一方で、いい意味でドライということと一見矛盾するかもしれないが、スプリントが終わったときの軽い打ち上げや、障害対応でランチとれなかった時には皆でピザを注文してオフィスで食べるなど、チームで開発しているなあと感じることも多い。

誕生日のときに覚えのない Pull Request がアサインされていて、開いてみたらこんな感じの内容で↓ 粋な感じだ。

まとめ

ソフトウェアエンジニアとして働くなら、海外の会社が環境的に良いと思うのだけれど、たとえばアメリカで働くとなると生活のこととか、こどもがいたら教育のこととかそれなりに大変だ。加えて、サンフランシスコはまだだいぶましだとは思うのだけれど、メシがあまりよろしくない。

「インターナショナルなメンバーで構成される開発チームの会社」でならこれまで挙げた外国で働いたときには得られるメリットを享受しつつ、東京ならおいしいところはたくさんあるし、治安が最高の日本という環境で生活できる。

Ruby/Rails で開発をおこなっているインターナショナルな会社は、探せば存在するので、これまで紹介した環境にあいそうだなあと思う人は、そうした会社で働くことにチャレンジしてみてはどうだろうか。

MediWeb もそうした会社のひとつで、RubyKaigi ではチームのメンバーがウロウロしているはず。僕も参加するので、もし興味があったら @jishiha にメンションをくれれば、どんな感じで働いているのか紹介しますし、開発チームの人にもつなげます。

あるいは本気に正式にコンタクトしたいという方は、こちらへ↓

» 医療クラウドのメディ・ウェブ | 採用情報

BASE でショップを作って物を売るという初めての経験をしていて、これが結構楽しい。

始めは購入者の情報を別のオーダー用ページにコピペとかしていたが、Greasemonkey などを駆使して全自動で転記できるようにしていたりで、エンジニア力の発揮し甲斐がある。

ちなみに販売しているのは iPhone がロボットになる Romo とそれを Scratch からコントロールできるようにする Scratch2Romo の導入マニュアル。導入マニュアル自体も販売しているが、つくる社ショップから Romo を購入してもらえば、導入マニュアルは無料でプレゼントとお得です。

» つくる社ショップ

Greasemonkey スクリプトを Chrome で動かすために Tampermonkey を使っていて、BASE の管理画面にアクセスすると、専用の Greasemonkey スクリプトが「購入者情報取り込み」と「マニュアル送信」というボタンを表示してくれる。

「購入者情報取り込み」ボタンを押すと、管理画面に表示されている購入者情報のうち、氏名や住所、メールアドレスなどを取り込むことができる。

また、「マニュアル送信」ボタンを押すと、購入者情報から取得したメールアドレスを宛先にして、販売しているマニュアルのダウンロードリンクを送る定型文のメールを宛名を入れた状態で Gmail の画面を開けるようにしている。

購入者情報を取り込んだ状態で、今度は Romo の送付を手配するための専用のオーダーページにアクセスすると、お届け先が自動で入力されるのでとっても楽ちん。

BASE では開発者向けAPIを提供しており、そちらを使った方が筋がいいのかもしれないのだが、Greasemonkey でいまのところ事足りているし、手軽に自動化できて気に入っている。

差し障りない形で BASE の購入者情報を取得できるサンプルの Greasemonkey スクリプトを用意したので公開しておきます。

» base_order_info_retriever_sample.user.js

BASE で物販を運営していて、こんな感じで自動化したいというショップの方がいらっしゃったら、スクリプトを再利用できるかもしれないので、お問い合わせ先までご相談ください。

MindWave Mobile という脳波センサーがついたワイヤレスヘッドセットを使って脳波データを取り出し、Scratch 1.4（教育用プログラミング環境）に送って、だれでも脳波データを使ったプログラムを作れるようにしてみました。

MindWave Mobile で計測できる脳波データはいくつかあるのですが、このうち比較的コントロールしやすい Attention と Mediation を使っています。Attention は集中したときに値が高くなります。一点をみつめて「上がれ、上がれ」などと念じると高くなります。Mediation はリラックスしたときに値が大きくなります。目をつぶってリラックスすれば上がりやすいです。

Attention があがると黄色いネコが上に上がり、Mediation があがれば青いネコが上がるようにしています。

両方の値とも 0 - 100 の間で MindWave Mobile で計測することができ、Bluetooth 接続した iPhone で動かしている自作アプリ Mind2Scratch(仮) に送ります。NeuroSky の SDK を組み込んだ Mind2Scratch で脳波データを取得します。

取得した脳波データを、Scratch のリモートセンサ接続（詳細はこちら → Scratch（スクラッチ）を外部のプログラムなどとつなぐ「遠隔センサー接続」を解説する）を利用して、Scratch に送ります。

Scratch で動かしているプログラムはこんな感じ↓ これは黄色いネコのプログラムです。

MindWave Mobile のような一般の人でも気軽に手に入れることができる脳波センサーの存在は、福祉用具や医療機器の設計やコンサルティングをおこなわれている 株式会社モノ・ウェルビーイング の榊原さんに教えていただきました。

榊原さんは、手足を自由に動かすことができない障害を持っているような方でも、脳波を使って意思表示することができるのではないかということを考えられており、それならそういうアプリをスクラッチを使って作ってみましょう、ということで実験してみました。

実際に自分の脳波を計測しながら練習を繰り返していると、比較的簡単に集中・リラックスを切り替えることができるようになってくるので、これでいろんなものを自由にコントロールできるかも、と思えてきてワクワクします。

今後は Scratch2Romo ともつなげてみたりして、念力(?!)で Romo を動かすとかもやってみたい。

MindWave Mobile と一緒に、榊原さんからお借りした本を読んで勉強中です。

(MindWave Mobile と Scratch をつなげる Mind2Scratch はまだ絶賛開発中です。体裁を整えたら App Store からダウンロードできるようにします)

　

今年も Scratch Day Tokyo 2015 が大盛況と言ってんじゃないだろうかという盛り上がりで終わりました。
主催側だとステージ上でのプログラムがなかなか見られないのですが、今年はニコニコ生放送で全編放送されていたおかげで、
それのタイムシフト視聴で存分に楽しめることができました。いまさっき観終えたところです。

僕は昨年、一昨年に引き続き、こどもたちが自分で作ったスクラッチの作品を自分で紹介する Show & Tell を担当しました。さっそく振り返ってみたいと思います。

KEEP(今年できて、今後も続けていきたいこと)

• このエントリー同様に、昨年も振り返りを残しています。
  
  きちんと振り返ることで、KEEPで挙げていた点は継続し、PROBLEMに挙げていた点に対しては確実に対策できていると思うので、
  引き続き今年も、もしあれば来年以降も続けていきたいと思っています。


• 昨年のPROBLEMに挙げていた、オンライン環境が不安定な場合にそなえて作品をあらかじめダウンロードしておくべきだった
  という反省を活かし、作品の差し替えは前日の 20:00 までという制限を設けた上で、それ以降にすべてダウンロードしておきました。
  ダウンロードしたファイルおよびあらかじめ提供してもらった動画ファイルも含めて、発表順に、1番は 1_◯◯ ではなく 01_◯◯ のように
  0 始まりの二桁で番号付けしておくことをきちんとおこなっていたので、この点では手間取ることはありませんでした。

Show & Tellに参加したこどもたちの交流の機会をまったく用意することができなかったという昨年の反省があったので、
Show & Tellが終わって、参加者にもう一度整列してもらったあと、ステージ横に一度集まって写真撮影をする機会を設けました。
こうすることで参加者同士の顔を覚えたり、Scratch ID を交換するきっかけになったらと思ったのですが、お膳立てはここまで、
あとはこどもたちにおまかせしました。
倉本さん中心にOtOMOメンバーで用意したスクラッチIDが書かれたシール、実はプログラミングバトルとShow&Tellに出たこども達は
ブルーのシールで一般参加者のオレンジのシールとは別だったのです。これによって誰が登壇者なのかがわかるような仕掛けになっていて、
これも交流の一助になることができたんじゃないかと思います。

• マルチプレイの模様など、当日のデモでは見せることが難しい部分はあらかじめ動画を用意してもらい送ってもらっていました。
  
  これは阿部先生にもらったアドバイスに従ったものだったのですが、Facebook グループにて Show&Tell 選考の模様を逐一報告していたために
  もらえたアドバイスなんじゃないかと思います。


• 申し込みフォームはこれまでの
  フォーマットを利用したりとこれまでの資産を存分に利用しました。採用通知に関しても
  Gistに共有しているので、来年以降もこれを参考に利用できるようにしています。採用の過程や、特に文面に神経を使う不採用通知はあらかじめ
  Facebook グループでスタッフ間で共有し、チェックしてもらうことでトラブルになりそうなところを事前につぶせたんじゃないかと思います。

PROBLEM（来年以降、今後解決していきたいこと）

• オフラインエディタで発表することという条件だったので安定した環境は作ることができたのですが、クラウド変数を使いたかったりなどオンラインでないと
  披露できない機能を持った作品に関しては、ブラウザで発表してもらっても良かったなあと思っています。


• ターボモードでないとストレスなく動かないという作品に関しては、あらかじめ聞いておき、オフラインエディタでもターボモードに切り替えて
  あげて発表してもらえたら良かった。配慮が足りませんでした。


• スクラッチの日本語フォーラムをきっちりとフォローしておくべきでした。Show&Tellに関する質問を結構フォーラムで
  受けていたのですが、阿部先生にこんな質問来てますよーと教えてもらってから答えるみたいな感じになってしまい、
  レスポンスが悪かったように思います。


• 相変わらず大人顔負けのMCぶりを披露してくれた宮島くんに安心しきってしまったのですが、今回から手伝ってもらう
  ことになったIくんのフォローが足りず、結果的にちょっとつらい思いをさせてしまいました。事前にきちんと運営側で打ち合わせを
  すべきで、役割をきちんと決めておくべきだったし、簡単なところから手伝ってもらうみたいに緩やかに慣れてもらう手段を
  取るべきだったなと思っています。


• こちらが用意した環境でない、自身が用意した特別な環境での発表も認めていたのですが、どうしても
  発表に手間取り、結果的には割り当てられていた時間をオーバーしました。ちょっとどう解決すべきか
  まだ具体策が思いつかないのですが、次回までには何らかの策を用意しておきたいです。


• [追記] ニコニコ生放送は、かなりクオリティが高く、後から視聴できる僕にとってはありがたい限りなのだが、一方で一部登壇している僕でも、コメントを見るのはかなり勇気がいる。こどもにとっては結構酷なコメントも散見されるので、特に登壇しているこどもが後から観る場合には、心ないコメントはゴミみたいなものだから全く気にしなくて良いということをきちんと説明する必要があるし、必要ならば、コメントをオフにして観てもらう、あるいはそのことを親御さんにあらかじめ説明しておくべきだったと思っている。

TRY（次回挑戦したいあらたな試み）

• PROBLEMというにはあまりに贅沢な悩みなのでTRYに挙げるのですが、年々作品のレベルが上がるし、応募数も
  増えてきて、このままだと次回どうなってしまうのだろうという感じです。これまで基本、ほぼ応募してくれた
  作品は受け入れてきたのですが、来年以降どうしても選考に漏れてしまうという作品がでてきそうです。
  しかしそれは正直やりたくない、応募するというだけでもかなりの勇気が必要で、
  そのすべてに発表する機会をあげたいと願っています。また、今年はびっくりするくらいレベルが高い作品が
  めじろ押しで、そのこと自体は本当に凄いことなのですが、あまりに Show&Tellの作品が凄すぎて、
  「ぼくの、わたしの作品ではダメだわ」とはなからあきらめてしまう子供がでてきてしまうのでは
  とも危惧しています。僕がMITで観たアメリカのShow&Tellでは、天才的な凄い作品もあればそうでない
  作品も等しく受け入れられ評価されていたのを覚えていて、そこが素晴らしいと思い日本でもやりたいと
  思ったわけで、その原点に立ち返り何か良い方策を用意したいと考えています。


• [追記] 来年は壇上とは別で、ミニShow & Tellコーナーを設けて、初心者でも参加できる雰囲気を作り、そこでひたすら Show & Tell をやるという企画を検討したい。スクラッチデーに来られない人でもリモートで接続できる環境を用意する。さらにひろげて、show & tell の動画を自分で撮って投稿できるサイトを用意し、マイクラ紹介動画のような感覚でこどもたちが気軽に自分のスクラッチ作品紹介動画を投稿できるような場を用意する。


• 昨年に引き続きやはりゲーム主体、男の子が応募しやすい形式にしてしまっているなあと思っています。
  昨年と同じTRYです。「ゲーム部門、ストーリー部門、音楽部門、ツール部門のように部門をいくつか作る必要があるかもしれません。
  女の子の応募をしやすくする工夫も必要そうです。」


• PROBLEMにあげたことの解決策もTRYも、もしかしたら大人だけで考えているから良い解決策が思いつかないのかも
  しれません。スクラッチの日本語フォーラムを通して、現役スクラッチャーのこどもたちに助けを借りるのが
  いいのかもしれません。また、スクラッチデーの運営、その中の Show&Tell の運営にも、もう少し
  こどもたちが関われるような工夫をしていく必要があるのかもしれません。

MacOS で rbenv install 2.1.2 しようとすると The Ruby openssl extension was not compiled. Missing the OpenSSL lib? エラーがでる場合の対処方法。

% CONFIGURE_OPTS="--with-openssl-dir=`brew --prefix openssl`" RUBY_CONFIGURE_OPTS="--with-openssl-dir=`brew --prefix openssl`" rbenv install 2.1.2

でインストールすることができました。

iPhone 6 にしてから、ことあるごとに iPhone が Xcode から見えなくなるという問題に悩まされていた。

Mac の方を再起動すれば直るというのを経験的に知ってはいたが、いちいち面倒。

Stack Overflow で探してみたらあっさり解決。

% sudo pkill usbmuxd

で usbmuxd(MobileDevice(iPhoneとか)とコンピュータをやりとりしているところ) のプロセスを kill すれば良い。(usbmuxd は自動的に再起動する)

» Xcode doesn't see my iOS device but iTunes does

Scratch Advent Calender 9日目は、3日目に書いた「Scratch（スクラッチ）を外部のプログラムなどとつなぐ「遠隔センサー接続」を解説する（その4）」の続きになります。

シリーズ全エントリーはこちら↓

» Scratch（スクラッチ）を外部のプログラムなどとつなぐ「遠隔センサー接続」を解説する（その1）

» Scratch（スクラッチ）を外部のプログラムなどとつなぐ「遠隔センサー接続」を解説する（その2）

» Scratch（スクラッチ）を外部のプログラムなどとつなぐ「遠隔センサー接続」を解説する（その3）

» Scratch（スクラッチ）を外部のプログラムなどとつなぐ「遠隔センサー接続」を解説する（その4）

» Scratch（スクラッチ）を外部のプログラムなどI とつなぐ「遠隔センサー接続」を解説する（その5）


その1からその4までに解説した方法を使い、Ruby とスクラッチを連携させて、スクラッチだけではできないことを実現してみたいと思います。

Twitterにつぶやく

スクラッチからTwitterにつぶやいてみましょう。

まずは Ruby だけでTwitterにつぶやくプログラムを書いてみます。

こんな感じです↓



上記プログラムを実行するには、

gem install twitter

で twitter gem をインストールしておく必要があります。

また、Application Consumer Key (API Key) などの各設定値は、自分のものに書き換えてください。

各設定値は Twitter にアプリケーションを登録して取得する必要があります。

取得する方法は、

» Twitter(Gem) - 逆引きRuby

などで調べて下さい。

スクラッチからTwitterにつぶやく

スクラッチから命令を送ったらつぶやくようにするには、その2で解説した方法で、スクラッチから Tweet という命令を Ruby に送るようにし、Ruby 側でこの命令を受け取ったら、つぶやく部分を実行するようにします。

プログラムはこんな感じになります↓



実際に実行してみましょう。



スクラッチから Tweet という命令を送ったら「こんにちは」とつぶやくことができました。

Scratch Advent Calender 3日目は、スクラッチのちょっと高度な使い方「遠隔センサー接続」についてです。

» Scratch Advent Calendar 2014

「遠隔センサー接続」はスクラッチと外部のプログラムや機器とをつなげることができる仕組みです。仕組み自体はシンプルなので、比較的簡単にスクラッチとほかのものを連携させることができ、たとえばスクラッチからツイートしたりとか、モーターを動かしたりといったこともできます。

遠隔センサー接続について、このブログでこれまでシリーズで書いてきたので、興味がありましたら その1 から読んでみてください。

シリーズ全エントリーはこちら↓

» Scratch（スクラッチ）を外部のプログラムなどとつなぐ「遠隔センサー接続」を解説する（その1）

» Scratch（スクラッチ）を外部のプログラムなどとつなぐ「遠隔センサー接続」を解説する（その2）

» Scratch（スクラッチ）を外部のプログラムなどとつなぐ「遠隔センサー接続」を解説する（その3）

» Scratch（スクラッチ）を外部のプログラムなどとつなぐ「遠隔センサー接続」を解説する（その4）

» Scratch（スクラッチ）を外部のプログラムなどとつなぐ「遠隔センサー接続」を解説する（その5）

今回は Advent Calender の力を借りて、なかなか筆が進まなかった遠隔センサー接続シリーズの続きを書きたいと思います。

センサーの値を外部のプログラムから変更する

シリーズの最初で遠隔センサー接続でできることを4つ挙げたのですが、そのうちの最後の1つ、スクラッチにカスタムなセンサーをつくってその値を外部のプログラムから変える、ということをやってみます。

スクラッチのセンサーの値を変更する Ruby のプログラムは次のように書けます。



その3で紹介した、スクラッチに命令を送る Ruby プログラムを一行変更したものです。

broadcast "a"

というメッセージの代わりに

sensor-update "a" 1

というメッセージをスクラッチに送っています。

その3で、スクラッチの変数の情報を送るために、スクラッチから Ruby のプログラムに送られたメッセージと実は同じなのだが、Ruby のプログラムからスクラッチに送った場合には、センサーの値を変更することに使われます。

実際にこのプログラムを実行してみましょう。



a という名前のセンサーの値を 0 から 1 に変更することができました。

その1からその4までで、遠隔センサー接続でできる4つのことを実際に Ruby のプログラムを使ってやってみました。

次回はこれらを応用して、Scratch と Ruby のプログラムを連携させて何か作ってみましょう。