0時過ぎに寝て6時に起きてだらだらしてて8時に起き上がった。

会議室予約

明日おかださんと話すのでシェアオフィスの 会議室予約サイト で会議室を予約した。この予約サイト、リリースされて1年近く経つけど、本当に使いにくい。技術の無駄遣いって言葉がしっくり来る。会議室はオフィスを借りている人には5時間/月まで無料で使える。元町オフィスの会議室を予約するのは初めてかな。どんな使い勝手かを試してみるよい機会でもある。明日に備えて設備やモニターチェックをしていた。

ソフトウェアエンジニアと技術力

そねさんの1ヶ月以上前に公開されたスライドを、あとで読みこじらせて、今日読み直した。課題管理のためのメンタルモデルを確立しないといけないと考えるようになってきた。そのためのヒントになるかな？とちゃんとメモを取りながら精読しようと思って1ヶ月放置していた。他のことに注力していると別のことができなくなる。ソフトウェアエンジニアという定義をあまりみたことがなくて斬新だったり、書いてある内容そのものは共感できるものではあった。一方で精神論や思想的な話しが多くて、もう少し理論的な裏付けや技術的な背景があった方が私の好みだったなと1ヶ月も置いておいたから期待値が上がってしまっていた。

ソフトウェアエンジニアとは、科学 (ソフトウェア) を活用して問題を解決する力をもつ人であり、ソフトウェアを使いこなして最小の労力で問題を解決することを技術力が高いと言う。

23時に寝て2時前に起きてまた寝て6時に起きてまた寝て8時に起きた。

ストレッチ

今週もお仕事がいっぱいいっぱいで全然ストレッチできなかった。今日の開脚幅は開始前167cmで、ストレッチ後169.5cmと前回よりも数値が悪くなった。さぼっていたから仕方ない。一方で右股関節の不可動領域が週ごとによくなっていて、可動していなかった領域が稼働することによって、内転筋に張りが出るようになっているとのこと。システムで例えると、ある地点のパフォーマンスが改善することで別の地点にニーポイントが移動するような話しだと思う。日常生活でもなんか違和感があると思ってはいたので改善していきたい。

ワーケーション準備

これまで準備してきた 内容を旅のしおりにまとめている。その内容を参加者4人で共有するための打ち合わせをした。これまで私が更新してきた旅のしおりの内容を一通り確認して、みんなで付近の観光案内などをみたりしていた。城崎温泉は720年開湯というくだりを話すと、歴史好きの人たちは反応して平安京やら平城京やらの年号で盛り上がった。私はもともと学校の書架に置いてある「日本の歴史」というタイトルの漫画を3回ぐらい読み込んでいた児童だったので観光地は歴史から入る癖がある。そんな人じゃなくても、人間、歳をとると歴史の重みみたいなのを感じるようになって、歴史に敬意を払うようになるんじゃないかと勝手に思っている。1泊目の宿は予約済みだけど、2泊目どうする？という話しをしていたら、たまたま宿泊予約サイトで Book store iChi ゲストハウス をみつけた。1部屋4人で宿泊できるし、料金も安いし、ゲストハウスとか泊まったことないという参加者もいるし、おもしろそうみたいなノリになって、ノリのまま予約した。ふるさと応援！ひょうごを旅しようキャンペーン も適用できるという話しなので兵庫在住なら2000円/人の割り引きを受けられる。なにかしら情報共有で他人と話すと新しい行動や調査のヒントがあったりしてモノゴトが進むきっかけになると実感した打ち合わせだった。

たまたま話していて「794 鳴くよウグイス平安京」は共通認識だけど、私は「710 なんと都を移す平城京」で覚えてたんだけど、平城京の語呂合わせはバリエーションがあるみたい。しかもヤフー知恵袋みたら「南都」という名詞バージョンもあるとのこと。へー。https://t.co/IvBLJ30inP

— Tetsuya Morimoto (@t2y) December 25, 2021

0時に寝て4時に起きて、なんとなくドラクエタクトしてたら6時になってそのまま朝活に出てた。sns のタイムラインを眺めていると今日で仕事納めにしている人をちらほらみかけた。私は外向けには月曜日が仕事納めで、内向けには水曜日までは働くかな。30日は実家に帰るか、ゆっくり休むか、まだ決めてない。

朝活: バッタを倒しにアフリカへ

