postgresql の json データ型

1時に寝て6時半に起きた。連休中に夜更ししてたから生活が乱れた。

ロガー向けのログ保存 API の開発

先週の休暇前にやっていた作業の開発に着手。一通り web api のエンドポイントの実装は終えてテストをあらかた書いたところ。いまのプロジェクトとしても、過去の私の経験としてもやったことのない新しい挑戦の1つとして postgresql の JSONデータ型 を使う。具体的には json 型と jsonb 型の2つがある。前者はテキストで保持する型で、後者は内部的にバイナリに変換されてインデックスも使える。バイナリに変換してインデックスを作る分、insert 時にテキストで保存するよりは少し余分なオーバーヘッドを要する。json のデータを参照用途で使うのか、検索するのかでこれらの型を使い分ければいいのかな。

実際の sql で json データの条件指定は次のようになる。@> というみたこともない気持ち悪い演算子を使う。

> select * from mytable where data  @> '{"x": 1, "y": 2}';

java の jdbc で扱うには PGobject という型に変換して扱う必要がある。

private PGobject convertData(String value) throws SQLException {
    var data = new PGobject();
    data.setType("jsonb");
    data.setValue(value);
    return data;
}

余談だけど、curl で json 文字列を query string としてリクエストするには url encode しないといけない。

$ curl -s --get --data-urlencode 'data={"x": 1, "y": 2}' http://localhost/path | jq .

quarkus のアプリ開発が楽しくなってきた

4時に寝て8時に起きた。昨日は久しぶりに夜更しして quarkus の調べものをしてた。新しいものを学ぶのはおもしろい。

ストレッチ

今週末は本当は実家に帰る予定だったのが、台風による雨で田んぼのコンディションがよくないので断念した。日曜日の夜、田んぼ仕事を終えて筋肉痛のところにストレッチしてもらう予定は変わってしまった。今日の開脚幅は開始前155cmで、ストレッチ後160cmだった。いつもは朝測っているのが夜になるので数値はよくなかった。とはいえ、あまり規則正しく寝てないわりには体調がよい。気候が涼しいせいかな。トレーナーさんに来週はもう10月ですよと言われて9月は過ぎさるのが早いと改めて思った。

quarkus アプリケーションと認可フロー

昨日の続き。お昼前ぐらいからずっと quarkus のアプリケーション開発をしていた。なんやらかんやらで3日間ずっと bolt や quarkus のソースやドキュメントを読んでいた。徐々に理解度が増えてきて、できることも増えてきて楽しくなってきた。web 系だと di に google/guice を使うものも多いけど、エンタープライズ系だと cdi なのかなぁとか思ってた。わからんけど。以前にも cdi のドキュメントを読んで関心があった。cdi は本当によく出来ていると思う。一方で難し過ぎて、そこまでコンテキストを厳密に管理する必要があるアプリケーションもそうないのかもなぁとは思ってた。今日 quarkus でアプリケーション開発していてドキュメントを読みながらやってみたところが次になる。

だいたい雰囲気は理解できてきたので backlog の Authentication & Authorization に書いてある oauth2 の Authorization Code Grant のフローを実装していた。access token の取得と refresh はできたのでこれを db に保存するのを明日以降にやってみる。

quarkus のビルド環境に手間取った

1時に寝て7時に起きた。休みだとやっぱりだらだらしてしまうな。

bolt for java on quarkus

昨日の続き。スクラッチから quarkus のアプリケーションの設定を gradle で行う。quarkus の上で slack apps としてのコマンドとイベントの振る舞いだけ確認した。

私は新規に開発する java アプリケーションは gradle を使うようにしている。これは java のよくないところだろうけれど、言語コミュニティが提供するパッケージマネージャやビルドツールがないから複数のツールが乱立している。maven から gradle に緩やかに移行していくのかな?と私は考えていたけれど、昔からあるライブラリのビルドツールを変更するのは労力に見合うメリットがないのか、maven も依然としてずっと使われ続けていくのかもしれない。maven と gradle の両対応という保守コストは、この先しばらく java コミュニティが抱えていく保守コストと言えるのかもしれない。quarkus はさらに独自の Quarkus CLI というビルドツールを提供している。そのため、ビルドのための設定だけで quarkus cli, maven, gradle の3つの方法があり、ドキュメントにもそれぞれの設定方法が書いてある。これを保守する方も使う方もややこしくて大変だなぁという印象を受けた。

