Posts for: #2022/09

半稼働日

#founding  #information exchange 

0時に寝て2時、3時と起きて5時に起きた。最近は夜に寝ているのか起きているのか、自分で分からなくなってきた。7時過ぎにはオフィスに着いてた。

サービス残業

今日は非稼働日なんだけど、半日ぐらいは開発していた。大掛かりなリファクタリングをするので今日中に主な修正をテスト環境にデプロイしておきたかった。スプリントが水曜日始まりの1週間なので運用に影響がありそうな大掛かりな機能追加やリファクタリングは金曜日中にはテスト環境へデプロイするように私はしている。そうすると、月・火で他のメンバーがテスト環境を触るのでリグレッションがあればバグをみつけやすくなる。さらにお小言を書くと、他の開発メンバーはこういう感覚がまったくない。大きな変更を伴うコミットを火曜日に普通にしようとする。「明日リリースですが、これをマージしてしまって検証できますか？」というツッコミを私が過去に何度もしている。大半は無理だと次スプリントへ持ち越しになる。残業しない開発者はタスクがスプリントをまたぐことになるので見た目以上のロスがある。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。いつも9時から雑談しているけれど、今日はお互いに歯医者があって15時に変更した。直近のお仕事探しの近況から情報共有をした。いまのところ、3社の選考が進んでいて、私の中の優先順位も明確になっていて、あとは実際に契約を締結するまでもっていけるか。ほんの2週間前までお仕事探しの書類審査すら通らない状況だった。最悪のケースとして11月からしばらくお休みすることも想定していた。現時点では3社もあればどこかに決まるだろうという楽観的な展望をもっている。

ある案件で react から next.js への移行の目的が seo 対策だという話しをしてたら、google のクローラーは spa アプリケーションも扱えるけれど、twitter, facebook のクローラーが全然ダメらしくて sns で記事をシェアするときにプレビューをきれいにみせたいといったときに課題があったりするらしい。spa の後にまた ssr (server-side rendering) やるというのは本当にあほみたいなことをやっていると私からは思えてしまう。

あと私はもうスクラムの議論には関心がなくなってしまった。昨日の日記にも少し書いた。いまは組織を変えられるかどうかに関心をもっていて、よいプロダクトにはよい開発文化が必要だ。そこで「よい開発文化」とはなにかを体系化しないといけない。そのうちの1つとして書くことをこれまで訴求してきた。その後もずっと考え続けてきて私の中では次の3本柱でいこうと決めた。

  • 書くこと
  • ワークフロー改善
  • 実践知リーダーシップ

いまはまだキーワードだけでその意図する具体的な内容は私の頭の中にしかない。この3つを軸に私のスキルと経験を詰め込んだ製品開発をしていく。

自分で自分を信用しない

#scrum  #event  #thought 

0時に寝て5時に起きた。朝から2時間ほどドラクエタクトしてた。

ふりかえりのフィードバック

先日 5日以上かけて非開発者向けのドキュメント を書き終えた。労力をかけてわかりやすいように書いたせいか、評判がよいという噂があり、ふりかえりのときにも先方の社内で共有されていて、他チームでも読まれているといったコメントをいただいた。それ自体は嬉しいことだ。一方で先方の社内に閉じている議論なのでドキュメントを書いた私には一切フィードバックはない。同じチームのメンバーからもほとんどない。

私はあまり自分自身を信用しない人間で、私が作った成果物はよいものだと考えていない。とくに初期のバージョンはすべてそう。誤り・勘違い・怠惰・抜け・漏れがいくつもあって3世代ぐらいのアップデートをこなさない限り、運用に耐えるものにはならないという考え方をする。書き終えたばかりのドキュメントを褒められても、自分の中ではそれはおかしいと思ってしまう。あんなものがよいはずがない。もっとよくするための取り組みがあるはずで、そのヒントを他者に期待しているところがある。単純に褒められるよりも「どこがわかりやすかった」「どこがわかりにくかった」「ここをもうちょっと詳しく」とか、そういったインタラクティブな議論を他者に求める傾向がある。それは自分自身が欠陥だらけだから。今回はふわっとした手応えで業務を終えることになる。

