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を使った移行方法の説明が多く見つかります。

AttlasianやGitlab.comもBFGを使用した移行ドキュメントを公開しています。

ところが、ドキュメント通りに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

*1:TorqueLの開発に使ってたリポジトリ

*2:https://github.com/git-lfs/git-lfs/issues/326

*3:https://github.com/git-lfs/git-lfs/issues/1062

*4:https://github.com/rtyley/bfg-repo-cleaner/issues/116

*5:https://github.com/git-lfs/git-lfs/wiki/Tutorial#migrating-existing-repository-data-to-lfs

Bitbucket CloudのMercurial(Hg)リポジトリをGitリポジトリに移行したときのメモ

　Bitbucket CloudのMercurial(Hg)サポート終了、そして最終的にはHgリポジトリは削除されるということで、Btibucket CloudのGitに変換・移行した手順のメモです。

bitbucket.org

　当初は、ほならサクッと変換してパパっと移行して終わり！　と思っていたところ、いざHgからGitに変換・移行方法を色々調べてみると、あっ、これ存外に面倒くさいな？　という感覚を得たので、移行しながら書いたメモを残しておきます。

作業環境: Windows 10 + TortoiseHG + HgGit + Convert Extension のPCで作業

　HgGitは本来Hgコマンド群でリモートのGitリポジトリを管理運用するツールですが、今回はGitリポジトリへの移行のためだけに使用します。そのため、移行したリモートGitリポジトリをHgGitで管理し続けていくという場合には本稿の手順だけでは不十分かと思います。

1. Bitbucket CloudのhgリポジトリをローカルにCloneする

　Clone完了後は失敗時のリカバリやオリジナル保全のため、ローカルでhgリポジトリを触る前に、Clone直後の状態を圧縮するなりコピーするなりしてとっておく。(HgGitの影響で何かしら操作すると.hg内にGit用ファイルが生成されたりもする)

2. コミットログのauthor名を変換(統一)する*1

　特に古いリポジトリなどでPC移行や表記ゆれなどがあり、コミット時のauthor名が統一されていないものがあった。

　移行を機にauthor名を統一することにして、Convert Extensionでリポジトリを変換を利用する。

　今回は今現在GitHubで使っているauthor名に統一した。(将来もしGitHubに持っていくとなったときに便利なので)

　author名変換リストを作成する。

　一行ごとに

[旧author名]=[新author名]

　と書いたテキストを用意する。

コミットログからauthor名を抽出する

　コマンドプロンプトで各リポジトリのディレクトリに移動して、hgログ出力からauthor名表記の行を抽出する。

hg log | findstr "ユーザ:"

※hgが日本語設定になっていたので"ユーザ:"表記で抽出、英語だとおそらく"user:"

　Windows cmd標準でuniq的なコマンドが無いので*2、出力を目視確認して必要なものをauthor変換リストに記載する。

　バッチファイルを作って必要なリポジトリのhg log全部叩いたのをユニーク抽出して一発でauthor変換リストを作るやり方もあるなと思ったけれど、今回はそこまでやらなくてもいいかなという規模だったので、コンバートするリポジトリごとに実行して、適宜author変換リストに追記した。(最終的には12種あったauthor名を1つに集約)

　変換するリポジトリの一つ上のディレクトリから、author変更のリポジトリ変換を実行

hg convert --authormap [author変換ファイル] [変換元リポジトリ名] [変換後リポジトリ名]

※--authorもあるが、現在は非推奨らしい

　変換後リポジトリは自動に生成されるので、フォルダなどは事前に作らず、変換元リポジトリ名-converted とした。(※指定していない場合は -hg が付いたものが生成される)

　変換後すぐは.hgしか存在していないので、updateで最新のファイル状態に復帰させて諸々確認する。

hg update

　author名が統一できておらず、author名変換の対象になったBitbucket Cloud hgリポジトリは15個中11個だった。(非公開設定のものを含む)

3. gitのbranchとしてhgのbookmarkを適宜作成する

　基本的にはhgのbranchを使って運用していたリポジトリにのみ実施する。