BUILDING QUARKUS APPS WITH GRADLE をみながら次の maven cli で作った gradle プロジェクトのテンプレートをみながら build.gradle の設定をした。

$ mvn io.quarkus.platform:quarkus-maven-plugin:2.12.3.Final:create \
    -DprojectGroupId=my-groupId \
    -DprojectArtifactId=my-artifactId \
    -Dextensions="resteasy-reactive,resteasy-reactive-jackson" \
    -DbuildTool=gradle

あと私は設定ファイルを yaml で管理したいので次の拡張も追加した。gradle タスクでも定義されていて次のように実行する。

./gradlew addExtension --extensions="quarkus-config-yaml"

この cli がやっていることは基本的に dependencies に次の1行を追加するだけ。

dependencies {
  implementation 'io.quarkus:quarkus-config-yaml'
  ...
}

設定ファイルを yaml から読み込めるようになると初期設定は次のようになる。

$ vi app/src/main/resources/application.yaml 
quarkus:
  http:
    port: 3000
  log:
    level: INFO
    category:
      "com.slack.api":
        level: DEBUG
      "tutorial.bolt.sample":
        level: DEBUG
  package:
    type: uber-jar

開発サーバーは次のようにして起動する。

$ ./gradlew quarkusDev

quarkusDev enables hot deployment with background compilation, which means that when you modify your Java files or your resource files and refresh your browser these changes will automatically take effect. This works too for resource files like the configuration property file. The act of refreshing the browser triggers a scan of the workspace, and if any changes are detected the Java files are compiled, and the application is redeployed, then your request is serviced by the redeployed application. If there are any issues with compilation or deployment an error page will let you know.

https://quarkus.io/guides/gradle-tooling#dev-mode

hot deployment 機能のおかげでソースや設定ファイルを変更すると自動的に反映される。他の言語なら普通の機能かもしれないけど、java でもそういう仕組みが普通になったんだなと思って感心した。変化に付いていけない開発者のような気持ちになった。

slack apps 開発に着手

0時に寝て6時に起きた。あまりうまく眠れなかった。

bolt for java

slack apps を開発するためのフレームワークとして bolt と呼ばれる高レベルのフレームワークが提供されている。このフレームワークは slack sdk を使って作られていて、slack apps の開発が簡単になるようにユーティリティが提供されている。The Bolt family of SDKs によると、javascript, python, java 向けに提供されている。以前 bizpy でも slack アプリ開発のチュートリアルの勉強会をしたことがある。そのときは bolot for python を使っていた。

一度触ったことがあったので bolt がどういうものかはすでに知っている。その java 版を使って slack apps を作ってみようと取り組み始めた。まずはチュートリアルを一通りやってみようと次のリポジトリでやってみた。

チュートリアルの内容を動かすだけならすぐできた。次に java の waf は何を使おうかを調べてた。Supported Web Frameworks によると、次の4つがある。

  • spring boot
  • micronaut
  • quarkus undertow
  • helidon se

さらに slackapi/java-slack-sdk#modules をみると、次の2つも追加されている。どちらも kotlin 向けのフレームワークらしい。

  • http4k
  • ktor

それぞれのフレームワークの説明を読んだり、この機に kotlin をやってみることも検討してみた。長期間の保守を前提にすると、一時的に触るだけの言語を使うのもどうかな?と思うところはあってやはり java でやることにした。spring boot はお仕事でよく使っていてどういうものかを理解しているので選択するなら他の3つのどれか。

Quarkus was created to enable Java developers to create applications for a modern, cloud-native world. Quarkus is a Kubernetes-native Java framework tailored for GraalVM and HotSpot, crafted from best-of-breed Java libraries and standards. The goal is to make Java the leading platform in Kubernetes and serverless environments while offering developers a framework to address a wider range of distributed application architectures.

