ここ4年ぐらいを無理やりに振り返っておく

昨年11月に約3年半通っていた心療内科の(通院最後の日に確認したところ軽度うつ、での)通院が終わって、現在まで割と問題なく生活できている感じなので、ざっくりここ4年ぐらいをまとめて振り返るのと、今後をどんな感じで考えているかを書いておきたいと思います。

機序

機序、と言っても、もともとそういう素養持ちだなという自覚はずっとありました。

何か一つのきっかけでそうなったというよりは、「TorqueL(トルクル)」にしろ「いろかたおりがみ」にしろ、制作中やリリース後にいいことも悪いこともありましたが、心情をどう持って行ってどう落ち着けてよいかずっとわからない状態が続いており、それによる消耗で一線を越えたという感じだと思います。*1

あとはイベント駆動*2で何とか動くような生活になっていて、今思えばそれも要因ではあるかなと思います。イベントに出る際はコンディションを整えるようにしていましたが、結果的にそれ以外の生活が怪しくなっていくというサイクルになっていたかと。

じゃあ、その一線を越えたのはいつかと言うのが自分でも正確にはわからないところなのですが、明確に自分の認識として「これはまずいな」となったタイミングの出来事は覚えています。

それは、2016年7月に参加したBitSummit 4thの後に催されたポリポリクラブの配信に参加するべく、配信会場である「さろん淳平」さんに移動したのですが、着いてから少しするとひどく気持ち悪くなってしまい、結局配信中ずっと2階で横になっていた時です。

イベント後で酒も入っていて、移動もバスだったので疲労や酔いが原因の可能性も十分にありますが、体調を崩しやすくなっている状態になっているのは間違いなく、自分の認識が変わったのは間違いないところです。(なので、イベントや配信そのものがどうこうという話でもない)

通院と緩解

それから半年間ほど、以前からやっていた気晴らしになるようなことや新しいコトに触れてみるなどしていましたが奏功せず、2017年頭に心療内科への通院を開始しています。

そこからは元々自分のゲーム制作のために充てていた時間を幾分か療養に充てるようにして通院しつつ、可能な範囲でTorqueLの移植や、頻度を減らしてのイベント参加などの活動を継続しながら何とか生活していました。

ただ、以前から手掛けていた定期的な仕事と言うのは継続出来ていました、この仕事が週5勤務というわけではなかったというのは大きかったように思います。(影響が全くなかったとまでは思いませんが)

なんやかんやと諸々凌ぎつつ生活し、2020年11月に心療内科への通院がとりあえずは終了(症状の緩解)しました。

今後のこと

2021年に入って、自分にはっぱをかけるため色々と生活環境を変えてみました。(当然うまくいくかは置いておいて)

はっぱをかけるといっても、現時点なにか新しくゲームを作るというのは難しいと考えていて、それなら奨学金の返済を加速させたいなという心持ちになってきたので、安定的収入を増やす方向に舵を切ろうとしています。(増やせるとは言っていない)

新しくゲームとか作らんのかい! という点に関しては、リハビリがてら小さいものを作ったり制作環境の維持整備は続けたり、情報収集もそれなりに継続はしていますが、やはりどうしても「(いいこともわるいこともあったのを振り返って)もう一回アレやるの?」という気持ちがずっと拭えない、というのが個人的に大きな問題になっています。

また、制作体制を変えれば...と思わなくもありませんが、今の状態で制作体制を変える+ゲーム制作というのは健康面でのリスクが高すぎるのではないかと思っています。

とはいえ、収入増と呪文を唱えれば増えるわけではないので、自分のゲーム制作という名目で確保していた時間(近年はそれを幾分か療養に充てていたわけですが)を多少切り崩してでも、やれることからやっていくべきかと思っています。

かなりざっくりと書きましたが、振り返りとしてはこんなところです。

*1:じゃあ今落ち着けているかというとかなり疑問がありますが、ある程度は腹落ち出来ているようです

*2:トルクルリリース後あたりは月に一回程度イベント参加みたいなスケジューリングで動いていた

2020年を振り返りたい

2020年も終わりなので、振り返り記事でもと思ったら、2020年中には記事3本しか書いてなかったですね。

nanmo.hateblo.jp

nanmo.hateblo.jp

nanmo.hateblo.jp

