PSVitaのバックアップ環境をNASに作る

まず、Windows10とかだとコンテンツ管理マネージャーがインストールできないので、下記を参考にインストールする

livesketch.net

次に、こちらを参考にNASに向けてバックアップ先フォルダを設定する。

bwt.blog.ss-blog.jp

参考までに、音楽は設定したフォルダの下に PSVita というフォルダが作成されるため、PSVita というフォルダをパスに含めなくて良い。

Container Managerでプライベートリポジトリを構築する

Synology NASでプライベートクラウドを構築する話。NASでDockerが動くらしいので、とりあえず環境構築しておけばいい感じのクラウド環境になりそう。買ったやつはまだメモリにも余裕があるし、足りなくなったら増設すれば良い。

環境構築は下記のサイトを参考にした。一部分設定が異なるので、差分だけメモっておく。気が向いたらそのうちQiitaに書く。NASあまりにも便利すぎてみんな使いだして品薄になっても困るけど。

taktak.jp

bitkatasumi.com

まずはパッケージマネージャーからContainer Managerをインストールする。

次に自己証明書ではなくLet'sEncriptから証明書をダウンロードする。プライベートリポジトリといえど、https通信が必須らしく、そのためには正規の証明書が必要らしい。この証明書を得るためにDDSNの設定が必要になるので、DDSNの設定がまだの場合は、それからしておく。

次にリポジトリ用のdockerコンテナを立てる。Container Managerを作ると、永続用に"docker"という共有フォルダが作られる。ここに下記のようなファイルとフォルダを作成する。

ファイル：/docker/registry/config/config.yml

```dockerfile

version: 0.1
log:
  fields:
    service: registry
storage:
  delete:
    enabled: true     # open delete api
  cache:
    blobdescriptor: inmemory
  filesystem:
    rootdirectory: /var/lib/registry
http:
  addr: :5000
  headers:
    X-Content-Type-Options: [nosniff]
health:
  storagedriver:
    enabled: true
    interval: 10s
    threshold: 3
auth:
  htpasswd:
    realm: basic-realm
    path: /auth/htpasswd    # use apache basic-auth

```

ファイルの書式の詳細はこちら

docs.docker.jp

ファイル：/docker/registry/config/htpasswd

レジストリにログインするユーザーとそのパスワードを保管するためのファイル。このファイルを作るための専用のdockerイメージがあるので、サクッとdocker runして作ることができる。

```shell

docker run --rm -ti xmartlabs/htpasswd ユーザー名 パスワード > htpasswd

```

イメージの詳細はこちら

github.com

フォルダ：/docker/registry/certs

ここに証明書のファイル(.crt, .key)をいれる。Synologyのコントロールパネル > セキュリティ > 証明書から、証明書のエクスポートで各種 pem ファイルが圧縮されたzipファイルが降ってくるので、それを解凍して、次のコマンドで .crt と .key ファイルを作成する。

```shell

cp privkey.pem domain.key
awk '{print $0}' cert.pem chain.pem > domain.crt

```

なお、証明書が更新されたタイミングでこれを行う必要がある。Let'sEncryptは3ヶ月しかもたないので、そのたびにやる必要がある。ダルい。なんとかして自動化しなければ...(Synology NASはWebAPIがあるらしいので、自動化も頑張ればできるかも？）

kb.synology.com

フォルダ：/docker/registry/images

ここにプッシュしたイメージが登録される。

ここまでできたらContainre Managerからコンテナを作成する。各種設定について

  • 自動再起動はONにしておく
  • デフォルトポートはSynology NASコンソールが使っているので5000, 5001を避けて設定する（例：5002）
  • 下記ボリュームの設定をする
  • /docker/registry/certs:/certs
  • /docker/registry/images:/var/lib/registry
  • /docker/registry/config/htpasswd:/auth/htpasswd
  • /docker/registry/config/config.yml:/etc/docker/registry/config.yml
  • 下記環境変数を追加する
  • REGISTRY_HTTP_TLS_KEY
    • /certs/domain.key
  • REGISTRY_HTTP_TLS_CERTIFICATE
    • /certs/domain.crt

ここまでできたらコンテナを起動し、下記で動作確認する

