Posts for: #2021/09

窓のある部屋

#gig  #book 

夜は自民党総裁選の総括の記事を読んでた。政治に関心があるわけではないが、選挙後の総括にはとても関心がある。とくに負けた人がどんなことを言うのか、敗因をどう分析するのか。シンゴジラで矢口の発した 「政界は敵か味方しかいない。シンプルだ。性に合ってる」 という言葉が好き。選挙というわかりやすい勝ち負けが明確に出る仕組みは確かにシンプルだ。その後、3時まで本を読んで寝て7時ぐらいに起きた。

カジュアル面談準備

課題管理と開発方法論の体系化のため、プロジェクトマネージャーの案件を探している。Remogu というリモートワークxエンジニア専門のサイトでギグワークできないかを検討中。ある会社を提案されたのでその会社のサイトとサービス内容を調べてた。飲食業界向けに提供しているサービスを、これまではアウトソースで開発していたシステムを内製化するために開発者を募集しているようだった。いま風に言えば、DX の1つと言えるだろう。これから内製の開発チームを作っていくとのこと。言うても CTO (PMO) 以外はすべて業務委託で集めるとのこと。デメリットはチームにならず、寄せ集めの集団になってしまう懸念がある一方、メリットとして採用したものの、マッチングしなかったメンバーの契約更新しないことで入れ替えることができる。明日、その会社の人たちとカジュアル面談をして双方のマッチングをみてみる。

Joel on Software

昨日の続き。夜に読み切ろうと思っていたけど、ドラクエタクトの新しいイベントがリリースされて、それやってたら疲れて寝てしまった。あともうちょと。特定の技術に言及している内容は2000年代半ばの話しなのでいまとなっては有効ではないものや歴史書のように読めたりもする。中盤からソフトウェアビジネスやソフトウェア会社の運営などが書いてあって、マイクロ法人を始めたばかりの私にとっては興味深い。例えば、オフィスの要件は次の内容をあげている。

  1. 1人1人にちゃんとドアの付いた個室があること、絶対条件
  2. コンセントがたくさん必要、新しいおもちゃを机の上でつなげられる
  3. データケーブルを簡単につなぎ直せる
  4. ペアプログラミングが可能であること (L字型の大きい机を用意する)
  5. 遠くのものを眺めて目を休められるよう窓を設け、ディスプレイを壁に向かって置いてはいけない
  6. オフィスはそこで時を過ごすのが快適なたまり場のような場所であるべき

その上で、会社の成功は、ある部分までプログラマーが実質オフィスに暮らすようになるかどうかにかかっているので、オフィスが平均的なプログラマーの家よりも素敵な場所である必要があると述べている。実際、私は過去に働いた6社すべてで泊まり込みで働いたこともあるのでまさに暮らすように働いていた時期もあったかもしれない。机に伏して寝たり椅子を並べて寝るよりは、ソファやくつろぎスペースで寝る方が快適だった。あと、いまのオフィスの唯一の欠点は窓がないことだと1年ほど働いて、ちょうど私も実感していた。窓がないと1日の天候の移り変わりや季節の移り変わりがみえなくて気分転換ができないのだ。次にオフィスを引っ越すときは窓がある部屋を条件に加えようとまさに考えていた。

あと自分にとっての課題管理の原点をみつけた。過去に働いていた会社で、課題管理システムに顧客からの問い合わせや開発者のTODOやシステム管理のメモなど、すべての情報を入れられていた。こういった課題管理システムの使い方は次の記事に影響を受けて実践されたものだったと当時の上司に確認した。たったこれだけの話なんだけど、私にとっては原点なので宝ものを発見したかのような嬉しい気持ちになった。

読書とイベント参加

#book  #java  読書とイベント参加

0時頃に寝て8時ぐらいに起きる。やや発熱して疲れてたせいか、久しぶりに早く寝付けた。一日を通して体温は平均36.7℃なのでもう副反応は過ぎたみたい。体調もまったく悪くない。

Joel on Software