フリック入力ミスったー」は、諸々調子が良くなってきたところで、時間をちゃんと作ってちまちまやれば一応物は作れるなと自分なりに確認できた感じです。

他2本は記事と言うか、昨年から引き続いてる件だったり、告知みたいなものなのでここで改めて書くことは特に...

特に記事にしてない振り返り

今年1年を通してはご多分に漏れず、リモート対応なりで家にいる時間が長くなり、もともと毎日出勤みたいなスタイルではありませんでしたが、確かに調子を整えやすくはなったけれどパフォーマンスとしてはどうやろね? というのはありました。

じゃあその期間に何か作ったり、というのも考えなくはなかったですが、調子が良くなったのと合わせて作品を鑑賞するモチベーションが回復してきたので、そういうインプットに当てたような感じです。

これは3年半ほど続いていた心療内科への通院が(結果的に)今年11月に終わるぐらいには回復傾向が強くなっていたので、生活サイクルの維持に努めた方が良かろうと思っていたのもあります。

(通院時に、家にいる時間が長くなったのがいい影響になったんじゃないかという話があったりしましたが、まあ正直なところよくわかりません)

あとはまあ、活用できる制度は諸々活用しつつ、何となく講談社のアレにとりあえず1本投げてみたり、TorqueLリリースから6年経ったね、と言う感じでしょうか。

来年に向けては、一応緩解したので環境を変えたり見直した方が良いかなということで、年明けて少ししたら引っ越しを予定してます。(6月からちまちま探してて最近物件が決まりました)

まあどうなるかわかりませんが、とりあえず生き延びています。よいお年を。

商標登録第6121255号「トルクル」への異議申し立てについて、決定が通知されました(商標登録は維持されました)

だいたい1年2か月ほどかかりましたね。

商標登録第6121255号「トルクル」への異議申し立て(異議番号 2019-900082)について、決定が通知されました。

異議申し立ての内容は過去記事に書いてあるので、そちらの参照をお願いします。

決定にかかる文書(異議番号 2019-900082 )はおいおい J-PlatPat商標審決データベース などで公開・公報されると思いますので、 以下に自分なりに決定の内容を要約しておきます。

(あまりに長期間公開されないとかだったら文書のスキャンなども考えます)

2020.12.26 追記
商標審決データベースで異議の決定が公開されていましたので、以下にリンクを置いておきます。
異議の決定|異議2019-900082 - 商標審決データベース

  • 当該商標の「トルクル」とTorqueLの読みの「トルクル」については、指定商品(第9号)の商標として類似性が認められる、しかし自分が示した証拠類では(特に量的に)需要者への周知性は認められない。
  • 上記から、商標法第4条第1項第10号(他人の周知商標)に該当しないため、商標登録は維持する

他、個人的に気になったところを目についたところ書いておくと

  • 指定商品の解釈については同一区分(9類)であることが認められているが、商品としての類似性は否定されている。(両商品の目的、用途、流通部門及び需要者等が異なる)

というところかと思います。

自分が示した証拠類は、既に広報・発売されていたことを示す記事ややりとりが主で、具体的な数値(例えば本数や視聴率)は強く示してはいませんから、 需要者への周知性を認められるには難しい面があることは想定できることだったので、ありうる決定でした。

今回異議申し立ては認められませんでしたが、過去記事でも書いた通り、 商品・役務として直接衝突するものではないと思われるため、先使用権の主張のための法的手続き、当該商標の無効審判手続きなどは行わない予定です。

異議申し立て書を作成する際に相談させていただいた方々、提出後に対応いただいた特許庁の方々へこの場を借りて改めて御礼申し上げます。

Qiita投稿記事をはてなブログに転記しました。

以下8本のQiita投稿記事をこのはてなブログに転記しました。 Qiita投稿記事をすぐ削除するという予定はありませんが、どちらか一方だけ残すとなったらはてなブログの方を残すと思います。

カテゴリとして「Qiita移行記事」を割り当ててあります。

nanmo.hateblo.jp

nanmo.hateblo.jp

nanmo.hateblo.jp

nanmo.hateblo.jp

nanmo.hateblo.jp

nanmo.hateblo.jp

nanmo.hateblo.jp

nanmo.hateblo.jp

Markdown記法使えるしそんなに手間かからんやろと思ったら、微妙に実装が異なってて書き直しが必要になったり、画像をはてなブログにアップロードしなおしなどで結局面倒でした。

