Git 2.37.0 から git push に --set-upstream origin が要らなくなったという話。 出典はこちらのツイート: With the newest version of Git 2.37.0, you can run just "git push" to push new branches. No more "--set-upstream origin". Enable with: git config --global --add --bool push.autoSetupRemote true pic.twitter.com/1SzIqzvEFR — James Ide (@JI) July 12, 2022 ツイッターだけだと忘れてしまうので、検索用のメモ。 Git のデフォルトの設定では、 git push のときに upstream が設定されていないと「--set-upstream origin をつけて再実行してくれ」と 怒られます。 v2.37.0 から、これを自動的に行うオプションが追加されたらしいです。 $ git config --global --add --bool push.autoSetupRemote true 有効化すると自動的にリモートブランチを設定してくれます。

タイトルのとおり。 先日落とし物の iPhone を交番に届けました。 「落とし物を拾ったら交番に届けましょうね」と小さい頃からよく言い聞かされるけど、 意外とそういう機会ないよね？？？ということでメモ。 TL;DR 落とし物を拾ったら交番に届けよう (大事) 「拾った場所と時間」を聞かれるので、しっかり覚えておこう 拾った人がもらえる「ここまで来るのにかかった費用」「拾得物の5%から20%のお礼」「落とし主が見つからなかった場合は所有権」を受け取る権利をどうする(放棄するかしないか)を聞かれるので、決めておこう 野生の iPhone が現れた！ 駅の前を通りかかったときに、たまたまスマートフォンらしき物体がが落ちているのを発見。 とりあえず、現場の状況を記録しておこうと、一緒に歩いていた @nnsnodnb 先生に現場写真をとってもらいます。 この手順は意外と重要だったりする(かもしれない)。 拾い上げて確認してみるとどうやら iPhone のようです。 飲み会の帰りで深夜午前2時とかだったので、正直見なかったことにして帰りたいところでしたが、 モノが高価なので一応交番に届けるか・・・ということになりました。 交番での手続き 外から見たら誰もいないように見えましたが、ドアを開けると中から警察官のひとが出てきてくれました。 iPhone を見せ、落とし物を拾ったことを伝えると、「どこで拾いましたか？」 「拾ったのは何時頃ですか？」 と質問を受けました。 このときに、最初に撮った現場写真が役に立ちます。今どきのスマートフォンは写真を撮った位置や時刻を記録してますからね。 (ちゃんと覚えていたので使わなかったけど、ありがとう @nnsnodnb) その後「手続きに10分ほど時間がかかりますが、よろしいですか？」と聞かれました。 特に断る理由もないので、そのまま手続きを進めます。 手続きに必要なのは、自分(落とし物を拾った人)の 住所 ・ 名前 ・ 電話番号 です。 さらに、落とし物を拾った人の権利についての説明を受けたあと、以下のような質問を受けます。 「ここまで来るのにかかった費用」「拾得物の5%から20%のお礼」「落とし主が見つからなかった場合は所有権」を受け取る権利はどうするか 所有権を保持した場合でも、 iPhone のような個人情報が入ったものは渡せないが、それでも良いか 落とし主に連絡先を伝えることに同意するか ひとつめの質問、本当に「どうするか」としか聞かれなかったので「え、どういう選択肢があるんだ？？？」と一瞬その場で考えたんですが、 よく考えるとお礼等を受け取るのはあくまでも「権利」なので、行使 するか 放棄 するか選べるんですね。 純粋に善意で届け出た(ｴﾗｲ)ので「権利は放棄する」「連絡先を伝えることに同意する」ことを伝えました。 以上のやり取りの内容を書面にまとめてくれるので、それに署名すれば手続きは完了です。 iPhone はもらえないという話 手続きの途中で「所有権を保持した場合でも、 iPhone のような個人情報が入ったものは渡せない」と説明を受けました。 書類の控えをあとから見返すと「遺失物法第35条の規定により、法定の期間が経過しても、あなたが受け取ることができない場合があります」とあります。 「遺失物法第35条」の規定は以下の通りです。 （所有権を取得することができない物件） 第三十五条　次の各号に掲げる物のいずれかに該当する物件については、民法第二百四十条若しくは第二百四十一条の規定又は第三十二条第一項の規定にかかわらず、所有権を取得することができない。 法令の規定によりその所持が禁止されている物（法令の規定による許可その他の処分により所持することができる物であって政令で定めるものを除く。） 個人の身分若しくは地位又は個人の一身に専属する権利を証する文書、図画又は電磁的記録（電子的方式、磁気的方式その他人の知覚によっては認識することができない方式で作られた記録をいう。以下同じ。） 個人の秘密に属する事項が記録された文書、図画又は電磁的記録 遺失者又はその関係者と認められる個人の住所又は連絡先が記録された文書、図画又は電磁的記録 個人情報データベース等（個人情報の保護に関する法律（平成十五年法律第五十七号）第十六条第一項に規定する個人情報データベース等をいう。）が記録された文書、図画又は電磁的記録（広く一般に流通している文書、図画及び電磁的記録を除く。） なるほど、iPhone は第4項の「個人の住所又は連絡先が記録された文書、図画又は電磁的記録」に該当しそうです。 「いやでもロックかかっていて見れないし・・・」とも思ったけど、この規定だとロックの有無は関係なさそうですね。