過去に働いていた会社での課題管理のやり方や開発方法論について、当時の上司と雑談したところ Joel Spolsky に由来するということを聞いた。そこで今更ながらに More Joel on Software を読むことにした。2000年代に書かれた記事の内容なのでいまとなっては古典に分類される本かもしれない。だいたい半分ぐらい読んだ。技術の詳細に言及した内容は古くなっていてあまり有用ではないものも多いけど、マネジメントや優秀なプログラマーの特性などはいまでも通用する内容に思えた。あとで私が関心をもった内容をブログでまとめることにする。

第10章コンピュータサイエンスの学生へのアドバイスで「卒業するまでにミクロ経済学を学ぶこと」という節がある。著者がミクロ経済学を推奨する理由を引用するとこれら。

ミクロ経済学はビジネスで重要な理論すべての基礎となっている。需要と供給とか、競争優位とか、NPV とか割り引きとか限界効能について知らなければ、ビジネスの仕組みが全然理解できないからだ。

マクロ経済学は、当たっているよりもはずれていることの方が多い。スキップしてよい。それ以降はただ悪くなっていく一方。

ビジネスの基礎を理解しているプログラマは、理解していないプログラマよりもビジネスにおいてずっと価値が高いからだ。

学んだことがなかったので簡単そうな ミクロ経済学入門の入門 を購入した。

読んでて気づきを得てふとツィートした。

Java 17 リリースイベント

【オンライン】 JJUGナイトセミナー「Java 17 リリース記念イベント with Foojay」9/29(水) 開催 に参加した。Java の LTS はいま過渡期でややこしいことになって、8, 11, 17 になる。リリースされたばかりの Java 17 は LTS で重要なバージョンになる。Oracle Java SE Supportロードマップ から Premier Support 期限が次になる。

  • 8: 2022年3月
  • 11: 2023年9月
  • 17: 2026年9月

いま 11 を使っている組織はいいが、8 を使っている組織もまだまだ多いと推測する。8 と 11 の Premier Support 期限が近いことから 8 を使っている組織は 17 に一気にバージョンアップすることが想定される。どこかのタイミングで Java 17 を前提した開発に切り替わっていくだろうと思われる。

最初の発表は Pattern Matching & Sealed Classes に特化した内容。これまでは instanceof と共に使う機能だった。switch 構文とパターンマッチングを組み合わせると、コードが簡潔になって Cognitive complexity を下げるという。発表者が Type Guard という呼び方をしていた。Type Guard をググると TypeScript の記事がヒットする。JEP 406: Pattern Matching for switch (Preview) ではこれを guarded pattern と呼んでいる。まだあまり一般的な用語ではないのかもしれない。あとは Sealed クラスと組み合わせた switch 構文のコード例では、すべてのパターンが網羅されていることをコンパイラが検出して default 句が不要になるコード例も紹介されててよさそうにみえた。但し、switch 構文のパターンマッチングは preview なので実際には 17 ではまだ使われないのかもしれない。今後もさらに switch 構文とパターンマッチングの機能拡張が行われる展望らしい。

2番目の発表は Java 17 の全体的な話し。fix した issues のツリーマップで contributor の分布を紹介していた。oracle, redhat, independent の順番に多い。oracle が過半数以上。日本だと ntt data が一番貢献してた。spring フレームワークの次期バージョンは Java 17 がベースラインになる。java のアップグレードを促す要因の1つにはなるはず。lts なのになぜ preview や incubator があるのか？openjdk 開発側は6ヶ月というリリースサイクルを守っている。lts にするか否かは開発者が決めているらしい。graalvm のリリースサイクルは java とは異なる。こちらは年3回のリリースなので次のリリースで出てくるはず？いくつか jep の内容を紹介してた。jep の概要は Java17の新機能をざっくり紹介 にまとまっている。さくらばさんがパッケージの api レベルでの変更を JEPでは語れないJava 17 にまとめている。ざっと目を通して興味があるものがあればみとくぐらい。8 から 17 への移行の記事やドキュメントなども紹介されてた。移行について基本は Oracle JDK Migration Guide を読めとのこと。8 から 17 の移行せずにその次の 23 を待つと作り直しになってしまいますよと 17 への移行を推奨してた。

