最近アプリの UI で角丸アイコンを見ることが多くなりました。 この角は完全な円ではなく、スーパー楕円というものだという情報を入手しました。 スーパー楕円 UI を iOS+Swift で実装する 丸よりも丸みを感じる!? スーパー楕円の魅力とデザイン 記事の中ではベジェ曲線で近似する方法が書かれています。 なるほど、こうすれば描けるのか！と関心したので、自分でもベジェ曲線で描いてみることにしました。 スーパー楕円 スーパー楕円というのは円の方程式を以下のように拡張したものです。 $$ \left|\frac{x}{a}\right|^n + \left|\frac{y}{b}\right|^n = 1 $$ n は曲線を制御するパラメーターで n=2 は円となり、n>2 の場合は円と四角形のあいだのような形になります。 n が大きいほど四角形に近づいていきます。 3 次のベジェ曲線 Illustrator のようなベクターツールではおなじみのベジェ曲線です。 ベジェ曲線は任意の次数に拡張することができますが、コンピューターグラフィックスで多く用いられるのは 3 次ベジェ曲線です。 制御点を $ \boldsymbol{B}_0, \boldsymbol{B}_1, \boldsymbol{B}_2, \boldsymbol{B}_3 $ とした場合の 3 次ベジェ曲線の数式を具体的に書き下すと以下のようになります。 $$ \boldsymbol{P}(t) = \boldsymbol{B}_0(1-t)^3 + \boldsymbol{B}_1 3t(1-t)^2 + \boldsymbol{B}_2 3t^2(1-t) + \boldsymbol{B}_3 t^3 $$ 近似してみる 以下の記事と同じ戦略で近似してみます。 ベジェ曲線による円の描画の制御点の位置はなぜ 0.55228…なのか? スーパー楕円は左右対称・上下対象なので、第一象限の形だけ求めれば十分です (x > 0, y > 0 )。 またアフィン変換に対して不変なので a = b = 1 の場合のみを考えます。

いつかやろうと思っていた AWS::Lambdaの Docker コンテナ対応、 年を越してしまったけど、ようやく手を付けました。 AWS Lambda の新機能 – コンテナイメージのサポート 使い方 以下の handler.pl を Docker コンテナとして AWS Lambda デプロイする例です。 use utf8; use warnings; use strict; sub handle { my $payload = shift; return +{"hello" => "lambda"}; } 1; ビルド済みイメージを使う Amazon Linux 2 ベースの Perl Runtime 入りイメージをDocker Hub で公開しています。 これをベースにデプロイしたいファイルを追加し、CMD に実行したい関数名を指定するだけ。 簡単ですね。 FROM shogo82148/p5-aws-lambda:base-5.32-paws.al2 COPY handler.pl /var/task/ CMD [ "handler.handle" ] Docker Hub からのダウンロードに Rate Limit が適用されるようになったので、 同じイメージを Amazon ECR Public Gallery でも公開しました。 こちらを利用することも可能です。

弊社では GitHub のレポジトリ管理に Terraform GitHub provider を使用しています。 いちいち手元で terraform plan や terraform apply を叩くのは面倒なので、 GitHub Actions を利用することを考えました。 tf ファイルと現実のリソースとの不整合を避けるために、 これらのコマンドは排他的に実行する必要があります。 例えば terraform apply を実行している最中に terraform plan を実行することはできません。 ここで問題になってくるのが GitHub Actions のジョブ並列数です。 2020-12-30 現在、GitHub Actions は同時に 20 並列まで実行可能ですが、逆に並列数を制限できないという贅沢な悩みがあります。 一応 Matrix Build の並列数を制限するオプションはありますが、 ワークフローをまたいだ並列数の制限はできません。 これを解決するために作ったのが actions-mutex です。 shogo82148/actions-mutex actions-mutex Marketplace 使い方 ただワークフローから uses を使って呼び出すだけ。 面倒なアクセスキーの設定等は必要ありません。簡単ですね。 on: push: branches: - main jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: shogo82148/actions-mutex@v1 - run: ": 排他的に実行する必要のあるタスク" 仕組み actions-mutex と同様のことを実現する Action として GitHub Action Locks があります。 これの使用も考えたのですが、GitHub Action Locks はバックエンドに AWS DynamoDB を使用しています。 DynamoDB のテーブルを作成した上で AWS IAM を適切に設定する必要があり、セットアップが面倒です (まあ単に DynamoDB 食わず嫌いしているだけ、というのもあります)。

