GitHubのプルリクエストにpushしたコミットが反映されない問題

https://stackoverflow.com/questions/45626986/updating-pull-request-after-review-changes-commit-doesnt-show-up-in-the-pull-re

問題と解決方法

GitHubには、pullrequestを行っているブランチへ新しいコミットを追加してそれをpushしたのに、プルリクエストに新しいコミットが反映されないことがあるバグが存在するようだ。
この問題はプルリクエストのベースブランチを設定変更して、元と同じベースブランチを再選択することで解決し、プルリクエストに新しいコミットが反映されるようになる。
無意味な操作に思えるが、この操作でプルリクエストの情報が更新されてうまくいくようだ。

ベースブランチの設定変更方法

https://docs.github.com/ja/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request
プルリクエストのタイトルを変更するためのものだと思っていた「Edit」ボタンは、実はベースブランチの変更も行えるボタンだった。
このUIはちょっといただけないと思う。

その他の参考情報

ちなみに上記問題が発生しているとき、レポジトリのファイル一覧上部リンクから飛べるBranchesページでブランチを見ると、Updatedに新しいコミットのpushを反映していない時間が表示されないのに、ブランチをクリックして詳細ページに飛ぶと新しいコミットのpushを反映した内容が表示される……というよくわからない状態になっていた。
問題が解決した後で、Branchesページを再確認すると、Updatedには正常に新しいコミットのpushを反映した時間が表示さていた。
以下URLによれば解決済みということになっているが、少なくとも私は2024年3月時点でこの問題に遭遇した。
https://www.githubstatus.com/incidents/pr0ptqcw6q8d

MySQLのAUTO_INCREMENT列はalter tableで再設定できるが、存在する番号以下にはできない

https://dev.mysql.com/doc/refman/8.0/ja/alter-table.html

現在の自動インクリメント値をリセットするには:
ALTER TABLE t1 AUTO_INCREMENT = 13;
このカウンタを、現在使用されている値以下の値にリセットすることはできません。
設定値が現在 AUTO_INCREMENT カラム内にある最大値以下である場合、この値は現在の AUTO_INCREMENT カラムの最大値に 1 を加えた値にリセットされます。

-- テスト用テーブル作成
create table inc_test(
    record_id int unsigned not null AUTO_INCREMENT,
    text varchar(32) not null,
    PRIMARY KEY (record_id)
);

-- 最初は、連番1から振られる
insert into inc_test(record_id, text) values (null, 'aaa');
insert into inc_test(record_id, text) values (null, 'bbb');
insert into inc_test(record_id, text) values (null, 'ccc');
select * from inc_test; -- 1, 2, 3 のレコードIDが振られる

-- 大きいレコードIDのデータを入れると、その次の番号から振られる
insert into inc_test(record_id, text) values (1000, 'ddd');
insert into inc_test(record_id, text) values (null, 'eee');
select * from inc_test; -- 1, 2, 3 に加えて、1000, 1001 のレコードIDが振られる

-- 大きい値を削除しても auto_increment はリセットされない
delete from inc_test where record_id >= 1000; -- 1001, 1002 削除
insert into inc_test(record_id, text) values (null, 'fff');
select * from inc_test; -- 1, 2, 3 に加えて、1002 のレコードIDが振られる

-- alter table で auto_increment を設定しても、テーブル内にそれより大きい値があると無意味
alter table inc_test AUTO_INCREMENT = 10;
insert into inc_test(record_id, text) values (null, 'ggg');
select * from inc_test; -- 1, 2, 3, 1002 に加えて、1003 のレコードIDが振られる

-- 大きい値を削除してから alter table で auto_increment を設定すると、連番がその値から振られる
delete from inc_test where record_id >= 1000; -- 1002, 1003 削除
alter table inc_test AUTO_INCREMENT = 10;
insert into inc_test(record_id, text) values (null, 'hhh');
select * from inc_test; -- 1, 2, 3 に加えて、10 のレコードIDが振られる

-- テスト用テーブル削除
drop table inc_test;

Balatro

クリア。とりあえず基本の5色デッキを基本ルールでクリア。
ポーカーを基本にした、指定の手数以内で目標スコアを出すことでステージクリアしていくゲーム。
デッキ構築ローグライクというジャンルで紹介されていて確かに各ゲームランは1から始まるのだが、ジャンル名については Slay the Spire とのシステム類似からそう呼称されているだけでこのゲームが単独で存在していればテーブルトップ・パズルというジャンル名になるであろう作品。
スキルの組み合わせでポーカー役のスコア(ダメージ)を増幅させて、目標スコアを達成する(敵のHPを削りきる)というステージを繰り返していくという点で、考えてみるとゲームループのメカニクスパズドラなどのソシャゲに近い。
テーブルゲームを題材にした作品でキャラクターやストーリーといったものは皆無だが、1人のスタジオで作られていることを考えるとそれも悪くなく、ゲームとして奥深い楽しみがある佳作。
音楽・効果音が地味ながら素晴らしく、落ち着いたBGMの中で倍率が上がっていくチャリンチャリン音が鳴り続けるのはクセになる気持ちよさ。