副反応はいずこ？

#life  #hugo  #book  #halp  副反応はいずこ？

2時過ぎぐらいに寝て5時前ぐらいに起きる。やや熱っぽいかなぁぐらいの印象でもう一度寝る。8時前に起きるともう平気になってた。昨日、書籍や macbook を持って帰ってきて引きこもり対策してたけど、体調が悪くないのでオフィスへ行くことにした。お昼から1時間おきに熱を測ってみたら37℃前後なので少し熱は出ていたみたい。とくにしんどくなかったので普通にお仕事してた。

水分補給

副反応対策として、ポカリスエットイオンウォーターの粉末をウォーターサーバーの水に混ぜて飲んでみる。イオンウォーターと普通の ポカリスエットとの違いは何ですか？ によると、基本的な成分は同じで低カロリーという違いがあるらしい。

日記サイト構築

diary リポジトリに push すると GitHub Actions で静的サイトをビルドして GitHub Pages で扱うための gh-pages ブランチに push される。GitHub Actions による GitHub Pages への自動デプロイ を参考にした。gh-pages ブランチにあるものが次の URL で参照される。リポジトリ名の diary がパスになるらしい。

まだ設定は不完全だけど、運用しながらおいおい設定を詰めていく。Hugo は会社のホームページにも使っているので慣れているのと、使い心地も気に入っているのでこのまま使い続ける。会社のサイトはたまにしか更新しないので日記を書く方が更新頻度があがって Hugo を触るインセンティブになるかもしれない。

ジャーナリングとは

読みかけで放置していた 「手で書くこと」が知性を引き出す 心を整え、思考を解き放つ新習慣「ジャーナリング」入門 を読み終えた。この日記も簡易的なジャーナリングになればよいと願っていたりする。「書くこと」への期待値を高くもって読み進めたせいか、内容が薄かったように思えた。ジャーナリングを行うテーマのワークシートが24個ついていて、ページ数を稼いでいるように感じた。日常生活であまり書いていない人には関心をそそるかもしれないけど、プログラマーは日常生活で平均以上の文字数を書いていると推測する。私にとってはあまり目新しいことはなかった。

マインドフルネス (気づき) を得るための方法論の1つとして書く瞑想=ジャーナリングを推奨している。手書きとキーボードのタイピングでは効果が異なるという研究成果はおもしろかった。手書きの方が記憶力や理解力を高める、脳波はアルファ波が出るといった研究があるという。従って、より創造的な仕事に向くかもしれない。ジャーナリングの研究によって、わかってきたことの1つは、自己や他者、社会への適応力を高めると示唆されている。ここでいう「適応力が高まる」というのは、課題や問題をどうとらえ、これからどう行動すればよいかのヒントにつながる可能性があるという意図らしい。ジャーナリングは心身の健全性にもプラスの影響をもたらされる可能性が高いといった研究も紹介されている。私の感覚的にも、書くことで課題や問題を明確化することはストレスを軽減して健康になるような気がする。

ジャーナリングをする際に大事なことは「考えない」 ということです。

書く瞑想とも言われる所以にも思える。そのままの状態を観察して気づきとするような、そういう姿勢を説いている。この内容は業務の取り組みへの応用からは離れてしまう。

前に メタ認知で〈学ぶ力〉を高める：認知心理学が解き明かす効果的学習法 の著者が タイピング思考法の開発とその有効性の検討 という研究発表をしていた。この研究は、思考過程を推測する手法として、発話思考法における問題を解決するタイピング思考法を提案し、既知の問題を解決しつつ、発想の促進効果もみられてそこそこよい結果が出たというものであった。思考過程を発話とタイピングの2つで比較している。比較項目に手書きがあると少し結果に差異が出たりしたのかなぁとか思った。