開発方法論を議論するのに飽きた

エンジニアリングマネージャーのしごと 読んでみたけど、質問ある？（答えられるとは言っていない に参加した。ちゃんとしたイベントじゃなくて、書籍を読んだ感想を discord で気軽に雑談するようなイベントだった。雑談と言っても話していたのは主催者のみで、他のメンバーはチャットにコメントして、それを主催者がみて話題として取り上げるといった進め方だった。悪いイベントではないのだけど、コミュニティの内輪感が強くて初めての人が参加するようなところではないなと思えた。

この1年、スクラムを実践しながらずっと開発方法論やマネジメント／リーダーシップについて考えてきた。考え抜いた (と言ってもたった1年だけど) 結論として開発方法論そのものはあまり重要ではないと結論づけた。重要なのは、自分たちの開発にとって障害や課題を認識したときに改善していけるか。そんなの当たり前だと思うかもしれない。改善するにあたって組織も含めて変えられるかというところが最も重要だと気付いた。スクラムにおいても、簡単な問題はすぐ解決しようとするのに、複雑で難しい問題はなぜ解決への試みすらやらないのだろう？とずっと不思議に思っていた。それは既存の組織や制度のなにかを変えないといけないとき、それらを改善の対象とみなすか・みなさないかという視点が人によって大きく異なることに気付いた。多くの人はそこまでやろうとしない。それは越権行為かもしれないし、思い付きで組織の決めごとを変えられても困るかもしれない。一方で私は頭がおかしくて組織や制度そのものも変えようとする。まず組織を変えようとするかどうかが最初の分水嶺になる。そして、実際に組織が変われるかという最大の課題もある。開発のためだけに組織を変えてくれと経営者にお願いして「わかった」という経営者は稀かもしれない。組織にも歴史や文化があり、会社には開発以外の様々な業務もある。大規模スクラムが提唱されるようになったのは組織を変えていくアプローチがスクラムには重要になってくるという証左かもしれない。

組織さえ変えられるのであれば開発はいくらでもよくなる可能性がある。これは小さい組織や若い組織にとってはとくに有利な点と言えるだろう。開発方法論に何を採用するか、初期のチームがうまく開発できないといったことは些事でしかない。自分たちの開発をより良くすることを本当にやろうとしているかどうかが重要だ。そのことに気付いてからゾンビスクラムをみかけたときも、これは組織のこういった課題から派生していると深堀りするようになってきた。

url エンコーディングと uri の仕様

#java  #spring boot  #medium 

1時に寝ようとして、寝てたか起きてたかわからない時間を過ごして7時に起きた。

WebClient と query string のエンコーディング

以前にも WebClient の基本 について少し書いた。data={"x": 1, "y": 2} のような json 文字列を query string でリクエストしようとしたときに少しはまったので書いておく。java 標準ライブラリの URLEncoder を使ってエンコードするとスペースが + になる。これは html の仕様として正しいが、uri の仕様としては不正になる。そのため + を %20 に置き換える必要がある。

private String encode(String data) throws UnsupportedEncodingException {
    // NOTE: the URI doesn't allow '+' character
    return URLEncoder.encode(data, StandardCharsets.UTF_8).replace("+", "%20");
}

このロジックで {"x": 1, "y": 2} を url エンコードすると次の文字列になる。

%7B%22x%22%3A%201%2C%20%22y%22%3A%202%7D

あらかじめ url エンコーディングした文字列を渡すと、今度は WebClient が % を %25 にさらにエンコーディングしてしまう。Spring WebClient Requests with Parameters 6.Encoding Mode によると、次の4つのエンコーディングモードをカスタマイズできる。デフォルトは TEMPLATE_AND_VALUES らしい。

  • TEMPLATE_AND_VALUES: Pre-encode the URI template and strictly encode URI variables when expanded
  • VALUES_ONLY: Do not encode the URI template, but strictly encode URI variables after expanding them into the template
  • URI_COMPONENTS: Encode URI component value after expending URI variables
  • NONE: No encoding will be applied

