今年度の新講義その2: 全学1年生にSNSとの接し方を話しました

いまさらという感じなのですが、今年度初めて担当した講義の振り返り2つ目。6月3日に、勤務先大学の新1年生全員を対象に、SNSとの接し方について話しました。いわゆる新入生教育の講義の1回でして、他には片岡聡一総社市長も登壇されたようです。

そもそもこういう新入生向けの講義は、聞いてる側のモチベーションは高くありません。さらに、本学での時間割は午後の最初。昼食が終わって眠くなる時間です。

幸い、話題は学生さんには興味を持ってもらえそうです。そこで、幾つか仕掛けを入れて、学生さんのテンションを上げようと考えました。1つめが、この講義用にTwitterのハッシュタグ(#opusns0603)を用意すること。今の学生さんがよく使うSNSはLINEとTwitterであるという話を聞くので、講義の最中でもある程度はツイートしてくれるかも、という期待からでした。2つめが、アイスブレイキングを設けること。特に学生さんに他人事と思わせたくなかったので、インタラクティブなやり取りにしたいと考え、幾つSNSのアカウントを持っているかを挙手してもらう、“SNS”という言葉から連想することを学生さんにマイクを向けて聞いてみる、というものを用意しました。

そしてもう一つ。私から話を押し付けすぎないこと。私もSNSのアカウントは多数持っていますし、普段から使ってもいます。けれど、18歳そこそこの彼らとは、SNSとの接し方も、使い方も、生活に占める割合も、全く違うに違いありません。だから、彼らにとってのSNSを尊重した上で、それでもなお伝えたいことを伝え、彼らに考えてもらうきっかけにしてもらいたい。そんなつもりで話を組み立てました。当日使ったスライドを貼っておきますが、「明学生が考えたSNSのための5つの合言葉」を中心にしました。

そうそう、些細なことですが、私が講堂の壇上で話し、学生さんは客席、という形だったので、なるべくステージの前面で話すようにしました。Steve Jobsのプレゼンスタイルを意識しました。

で、結果がどうだったか、ということなのですが…上記のハッシュタグを見てもらうとわかる通り、アイスブレイキングと思っていたコーナーでタイムラインが暴走してしまい、それ以外ではほとんどツイートがない、という、予想外の方向に進んでしまいました。まあ、寝させない、という意味では成功したともいえますけど、講義としては反省材料が多かったな、と思います。

私もTwitterを講義で使うのは初めてで経験不足、学生さんも講義中に堂々とTwitterを使えるのは初めてでテンションが上がっている、そんな状態のときにランダムにマイクを向けたものだから…暴走はある意味当然でした。

一方で、技術的制限で今回はスクリーンにタイムラインを映すことができず、Twitterのアカウントを持ってない人は暴走に参加できずに蚊帳の外だった点も反省点です。勉強会なんかではタイムラインをスクリーンに映してますが、あれ重要なんだなあ、とよくわかりました。

数人の学生さんから講義後にいい感想のツイートがあったのが救いでした。あとは、学生さんのレポートにどんなことが書かれているかですねえ…まだ手元に来ていないので、期待半分、不安半分で待ちたいと思います。

ACM ICPC国内予選、初めて突破!

前の投稿の続きを書かないとなあ、と思いながら、1ヶ月。ちょっと号外的な出来事があったので、先にこっちを書いてしまいましょう。

さる6月26日に、ACM ICPC (International Collegiate Programming Contest) の国内予選がありました。で、私の勤務先である岡山県立大学のチームが見事、国内予選を突破しました。私が知る限り、うちの大学としては初めての国内予選突破だと思います。

ずっと以前は、腕試しの機会として、研究室の学生に参加を勧めていました。年に1〜2チームは参加していたかと思います。ただ、このコンテストに興味を持っておられる方ならご存知だと思いますが、事前にコンテスト用の対策をしっかりしておかないと、正直なかなか歯が立ちません。教員からの働きかけでは学生さんのモチベーションも上がらなかったのか、あまり対策もしないまま本番を迎え、当然成績は振るわず。そんなことを繰り返すうち、こちらも参加を促すことをやめてしまいました。

そんな中、今年は学生さんから「参加したい」と申し出がありました。他研究室の学生さんでしたので、一旦は、自分の研究室の教員にお願いしたら、とも言ったのですが、結局監督を引き受けることにしました。今思うと、以前のチャレンジの時のやり残した感が残っていたせいかもしれません。

国内予選が始まって驚いたのが、彼らの手の早さ。問題の把握も、アルゴリズムを考えるのも、コーディングも、すべてにおいて、以前のチャレンジの時とは全然違いました。過去問での練習など、自分たちでだいぶ準備をしていたようですが、地力も、うちの大学の学生さんの平均的なレベルからは段違いでした。易しめの問題A〜Cを解き終えた時点で、一時は25位につけていたと思います。これはひょっとしたら突破できるかも、と、こっちが熱くなってしまいました。

結局この後、問題D以降は正解を出せず、終了となったのですが、学生さんの可能性を実感できる、本当にいい体験でした。監督を引き受けてよかった。

11月のアジア地区予選は、まあ思いがけないプレゼントみたいなものですね。7問正解の東大チームに勝てるとは正直思えないですし。

プログラミングに関して指導できることはあまりなさそうだし(もう、ICPCに関しては彼らの方が上だと思います)、彼らが楽しんでいい経験を積めるよう、後方支援に徹して、11月に向けて準備をしてあげようと思っています。

今年度の新講義その1: TCP/IPネットワークプログラミング演習

今年度は、初めて取り組む講義が多い年です。現時点で3つ完了、今後行うものが2つ。長いこと大学の教員をやっていますが、大学が変わっていないのにこんなに新しい企画が多く来るのは初めてです。その中で、ここに書いても差し支えないものについて書いておこうと思います。

まず、2年生を対象にTCP/IPネットワークプログラミングの演習を行いました。いわゆるソケットを用いた通信プログラムの演習です。演習回数は2回、1回あたり2コマ(3時間)、プログラミング言語はCです。

ここ何年か、自分ができる範囲で、通信に関わるプログラミング教育を少しずつ充実させてきました。最初は何もなかったところから、Rubyによる簡単なWebアプリケーション構築、Webを支える技術に関する網羅的な講義を順に立ち上げ、今回、もう一つ下のレイヤ(TCP/IP)まで対象を広げたわけです。やっと情報工学側の教育内容と通信工学側の教育内容との橋渡しが一通り完成したかな、と思っています。

とはいえ、内容の構成にはかなり苦労しました。対象となっている学生は、1年生で一通りC言語の学習・演習を終えたところで、あまり複雑なプログラムを書くスキルは身についていない、という状態です。また、講義についてもちょうど同期に情報ネットワークに関する講義を受けている状態で、通信に関する知識がそれほど身についているわけではありません。このような学生たちにTCP/IPのプログラミングをさせるのは結構難しい。そもそも通信というもののイメージがつかめていない学生が大半でしょうから、多少の説明程度でソケットを扱うプログラムが書けるとは到底思えません。

そこで、プログラミングの課題は2週目のみとし、1週目はその準備をさせることに専念しました。

準備の1つ目は、ifconfig, netstat, dig, telnetなどのLinuxコマンドを通して、TCP/IP通信の概要をわかってもらうこと。これは一緒にこの演習を担当している先生のアイデアで、そのまま採用させていただきました。

2つめは、あらかじめ私が用意したTCP/IPサーバとクライアントのサンプルプログラムを実際に動かして、動作を確認すること。そして、次回への予習として、このプログラムのコードリーディングをさせることとしました。ソケット通信のプログラムでは、彼らがこれまで使ったことのないシステムコールを多用しますので、これらについても自力であらかじめ調べさせることにしたわけです。

ここで、演習内容とは直接関係しない小ネタを少し入れて、今時のソフトウェア技術者に必要なスキルをほんの少しだけ体験させることにしました。一つはGitコマンドとGitHubの利用。学生には、Gitコマンドを使って、GitHubからサンプルコードを取得するようにさせました。もう一つは、オープンソース界隈で当たり前のように使われているGNU configureを使ったプログラムのビルド。サンプルコードを、GNU configureからmakeの流れでコンパイルするようにしておいたのです。いずれも、細かい仕組みを説明するところまではやらなかったので、十分とは言えないのですが、いずれこれらを使う必要が出たときに少しくらいは足しになるかなあ、というつもりです。

2週目は、すでに配布したサンプルプログラムを改良して行う課題を2つとしました。1つは、通信メッセージの内容を少しカスタマイズする課題で、サンプルプログラムの流れがわかれば、基本的なC言語の知識があれば解ける問題。もう1つは、いわゆるエコーサーバの実装です。対象学生にはかなり歯ごたえがある問題でしょうが、サンプルプログラムをちゃんと読めれば、手が届かない問題ではないと判断しました。

提出されたレポートを見ていると、半数以上はエコーサーバまで到達しているようで、友人のプログラムをほぼ借用、というケースはあるだろうことを割り引いても、目標はまずまず達成できたというように思っています。中には、Cプログラミングと通信とが今まで結びついていなかった、という(ある意味衝撃的な)感想もありまして、こういう演習をやる価値を再認識させられました。

研究者のWebページはあまりモバイル対応できていない?

Googleが、モバイルフレンドリーかどうかを検索ランキングの要素として使い始めると発表したので、自分が管理しているWebサイトのモバイル対応を行いました。ほとんどはレスポンシブWebデザインにしてあったんですけど、見直してみると、Google Sitesを使っている自分のメインページに設定ミスがあったりして、見落としてるもんだなあと思いました。

やった作業はたいしたことなくて、自分でCSSを書いているサイトについて、Googleのチュートリアルにしたがって、viewportを設定して、600ピクセルをブレークポイントにしてmedia queryをかけ、簡単にスタイルを設定しただけなので、作業時間は2時間もかかってないです。まあ、本当はデザインを根本的に見直すべきなんでしょうけど、またそれは別の機会としました。

で、これからが本題。ついでに、自分の勤務先の大学内のページとか、同業の研究者のページとかがどれくらいモバイル対応しているか、Googleのチェックツールで調べてみたわけなんですが… ほぼ壊滅でした。大学内では、私が関係しているサイト以外どこもviewportの設定がないような気がしました。情報系やデザイン系の学部があるというのに、どういうことなんでしょう… 同業の国内研究者のページ(Webに関わる研究をやっている情報系の教員ばかりです)も同様でした。1つだけ、WordpressのWPtouchプラグインを導入しているらしきサイトがあったんですけど、このプラグイン、ブログの記事が時間順にトップページに並ぶので、研究室のような静的ページ中心のサイトだとあまり良くないと思います。

さらに、研究者のポータルサイトとして有名なresearchmapというサイトがあるんですが、これもviewportの設定なし。

確かに、研究者がWebにアクセスするのはパソコンが中心でしょうから、自分たちはこれで困らないと思うんですが、さすがに世間のWebの使われ方(モバイルファースト)と乖離しすぎのような気がするんですよね。現に、普段相手をしている学生たちはみんなスマートフォンでWebを見ているわけで、モバイル対応のサイトでないと彼らにアピールしづらいと思うのです。

企業だったら、自分たちがWebデザインに明るくないのであれば外注を考えると思うんですが、大学の研究者だと、 入門書を買って勉強するなり、Webデザインソフトを買うなりして、まず自分たちでやることを考えるんでしょうね。自分も研究者の端くれだから、その気持ちはよくわかる。ただ、それでは最低限のクオリティを維持できないほど、Webの現場の話が複雑になってるということなんでしょう。

あー、もしかして、研究者向けにいまどきのWebデザインの入門を書いたりすると、需要があったりするのかな。需要があるんだったら、やってみてもいいかな。

所属研究室名が変わりました

現職に就いて以来、ながらく「知能メディア工学研究室」という名前の研究室に所属していたのですが、つい先日、研究室の名前が「人工知能学研究室」に変わりました。教授が昨年4月に交代し、研究室として取り組んでいる課題が人工知能寄りに変わったためです。

もっとも、自分が取り組んでいる内容はやっぱり構造化文書やWeb、ソフトウェアで、特に変わるわけではありません。1年間、機械学習ベースの研究の話を聞いてきたけど、この辺はやはり勘が働きません。50歳近くになって乗り出すには畑が違いすぎるなあ、と改めて実感した次第です。

というわけで、関係者の皆様、引き続き宜しくお願いします。

松本吉弘先生の訃報

昨日、知人から松本吉弘先生の訃報を受けました。驚いてTwitterを検索してみたら、下記のツイートがありました。

松本先生のご専門はソフトウェア工学で、私の専門とはやや離れています。ですから、直接ご指導をいただくことはほとんどなかったのですが、にもかかわらず、印象深い方でした。

最初にお会いしたのは私が修士1年のとき、ちょうど松本先生が京都大学に着任された頃でした。私は当時ほかの研究室に所属していたのですが、カリキュラムの一環で、他研究室に出向いて短期間指導を受けるといった講義がありまして、すでにソフトウェアに興味を持ち始めていた私は、立ち上がったばかりの松本研を選択しました。

そこで、圏論に裏打ちされたソフトウェア設計の考え方に初めて触れたのでした。衝撃の一言でした。それまでに聞いたソフトウェア設計の講義は経験的な話が多くて、正直退屈だったのです。それが、こんなに理屈で裏打ちできるのか、と。まあ、すでに何をやったかも覚えていないし、それほど大した成果も出せなかったのだとは思いますが、体験としては強烈でした。

もう時効だと思うので書いてしまいますが、博士後期課程への進学を考えていたとき、松本研に行こうと、かなり真剣に考えていたことがあります。松本先生にもお話を伺いに行きました。その時、私はよほど深刻な表情をしていたのでしょうね。松本先生は穏やかな表情で「どうしたの?」というような言葉をかけてくださったように覚えています。そのときのご表情が、なぜか今でも印象に残っています。

当時の関係者はご存知の通り、結局その後、上林弥彦先生の研究室に進むことになり、松本先生とは、学科内の一教員と一学生、程度の関わりにとどまることになりました。それでも、この時の体験が心に残っていたのか、大学教員になってからしばらくして、松本先生の著書「ソフトウェア工学」をふと見つけ、手に取りました。

ここで、もう一度強烈な体験をすることになりました。この本の序文にこんな一節があります。

難しいということは彼ら(注: 学生)が敬遠する原因にはならない。難しくても面白ければなんでもやろうとする。(中略)数学(情報数学)的体系に基づいて構成的に話しが進められる部分に関しては、たいへん評判が良い。

先生ご自身の体験から出た言葉だと思うのですが、自分が自らの講義を通してなんとなく感じ始めていたことをはっきりと言語化してくれたのがこの一節でした。それ以来、どのような講義であれ、その裏に潜んでいる理屈を体系的に(聴衆となる学生たちがわかるように噛み砕きながら)示す、ということを常に意識しながら行うようになりました。

この「ソフトウェア工学」という本、すでに絶版になっているようです。私の宝物です。

松本先生に改めて感謝するとともに、ご冥福をお祈りいたします。

Rubyの代数パッケージalgebraを1.9.1以降に対応させました

Rubyで1変数または多変数の多項式を計算する、algebraというライブラリがあります。ところが、これ、Ruby1.8.7までしか対応しておらず、それ以降のRubyでは動かないものでした。

昨年末に、この件を知人の数学研究者から相談されまして、いろいろソースをいじくった結果、Ruby1.9.3以降で動作するようになったので、Githubで公開(kunishi/algebra-ruby2)しました。1.9.3-p551, 2.1.5, 2.2.0で動作をチェックしています。オリジナルのalgebraライブラリの作者である原さんには連絡をしまして、algebraライブラリのWebページからリンクしていただくことになると思います。

ただ、私自身は数学は専門ではないので、ソースに同梱されているテストを全て通すようにした、というだけで、まだバグが残っている可能性はあります。gemにもなっていません。

また、algebraライブラリはRationalクラスに依存しているのですが、Ruby1.9.1からRationalクラスの扱いが大きく変わりネイティブ化されたため、1.8.7以前では動作しません。そのため、オリジナルのalgebraライブラリに成果をマージできるかどうかは未定です。できたとしてもだいぶ先になりそうです。

データベースの教科書を一部執筆しました

知り合いの先生からお誘いを頂いて、昨年度からデータベースの教科書の執筆を行っていたんですが、このたび、ようやく刊行の運びとなりました。共立出版から出ている「未来へつなぐデジタルシリーズ」というシリーズの第26巻「データベースービッグデータ時代の基礎ー」です。

私は、この中の「半構造データとXML」という章の執筆を担当しました。半構造データやXMLについては名著「Data on the Web」の翻訳をやっていたりして、それなりにお声がけをいろいろいただける分野ではあります。今回も、懇意にして頂いている知り合いの先生が編集をされるという縁で、「XMLデータベースの部分を書いてもらえないか」という打診をもらいまして、お受けした、というわけです。

自分の得意分野とはいえ、やはり苦労もありました。まず、読者の対象が初学者で、かつ講義1回分、約20ページという制限があったこと。XMLの基礎だけでも、ちょっと詳しく説明すればこれくらいにはなってしまいます。でも、データベースの教科書の一部である以上、スキーマや問合せにも言及しなければなりません。

もう一つは、当初の企画案では、章のタイトルが「半構造データベース」となっていたこと。これはちょっと解説が必要ですね。普通に考えると、構造を持ったデータ(RDBのレコードなど)を少しゆるめた考え方として半構造データがあり、それを蓄積・検索する半構造データベースがある、そのような半構造データの一例としてXMLが有名である…ということで、普通のタイトルのように思うのですが、実はそうじゃないのです。

  • 半構造データは構造を持ったデータの集合も包含しています(なので、XQueryは単一の半構造データに対する問合せを想定しています)。ですので、『半構造データベース」なるものはないんじゃないかと。少なくとも私は記憶にありません。
  • 歴史的には、XMLのほうが半構造データよりも先に登場しています。つまり、XMLやHTML、あるいは電子メールのように部分的に構造を持ったテキストなどを包含する概念として提案されたのが半構造データなんですね。ある意味、アドバルーン的な概念と言えます。
  • そんな事情のためかはわかりませんが、半構造データの正確な定義はないように思います。少なくとも私は聞いたことがありません。大体こんなもの、という共通認識は、研究者の間ではあると思うんですけど。

企画案を直してもらうだけなら話は簡単なのですが、問題は、これが、情報工学の研究者から出てきた企画案だったということ。つまり、半構造データやXMLの専門家以外には誤解されている可能性が十分あるということで、誤解を解くように執筆する必要があるなあ、と実感させられました。

そんなわけで、結局、半構造データとその問合せの解説、ついで半構造データの一例としてのXMLとその問合せを解説し、次にデータベースらしい話ということで、スキーマの扱い、XMLデータのDBへの格納、SQL/XMLの話を加えました。もちろん、これを20ページに収めるということですから、本当に概要だけ、詳細は別の文献を見てくれ、というスタンスで、参考文献を結構あげています。XMLについても、あくまでデータベースの視点から話題の取捨選択を行いましたので、例えば名前空間なんかは完璧に省略した一方、識別子の扱いは比較的取り上げています(ID属性も、XPathによる識別子の代用も)。

書店には並びにくい専門書なので、実際にお手にとって見て頂く機会は少ないかもしれませんが、もし何かの機会がありましたらご覧いただけると幸いです。すでにいくつか誤植やバグを見つけて少々凹んでいますが、もしたくさん売れて重版されれば直る…かもしれません。

Google Readerのスターを一括で削除する方法

Reederが単独でRSSフィードを管理する機能を用意したので、Google Readerからのインポートを何度か試みたのだが、何度やっても途中でReederが落ちてしまう、という状態になっていた。いつも “Loading Starred Items” の途中で落ちてしまうので、Google Readerからスター付き記事のリストを取得しようとしている辺りで落ちているらしい。

そういえば、Google Readerでのスターを一時的なマーク代わりに使っていた頃があって、その影響もあって、スター付き記事の数が非常に多かったような記憶がある。20000は軽く越えていたような…

もっとも、スター付き記事を後で参照した覚えはほとんどない。というわけで、スターのインポートをあきらめ、Google Reader上でスターを一括で削除する方法がないか、検討し始めた。Google Readerの標準機能にはないようなので、何か方法がないかと検索してみると、ドンピシャのページがあった。

Jon Gallant: How unstar all Google Reader starred items

要するに、Google Reader上でスターを外していく作業をJavascriptで自動的にやらせよう、という方法である。手順は次のとおり。

  1. Google Readerをブラウザで立ち上げ、「スター付きアイテム」をクリック。
  2. スクロールを繰り返して、すべてのスター付きアイテムを表示させる。(というか、ブラウザのDOMに取り込む)
  3. 以下のJavascriptを実行。
var x = document.getElementsByClassName('entry-icons'); for(var i=0;i<x.length;i++)x[i].firstChild.click();

この人の作ったChrome機能拡張もあった。やってることは同じようである。

Chrome Web Store – Unstar All Google Reader™ Starred Items

この方法でスターを一括で削除した結果、Reederへのインポートが成功した。やれやれ。

以下、実際にやってみた経験からの注意点を書いてみる。

まず、手順2のスクロールだが、Google Readerに直接作用する機能拡張をブラウザに入れていると、このスクロールが非常に遅くなる。一回のスクロールで遅くなるのはごく僅かでも、スターの一括削除をしようとする(=スターが非常にたくさんある)状況だと、スクロールが度重なるので、「塵も積もれば山となる」という次第である。なので、この手の機能拡張はあらかじめ無効にしておく方がよい。私の場合、BufferPocket(特にBufferのほう)が該当した。

もう一つ。スター付きアイテムの数が多くなればなるほど、手順3を実行するときにDOMが非常に大きくなる。私の場合、20000以上のアイテムを全部取り込んだ状態で手順3を実行すると、ブラウザが反応しなくなってしまった。どうやらJavascriptは動いていたようなので、単にマウス操作に反応しなくなっただけのようだが、上のJavascriptは単純なことしかしていないので、手順が進んでいるのかハングアップしているのか、ブラウザの反応だけでは分からない。あまり精神衛生上よくないので、取り込むアイテム数を小分けにして、手順2と手順3を繰り返した。Google ReaderがAjaxをバリバリに使ったアプリなので、表示が乱れたりすることもあったが、Google Readerを立ち上げ直せば正常に戻ったので、単に表示だけの問題だと思われる。

今期の講義振り返り: Standard MLの講義、今年度で終了

半期ごと恒例の、その期の講義振り返り投稿です。今年はちょうど情報系のカリキュラム大幅改訂と重なっていて、担当講義がほとんど入れ替わるということになりました。旧カリキュラムの講義は今年度で終わりになる一方、新カリキュラムの講義が一部始まる、という感じです。

そんなわけで、今の大学に移ってきて16年くらい続けてきた、Standard MLを題材にした講義も今年度で終わりとなりました。まあ、実際は、今年度の受講生は過年度生だけで3人しかおらず、しかも全員が途中で出席しなくなってしまったので、実質は昨年度で終わりとなっていたわけですが。

この講義、白紙の状態から講義内容を考えた初めての講義でした。普通、講義というのは(その学科のカリキュラム編成から)ある程度題材が固定されていて、その範囲内で内容を考える、といった場合が多いのですが、この講義は、「プログラミング言語を題材にする」としか決まっておらず、選択の幅が極めて広いところから講義内容を考えることができたというわけです。

まあ、Standard MLを選択したのは、実は安直な理由でした。自分が大学生の頃から憧れの言語だったこと、そしてUllmanの書いた良い教科書があったこと。Ullmanの本は、型推論の理論などの説明もなく、どちらかというとリストや再帰といったプログラミングの基本的な知識、そして高階関数のような少し発展的な知識を実践的に述べる、というスタンスから書かれていて、プログラミング言語の専門書としては全然物足りないのでしょうが、私の大学でプログラミング言語を教える、という意味では、とても手頃なものでした。これに沿って教えていくうちに、「Standard MLを題材にして再帰や高階関数を教える」という、講義の骨格ができあがっていきました。

16年やってみて、実際のところどのくらい教育的な効果があったのか、というのは、自分ではよくわかりません。学生さんも様々ですから、Standard MLと相性がいいのも悪いのもいたように思いますし。

ただ、教える側から言えるのは、毎年楽しく講義ができたなあ、と思います。講義をやっていると、大抵どれでも、途中で「教えるのがしんどい」と思ってしまう回が何処かにあるものなんですけど、この講義はそれがありませんでした。講義の内容は程よく理論的になっていたほうが教えやすい、ということも、この講義を通して学んだことです。大体、そもそもの話として、これをやるまでは、自分自身が再帰や高階関数、型についてよく分かってなかった。教えているうちに、自分自身、非常に理解が深まったなあ、というのはここだけの話。

教員として、良い体験ができたなあ、というのが、正直な感想です。

この講義をやるうちに、いわゆる関数型言語が道具として面白く感じられるようになって、できればHaskellやOCamlあたりを研究の道具として使ってみたいなあ、と思ったりもするのですが、うちの大学の場合、大多数の学生にとっては少々高級すぎる道具(プログラミング言語)かなあ、という気がして、なかなか踏み出せないんですよねえ…まあでも、どこかで実践的に使ってみたいな。