Atlassian Community Online MeetUp の参加

課題管理システムとチャットツールを連携する Halp というツールがあるらしい。うちは課題管理システムにクラウド jira を使っていて、Atlassian 社から届くメールで本イベントのことを知った。Atlassian Community Event の頭文字をとって ACE と呼ぶらしい。

初めて ACE イベントに参加した。コミュニティ (ユーザー) 主体のイベントになるらしい。運営メンバーの中に前職での jira チームのリーダーが出ていてちょっとびっくりした。何度かやり取りしてお世話になった方だったのでこういうところでも活動しているんだと思ってさらに尊敬の念が深くなった。halp については、想像通り、非開発者向けに slack の操作だけで jira の課題管理システムと連携するためのサービスとしてよさそうだった。slack (halp) と jira は双方向にデータの同期ができる。いまのところ、halp の無料プランがないので試せてないけど、なにかの機会で一通り触ってみたいと思うサービスだった。

コロナワクチン2回目

#life  #xr  #hugo 

土曜日は昼寝してたくさん寝たせいか、昨日はうまく寝れなかった。4時頃に 「手で書くこと」が知性を引き出す 心を整え、思考を解き放つ新習慣「ジャーナリング」入門 の序章と1章を読んだ。手で書くのとキーボードをタイピングするのでは前者の方が脳が活性化されるらしい。指先の細かい制御が脳に効果的なようだ。5時ぐらいから寝て8時前に起きる。

Horizon Workrooms

Oculus Quest 2 を使って顧問の知人と workrooms を使って仕事の打ち合わせをやってみた。

9時から1時間強ほど打ち合わせ。

macbook を Oculus リモートデスクトップで接続して、ホワイトボード (スクリーン) で共有しながらの会話をやってみた。所感としてはこんなところ。

  • リモートデスクトップと画面共有
    • 目の前の画面を大きくできるのでホワイトボード (スクリーン) よりみやすい
    • 眼の前の画面をみて説明すると、相手の顔が見えないので vr のメリットが半減する
    • 半仮想モードで話しながらメモをとるのは可能ではあるが、現実でやるよりも難しいので効率が悪化する
    • パソコンの操作が現実よりも難しいので、操作しないインセンティブになりがち
    • リモートデスクトップで画面共有をしていたせいか、
      フル充電した状態から1.5 時間ぐらいでバッテリーが少ない警告が出た
  • ヘッドセットの位置調整がうまくいかないと画面の文字がぼやけたりする
  • ヘッドセットの固定がうまくいかないと、会議に集中できず、ストレスになる
  • 1時間程度の会議であれば、とくに vr による疲れなどは気にならない

打ち合わせ終わってから NeosVR をするために Linux マシンと Oculus Quest 2 を接続する方法を検討。

Oculus Link アプリを PC にインストールする必要があるが、Windows 向けにしか提供されていない。wine で動かない、一通りツール類をインストールして試してみたつもりだけど、このエラーを解決できなかった。諦める。

$ wine --version
wine-5.0 (Ubuntu 5.0-3ubuntu1)

$ wine ~/Downloads/OculusSetup.exe
002a:err:mscoree:CLRRuntimeInfo_GetRuntimeHost Wine Mono is not installed

Windows マシンを買うにしても PCVR をするにはそこそこのスペックが必要になり、ざっと調べると10-20万円ぐらい。ノートPCでも15-16インチぐらいのを購入すればスペック的には大丈夫そうといった記事がいくつかみつかった。

このために Windows マシンを買ってまでやるほどのことでもないので PCVR は断念して普通に Linux マシンで NeosVR に挑戦することに決めた。

お昼

14時前ぐらいにお昼ご飯に出かけた。近所の居酒屋さんが緊急事態宣言の期間だけお弁当を販売している。いつもは13時頃には売り切れているのに、今日はたまたま14時なのに3個も残ってた。500円でおかずがいろいろ入っててコスパがいい。そのままお弁当を買ってオフィスで食べることにした。