　hgとgitでbranchの概念や扱いが異なっており、HgGitにおいてはbookmarkがgitのbranchに対応する。

　hgリポジトリのbranchを確認

hg branches -c

※-cオプションで閉じたブランチも確認

　必要に応じてブランチに対応するブックマークを作成する。

　hgのdefaultブランチをGitのmasterブランチに対応させる場合のコマンドは以下の通り。

hg bookmark -r default master

※明示的にGitのbranch(hgのbookmark)を作らなかった場合、Pushはできるが何も見えず容量だけ消費しているGitリポジトリになることがある。今回は15個中2個のリポジトリで発生したが、上記のように明示的にmaster bookmarkを作成してから再度Pushしたところ正常に確認できるようになった。(なので、おまじないとして全リポジトリでとりあえずやっておくというのもありかもしれない)

　特に変名する必要のないブランチは -hg を付けたブックマークを作成(ブランチと同名のブックマークは作成できないため)

hg bookmark -r [ブランチ名] [ブランチ名]-hg

　作成したブックマークを確認

hg bookmarks

　最終的にブランチ移行が必要なhgリポジトリは15個中3個だった(元々ブランチを多数作っていたリポジトリ1個、hg defaultをGit masterに対応させる必要があったもの2個)。

4. Bitbucket Cloudで移行先となるgitリポジトリを作成する

　元となるBitbucket Cloud hgリポジトリ名に -git を付けたリポジトリを作成する。 　public/private設定などの各種設定もhgリポジトリに準じたものとした。

　Bitbucket CloudでリポジトリのURLはリポジトリ名がそのまま利用される、リポジトリ名は後で変更が可能なので、公開リポジトリなどで同じURLを維持したい場合は元のhgリポジトリ名を -hg を付けるなどして変更した後に移行したGitリポジトリ名を元のリポジトリ名にするという手段がある。

5. 移行先のBitbucket Cloud GitリポジトリにPushする

　sshの公開鍵認証によるPushになるので、Bitbucket Cloudに公開鍵の登録と、ローカルのsshクライアントへの秘密鍵の登録を済ませておく。

　今回はTortoiseHg付属のPageantを使うので、Pageantに秘密鍵を登録して、起動した状態にしておく(閉じていてもタスクトレイにいればいいはず)。

　鍵生成や登録設定については、Atlassianのサポートに記事があるので本稿では割愛する。

confluence.atlassian.com

　Bitbucket Cloud GitにPush

hg push git+ssh://git@bitbucket.org/[ユーザー名]/[Gitリポジトリ名].git

　コマンド完了後にBitbucket CloudのGitリポジトリを確認して終了。あとは置いておくなり、Gitクライアントからいじるなり、リポジトリ名変更までやって移行するなり。

　今回はGitへの移行までなので、これだけ。HgGitのまま使い続けるのであれば、毎回URI書くのは手間なので、 .hg/hgrc に各種パスを記述したりするなどいろいろな設定が必要になるはず。

移行したリポジトリ群

　公開リポジトリは長年放置してあるものが多いですが、本手順での移行の参考にどうぞ。

　リポジトリ名末尾に-hgold が付いているリポジトリが移行元になったhgリポジトリです。

bitbucket.org

参考文献など

qiita.com

qiita.com

stackoverflow.com

www.proton.jp

mochi-ha.hatenablog.com

www.google.com

www.mercurial-scm.org

bokko.hatenablog.com

confluence.atlassian.com

yymm.bitbucket.io

flying-foozy.hatenablog.com

今回使わなかった移行方法など

  • Bitbucket Cloudでリポジトリ削除するときには移転先URL表示するようにできるので、同名URLにこだわれなければ何かしらで移行した別名リポジトリに飛ばすとかでいいかも(でもオリジナル消すの怖いよな...)
  • GitHub.comのimportツールで移行すると、おおむね問題なさそうだったが、コミットメッセージの日本語が化けてしまったので利用せず
  • Gitlab.comのBitbucket Cloudインポートは今のところgitリポジトリしかインポートできなかった
  • fast-exportは今回の移行方法よりも実行環境を整えるのが面倒そうだったので試さなかった

