良くも悪くもワンオペ（あるいは、「みんなでスキルアップ」へのジレンマ）
校内イベント「卒業制作プレゼンテーション」第1回を実施。 学生はライブ配信（YouTubeライブ）を教室で視聴してチャットで質問等する形式。
今回は設営から配信から撤収まで完全にワンオペ。 昨年は協力してくれた他の職員におんぶに抱っこだったので、初ワンオペ。
やはり、というべきか、 ワンオペは大変。 でもワンオペは楽。
大変なのは、全部1人で処理すること。 そのため、テストがすこぶる不便であること。 （音や映像を送り出す人と、受けて聞いてみる人がいないと、不便） そりゃそうだ。
他のクルーとのコミュニケーションは、実はかなりのコスト。 事前の情報共有、打ち合わせをしっかりしないと動けない。
また、本番中の各種トラブルや「想定外」にも全員協力して対応する。 そのためには、事前のコミュニケーション、プロトコルの共有が欠かせない。
というわけで、他人とのコミュニケーションコストが結構大きいので、 ワンオペは、その意味ではかなり楽。自分だけで考えて行動すればいいので！
しかしまあ、実施に人間1人ではマンパワーが足りないのは明白。 １ヶ月後の「第２回プレゼン」までには、状況を改善しないと。
他の人間にスキルをインストールして、プロトコルを通して、 真っ当に取り組んで、、みないとね。
怒涛のように溢れる見事なサウンド（または世界最高のピアニストの音に酔った件）
マルタ アルゲリッチの名前は、もう何十年も「世界最高」という意味。 モーツァルトも、ラフマニノフも、ルトスワフスキもラヴェルも、 一つひとつの音が輝いて、パワー溢れる見事なサウンド。
ホール中に響きが広がって、ちょっと音に酔ってしまうレベル。
卓越した技量で繰り出されるアウトプットは、どんな分野であれ そういうものになる。
コードを書いても、映像を作っても、ライブ配信の音を作っても同じ。 大事なことは「確かな技量と経験に裏打ちされた表現」であること。
「卓越した」技量でなくても、真っ当な、正しい技術がないと、 無駄が増えて、手間と迷いが増えて、クォリティが下がる。
何より「本当にこれでいいか？」なんて考えていたら、 いいものになるわけない。
「ゼロではないので、ゼロよりマシ」というレベルで、 ライブ配信と1人で格闘するのは、なかなか厳しい。
明るさや色の表現、そのためのカメラや編集の設定、テクニック。 音を揃えるために必要なテストと道具立て、チェックと音作りの段取り。 映像づくりのためのライティング（これは経験ゼロ）。
基本的に学ぶのが好きで、新しい技術に取り組むのが楽しいタイプ。 とはいえ、確実な何かを辿って進んでいきたい。
もちろん繰り返しと膨大な時間をかけて経験値をうっすら 重ねていくのも好きだけど、業務上の取り組みとしては、 もうちょっと効率よく進みたい。
というわけで、とりあえず、できる範囲で格闘しながら ちびちび新しい取り組みをこなしていく日々。
（要するに明日のイベントを何とか乗り切りたい）
校内イベントの配信システム（または、言わなきゃわからない者はやらなきゃわからない件）
卒業年次の学生が取り組む「卒業制作」。 作るだけではなく、3回のプレゼンテーションがあり、今週金曜日は第1回。
コロナ下の近年は、スピーチコンテスト同様に１部屋を会場として、登壇者 以外は各教室でYouTubeライブを視聴、という形式で実施。
ホールを借りて実施していたのに比べると、テキストで気軽にコメントや質問ができて便利。 録画も残って見直せるのも助かるし。
しかし配信を担当するとなると、なかなか面倒であって頭の痛いことではある。 先月末のスピーチコンテストでは、学生7名の協力により運営できたが、今回はワンオペ。
なぜなら7名とも2年生で、自分たちのプレゼンがあるから。 もちろんそれは大事なことで、十分に経験値を積んでもらいたい。
また、カメラも少なく、カメラワークが必要ないので、ワンオペで問題はなかろう。 （現実的には、これまで他の誰かにオペを任せて周辺のサポートにあたっていたので正直きついけれど、まぁこなせはする）
問題は、スキルが低いためサウンドのコントロールや映像の明るさをきれいに揃えられないこと。 これは当分どうしようもない。勉強と練習とテストが必要。経験値が貯まらないとLVアップできない。 （LVアップに際して呪文を身につける仕組みに、ようやく共感できる今日この頃。40年くらいかかっとる）
あともう一つが、周囲の様々な人間が、映像・サウンド・配信について知らないために配慮ができず 迷惑なアクションをすること。
産学連携ということでベテランエンジニア＆経営者の方が卒業制作の指導に協力してくださり、 プレゼン当日もオンラインで視聴してコメントしていただける予定だったのだが、、 いつの間にか会場に来られることになっていたりして。
ワンオペだっつーのに、カメラが1台余計に必要。 また、電子黒板の配置を変えて、登壇者への返しモニタにしようと思っていたが、 会場に観客がいるとなると、スクリーンとして必要になった。
決めてきた人間に悪気がないのは知っている。長い付き合いで、その点は信頼している。 しかし、配信への影響を想定するとか、できなくても事前に相談するとか、そんな対応が あればかなり便利。つまり、ないのでかなり不便。
もちろん自分でも、取り組んでみたからようやく少しずつ、色々わかり始めたわけで、 体験無しにそれを想像するのは難しい。というか自分では無理。絶対できないと思う。
ただ、そういう未知の要素があるんじゃないか、という気遣いは、できてもいいだろうに とは思う。自分の能力がそう高くない事を知っているので、経験に裏打ちされた理解がない時は 経験者に相談し、共犯者になってもらう習慣はある。
まぁそれは、心の余裕、健康と、教養の問題。 知らないことに対処する、見えないものを見るのは、面白いんだけどね。
もちろん、経験するに如くはなし。 ていうか、やってみろよ、まず。
、、と、そこまで計画し、実行可能な段取りをつける能力がないもんで愚痴ることになる。 マインドフル瞑想でも、日々取り組んでみようかな。
レンズ（マニアックなハードウェアに向かいあわされている件）
カメラはレンズで光を集めて映像を得るデバイス。 レンズの性質によって、得られる映像は当然変わるもの。
しかし、その性質を決める特徴は様々あって、 好きでもなければなかなか頭に入ってはこない。
一つのレンズであるから、仕組みについて納得すれば それぞれの意味がわかり効果がわかって選べるように、 多分なるのだろう。
ホワイトバランスや露光、色温度などの設定、 フォーカスや露出のオートとマニュアルなどなど。 良い映像を知っていて、目指すものが明確ならば コントロールに必要な指標として操作できるのだろう、おそらく。
しかしまぁ、カメラには興味がわかない。 光に興味ないかというと、朝日や夕陽、日暮れどきの山並みの 色が変化していく様は素敵なのだが。
これまでに一度だけ、写真を見て「写真の力」を感じたことがあった。 多摩美大の卒業制作展で、なんてことのない自然な田舎の風景だったのに 妙に惹きつけられる、パワーのある写真。
制作者がいたので話を聞いてみると、エフェクトなどの加工は一切なし、とのこと。 撮って現像しただけで、ぐいっと迫る力（そうか迫力か）が出る（込める？）とは、 摩訶不思議。
いずれにせよ、、先日のスピーチコンテストの録画で、一眼とビデオカメラの 映像にあまりにも差があったのは、かなわん事実。
次のイベントでは、カメラが少ないからリスクも小さいけれど、ちょっとは 機材をコントロールして状況に対処できるように、準備とリハーサルをしておこう。
サーバサイド プログラミング with PHP（ITを学ぶのに想像力が必要な件）
久しぶりに、PHPによるサーバサイドプログラミングの授業。
本当は、Javaサーブレットと書いてあるのだが、変更した。 そんな効率の悪いことはできん。
サーバサイドでもクライアントサイドでも、システムの「奥行き」を 感じていないと理解が全く進まない。
システムの構成を図に描くと、２次元の平面でとりあえず描く、 描けてしまうけれども、「webサイトを作ろう。サーバも動かして」 となると、話は別になる。
そもそもパソコンの画面で起きる現象を見ていると、その裏側の システム、その構造を把握するのは難しい。
HTMLでwebページに何か表示するのと、 JavaScriptでwebページに何か表示するのと、 PHPでwebページに何か表示するのと、 どう違うのか？ どう選ぶのか？
HTMLで書くと、ページソースを見ても内容は確認できる。 JavaScriptで書くと、条件によって内容が変わったり、エラーによって表示されなくなったりする。 PHPで書くと、webブラウザ側では結果を受け取るだけだから、どう制御されているかは見えない。
何をしたいか、どうやりたいか、で決めれば良いのだが、 それを考えるには個々の性質を把握していないと、 どう違うかがわからない。従ってどう使い分けるかわからない。
つまり、単純に「こうもできる」「こんな方法もある」と言われても、 一つのことを実現するのに複数の手段があったら、困るだけ。
「操作と結果」だけしか頭にないと、決められない。 また、それぞれの関係がわからないので、「なぜ複数あるのか、学ぶのか」 意義がわからなくなる。
意義のわからない事に取り組んでいる／やらされていると思うと、 自己肯定感、自己効力感が落ちる。
徒労になり、とりあえず動けば同じ、という考え方に落ち着く。
そんなふうに考えている輩にインストラクションするのも 10倍くらい徒労感が溢れるので、やっておれん。
というわけで、サーバサイドプログラミングを学ぶ機会があるなら、 「サーバを起動」して、DocumentRootにコンテンツを置き、 codeを書いてダイナミックなwebページを作ってみるのが良い。
一つずつ概念に触れて、整理していく。 「client / server」のやりとりを脳内に描き、 「Not Found」はサーバが動いてないと見られない（サーバが動いているとわかる）ことを知り、 「入力フォーム」でユーザが入力したデータがどう受け渡されていくかを観察する。
メッセージ一つでもいいから、webブラウザで入力されてからDBに格納されるまでの 流れを把握できると、「仕組み」と「振舞い」がわかってくる。
もちろんそれは、Javaサーブレットでも、できないことはないのだが。 サーブレットエンジンが入ると、役者が増えすぎて理解が面倒になる。
「システム」や「関数」、「写像」などの概念を身につけていないと、 ただ単に「扱う単語や手間が増えただけ」になってしまい、効果が減。
そこで、XAMPPでいいから、自分の手で動かしてみよう、となる。 いずれにせよ「仕組み」と「連携」を想像して理解する能力は必要だが、 比較的扱いやすいので、エクササイズを順番に与えると、わかりやすくはなる。
もっとも、そもそも仕組みを把握しようとする心がないと、、 それは、どうしようもない。全ての取り組み、試みは崩れ落ちる。
だから、「話を聞いてない」「理解しようとしていない」とか、 そもそも「理解する／できた」経験がなく、正しい状態を知らない、 というのは悪である。
知らない／わからないものが、わかる／できるようになる事を 経験していないと、まぁ対応できない。
つまり、変わる事の意義、変わる方法を知らない・信じてないので 行動できない。従って永遠に変わらない。即ち学べない、学ぶ能力がないのである。
ITじゃなければ、、操作と結果だけでこなせる部分もかなりあるだろうけど、 画面で覗くしかないITは、想像力に支えられること大なので、まぁ厳しいな。
Flaskとファイル操作（または、２＝１＋１ではない件）
期末テスト代わりの演習課題として、Flaskでwebブラウザからの入出力と、 ファイル操作の組み合わせ。
入力フォームを使ってブラウザからデータを送信する練習。 基本的な入力として、5つ。
・テキスト( type="text" ) ・パスワード( type="password" ) ・ラジオボタン（変換するな、mac。。🔘）( type="radio" ) ・プルダウンメニュー ( select ) ・テキストエリア( textarea )
先週までに「テキスト」と「パスワード」しか扱っていなかったので、 他の3つを追加。
まず一つずつ、フォームを作成して、送信〜受信〜データを出力、の練習。
<form action="radio_app" method="POST"> 神奈川<input type="radio" name="address" value="kanagawa"> 東京<input type="radio" name="address" value="tokyo"> <input type="submit" value="OK"> </form>
色々書くものはあるけれども、、とりあえず動作させることを優先 & 可能な限りコンパクトに。
from flask import Flask, render_template, request app = Flask(__name__) @app.route('/radio') def radio(): return render_template('radio.html') @app.route('/radio_app') def radio_app(): address = request.form['address'] return address if __name__=="__main__": app.run(debug=True)
などと1個ずつ試しておいて、最後に「今日いちばん難しい問題」として、 「入力の全種類を使ってフォームを作成せよ。また、受信したデータをテキストファイルに書き込むこと」
テキストファイルへの書き込みも、前回やってあるので、 新しい要素はなし。調べる必要もなし。
しかし、、初心者にやらせるには「２＝１＋１」ではないことを知る必要がある。
要素技術が個別に揃っていても、それらを「組み合わせる」スキルが必要だからだ。
学生には、「アッポーとペンだけで、アッポーペンにはならない！」と体感できる問題になる。
具体的には、学生は単純に積み重ねようとするので、 1ページに「フォームが5個」ある状態になる。 （当然、submitボタンも5個ある！）
でもそれでは、5種類のデータを同時に送信できないので、 少し抽象化して整理できた者だけが、一歩進んで入力フォームを 扱えるようになる。
簡単なことだし、できてしまえば大したことでもない。 しかしながら、できない者には永遠にできない。
まず「こう書くと何ができるか、どんな仕組みなのか」が、掴めるか否か。
次に「組み合わせるとどうなるか、どう扱えば”合体”させられるのか」が壁となる。 1種類ずつのフォームの「形」ではなく「仕組み・ルール」を把握して使えるか、ということ。
まじめに丁寧に「書き写す」だけじゃダメだと、役にたたんと知るかどうか。 技術を学ぶ上で、そこが一番の「壁」。
プログラミングを基礎で言うと「繰り返し処理の中に条件分岐を入れる」ようなもの。 「if文」を習って、「for文」が書けた後、その2つを組み合わせて使えるかどうか。
毎年プログラミングの授業では、「helloと繰り返し30回出力。ただし5回に1回 ALOHA! と出力させろ」 を出題する。
まぁこれが、全然できない。 それはわかっているのだが、要素技術を知っても「組み合わせ」のスキルはまた別に要る、 ということを教えるには少し教師にもスキルが求められる。
もちろん学生にも、きちんと取り組む態度が要求される。 自分で考えることができないと、「知っているのにまだ何かが足りない（から、できない）」 という状況にならないから。
「正解を見せてもらって実行するだけ」とか「ググって見つけて、とにかく動けばOK（意味わからなくてよい）」 などと思っている、あるいは、メタ認知のかけらもなく「そういう態度で生きていくことしかしていない」者は、 そもそも気づくチャンスがないので、変われないし変わらない。
「学ぶことは変わること」なので、変わる能力がない者は永遠に変わらない。 そういう人間を作っちゃダメなんだが、、世の中の大人は、18歳までにそういうダメな躾を してしまうんだよなぁ。ホント勘弁して。
動画の収録と編集は「計画的」に！
先日のスピーチコンテスト動画、とりあえず版を公開しておいて、 ディレクターズカットにかかろう、と思っていたら、やばかった件。
Final Cut Proにも慣れておかねばならんので、クラス毎に1本ずつ まとめてみようという取り組み。
いや本当に、やばすぎる。 これをやってたら地獄を見る。
配信クルーはかなりの対応力を発揮してイベントを回してくれており、 本当に感心＆感謝するところ。
しかしイベント全体の段取りが悪く、演者のリハーサルは一切なし。 すなわち、ほぼ「切り替えを待たずに喋り始める」という惨劇。
エコーを避けるため、ミキサー側ではいちいちマイクをON /OFFしていたので、 合わせ技で音声はえらい事になっており、揃えるのが大変。
単純にゲインを上げても、遠いマイクに入った音なので、ノイズが拡大されてかなり不自然。 それがまた、セリフの途中まで／途中からなので、どないするもんか見当もつかない、、
トーシロが背伸びどころか走り高跳びしても届かない感じ。 何ができるか、何からやるのが適しているか、判断するスキルがない状態で 無理矢理やってみるのは、なかなかキツい。
コーチがいるなら、素直に反応してアドバイスから吸収すれば良いが、 いないので、、徒手空拳で殴りかかる感じで結構しんどい。
知識、経験、スキルがあると楽になるもんだと、体感的想像ができて、 面白いといえば面白いけれど。
まーなんとかクリンチとロープに逃げながら、しのぐしかない。 笑えるくらいやばいので、割り切りやすいのが好都合である。
とりあえず。