日記を書く環境を決める

この後、コロナワクチン2回目摂取があるので、副反応の発熱でいつ作業が中断してもよいように日記を書くための環境を構築することにした。

ざっくり条件はこんな感じ。

  • 目的は「書くこと」そのもの
  • シンプルに自分が読むためだけの文章を書ければよい
  • エディターやビューアをロックインされたくない
  • コンテンツをテキスト (markdown) で扱いたい
  • コンテンツをサービスにロックインされたくない

それぞれのツールを検討してたときのメモ。

  • ブログプラットフォームは使いたくない
    • hatena, medium, note はすでに使っているので除外
    • 広告やガジェットや管理ツールとかいらない
    • シンプルさがなくなってしまう
  • メモツールに書く
    • obsidian や hackmd など
    • メモツールなので日記を書く用途とはちょっとズレる
    • シンプルさがなくなってしまう
  • wiki に書く
    • notion や growi など
    • シンプルさがなくなってしまう
  • ジャーナルアプリに書く
    • まさに日記そのものだけど、有償のプロダクトが多い
    • エディターは専用アプリになりそう
  • 自分で日記ツールを作る
    • headless CMS とフロントエンドを実装する
    • いま日記を書き始めたいのにいつ書き始められるかわからない

最終的に残ったのは GitHub Pages だった。

  • 静的サイトジェネレーターに Hugo を使う
  • Hugo のテーマをカスタマイズすればシンプルにできそう？
  • 自分の好きなエディターで書ける
  • 自分の好きなビューア (ブラウザ) で読める
  • Git リポジトリなのでサービスにロックインされない

コロナワクチン2回目摂取

1回目の後、最速の日程から1週間ほど遅れてネット予約が取れた。摂取会場のクリニックでは、午前中は1回目、午後は診療やって、夕方に2回目摂取の時間帯になっているみたい。したがって17時という遅い時間帯に摂取した。私を含め、6人しか患者がいなかったので混雑も待ち時間もなくすぐに摂取して、15分ほど様子をみて帰ることができた。

ワクチン打った後、facebook にコメントを残したり、家族へ LINE でメッセージを送った。

それで何が変わるかわかってないけど、一人暮らしなので万が一、体調が悪くなって誰も気づかないままそのまま死んだとしても、ワクチンで運が悪くてしんだんやなと周りの人が気付けるようにという意図がある。一体、誰に気を使っているのか、自分でもよくわからないけど、自分が不慮の事故で死んでしまったとして、身近な人には多少なりとも背景が伝わることでお別れの挨拶変わりにはなるかな？という、変な気遣いをしている。

Terminal のカスタマイズ

副反応の発熱でいつ作業が中断してもよいように日記を書くための Hugo の Terminal というテーマの設定を始めた。

18時から20時ぐらいまでオフィスで作業して、買い物して帰ってきて晩ご飯食べて、その後も環境構築の作業をした。翌2時の時点で全くしんどくない。config.toml の設定項目に対するドキュメントがないけど、直接 grep で html のソースをみた方が早いことに気づいた。

とりあえずコンテンツを書いてみて、そこそこの見た目で表示できるようになった。まだ完全ではないので随時、後日、ソースを読みながら設定していく。

iostat-tool メンテ

#pypi  #iostat  iostat-tool メンテ

再現調査

お昼ぐらいオフィスに行って事前に下調べしてあった iostat-tool の不具合修正をする。

前職でディスクI/Oの振る舞いを調査していたときに iostat のアウトプットを直接みてもわからないので視覚化するツールを作った。例えば、iostat -ymxt 1 のアウトプットは次のようなログになる。