先日たまたまみかけた記事から購入した ことを書いた。積ん読状態だったけど、技術書ばかりも疲れるので気分転換に読み進めることにした。

第1章サハラに青春を賭けるを読んだ。著者はおもしろい人だというのは文章から伝わってくるので何を書いてても驚きはしないが、それでもアフリカ(モーリタニア)の生活や状況などは全く知らないことばかりなので何を読んでも斬新には感じる。モーリタニア・イスラム共和国 という国すら私は知らなかった。

第1章は渡航してフィールワークに出掛けた内容が書いてあった。砂漠へ行くチームにコックが必要というのは、ドラクエ脳の自分には出てこない発想で現実は旅をしながらおいしいものも食べたいという欲求は強いのだなぁという学び？があった。

slack のマルチチャンネルゲスト

これまでお手伝い先では slack のシングルチャンネルゲストで参加していた。必然的に1つのチャンネルにすべてのプロジェクトメンバー20人がいる。技術的な話題を気軽に投稿しにくいし、システム通知などもかなり制限されていた。

人間が会話するチャンネルとシステムが通知するチャンネルは分けた方がよい

と、私はプラクティスとして常々言っている。きっと誰もが言っている。システム通知が認知負荷となるという声は業務側のメンバーからも届いていた。これは外部メンバーをマルチチャンネルゲストにすることのコストだけの問題なので、その価値をどう測るかという視点から、中の人がその予算を確保して外部メンバーがマルチチャンネルゲスト化された。その判断を支持する意図でも、slack のチャンネルが複数扱えることでどういった情報共有やシステム間連携の価値があるかというのを、私の経験からも提示していきたいと考えている。情報を監視するという概念、ならびに情報の一元管理にも関わってくるので、課題管理と並ぶ情報共有という文脈で私の強みが活きる分野でもある。いろいろやっていきたい。

23時に寝て1時に起きてまた寝て6時半に起きた。変なライフサイクルになってきた。

maven のアップデートポリシー

maven が依存解決するとき、例えばバージョンの範囲を指定して最新バージョンを取得するといった設定ができる。実行していると、新しいバージョンをチェックしにいくときとそうじゃないときがあって、どういう仕組みで動いているのかよくわからなかったのでデバッグした。言うても DEBUG ログを出力させて、ログの内容をソースで grep しながら関連するところを読んだだけ。

DefaultUpdateCheckManager.isUpdateRequired の中でポリシーが最終チェック日付を確認していいる。ここから辿っていくと ArtifactRepositoryPolicy という仕組みがある。

return ( lastCheckDate == null ) || policy.checkOutOfDate( lastCheckDate );

ドキュメントでそれっぽい内容を調べると updatePolicy を設定できるようになっている。デフォルトは daily なので日次でチェックしにいくような振る舞いをする。バージョンチェックするときとしないときの何が違うのか、よくわかっていなかった振る舞いを理解できた。これはビルドキャッシュの有無に関係ないのでキャッシュがあるからバージョンチェック処理をスキップできるわけではない。もちろん、更新をチェックさせたくないのであれば never に設定してもいいのかもしれない。

updatePolicy

The frequency for downloading updates - can be “always”, “daily” (default), “interval:XXX” (in minutes) or “never” (only if it doesn’t exist locally).

https://maven.apache.org/ref/3.6.3/maven-settings/settings.html

0時に寝て4時過ぎに起きて2度寝して6時前に起きた。

朝活: バッタを倒しにアフリカへ

【三宮.dev オンライン】今年最後のリモート朝活もくもく会 に参加した。スクラム本を読み終えたので気分転換に バッタを倒しにアフリカへ を読むことにした。主に雑談してたら序文しか読めなかった。

課題管理システムを一本化する

お仕事でスクラム開発を実践している。プロダクトバックログを backlog で管理し、スプリントバックログを GitHub Issues で管理している。課題を複数のプラットフォームで管理することは情報の一元管理という側面からよくないといったことをお手伝いを始めたときから機をみて指摘していた。そういう状態が2ヶ月ほど続いて、GitHub Issues は機能的に厳しいという共通認識が開発者にはあるため、backlog へ一本化されることに決定した。スクラムと課題管理との関係を追究したい私にとっては朗報で、今後は PO も含めて課題管理システムの用途をメンバーにアドバイスしながら課題管理の高みを目指していきたい。但し、backlog は標準で github 連携機能を提供していないため、チケット駆動開発をするには自前で連携機能を作らないといけないらしい。