この記事はフラーAdvent Calendar 2020の3日目の記事です。 2日目はid:gibachan03 さんで「Androidアプリエンジニアになって気づいたiOSとの違い」でした。 さて、公開当初色々して遊んだ GitHub Actions ですが、今年も引き続き遊んでました。 いくつか新しい Action を作ったものの、このブログでは紹介していなかったので、2020年作ったものを紹介したいと思います。 actions-upload-release-asset Yet Another Upload Release Asset Action 一言で表すのならば、 Yet Another actions/upload-release-asset GitHub Action です。 GitHub の Releases にファイルをアップロードする Action です。 このアクションは GitHub 公式という安心感はあるのですが、一度のステップで1個のファイルしかアップロードできません。 ソースファイル本体と、ビルド済みバイナリと・・・と色々アップロードしたいものがあったので、新しく作りました。 actions-upload-release-asset は @actions/glob の Glob Pattern に対応しているので、一つのステップで複数のファイルをアップロードすることができます。 例えば、カレントディレクトリにあるテキストファイルを全てアップロードする例は以下のようになります。 on: release: types: - created jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 # steps for building assets - run: echo "REPLACE ME!" > assets.txt - uses: shogo82148/actions-upload-release-asset@v1 with: upload_url: ${{ github.

なんだか今日はもうコードを書く気がしないので、最近思っていることをつらつらと・・・ タイトルの通り、最近 AWS SDK for Go v2 の行く末がちょっと気になっています。 あんまり話題になっているのを観測できていないので、少し現状を書いてみます。 背景 最近あったビッグイベントが v0.25.0 のリリースです。 Client Updates in the Preview Version of the AWS SDK for Go V2 パッケージの構成が見直され、APIの呼び出し方法も変わりました。 まあ、プレビュー版なのでよくあること・・・なんですが、ちょっと変更点が多すぎて追いきれない。 v0.25.0 移行で入った変更の数々 ちょっと一例を見てみましょう。 設定の読み込み Before: v0.25.0 より前は external パッケージを使って設定を読み込んでいました。 import ( "github.com/aws/aws-sdk-go-v2/aws/external" ) func loadConfig() (aws.Config, error) { return external.LoadDefaultAWSConfig() } After: これが config パッケージに変更になりました。 import ( "github.com/aws/aws-sdk-go-v2/config" ) func loadConfig() (aws.Config, error) { return config.LoadDefaultConfig() } API の呼び出し Before: Requestオブジェクトを作って、そのSendメソッドを呼ぶ形式でした。 s3svc := s3.

リリース当初は git push など GitHub 上のイベントしかトリガーにできなかった GitHub Actionsですが、 workflow_dispatch イベント の登場により手動実行ができるようになりました。 社内でもこの機能を利用してワークフローの手動実行をしていたのですが、人間とは欲深いもので「毎回ワークフローを選択してポチポチするのだるい」という声があがってきました。 そういうわけで、Pull Request のコメントをトリガーにしてワークフローを実行する簡単なボットを作ってみました。 方針 workflow_dispatch と issue_comment をトリガーにしたワークフローを作ればいいだけの気もしますが、 以下のような理由からワークフローからワークフローを呼び出す形にしました。 workflow_dispatch を使った既存のワークフローがあるので、それを流用したい トリガーが複数あると、イベントの種類に応じてペイロードの形式が異なるので、地味に処理が大変 issue_comment は全部のコメントに反応するので、本当に見たいログが埋もれてしまう コメントを投稿した Pull Request のHEADでワークフローを実行して欲しい issue_comment はイベントの発生元として、デフォルトブランチのHEADが渡ってきます イベントのペイロードには、プルリクエストへのリンクが入っているだけで、HEADの情報はわからない 実装 jfurudo1 がサードパーティのアクションを使ってゴニョゴニョやっていたものの、 あんまりうまく行ってなさそうだったので、bash script でエイヤッと書き直しました。 「build」 とコメントすると、.github/workflows/build.yml のワークフローを実行するサンプルです。 name: comment hook on: issue_comment: types: [created] jobs: distribute: runs-on: ubuntu-latest steps: - name: dispatch workflow run: | # イベントに関する詳細情報を取ってくる PAYLOAD=$(cat "$GITHUB_EVENT_PATH") NUMBER=$(echo "$PAYLOAD" | jq -c '.issue.number') # Issue と Pull Request のコメントが混ざってくるので、Issueは無視する if [[ "$(echo "$PAYLOAD" | jq -c '.

Amazon Linux 2 への移行が進む AWS Lambda ですが、 ついに Custom Runtime にも Amazon Linux 2 がやってきました。 AWS Lambda now supports custom runtimes on Amazon Linux 2 同時に provided.al2 の Docker Image も公開されたので、 それを利用して Amazon Linux 2 対応の Perl Runtime Layer を作成しました。 AWS::Lambda ビルド済み公開 Perl Runtime Layer リージョン毎のArn一覧はこちら Perl 5.32 arn:aws:lambda:af-south-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:ap-east-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:ap-northeast-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:ap-northeast-2:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:ap-south-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:ap-southeast-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:ap-southeast-2:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:ca-central-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:eu-central-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:eu-south-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:eu-west-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:eu-west-2:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:eu-west-3:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:me-south-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:sa-east-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:us-east-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:us-east-2:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:us-west-1:445285296882:layer:perl-5-32-runtime-al2:1 arn:aws:lambda:us-west-2:445285296882:layer:perl-5-32-runtime-al2:1 --runtime provided.al2 と合わせてご利用ください。

