Runner in the High

技術のことをかくこころみ

vim-lspでelm-language-serverを使うとリファクタリング系のCodeActionが動かない件を修正するPRを投げた

github.com

仕事柄vim-lspでelm-language-serverを用いてElmを書くことが多いのだが、なぜかVimだとリファクタリング系のCodeActionが動かないことが多かった。中でも関数のexpose/unexposeが動かないのはまあまあストレスだったので、この機会に腰を据えて調べてみた。

調べた結果をざっくり説明すると、どうやらvim-lspでは codeAction/resolve というcodeActionの遅延実行的なIFが未実装らしい。一方でelm-language-serverはリファクタリング関連のcodeActionをすべて codeAction/resolve で実装しているようだった。従ってLSPクライアントでも codeAction/resolve を実装しているものでしかelm-language-serverは動かないようにできていた。VSCodeは問題なく動いていたので、おそらくIFを正しく実装しているのだろう。

というわけで、取りうる手段はvim-lspに codeAction/resolve のIFを実装する」「elm-language-serverで codeAction/resolve が動かないケースをハンドリングする」のふたつだったのだが、前者はVimScriptを読み書きしないといけなく気乗りしなかったので後者を選択することにした... そんなこんなで、時間はかかったがめでたくマージされましたとさ。

abema/go-mp4でASCの値を取得する

以下の記事ではASC(Audio Specific Config)をffprobeで取り出したが、これはmp4デマルチプレクサでも取り出すことができる。

izumisy.work

今回はabema/go-mp4を使ってやってみる。

mp4の仕様によればesdsというboxの中に入っているらしいので、それを取り出せばいい。

// esdsからASCの値を含むデスクリプタを取り出す
func getASCDescriptor(reader io.ReadSeeker) (*mp4.Descriptor, error) {
    var ascDescriptor *mp4.Descriptor

    if results, err := mp4.ExtractBoxWithPayload(reader, nil, mp4.BoxPath{
        mp4.BoxTypeMoov(),
        mp4.BoxTypeTrak(),
        mp4.BoxTypeMdia(),
        mp4.BoxTypeMinf(),
        mp4.BoxTypeStbl(),
        mp4.BoxTypeStsd(),
        mp4.BoxTypeMp4a(),
        mp4.BoxTypeEsds(),
    }); err != nil {
        return nil, err
    } else {
        esds := results[0].Payload.(*mp4.Esds)
        for _, descriptor := range esds.Descriptors {
            if descriptor.Tag == mp4.DecSpecificInfoTag {
                ascDescriptor = &descriptor
                break
            }
        }

        if ascDescriptor == nil {
            return nil, errors.New("no descriptor found")
        }
    }

    return ascDescriptor, nil
}

単なるm4aファイルに対して動かして確認してみた限り esds.Descriptors には4つ程度のデスクリプタが含まれていた。その中で mp4.DecSepcificInfoTag という値に該当するやつがASCを持っているっぽい。なのでそれを探してやればいい。

あとはこんな感じでgo-fdkaacの初期化のときのパラメタとして使える。

descriptor, err := getASCDescriptor(m4aFile)
if err != nil {
    panic(err)
} else if len(descriptor.Data) == 0 {
    panic(errors.New("no ASC available"))
}

decoder := fdkaac.NewAacDecoder()
if err := decoder.InitRaw([]byte{
    descriptor.Data[0],
    descriptor.Data[1],
}); err != nil {
    panic(err)
}

Jelly Pro 2でBluetoothの接続が安定しない

1年ほどUnihertzのJelly Pro 2を使っているのだがFitbit (Charge 4)との相性が悪いのかBluetoothの接続が全く安定せず、諦めてFitbitをただの時計として使ってきた。

さすがにちょっと嫌だなと思い改めていろいろ調べた結果、以下のRedditの投稿で少なくとも通知は来るようになりある程度Bluetoothとの接続がうまくいくようになった。

www.reddit.com

ざっくりBluetooth MIDI Service というシステムのアプリケーションがバックグラウンドで動くようにしただけだが、これまで毎回失敗してたFitbitアプリでの同期やアプリからの通知が動くようになった。

Github Action上でEarthlyからGithub Container Registryへimageをpushする

自分で管理しているDockerイメージのリポジトリでリリースフローを自動化してみたので備忘メモ。

github.com

実際のAction実装は以下のような感じ。

Earthlyもキャッシュをいい感じにしてくれるので2回目以降はかなり速い。

name: release

on:
  push:
    branches: 
      - master
      - main