```shell

# Macのコンソールで実行
curl https://testuser:testpass@example.synology.me:5002/v2/_catalog

# 下記のようなレスポンスが返る
{"repositories":[]}

```

次に、このレポジトリをNASに登録してプライベートリポジトリに上げたイメージからコンテナを作れるようにする。

レジストリのURLは https://IPアドレス:さっき開けたポート(例:5002) になる。

プライベートクラウドとしてのNAS

弊社のテックトーク過去回を見ていたら、これを見かけました。

youtu.be

kakaku.com

見終わったら、もう紹介されていたNASをポチっていました。最近のNASはLANに繋がった外付けHDDってだけではなく、ちょっとしたプライベートクラウドとして使えるのですね。便利な世の中です。

Synology Photos

このNASを買う前から、自宅でNASを運用していました。NASの用途は主に写真・動画のバックアップで、nasne ACCESSを使ったり、RAVPower FileHubに外付けHDDを繋げて、そこにPhotoSyncのNASアドオンを使って写真・動画をバックアップしていました。しかし、nasneは本体HDDがぶっ壊れたし、FileHubは稀に接続が途切れてバックアップできなかったりしていて、ちょっと不満がありました。

SynologyのNASは常時起動を前提としているため、安定感抜群です。そしてSynology Photosというソフトウェアを使うことで写真を自動バックアップできるようになりました。ただバックアップするだけではなく、GoogleフォトのようなUIが提供されているので、もうバックアップはこれメインでいいような気がしています。

Googleフォトは共有機能が強いですが、保存容量が高く(100GB 2,500円/年)、動画の容量制限がある(10GB未満)、容量無制限の場合はPixel 5以下で画質を落とす必要ありなど、いろいろ制約があります。Synology Photosを使うと、保存容量はHDDを買えば好きなだけ増やせますし、スマホもPixel 5以外の選択が増えます。後述するVPNを構築すれば、外出先からも写真のバックアップや共有ができます。

VPN Server

Synology NASには無料でDDNS機能とVPN機能を追加できます。そのため、外部のネットワークからNASに安全にアクセスできます。VPNの方式は現状OpenVPN一択です。ただ、NASの構築にあわせてルーターも新調し、VPNはルーター側の機能を使っています。

外付けHDDの追加

Synology NASはUSBポートがあり、そこに外付けHDDを繋げればそれも共有対象にできます。外付けHDDの方はファイルシステムとしてNTFSも使えるので、既存のHDDをさして気軽に共有できます。

Audio Station

音楽共有機能を使うことで家庭内で音楽を共有できます。自分専用のフォルダも用意できるので、共有側にはJ-POPを、自分専用側にはアニソンを入れておくことができます。なお、wmaには対応していないので、wmaファイルはmp3に変換する必要があります。

Container Manager

NAS上でdockerコンテナを起動させることができます。パブリッククラウドに上げる前の動作確認に使えそうです。また、container registryを立ち上げることで、プライベートコンテナリポジトリを構築できます。

ひろがるスカイ!プリキュア

ひろがるスカイ!プリキュアを見ました。

https://www.amazon.co.jp/gp/video/detail/B0B8N564YV

元々は娘がプリキュアの存在を知って、最新のプリキュアだとまだ1話しか出ていなかったので、1つ前が上のPrime Videoで全部見れると知ったので、「プリキュア！」と言われたらこれを流していた。

ら、私もガッツリハマってしまった。なお、途中から妻もちゃんとハマってしまった。ここではひろがるスカイ!プリキュアの魅力を紹介したいと思う。

過去作品を知らなくても楽しめる

プリキュアはひろがるスカイ!プリキュアで20周年という節目らしい。こんな節目なら、レジェンドキャラとかが出てきたりとかするかと思ったら、そういうものはない。純粋にひろがるスカイ!プリキュアだけでキャラもストーリーも完結しているので、事前知識要らずに楽しめる。

30分でまとまってる