https://quarkus.io/about/

いま kubernetes に好印象をもっていることもあり、この説明を読んで quarkus を選択することに決めた。そんなことをつぶやいていたら、せらさんからいくつかアドバイスをいただけた。slack について何かをつぶやくと100%返信がくる (ソースは私の経験) 。感謝。

java アプリケーションを実行可能なバイナリにコンパイルする機能を graalvm が提供している。graalvm ではこのバイナリのことを native image と呼んでいる。quarkus は java の web アプリケーションフレームワークであり、graalvm を使って native image を作ることも考慮して設計されている。コンテナでデプロイすることを想定したフレームワークと言える。残念ながら slack sdk が使っているライブラリである gson はリフレクションを多用していて、それが graalvm とは相性が悪いだろうという話しで現時点では native image 化は難しいみたい。たしか native image でリフレクションを使うには使っている箇所を設定にすべて列挙しないといけなかった気がする。リフレクションのような動的に用いるものと静的な設定は相性が悪く、がんばれば特定のバージョンで動くものは設定できるかもしれないけど、ライブラリのようなものでバージョンアップに追随するのはしんどいという話しなのかなと思う。

勉強会が2つ

0時に寝て6時に起きた。涼しくて体調は抜群。

インフラ引き継ぎ勉強会

先週引き継ぎのためのインフラドキュメントを書いていたものをチームの開発者に共有した。今日は開発者向けの話しなので 5日以上かけた非開発者向けのインフラドキュメント は使わないが、社員さんによると、(私が参加していない社員さんだけの) 別の開発者チャンネルで読まれているとのこと。時間をかけたので多くの人に読んでもらえるに越したことはない。但し、そのフィードバックは私には一切ないので役に立っているのかどうかの判断しようがない。業務委託にそういう外様感を与えるかどうかは組織によって大きく異なる。過去に働いたある会社では自由に勉強会に参加したり他チームのメンバーとも技術の議論をできたりした。私は技術の話題に対しては真摯なので当たり前のように感じていたが、あの会社のあの文化は特別だったのだとそれから別の数社で働いてみて気付いた。

書いたインフラドキュメントに沿って一通り説明して、ほとんど実務をやっていないメンバーではあまりイメージができないと思うので質問もそれほどなかった。次回は実際にどうやってインフラのデプロイをするかの作業をみんなで確認しながら cdk の使い方などの話しをしようと思う。

インフレ勉強会

fin-py の月例のインフレ勉強会に参加した。背景はわかってないが、connpass イベントではない。市場調査や金融の勉強のために最近は毎月出席している。

直前に政府の円買いの為替介入あったのが話題になってた。政府が本気?出せばこんな勢いで5円も動くらしい。為替介入はサプライズが大事らしくて、サプライズという側面ではみんなびっくりしたので効果はあったのかもしれない。

fin-py の中の人もこんな勢いで動くのは珍しいと話していた。日本が為替介入するときは米国にお伺いを立てないといけないらしく、米国がうんと言わないと実弾の為替介入はできないことが多いらしい。中の人によれば、いまも米国は日本の為替介入をよくは思ってないだろうと推測されるので、こんなことをずっと続けられるかどうかは懐疑的だという。さらに世の中のトレンドはドル高なので為替介入しても一時的なもので意味がないという考え方もあるとのこと。今回の介入の意味があったかどうかは今後の為替が安定するかどうかで判断される。日本は世界でトップクラスに外貨準備のドルをもっている国なのも事実なので為替介入の実弾もたくさんあるから今後も介入する可能性はある。

最近の java の勉強

0時に寝て7時に起きた。

運用対応

ある施設のサービスインのシステム切り替えでほぼ1日を終えた。昨日のロガーの要件を詰めようと思っていたけど、なんの話しもできないまま1日が過ぎた。トラブルの運用対応に開発リーダーが忙しくて、他の外部開発者は遊休中。自分の時間を無駄遣いしているようで辛い。あと1ヶ月の辛抱。