フレーバーのためにゲーム用語をポーカー単語に置き換えたものをちりばめていて、最初は理解しづらいのは良し悪しか。
たとえば独自用語でこのゲームを説明すると「各ラウンドでハンドが0になるまでにブラインドの目標チップを獲得する。それを繰り返してアンティを8まで上げるとゲームクリア」となる。
特に手札ではなく卓上に配置してパッシブスキルを発動するカードを「ジョーカー」と呼ぶのは混乱した。普通のポーカーでは手札に配られるオールマイティカードが「ジョーカー」だが、この作品のジョーカーは全くの別物である。
あとコレクション埋めのために、役に立たないことが分かりきっているジョーカーを配置枠を消費して購入することを求める仕様はどうかと思った。金は出すからアンロックだけさせてくれ。
最終的にパッシブで得られる倍率がプラス数百倍といった状況になるので、ワンペアだろうがロイヤルストレートフラッシュだろうが元役の倍率は誤差でしかなくなるというのも面白い。
そこまで行くとポーカーのゲーム性が死んでいるともいえるが、むしろ「良いビルドが完成したご褒美」としてうまく機能していると思う。

BitNet b1.58

https://qiita.com/tech-Mira/items/67dec9c5a5f025d2727a
通称1bitLLM。学習済みモデルから推論を行う際の効率よい計算方式。
遅延、メモリ使用量、処理能力、エネルギー消費の大幅な削減にが可能になるアルゴリズムのこと。
実際には演算の単位が「-1,0,+1」という3つの値で扱われるため、BitNetの「ビット」は一般的な1ビットではなく情報量としては1.58ビットになるらしい。
計算単位が実数ではないことから1.58ビット技術はGPUではなくCPUに適しているが、モデルの構築や学習においてはGPUは依然として重要な役割を果たす。

Git LFS ( Large File Storage )

https://support-ja.backlog.com/hc/ja/articles/360038329474-Git-LFS%E3%81%AE%E4%BD%BF%E7%94%A8%E6%96%B9%E6%B3%95
gitで巨大なファイルを扱うための拡張機能
gitは中央集権型バージョン管理システムと違ってローカルレポジトリにも全ての履歴を持つため、リモートレポジトリに巨大なファイルが含まれているとgit clone・git pullなどで巨大なファイルの各履歴をダウンロードしなければならなくなり動作速度に問題が出る。
この問題を解決するためにGit LFSでは、巨大なファイルの実体をレポジトリ内に置く代わりに、巨大なファイルの実体をLFSサーバー(ファイルサーバ)に置いてレポジトリにはLFSサーバーに問い合わせるための数百バイトのメタ情報テキストファイルを置く。
LFSで管理したファイルはgit clone・git pullのときではなく、git checkoutのタイミングで必要な分だけダウンロードされる。



巨大なファイルは競合時にマージが行えないバイナリファイルであることが多いため、同時に編集できないようにするためのロック機能も含まれている。

# 次のコマンドでGitLFSで扱うファイルパターンが.gitattributesファイルに追加される
$ git lfs track "*.png"

>

# あとは普通にgitコマンドで操作をすれば、特に意識せずにGitLFSでファイルを管理できる
$ git add example.png
$ git commit -m "add git lfs file"
$ git push



マシンに Git LFSをインストールされていない場合、GitLFSで管理している大容量ファイルにはアクセスできない。
クローンを試みた場合、例えば以下のようなポインタファイルが取得される。

  1. version https://git-lfs.github.com/spec/vi
  2. id sha256:7194bdd797bde471a6e29b4fa9c8c2278b3c4dadfc5cb2c36d7f4531dc6cb8f
  3. size 17330

特異メソッド

https://qiita.com/k-penguin-sato/items/d637dced7af32e4ec7c0
ruby発祥の概念で、1つのインスタンス固有のメソッドのこと。
rubyではそれを実現するために裏で自動的にクラスが作られており、それを特異クラスと呼ぶ。
javascriptpythonなどのインタプリタ言語でも実現でき、そちらは単純にオブジェクトのプロパティに関数オブジェクトを代入することで実現される。

Amazon S3 (Simple Storage Service)

https://ja.wikipedia.org/wiki/Amazon_Simple_Storage_Service
https://qiita.com/taku-y-9308/items/93c8dc5c8f86f9563acf
Amazonの提供する、REST、SOAP、およびBitTorrentを介してアクセスできるストレージサービス。
静的ウェブサイトを配置することも可能。
一般的なストレージサービスとは性質が異なり、リクエスト単位で料金がかかる(数千ファイルのアップロードやダウンロードをしても数ドルレベルだが)のだが、それでも低頻度アクセス(取り出しリクエストに最長12時間かかる)の「S3 Glacier Deep Archive」プランであれば、1TB(1000GB)保存しても1か月1ドルという低金額でファイルのオンライン保存が行える。
バックアップ用途で個人利用する場合の候補としても優秀。