0時に寝て6時に半に起きた。今日は普通に眠れた。お仕事で本番リリース作業のトラブルシューティングのお手伝いをしていてバタバタしてた。

誕生石を63年ぶりに改訂？

先日コーポレートストーンを ターコイズ に決めたとか、訳のわからないことを書いた。たまたまはてブで 日本の誕生石、63年ぶりに改訂　新たに宝石10石追加、全29石に というニュースをみかけた。誕生石のことをよく知らなくて勝手に月に1つの石があるんだと思い込んでいたら全然そんなことはなくて、今回の追加で多い月は4つの石が設定されたらしい。

全国宝石卸商協同組合（東京都千代田区）は12月20日、63年ぶりに日本の誕生石を見直し、新しい宝石10石を追加したことを発表しました。今回の追加により、日本の誕生石は全29石になりました。

(中略)

日本の誕生石は1958年、アメリカの宝石商組合（現在のジュエラーズ・オブ・アメリカ）が定めたものをベースに全国宝石卸商協同組合が初めて制定しました。

記事によると、業界団体が決めているだけで、最終的な目的は宝石を売りたいだけなのかな。「資本主義ってやつか」 って一言つぶやいたら満足するような記事だった。

23時に寝て1時過ぎに起きて4時半に起きて6時半に起きた。寝てないわけじゃないけど、うまく眠れなくなった。

スマホのマイナンバーカードの読み取りは位置がシビア

ワーケーションで ふるさと応援！ひょうごを旅しようキャンペーン を利用する条件の1つにワクチンの接種証明を提示する必要がある。ちょうどデジタル庁から 新型コロナワクチン接種証明書アプリ がリリースされた。このアプリを使えば接種の原本の書類を持っていかなくて済む。

朝からアプリをインストールしてマイナンバーカードを使って接種証明書を発行しようとしたのだけど、マイナンバーカードの読み取りができない。エラーも表示されなくてうんともすんとも動かない。パスワードがロックされていたらエラーが表示されるように思えるのでなんかおかしい状況だった。そのことをツィートしたら、とのきさんがマイナンバーカードの読み取りはシビアで位置があっていないと読み取りできないとアドバイスしてくれた。

スマホ機種によってNFCの搭載位置やカードの当て方などで読み取りが非常にシビアみたいです
NFCチップの位置をスマホとカードで正確に一致させてギリギリ読みとれた、など聞いたことがあります

— demobird (@tonoki) December 20, 2021

午後から JPKIMobile を用いた有効性の確認方法 を確認しながら再挑戦した。ここに書いてあるようにちょっと離したり、カードの位置を少しずつずらして調整したりしてたら読み取りできた。この時点でパスワードロックではないことを確認できた。

iPhone端末にICカードをセットします。画面が変わらないようであれば、一度ICカードを離してから再度セットしてください。

JPKIMobile で読み取りできたので同じ要領で接種証明書アプリでもやってみたら今度はすんなりと読み取りできて発行できた。位置さえあえば読み取りはすぐできた。今朝はたぶん机に置いて位置を調整せず、読み取りには時間がかかるのかな？とずっと動かさず待っていたのがよくなかったみたい。とのきさんのおかげで区役所に行く無駄な時間を削減できた。感謝。

0時に寝て2時過ぎに起きてだらだらして7時に起きてだらだらして8時に起き上がった。休日は自然とだらだらしがち。

log4j2 の脆弱性対応

たまたま sns で新たに脆弱性が発見され 2.17.0 がリリースされたことをみかけた。Apache Log4j Security Vulnerabilities をみて、午前中に対応して pr を作成して dos 攻撃の脆弱性と書いた後に次のツィートをみかけた。私は詳細を理解できていないのでこの内容が 2.17.0 で fix されているのかどうかまでは調査できていない。いずれにしても rce 攻撃はこわいから緊急度が跳ね上がるなとみていた。

【悲報】log4jのRCE脆弱性、2.15で緩和策としてlocalhostにしかlookupできなくしたはずが、127.0.0[.]1#example[.]comのように#を挟むことにより回避可能ということが判明。これにより任意ドメインへのリクエストが可能になり再びリモート実行可能に。みなさん最新版の2.17にアップデートしましょう。 https://t.co/uQhJSnjv7m