java 勉強会

たまたま Java 19が正式リリース。より軽量な仮想スレッド、RISC-Vへの移植など新機能。1年後のJava 21が次のLTS版に をみかけた。今後は java の lts リリースが3年から2年に変わるらしい。他の言語では軽量プロセスと呼ばれる仕組みを java では Virtual Threads (仮想スレッド:JEP 425) と呼ぶらしい。まだプレビュー版だけど、次の lts には使えるようになっていると思う。サーバー用途で言えば仮想スレッドを使ったサーバーが主流になれば java の運用時のメモリ使用量がいくらか減ることになって嬉しい状況はあるのかもしれない。

その記事と同時にタイムラインで Java仕様勉強会「Java SEの動向 2022夏」 をみかけたので気付いたタイミングで参加した。現在の java の機能拡張をしている様々なプロジェクトの紹介がされていた。半分は知ってたけど、半分ぐらいは知らないものもあって勉強にはなった。プロジェクトが多過ぎてだんだん聞いていて飽きてくるのもあったので勉強会のやり方を見直してもいいかもしれないとも思った。

その後にきしださんが java 19 の紹介をされていたのでそのまま視聴した。switch 式やパターンマッチングとの親和性あたりは私も期待していた内容の通りに拡張されているようにみえてよさそうの思う。次の lts はまだ先だけど、そのときに java を書くのが楽しみになるぐらいの機能拡張だとは思う。仮想スレッドの説明もデモしていた。他の言語で軽量プロセスを扱っている人にとっては意図した内容なので目新しくはないが、java でフレームワークを作っている開発者にとってはパフォーマンスを向上できる可能性があるので関心の高い機能だとも思う。

台風の過ぎた連休明け

0時に寝て7時に起きた。朝には台風は過ぎ去っていた。

ロガーとデータベースとの境界

ちょっと前にバッチ処理の履歴をデータベースに保持して履歴情報を使って運用対応がやりやすいような機能を一通り構築した。その延長上でロガーが任意のログをデータベースに保存できるようになれば、開発者からみてロガーを使ってログ出力するだけでデータベース保存もできてよいのではないかと考え始めた。既存の処理を見直しながらその移行ができそうかどうかを考えていたら、既存の処理をすべて捨ててもう一度スクラッチから作り直した方がよい気がしてきた。また明日そのアイディアの是非を確認してみようと思う。

ブロックチェーンのお仕事の面談

ある会社から lapras さん経由でスカウトをもらってカジュアル面談をした。ブロックチェーン界隈の事業のミドルウェアに位置するサービスのようで、ブロックチェーンからみたらアプリケーションだけど、web3 や nft のようなアプリケーション側からみたらインフラ側といった業務内容だった。ブロックチェーンや web3 関連は昨年ぐらいから情報収集していて関心のある業界ではある。私自身バックエンドのスキルやキャリアを高めたいという考えもあり、流行りと詐欺のみわけがつかない上モノのアプリケーションよりも基盤の方が向く。話しを聞いていて真っ当なビジネスであることは確認できた。ブロックチェーンの予備知識はまったくないが、先方も基本的な技術は web2 でも使われているものを使って構築されており、一般的なコンピューターサイエンス、データ処理やアルゴリズムの知識があればよいとのこと。話しを聞いていてそれはよく理解できた。先方は基本的に正社員で採用を考えていて、私は業務委託でしかお手伝いできない。いまのところ、自社プロダクトの開発に着手するまであと1-2年しか時間がない。この職場に私が参加しても1-2年後には辞めないといけないとしたら申し訳ないというところだけが懸念に思えた。カジュアル面談だったので選考の候補の1つとして一旦は保留しておく。

台風待ち

0時に寝て7時に起きた。台風がやってきそうでなかなか来ない。2日前から警戒して備えているのに今朝時点ではまったく平気。朝起きて雨だったら休もうと思っていたものの、雨がやんでたからオフィスきて一仕事してきた。

ドキュメントを書き終えた