おわりに

Git移行したんやからでかいリポジトリ(TorqueLのリポジトリがほぼ1GB)はGit-LFSに移行したろ！　と思ったらこれまた面倒な感じだったので調査と検証中...

*1:コマンドのオプション名からauthor表記にできるだけ統一したけど、ユーザ/userの方がより正しいのかな？

*2:標準コマンドの組み合わせでuniqを実現してる例はある

商標登録6121255号「トルクル」に関して、商標登録異議申立を行いました。

その他

　とりあえず、表題の通りなんですが、結論まとめ3行。

  • 商標登録6121255号「トルクル」第9類 コンピュータプログラム（記憶されたもの又はダウンロード可能なもの）の登録を取り消すよう、特許庁に異議申し立てを行いました。
  • 「TorqueL(トルクル)」の販売・配信について今のところ影響はありません(おそらく今後もないと思われる)
  • 異議申立ての結果がわかるのはだいぶ先です(年内にわかれば早い方)

商標登録6121255号について

　商標登録6121255号「トルクル」は京都機械工具株式会社を権利者として平成30年4月11日に出願、平成31年2月8日に登録、平成31年3月5日に公報されました。

　区分・指定は以下のように登録されています。(強調はこちらで付加したものです)

区分 指定商品・指定役務
7 金属加工機械器具，動力付き手持工具，インパクトレンチ，ナットランナー，電動ドライバー，電動ドリル
8 手動工具，手動利器，トルクレンチ，トルクスクリュードライバー（手動工具）
9 コンピュータプログラム（記憶されたもの又はダウンロード可能なもの），コンピュータプログラム開発用コンピュータプログラム，製造業における生産性向上を支援するためのシステム用コンピュータプログラム，測定機械器具，トルク測定機械器具，トルクゲージ，ノギス，マイクロメーター，タイヤ空気圧計，深さゲージ，距離測定機械器具，ホイールバランサ，気圧計，ゲージ，電気式測定機械器具，試験装置（医療用のものを除く。），電子出版物
37 測定機械器具の修理又は保守，金属加工機械器具の修理又は保守，手動工具の修理又は保守，動力付き手持ち工具の修理又は保守

　商標登録6121255号については、日ごろTwitter上などで「TorqueL(トルクル)」の関連情報を収集しているうちに、2018年4月末ごろに商標登録OCRbotのツイートをきっかけに出願に気づき、以来その経過を見守ってきました。

　商標登録6121255号の全情報については以下の固定URLから参照してください。(以下のURLからさらに先のURLについては共有してもうまくいかないことがあります)

https://www.j-platpat.inpit.go.jp/web/TR/JP4_2018045392/425224C7CE0E1A98AB6A0213CCD6D9EB

異議申立手続きについて

　当方は商標法第4条第1項第10号（商標法第43条の2第1号）に基づき、「トルクル」は指定区分・指定役務「第９類 コンピュータプログラム（記憶されたもの又はダウンロード可能なもの）」について未登録の周知商標であるとして、商標登録異議申立手続き*1をとることとし、特許庁に商標登録異議申立書を提出しました。

　商標登録6121255号の権利者である京都機械工具株式会社については、スマートセンシングデバイス「TORQULE（トルクル）」を実際に商品展開しており、商標のフリーライドなどには当たらず、また拙作「TorqueL(トルクル)」とは(商標上の)商品・役務などもかぶっていないものと考えていますが、おそらくスマホアプリなどの展開のために補助的に申請されたと思われる「第９類 コンピュータプログラム（記憶されたもの又はダウンロード可能なもの）」に限っては、拙作との権利衝突の可能性がある(または商標権の行使により拙作へ影響を与えることが可能である)と考えております。

　商標登録6121255号の登録にあたり、京都機械工具株式会社から連絡等のコミュニケーションはこれまでありませんし、先に書いたように商品・役務として直接衝突するものではないと思われるため、当方は京都機械工具株式会社と事を構える気もなく、あくまでも特許庁の判断に異議を申し立てるものです。