— たいしょー（Hiromasa Ihara） (@miettal) December 19, 2021

アジャイル開発とスクラム 第2版

昨日の続き。素晴らしい本だったので所感をまとめた。スクラム開発の理解がより進んだ。

• アジャイル開発とスクラム 第2版 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

0時に寝て6時に起きてだらだらしてて8時に起き上がった。

ストレッチ

今週もお仕事に注力してた。ストレッチは2-3日/週かな。普通ぐらいの頻度。夜は寒くなって外に出掛けるのが億劫で1日ウォーキングしたかなぐらい。今日の開脚幅は開始前169cmで、ストレッチ後170cmで、久しぶりに170cm台に戻した。いい感じ。右股関節の不可動領域がよくなっているのが実感できるようになってきているので調子はよさそう。今日は全体的に右半身 (太もも後ろ、腰、大胸筋) と張りがあって疲労もやや溜まってそうに思えた。基本的に週末もなにかしら作業していて疲労が蓄積していないのは毎週のストレッチの効果も大きいと考えている。

次の bizpy 勉強会

1月の bizpy 勉強会のイベント、Python で機械学習をやってみる勉強会 を公開した。次回はわたなべさんに講師をやってもらう。このイベントページも作っていただいた。運営が2人になったのでお互いの忙しいときは分担しながらコミュニティを運営していける。本当にありがたい。わたなべさんが担当している間に私も次のネタの下調べや仕込みをする余裕がもてる。メタバースの勉強会やってもいいなとは考えているけど、私だけではコンテンツが弱くて、よそから詳しい人を招いてこないといけない。どうしたものか。

アジャイル開発とスクラム 第2版

読了した。全12章の後にもコラムと対談があって、この内容も読み応えがあっていくつも示唆を与えられるものだった。

• コラム 野中理論とスクラム
• スペシャルトーク 野中氏と平鍋氏の対談
  • イノベーションに必要なのは、対話を通じて共振・共感・共鳴する実践知リーダーシップであり、それがスクラムの心だ
• おわりに

12章で出てきた実践知について、実践知とは何か、実践知リーダーシップとはどういうことかというのが対談の中でも繰り返し出てきてその理解が深まった。私の中では暗黙知と実践知の境界が曖昧だったが、暗黙知と形式知を行ったり来たりすること、そして身体性を伴っているというのが実践知であること。そこには「もの」や「こと」の目に見えない関係性を洞察しながら判断し、本質を考え抜く知力が必要であると述べられていた。昔は 知行合一 と言ったらしいが、90年代以降の日本は分析過多、計画過多、コンプライアンス過多になってしまったという。また時間のあるときに所感をまとめようと思う。

0時に寝て6時に起きた。ここ最近は晩ご飯作って食べてアイスクリーム食べてドラクエタクトやって寝るみたいな業後の過ごし方が多い。

朝活: アジャイル開発とスクラム 第2版

金朝ツメトギ 2021-12-17 AM 6 金曜朝6時開催のもくもく会 で第11章スクラムと知識創造と第12章スクラムと実践知リーダーを読んだ。

第11章では知識想像モデルとして SECI モデルが紹介されている。ふと読んでいて、私が課題管理システムでやっていたのはこの「表出化」の活動で、多くのスクラムをやっているチームは「共同化」を主にやっているように思えた。ソフトウェア開発方法論の歴史的に、チケット駆動開発 → イテレーション開発 → アジャイル開発/スクラムの時系列に発展してきた経緯から、私のようなチケット駆動開発をがっつりやってきた開発者が言う対話が重要だと言うことと、最初からスクラム開発で「共同化」しかやらず「表出化」していない開発者が言う対話が重要だと言うことは、背景事情からして根本的に指している内容が違うのではないか？という仮説を思いついた。対話が重要だと言う開発者がドキュメントや文章を書くことをなおざりにするのを見かけて違和感を感じていた。チケット駆動開発をがっつりやってきた開発者は文章を書いた上でそれだけでは解決できなかった問題を解決するために対話が必要だと言っているわけであり、文章すら書けない開発者は対話だけで開発を進められるわけではないと考えると、これまでスクラム開発に抱いていた私の違和感の正体に近づいたように思えた。