jobs:
  release:
    runs-on: ubuntu-latest
    permissions:
      packages: write
      contents: read
    steps:
      - uses: actions/checkout@v3

      - name: Login to GHCR
        uses: docker/login-action@v1
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Setup earthly
        run: |
          wget https://github.com/earthly/earthly/releases/download/v0.6.1/earthly-linux-amd64 -O /tmp/earthly
          chmod +x /tmp/earthly
          /tmp/earthly bootstrap
          /tmp/earthly --version
      - name: Build and push
        run: /tmp/earthly --push --ci +image

ポイントは permissions のところで、そこが設定されていないとpackageを公開する権限がなく403エラーになってしまう。

ちなみに、Github上ではPackageに対してリポジトリと1:Nの関係で権限を設定できる。うっかり自分はそれを設定してしまったのだが、その場合にはActionの設定画面でPackageに対する権限を明示的に Role: Write にする必要があるっぽい。デフォルト設定はReadのみなので、ここでWriteが設定がされていないとyamlファイルの中で permissions を指定していても403エラーが出るので注意。

Packageに対するリポジトリの紐づけを行う画面

Earthlyからは unexpected status: 403 Forbidden というエラーしか出してくれないのでなにが原因なのかわからずらい...

とりあえずopenresty/openrestyを使ったイメージを作る

超最小構成でこんな感じ

FROM openresty/openresty:1.19.9.1-alpine

WORKDIR /app

COPY nginx.conf nginx.conf

EXPOSE 8080

CMD ["nginx", "-c", "/app/nginx.conf"]
daemon off;

http {
  server {
    listen 8080;
    
    location /hello {
      default_type text/plain;
      content_by_lua_block {
        ngx.say("hello")
      }
    }
  }
}

参考になりそう→ 逆引きlua-nginx-module · GitHub

Github Actionでdockerイメージをビルドし任意のコマンドを実行する

docker/docker-push-actionaddnab/docker-run-action というやつを組み合わせると最小構成でいい感じにできる。

name: Test
on: push

jobs:
  test:
    name: test
    runs-on: Ubuntu-20.04
    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - uses: docker/build-push-action@v2
        with:
          file: Dockerfile.test
          tags: yourtestapp
          push: false # pushするならここtrueでもいい

      - uses: addnab/docker-run-action@v3
        with:
          image: yourtestapp
          options: -v ${{ github.workspace }}:/src
          run: make test

ビルドするDockerfile.testはこういう感じ

FROM golang:1.16.14-bullseye

ENV APP_ROOT /src
WORKDIR $APP_ROOT

# download app deps
COPY go.mod $APP_ROOT
COPY go.sum $APP_ROOT
RUN go mod download

# use bash for entrypoint to run commands passed on running this Docker image
ENTRYPOINT ["/bin/bash", "-c"]

ローカルでもdocker上でテスト実行できるようにソースコードまるごとはCOPYしない。

あとは、最後のENTRYPOINTに /bin/bash -c を与えているのがポイント。こうしないと docker run に渡した任意のコマンドをコンテナ内で実行できない。

OpenTelemetryでもGin+GAEのログをリクエスト単位でグルーピングする

前回のOpenCensusでは比較的すんなりとGAEのログをリクエスト単位でグルーピングさせることができたが、OpenTelemetryの場合には追加でGoogleCloudPlatformのGithub Orgが用意しているpropagatorを使わねばならない。 github.com

以下がとりあえず動く超最小構成のミドルウェア

package middleware

import (
    cloudpropagator "github.com/GoogleCloudPlatform/opentelemetry-operations-go/propagator"
    "github.com/gin-gonic/gin"
    "go.opentelemetry.io/otel/propagation"
    "go.opentelemetry.io/otel/trace"
)

func Tracer() gin.HandlerFunc {
    return func(c *gin.Context) {
        ctx := c.Request.Context()

        // まずはX-Cloud-Trace-Contextからの読み取りをトライ
        // ここでエラーを拾っても何もできないので意図的にエラーは無視する
        if sc, _ := cloudpropagator.New().SpanContextFromRequest(c.Request); sc.IsValid() {
            ctx = trace.ContextWithRemoteSpanContext(ctx, sc)
        } else {
             // X-Cloud-Trace-ContextからValidな値が取れない場合には
             // traceparentヘッダからのTraceID/SpanIDのパースを試してみる
             prop := propagation.TraceContext{}
             ctx = prop.Extract(ctx, propagation.HeaderCarrier(c.Request.Header))
        }

        // 必要に応じてNewTracerProviderの中でsamplerやexporterを指定する
        traceProvider := sdktrace.NewTracerProvider()
        defer traceProvider.Shutdown(c)

        tracer := traceProvider.Tracer("yourapp/trace") // Empty: use default tracer name
        spanCtx, span := tracer.Start(ctx, c.FullPath())
        defer span.End()

        c.Request = c.Request.WithContext(spanCtx)
        c.Next()
    }
}