いわゆる深夜帯のストーリー性のあるアニメは、次の話を見てもらうために話の最後に次回話のつなぎのストーリーを入れてどんどん次の話を見てしまい、なかなか区切りがつかない。一方でひろがるスカイ!プリキュアは1話30分で悪役が活躍しヒーローが倒す勧善懲悪が守られている。ちょっと時間が余ったから30分だけ見よ～みたいなことができる。娘としても、プリキュアがちゃんと悪役をやっつけて話が終わるので「よし、次はご飯食べようね」だったり「お風呂入ろうね」だったりと気持ちの切り替えがしやすい。

「ひろがる」テーマが素敵

ひろがるは「Hero Girl」と「広がる」をもじっている。主人公であるソラは昔ヒーローに助けてもらって以来、困っている人を助けるヒーローを目指している女の子である。ヒーロー修行をしていたせいか、生身の身体能力もずば抜けていたりする。しかしソラの良いところは、ヒーローの心得という芯を持っているところだ。その揺るぎない芯を信じる心が周りの人を巻き込んでいき、プリキュアのメンバーも「広がって」増えていくことになる。たまに弱い心も見せたりしてそのソラの葛藤がとても揺さぶられる。そして仲間を信じて仲間と一緒に問題を解決していくのだ。これが素敵すぎる。

この「広がる」テーマ、最初は一人でヒーローをやっていたソラが最後には沢山の仲間と悪役をやっつけるのだが、「カイゼン・ジャーニーじゃん」って思った。

https://www.amazon.co.jp/dp/4798153346

つまりプリキュアは、抽象度を高くしたらビジネス書籍と同じカテゴリなんだ！（ゴリ押し

ソラがかっこいい

ヒーローを志すソラがかっこいいんだが、まぁプリキュアなんでソラはプリキュアに変身するわけで。変身シーンがカッコ良すぎるのでまだ見てない人はとりあえず無心で見ると良いと思う。

youtu.be

あーかっこいいわ...

その他

途中でソラが闇落ちするんだけど速攻で浄化されてしまった。もし30分という枠がなかったら、もう少しダークキュアスカイの出番が出て面白そうに思ったけど... 

ディズニー

今年はディズニーランドが40周年の節目だとか。5年おきに周年記念しているので、個人的にはまたやってるなーという気分になる。しかし、関東にいる人にとっては身近な巨大遊園地なので、餌の時間になったペットのようにやってきてしまうらしい。

子供がいると、特に抱っこをねだるくらいの小さい子供がいると、いろんなことに駄々をこねたりすることを覚悟していたが、せいぜい抱っこの時間が長いくらいだった。まあ、子供にとって遊び以外の立ち待ちや移動はつまらない以外の何ものでもない。それを発生させてしまったのであれば抱っこするのは仕方ないね。

あと子供は悪者が本当に怖いらしい。パウ・パトロールの映画の悪役だったり、プリキュアの悪者だったり、美女と野獣の野獣だったりにガチで拒否反応を示して号泣してしまう。今度はちゃんと野獣見に行こうな。

家に帰ってからは1500円で買ったバルーンを使い倒してやろうと思って外出時に持っていっていたら、2日も経たずにしぼんでしまってテンションが下がったミッキーになってしまった…夢が解けてしまったようだ。

社内ツール改善

JIRAやGitLab, Slackなど、業務でツールを使っているとどうしても定型作業が出てくる。そういう作業は徹底的に自動化すると、ツール間のスイッチングコストが減って、本質的な作業に集中できる。

そのようなツールをsbtタスクで書いていた。sbtタスクを使うと、タスクを静的型付けで書けて、mavenライブラリをシームレスに使える利点がある。通常、これらのツールはrest apiを用意しているので大体curlとjqを駆使することになるが、使い慣れたScala言語で統一できること、Scalaの表現力が高いことで、ロジックが保守しやすい。書捨てられるもよくあるこれらの処理を第一級の言語で書けるのは良いカルチャーショックだと思う。

ただ、これにはちょっと欠点があって、テストが書きづらい。頑張れば書けなくもないけどscriptのテストってあんまり馴染みが無いと思う。それよりかは普通にscalatestのほうが後々を考えると良いだろう。

というわけでタスクを1つのプロジェクトとし、ロジックをmainメソッドに書き殴るようしてみた。sbtは気軽にマルチプロジェクトを構築できるので、そういうフッ軽な所も好きだ。