Flutter(for web)で"フリック入力ミスったー"を作った

表題の通り、Flutter(for web)を使用してフリック入力ミスを再現するWebアプリ、「フリック入力ミスったー」を作成しました。

フリック入力ミスったー/Flick Input Mistake Simulator

f:id:nanmo:20200308203047g:plain

手元にある範囲でしか動作確認できてませんが、大体のブラウザで問題なく動作すると思います。

制作中、Android向けにビルドして動作確認もおこなっていますが、Android/iOSアプリとしてリリースする予定は今のところありません。

制作メモ

フリック入力によるミスのうち、タッチ開始位置を間違えたり、フリックする方向を間違えたりするのをあえて再現することに面白みがあるんじゃないかと考えついて、今作るならReactでWebアプリかな? と思って調べつつ作りつつFlutterに移行しつつで大体一か月ぐらいで思いついた程度の実装が済んだので公開しました。

f:id:nanmo:20200308202928g:plain
Reactで作ったプロトタイプ

Reactから始めたはずがFlutterになったのは、

Reactのドキュメントを読み込んでJavascriptでざっくり作る
->Material UI導入してUIを付ける
->スタイリングが面倒そうなことに気づく
->進捗を方々に見せつつReact Native(for web)に移行した方が良いのでは? と考え始める
->Flutter(for web)という手もあると教えてもらう
->React Native, React Native(Expo), Flutterをそれぞれ調べつつ比較する
->事情はよく分からないが、React NativeのSliderがDeprecatedになっていることが気になる
->Betaだけどそこそこまともに動くみたいだし、Flutter(for web)でええか...

という経過をたどったからです。

フリック入力ミスを再現するのにあたっては、事前に考えていた機能設計で文字列と連想配列と2次元配列が扱えれば問題ないと判断していたので、JavascriptからDartに移行するのも抵抗はありませんでした。(いざやってみると、文法の違いや何やらで戸惑う点はありましたが)

フリック入力ミスを再現する仕組み

ひらがな、ローマ字、数字といった入力パネルをキーとして連想配列(Map)を作成し、Mapのバリューとして入力する文字を並べた2次元配列を用意しました(1次元目がタッチ位置に、2次元目がフリック方向に対応する)、これを一文字ずつ照らし合わせて、該当するものがあればタッチ位置ミスやフリック方向ミスの判定を行って、タッチ位置ミスであれば1次元目の選択をランダムにずらし、フリック方向ミスであれば2次元目の選択をランダムにずらして選択・表示する、というやり方です。(二つのミスは独立に判定しているので、両方発生する場合もあります)