　そのため、今回の異議申立が認められれず、当該商標の異議申立範囲での取り消しが行われなかった場合においても、先使用権の主張のための法的手続き、当該商標の無効審判手続きなどは(もっぱら手続きにかかる手間暇の問題からではありますが)行わないつもりです。

　商標登録異議申立の審理については、商標登録異議期間と(その間に提出されたものの)補正期間が終了してから、6か月から8か月程度と案内されている(PDF)ため、年内に結果が出れば早い方だと思います。

　なお、「第９類 コンピュータプログラム（記憶されたもの又はダウンロード可能なもの）」が「TorqueL(トルクル)」のようなゲームソフトウェアを含むかどうかについては当方は判断がつかず、念のため異議申立てを行っているという面もあることも付記します。(類似群コードだけでは判断が難しく、家庭用ゲームソフト・業務用ゲームソフトなどは別に区分や役務が設定されていることがあるため)

　ですので、異議申立てそのものが通らなくても、「第９類 コンピュータプログラム（記憶されたもの又はダウンロード可能なもの）」が「TorqueL(トルクル)」のようなゲームソフトウェアまで及ばないことが確認できれば重畳だと考えています。

　記事の最後に今回の商標登録異議申立書と参考にした色々なURLを貼っておきます。

留意事項

　今回の異議申し立てにあたって「未登録の周知商標(商標法第4条第1項第10号)」を申立て理由に挙げていますが、周知かどうかの判断は当該商標の出願日時点(あるいはそれ以前)で判断されます。そのため、今から広めようというようなことは(ありがたいことではあるのですが)、異議申し立てには影響しません。

　「需要者の間に広く認識・周知されている」の「需要者」とは、いわゆる一般の消費者だけでなく、取引先なども含みます。

　「TorqueL(トルクル)」は2014年12月24日より前に各種イベントでの展示や、賞をいただいたことなどもありますが、今回の異議申し立てにあたっては「業として」の判断が容易である2014年12月24日以降の情報を証拠として使用しています。(甲第23号証は許諾周りのやり取りが2014年12月24日以降に行われているため例外的に使用しています)

商標登録異議申立書(一部公開用に修正入り)

f:id:nanmo:20190311213959j:plain
p.1

f:id:nanmo:20190311214026j:plain
p.2

f:id:nanmo:20190311214047j:plain
p.3

f:id:nanmo:20190311214104j:plain
p.4

f:id:nanmo:20190311214127j:plain
p.5

f:id:nanmo:20190311214143j:plain
p.6

参考URL

出願しても登録にならない商標 | 経済産業省 特許庁

商標登録異議の申立て | 経済産業省 特許庁

郵送等で手続する方へ | 経済産業省 特許庁

類似商品・役務審査基準〔国際分類第11-2018版対応〕 | 経済産業省 特許庁

「鳥貴族」と「鳥二郎」【異議申立】

www.astermarks.jp

www.ishioroshi.com

imaokapat.biz

speakerdeck.com

2019.04.26追記

今回の異議申し立ては　異議番号 2019-900082 で通知されています。

*1:本当は審議中に情報提供するのが良かったのですが、情報提供出来ることに気が付いたのが商標登録異議申立書を本格的に仕上げようとしてからでした

【追記あり】VRMとVRoid Hub登録とライセンスとか

と、ライセンス周りを調べて何となく図にまとまったので、はてなブログにも残しておくテスト。

f:id:nanmo:20190109121802p:plain

[ここから追記: 2019/02/07]

VRoid HubのFAQでライセンス周りの説明がアップされていたので、確認もしつつ再検証しました。

(ツイート張り付けてますが、ちょっと見づらいかもしれません)

ということで、「アップロードする際、自動的に～書き換わる」は誤った表現でした。申し訳ございません。

このツイートのあと数日して、ピクシブさん(VRoid Hub)からサポート問い合わせの返信がありまして、ライセンスの非互換性などの諸問題については把握していただけているようです。