WG1200HS2を使ってnasneを無線ネットワーク上に置く

f:id:gensobunya:20200630144917j:plain

我が家にはTVがなく、TV番組を視聴したい時はnasneをヘビーユースしてPCとスマホDTCP-IPクライアントを使って視聴しています。

今までの1Kではこの構成でなんの問題もなかったのですが。広い部屋に引越したところ、アンテナ線の出口と光コンセントの位置が部屋の反対側になってしまいました。

f:id:gensobunya:20200630145522p:plain

nasneルーターに直接有線接続する必要があるので、大抵はルーターの隣に鎮座させるのですが、アンテナ線もないと当然nasneは機能しません。

無線LANコンバーター買えばいいよね

軽くググると同じ事例に当たっている人は何人かいまして、みなさんUSB接続の無線有線コンバーターこういうの)を購入して解決しているようでした。

確かにこれならば別の電源は不要でスマートに解決できます。無線LAN側通信速度も300Mbpsならなんとかなりそうな気がします。

ただ、有線LANの規格が100BASE-TX という仕様で、nasneと中継機の通信がボトルネックとなってしまい最大100Mbpsでの伝送しか出来ません。ローカルLANのくせにインターネットより遅いなんて!…ということで別の手段を考えました。

TP-Linkの製で1000BASE-TX対応のモデルも有りましたが、6000円~1万円もしてしまうので却下。

エントリーモデルのルーター活用

色々考えた末、中継機能のある無線ルーターコンバーターとして活用することにしました。

安心と信頼のNEC WG1200HS2をチョイス。メルカリで2000円台で調達しました。

この製品は、中継機能(コンバーターモード)を備えており親機のルーターから無線を拾って有線でつなぎ直すことが出来ます。本来は電波の届きづらい場所への中継する機能がメインですがそれは利用せず、LAN1ポートにnasneをつないで中継機としてセットアップします。

セットアップには有線LANで1200HS2にPCを繋ぐ必要があるのがやや面倒でしたが、設定そのものは物理スイッチを切り替えて親機のAPを指定するだけですので簡単です。

f:id:gensobunya:20200630151547p:plain

自動的に中継機に接続したnasneを認識してくれました。PC TV plusからも再生を確認。

自宅内NWの構成は下の図の通りです。

f:id:gensobunya:20200630151831p:plain
自宅NW

Google Play Music から Youtube Music へ移行できていない話

前置き

この記事は一切生産的なことが書いてありません。

Google Play Musicでは日本で正式に利用可能になる前から米国プロキシ経由で音楽アップロード機能をずっと使っていたいわゆる古参。 YoutubeGoogleアカウントと共通化される前からのユーザー←重要

Play musicのライブラリは「アップロード : 購入 = 99 : 1」程度の割合。必要ないのでPremium契約はしていない。

TL; DR

  • Youtube Musicはアップロードした音楽を扱うには全然機能足りない
  • このままGoogle Play musicが終了したらYoutube Music以外の選択肢を探すべき

移行ツール、ついに来たる

www.itmedia.co.jp

6月初旬についに移行ツールのURLを叩いたときの表示が「まもなく開始致します」から変更となり、Google Play musicにアップロードしていた大量の同人音楽ライブラリを移行できるようになりました。

死にゆくサービスにしがみついても仕方ないので、Youtube Musicのアプリに乗り換えるつもりでした。 この瞬間までは。

f:id:gensobunya:20200614181249p:plain

事態を飲み込むのに30秒ほどかかり、Youtubeの現ブランドアカウント(元々のYoutubeアカウント)はPlay Musicの転送先には使えないことを理解した。

まぁわからなくもない…元々Google Play MusicGoogleアカウントで使っていたものだし。アカウント内の移行じゃないと問題があることが色々あるんだろう…きっと。

落ち着いて本来のGoogleアカウントを選択しなおし(なぜかチャンネルを作成させられた)、転送をはじめて暇つぶしYoutubeにアクセスした。