僕が管理しているサービスでは、ALB が発行する Trace ID を調査時の手がかりとして使えるようログに出力しています。 これのおかげで、Nginx, アプリケーション, その他AWSのマネージドサービス, etc. といった異なるコンポーネントであっても、関連するログを抽出ができ、 障害発生時の役に立っています。 しかし、肝心の抽出作業がマネージドコンソールぽちぽちなため、完全に職人芸になっているというのが現状でした。 解決のための良いツールがないかな、と目をつけたのが CloudWatch ServiceLens です。 CloudWatch メトリックとログ、AWS X-Ray からのトレースを結び付けて、直感なインターフェースで分析できるというもの。 Amazon CloudWatch ServiceLens の発表 AWS X-Ray のトレース結果を送るのは、以前開発した Yet Another AWS X-Ray SDK for Go でできます。 CloudWatch Logs への出力方法は色々ありますが、僕は自作の cloudwatch-logs-agent-lite を使っています。 材料はそろった、さあ、ServiceLens で分析だ！と行きたいところですが、 ただ単にこれらの情報を送りつけるだけでは、得られる情報は X-Ray 単体、CloudWatch Logs 単体で使ったときと大差ありません。 X-Ray のトレース結果とログの関連付けが行われていないので、結局 Trace ID を使って CloudWatch Logs を検索する必要が出てきてしまいます。 ドキュメントを見る限り、2020-07-06現在 AWS X-Ray SDK for Java だけがログ関連付け機能に対応しているようです。 JavaにできてGoにできないわけがないだろう・・・ということで移植してきました。 使い方 aws-xray-yasdk-go の v1.1.1 移行で対応しているので、そのバージョンを落としてきます。 go get github.

@furusax が書いてくれた GitHub Action からの Slack 通知機能について以下のようにコメントしたところ、 対策案を考えてくれました。 そういえばこれって Pull Request Title Injection できないですかね？ まあ、タイトル書くの社員なのでいいんですが。 対策してみました #はてなブログ Pull Request Title Injection とその対策 - なまえは まだ ないhttps://t.co/hIkMykFUr8 — ふるさっくす (@furusax) March 31, 2020 Pull Request Title Injection とその対策 なるほど、こう来ましたか。しかし、まだまだ甘いですね・・・。 2021-08-19 追記 ドッグさん が便利なツールを作ってくれました。 rhysd/actionlint actionlint v1.4 → v1.6 で実装した新機能の紹介 GitHub Actions のワークフローファイルの静的チェッカーです。 チェック項目にこの記事で紹介したような脆弱性検知も含まれているのでおすすめです！ Pull Request Title Injection について まずはこの記事に出てくる「Pull Request Title Injection」についておさらいです。 以下のような Slack への通知を行う GitHub Actions があります。 github.event.pull_request.title はプルリクエストを送った本人が自由に設定できるので、 ここにうまいこと細工をすれば Slack への投稿内容を自由に改変できてしまうのでは？という問いかけでした。

AWS X-Ray Go SDK の地雷処理をしている話 で投げたSQLのプルリクエスト も無事マージしてもらい、 その後もちょくちょくプルリクエストを投げて地雷処理をしていたんですが、我慢できずにやってしまいました・・・。 Yet Another AWS X-Ray SDK for Go そもそも AWS X-Ray ってなんだ、という方は以下のリンクから @fujiwara さんの記事へ飛べるのでどうぞ。 AWS Lambda Perl Runtime で AWS X-Ray を使えるようになりました 使い方 だいたいオフィシャルSDKと一緒です。 ただし、パッケージ分割をしたので、呼び出す関数名等はちょっと変わってます。 他にも微妙に挙動が違う箇所があります。 環境変数の設定 AWS_XRAY_DAEMON_ADDRESS, AWS_XRAY_CONTEXT_MISSING 等の環境変数の設定項目は本家と合わせました。 ただし、以下の点が本家とは異なります。 コード内の設定が優先されます。 環境変数はコード内で明示的に設定が行われなかった場合のフォールバックです。 AWS_XRAY_CONTEXT_MISSING のデフォルト値は LOG_ERROR です。 セグメントの作り方 オフィシャルSDKは seg.Close(err) のようにセグメントを閉じるときにエラーを渡します。 Go には defer という便利な機能があるので、セグメントを閉じるときもこれを使いたいところです。 だたエラーを正しく受け取るには、以下のように戻り値に名前をつけて、defer 部分を無名関数の呼び出しにする必要があります。 // オフィシャルSDKの場合 import "github.com/aws/aws-xray-sdk-go/xray" func DoSomethingWithSubsegment(ctx context.Context) (err error) { ctx, seg := xray.BeginSubsegment(ctx, "service-name") defer func() { seg.