個人用 Clipchamp から組織ユーザーへプロジェクトを無理やり移行する

この記事では、 個人アカウント用 Clipchamp から組織(法人)ユーザーの Clipchamp へプロジェクトを移行する方法、およびその応用で、個人用から別の個人用ユーザーに Clipchamp プロジェクトを移行(コピー)する方法を説明する。


去る7月31日に、 動画編集アプリ Clipchamp が組織アカウントに対応し、ビジネス向け Microsoft 365 に加わることが発表された。

これにより、 Microsoft での買収以降どのプランが商用利用可能なのか曖昧だった Clipchamp が、組織アカウント上で安心して商用利用できる事になる。
北米時間の 2023年10月15日 に Clipchamp が商用ユーザーで利用可能になったことが発表 され、 Microsoft 365 の対象プランのライセンスを持つ全てのユーザーに対し Clipchamp が一般公開された。

さて、 Clipchamp が組織アカウントに対応したことで、旧来の個人アカウント用 Clipchamp アカウントで作成していたプロジェクトを、組織アカウントに移行したくなる場合もあるだろう。

しかし FAQ などをみると、

職場アカウントで Microsoft Clipchamp にアクセスする方法 - Microsoft サポート

個人アカウント用に Clipchamp で作成されたプロジェクトを作業バージョンに移動できますか?

いいえ。

無慈悲。

仕事向けの Clipchamp - clipchamp.com

個人用アカウントの Clipchamp で作成したプロジェクトを職場アカウントに移行できますか?

現時点では、個人用アカウントで作成したプロジェクトを職場アカウントに移行することはできません。

こちらは、もうちょいマイルドだ。

将来的にやる気があるのかはわからんが、少なくとも現時点では、個人アカウントのデータの組織アカウントへの移行は、公式的にはできないらしい。

ところで、実際に組織アカウントで Clipchamp を使ってみると、プロジェクトファイルが OneDrive for Bussiness の <ルート>\動画\Clipchamp\<プロジェクト名>\ あたりの、 *.clipchamp という、 JSON が実体のファイルとして保存されていることに気づく。

個人用 Clipchamp の動作を思い出してみると、画像や音声などのアセットはローカルにキャッシュや保存されているものが参照されているだけで、別 PC でプロジェクトを開こうとすると、改めてアセットファイルを紐づける必要があった。

このため、 個人用 Clipchamp のプロジェクトも、この JSON ファイル程度の情報しかサーバーで管理されていないのではと推測できる。

つまり、何らかの方法でこの JSON ファイル相当の情報を個人用 Clipchamp から抜き出せれば、組織アカウントに移行できるかもしれない。

試行錯誤してみたところ、どうやら上手くいったようなので、その方法を紹介しよう。

続きを読む

Pester v3 & v5 互換のテストコードを書く (PowerShell)

PowerShell のテストフレームワークである Pester は、単体テストや自動テストなどを手軽に書けるので、スクリプトやコードの品質を保つのに役立つ。

しかし、 Pester は v3 から v5 にかけてかなり大きな破壊的変更がある。

この記事では、 Pester v3 と v5 の両方に互換があるテストコードの書き方について紹介したい。

何故 v3 と v5 で互換を取りたいか

Windows 10 や 11 では、デフォルトで Windows PowerShell 5.1 がインストールされており、更にそこには Pester モジュールの v3.4.0 もインストールされている。
Windows 上の PowerShell モジュールディレクトリはシステム全体で共通のため、たとえ別途 PowerShell 7.3 LTS などをインストールしていたとしても、既定では Pester v3.4.0 が読み込まれるわけだ。

一方、 Linux 等のそれ以外のシステムで PowerShell をインストールした場合は、 Pester が自動的にインストールされることはないため、 Pester モジュールを追加でインストールすることになる。
このとき、普通は最新版の v5 が入るだろう。

Windows PowerShell の Pester を v5 に更新させたり、 Linux 等のシステムでインストールする Pester モジュールを v3.4 に抑えさせたりできればよいが、まぁなかなかそうも行かない時がある。

そんなのっぴきならん状況だと、多少苦労してでもテストコード側を Pester v3 と v5 どちらにも互換を取ってしまったほうが手っ取り早いかも…なんて状況が地球上の何処かには存在するかもしれない。

テストコードの書き方

v3 と v4 の間の破壊的変更で一番デカいのは、 Should 構文の変更で互換切りを行っている部分だ。

続きを読む