PEUGEOT 106S16

先月とうとう106を売り払って新車を購入しました。予算は前回の半額以下で国産車ですが、いくつもの快適装備にびっくりしています。

もう思い出すこともないでしょうから、106を売った理由であるトラブルの数々を思い出せる限り書いておきます。

フルシーズン

エンジンがかからない。30分かからなかったことアリ。(購入3年目くらいから。これが買い替えの決め手)

荷室ランプがつきっぱなし。(オカマ掘られた後から。フレームゆがんだみたい)

外気導入ボタンを押すとカチカチ音がする。(3年目くらいから。部品交換後も発生。最近は回路をきってもらった)

ウインカーが必要以上にチカチカする。左折してウインカーが戻った後もチカチカがとまらない。(2年目、クレームで処理)

左テイルランプがサビてつかない。(オカマのせいで水が入った。交換費高かった)

クラッチがたまに戻らない。(2年目から。ダブルクラッチに慣れた)

夏期

エアコンが効かない。エアを詰め替えたが空気が入ってしまうらしい。(最近)

エンジンの回転数が上下する。アクセル踏むとエンストする。(2年目、クレームで処理)

オーバーヒート。(最近。冷却水が減ったため。何で?)

冬期

助手席ドア閉まらない。閉めるとバーンとはねかえってくる。(5年目くらいから。面白い。無視)

助手席ドア開かない。内側も外側もレバーを引いてドアが開かない。(同上。結構アセる)

運転席ドア閉まらない。必ず半ドアになる。(最近。外から押せばヨシ)

いろいろとトラブルがあり修理費も総額(オカマ別)で100万を越えたと思いますが、エンジンのかかり以外は全て許せました。今まで乗った7台の車の中でも一番気に入っています。(動いた後の)エンジンとハンドリング、身の軽さは本当に素晴らしかったです。

2勝1敗

学園祭で学生さんたちとAIBOサッカーの試合を行いました。帝京科学大学の先生と組んだ教員チームとして、何とか2勝1敗得失点差+2で終えることができました。

2体のフィールドプレーヤーは正味1つのプログラムだったので、案の定2台が同じボールを取り合う状態になったのですが、1台に後から加えたプログラムにバグがあってボール直前で止まったため、別の1台がシュートに結び付けられたという笑えない勝利ではありました。

相手がいるというのはいいことで、互いの学生さんにとっても刺激になったのではないでしょうか。

久しぶりのサッカープログラム

今年も学園祭でサッカーの試合をすることになりました。もちろんロボットに対戦させるわけですが。同県の他大学と対抗試合をするということで、私は免れるのかと思っていたのですが、どうやら教員vs学生という対抗試合もするそうで、私もプログラムを作らざるをえないはめになりました。

久しぶりのビジュアルプログラミングは楽なところもあり、難しいところもあります。新しいシステムを横で作っているので、そっちを使いたい衝動にかられますが、やはりフェアに学生さんと同じ古いシステムで作っています。

いろんな他の人のアイデアを取り入れながらほとんどスクラッチから作っています。どんな結果になるのやらです。

Defart改造

20061016100754

20061016100807

本丸のプログラミング部分は手をつけずに、外回りの改造に着手しました。現在、AIBOと通信しながら各種の設定を管理しているAiboSessionと、プログラミング部分とが別々のウィンドウに分かれています。これは複数のウィンドウで状態遷移図を扱おうと考えたからなのですが、実際にはそのように実装せず1つしかプログラムウィンドウを開けず、ボタンで複数の状態遷移図を切り替えています。そこで、プログラムとAIBOの管理とを一体化させて、AIBOを使いながらデバッグが容易になるようにしました。

20061016100832

20061016100820

AIBOを動かすにはそれなりの設定が必要です。また、スタンドアロン環境とネットワーク環境の切り替えも面倒だったので、その辺りを抜本的に改造しようかと思っています。ずっとListMorphやPopUpMenuに頼っていた部分を思い切ってアイコン化する予定です。多分、見た目は随分かわるんじゃないかと思います。ネットワーク関係やデータの持ち方も大きく変え、大規模なクラスもかなりリファクタリングしました。

ここ半月ほどコーディングから遠ざかっていたのですが、とりあえず上のような改造を施すのが2、3日で済むのはsqueakのありがたいことです。

Post Defart(続き)

さて話を元に戻すと、やはりというか「矢印のついた線」は動作の流れを直感的に理解できるようです。いいかげんに教えてもちゃんとそれなりのものを作ってくれるのはその効果によるところ大のようです。一方で状態の理解は難しいです。ほとんど最初の時点では誰も理解なんてできません。

初めてDefartでプログラムを作ると状態の意味がわからないので、どう作っていいか困ります。「意味は自分で与えるのだ」というと更に途方に暮れます。

しかし、状態を2つ配置してみて、その間を矢印で結ぶと何かの動きをするわけです。いくつかの状態をつなげていくと何らかの仕事をしてくれます。そのうち状態は一連の仕事の到達点(過程の場合もありますが)であることがわかり、後は放っといてもプログラムを作れるようになります。この辺りの試行錯誤を横から見ているととても面白いです。

で、今後どうしていくのか?ですが、状態を残しつつ矢印線のあたりを改良しようかと思っています。無駄な状態の増えるのを極力抑え、クモの巣にならないようなものです。具体的なイメージは「人生ゲーム」です。人生ゲームのような「少しずつ仕事しながら最終的に大きな目標を解決する道筋を作るプロセス」をプログラミングと捉えようというわけです。山有り谷有り、時には後戻りありなど。他にも今までにない機能を入れたいとは思っています。人生ゲームにおける「さいころ」のようなものです。まあ、この辺りは作ってみないとなんとも言えないのですが。

目の悪いときに限って視覚的なものばかり書くのは因果なものですね。

Defart芸術

余談ですが、プログラムを奇麗に(構造的にわかりやすく)書くことやインデントを推奨することを実践させるのは結構大変です。多くの学生さんはスペースやタブをケチり行をケチります。FORTRANを教えているんじゃないかと錯覚するほどです。(点数とかで)脅迫(!?)するか授業がかなり進まないと実践してくれません。

ビジュアル系の環境の良いところは見てすぐわかる点ですね。美しい汚いの感覚は人によって異なりますが「明らかにぐじゃぐじゃ」というのは結構共有されます。後ろから覗き込まれたとき、伝統的言語では「どうだ難しい事やってるだろ」というのが、視覚的言語では「汚いから後で奇麗にするんだよ」に変わるのは面白いところです。

美的感覚でいうとDefartを使う学生さんには、左右対称派と円配置派がいるようです。(もちろん抽象芸術派もいます)

Post Defart

いろいろとDefartの次のVisual Programming環境を考えています。

現在の状態遷移図ベースを続けるか、別の方面でいくか。いろいろと学生さんのプログラミング活動を見ているとそれほど苦もなく作っているように見えますし、問題は別のところ(例えばデバッグ環境など)にあるようにも思えます。

状態遷移図で困るのは状態を結ぶ線の扱いです。放置しておくとたいていのプログラムはスパゲッティというかクモの巣状になります。状態遷移図をやめようかというのはこの辺のわかりにくさを解消したいからでもあります。

ただ、インターフェイスの悪さもあって、そのうち業を煮やした学生さんが自主的にスマートな構造を自分なりに作り上げて行くのは予期しない効果であるのですが、デバッグが重なっていくとやっぱり大変なことになります。