生JavaScriptでは難しい理由
Web業界はこの10年で、驚くべき進化を遂げたと思う。ただし、当初デザイン系要素の比率が高かった影響か、ECMAScript等のスクリプト系開発言語がその初期学習コストの低さからか主流となり現在に至るが、若く優秀な人材が大量にこの方面に流れた影響か、このような大規模プロジェクトにはあまり向かないスクリプト系言語でも、様々なライブラリの登場で、大規模プロジェクトでも何とかやってこられたような印象を受けた。
そして、このWebアプリ成功の影響が我々エンタープライズ業務開発系業界にも３周遅れ(いや10周以上の遅れか)でやってきたが、少なくとも私現在いる業界ではせいぜいASP.NETやRuby on Railsでの開発がたまにあるくらいで、JavaScriptでクライアントサイドからWebAPIを叩くような開発はあまり聞かない。そんな状況なので、静的型付言語で開発しろといっても、多分色々な意味でカオスになってしまうのではないだろうかと。
だったら、ASP.NET(.aspx)とかでやればいいじゃないかという話もあるが、今回は提供されるAPIがJavaScriptなので、開発はJavaScript主体が良いだろうと。
今日はこれ位で。
なぜTypeScriptなのか
ActionScriptの悪夢以降、PythonやPerlなどちょろっと触ることはあったのだが、やはり動的型付言語だとプロジェクトが大きくなるとトラブル多発は免れないだろうなという印象は変わることなく今現在に至っていたが、Visual Studio MagazineなどでTypeScriptの存在は何となく知っていたので、この機会に色々と最近のWeb開発環境について調査をしてみると、TypeScript2.0が、つい最近リリースされたということを知った。
そしてまた、メジャーなフレームワークであるAngularJS2もまた最近発表され、その開発にもTypeScriptを使用しているとのことで、良い機会なので、勉強がてらTypeScriptについて色々調べてみようかなとの結論に至ったというわけ。
いまさらながらのスクリプティング
FlashでActionScriptの悪夢に悩まされたのはいつの頃だったか、もうECMAScriptには関わり合いたくないと思ってから10年超。最近、ひょんなことからWebアプリを開発しなければならないような状況になったので、備忘録兼ねてブログを再開しようかなと。
Lego Mindstormsで何ができるのか
Mindstormsは、NXTブロックを中心として組み立てたLegoブロックをプログラミングして動かします。NXTブロック自身でも簡単なプログラミングが出来ますが、パソコンと接続してプログラミングを行うことが前提となるでしょう。
LabView
Lego Mindstormsを購入すると、ロボットを制御するためのアプリケーションであるLabViewが付属してきます。画面上でブロックを並べてプログラミングを行うことが出来ます。
http://www.ni.com/academic/mindstorms/ja/
Microsoft Robotics Developer Studio(RDS)
ロボット制御アプリケーションの開発環境。自作のロボット制御アプリケーションを開発するための環境ですが、Lego Mindstorms用のテンプレートが含まれているため、簡単に制御アプリケーションを開発出来ます。
実際の開発には、前述のLabViewに似たVisual Programming Language(VPL)と呼ばれる開発環境で、ブロック様のコンポーネントを組み合わせて開発を行います。また、C#やVB.NETなどを使用して、コンポーネントの開発を行うことが出来ます。
サンプルには、Xboxのゲームコントローラーを使用してロボットを制御するサンプルもあります。
http://www.microsoft.com/robotics/
MINDdroid
Androidスマートフォン、タブレットなどからMindstormsを制御できるアプリ。実際には、Android側の傾きセンサーを利用して、製作した戦車型ロボットを制御します。
https://play.google.com/store/apps/details?id=com.lego.minddroid&hl=ja
日本でのLego Mindstorms
今日は、Lego Mindstormsについて書いてみたいと思います。
日本におけるLego Mindstormsの位置づけ
情報教育というかコンピューター科学教育において世界中で広く利用されている、言わずと知れたLego Mindstormsですが、日本では今一つ盛り上がりに欠けている感じがあります。
その理由としては、
・一般の小売店やレゴショップで入手できない
・Web上の日本語の関連情報があまりない
・小中高のコンピューター科学を専門としない教師から見ると敷居が高い
などがあると思われます。また、これは日本に限った事ではないですが、価格が高い(Amazon.co.jpで￥30,000前後する）のも理由の一つとして考えられるのではないでしょうか。
日本でのLego Mindstormsの入手方法
日本でLego Mindstormsを入手しようとした場合、以下のような方法があります。
・Amazon.co.jp等、通販で購入する
・米国の輸入代行業者や知人友人を経由して購入する
・日本の正規代理店から購入する
この中で、少し不思議な感じがするのが、正規代理店から購入する方法です。詳しく調べていないので本当のところは不明ですが、国内正規代理店のWebページを見ると価格が表示されておらず、Webページから見積もり依頼をして購入する方式になっています。
実際米国でも、一般小売店から購入できるバージョンと別に学校などに納入される特別バージョン(Legoのオンラインストアでは購入できる)が存在しているので、Lego社の日本国内における何か特別な販売戦略が存在するものと思われます。
https://www.legoeducation.us/eng/product/lego_mindstorms_education_nxt_base_set/2095
ちなみにこのEducation Setは、レゴブロックをしまうためのトレイが付属したり、充電式バッテリーがセットになっていたりします。通常版でもエネループを使うことで同じようなことは実現できるのですが、エネループだと通常の乾電池と比べて電圧が低いため、NXTブロックの液晶が暗かったり、モーターを駆動した時の回転速度が若干異なったりするので、入手可能であればこのEducation Setの購入を検討しても良いかもしれません(Amazon.co.jpでは出品されていないようです)。
情報教育とロボット
情報教育のための一つのアプローチとして、「ロボット」をテーマにすることにしました。
キーワードとしては
Lego Mindstorms
Raspberry Pi
Arduino
mono
Android
あたりでしょうか。ロボットの製作、制御等を通じて子供たちがコンピューターサイエンスに興味を持ってくれれば良いなと考えています。
目標というかクリアすべき課題
コスト
教育という前提に立つと、コスト面が非常に重要になってくるのではないかと考えています。というのも、教室で多数の生徒たちに教えようとした場合、相当数の教材セットが必要であり、複数人数でグループを組んだとしても１０〜２０セットの教材セットが必要になりますから、１セットでコストが１万円アップすると、全体では１０〜２０万円のアップとなってしまいます。
また、授業で興味を持った生徒が自分でも環境を揃えて、部活や自宅で遊んでみようと考えたときに、相応の価格で入手が可能であることも重要であろうと考えています。
発展性
授業を行うためには、あらかじめ定められた教材とカリキュラムから授業を設計することになりますが、授業が一通り終わった時点で、「もっと色々なことができそう」とか「自分だったら、もっとカッコいいものが作れるのに」と生徒が考えてくれることが重要なのではないかと思っています。
特に「ロボット」がテーマとなると、機械工学や電子工学、制御プログラミングが中心になりがちですが、それだけではなく、それらをどうやって「サービス」に結びつけていくのか。どのようなアプリケーション(社会との接点)が考えられるのか、というレベルまで展開できればと考えています。
認知的プログラミング
デザインパターンとその運用
GoF デザインパターンが発表されて２０年近く経過していますが、開発の現場では、その真意があまり理解されていないように感じます。特に Java プログラマが実装した C++ コードや、C++ プログラマが実装した C# コードなどでは、異なる言語仕様の上に自分が得意な言語での実装方式を無理矢理持ち込んでいるような事例を見る機会は少なくありません。
GoF の本を読めば、一番最初に書いてありますが、目の前に解決すべき実装上の問題があって、その問題の解決手法を抽象化したデザインがデザインパターンであり、実装については、実装を行う言語の言語特性を正しく理解した上で、どのように実装すべきかを考えるべきです。特定の言語における実装は、あくまで例であり、異なる言語で実装する場合には、再びどのように実装すべきかを検討しなければなりません。
確かに、自分の得意な言語があって、似たような言語であまり使い慣れていない言語を利用する場合には、過去の経験に従って実装を行うことは自然な流れであり、また新たな言語は「使い慣れる」までに相応の時間を必要とするため、前述のような結果になってしまうことは無理もない話ではあるのですが、そのコードをメンテナンスするプログラマに対しては、全てを書き直したくなる欲望との戦いを強いることになってしまいます。
問題記述におけるプログラミング言語と自然言語の持つジレンマ
GoF の本は、主として オブジェクト指向設計における実装時の問題とその解決方法に着目しているわけですが、その記述はサンプルコードが付属しているとはいえ、あくまで英語や日本語の自然言語での記述が中心です。
しかし、自然言語での論理記述は、文書化された RFC などの規約をもとに実装を行った経験がある方は思い当たる部分があるかと思いますが、自然言語での規約の定義はいざ実装してみると、抜けや矛盾を含んでいる場合が少なくありません。
つまり、プログラム設計時の問題をプログラム言語で表現すると、その問題の本質を覆い隠してしまい、かといって自然言語で表現すると、そこに抜けや矛盾を含んでしまうというジレンマが、デザインパターンに限らず、論理的な問題を的確に記述することを困難にしているとは考えられないでしょうか。
問題共有のための記述
長々と述べましたが、システム開発における成功と失敗を分ける大きな要因である情報共有を確実に行うためには、問題を的確に記述する必要があり、その手法について今後も考えていきたいと考えています。
