Shogo's Blog

Nov 20, 2022 - 1 minute read - Comments - go golang

50音順(JIS X 4061)をGoで実装してみた

今後Go言語でも50音順ソートしたくなるのでは、と虫の知らせがあったので作ってみました。 shogo82148/jisx4061 50音順とは何者か 50音順は「あいうえおかきくけこ・・・」あたりまでなら簡単なので、すごく簡単に思えるじゃないですか。 しかしここに濁音・半濁音・拗音・片仮名・長音記号etc. が入ってくるとだいぶややこしくなります。 濁音を含んだソート たとえば濁点の扱いを見てみましょう。 「さどう」「さとうや」「サトー」「さと」「さど」「さとう」「さとおや」という7つの単語を並べ替えます。 普通にGo標準のソートを使うと以下のようになります。 package main import ( "fmt" "sort" ) func main() { list := []string{ "さどう", "さとうや", "サトー", "さと", "さど", "さとう", "さとおや", } sort.Strings(list) fmt.Println(list) // Output: // [さと さとう さとうや さとおや さど さどう サトー] } 一見良さそうですが・・・「さと」と「さど」が遠く離れてしまいました。 このふたつは音が似ているので近くに配置したいです。 jisx4061を使ったソート shogo82148/jisx4061を使うと解決します。 package main import ( "fmt" "github.com/shogo82148/jisx4061" ) func main() { list := []string{ "さどう", "さとうや", "サトー", "さと", "さど", "さとう", "さとおや", } jisx4061.

Nov 16, 2022 - 1 minute read - Comments - github

GitHub GraphQL のノードIDフォーマットが変わるらしい (続報)

以前 GitHub GraphQL のノードIDフォーマットが変わるらしい に書いたように、 将来ノードIDフォーマットが変わるらしいらしいです。 これについて、旧式のノードIDを使用した場合に警告がでるようになった、とアナウンスがありました。 GraphQL Legacy Global ID Deprecation Message というわけで、どんな警告文がでるのか試してみました。 実際の挙動 試しに僕の名前を取得するクエリを実行してみると、以下のような警告文がでました。 $ gh api graphql -f query='query { node(id: "MDQ6VXNlcjExNTczNDQ=") { ... on User { id name login } } }' { "data": { "node": { "id": "MDQ6VXNlcjExNTczNDQ=", "name": "ICHINOSE Shogo", "login": "shogo82148" } }, "extensions": { "warnings": [ { "type": "DEPRECATION", "message": "The id MDQ6VXNlcjExNTczNDQ= is deprecated. Update your cache to use the next_global_id from the data payload.

Oct 19, 2022 - 1 minute read - Comments - aws perl aws-lambda

WEB+DB PRESS Vol.131にPerlとAWS Lambdaの記事を寄稿しました

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を蘇らせる

Oct 8, 2022 - 1 minute read - Comments - aws perl aws-lambda

AWS::Lambda v0.0.37リリースのお知らせ

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は以下の通りです。

Sep 20, 2022 - 2 minute read - Comments - aws go golang gcp

AWS SDK v2 for Goが壊れた、Googleお前もか

何もしていないのに壊れました。(ライブラリのアップデートはした) 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.

Aug 11, 2022 - 2 minute read - Comments - git

git push のときに自動的にリモートブランチを作成する設定

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 有効化すると自動的にリモートブランチを設定してくれます。

Jun 11, 2022 - 1 minute read - Comments - 人生の備忘録

落とし物の iPhone を交番に届けた話

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

May 27, 2022 - 2 minute read - Comments -

動的ライブラリの検索パスに、実行バイナリからの相対パスを入れたい

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 を動的ロードしたい。

May 16, 2022 - 2 minute read - Comments - perl

Perl の extra_paired_delimiters を先取り!

そういえば 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 をひとつの文字列として扱ってくれます。

May 6, 2022 - 1 minute read - Comments -

本名の英語表記を姓名の順に統一していくぞという話

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