あとは前回の記事を参考にしてContextからSpanIDとTraceIDを取り出してロガーで送ってやればいい。まじめにやるならサンプラーやエクスポータなどもちゃんと設定してやったほうがいい*1が、そのあたりはこの記事では触れない。

OpenCensusのときはパッケージの中にStackdriver用のエクスポータが用意されていて、その中で X-Cloud-Trace-Context ヘッダから値を取り出すパーサが実装されていた。しかしOpenTelemetryからはどうやらエクスポータはインターフェイスのみを提供し、プラットフォーム固有のエクスポータは自分たちで用意してくれという方針になったように見える。Googleが使っている X-Cloud-Trace-Context 相当のヘッダはW3Ctraceparent としてベンダ非依存のオープンな仕様へと標準化されたらしく、むしろGoogle側がOpenTelemetryの仕様に従うという構図になっているっぽい。

もしかするとOpenCensus時代はまだ分散トレーシングが黎明期(?)だったこともあって、むしろ先立って分散トレーシングを製品化したり大規模に使ったりしていたGoogle側の仕様をOpenCensus側が取り入れたのかもしれない。

ヘッダの仕様に関しては以下のドキュメントが参考になった。 cloud.google.com

*1:たとえばこのサンプルではCloud Traceが動かない。トレーシングをするにしてもサンプリングの頻度指定もされていない。

GinのOpenCensusミドルウェアを作ってCloud Loggngのログがリクエスト単位にグルーピングされるようにする

OpenCensusはdeprecatedされているので本当はOpenTelemetryを使った方がいいのだけれど、やったのでメモがてらに残しておく。アプリケーションの実行環境はGAEでやった。

追記: OpenTelemetryでやる方法も書きました izumisy.work

まずはログのグルーピング(Span)をリクエスト毎に開始するためのミドルウェアを作る。

package middleware

import (
    "github.com/gin-gonic/gin"
    "go.opencensus.io/exporter/stackdriver/propagation"
    "go.opencensus.io/trace"
)

//
// ルーティングの実装ではUseを使って以下のミドルウェアを登録しておく
// router.Use(Tracer())
//

func Tracer() gin.HandlerFunc {
    return func(c *gin.Context) {
        ctxWithSpan, span := trace.StartSpan(c, "yourapp/trace")
        defer span.End()

        httpFormat := propagation.HTTPFormat{}
        if sc, ok := httpFormat.SpanContextFromRequest(c.Request); ok {
            ctxWithSpan, span = trace.StartSpanWithRemoteParent(c, c.FullPath(), sc)
        }

        c.Request = c.Request.WithContext(ctxWithSpan)
        c.Next()
    }
}

TracerミドルウェアによってContextにグルーピングのために必要な情報がセットされるので、それを取得する関数も用意しておく。

gin.Context の場合にはRequestからContextを取り出すようにしているのがポイント。

package log

import (
    "context"

    "github.com/gin-gonic/gin"
    "go.opencensus.io/trace"
)

type Tracer struct {
    SpanID  string
    TraceID string
}

func ExtractTracer(ctx context.Context) Tracer {
    sc := trace.SpanContext{}

    if ginCtx, ok := ctx.(*gin.Context); ok {
        sc = trace.FromContext(ginCtx.Request.Context()).SpanContext()
    } else {
        sc = trace.FromContext(ctx).SpanContext()
    }

    return Tracer{
        SpanID:  sc.SpanID.String(),
        TraceID: sc.TraceID.String(),
    }
}

あとはCloud Loggingにデータを送信するタイミングで、上で作ったExtractTracerを用いてContextからSpanIDとTraceIDを取り出し、それぞれ適切な形でセットしてやればok

package log

import (
    "fmt"
    "os"
    "log"

    "cloud.google.com/go/logging"
)

func Log(ctx context.Context, severity logging.Severity, timestamp time.Time, text string) {
    projectID := os.Getenv("GOOGLE_CLOUD_PROJECT")
    client, err := logging.NewClient(ctx, projectID)
    if err != nil {
        log.Fatalf("Failed to create client: %v", err)
    }

    tracer := ExtractTracer(ctx)
    logger = client.Logger("ServeHTTP")
    logger.Log(logging.Entry{
        Timestamp: timestamp,
        Severity:  severity,
        Payload:   text,
        SpanID:    tracer.SpanID,
        Trace:     fmt.Sprintf("projects/%s/traces/%s", projectID, tracer.TraceID),
    })
}

DeNAが出しているaelogというパッケージを使えばこの辺全部よしなにやってくれるっぽい。

Ginでなにもせず使えるかは試してない。ミドルウェアの型定義的に gin.WrapH とかでラップしてUseしてあげれば使えるような気もするけど、どうなんだろう github.com

追記: 調べたらこんなのもあった。 github.com Cloud Loggingとのつなぎこみだけ自分で作ってこういうのを使うでもいいかも。