だだもれ

2017年12月17日

結局仕事が忙しい上に家にいる時には家事やら何やらあって PCをいじっていられるような状況ではなく、 未だにutf8化ができていない。本当どうしたものかな。 とりあえずせっかく買ったwindows機で日記をいじれるようにしないとなあ。

今度社内の勉強会で何かしゃべらないといけないのだが、 何も考えてない。昔やったようなネタを焼き直してもいいが、 あまりハード寄りだったりアルゴリズム寄りだったり数学寄りだったりすると ウケが悪かろうし、仮に面白がられたとしても一時のことになっては 時間を使う甲斐がない。Unityを使うのは、面倒な下層を他人に押しつけるため なのであって、私が新人だった頃のコンパイラやハードのSDKのような位置に、 UnityなりC#なりが座っている。ハードウェアがどうなっているかなんて UnityでUGUIを使っている分には意識しようもない。 そういうネタはダメだ。 もっと即席で使えるネタがいい。 となれば、ここ最近で私が実際に取り組んだ問題が良かろう。

一つはテストだ。 ゲームにバグがないかどうかは、結局のところゲームを動かして操作してみないと わからない。厳密に言えば操作したところでバグの有無がわかる、 というわけでもないのだが、大抵のバグはたくさん操作すれば出てくる。 しかし、人間が操作するのは効率が悪い。まず人件費がかかる。 次に、人の行動にはムラがあり、漏れやすい。 全場面で画面のあらゆる部分を偏りなくタップする、 などというテストはとてもできない。 実際に遊ぶのは人間であり、作るのも人間なので、 間違いを入れやすく、かつ、実際に行われやすい操作を狙う、 というのは人がやる方が向いている。そういうテストは人力の方が良く、 実際そのために人を雇うわけだが、 そこまで凝ったものでもない単純なテストに人を使うのは下策だ。 そういうわけで、毎晩コンピュータに自動で遊ばせておき、 おかしなことが起こらないかの検査をてんこもりにして、 毎朝間違いがなかったかチェックする、というのはいい手だと思っている。 問題はそれをどう実践するかだ。 これについては最近やったことなのでそれなりに話せる。 ただ問題は、技術的な側面よりも運用面の方が厄介が多いということだ。 仮にそういうテストができたとしても、 毎晩PCを回しっぱにするには、PCを持って帰らないで動作状態で 置きっぱなしにする、ということが必要になる。 スマホ実機もできるが、Unity開発はとにかく実機で動かすのが面倒くさい。 PS3ならF5押しておしまいなことが、gitで上げてjenkins叩いて ビルド待って、できたらインストールして、みたいな話になる。 面倒くさすぎてやってられない。 私は一台のPCにプロジェクトを2つクローンしてUnityも2つ起動して テストしているが、これですら結構面倒くさい。 この面倒くささを取り除くべくいろいろ整備することはできるが、 その整備は相当面倒くさいだろう。

あとはUIのコードの書き方について。 とあるシーンにボタンがあって、そのボタンが押されたら ゲーム進行を司るクラスまで情報を上げて通信し、 通信の返答が来たらそれに応じて処理をする、 みたいなことをやるとする。ボタンは複数あって、 あるボタンが押されたら、その通信が終わるまで他のボタンは 押されないようにしたい。 また、ゲームの進行を司るクラスから、個々のボタンの有効無効を 切り換える信号が来たりもする。時間が経ったら無効になるとかだ。 こういうのをどう書いたら楽で間違いが起きないか、という話である。

仮にクラス群が木をなしているのであれば、 ボタンは末端にあるクラスだ。 コールバックであれ直接呼び出しであれ、ボタンが押されると 根の方向に情報を伝えていくことになる。 子が親の参照を持つことになって、双方向リンクになるので、 片方向よりはバグりやすい。片方だけ参照が切れる危険もある。

2017年12月11日

ひどく日記が空いて、ついに1ヶ月丸々何も書かずファイルが抜けるという 事態に至った。 さらに、ひつじこから日々もらっている日記が1ヶ月ほど欠損して、 10月分を貼れないという事態になった。 gmailにはあるのでやれなくはないが、手間がかる。 根本的にフローを変えないとどうにもならない。 そもそも、この作業をしている家のFreeBSDマシンが 落ちることが頻繁にあり、このままではもうダメだ。 マシン自体はかなり前に新しいものを用意してFreeBSDも入れてあるのだが、 移行が全く済んでいない。これも早くどうにかせねばならない。

とはいえ、仕事がひどく忙しい上に、子供が3人もいると サーバいじりをしている時間など全くない。サーバの移行作業は 絶望的に無理だ。クリーンインストールして足りないものを少しづつ 復旧していくというのは毎日少しづつでもサーバに入って 何かしら作業をする生活習慣が必要になる。 かくなる上は、一旦新しいマシンのインストールを破棄して、 ddで丸コピーしてゴミごと移行するプランに変えた方がいいだろう。 それならハードウェア上の問題がなければ即日移行できる。

だがとりあえず可能な限り安くひつじこの日記更新フローを変えねばならん。 現状macあるいはwindowsからvncでFreeBSDに入り、 muttでsannetに送られてきた日記を保存し、 手動でviを開いて貼りつけ、誤字等の修正をして、 FreeBSD上にある日記処理スクリプトを介して更新している。 もはやブログにすれば良くね?感はあるのだが、 ひつじこ的には直接アップロードはしたくないわけで、 まずは地続きでの改良を試みるべきだ。

まずsannnetのメアドを破棄する。 muttってgmailから取れるかな。

ダメそうだな。SSH通さないと取れない。 たぶんいろいろ設定すればできるんだろうが、 経験上その手のことは時間がかかる。 サーバ屋になるならその手のことに慣れておくべきだろうが、 現状私はサーバ屋ではないし、 そういう勉強は正直会社でやらせてほしい。 家で勉強してるヒマはないのだ。

muttごと破棄だ。となるとFreeBSD上で更新する、 ということ自体を破棄した方が速い。 まずサイトを丸ごとgitにつっこむ。 mac上でclone。あとは更新用のperlスクリプトのsvn叩いてる所を git用に書き換えてmacで動くようにするが、 とりあえず手動更新で良ければそれも省略できる。 まずは日記の更新にFreeBSDを要しなくする状態にしよう。 若干効率が落ちてもかまわん。日記から2日分自動で抜き出す処理、 アンカーを勝手に埋め込む処理などは消えてもかまわん。 もはやそういう時代じゃない。その手のものはjs側につっこむ方がいい。 勝手に一月前のもフェッチして新しい順にソートして表示する jsくらいはすぐ書ける。だがそれも後だ。

おお、portsにgitがねえ。一体いつから更新してないんだ。portsの更新しよう。 どうやってやるんだっけくそう。

おお、いつも使ってるユーザがsuできない! しかもsshはrootのログインを塞いである! 何そんなところできちんとしてんだ過去の私! キーボードとモニタつないで本体にログインしないとダメじゃん! ダメだ、それは手間がかかりすぎる。

全データをzip、macからsmbでつないで持ってきてgithubに送る。 っていかん、githubって隠せないんだった。

金払えばいいだけか。今ケチってる場合じゃない。

zip開いた所でgit init、add --allして、remote add origin ほげほげ、 pushして送りつけ完了。

っていかん、今書いてるこれが反映されてない。一旦ここまでで上げる。 これをFreeBSDからの最後の更新としよう。


もどる