…いつものプレイリストがない。登録チャンネルもない。





慌ててアカウントを見ると、"Googleアカウント"が表示されている。 Youtube Musicでアカウントを切り替えると、Youtubeの使用アカウントも連動して切り替わるようだ。

しかし、自分にはブランドアカウントでないGoogleアカウントでYoutube活動(動画公開やコメント)を行うのはまっぴらごめんだ。そもそもそのGoogleアカウント本垢だから本名出ちゃうんだが!!!!!

試しにAndroidスマートフォンでアカウントを切り替えてみたところ、こちらはYoutubeアプリとYoutube Musicアプリで別のアカウントをメインで利用することができた。同じブラウザ上使うPCならではの問題っぽい。

最悪、Chromeのユーザーを2つ並行して使うしかないかなどと考えていた。この時は。 メチャクチャ不便ではあるが、まぁワークアラウンドで対応できないことはない。

本題のデータ移行の方だが、幸い移行が有効化されて早々に対応したので、順番待ちなどはほぼなく10分ほどで全ライブラリが移行された。

OK, Google←OKじゃない

とりあえず動作確認。

OK, Google Youtube Musicで「偶像に世界を委ねて」を再生して

「Premium契約が必要です、今なら1ヶ月無料です。詳細を聴きますか?。。。。」

えぇ…それ自分でアップロードした曲なんだけど… (2回目移行はステーションが自動的に再生されるようになったが、もちろん同人音楽のステーションなどないので関係ない曲が流れ始める最悪の体験)

ダウンロード←できない

様々な記事で触れられていたが、Youtube Musicでは一度アップロードした曲のファイルをダウンロードできない。まぁこれはいい。

バックアップに使えないという意見もあるかもしれないが、Google Play musicにからダウンロードできるものは320kbps MP3に再エンコードされているので、手元にある可逆圧縮Flacのバックアップに比べれば価値は低い。

アップロードされた曲はオフラインでも使えるとドキュメントにあるし、さっそくいつものプレイリストをスマホに保存して…

f:id:gensobunya:20200614183216p:plain

そのプレイリスト、全部自分でアップロードした曲ーーーーーーーーーーーーーーーー!

※曲単位・アルバム単位でのオフライン再生のためのダウンロードはできますが、そんな面倒な使い方してる人いるんですかね

ドライブ中、無限にモバイルデータ食われるのは勘弁してほしい…(自分のアップロード曲は広告無しでAndroid Autoから再生できて唯一安心したポイントだった)

ドキドキタグ情報

YT musicは曲名とかアルバムとかの編集ができない。

タグ情報間違えてアップロードしたらあとから弄れないという緊張感が追加されている。なかなかスリリングなサービスだ。間違えたらアップロードしなおせばいいだけではあるが。

2020/6/15追記

Android Autoではアップロードした曲を広告無し、かつバックグラウンド再生に移行できることを確認しました。一応配慮されているようです。

※非プレミアムではAndroid Autoでの所持曲以外のストリーミングは不可です

f:id:gensobunya:20200615213707j:plain

多分バグですが、非プレミアムのせいなのか選曲のためのトップメニューが表示されません。

選曲するときいちいちモバイル端末を弄れと…?危険だが…

support.google.com

コミュニティにも同じ事象があったのですが、これ根本解決していないような

Fxxxまとめ

  • PCでPlay Musicから移行したYoutube Musicアカウントを利用するとYoutubeを昔からのアカウントで使えない
  • Google HomeからキャストするのにPremium契約が必要(明らかな劣化)
  • プレイリストのダウンロードができない(明らかな劣化、ワークアラウンドなし)
  • タグ情報の編集ができない(正気ではない)
  • Android AutoのYoutube Musicの対応が明らかに未完成 2020.06.15追記

Play Musicがなくなることは動かないと思うので、ライブラリをPlay MusicとYT music両方で更新しながら改善を祈るしかない。

