Team Foundation バージョン管理から Git に移行するための旅路 (3)
免責事項
この文書は技術文書ではない。私の思い出話や蘊蓄を多分に含んだ内容であり、とても冗長である。 また、正確性にも欠ける点があるかもしれないし、この資料を作るために時間を掛けて検証したりなどはしていない。 読者は、そういう文章であるという点を十分理解した上で、読んでほしい。
本ドキュメントは読者の参考になればと思って書いてはいるが、本文書の内容によって生じた一切について責任を負わない。 すべて "At your own risk" である。
はじめに
今回は Team Foundation バージョン管理のワークスペースについて話す。
これは完全に私の私感であるが、Team Foundation Server 2012 Update 2 で Git をサポートした当時、Team Foundation Server の開発チームは現在のデファクト スタンダードの状態まで Git がなるとは思わなかったのではないか、と想像している。
というのも、Git がリリースされた当時、製品責任者である Brian Harry によって 「Git と Team Foundation バージョン管理 (TFVC) は同様に扱う」 とアナウンスされていたからだ。
が、その後状況は変わる。世の中は急激に Git にシフトし、開発者は GitHub を OSS 開発の基盤として利用し、マイクロソフトは GitHub をマイクロソフト ファミリーの一部にした。最終的に、Visual Studio の次期バージョン開発では "Git first" として、Git 前提の機能が増えて行くのである。
実は、Team Foundation Server 2012 では Team Foundation バージョン管理に対して、Git のトレンドを見て導入した新機能が追加されている。 それが今回話す「ローカル ワークスペース」である。
（他にも .gitignore から影響をうけた .tfignore もあるが、今回は含まない）
ローカル ワークスペースとサーバー ワークスペース
ローカル ワークスペースは、Team Foundation Server 2012 で追加された機能である。 私の偏見が大分入っていると思って聞いてほしいが、Git のような分散バージョン管理のトレンドを Team Foundation バージョン管理を使うユーザーにも提供しようという思惑から実装された機能と思われる。
実は、Team Foundation Server 2012 の既定ではローカル ワークスペースとなっており、知らぬうちにローカル ワークスペースを使っていた、ということもよくある。
まずは、この Team Foundation Server 2012 で追加されたローカル ワークスペースと、それ以前から存在しているサーバー ワークスペースの違いについて話そう。
サーバー ワークスペース
サーバー ワークスペースは、各クライアントのワークスペースをサーバー側で保持する、という方式である。ワークスペースには、マシン、ユーザー、マッピングするフォルダー（サーバーのどのパスをローカルのどこに保持するか）といった情報が管理されており、内部的にはどのファイルをいつ取得したのか、といった情報まで記録されている。
一方、これにはいくつかの問題があった。当時、言われていた問題は下記のようなモノがある。
- パフォーマンスが悪い
- オフライン時に開発ができない
前者は、サーバー側で管理をするため、ファイル数が膨大になると処理時間がかかるというもの。後者は、何かをする度にサーバーアクセスが必須となるため、オフライン時に開発作業ができなくなるというものである。
ローカル ワークスペース
ローカル ワークスペースは、これまでサーバー側で管理してきたワークスペース情報の一部をローカル側で保持する方式である。 たとえば、サーバー ワークスペースの場合、ローカルファイルを編集したい場合は、サーバーに対してチェックアウト要求を行い修正を開始する。また、ファイルを元に戻すのにもサーバーのアクセスを必要とする。
一方、ローカル ワークスペースの場合は、チェックアウト時にサーバーへの要求は不要で、未変更時のファイルをキャッシュとして内部保持するため、変更前に戻す、変更前との比較もサーバーアクセスなしに実現できるのである。
また、オフラインモードにも対応しており、飛行機による移動中などインターネット アクセスが難しい場所であっても、ローカル ワークスペースに保持されている情報の範囲で編集作業が続行できる。
とても便利な機能であり、だからこそ既定になっているのだが、実はローカル ワークスペースによって失われた重大な機能がある。 それが、「チェックアウト ロック」である。
チェックアウト ロック
チェックアウト ロックは、特に Visaul Source Safe ユーザーから愛された機能であり、この機能があったからこそ Subversion などの他のバージョン管理ではなく、Team Foundation Server に移行した、という人もいたことだろう。
実は、Team Foundation バージョン管理では、ロックに２種類が存在し、一つが「チェックアウト ロック（悲観的ロック）」、もう一つが「チェックイン ロック（楽観的ロック）」である。
悲観的ロックと言われているチェックアウト ロックのイメージは「私が編集している間に他の人がファイルを触ると怖いので、誰もチェックアウトさせないぞ！」というものである。一方、楽観的ロックであるチェックイン ロックは「私が編集している間に触られても良いけど、私が先にチェックインするよ！（競合するのはそっちだぞ）まぁ、競合したときは、そのときで！」という感じである。
さて、お気づきだろうか？チェックアウト ロックを実現するためには、ファイルが編集されようとする（チェックアウトする）度に、サーバーにアクセスし、ロックされているかどうかを検証する必要がある。
つまり、ローカル ワークスペースのように、ローカル内のファイル修正時にサーバー アクセスが行われないケースでは、チェックアウト ロックは動作しないのである。 実際、これはローカル ワークスペースの制限事項になっており、一部のユーザーはこの機能のためにサーバー ワークスペースを現在も使っているという人もいると思う。
おわりに
さて、長くなってきたので今回はここで終わりにしたい。 ワークスペースの動きの違いから、チェックアウト ロックの話をしたところで、きっとあなたはこう思ったハズだ。「仕組みの話からして、Git ではチェックアウト ロックは使えないんですよね」と。実は方法が無いわけではない（二重否定）。
というわけで次回は、Git を機能拡張する話をしよう。 では、また次回。
(おまけ)
実は、記事をためておいて、時間投稿機能を使って段階的に公開させるはずが、設定ミスで全部公開してしまった。（1, 1.5, 2 が同時公開されたのはそれが理由である） 今後は定期的 (?) に投稿されるはずなので、焦らず待ってほしい。
Team Foundation バージョン管理から Git に移行するための旅路 (2)
免責事項
この文書は技術文書ではない。私の思い出話や蘊蓄を多分に含んだ内容であり、とても冗長である。 また、正確性にも欠ける点があるかもしれないし、この資料を作るために時間を掛けて検証したりなどはしていない。 読者は、そういう文章であるという点を十分理解した上で、読んでほしい。
本ドキュメントは読者の参考になればと思って書いてはいるが、本文書の内容によって生じた一切について責任を負わない。 すべて "At your own risk" である。
はじめに
今回は、Team Foundation バージョン管理がどのようにファイルを管理しているのかについて話す。 これは、Git に移行する際に何に注意する必要があるのかについて理解するのに役立つ。
集中型バージョン管理と分散型バージョン管理
Team Foundation バージョン管理は「集中型バージョン管理方式」であり、Git は「分散型バージョン管理方式」である。 しかし、読者の中には「Git の場合もサーバー上で管理されているコードをみんなで取得したり発行したりしているのだから、Team Foundation バージョン管理のときとサーバー・クライアントの関係は同じなのでは？」と思うかもしれない。
答えは、その通り。ただし、ここでいう集中と分散という言葉が指しているのは、クライアント・サーバー間の関係ではなく、「履歴情報」である。
Team Founation バージョン管理の場合、指定されたコードのみがクライアントに渡るが、履歴情報のすべてを保持しているのは Team Foundation Server / Azure DevOps Server だけである。
一方、Git の場合は、基本的に履歴情報すべてを同期するので、クライアント側でも履歴情報が保持される。 これにより、万が一サーバーがダウンしてしまっても、開発者は履歴の変更も参照も問題無くできる、というわけだ。（システムダウン中に他者にコードを共有するのは簡単ではないが）
履歴がクライアントにもコピーされるとはどういうことか
上で、履歴がクライアント側にコピーされる、これによりサーバーがダウンしていても履歴の更新や参照が可能になる、という話をした。 では、この話はどのような問題があるのかを考えてみよう。 たとえば、次のような課題が思い浮かぶことだろう。
- リポジトリが巨大な場合は、クローンに時間がかかる（クライアント側の容量も心配になる）
- 履歴情報すべてがクライアントに保持されるので、情報漏洩時のリスクが高まる
- 細かい監査ができない
それぞれについて簡単にコメントする。
リポジトリが巨大な場合は、クローンに時間がかかる
Git リポジトリをローカルに取得する操作を「クローン (Clone)」と呼ぶが、この際にリポジトリの履歴情報すべて取得するので、リポジトリの容量が大きいほどダウンロードに時間がかかり、クライアントのディスク容量も消費される。
マイクロソフトの Windows チームが Git に移った当時のリポジトリ サイズは 300 GB を超えていたそうで、そのままクローンした場合は１日では終わらなかったそうだ。（実際、彼らはそれを解消するために独自のツールを開発することになるのだが、それは別の話。）
300 GB は極端な例にしても、バイナリファイルを大量に履歴に含めていると、数 GB 以上というケースはよくある。 これまでバージョン管理からバイナリ ファイルを取り除くかをこれまで説明してきた理由を理解していただけたと思う。
情報漏洩リスクが高まる
言うまでも無く、ソースコードは開発会社にとって「資産」である。ソースコードの漏洩だけで大きなリスクだが、Git リポジトリが漏洩した場合はすべての履歴情報だけでなく、何時、誰が（名前とメールアドレス）修正したのか、という情報も漏洩してしてしまう。
また、Git リポジトリの性質から、比較的簡単に外部のパブリック リポジトリ (GitHub.com など) に再発行できてしまうのもリスクの１つと言える。 最近は「あなたの適正給与を調べます」といったサイトで、Git リポジトリを分析するサービスもあり、「気軽な気持ち」で情報漏洩をしてしまった事例もあるので、注意が必要である。
これに対する対処は Git 単独ではできず、クライアント側のセキュリティ ソリューションと、Git をホスティングするサービス側で防衛する必要がある。 具体的にどのような方法があるのか興味がある読者も多いかもしれないが、今回の話とはずれてしまうので、また別の機会にする。
細かい監査ができない
これまで説明してきたとおり、Team Foundation Server からバージョン管理されているファイルを取得するには、都度 Team Foundation Server にアクセスしなければならない。このため、Team Foundation Server 側で誰が何時、バージョン管理にアクセスしたのかを把握することができる。 また、後述するサーバー ワークスペースの場合は、ワークスペース管理自体をサーバー側で行っているため、誰が、どのコンピューターに、いつ、どのファイルを取得したのか、というのが保持されている。
一方、Git の場合は、自身の作業が完了し Team Foundation Server / Azure DevOps Server にプッシュ (発行) するまで、サーバー側は関知することができない。
Team Foundation バージョン管理におけるリポジトリ
次に、Team Foundation バージョン管理のリポジトリと、Git リポジトリの範囲と管理について話す。
Team Foundation Server / Azure DevOps Server には、チーム プロジェクト コレクション (TPC) と呼ばれる複数のチーム プロジェクト (TP) を束ねる概念があるが、Team Foundation バージョン管理はチーム プロジェクト コレクションと１対１の関係として管理されている。 一方、Git はチーム プロジェクト (TP) の中に複数の Git リポジトリを管理することができる。
これだけを聞くと、Git リポジトリの方が柔軟でよさそうだが、いくつか問題がある。
たとえば、Git ではリポジトリ内のフォルダーやブランチ単位でアクセス制御ができない。 たとえば、リポジトリの docs フォルダー配下は、マニュアル担当者しか変更させたくない、といったことは実現できない。
Git は基本的にリポジトリ単位でアクセス権限を分けることになるため、上記の例でいえばドキュメント管理用のリポジトリを作成し、そこに適切なアクセス権限源を付与させることになる。このように、アクセス権限の単位や方法も変わる。
おわりに
さて、長くなってきたので、今回はこれで終わりにしたい。 次回は Team Foundation バージョン管理のワークスペースの種類の話をしよう。Git のようになりたかった Team Foundation バージョン管理が Git を参考にして追加した機能、そして失われた機能、そして Git ではどうするのか。 それでは、また次回。
Team Foundation バージョン管理から Git に移行するための旅路 (1.5)
免責事項
この文書は技術文書ではない。私の思い出話や蘊蓄を多分に含んだ内容であり、とても冗長である。 また、正確性にも欠ける点があるかもしれないし、この資料を作るために時間を掛けて検証したりなどはしていない。 読者は、そういう文章であるという点を十分理解した上で、読んでほしい。
本ドキュメントは読者の参考になればと思って書いてはいるが、本文書の内容によって生じた一切について責任を負わない。 すべて "At your own risk" である。
はじめに
前回の最後に「次回は、Team Foundation バージョン管理がどうやってファイルを管理しているのかを話す」言って、今回は前回入れ忘れていた話をする。 なので、番号を 1.5 とした。次回の話に興味がある人は 2 を待って欲しい。
何を忘れていたかといえば、「ライブラリ管理」の話である。今回は、アプリが使用するライブラリをどうやって管理するのかについて話す。
今のソフトウェア開発
今どきのアプリケーション開発では、どの開発言語を使っていてもライブラリを管理するための仕組みが搭載されている。 たとえば、C++ や .NET といったマイクロソフトの技術を使っている場合、Visual Studio 2012 以降では NuGet と呼ばれるパッケージ管理機能が IDE に搭載されている。 振り返ってみれば、今アプリケーションを新規で開発するのに、外部ライブラリを一切使わずに大規模なアプリを作る、というのは簡単ではないだろう。
もし、対象のプロジェクトが Visual Studio 2010 などパッケージ管理機能に対応していないような開発環境である場合、残念ながらビルドに使用するファイルはバージョン管理の中に直接入れ込むか、ビルド時に参照可能なファイル サーバーなどに配置するしかない。 一方、もし Visual Studio 2012 以降の開発環境で NuGet が使用できるならば、ライブラリを NuGet パッケージ化することを検討すると良い。
NuGet パッケージをどこで管理するか
Team Foundation Server や Azure DevOps Server を使っているならば、パッケージ管理 (Azure Artifacts) で管理できる。 以前は別途有償の機能だったが、クラウド版である Azure DevOps Services に対して Azure Artifacts の無料枠が追加されたタイミングで、無料で使えるようになった（確か 2019 年）。
もし、何らかの事情で Team Foundation Server / Azure DevOps Server 以外で管理したいという場合には、ファイル サーバー上でホストする機能もある。（たとえば、近い時期に GitHub への移行を考えていて、これ以上 Azure DevOps Serverの機能を使うことは避けたい、というケースがこれに該当するかもしれない）
自社ライブラリを NuGet パッケージ化する
これはネットで調べてもらえば、沢山事例もドキュメントも出てくるのでここでは解説しない。 強いて言うなら、次の点を意識すると良いと思う。
- 依存ライブラリを１つのパッケージに集約しない (やりがち)
- ライブラリの依存関係はパッケージの依存関係として管理する
- セマンティック バージョニングを学習する
これも簡単だがそれぞれについてコメントしておく。
依存ライブラリを１つのパッケージに集約しない
アプリをビルドするために必要な依存ライブラリが 10 ファイルあったとしよう。１つずつ NuGet パッケージ化するのは面倒だな...と思っても、１つに集約することはお勧めしない。
たとえば、そのうちの１つのライブラリに脆弱性が見つかった場合、そのライブラリのために集約したパッケージを更新しなければならない。すると、パッケージのバージョン番号は、ライブラリのバージョン番号と違う値になるだろう。すると、次はパッケージのバージョンと内包されているライブラリのバージョン番号一覧を管理しなければならなくなる。そんなことはやめた方が良い。
基本的にはライブラリ単位で１パッケージにする考えで良いが、依存性が高く、ファイルとして重複しないライブラリならまとめてしまってもいいだろう。
ライブラリの依存関係はパッケージの依存関係として管理する
ライブラリが他のライブラリに依存しているということはよくある。 そのような場合は、NuGet パッケージの依存関係として nuspec ファイルに記述するとよい。
こうしておくことで、利用者が個別にパッケージをインストールする手間が減り、更新の際も楽になる。
セマンティック バージョニングを学習する
NuGet パッケージも含め、多くのパッケージ管理システムで扱われるパッケージのバージョンは「セマンティック バージョニング」と呼ばれるバージョン番号で管理されている。これは従来のバージョン番号の付け方とは異なるもので、利用者目線での影響度をバージョン番号として管理するものになっている。
自社ライブラリを NuGet パッケージとして管理する場合は、まずはこのセマンティック バージョニングで管理できないかどうかを検討してみると良いだろう。
外部ライブラリを NuGet パッケージ化する
外部ライブラリの場合は基本的に NuGet.org などのパブリック パッケージ フィードに公開されていないかどうかを確認するとよい。 有償のサードパーティ ライブラリの場合は、ライセンスの関係から NuGet.org ではなく、独自のフィード上で管理されているケースもある。面倒だが、これについてはライブラリ個別に確認するほかない。
もし、NuGet.org などのフィードからは入手できないライブラリがある場合は、自身で NuGet パッケージ化するとよい。 このときは、バージョン管理が楽になるようにファイル バージョンとライブラリ バージョンを一致させると良いだろう。
おわりに
パッケージ化できたら、プロジェクト ファイルの修正、自動ビルドの修正などを行う必要があるが、これは言及しなくても分かることだろう。 ポイントは、ライブラリ類はバージョン管理に直接入れるのでは無く、パッケージ管理側でやるべきだ、ということだ。
これは単にバージョン管理からバイナリを排除するだけでなく、DLL 地獄問題や更新時のバージョン管理の複雑さを排除するのにも多いに役立つ。 手間はあれど将来的に役立つ作業なので、ぜひやってほしい。
さて、次回こそ Team Foundation バージョン管理がどうやってファイルを管理しているのかを話そうと思う。 それでは、また次回。
Team Foundation バージョン管理から Git に移行するための旅路 (1)
免責事項
この文書は技術文書ではない。私の思い出話や蘊蓄を多分に含んだ内容であり、とても冗長である。 また、正確性にも欠ける点があるかもしれないし、この資料を作るために時間を掛けて検証したりなどはしていない。 読者は、そういう文章であるという点を十分理解した上で、読んでほしい。
本ドキュメントは読者の参考になればと思って書いてはいるが、本文書の内容によって生じた一切について責任を負わない。すべて "At your own risk" である。
はじめに
この文書は Team Foundation Server (TFS) または Azure DevOps Server 上で Team Foundation バージョン管理を使っている方で、将来または今後 Git に移行しようと考えている方に向けて書くものである。タイトルに「旅路」と付けたのは、この移行作業が単純なものではなく、じっくりと理解し、時間をかけて準備・作業しなければ、上手くいかないという厄介さがあることを伝える為だ。
この作業は簡単ではないし、考慮事項も多い。だが、もしあなたの資産を正しく Git に移行したいのであれば、この文書が役立つだろう。
Team Foundation バージョン管理とは何なのか
Team Foundation Server を使っている人の中には、自分が使っているバージョン管理方式が「Team Foundaiton バージョン管理 (通称、TFVC)」であると知らない人もいる。それは、リリース当時、そのような名前は無かったことに起因している。
この名前は Team Foundation Server 2012 Update 2 以降、バージョン管理方式に Git が追加されたことに起因している。 以前は「Team Foundation Server のバージョン管理機能」という位置づけでよかったものが、Git と従来方式を選択できる（正確にはどちらも一緒に使うことができる）ことになったため、便宜上名前を後から付けたのである。
数十年前のソフトウェア開発を振り返る
読者の中には、20 年以上ソフトウェア業界に身を置いている人もいれば、そうでない人もいるだろう。 20 年前には、バージョン管理のツール自体は存在していた (「ごった煮版 CVS」とか懐かしい) が、まだ主流ということではなく、小規模なアプリ開発であればファイル共有フォルダーに "v1" "v2" といったフォルダーを作って世代管理をしていた時代だったように記憶している。
このような古（いにしえ）の時代の風習は、なぜか未だに残っており、Team Foundation バージョン管理の履歴を蝕んでいることがよくある。 たとえば、下記の項目に該当しないだろうか？
- 作成したツールは開発当時のツール チェインから更新してはならない (VB 6 で開発したならば、現在の修正も VB 6 で行っている、ということ)
- ビルドしたライブラリや実行ファイル (.dll, .lib, .exe) を成果物管理の目的でバージョン管理に入れている (コードもいれるし、ビルド後のバイナリも入れる)
- ビルドしたファイルの日付で変更管理を行っている
- コードを変更する度に誰がいつ変更したのかを各行にコメントとして挿入している
- 開発ドキュメントをバージョン管理に入れている
それぞれについて私なりのツッコミをいれておきたい。
ツール チェインを更新しない
おそらくこのルールが適用された背景には、コンパイル ツールのバージョン更新でバイナリの内容が変わり、動作しなくなったというトラウマから来ているのではないかと思う。これは今でも希に見舞われる問題だが、そもそもセキュリティ上の問題でランタイムや OS 自体が強制的に更新される現代において、コンパイル ツールを「永遠に固定化」するメリットは小さい。少なくとも、サポート終了 (EOS) がアナウンスされる頃になったら、保守コストとメリットを天秤にかけて、ツールを更新する必要がある。
今更「ついに重い腰を上げて、VB 5 から VB.NET の最新に移行する気になりました！」と言われても、「既に移行ツール自体が EOS になっている/入手できない」という状況にもなりかねない。
自身の体調に違和感を感じたら自然と病院に行くように、EOS の足音が聞こえたら移行を検討すべきなのだ。
バージョン管理にビルド後のバイナリ ファイルを追加する
この話は、上の話に繋がっている。「ビルドする度に内容が変わるかもしれない」という不安から、バージョン管理にバイナリ ファイルを入れているのだ。 そして、v1.0 といったラベルを付与することで、ソースコードと関連するバイナリ ファイルを一元的に管理できるという面もある。
Team Foundation Server には自動ビルド (CI/CD) によってビルド後のファイルが成果物（アーティファクト）として保持されるので、こちらで管理すべきなのだが、Team Foundation Server を単純な「バージョン管理ツール」として見ている人ほどバイナリ ファイルを直接入れる傾向が強いようだ。（Visual Source Safe からの移行者など）
なお、これはバージョン管理の観点からも推奨できないのだが、話が長くなるので、また別の話とする。
ビルドしたファイルの日付で変更管理をしている
大規模なアプリ開発をしているケースでコンポーネント毎に出荷管理をしていると、「ファイルの作成日時・更新日時で棚卸しをしているので変更したくありません」と言われることがある。（実際、Team Foundation バージョン管理にはユーザーフィードバックによりチェックアウト日付になる機能が追加された過去がある）
これは先ほどの話と同じで、成果物のファイル単独で判断するのではなく、自動ビルド側で保持・管理をさせるほうが適切と言える。 もちろんファイル単独では判断できないが、ビルド ツールはいつ、どのコードを、誰の指示でビルドしたのかを保持しており、同時にビルドした成果物（バイナリ ファイル）も関連付けして保持している。棚卸しの情報としては、これで十分だと私は思う。
ソースコードに変更日付と変更者をコメントとしてを追記している
これを見た時に私は目を疑った。なぜなら、同じ情報をバージョン管理自身が保持しているからである。 「差分は分かっても誰がどの行をいつ修正したのかわからないじゃないか！」という人がいるとすれば、それは「注釈 (Annotate)」機能を知らないだけである。
どうでも良いが、Git ではこの機能を blame と呼ぶ。blame は「責任を負わせる」、「非難する」を意味し、確かに「ビルドが通らない！誰がこの行を変更したんだー！」という時に使う機能ではあるが、名前付けがダイレクトすぎるだろう、と思わなくもない。が、Team Foundation バージョン管理の場合は「注釈 (Annotete)」という名前がぼんやりしすぎていて、そんな機能だとは知られていないことがよくあるので、それに比べるとマシなのだろう。
開発ドキュメントをバージョン管理に入れている
これは先ほどの「ビルド後のバイナリ ファイルを追加している」ケースと殆ど同じ話である。 ドキュメントの世代管理をしたいならば、今は SharePoint であったり、オンライン ファイルストレージ系のアプリで世代管理をしてくれるので、そういった機能を使うことが推奨される。
もし、ソースコードと紐付けたいというのであれば作業項目 (Azure Boards) を使うことを検討してほしい。 作業項目には、ファイルを直接アタッチすることもできるし、リンクを追加することもできる。 もし管理したいファイルが Office ファイルならば、SharePoint 上で管理し、対象世代の URL を作業項目にリンクさせるのが一番簡単だと私は思う。
作業項目をどう管理すればいいのか、というのも議論のポイントだが、これも話が長くなるので、またいつかの話とする。
おわりに
長くなってきたので、今回はこれで終わりにしたい。
読者の中には、昔話をして終わりじゃないか！と思うかもしれないが、これらは Git に持ち込んではいけない過去の風習である。 今は便利なツールも機能もあるし、ソフトウェアの開発状況も変わっている。「よくよく考えてみると、不要なのでは？」となるものもあれば、代替手段が必要なものもあるだろう。その場合は、私が書いたコメントを参考にしてみてほしい。
次回は、Team Foundation バージョン管理がどうやってファイルを管理しているのかを通じて、Git 移行時に起きる問題点を考えてみよう。
それでは、また次回。
Halo 65 を購入した話
タイトルの通り、人気のメカニカル キーボードである Halo 65 を購入した。
Halo65 Wireless Mechanical Keyboardnuphy.com
HHKB との比較
元のキーボードは HHKB (Happy Hacking Keyboard) Professional HYBRID Type-S なので、これとの比較・感想を書いておく。
HHKB Professional HYBRID Type-S
Halo 65
- いいところ
- 十字キーが独立したキーとして存在する
- PgUp, PgDn, End が独立したキーとして存在する
- 接続方式が多い (Blueooth で最大 3 台のマルチペアリングに対応、2.4GHz の無線接続に対応、有線接続も可能)
- デザインが洗練されている（個人の感想）
- RGB バックライト搭載 (そこまで光はキツくないので、ON でも問題は少ない)
- 残念なところ
- いいところ
` や ~ キーが押下しにくい問題
この特殊な配列で一番困るのは、IME の On/Off だと思う。
たとえば、英語キーボードで日本語 IME を有効にしたい場合、既定では Alt+` を押下することになっているが、Halo 65 の場合、` キーは Fn+Esc で入力することになるので、IMEの切り替えの度に、３つのキー (Alt+Fn+Esc) を押下しなければならない。
日本語IMEが MS IME の場合は、日本語の切り替えを Win+Shift に置き換えるオプションがあるので、これを使うのも１つの方法なのだが、私は ATOK 使いなので、このオプションは使えない。
ATOKもIMEの On/Off を切り替えるキーを変更することはできるが、CtrlまたはShiftの組み合わせで実現しなければならいため、他のアプリに影響がある。 *1
というわけで、PowerToys の Keyboard Manager を使ってキーショートカットを上書きすることで問題を回避した。(現在は、ショートカットで Win(Left)+Space を IME Kanji にマッピングすることでこの問題を回避している。)
*1:たとえば、Ctrl+Spaceは切り替えしやすいキーバインドだが、Visual Studio の InteliSence と重複する
Chrome の 1Password 拡張機能を使うときにページの再読み込みが必要となる問題の解決方法
ブラウザーのセキュリティが強化され、拡張機能の サイトへのアクセス が既定で クリックされた場合のみ になっているため、いざ 「1Password を使ってログイン情報を Auto Fill するぞ！」と思ったタイミングでページの再読み込みが必要となってしまうことがある。
解決する手順は次の通り。
- Google Chrome 拡張機能のページを開く (または、
chrome://extensions/にアクセスする) - 1Password 拡張機能の
詳細をクリック - [サイトへのアクセス] のドロップボックスをクリックし、[すべてのサイト] にする *1
*1:すべてのサイトへのアクセスを許可してしまうのが怖い...という気持ちにもなるが、そもそもこの会社が信頼できないならばログイン情報を預けてはいけない...。
Windows で画像内の文字を手軽にコピーしたい
macOS 12 (Monterey) になってから、OS 標準の機能として画像内のテキスト認識機能が搭載されましたね。 実装されたときは「こんな機能使います？」と思っていましたが、結構使いたいときがあります。
- エラー情報がスクリーンショットとして添付されてきたとき (GUID を手打ち...！)
- 画像内の長文の英語を翻訳したい
macOS では標準搭載ですが、Windows 11 にはまだ標準搭載されていません。 もちろん、ウェブサイトやフリーソフトとして類似したものは沢山ありますが...機密情報を含むことになるので、なるべく安全・安心なソフトで実現したいことではあります。
良い方法がないものか、と思ったときに見つけたのが PowerToys です。
PowerToys
PowerToys は Microsoft が開発しているアプリで、Microsoft ストアから入手できます。
月１回ぐらいのペースで更新されるので、Microsoft ストア経由で自動更新できるのはいいことです。
PowerToys は、簡単にいえば便利な機能ツールであり、複数の機能を持っています。 この機能の 1 つが "Text Extractor" です。
Text Extractor
ショートカットで動作するようになっているため、Windows でショートカットを利用しない人には、少し使い方がわかりにくいです。 一応、簡単な使用手順を書いておきます。
Win+Shift+Tキーをクリックします (好きなキーに変更できます)- 画面が暗くなり、カーソルが十字カーソルになったら、ドラッグしてテキストとしてコピーしたい範囲を指定します
- 画面が明るく戻ったら、貼り付けたい場所で
Ctrl+V(貼り付け) します。
なお、日本語/英語どちらにも対応していますが、優先する言語は指定できます。 うまく認識されないぞ？と思った際は、設定画面の [優先する言語] を変更してみてください。
一応、公式ドキュメントもあるので、詳細が知りたい場合はこちらもご確認ください。
注意事項など
先にも説明したとおり、PowerToys は便利機能の詰め合わせで、既定で様々な機能が有効になります。 Text Extractor 以外にも便利な機能が一杯ありますが、使わない機能は無効にしておくと良いでしょう。
また、PowerToys は常駐型のアプリです。 常駐が嫌いな方は設定アプリで常駐を無効化すると良いでしょう。