もとの url エンコード済みの文字列が次のようなものになってしまう。

%257B%2522x%2522%253A%25...

既存の実装をあまり変えたくもなくてやや力技で実装した。局所的な変更だからまぁいっか。

webClient.get().uri(uriBuilder -> {
  var uriObj = uriBuilder.path(getControllerBasePath() + path).queryParams(query).build(pathParams);
  if (encodedData != null) {
      var uri = uriObj.toString();
      var connector = uri.contains("?") ? "&" : "?";
      uriObj = URI.create(String.format("%s%sdata=%s", uri, connector, encodedData));
  }
  return uriObj;
}).retrieve()

よいエラーメッセージ、わるいエラーメッセージ

タイトルに惹かれてちょっと期待外れ。art というと日本人は芸術と高度なものを期待しがちだけど、the art of だと技術の体系といった意味合いもあるのでちょとしたノウハウを解説する技術ブログのようなものでも誤っていない。

ユーザー体験をよくするためのエラーメッセージのコツとして次の3つを提案している。

  • 何が起きたのか、なぜ起きたのかを説明する
  • 次のステップを提案する
  • 適切なトーンで書く

この3つの具体例としてどのようなものかを説明している。私にとってはそう目新しいものではないが、エラーメッセージにトーンという概念はなかったので最近の流行りなのかなと思った。

そして1年が経った

#thought 

2時に寝て7時に起きた。寝付けなくてタイムラインを眺めてた。1日を淡々と開発して淡々と業務を終えた。

日記を1年書き続けた

最初に日記を書いたのが 2021-09-26 なのでもう1年経ったことになる。時間というのは過ぎてみればあっという間に感じる。歳を取るごとに人生の生きている時間が長くなって相対的に1年の時間が短くなるという論理的な説明を私は気に入っている。私の記憶では1年も継続して日記を書き続けられたことは過去に1度もない。はてなブログを見返すと、もっとも書いた年でも65日だった。もちろん過去の自分は本気で毎日書こうと思っていなかった。そして、それ以上になんのために書き続けるかという動機もなかった。いま独りでお仕事するようになって「書くこと」の重要性に気付いたことは過去にも書いた。

一方で私は平均的な開発者よりも遥かに多くの文章を、日々の業務で書いている。それは課題管理システムに様々なことを記録しているし、チャットでやり取りすることも多いし、1日の半分以上はプログラムを書いている。嗜む程度に sns に投稿したりもする。これだけ書いていて、さらに日記も書くのだから書くスキルが相当に向上している。言い換えれば、毎日日記を書くのが大した労力に感じないぐらいの実務力が上がっているとも言える。日記を書くのは、課題管理システムに日々の積み重ねを書くのとはまた違った様子が伺える。それは1年も書いてみるとその内容から明らかになってくる。人間はわりと自分のことすら分からない。日記にはそのときでしか書けない雑感がある。それはおそらく自分で自分を知る手掛かりになる。

当初の動機づけは あんちぽさんの日記 に影響を受けている。あんちぽさんは20年も日記を書き続けている。どのぐらい続くのかわからないが、5年、10年と続けられるよう、私も書くスキルを磨いていこうと思う。

postgresql の json データ型

#postgresql  #java  #cli 

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 のアプリ開発が楽しくなってきた

#life  #java  #quarkus  #backlog 

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 のビルド環境に手間取った

#java  #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 開発に着手

#java  #slack  #quarkus 

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つ

#infrastructure  #finance  #event 

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

インフラ引き継ぎ勉強会

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

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

インフレ勉強会

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

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

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

最近の java の勉強

#java  #event 

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 でフレームワークを作っている開発者にとってはパフォーマンスを向上できる可能性があるので関心の高い機能だとも思う。

台風の過ぎた連休明け

#founding  #career 

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

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

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

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

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