Lycolog

• 特定ブランチ以外を全部消す
• マージコミットをリバートする
• コミット間のハッシュを見る

特定ブランチ以外を全部消す

Git 2.25.1で確認

# マージされてないのは残す
git branch -d $(git branch | grep -vP <PCRE pattern>)
# 強制削除
git branch -D $(git branch | grep -vP <PCRE pattern>)

参考：git-branch - List, create, or delete branches (git-scm.com)

マージコミットをリバートする

Git 2.25.1で確認。基本-m 1で問題ないと思われる

git revert -m 1 <commit>

参考：git-revert - Revert some existing commits (git-scm.com)

コミット間のハッシュを見る

Git 2.25.1で確認

# 新しい順
git log --pretty=format:'%H' <commit>..<commit>
# 古い順
git log --pretty=format:'%H' <commit>..<commit> --reverse

参考：git-log - Show commit logs (git-scm.com)

新しくセットアップしたTypeScriptのプロジェクトでauto-importが機能しなかったので原因を調べた。

ここ数年ちまちま起きて、そろそろイラついて我慢の限界を覚えたので…。

確認環境

再現方法

再現用のサンプルリポジトリでsrc/index.tsの下図コードに対してauto-importが発動する操作を行う。

発生条件

恐らく以下を全て満たすときにauto-import操作をしようとした時に発生する。地味にややこしい。

node_modules配下に存在し、@types/モジュールを持たないものでかつ、同一プロジェクト内でimportされておらず、package.jsonのdependenciesに書かれていない。

因みにhoge/piyo/fugaのようなモジュールはhogeだけがdependenciesにいてもauto-importが動かない。これを全部package.jsonのdependenciesに書いていくのは目眩がするので正直auto-importを諦めて自分でimportを調べて書くのが無難だと思う。

発生原因

TypeScript 4.0で実装されたSmarter Auto-Importsのせい。

node_modulesをクロールすると重すぎるので@types/だけ読み込んで、あとはpackage.jsonのdependenciesも見るようにしたよという内容らしい。

解消方法

package.jsonのdependenciesに全部のモジュールを書いていくというのが解決方法になるが、気が遠くなるので諦めた方がいい。初回だけは苦痛でもimportパスをどうにかして調べて手動で書いて、あとはauto-importされるのを期待するのが良いだろう（そんな何度もimportしないと思うが…）

取り敢えず基本npm iで入れて行き、スラッシュ区切りのやつは諦めるくらいがちょうどいいだろう。

再現用のサンプルリポジトリではpackage.jsonのdependenciesに"firebase/app": "^10.4.0"を追加することでsrc/index.tsのinitializeAppに対しauto-importが発動する様になるはずだ。

あとがき

早い話、node_modules配下にあって@types/を持たないものはTypeScriptに対応する気がないんだな程度に思っておくのが良いだろうが、TS化で@types/を廃止したライブラリがある当たり、すごく微妙な感じがある。ちょっとなんとかしてほしい。

そもそもpackage.jsonのdependenciesはnpm packageを公開する時に動作するために必要な依存関係を登録する場所で、型の補助をする場所ではなかったはずだ。

少なくともnpmjsのdevDependenciesには以下の記述がある。つまりモジュールを配布する時に動作に不要な依存関係を含まないようにするためにdevDependenciesがあるということだ。つまりdependenciesには動作に必要なものだけを入れるべきで、モジュールを配布しない場合、このフィールドは不要になるはずである。

If someone is planning on downloading and using your module in their program, then they probably don't want or need to download and build the external test or documentation framework that you use.

In this case, it's best to map these additional items in a devDependencies object.

ただTypeScriptがdependenciesに書かないとauto-importが失敗すると言っているので使うものはdependenciesに入れるというのが良いのだろう。（配布しないモジュールだとしても）

ただそれにしてもauto-importを動かすためだけに、dependenciesに同一モジュールのスラッシュ違いを大量に入れていくのはバカバカしいと思う。

  "dependencies": {
    "firebase": "^10.4.0",
    "firebase/app": "^10.4.0",
    "firebase/database": "^10.4.0",
    "firebase/analytics": "^10.4.0",
    ...
  }

かといってinitializeAppがfirebase/appにあるなんて知らんわけで、全部のパスに総当りしていくのも嫌だし、一々リファレンス漁るのも面倒だし、なんかもうちょっといい具合になって欲しい…。

確認環境

手順

1. gpg -kで削除したいキーの下記XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX相当の部分をコピペ

pub rsa3072 2021-01-17 [SC]
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
uid [ 不明 ] Foo Bar <foobar@example.com>
sub rsa3072 2021-01-17 [E]

1. gpg --delete-secret-keys XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXで秘密鍵を消す
2. gpg --delete-keys XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXで公開鍵を消す
3. gpg -kで削除出来ているか確認

なんとなくアプリを作りたくなったので。Hello worldするとこまで。

確認環境

手順

1. 公式サイトからインストーラーを落としてくる
2. NextとAgree連打でインストールする
3. Empty Activityを選ぶ

   1. 

4. Tools→Device Managerでデバイスがなんか入ってるのを確認する

   1. 

5. 再生ボタンみたいなやつを押す

   1. 

6. しばらくするとエミュレーターが起動するのでドロワー中央のAndroidアプリを起動

   1. 

7. 画面が出てくればOK

   1. 

Groovy Scriptの読み方が分からなかったので読み解き方のメモ。全て憶測

確認環境

サンプルコード

def credentials = com.cloudbees.plugins.credentials.CredentialsProvider.lookupCredentials(
    org.jenkinsci.plugins.plaincredentials.StringCredentials.class,
    jenkins.model.Jenkins.instance.getItemByFullName("ここにフォルダパス")
)

def cred = credentials.findResult { it.id == "ここに取得したいやつのCredentials ID" ? it : null }

読み解き方

個人的な解釈なので特に根拠はない。全て憶測。

lookupCredentialsの部分

端的に言うとデータ型とストア名のようなものを指定し、認証情報を取得する機能であると思われる。Groovy Script的にはCollectionが返ってくる。

• com.cloudbees.plugins.credentials.CredentialsProvider.lookupCredentials())
  • 第一引数にデータ型、第二引数にLOOKUP条件を設定するものと思われる
• org.jenkinsci.plugins.plaincredentials.StringCredentials.class
  • 文字列の認証情報ということだと思われる
• jenkins.model.Jenkins.instance.getItemByFullName())
  • 現在のJenkinsインスタンス（Jenkinsシステムそのもの）から名前で要素を取得するものだと思われる

findResultの部分

• http://docs.groovy-lang.org/docs/groovy-2.1.3/html/groovy-jdk/java/util/Collection.html#findResult(groovy.lang.Closure)
  • 恐らくJSのArray.findと似たような機能で、itの中に配列要素が入ってくるので、それを使って配列内容の要素を取り出すのに使うのだと思う