その他にも英語メディアを漁るとYoutubeのLikeがYT Musicに影響を与えて云々とか色々出てくる。

Likeベースのストリーミングが全盛期なので、自前のライブラリを楽しむ人は少数派だとは自覚している。ただ、移行を促すなら基本的なことくらいは実装してほしい…

優秀な(この際優秀ということにしておく)ミュージックロッカーとしてPlay Musicを使っていた人間にはだいぶ厳しい仕様変更だ…当面はアップロード音楽をミラーリングしつつGPMを使います

Github ActionsでGatsbyサイトのプルリクを毎回Lighthouseで監査してみた

パフォーマンス変化がないか監視する

Github Actionsを使ってプルリクエストのたびにLighthouse CIを使ってスコアを算出し、低下している場合は警告を出します。

まずはGithub ActionsのYamlから。 Chromeは既にインストール済みなので、別途インストールする必要はありません。

name: lighthouse audit

on:
  pull_request:
    branches:
      - master

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          ref: ${{github.event.pull_request.head.sha}}
      - uses: actions/setup-node@v1

      - name: npm install
        run: npm install && npm install -g @lhci/cli

      - name: build
        run: npm run build

      - name: Lighthouse audit CI
        run: lhci autorun --config=./.lighthouseci/lighthouserc.json
        env:
          LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}

環境変数として設定しているLHCI_GITHUB_APP_TOKENは、Lighthouse CIのGithub Appを承認した際に発行されます。

これは、プルリクエストの画面でテストとしてLighthouse CIを表示させるために必要です。コマンドラインの結果だけでいい場合はこの設定は不要です。 公式のCheckoutスクリプトでよろしく処理するために必要な設定があるので追加しています。

github.com

設定ファイルは./.lighthouseci/lighthouserc.jsonにまとめて記載します。

{
  "ci": {
    "collect": {
      "numberOfRuns": 3,
      "staticDistDir": "./public",
      "isSinglePageApplication": true,
      "url": ["http://localhost/", "http://localhost/post/2019/08/edge530j/"]
    },
    "assert": {
      "assertions": {
        "categories:performance": [
          "warn",
          {
            "minScore": 0.6
          }
        ],
        "categories:accessibility": [
          "warn",
          {
            "minScore": 0.8
          }
        ]
      }
    },
    "upload": {
      "target": "temporary-public-storage"
    }
  }
}

Gatsby.jsのウェブサイトなのでisSinglePageApplicationフラグをtrueにしておきます。

プリセットを行わないことで、細かい実装ルールは検査せずにスコアのみの監査としています。 警告のしきい値は現在のスコアから適当に設定しておきました。

NetlifyからVercel(元ZEIT(元now))にホスティング先を変更してみた

NetlifyのCDNに不具合があり、TTBFが遅延する自体が長いこと続いているので別のJAMStackホスティングサービスを探しており、now.shとして知られていたサービスが今ではVercelとなりJAMStackとの親和性が上がっているようでしたので、テスト的にサークルサイトを移行してみることにしました。

TTBFが1秒近くかかる不具合を半年対応できないとかヤバすぎる

移行にかかった時間はドメインTTL待ちを除けば30分ほどです。リダイレクトやルーティングが不要であればポチポチして5分で終わります。

セッティング

概ねNetlifyと同じく、WebコンソールからポチポチしてGithubリポジトリとリンクすると、ビルドコマンドとdevコマンドを入力する画面が現れるので、これを指定して始めます。

自動的にフレームワークを認識する機能がついているので、ビルドコマンドもサジェストされるのは好印象。

f:id:gensobunya:20200523100324p:plain
デプロイはじまりました

Netlifyでは、インクリメンタルビルドを利用して3分は最低でもビルドにかかるリポジトリなのですが、なんと全ページをビルドしてたったの2分しかかかっていません!

f:id:gensobunya:20200523100550p:plain

