WEB+DB PRESS Vol.131内の連載「第75回Perl Hackers Hub」に 「AWS Lambda入門……サーバレスでもPerlを活用しよう！」というタイトルで寄稿しました。 発売日は10月22日です。 WEB+DB PRESS Vol.131、どこよりも早い表紙画像です！ Rust入門、はじめてのElixir、実装して学ぶHTTP/3を大特集！10月22日発売です！#wdpress pic.twitter.com/uEIjuPYXu6 — WEB+DB PRESS編集部 (@wdpress) October 4, 2022 前回寄稿したときがVol.97第43回Perl Hackers Hubなので、約5年ぶり2回目の寄稿です。 WEB+DB PRESS Vol.97にPerlとRedisの記事を寄稿しました 内容 AWS Lambdaの上でPerlを動かしてみよう！という内容です。 AWS::Lambdaモジュールの簡単なチュートリアルになっています。 今年の4月に提供が開始されたAWS Lambda Function URLsにも対応した内容です。 作るのはもちろん！アクセスカウンター！ AWS Lambdaでできるのは計算だけで、単体では大したことはできません。 AWS Lambdaの便利なところは、他のAWSのサービスと連携できることです。 今回寄稿した記事でもその便利さが伝わるといいなと思い、Paws (Perl SDK for AWS)を使って DynamoDBと連携するところまでを書きました。 やったねたえちゃん！カウンターの値が永続化されるよ！！！ まとめ というわけで、続きは紙面でお楽しみください。 WEB+DB PRESS Vol.131の「第75回Perl Hackers Hub」です。 発売日は10月22日。 参考 WEB+DB PRESS Vol.131 AWS Lambda AWS::Lambdaモジュール AWS Lambda Function URLs の提供開始: 単一機能のマイクロサービス向けの組み込み HTTPS エンドポイント AWS LambdaでCGIを蘇らせる

AWS::Lambda v0.0.37 をリリースしました。 12のリージョンでARM64互換レイヤーを公開 新たに12のリージョンでAWS LambdaのARM64(AWS Graviton2)対応が発表されました。 AWS Lambda Functions powered by AWS Graviton2 now available in 12 additional regions 今回公開されたのは、以下の12のリージョンです。 アフリカ (ケープタウン) af-south-1 アジアパシフィック (ソウル) ap-northeast-2 アジアパシフィック (ジャカルタ) ap-southeast-3 アジアパシフィック (香港) ap-east-1 アジアパシフィック (大阪) ap-northeast-3 カナダ(中部) ca-central-1 ヨーロッパ (パリ) eu-west-3 ヨーロッパ (ストックホルム) eu-north-1 ヨーロッパ (ミラノ) eu-south-1 中東 (バーレーン) me-south-1 南米 (サンパウロ) sa-east-1 米国西部(北カリフォルニア) us-west-1 以下の10のリージョンは2021年9月から利用可能だったので、約1年遅れの登場です。 (AWS Graviton2 プロセッサを利用する AWS Lambda 関数を使用して最大 34% 優れた料金/パフォーマンスを実現) 米国東部 (オハイオ) us-east-2 米国東部(バージニア北部) us-east-1 米国西部 (オレゴン) us-west-2 アジアパシフィック (ムンバイ) ap-south-1 アジアパシフィック (シンガポール) ap-southeast-1 アジアパシフィック (シドニー) ap-southeast-2 アジアパシフィック (東京) ap-northeast-1 欧州(フランクフルト) eu-central-1 ヨーロッパ (アイルランド) eu-west-1 ヨーロッパ (ロンドン) eu-west-2 これを受け、「AWS Lambda Perl Runtime の Arm64 互換レイヤーを公開しました 」 で公開したARM64互換レイヤーも、ARM64対応のリージョンで公開しました。 利用可能なARNは以下の通りです。

何もしていないのに壊れました。（ライブラリのアップデートはした） AWS SDK v2 for Goが壊れた 該当のプルリクエストはこちら: Bump github.com/aws/aws-sdk-go-v2/service/ssm from 1.27.13 to 1.28.0 in /lambda/metadata-updater shogo82148/private-rpm-repo#87 true を *bool 型に変換できないと怒られてしまいました。 ./main.go:305:19: cannot use true (untyped bool constant) as *bool value in struct literal どうやらAWS SDK v2のこのコミットの影響でビルドが通らなくなったようです: aws/aws-sdk-go-v2@a13b7a4 diff --git a/service/ssm/api_op_GetParameter.go b/service/ssm/api_op_GetParameter.go index c7617dcfd0e..f58354b6528 100644 --- a/service/ssm/api_op_GetParameter.go +++ b/service/ssm/api_op_GetParameter.go @@ -39,7 +39,7 @@ type GetParameterInput struct { // Return decrypted values for secure string parameters. This flag is ignored for // String and StringList parameter types.

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[].