5日以上に及んだ 非開発者向けのインフラドキュメント を書き終えた。他にもいくつかインフラのドキュメントの加筆や推敲もしていた。叩き台としてそれなりに伝えたいことは書けた。あとは勉強会をしながら出てきた話題や質問などを参考にしながら推敲していくだけ。

一日中議論してた

1時に寝て7時に起きた。

会計監査と数字の着眼点

note で300円で販売している記事をみかけた。監査法人に勤めていた公認会計士が勝手にレビューしてみた的な記事になる。

タイムラインでみかけたことをきっかけに私も過去3年分の会計報告を眺めたり、社内コミュニティで時事問題として取り上げていたので関心があった。経営者として他社の財務諸表をみる機会は私もあるので、会計士さんがどういった数字の見方をするのかの視点はとても勉強になった。現時点で不正をしているという話ではなく、会計報告からみえる数字だけを追いかけても経費の数字のいくつかに不可思議なところがあるという会計士からの指摘だった。ヒアリングすれば解決するかもしれないしそうじゃないかもしれない。一方で国や都からの少なくない金額の助成金 (税金) を受け取っているので会計報告に不明瞭なところがあるのであれば、精査して説明責任を果たす必要はあるだろうというのは一般的な共通認識ではないかと思う。

スクラム雑談

【三宮.dev オンライン】語り合おう!スクラム開発雑談会! に参加した。常連のメンバー3人で話し始め、途中から主催者の先輩が加わって、sier のマネジメントのしんどい話しみたいものになって、最後はフロント/バックエンドの技術談義とかハックバーどうよみたいな話しになって、まさに雑談イベントみたいなものになった。ニフティのスクラム という本があるよと教えてもらって無料なので読んでみた所感をつぶやいたりもしてみた。あるイベントでも スクラム雑談 をしていて気付いたことの1つに、スクラムうまくいかない話しの大半は、スクラムというガイドライン上に洗い出された組織の課題を議論するようになるのではないかと思う。組織の課題の洗い出しにスクラムは使えるが、スクラムをやれば組織の課題を改善できるわけではないとわかってきた。

ドキュメントを書いてマンガを読んで

0時に寝て7時に起きた。

ストレッチ

今日の開脚幅は開始前160cmで、ストレッチ後163cmだった。今週も調子がよい。やはり涼しくなって日々の生活の快適度があがって体調もよくなっている気がする。ストレッチを受けていてもあちこち調子よくていい感じにストレッチできているように思う。これで少しジョギングや運動をするといいんだろなという気持ちになってくる。これまでも暑い夏はあったと思うが、今年ほど夏の暑さにまいって集中力を欠いた年はなかったと思う。というのは、日記を1年近くも毎日書いたことがなかったからその変化に気付けたことも過去になかった。日記を書く過程で環境や状況の変化に敏感に気付けるようになったという背景もある。他の要因としては歳をとって体力が落ちているのだろうと推測する。落ちた体力をカバーするだけの取り組み (運動するとか摂生するとか) が必要なのだろうけれど、私は昔と比べて生活の姿勢をとくに変えていない。もうそろそろ不摂生がダメなんだろうなという自覚は出てきた。昨年からストレッチを始めたのは本当に僥倖で健康度はいくらか上がっていると思う。

まだドキュメントを書いている

非開発者向けのインフラドキュメント がなかなか完成に至らない。厳密に書くわけでもなく、嘘を書くわけでもなく、重要なことのみを専門用語を使わずに技術知識がない人たち向けに書くドキュメントは相当に難しい。どういう構成にするかも何度も試行錯誤しているし、説明のための文章量も増えてしまうところがある。インフラを知らない開発者向けに引き継ぎのドキュメントを書くよりもずっと大変だと3日も書いているのに書き終わらない (自分で納得がいかない) 事実から認識できた。書いて読まれるのかどうかもわからないけど、それは読み手の自由であって書き手は自分が伝えたいことを自分の言葉で書くことに意味があるだろうと考えて、いまの自分ができる精一杯のドキュメントを書こうと思う。

葬送のフリーレン