第12章では実践知という概念とそのリーダーシップが紹介されている。以前 実践知 — エキスパートの知性 という本を読んで、メタ認知も含めた認知心理学の知見を踏まえた知識創造や実践知を獲得するに至る背景や教育と課題管理との間にある関係性を考えていたことがあった。スクラムにおいても実践知という概念を扱っているのを読んで、ここにはなにかしらの関係性を見出したり体系化を行う余地があるように考えている。やや哲学的な話題も出てくるので人によって賛否がわかれるかもしれないが、私は自分の考えている中長期的な思考や教育への考え方の価値観が合致していて、これが日本的な経営スタイルの鍵だという意見には一定の同意ができる。自分自身も中長期的な展望を大事にしながら課題解決していきたいという想いもあるからだ。

ワーケーション準備

ワーケーション準備 の残タスクを少しずつやっていく。宿泊先の きのいえ に電話してチェックイン前に駐車場にレンタカーをとめさせてもらえないかを問い合わせた。当日に宿泊客がいれば13時以降、いなければそれよりも早めにとめてもよいとのこと。スタッフがいれば声をかけていなくても勝手にとめてよいと教えてもらった。先方からも ふるさと応援！ひょうごを旅しようキャンペーン が本来は12月末で終了だったのが2月28日まで延長されたため、宿泊者が兵庫県在住であればその手続きをしたいとのこと。一旦、オンラインで決済済みの予約をキャンセルして、現地決済で兵庫県の割り引きの手続きをしてくれるという。メンバーは4人中3人が兵庫県在住なので4,000円/人の割り引きで合計12,000円の割り引きになった。

1時半に寝て7時半に起きた。ちょっと疲れてて寝坊した。

W3C Trace Context の traceparent ヘッダーの生成

前にお仕事で dapr の分散トレーシングを検証している ことについて書いた。

dapr の分散トレーシングは W3C Trace Context に準拠していて、dapr 経由のリクエストは自動的にこの情報が付与されるが、そうじゃないリクエストもトレーシングできるようにするためには http ヘッダーの traceparent をセットしないといけない。試しにサーバー側に traceparent を生成するのはどうやるのかを調べてみた。Implementations of Trace Context にある java ライブラリを調べていて、Jaeger クライアントは OpenTelemetry に移行したと書いてあって、OpenTracing と OpenCensus は OpenTelemetry に統合されたと書いてあって、どうやら OpenTelemetry を使うのがよさそうだとわかった。

やりたいことは traceparent を生成したいだけだが、OpenTelemetry の Manual Instrumentation を読んでも直接的なやり方は書いてなくて、open-telemetry/opentelemetry-java のテストコードなどもみながら実装した。細かいところの仕様をまだ理解できていないけど、ひとまずこれで生成できたので検証はできると思う。

public class W3cContextUtil {

    private static final String TRACE_PARENT_VERSION = "00";
    private static final OpenTelemetrySdk openTelemetry = OpenTelemetrySdk.builder()
            .setTracerProvider(SdkTracerProvider.builder().build())
            .setPropagators(ContextPropagators.create(W3CTraceContextPropagator.getInstance()))
            .buildAndRegisterGlobal();
    private static final Tracer tracer = openTelemetry.getTracer(
            "my-tracer", "1.0.0");

    public static String generateTraceParent() {
        Span span = tracer.spanBuilder("parent").startSpan();
        try {
            SpanContext sc = span.getSpanContext();
            return String.format("%s-%s-%s-%s",
                    TRACE_PARENT_VERSION,
                    sc.getTraceId(),
                    sc.getSpanId(),
                    sc.getTraceFlags().asHex());
        } finally {
            span.end();
        }
    }
}

大阪Python もくもく会

大阪Python もくもく会 #66 にオンライン参加した。コロナ禍前に大阪へ通勤していた頃はオフライン勉強会に何回か参加したことがある。主催者のやぎさんは一度 bizpy に参加してくれたこともある。11月からオフライン勉強会を再開したとのこと。久しぶりに参加してやぎさんと話していたら neosvr にも関心をもっているとのこと。私も少し前に oculus quest 2 を購入して触ってみた程度なのでメタバース関連で一緒に勉強会をしてもよいかもしれない。もくもく会では「アジャイル開発とスクラム 第2版」を読んでいて昨日の日記の記事がまさにその成果物。せっかくなので成果発表でこの本の紹介などをした。