書いていると1つ問題が発生してしまった。各SaaSのjavaライブラリのラッパーを社内ライブラリとしてパブリッシュしようとおもったが、引き続きsbtタスクをとしても使いたい場面もあったため、scala2.12で書く必要があった。sbtの支援もないのでusingとかもなくてなかなか体験が悪い。複数バージョンでビルドできるが、2.12と3.3だとソースを共有できない場面が多い。辛い。

今の所は2.12ベースで書き直して、sbt2がでたら移行するのが良いかならと思っている。…sbt2いつでるかな？

単体テストは難しい

プログラミングを仕事とする場合、避けては通れない単体テスト。それは自分の実装に対して自動で動作確認を行う仕組みな訳だが、これが結構難しいのかな、という印象を持った。

仕事では、全てが自分のコードではない。既存の複雑に絡み合った実装の中に針を通すような改修を行うこともある。さて、その改修が正しいことを示すために単体テストを書こうとした時、まずはその単体テストできるための環境を作るのが大変だったりする。前提となるインスタンスを作成するために様々な依存関係を解決しなくてはいけなかったりする。まぁ最近はモックライブラリがかなり優秀なので mock[TargetClass] みたいにすればだいたいうまいこといくことが多い（いかないこともあるが...）。さて、問題はここからだ。単体テストの本質というか、ここからが書き手のセンスが問われる。つまり、自分は何を動作確認したいか、だ。

まず、これをするためには自分が何を動作確認したいかを適切に捉える必要がある。仕様をきちんと理解して、それを言語化する必要がある。加えて、言語化した情報をプログラミング言語に翻訳する必要がある。この部分は実装を書くよりもクリエイティブな作業になることが多い。改修作業は、求められる機能が決まっているのでブレることが少ないが、単体テストを書く時は自分が確認したい動作をきちんと捉えられているかどうか、もしくは自分がその問題をどのように捉えているのか、が如実に実装に反映される。改修時よりも余白があって、１つの正解、というものがない。

私は以前、単体テストといえばラインカバレッジを満たすためのものという感覚があったが、そういうホワイトボックステストは脆弱なテストと言われる。それは改修の余白を生まなくなり、改修時に単体テストも一緒に修正することになるので、デグレ確認としての単体テストが機能しづらい。そこから実装の余白を生むためにBDDのようなテスト技法が生まれたと思う。ラインカバレッジを重視するのではなく、仕様（機能の振る舞い：Behaviour）を重視する姿勢だ。ただ、これが既存実装に対して適用するのはホワイトボックステストよりも骨が折れる。なぜなら、仕様はコードに現れないことがあるからだ。もしくは改修に改修を重ねたコードが表現する仕様は、1つの仕様書としてまとまっておらず、複数の仕様書をパッチワークのように適用した結果できることがある。それを読み解いて、言語化し、プログラミング言語として実装する必要があるからだ。そんなのができるのはそのサービスにとても精通しているベテランしかできない。少なくとも２〜３日でできる技じゃない。

だから単体テストは難しい。単体テストを書くとはもはや実装を見ることではなく、仕様を掘り起こす作業になるからだ。仕様を把握して動作確認すべき箇所をピンポイントに言語化して実装する、これはプログラミング言語だけを勉強してても身につかない。そのサービスをちゃんと理解していないと書けない。難しい。

そういったものをチームで解決するためにコードレビューを通してベテランの知識を提供することは良いかもしれない。ただ、レビュワーに対しても同じだけの負荷、つまり仕様に対する背景等を持った上で、目の前のプログラミング言語で書かれた動作確認書を読む必要があって、なかなかしんどい。難しい。上手い解決方法はないものか...

最近は単体テストを書いていると、Copilotがかなり適切にサジェストしてくれるようになって、単体テストの実装を書く上ではかなり省力化された感じがする。Copilotがそのプロジェクトのコードを全て理解するようになれば、より適切な単体テストもサジェストしてくれそうだなという感覚もある。実装者は動作確認の言語化を適切にできる能力を磨けば良い未来が来るかもしれない。もしくはExcelやConfluenceとかで書かれた日本語での仕様書も全部読み取って、Copilotがその動作確認の言語化もサポートできるようになると、単体テストを実装する転換点になると思った。