//Dart
  static const Map flickInputTextMap = {
    'hiragana': [
      ['あ', 'い', 'う', 'え', 'お'],
      ['か', 'き', 'く', 'け', 'こ'],
      ['さ', 'し', 'す', 'せ', 'そ'],
      ['た', 'ち', 'つ', 'て', 'と'],
      ['な', 'に', 'ぬ', 'ね', 'の'],
      ['は', 'ひ', 'ふ', 'へ', 'ほ'],
      ['ま', 'み', 'む', 'め', 'も'],
      ['や', '「', 'ゆ', '」', 'よ'],
      ['ら', 'り', 'る', 'れ', 'ろ'],
      ['わ', 'を', 'ん', 'ー'],
      ['、', '。', '?', '!'],
    ],
    //以下パネルごとにMap定義が続く

ローマ字・数字の入力パネルや、ひらがなも濁音・半濁音で被る文字があるので、照らし合わせる前に入力パネルの順番をシャッフルするような処理も入れています。

該当する文字が無い場合は全走査することになるので、最悪1文字ごとに3次元配列にアクセスするような感じになるので、自動実行の際は最大文字数を設定して制限するようにしています。

上の方法でのシミュレートは、変換ミスや、パネルを間違えるといった場合が含まれないことになりますが、てにをはの間違いぐらいが面白みがあると思っていたのと、実装難度のバランスを考えてこうした方法になっています。(漢字を開いてさらに間違えてどうこうとかやりたくなかった)

中華フォント問題

Flutterでビルドしたアプリが日本語で動作させるといわゆる中華フォント問題が発生することがあり、いくつか解決法があるようなのですが、今回は flutter_localizations を使ってサポート言語に日本語のみを設定する方法をとりました。(そのうち公式に修正されるかもしれないので、いつまでこういった類の作業が必要なのかは謎)

//Dart
//Flutter 1.14.6 / channel beta
import 'package:flutter_localizations/flutter_localizations.dart';
//中略
class MyApp extends StatelessWidget {
  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'material app title',
      localizationsDelegates: [
        GlobalMaterialLocalizations.delegate,
        GlobalWidgetsLocalizations.delegate,
      ],
      supportedLocales: [const Locale('ja', 'JP')],
//後略

作ってみて

  • 型が無いのはやっぱり辛い時もある(React/JSでイベントオブジェクトという名の別物に行き当たった)
  • Flutter/Dartはドキュメント自体はそろっているけど、やっぱりまだ日本語のドキュメントが少なく感じた。
  • Flutterのウィジット/コンポーネントは種類も機能も充実しているが、同じ機能を実現するのにいくつも手段があるので、それはそれで面倒に感じた。
  • React/Github Pagesで考えていたものが気がついたらFlutter(for web)/Netlifyになっていた。どういうことなの...
  • ReactもFlutterもsetStateしたあとのStateの更新タイミングで結構困りがちだった

(予定はないけど)更新するなら

  • 入力パネルの順番シャッフル頻度の調整
    • 今だと文章全体のルーチンが始める前に一回シャッフルするだけなので。ただ、あまり頻繁にやるとメモリを食いつぶすような気もして微妙。
  • UIの調整
    • 変換対象テキストと変換後テキストの位置が離れているので、UIコンポーネントの順番を入れ替えるか、オプションをまとめて閉じておくことができるようにする
  • 多言語対応
    • 英語切り替え対応はしたいけど、そもそも日本語圏以外でフリック入力ってどういう扱いなんやろか...
  • アイコン
    • 各ストアのアプリで出すなら、Flutterデフォルトのじゃないのがやっぱりほしい

最後に

フリック入力のミスを再現するアプリ」のアイコンってなんだよと思いながら、マテリアルデザインのドキュメント読みながらひねり出したのが次の画像になります。

f:id:nanmo:20200308202215p:plain

以上です。

2019年を振り返る振り返る

特に大きな活動はありませんが軽く一年を振りかえってみる記事です。

1月

nanmo.hateblo.jp

2018年末あたりにVRM化した100ポリモデルを、VRoid Hubに持ち込む際にあった色々をまとめた記事です。

さすがに11か月も前となると、サービスの仕様が変わっていそうですが、最近はどうなんですかね?

pixivさん仕様面などへの問い合わせに回答頂きありがとうございました。

hub.vroid.com

3月

nanmo.hateblo.jp

ゲームソフトウェアを含む、第9類区分での「トルクル」商標登録への異議申し立てを行いました。

現在までに、特許庁から異議申し立て番号も通知され、補正命令への対応などを行いました。

結果がわかったらまた記事にすると思います。(通るにしろ通らないにしろ参考になるとは思うので)

でもまあやはり、異議申し立てはお金もかかる手続きなので、可能なら審議中に情報提供しておいた方がベターだとは思います。(どうやって、どのタイミングで気づくかという問題もありますが)

www.jpo.go.jp

5月

Indie-Streamのサイト閉鎖に伴う情報のFANBOXへの移転や、Steam版トルクル(TorqueL)のパブリッシャー変更(セルフパブリッシングからPLAYISMパブリッシング)、あとトルクル(TorqueL)のステージをモチーフにしたスマブラのステージを公開しました。思ったより活動してた。

www.pixiv.net

www.pixiv.net

www.pixiv.net

パブリッシャー変更に関して何か書こうかと思ったけど、fanboxに書いてあるので十分な感じでしたので、こちらからは以上です。

3月から6月にかけて断続的に

スマブラのスマッシュや、鉄拳のバウンドコンボの爽快感を抽出したようなのはどうかなーとUnityを色々いじってました。

twitter.com

弾いたり、引っ張ったりして飛ばすアクションは最近そう珍しくない感じですが、そこにゴルフ、もといスピードゴルフ(実在する競技です)を混ぜ込んだ架空スポーツ的な感じでどうやろと仮組していましたが、ゲーム全体のデザイン方法がピンとこなかったので、とりあえず塩漬けにしてあります。

特にマップ・ステージの作りをどうするかというあたりが難儀で、有機的な(?)形をとれるようにしたい感じだったのですが、今んところいい手は思いつきませんでした。

8月

BitbucketのMercurial(hg)サポート終了が予告されたので、Gitへ移行をやってみた記事と、Gitに移行したついでにGit-LFSも導入してみる作業とそのメモを記事にしました。

nanmo.hateblo.jp

nanmo.hateblo.jp

実際にサポートが終了するのは2020年6月1日あたりのようなので、時期が近づくとまた需要がある感じでしょうか。

10月

トルクル(TorqueL)のDL/デジタル販売価格を改定しました。

www.pixiv.net

理由とかはFANBOXの記事で十分かなと思うので、そちらのほうで。

いざやってみると、やはり各ストアへの準備とか、セルフパブリッシングとそうでないものの混じり合いとかでたいそう面倒なので、そう気楽にやるものではないですね...(2か月ぐらいかけて調整してた気がする)

12月

12月24日でトルクル(TorqueL)リリース5周年でした。

特に催しとかはありませんが、引き続きよろしくお願い致します。

ここ最近のこと

9月あたりから、Kindle Paperwhiteを投入して、100件に届きそうになっていた積み本(デジタルだけど)*1をいい速度で消化できるようになってきました。(読んだ分さらに続きを買っていたりもするので、大体20件前後を積みながら消化しています)

それに加えてFGO(アニメ), 仮面ライダーゼロワン, 孤独のグルメ(ドラマ)あたりを毎週録画してみていますが*2、気を抜くと数週分溜まるので、やはり本にしろゲームにしろ、アニメをはじめとする映像作品にしろ、心身健康でないと新しいものに触れていくのはやはり難しいなと、思いを新たにしました。(ほかにも色々触ってはいますが、まあたまにTwitterでつぶやいてるのでそれで)

調子が戻ったぐらいだと、停滞した分はそのままなので、どうしたものかなと思いますが、まあどうにかなるんじゃないでしょうか。多分。多分?

どうも活動そのものができないことと、センサー各種が正常に動いていないのが併発するため、正常になる過程で、センサーだけが正常化したことによって、活動量が横ばい、またはむしろ下がるような状態になることがあります、活動量という結果だけでなく、プロセスも考慮してみる必要があるようです。(プロセスだけ見てもダメではあるので、程度問題ということになるかと思います)

それでも10月のころから比べると、引き続き減薬しつつ、より思考を巡らせたり・深めたりができるようになってきています。

とはいえ、この状態に戻るまでの間に体力的なところや技術的なところは落ちていたり、下がっていたりするので、改めて習得していく必要があるので、そこはやはり気が重いところではあります。

そう思って、色々予定を立てたりすると片頭痛や体調不良でアカン*3みたいなことはやっぱりあるので(この記事を書くのですら若干その傾向がありました)、どうにか前向きにやっていきたいと思います。

ここまで書いて、はてなブログとFANBOXの使い分けが相変わらず適当なことに気づきましたが、うーん、どうしましょうね...まあ、そのうち...(先延ばし)

*1:紙の本も色々積んでるけど電子本はやっぱり気軽でいいですね

*2:余裕があるときは録画だけはしっかりしてあったハイスコアガール(アニメ)を見進めるようにしています。まあまだまだ録画だけして積んであるのは結構あるんですが...

*3:コーヒーなどのカフェインの効用で、無理やり眠くならないようにをしても全く思考もできず、活動もできずに、哲学的ゾンビのような状態になるだけでほぼ意味が無い時があったり。

git lfs migrate で Git-LFS 移行したときのメモ

Mercurial(Hg)からGit移行移行したついでに、ほぼ1GBとかあるリポジトリ*1をGit-LFSに移行した際のメモです。

Git-LFSを扱えるサービスとしてはBitbucket CloudよりもGitlab.comの方が制限が緩かったので、そちらへの移行も同時に行いました。

ja.confluence.atlassian.com

gitlab.com

作業環境: Windows 10 + Git for Windows(+Git Bash,Git LFS)

0. BFGを使わなかった理由

Git-LFSへの移行(変換)を調べているとBFGを使った移行方法の説明が多く見つかります。

AttlasianGitlab.comBFGを使用した移行ドキュメントを公開しています。

ところが、ドキュメント通りにBFGによるGit-LFSを実行したところ、一見問題なく移行できたように見えて、実はうまくいってないのでは? という状態になり、色々調べ直したところ、現在は git lfs migrate で問題なく移行できるというところに行きつきました。*2

BFGでのGit LFS移行について、自分の環境で問題になったのは以下の点です。

  1. BFGが生成する .gitattributes ファイルはオプションで指定した文字列がそのまま入ってしまう関係上、Git-LFS的に無効なフォーマットで生成される場合がある。(これにより、問題なくgit lfs pullできるが、git lfs管理のファイルがModifiedな状態として認識される事態が発生した)*3
  2. .gitattributes ファイルが、ルートになるディレクトリだけでなく、対象となるファイルがあるフォルダ毎に生成されてしまう。*4(1.の問題に引っかかると認識しにくいが、リポジトリ内を一括で変換してるのにディレクトリ毎に .gitattributes ファイルを管理することになるのはうれしくなかった)

1. Bitbucket Cloud から --mirrorでクローン

git clone --mirror git@bitbucket.org:[ユーザー名]/[リポジトリ名].git

※クローンした [リポジトリ名].git を別にコピーしておくなり圧縮して置いておくなりすると、繰り返しテストする時など大変便利がいい。

2. git lfs migrate info による事前調査

クローンした[リポジトリ名].gitフォルダに移動したのち、現在の状態を調査

git lfs migrate info --everything

上記を実行すると、リポジトリに含まれるファイルのサイズを拡張子毎に集計して、容量降順に並べて表示してくれる。 デフォルトだとトップ5の拡張子まで表示してくれる。

--everything は全ブランチを対象にするオプション。

git lfs migrate info --top=20 --everything

だと、トップ20まで表示してくれる。

あくまでも拡張子毎に集計しているだけなので、.csなども普通に入ってくる。

参考にしつつ、対象となる拡張子(またはファイル)を選定する。

なお、このgit lfs migrate infoでは拡張子の大文字小文字も厳密に分けて集計される。 これはのちに実行する変換コマンドでの指定でも同様なので留意する。

バイナリだからとにかくGit-LFSに移行すればよいってものでもないと思うので、そこの判断は慎重に行う。(あとマイナー?な拡張子はバイナリかどうかの判断に困ったりもする)

3. git lfs migrate import 実行

[リポジトリ名].gitフォルダ内で、Git LFSに移行するファイルを指定してgit lfs migrate importコマンドを実行する。

git lfs migrate import --include="[Git LFSに移行するファイルの指定]" --everything

--include でのファイル指定はワイルドカード(*)が使えるので、拡張子を指定する場合は *.[拡張子] で指定する。複数指定がある場合はカンマ(,) でつなげていく。

例として、以下の指定だと、拡張子wav,png,bmp,zipのファイルが移行対象になる。

git lfs migrate import --include="*.wav,*.png,*.bmp,*.zip" --everything

※細かい指定方法などは git-lfs/git-lfs-migrate.1.ronn at master · git-lfs/git-lfs · GitHub を参照のこと。

あまり指定が長くなるようなら、(Git Bashなので) \ でつないで複数行にする。

git lfs migrate import の実行が完了したら、以下のコマンドで、ローカルのファイル・キャッシュを整理する。*5

git reflog expire --expire-unreachable=now --all && git gc --prune=now

リポジトリのルートディレクトリに .gitattributes が追加されているので、--inlude で指定したファイル名、パターンが問題なく記述されていることを確認する。(履歴も改変されて.gitattributesが最初期にコミットされたことになっているはず)

また、git lfs migrate import 実行後に git lfs migrate info を実行すると再度集計できる。この時Git-LFSに移行したファイルはポインタファイルでの集計になっている。これは移行の確認や効果の見直しなどに使う。

4. Gitlab.com へ --mirror でプッシュ

Gitlab.comで新しく作ったGitリポジトリへプッシュ

git push --mirror https://gitlab.com/[ユーザー名]/[リポジトリ名].git

既になにかしらあるリポジトリへも --mirror だとforce扱いでpushできるが、それは結構な荒療治なので諸々確認が必要になる。 (なので新しいリポジトリにpushして移行する形にしている)

リポジトリURI形式がBitbucket CloudとGitlab.comで異なるのはたまたま作業していてそうなっただけで特に意味はありません。

5. 参考資料ほか

github.com

tech.griphone.co.jp

qiita.com