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 にメンションをくれれば、どんな感じで働いているのか紹介しますし、開発チームの人にもつなげます。

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

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