不定期戯言

今年もオンラインで講師を務めたわけだが，全員がマイクミュートという状況でしゃべるのがこんなに怖いとは思わなかった（昨年度は人数が少なかったからビデオもつけていて反応が見られた）。自分が話したことが伝わっているのかどうかわからない。オンデマンド用に動画撮影しているときには，反応がないのが当たり前だからそんなことは感じなかったのだが…。

今回はOBSを使って，クロマキー合成で背景を抜いて，画面の上に乗っかってしゃべってみた。なんだかLinux-Fake-Background-Webcamで自分がよく消されてしまうように思う。これは調整したほうがよさそうだ。

実はこの講習に先立ってPyPENの入力支援ボタンにすごく些細な変更を加えた。分岐やループのブロックを示す空白を，入力支援ボタンでは入れないことにしたのだ。というのも，その前の行でEnterを押せば自動的にインデントが入るようになっているのだから，予めスペースが入っていると操作の直行性がなんだか悪くなるように思われたからだ。

今回もオンデマンド発表。公開されている動画は全部一通り目を通した。リアルタイムとちがって見逃す心配がないので，実はこの方がお得かなとか思ったりもする。もちろんリアルタイムだと質疑とかでライブなところはあるのだけど。

PyPENにはURLにcode=…でコードを入力した状態で開くという機能があるが，これをするとカーソル位置の計算がおかしくなるのが気になっていたので修正。先月末に行った修正とこれで，だいたい不満に思っていたところは解決したように思う。

昨日までの3日，学校で情報の講座をやってそこでPyPENを使っていたのだが，使い勝手の点で気になる部分が出てきたので修正。たとえば入力支援ボタンを使うとエディタ部分がスクロールしてしまうこととか，右クリックメニューを変更しなくちゃとか，要するに日本語変換を一切必要とせずにプログラミングできるようにする修正を行った。よくある全角半角の混乱が防げるんじゃないかなと思っている。

しかし，たとえばイコールを入力するために「いこーる」を変換するという面倒なことをやる生徒って実際いるわけで，そりゃケータイでやろうと思ったらそれがけっこう手っ取り早いんだからしょうがないわなとは思うものの，何とかしたいことではある。

代入を「=」，等値比較演算子を「==」に限定することにした。また比較演算子もa<b<cみたいなのをOKにした。それに伴い，マニュアルやサンプルプログラムを修正。また，配列や辞書に不具合があったのでこれも修正。とりあえず落ち着いたかなという感じ。

久しぶりにオフラインな勉強会。講師は青山学院大学の伊藤一成教授。共通テストのサンプル問題を中心に話を伺ったが，問題を解く上での視点の違いについて考えさせられた。たとえばプログラミングの問題で，私は書く立場で考えるのだが生徒の多くは読む立場からの視点ではないかということだ。これは目からウロコ。プログラムを書く人になる場合はともかくとして，使う立場であれば多くの場合は読めればいいのだし。

Pythonではa<b<cのように比較演算子を続けることができる。Cでもエラーにはならないが，それはa<bかつb<cとは違う意味になるので初心者には厳しい。とりあえずPyPENもそれに合わせた変更ができることは確認したが，これをリリースするかどうかは悩みどころだなあ。

今のところ代入は「←」で比較は「=」を標準にしているが，それぞれ「=」や「==」でも書けるようになっている。どちらを標準にするか，あるいは前者を廃止して後者のみにしてもいいのではないかと言ったことで悩んでいる。というのは，共通テストのサンプル問題が後者になっていて，DNCLの後継（仮称DNCL2）はそちらになるのではないかという話があるからだ。今まで作ったものを書き換えなくてはいけなくなるわけだが，それでも変更するメリットがあるのかもしれない。これはかなり大きい変更になるからオプション扱いは難しい…いや，パーサを2つ用意しておいて使い分ければいいのか？それはそれで動作確認が大変だが…。

某解説動画を作っていたら，代入に「=」を使うとエラーになる部分があった。てっきり「代入の定義から間違って削っちゃったかな」と思って「←」に変更してやり過ごしたのだが，調べてみるとそういう事実はない。エラーになるのは「a=9個の0」というように「〜個の〜」を使っているところで，結局「〜個の〜」を演算子扱いしていることにより，「=」の結合規則（nonassoc）の影響を受けてしまったということらしい。「←」は演算子扱いしていないのでその影響は受けない。

「=」などの比較演算子をnonassocにしているのは，たとえば「a==b==c」が「a==(b==c)」と解釈されて，「エラーにならないけど思ったのと違う挙動をする（Cっぽい感じ）」ことを避けて「エラーにする」ためだ。しかしPythonでは「a<b<c」のような比較が認められているのだから，それに合わせて「a==b==c」を「a==bかつb==c」というように解釈するのも一つの解決になる。そういう感じの比較クラスを作ってしまえば解決するような気がするのだが，どうしたものか。DNCL2ではこのあたりどういう扱いになるんだろう。

そもそもは「=」が代入にも比較にも使えるとしてしまったことに原因があるので，比較は「==」でないとダメ，とするのもまた一つの解決になる。でもそれだとDNCL2と挙動が違ってしまう。

もう一つ解決方法があって，「=」などの比較演算子よりも「〜個の〜」の優先順位を上げて，「a=4個のx=y」のような比較演算を使うときは「a=4個の(x=y)」というようにカッコを強制するというものだ。それなりに悪くない気はするが，「a=4個の1+2」にはカッコがいらないのだからちょっと気分が悪い。

文科省から出された表題の事例集の中から，プログラミングに関するものを紹介する動画を作って再生リストにしてみた。例によって一発撮りで細かい編集はしていないので，動画としての出来はよろしくないが，それはそれ。

文科省のサイトで高等学校「情報」実践事例集が公開されたので，プログラミングのところをPyPENで実装してみようと思った。元ネタがPyPENのものは問題ないのだが，ライフゲームについてはなぜかうまくいかない。これは明らかにPyPENのバグなわけで…しかも先日気になっていたところと同じところに根がありそう。そんなわけで間に合わせ的にやってる前処理関数を全部廃止して，その代わりにマメにするべき処理をスタックに積むようにしてみた。これでだいぶ見通しは良くなったはず。なお，ライフゲームのプログラムはこんな感じ。たぶん実践事例集のプログラムは盤面初期化のときのhとwが逆になってる。