夕方から 葬送のフリーレン を7巻ぐらいまで読んだ。これまで1巻を無料キャンペーンで読んだことはあったし、人気があることも知ってはいたけどいつか読もうぐらいの感覚だった。毎日 LINE マンガで 神之塔 を読んでいて、たまたま2巻も無料化されたのを見かけて読んでみたらおもしろかったので、いつかはいまだと認識して電子版を購入して読み進めた。

葬送 という言葉も私は知らなかった。「死者と最後の別れをし、火葬場、墓地に送り出すこと。」を指す言葉らしい。マンガのタイトルから「葬送のフリーレン」という物語だよというのは、内容から妥当だと思うものの、これは物語の世界の中でもフリーレンの異名として魔族が呼んでいる。私はてっきり勇者ヒンメルとの思い出を辿る旅全体を葬送に見立てているのだと思って読み進めていたのに、途中で魔族からそう呼ばれていて、魔族を殺しまくる忌み名的なものだったの?!というところで、それまで読み進めていた自分の中の世界観とバグが生じた。もしかしたら今後の物語の展開によってまた違った意味になってくるのかもしれないけど。

歴史上で最も多くの魔族を葬り去った魔法使いとして「葬送のフリーレン」の異名を持ち、魔族から忌み恐れられている。

ja.wikipedia.org/wiki/葬送のフリーレン

あと思い出を辿るという物語は、ほのぼのしている話しもあれば、魔族との戦いを話しもあり、資格を取るための競技会の話しもある。話しの展開を何とでも創生できる想像力の源になっている。このマンガは旅の終わりが来なくてもよいし、強い敵を倒さなくてもよいし、思い出さえあれば物語を展開できるのでその幅の広さに感心した。内容はまったく違うけれど、蟲師 を読んだときと同じような感銘を受けた。葬送のフリーレンもアニメ化が決定しているらしい。

これから面談が増えていく

23時に寝て5時過ぎに起きた。7時にはオフィスに着いて9時までプロダクトオーナーのためのインフラ入門のドキュメントの続きを書いてた。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。前隔週を1回飛ばしたので話題はたくさんあった。エージェント経由のお仕事探しはまったくうまくいってないという状況を相談していたら、私のような開発者が匿名の職務経歴書で選別されるのは難しいのではないかとのこと。まさにその通りだと私も思う。逆に個人のパブリックなリソース (github, qiita, blog, slide など) からスコア算出するサービスは相手から面談のオファーがくる。長く生きている分だけパブリックなリソースがあってスコアがよくなるという理屈だが、そういったお仕事探しをしないと私の実績や経験では職務経歴書の見栄えが足りないということを学んだ。はらさんからのアドバイスとして、勉強会やイベントに登壇して発表者だけのレセプションパーティーに参加するのがよいと教えてもらった。懇親会とは異なる。懇親会はどちらかという参加している開発者のためのパーティーだが、レセプションパーティーは関係者のためのパーティーなのでスポンサーや著名人と話しやすい。そこでコネができるとカジュアルによいポジションのお仕事の紹介/斡旋が起きるとのこと。

お仕事探し

知人の働く会社で面談してもらった。たまたまやり取りするきっかけがあったので開発者を探していれば声をかけてくださいと言ったらまさにそういう状況だったみたい。経営者の方々とも、私からは面識があって10年以上前に1度だけご挨拶したことがあった。先方が覚えてくれていたかどうかはわからない。「いま何歳?」と聞かれて、あのとき20代だった人間がもう40代か、歳とったなとみんなで笑っていた。そりゃ16年も経っているのだからそうだよねって感じでおもしろかった。業界内ではトップレベルのパッケージベンダーだし、私自身も大先輩の方々だと認識しているし、技術的にも私などがお手伝いできるのだろうか?という懸念はあったものの、先方がやってほしいと考えている業務内容だけをみたらマッチングは問題なさそうに思えた。うちの会社のビジネスにしたい課題管理のノウハウを実践したり体系化したりする現実の職場としてもよさそうに思う。詳細な契約の条件や先方の要件などをこれから摺り合わせていく。うまくいくといいな。