06/13/2018 02:10:50 PM
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.47    0.00    0.24    0.18    0.00   99.11

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdd               0.07    45.88    1.57    0.59     0.08     0.18   246.55     0.26  121.04    1.28  436.94   2.07   0.45
sdh               0.07    45.78    1.59    0.60     0.08     0.18   245.64     0.22  101.97    1.17  367.51   1.89   0.41
sdb               0.25    74.42    5.70    0.87     0.57     0.29   268.00     0.32   49.24   38.06  123.00   1.83   1.20
sdg               0.07    45.84    1.57    0.60     0.08     0.18   246.12     0.26  118.32    1.24  426.10   2.05   0.44
sdc               0.10    46.79    1.62    0.63     0.09     0.19   246.47     0.16   72.62   11.13  232.29   1.39   0.31
sde               0.07    45.79    1.56    0.60     0.08     0.18   246.16     0.21   98.68    1.10  351.50   1.83   0.39
sdj               0.07    45.88    1.56    0.60     0.08     0.18   245.68     0.21   95.91    1.07  341.03   1.80   0.39
sdf               0.07    45.76    1.58    0.60     0.08     0.18   245.70     0.19   85.95    1.03  308.11   1.79   0.39
sdk               0.07    46.68    1.56    0.61     0.08     0.18   247.68     0.28  128.43    1.25  455.92   2.17   0.47
sdi               0.07    45.67    1.57    0.60     0.08     0.18   244.58     0.21   96.74    1.11  344.99   1.84   0.40
sda               0.16    15.06    0.15    1.95     0.01     0.07    72.69     0.13   61.45    3.77   65.84   8.24   1.73

当時 rhel6 相当のディストリビューションで検証していた。そのため、その iostat のバージョンしかテストしてなかった。その後、時間が経って新しい項目が増えたり、同じ項目でも名前が変わったりしたみたい。vagrant で bento/centos-8 の環境を構築して man iostat や iostat のアウトプットを出力しながら確認した。

CentOS 8.3 の systat 11.7.3 のバージョンのアウトプットはこんな感じ。

09/26/21 03:35:19
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.00    0.00    0.00    0.00    0.00    1.00

Device            r/s     w/s     rMB/s     wMB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util
sda              1.00    0.00      0.01      0.00     0.00     0.00   0.00   0.00    1.00    0.00   0.00     8.00     0.00   2.00   0.20

時刻のフォーマットが違う

これは sysstat のバージョンによるものではないけど、ロケールの LC_TIME のエンコーディング指定を変えると時刻のフォーマットが変わることに気づいた。これも en 環境しかチェックしてなかったから今回 ja でも正しく時刻をパースできるように修正した。

old: 06/13/2018 02:10:50 PM  # LC_TIME="en_US.UTF-8"
new: 09/26/21 03:35:19       # LC_TIME="ja_JP.UTF-8"

Device の軽微な変更と項目の変更

新しいフォーマットだと Device: のコロン文字がなくなってたりしてパースできなくなっていた。あと次の項目が名前変更、または新規追加されてた。

  • aqu-sz
  • rareq-sz
  • wareq-sz
  • %rrqm
  • %wrqm

基本的にパーサーをいじる必要はなくて項目の追加などで対応できた。当時、検証していたとき、作業がうまくいってなくて2-3日で突貫で作ったツールなのでパーサーはあまりきれいに実装はされていない。作った本人がみても1-2時間デバッグしながら直す必要があった。今後も iostat のアウトプットに大きな変更があるとは思えないからまぁいいかな。

generator-based coroutines の deprecated

このツールを作った当時、python 3.4 以上をサポートする必要があったの generator-based coroutines で実装した気がする。それが 3.8 以降は deprecated になっているみたい。今回保守するときにサポート対象を 3.6 以上に変更したのですべて async def で書き直せるようになった。そう急ぐ必要もないのでまた今後、気が向いたら async 周りの実装も見直しながらやってみる。覚えていたら。

Deprecated since version 3.8, will be removed in version 3.10: Use async def instead.

https://docs.python.org/ja/3/library/asyncio-task.html#asyncio.coroutine

iostat-tool 0.3.0 リリース

2018年から約3年ぶりに保守した。ついでに GitHub Actions で lint check と doctest の CI を実行するように変更した。