そういえば 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.

AWS App Runner に！VPC との接続機能がやってきました！！ 📣『VPC 内の RDBMS 使いたいから App Runner じゃなく ECS/Fargate 使ってますわ〜』という皆さまお待たせしました！！ 本日から既存の App Runner サービスを含め、直接 VPC 内リソースにアクセスできるようになります！🎉🎉🎉https://t.co/SGDTD1kPCb 1/4 pic.twitter.com/tbVt47ORSI — Tori Hara (@toricls) February 9, 2022 Amazon RDSやAmazon ElastiCacheのような一部のサービスは VPCからの利用を前提としています。 VPCを利用することによりセキュリティーを担保しているのですが、 AWS App Runner のようなマネージドサービスと連携が難しいという欠点がありました。 しかし、今回の VPC connector サポートにより簡単に連携ができるようになりました。 というわけで、お試しで MySQL (on Amazon RDS) との連携を試してみました。 使う言語はもちろんPerl！ 作るのはやっぱりアクセスカウンター！! アクセスカウンターを用意する MySQL を使ったアクセスカウンターを知らないのでテキトーに作ります。 ファイルを直接操作するよりはずっと簡単ですね。 AWS App Runner に Perl をデプロイしてみた のときと同様、 ソースコードは shogo82148/perl-on-aws-app-runner に置いてあります。 こんな感じになりました。 # app.psgi use DBI; use 5.

Apple M1 が登場してはや一年。 昨年末にはその強化版の M1 Pro / M1 Max が発表され、 Mac Book Pro / Air のラインナップも全て M1 に置き換わってしまいました。 使用しているツールが未対応だったこともあり、弊社ではインテル版を使い続けていたのですが、 今ではツールの M1 対応も進んできたので、徐々にM1への移行を進めています。 僕の手元にもようやく M1 Mac Book が回ってきたので、 何周か遅れている気はしますが、インテルからM1への移行やってみたよ(2022年1月版)ということで記録を残しておきます。 Homebrew 公式ドキュメントのインストール手順 に従って以下のコマンドを実行すればOKです。 インテルもM1も特に変わりはありません。 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)" ただしドキュメントの冒頭に記載がある通り、インテルとM1とではインストール先が異なります。 This script installs Homebrew to its preferred prefix (/usr/local for macOS Intel, /opt/homebrew for Apple Silicon and /home/linuxbrew/.linuxbrew for Linux) so that you don’t need sudo when you brew install. どうやら /usr/local への書き込みに root 権限が必要になったので、 /opt/homebrew へ移動したようです(要出典)。 /usr/local/bin にはデフォルトでパスが通ってますが、/opt/homebrew/bin には通っていないので、明示的に追加する必要があります。

dependabot を使って 依存ライブラリの更新に追従しているのですが、 API のようなデプロイが必要なものは当然ながらデプロイしないと意味がありません。 今までは手元でデプロイしてきましたが、いい加減面倒になったので GitHub Actions を使った自動化をしてみました。 とりあえずお試しで shogo82148/holidays-jp にワークフローを設定してみました。 AWS SAM を使った API で、 データーベースや外部サービスとの連携のないシンプルなものです。 API 自体の使い方はこちらをどうぞ。 祝日 API を公開しました 単純にデプロイした場合の問題点 GitHub Actions の環境にはすでに AWS CLI, AWS SAM CLI, Go 等々ビルドに必要なものはすでにインストールされています。 あとは 「適切な権限を設定」 すればデプロイ自体は直ぐにできます。 ただまあ、この「適切な権限を設定」が一番の難所なので今まで二の足を踏んでいたわけです。 AWS SAM で作成した API は AWS Lambda によって実行されるのですが、 Lambda 関数に適切な権限を渡すために IAM Role を作成する必要があります。 つまり SAM アプリケーションのデプロイには「IAM を操作する権限」というかなり強力な権限を GitHub Actions に渡さなければなりません。 例えば GitHub Actions からデプロイ用 IAM ユーザーのアクセスキーが漏れたとしましょう。 IAM ユーザー自体の権限を最小限に絞っていたとしても、アクセスキーを入手した人は「IAM を操作する権限」を使って「AWS アカウントのすべての操作が可能な管理者ユーザー」を作ることができてしまいます。 いわゆる 権限昇格の脆弱性 です。 「管理者ユーザー」さえ作ってしまえば、EC2 のインスタンスを大量にたてて仮想通貨のマイニングをしたり、S3 から情報を抜き取ったりと、デプロイとは無関係のことも何でもできてしまいます。