C や C++ で普通にコンパイルしたバイナリを実行すると、 /lib や /usr/lib といったディレクトリから動的ライブラリを検索して来ます。 この検索パスは LD_LIBRARY_PATH 環境変数や /etc/ld.so.conf 設定ファイルで設定可能です。 しかし、これらの方法ではすべての実行コマンドの設定が上書きされてしまいます。 「自分がコンパイルしたバイナリ」のみ、検索パスをいじりたい。 できれば実行バイナリの相対パスを指定したい。 そんな場面に遭遇したので、備忘録として残しておきます。 背景 以前 Redis をインストールしてセットアップする GitHub Action actions-setup-redis を公開しました。 「Redis くらい Docker でシュッとたちあがるやろ」という話もありますが、 Workflow の中で redis-cli を使いたい場合や、 macOS で実行したい場合 Docker は使えません。 これを解決するために、actions-setup-redis では プラットフォームに合わせてビルド済みのバイナリをダウンロードする、という手法をとっています。 Redis は v6.2.0 から OpenSSL を使った SSL/TLS 通信をサポートしています。 せっかくなので SSL/TLS 通信したいですよね (というかそういう要望がきた)。 そうすると当然 Redis と OpenSSL のリンクが必要です。 別のプロジェクトですが、過去に リンクしていた OpenSSL が OS イメージから削除される という経験をしていたので、 Redis に OpenSSL をバンドルして配布することにしました。 バンドルした OpenSSL と プリインストールされている OpenSSL のバージョンがあっている保証はありません (そもそもそういう場合に備えてバンドルしてる)。 グローバルな設定を書き換えてしまっては、既存の OpenSSL に依存しているコマンドが壊れてしまいます。 でも redis-cli を使うときだけはバンドルした OpenSSL を動的ロードしたい。