サイトはインターネット経由で確認できるので、Pagespeed Insightsで確認してみます。 正規ドメインでないと実行されないスクリプトがあるので単純比較はできませんが、TTFBは明らかにVercelが勝っています。

f:id:gensobunya:20200523100829p:plain
Vercel

f:id:gensobunya:20200523100903p:plain
Netlify

CDNのエッジサーバーが東京にあるので、かなり期待できそうです。

設定の移行

ビルド設定以外に、Netlifyでリダイレクト設定やヘッダー設定をしている箇所があるので、これらをVercel用に移行します。

Netlifyでは_redirect, _headerのようなファイルをStaticディレクトリに入れてルートに配置することでこれらを設定していましたが、Vercelではvercel.jsonという設定ファイルをプロジェクトルートに配置して設定します。

vercel.com

JSONなのでコメント書けないのはちょっと…ですが新しく候補にしていたAzure Static AppsもJSONなのでここは文句を言わないことにします。正規表現がリダイレクトで使えるのは非常にGood!

ビルド時間短縮用のオプションと、移行した記事のリダイレクトを書いていきます。

{
  "build": {
    "env": {
      "GATSBY_TELEMETRY_DISABLED": "1"
    }
  },
  "redirects": [
    {
      "source": "/portfolio/md2doujin/",
      "destination": "https://gensobunya-tech.hatenablog.com/entry/2018/12/20/000000"
    },
     {
      "source": "/category/(.*)",
      "destination": "/tags/$1"
    },
...

Netlify用のtomlで記載されていたリダイレクトのリストはスプレッドシートという有能なソフトでJSONに変換しました。

リダイレクトは、ローカルでも確認できるのでvercel devコマンドを実行することでVercelでのホスティング状態をエミュレートできます。便利。

デプロイはvercelコマンドだけでいいのですが、Githubインテグレーションを設定しているので、Pushするごとにプルリクやブランチに応じたプレビューURLを作ってくれます。ステージング確認はそれらで実施するのが良いでしょう。

移行

ローカルで稼働確認をしたら、プロダクションブランチをスムーズに移行させるためにNetlifyのサイトは活かしつつ、Vercel側で新バージョンのデプロイをしてDNSを切り替えます。

  1. Netlifyの自動ビルドを止める
  2. Vercel移行のプルリクを作成、ビルド結果を確認
  3. DNSを切り替え

これで、DNSの切り替えが反映されていない人はNetlifyのホスティングを参照してくれます。TTLの倍の時間が過ぎたらNetlifyのサイトは削除してもよいでしょう。

VercelでもIncremental Buildが使えるようになってほしいですね~。ビルドキャッシュをどこに保持するのかが問題になりそう

Docker for WSL2においてユーザー権限でコンテナを動かす

なんで

Gatsby.jsのプロジェクトをDockerで動かす際に、.cache, public/* がroot権限で作成されてしまい、コンテナの再起動や、コンテナ外からの操作が権限エラーでコケてしまう

対処法

Dockerfile でローカルユーザーを作っておく。 この方法は、UIDとGIDをハードコーディングしているため、環境によってこれらを書き変える必要がある。 他にもEntrypointのスクリプトを使ったり、/etc/passwd などをマウントする方法もあるが、docker-composeコマンドにオプションを追加せず使いたかった

# useraddがAlpine Linuxイメージにないので
RUN apk add shadow

ARG UID=1000
ARG GID=1000

# 中略

RUN useradd -m -u ${UID} -g ${GID} gensobunya
USER gensobunya

UID1000は既に存在するぞと怒られた。とりあえずUID指定せずに作ったところ、想定通りの動作はしてくれが、UIDが違うのTypesにアクセスできなかった。使っているイメージのユーザー状態を確認してみる。

~ $ cat /etc/passwd
root:x:0:0:root:/root:/bin/ash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/mail:/sbin/nologin
news:x:9:13:news:/usr/lib/news:/sbin/nologin
uucp:x:10:14:uucp:/var/spool/uucppublic:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
man:x:13:15:man:/usr/man:/sbin/nologin
postmaster:x:14:12:postmaster:/var/mail:/sbin/nologin
cron:x:16:16:cron:/var/spool/cron:/sbin/nologin
ftp:x:21:21::/var/lib/ftp:/sbin/nologin
sshd:x:22:22:sshd:/dev/null:/sbin/nologin
at:x:25:25:at:/var/spool/cron/atjobs:/sbin/nologin
squid:x:31:31:Squid:/var/cache/squid:/sbin/nologin
xfs:x:33:33:X Font Server:/etc/X11/fs:/sbin/nologin
games:x:35:35:games:/usr/games:/sbin/nologin
cyrus:x:85:12::/usr/cyrus:/sbin/nologin
vpopmail:x:89:89::/var/vpopmail:/sbin/nologin
ntp:x:123:123:NTP:/var/empty:/sbin/nologin
smmsp:x:209:209:smmsp:/var/spool/mqueue:/sbin/nologin
guest:x:405:100:guest:/dev/null:/sbin/nologin
nobody:x:65534:65534:nobody:/:/sbin/nologin
node:x:1000:1000:Linux User,,,:/home/node:/bin/sh
gen:x:1001:1000::/home/gen:/bin/ash

nodeユーザーが作成されてますね… 使っているnode:version-alpineイメージで作成されているようなので、このユーザーを使ってしまおう。

マウント先が変わるので、docker-compose.yml も変更

FROM node:12.14.1-alpine

~中略~

# ユーザー権限に切り替える
USER node
WORKDIR /home/node

~~~
version: "3"
services:
  web:
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - "8000:8000"
    volumes:
      # コンテナ内にボリュームを作成する
      - /home/node/node_modules
      # プロジェクトをホームディレクトリにマウントする
      - .:/home/node
    environment:
      - NODE_ENV=development

参考

qiita.com

zukucode.com

amaya382.hatenablog.jp

NetlifyでGatsby.jsのIncremental Buildが使えるようになったのでビルド時間短縮を検証してみた

Gatsby.jsのIncremental BuildがNetlify上でBeta版として利用できるようになりました

www.netlify.com

これは、本来は毎回リポジトリ全ページをビルドするGatsbyのビルドを、前回ビルド時のキャッシュを利用して更新が入ったページのみ追加でビルドして更新のないページはそのままにするというもので、大きなWEBサイトで毎回長いビルド時間をデプロイのために費やす必要をなくすためのものです。

ローカルサーバー作成時には使えないので、開発時は今のままです。

まずは、本当に短縮されるのか比較的サイズの小さいリポジトリで検証してみます。

※Netlifyはフリープランです

リポジトリ

利用のためのコード修正と、Netlifyの設定変更を行います。

1. Netlifyセッティング

Netlifyのビルドプラグインを有効にします。これだけはWEBコンソールからの設定が必要です。

次にnelify.toml末尾に設定を追加します。

[[plugins]]
  package = "netlify-plugin-gatsby-cache"

ProductionのContextだけに含めるなどの設定ができると面白いのですが、今回は未検証です。

2. npm scriptの更新

ビルド用のnpm scriptにIncremental Build用の環境変数を追加します。

  "scripts": {
    "build": "GATSBY_EXPERIMENTAL_PAGE_BUILD_ON_DATA_CHANGES=true gatsby build",
    ...

buildコマンドに gatsby clean を入れているとキャッシュを消去してしまうので、利用している場合は使わないようにします。

ページごとにどのページが新しくビルドされたのか知りたい場合は、 --log-pages オプションを末尾に追加します。

あとはGatsby.jsを最新版に更新すれば準備はOKです。

ログから結果確認

pluginを追加したことで、見慣れない出力が出てきます。

8:42:23 PM: ┌─────────────────────────────┐
8:42:23 PM: │        Netlify Build        │
8:42:23 PM: └─────────────────────────────┘
8:42:23 PM: ​
8:42:23 PM: ❯ Version
8:42:23 PM:   @netlify/build 0.4.26
8:42:23 PM: ​
8:42:23 PM: ❯ Flags
8:42:23 PM:   mode: buildbot
8:42:23 PM: ​
8:42:23 PM: ❯ Current directory
8:42:23 PM:   /opt/build/repo
8:42:23 PM: ​
8:42:23 PM: ❯ Config file
8:42:23 PM:   /opt/build/repo/netlify.toml
8:42:23 PM: ​
8:42:23 PM: ❯ Context
8:42:23 PM:   production
8:42:23 PM: ​
8:42:23 PM: ❯ Installing plugins
8:42:23 PM:    - netlify-plugin-gatsby-cache
8:42:42 PM: ​
8:42:42 PM: ❯ Loading plugins
8:42:42 PM:    - netlify-plugin-gatsby-cache@0.2.1
8:42:42 PM: ​
8:42:42 PM: ┌────────────────────────────────────────────────────────┐
8:42:42 PM: │ 1. onPreBuild command from netlify-plugin-gatsby-cache │
8:42:42 PM: └────────────────────────────────────────────────────────┘
8:42:42 PM: ​
8:42:42 PM: No Gatsby cache found. Building fresh.
8:42:42 PM: ​

プラグインの利用と、Incremental build用のキャッシュが存在しないことを出力しています。

次に、Markdownファイルを1つ修正したコミットのデプロイ結果を見ます。

8:51:30 PM: ┌────────────────────────────────────────────────────────┐
8:51:30 PM: │ 1. onPreBuild command from netlify-plugin-gatsby-cache │
8:51:30 PM: └────────────────────────────────────────────────────────┘
8:51:30 PM: ​
8:51:30 PM: Found a Gatsby cache. We’re about to go FAST. ⚡️
8:51:30 PM: ​
8:51:30 PM: (netlify-plugin-gatsby-cache onPreBuild completed in 255ms)

前回のビルド結果がキャッシュとして使われていることが通知されました!

肝心のビルド時間を確認してみます。

f:id:gensobunya:20200516120617p:plain

201秒→164秒へ約20%の削減達成!このサイトはHTML15枚、サムネイルが99枚ビルドされた結果です。

サイズの大きいサイトで試す

より効果を実感するための、数年間運用しているブログをビルドしてみます。

HTMLページは222ページ、サムネイルは2500枚程度なのでおおよそ15倍の規模です。

f:id:gensobunya:20200516122120p:plain

全体で652秒から、1ページのみの更新だけのビルドでは274秒まで短縮されました!すごい!

ただ、その後の netlofy.toml をビルドした結果で377秒かかっているのが気になります。理論上は1ページも更新されていないのだから、もっと速いはず…

ビルド時間内訳の確認

3回のビルド時間の内訳を確認してみます。

  • Build ready to start ~ Netlify Build
  • Netlify Build ~ onPostBuild command from netlify-plugin-gatsby-cache
  • onPostBuild command from netlify-plugin-gatsby-cache ~ Site is Live

これらの3つに分類して時間を比較します。

イメージ起動~npm install Gatsby build Post processing
初回ビルド 9:09:28~9:12:16 9:12:16~9:17:37 9:17:37~9:20:31
1ページ更新 9:20:54~9:21:51 9:21:51~9:23:34 9:23:34~9:25:31
設定ファイル更新 9:27:52~9:29:10 9:29:10~9:31:23 9:31:23~9:34:13

秒数に直します

(sec) イメージ起動~npm install Gatsby build Post processing
初回ビルド 168 321 174
1ページ更新 57 103 97
設定ファイル更新 78 133 170

考察

Dockerイメージ起動とnpm installの時間が大幅に短縮されているのは、Netlifyの内部処理によるものと推測できます。これだけで2分ほど短縮されているのですが、実際の更新がこれほど頻繁に走ることはないので実際はこの120秒前後はIncremental Buildによって、日々のデプロイで短縮される時間ではないと推測できます。

Gatsbyのビルド時間は1/3ほどに短縮されています。これは素晴らしい効果。一方で1ページも更新していない際に30%ほど長時間化している点はNetlifyのコンテナ環境によるものなのか、Incremental Buildの要改善点なのかはこれからの更新やコミュニティをウォッチする必要がありそうです。

Post processingの時間差は…謎です。Incremental Buildの影響でMinifyingする必要があるJS,CSSがなくなっているので1ページだけ更新しているビルドはこれらのプロセスがスキップされており、その分2~3分の短縮がされています。

9:18:30 PM: Starting post processing
9:18:31 PM: Minifying js bundle
9:18:34 PM: Minifying js bundle
9:19:15 PM: Minifying js bundle
9:20:04 PM: Finished processing build request in 10m26.801042671s
9:20:20 PM: Minifying js bundle
9:20:31 PM: Post processing done
9:20:31 PM: Site is live

↓

9:24:20 PM: Starting post processing
9:25:30 PM: Post processing done
9:25:31 PM: Site is live
9:25:50 PM: Finished processing build request in 4m54.572851706s

一方で、設定ファイル更新したビルドは謎の2分間がPost Processingに費やされています。

9:32:21 PM: Starting post processing
9:33:37 PM: Finished processing build request in 5m42.65207949s
9:34:12 PM: Post processing done
9:34:13 PM: Site is live

これ以上このログから何が起きたのか追うことは出来ませんが、まだβ版機能ですので不具合が残っているのでしょう。

コミュニティでも不可解なビルド時間に対する議論が起きているので、GAまでの改善を期待します。

community.netlify.com

これは良いんだけどCDNのレスポンスがポンコツ化したのなんとかしてくれないかな…

いよいよGoogle Play Musicがサービス終了するのでYoutube Musicに移行する準備を始めた

アナウンスされていたGoogle Play Musicのサービス終了がついに具体的に動いてきました

www.itmedia.co.jp

個人的には、膨大な同人音楽ライブラリの転送さえできれば以降に対して特に思うところはないのですが(AndroidAutoでも使えるし)、音質がSpotifyなどにくらべて良くないらしいのでGoogleには頑張ってもらいたいところです…

非プレミアムでのバックグラウンド再生や広告無しはやってもらわないと困りますが…というか自分のライブラリ再生するのにそんな制限されるのはちょっと意味不明なのでやめてねというところ。

GPMのアップロード・ダウンロード仕様

  • アップロードは一般的なコーデックなら大体OK(今は可逆圧縮Flacでアップロードしている)
  • 再生用音源は320kbps MP3
  • ダウンロードで落ちてくる音源も320kbps MP3、アップロード時の形式は無関係

つまり、オリジナル音源は自分で持っておかないと消えます。別途アーカイブとして保管が必要。

Youtube Musicではできないこと

ところで、過去のITMediaの記事を参考にすると、Youtube Musicではライブラリのダウンロードができないようです。

www.itmedia.co.jp

普段聞くだけならば、クラウド上にファイルが有れば十分なのです。が、当然購入した資産はバックアップして他のサービスでも使えるようにしておくのが危機管理というものですので、手持ちのライブラリのアップロードではなくGPMで購入した楽曲についてはダウンロードしておきます。

f:id:gensobunya:20200513173725p:plain
Music Managerでダウンロードしておく

普段は絶対使わなかったミュージックマネージャの「ダウンロード」タブを開くと購入済みの曲のみをダウンロードできる機能があるのでこちらを利用しました。

ファイルそのものはGoogle Cloud StorageのCold Lineにアーカイブして保管しています。

ダウンロード料金や、最低保管期間がありますが0.006USD/GB/Monthと圧倒的安さなのでおすすめです。今はさらに安いArchive Lineというのも出ていますね。