blog.8-p.info

公立小学校教員の残業代訴訟というのがあり、藤井孝良さんが原告のひとの記者会見の言葉を紹介していた。

「パソコンを打ちながらだと人の気持ちは伝わらないから、記者の皆さんも手を止めて聞いてください。後で紙を見せるので写メしてください」と、判決後に文科省で行われた記者会見で、田中まさおさんが記者たちに一言。それに続いて語った言葉が、記事には載せなかったけれど、胸に刺さりました。

現場の先生たちは、働かされています。児童生徒が行ったテストの丸つけは、仕事に当たりませんか。授業の準備は、仕事に当たりませんか。欠席児童への連絡はどうですか。朝の登校指導は仕事ではありませんか。これらは、毎日のように行われている教師の仕事です。

一方で、シアトルでは、Seattle Public Schools (SPS - 雇う側) と Seattle Education Association (SEA - 先生など雇われる側) が労働条件について交渉しているのだけど、SPS のほうは “Competitive Pay” といっている。

We know that competitive pay and high standards of excellence provide teachers with the resources and support they need to create positive learning environments and are offering a substantial package.

給料の話をするのはえらいなと感心していたけれど、結局条件は折り合わず、9月にはじまるはずの学校がまだはじまっていない。SEA のほうは What’s at stake – SEA 2022 Bargaining という PDF で、SPS と SEA の提案の違い (つまり「SEA の方が良い」という主張) をまとめている。

そもそも日本の公務員には団体行動権 (ストライキとかする権利) がないので、これは個々人に帰する問題ではないのだけど、こういうのを背景に育つと、物事の見方も変わるよなと思う。

karino2 さんに返事をもらったので、その続きです。

個人的には、自分のなかで一番すごい、これこそ私の代表作だと思えるもの、他人の認めるもの、ヒットしたもの、は一致すると素晴らしいけど、バラバラでも良いと思っていて、なので世界をロックしなくてもいいかなあと思っています。

そもそも、9割くらいを自分が書いた、そこそこ複雑なソフトウェアというのが無いので、まずはそこからかなあと。短編しか書けない小説家みたいな。一方で、仕事でやるときは、逆にあんまり書かないというか、枠組みを作って周囲の人々を活躍させるほうが好ましい、というノリを感じるので、そういうところでも趣味でやったほうがいいのかも。

コンピューティングの世界は、その世界で使われるものを作るには中にいたほうが良いのだろうけど、結果として作るものが内向きになるような気もしています。

ひとでさんの日記を読んだら、Make Time のことを思い出して、またスマートフォンからブラウザを消してみた。

ブラウザを消すと、私の「ふとした瞬間にスマートフォンを見てしまう」度は極端にさがって、例えば昼ごろに「あれ、そういえば電話どこにおいたっけ?」となって、寝室で発見したりする。ふとした瞬間にスマートフォンを見るのがすごい悪いかというと、これは好みの問題かと思う。私はあんまり好きじゃない。マルチタスクはせず、細切れの時間にはなにもせず、適度に退屈しているほうがいい。

一時間くらい電車に一人で乗るのなら本とか読みたいけれど、最近は自宅から働いているので、そういった時間はあまりないのだった。

出先で調べものをする必要のないくらいの、繰り返しあるいは守りに入った生活をしていることに、ちょっとの不安を感じなくもないけれど、まあこれは別の問題。

プログラマが一番凄いものを作ろうと思ったら、仕事でやるのと趣味でやるのどっちがいいの？的雑談 を聞いた。

すごいもの、色々と尺度があると思うけど、例えば初期の　SQLite や Git とか、mold とかは一人で作っているのですごいなあと思う。GIMP は二人、GitHub も最初は三人ではじまったわけで、少人数で出来ることは色々とある。

外野からみると、

1. よい問題をみつけて
2. その問題にある程度の時間とりくんで
3. 結果を出す

という3つができるといいのかと思う。

1は、仕事でやると人々からの助けがある一方で、会社にとってのよい問題で、自分にとってよい問題となると、その集合が重なる部分は結構小さくなってしまうので、なかなか難しい。

2は、最近の自分が「時間がない」といいわけにしがちだけれど、一日に使える時間が半分になったら期間を二倍にすればいいはずで、どちらかというと持久力の問題のようにも思う。例えば Oil とか2017年からずっとやっている。

3も、1と同じく定義には色々と幅がある。完走して、とりあえず動くものができれば良しとすることもあるし、一定のシェアをとることを目指すこともある。仕事でやると「出来ました」で終わるわけにもいかないけれど、趣味だったらそれでいいのかなとも思う。これは「すごいもの」「よい問題」とかの定義にも戻ってくるけれど。

Make checkContainerTimestamps less strict on Windows

containerd には「なにか変更をした後には、UpdatedAt が CreatedAt より後ろに更新される」というテストがあるんだけど、Windows でたまに失敗している。

調べると、Go そのものほうに testing: benchmark is using low resolution time on Windows というのがあった。すでに、I want off Mr. Golang’s Wild Ride で触れられている話ではあるけれど、Go の time.Duration に時刻とモノトニックな時刻を同居させるのは、ちょっと無理があった気がする。

テストが失敗するのはよくないので、取り急ぎ、チェックをゆるく (Windows に限り、更新されていなくても、巻き戻っていなければよいということに) した。