そういえば Perl 5.36 もうすぐリリースだなー、なんか面白い変更あるかなー、 と perldelta を眺めていたら、あった！！！！ というわけで Perl 5.36 から導入されるらしい extra_paired_delimiters を試してみました。 Paired Delimiters 他の多くの動的言語では、シングルクォーテーション(') やダブルクォーテーション(")で囲うことで文字列を表します。 これは Perl でも同じです。 use 5.35.11; use utf8; say 'Hello World'; say "Hello World"; でもこれだけだとシングルクォーテーションやダブルクォーテーションを含む文字列を表現しようとしたときに、 エスケープが必要になります。 これくらいの短い文字列であれば余裕ですが、あまり長くなると大変です。 use 5.35.11; use utf8; say '\'Hello\' "World"'; say "'Hello' \"World\""; Perl にはそれを解決するための便利な記法があります。 例えば q(文字列) と書くと '文字列' と書いたのと同じ意味になります。 ( ) 以外にもいくつかペアがあり、以下はすべて同じ意味になります。 use 5.35.11; use utf8; say 'Hello World'; say q(Hello World); say q<Hello World>; say q[Hello World]; say q{Hello World}; この記法が便利なのは「カッコの対応をチェックしてくれる」という点です。 例えば q((Hello) World) という文字列の場合、ナイーブな実装であれば (Hello までが文字列として判定されてしまうでしょう。 しかし Perl は賢いので、 (Hello) の先頭と末尾のカッコが対応していることを認識し、 (Hello) World をひとつの文字列として扱ってくれます。

本名の英語表記を「姓-名」の順に統一していくぞ、という決意(？) 表明です。 戸籍ネームを名乗るときは「ICHINOSE Shogo」で統一していこうと思います。 背景 日本では戸籍や住民票など、公的な文章では「姓-名」の順番で名前を扱います。日常生活でも同様です。 僕もフルネームで名乗るときは「一野瀬 翔吾」と名乗っています。 (日本語が母語でないひとのために一応補足しておくと、「一野瀬」が姓、「翔吾」が名です) 一方、英語を母国語として使っている国では、名前は「名-姓」の順番にすることが多いです。 その文化に合わせて、日本人であっても英語で自己紹介する場合 “My name is Shogo Ichinose.” のように「名-姓」の順番で名乗っている人も多いでしょう。 ただ、これにはいろんな意見があって「本人の国の文化に合わせるべき」 つまり「日本人の紹介をするときは、英語で話す場合であっても 名-姓 を使おう」という人もいます。 こういう意見は僕が中学校で英語を学び始めたことからあった気がします。 この意見を聞いて「なるほど、そのとおりだな」と感じたので、「姓-名」を使っていこうと思ったのですが、 当時は「名-姓」で表記されている書籍もたくさんありました。 英語の勉強を始めたばかりの僕は混乱していしまい、名前を書くときの気分によって「姓-名」「名-姓」が混在する、 という状況がつい最近まで続きました。 特に GitHub を使うようになってからは、 LICENSE ファイルの copyright 表記でさんざん迷いました。 そして統一へ 「まあ、名乗るときは基本 shogo82148 だからいっか」とずっとそのままだったんですが、 「公用文書に名前をローマ字表記をする場合は『姓-名』とする」というニュースを見て、改めて考え直すことにしました。 (普段ニュース興味ないから、知ったのは報道から2年半後の今・・・) ローマ字表記「姓→名」、来年１月スタート　国の公文書 今までイマイチ決断できなかった理由のひとつに「Ichinose Shogo」だと極稀に Shogo が姓だと思う人がいる、というのがありました。 この申し合わせでは、姓と名の区別が必要なときの書き方も示されています。 各府省庁が作成する公用文等において日本人の姓名をローマ字表記する際に，姓と名を明確に区別させる必要がある場合には，姓を全て大文字とし（YAMADA Haruo）， 「姓―名」の構造を示すこととする。 長いものには巻かれろということで、姓を全て大文字として「ICHINOSE Shogo」の表記でいこう、と決めた次第です。 まとめ LICENSE ファイルの copyright 表記に「姓-名」「名-姓」が混在していたので、 「ICHINOSE Shogo」に統一することにしました。 もちろんこれは僕の個人的なポリシーです。みなさんはご自身の好きな名前を名乗ってください。 参考 外来語の取扱い、姓名のローマ字表記について 外来語の取扱い、 姓名のローマ字表記について（平成12年12月26日文化庁次長通知） 公用文等における日本人の姓名のローマ字表記について（令和元年10月25日関係府省庁申合せ） 公用文等における日本人の姓名のローマ字表記に関する関係府省庁連絡会議 公用文等における日本人の姓名のローマ字表記について（令和元年10月25日関係府省庁申合せ） ローマ字表記「姓→名」、来年１月スタート　国の公文書

JSONを加工するときに jq は必須の存在になりました。 jqハンドブック なんてものが発売されるくらいですからね。 そんな jq なんですが、@Gaku07jp が AWS CloudShell 上で 期待どおりに動かない、と困ってました。 なんでこんな挙動になるのかなーと気になったので、調査してみたメモです。 症状 問題となったのはこんな感じのシェルスクリプトです。 FOO=$(echo '{}' | jq) 普段開発で使用している macOS 上では FOO={} と展開されるのですが、 CloudShell 上では jq のヘルプメッセージが表示されます (2022-04-25現在)。 # CloudShell 上 $ FOO=$(echo '{}' | jq) jq - commandline JSON processor [version 1.5] Usage: jq [options] <jq filter> [file...] (...snip...) 原因 直接の原因は引数を省略してしまったことです。 jq の第一引数には jq の式が必要です。単に整形したい場合は jq . とすればOKです。 FOO=$(echo '{}' | jq .) macOS と CloudShell の違い スクリプトが動かない直接の原因はわかったものの、同じ jq なのに、なぜこのような違いが生まれるのか気になりますよね？ というわけでソースコードを追ってみました。

「[要対応] AWS Lambda における Python 3.6 のサポート終了 | [Action Required] AWS Lambda end of support for Python 3.6」というメールを受け取ったので、その対応メモ。 背景 調査自体は簡単です。親切なことに送られてきたメールにやり方がバッチリ記載されています。 次のコマンドは、AWS CLI [3] を使用して、特定のリージョン内の Python 3.6 を使用しているすべての関数を一覧表示する方法を示しています。お客様のアカウント内のこうした関数すべてを確認するには、リージョンごとに次のコマンドを繰り返してください。 以下のコマンドを叩くだけ。 aws lambda list-functions \ --function-version ALL \ --region us-east-1 \ --output text \ --query "Functions[?Runtime=='python3.6'].FunctionArn" ただ、「リージョンごとに次のコマンドを繰り返してください」とあるんですよね。 えっと・・・AWSって一体いくつリージョンあるんだっけ・・・？ このメールを書いた人は自社のリージョン数を把握しているんでしょうか？ 管理しているAWSアカウントも複数あるので、全リージョン分繰り返すなんて不毛です。 調査方法 そういうわけで簡単なシェルスクリプトを書きました。 #!/bin/bash ​ for ACCOUNT in $(perl -nle 'print $1 if /^[[](?:profile\s+)?([^]]+)/' ~/.aws/config); do for REGION in $(aws ec2 describe-regions --region us-east-1 --profile "$ACCOUNT" --output text --query "Regions[].

COVID-19 のワクチン接種3回目の副反応におびえているいっちーです。 摂取から5時間経ちましたが、まだ特に症状は表れていません。 翌朝が怖い。 さて、副反応への恐怖を少しでも紛らわせようと、 RFC9226 Bioctal: Hexadecimal 2.0 を実装してみた、というお話です。 shogo82148/go-bioctal RFC9226 Bioctal: Hexadecimal 2.0 4/1 に公開されていることから分かる通り、Joke RFC です。 実用性はありません・・・が、実装することは可能です。 今年のジョークRFC「16進数2.0」。16進数を表記するには0から9の数字にABCDEFを加えた物が一般的だが、01234567cjzwfsbvにする事で、数字かどうかで最上位bitがすぐ分かり、なんとなく形が似た文字から下3bitがすぐに連想できる為humanのbrain cyclesを抑えられるという内容https://t.co/BsmKFcqv4J — Fadis (@fadis_) April 2, 2022 一般的な16進数の変換に使われる文字を、下位3bit が同じもの同士が縦に並ぶよう配置すると、以下のようになります。 0 1 2 3 4 5 6 7 8 9 A B C D E F 下の段はアルファベットが入るのに、8, 9 だけが数字で不自然ですね(？) というわけで、下段を英字だけにしたものが Bioctal です。 0 1 2 3 4 5 6 7 c j z w f s b v 一般的に人間が一度に覚えられる物事の数は 7±2 と言われています。 16個も文字とそれに対応するbit列を覚えるのは大変です。

謎の個人ブログの「同じPCトラブルが出た人の為に備忘録を残しておきます」の頼もしさは異常 PCトラブル以外で人生とかも言及しといて欲しい — とあるコンサルタント (@consultnt_a) March 6, 2022 ちょっと明日マイナンバーカードの住所変更してくるから人生の備忘録として残しておくね・・・ — f96fd3a0-bdb9-4f10-b69f-8f765c1d341c IchinoseShogo (@shogo82148) March 6, 2022 と書き込んだのをすっかり忘れていたのでやっていきます。 住所書き換えの手順 いろいろあって千葉県柏市柏の葉キャンパスから新潟県新潟市に引っ越したので、人生の備忘録として残しておきます。 「いろいろ」の詳細はそのうち書くかもしれない。書かないかもしれない。 とりあえず悪い話ではないとだけ記しておきます。 持ち物リスト 引越し前の住所の転出証明書 マイナンバーカード 利用者証明用パスワード (4桁の数字) マイナンバーカード署名用パスワード (6文字から16文字までの英数字) 僕は今回身分証明書としてマイナンバーカードを利用したましたが、もちろん運転免許証や保険証・パスポート等でもOKです。 まあ、マイナンバーカードを発行していたらどうせマイナンバーカードの住所変更も必要なので、 このリストが一番楽だと思います。 NEXT21 へ行く 新潟市中央区役所 のサービス窓口は NEXT 21 というビルに入っているので、そこに向かいます。 Google Map で調べたら自宅からバス10分、徒歩20分だったので、 「バスの平均待ち時間を考えれば大差ないな」との結論にいたり、徒歩で向かいました。 駅からだと倍くらいかかかると思うので、駅からならバスを利用したほうが良いかもしれません。 転入届を提出する NEXT 21 の二階にサービス窓口があるので、そこに転入届を出します。 エスカレーターで二階に上がったらお姉さんが待ち受けていたので、転入届を出しに来たことを伝えると、 さっと記入用紙を出してくれました。 やっぱりこれからの時期転入・転出が多いので慣れているんでしょうね。 自分名前と引越し前の住所と引越し後の住所等々を記入し窓口に提出します。 引越し前の役所でもらった転出証明書も忘れずに。 このとき身分証明書も必要になりますが、今回はマイナンバーカードを証明書として提出しました。 マイナンバーカードの住所表記を書き換える マイナンバーカードを身分証明書として提出したので、 こちらから特に何も言わずともマイナンバーカードの住所表記書き換えをやってくれました。 ただし担当が違うらしく「同じフロアにあるパスポートセンターで待っていてください」と言われたので、 指示にしたがって移動します。 10分ほど待っていたら窓口に呼び出されてマイナンバーカードの住所表記が終わっていました。 新しいマイナンバーカードの電子証明書を発行してもらう ここで注意が必要なのは「マイナンバーカードに印字された住所のみ変更される」という点です。 マイナンバーカードの電子証明書にも住所情報が書き込まれているのですが、 その変更には別途手続きが必要です。 (こう説明を受けた覚えがあるけど、一度発行した電子証明書を書き換えることは技術的に不可能なので、実際には新規証明書の発行かな？) 職員さんから「パスワード覚えていたらこのまま手続きできますよ」と案内されたので、 案内にしたがってパスワードを入力します。 利用者証明用パスワード (4桁の数字) マイナンバーカード署名用パスワード (6文字から16文字までの英数字) (QWERTYキーボードではなくABCD配列だったので打ちにくかった)

Go言語の time.Time 型の比較は比較演算子が使えず、 Time.Before と Time.After を使う必要があります。 日本の Gopher あるあるだと思うんですが、これって覚えられないですよね・・・。 英語のネイティブスピーカーだと楽勝なんでしょうか。 よくわからなくって毎回ググっているので、対応表にまとめました。 対応表 大小関係 Go での記述 t == u ⇔ t.Equal(u) t > u ⇔ t.After(u) t < u ⇔ t.Before(u) t >= u ⇔ !t.Before(u) t <= u ⇔ !t.After(u) 以上 2023-10-24追記: Go 1.20 から Time.Compare が追加されました。 これを使うと以下のように書けます。 大小関係 Go での記述 t == u ⇔ t.Compare(u) == 0 t > u ⇔ t.Compare(u) > 0 t < u ⇔ t.