0時に寝て6時に起きた。たまたま見かけた記事から昔読んだ本を思い出した。

40代は改革と革命

たまたまタイムラインでこんな記事をみかけた。

30代のころは「改善」でいいと思うのです。30代のうちに仕事の基礎をガッチリ身につけ、40代以降は改革と革命に取り組む。私はいつも、40代以上の社員に「改善をするな」と言っているんですよ。

ニトリ会長が斎藤佑樹にアツく語る、「30代にするべきこと」「40代にやるべきこと」

私の生き方に近い考え方だったので印象に残った。私はもともと sier 出身なので働き始めた頃からマネージャー側にいた。たまたまトラブルプロジェクトに参加してひたむきに1年半ほど働き通したら大きな成果が出て、組織からプロジェクトマネージャーになることを嘱望されるようになってしまった。私はただの議事録係だったが、結果的に事実上のプロジェクトを仕切るようになった。それはそれで誇らしかったのはあるけど、それと同時にマネージャーはだいたい分かったという気持ちにもなった。そしてマネージャーの働き方は自分の意思ともあわなかったので潔く辞めた。おそらく自分がやったことのないことに挑戦するという生き方の基礎が最初の退職と同時に出来た。転職じゃなくて退職なのは辞めることを決めてから次のお仕事を探したから。閑話休題。30代のときにひたすらコードを読んで、ひたすらコードを書いてきた動機づけの1つとして、昔読んだ本の１つに リーダーの易経 がある。著者によると、易経とは時の変化の原理原則が書かれていて、時を読むための専門書と言えるらしい。時の第三段階として次の言葉がある。

君子終日乾乾 (けんけん) し、夕べに惕若 (てきじゃく) たり。厲 (あや) うけれども咎なし。

(要約) 朝から晩まで、繰り返し邁進して努力する。そして、夜、独りになったときに、1日を恐懼 (きょうく) して省みる。そのようであれば、危うい時ではあるが、咎めはない

「乾乾 (けんけん) す」とは高揚感、充実感をもって進む、「厲 (あや) うけれども咎なし。」とは省みることを怠らなければ、危うい立場ではあるが、大きな失敗はないという意味になるらしい。

自分の力、自分でないとできないことを創出するためには、なかったものを創り出すわけです。そのために必要なものは、毎日朝から晩まで同じことを繰り返すことです。継続は力なりというのは、この段階です。

同じことを繰り返すことが創出につながるというのはおもしろい話しで、同じことを繰り返すうちにちょっとしたミスや失敗が創意工夫や技を磨くきっかけになるという。失敗したで終わらせずに省みることで気付きを蓄積していくことがオリジナリティを育てる。乾乾 (けんけん) という言葉の響きを気に入ったのか、おそらく2007年頃に読んだ本なのに15年経ってもいまも記憶に残っているというのは人生において影響を受けたと言っていいだろう。

若い頃からマネージャーをやってくれという依頼を断り続けて、いま満を持して次のお仕事ではマネージャーをやろうと考えている。メンバーとして経験を得た上でマネージャーとして自分が何をできるかを確認したい。一方でマネージャーの仕事を未経験／業務委託で探すのがなかなか難しくて苦戦している。私には課題管理というたった1つの武器しかないが、それをマネージャーとしてどう活用できるのか。組織で働く人は言われたことをやる人が多い。私は課題管理を用いて然るべきことをやることに重きを置いている。課題管理で業務を改革や革命のレベルまで昇華できるかどうかを実践の場で確かめたい。

1時に寝て7時に起きた。開発の作業しようかと思っていたけど、なんか気分が乗らなくて本を読んでただけだった。

ストレッチ

今日の開脚幅は開始前158cmで、ストレッチ後162cmだった。まずまずの数値でストレッチを受けていても調子がよかった。気温が下がって暑さが和らいできて体調もよくなってきた感じがある。以前から姿勢があまりよくないといったアドバイスを受けていて、前側の筋肉に比べて後側の方が相対的に強いから後側の筋肉を多用しようとして腰に負担がきているといった話しがある。姿勢を保つときに腹筋を使うように意識した方がよいといったアドバイスをトレーナーさんからもらった。

正史 諸葛亮孔明

「第四章 赤壁の戦い」を読んだ。

孔明が軍事の指揮をとるのは劉備の死後になるので、劉備の生前に起こった赤壁の戦いで伝えられる孔明の逸話は基本的にすべて嘘になる。演義では十万本の矢、東南の風、龐統による連環の計までもが創作らしい。赤壁の戦いの功労者は呉の都督だった周瑜の戦略によるもので戦う前から結果がみえていた。周瑜が用意周到に準備した戦略通りに魏軍がはまり、そこに周瑜の部下である黄蓋が提案した火計が成功をおさめたという。これはこれでおもしろくて戦いとはその前の準備の段階で決着がついているという見方ができる。周瑜は都督で全体の戦略を描くものの、実際の戦場における戦術は積極的に部下に任せるというスタンスをとっていた。また実際にはこれは大きな戦ではなく、小競り合いと決定打だとなった火計はあったものの、魏軍で流行した疫病による撤退というのが史実だと言えるらしい。演義における赤壁の戦いが大創作になっている背景として、三国志演義が編纂された時代 (実際の赤壁の戦いから千年後) にあった 鄱陽湖の戦い がモデルになっているのではないか。また孔明の神算鬼謀も朱元璋に仕えた 劉基 からきているのではないかという話しでもあるらしい。

0時に寝て3時に起きて2時間だらだらしていて6時に寝て7時半に起きた。ここ1週間ほどこういう寝方が続く。

運用対応の続き

昨日からまだトラブルが続いているらしく運用対応がてんやわんやになっている。私は本番環境のログもデータもみれないから社員さんから伝え聞く分しか状況がわからない。そのため、現状の運用でうまくいっているのかと思ってたら、たまたま他の要因が重なって発生しているのかもしれないけど、大きな障害に発展しているのかもしれない。従来の正しいと思われていた運用ツールにも誤りがあったらしく、これまでの運用は正しかったんやろか？という懸念も出てきた。スクラムマスターからも、既知の課題を放置してトラブルが常態化して運用対応に工数を割いて他の仕事ができなくなっているのではないか、仮説の検証をちゃんとやってないんじゃないかとかツッコミが入ってた。PO が未熟と言ってしまえばそうなのだけど、スクラムの悪いところは問題が起こっても責任の所在を曖昧に終わらせることがうちのチームでは多々ある。責任の所在をちゃんとふりかえらないと、再発防止やその対応に誰も責任をもたないという状況が発生する。今回のふりかえりがどうなるのかは来週にならないとわからない。ちゃんと反省してチームとしてふりかえりできるかどうかも観察してみようと思う。

次のお仕事探し

以前から勝手に私が応援している地元の会社の求人情報をみかけた。それは正社員しか募集していないのだけど、ダメ元で業務委託を雇っていないか問い合わせてみるかを迷っていた。そこで地元のコミュニティの知人が、地元の会社の中の人を知っていると話していたことを思い出して、その知人に業務委託で雇っているかどうかを試しに聞いてもらえるかを尋ねた。快く聞いてくれて、直接つながって問い合わせてくれて本当にありがたい。そしたら業務委託は採用していないらしいのだけど、一応は経歴はみるかも？といった返事だった。じゃあ、ダメ元で採用情報のページから応募しようかと考えていたら、その知人経由で経歴がわかるものがあったらそれでいいという話しになって linkedin と会社の事例紹介の url を転送してもらった。普通に応募するなら履歴書と職務経歴書をファイルで送らないといけない。仮に不採用になっても url を送るだけの手間しかかかっていない。わずか1時間ほどのやり取り。そう思うと人材求人プラットフォームに登録して、定型的な資料を用意して、手続きをとって、先方からの返信を待つといったワークフローはなんと無駄の多いことかとか考えたりしていた。

0時に寝て4時に起きた。5時からドラクエタクトしてた。

運用対応と遊休

今日も本番環境でトラブルがあったらしく、その対応で開発リーダーが忙しくて、お昼にあるチケットの仕様を決める小さい打ち合わせ (15分程度) を経て対応しようと思っていたのに、最終的にそれができたのは19時半になった。当然、実作業もやってない。昼間の3時間を休憩時間として別のお仕事をしていた。9月から新たにフロントエンド開発者が入って、チームの開発者が7人になって開発者が遊休する状態に拍車がかかった。本当はチームを分割すればいいけど、チーム事情でできず混乱している状態。権限委譲もできてないのでチームを任せられる開発者が他にいないのだと思う。人を教育せずに人数だけ採用して開発チームを拡充してきたのが垣間見える。古いプラットフォームの仕様を知っている人が1人しかいないといった状況は大変そう。そういう開発や組織を是としてきた先駆者の責任でもある。そんな組織の開発者が外部でいいことばかりを言っているのをみると、よい開発者が入ってきても騙されたと思って定着しないのではないかと思う。私がみえる範囲でもよい開発者がいないので組織における開発リーダーの重要性を実感する。

次のお仕事探し

たまたま求人検索していて Offers「オファーズ」 - エンジニア・デザイナーのための副業・複業・転職サービス というサービスをみつけた。ちょっと前に求人プラットフォームを開発していたのでいくつかの求人サイトに登録して調査したりしていた。その中でもこのサイトは上位に入る優れた品質だと思う。一番嬉しいのが職務経歴を linkedin からインポートしてくれる。求人プラットフォームでもっとも嫌なことは、それぞれのサイトごとに職務経歴書を作らないといけないところ。プログラマー的に同じ作業を何度も繰り返すことに苦痛を感じる。比較的新しいサイトなのでどういったものか、わかっていないけど、サイトの使い勝手がよかったので縁があれば面談もやってみようと思う。

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

バッチ処理一覧と手動実行

2週間前からフロントエンドの画面作りを始めた。2つ作らないといけない画面があってそのうちの1つを作るのに1週間ちょっとかかった。最初に作る画面で次の順番で作業を進めた。

1. web api のエンドポイントの整備
2. ページング処理
3. 検索フォームのコンポーネント作り
4. v-data-table の slot 埋め込み
5. モーダルダイアログと更新処理

やりたいところに関係する vuejs, next, vuetify の機能を調べたり、イベントの伝搬の仕組みを調べたりしながら作成した。一度理解したら簡単なので2つ目の画面は半日で完成して pr を出して、もうそのまま本番環境にデプロイした。1つ目の画面の方が要件が複雑で2つ目の方が簡単だったというのもあるけど、どちらもストーリーポイント5が割り当てられているチケットの作業工数は1週間強と4時間といったものになった。なんというか、ストーリーポイントは中長期でみれば、このような人間が成長して一定期間内に消化できるポイントが増えることを計測する狙いもあるけれど、短期でみたらまったくプロジェクトマネジメントには役に立たない。

最近フロントエンド開発者がチームに参加して、コードを読んだらだいぶひどいみたいなことを言ってた。開発リーダーもフロントエンドは基本的に動いたら OK とか答えてた。だから品質が悪い。

コワーキングのオンラインイベント

先日 カフーツさんのイベント のイベントに参加した。それがきっかけとなり、いとうさんが手掛けている Beyond the Coworking 〜移働の時代〜 という note のメンバーシップという有償コミュニティのようなものに入ってみた。記事を読むだけなら1,000円/月で、それ以上の付加価値サービス向けに2,000円/月という料金設定になっている。毎月 zoom でオンラインミーティングを行うというので参加してみた。いとうさんは少し前にコロナに感染して療養していたそうなので日程が急に決まったせいか、たまたま私しか参加者がいなかったので1on1みたいな感じで雑談した。コミュニティを運営するためのサービスとして何がいいかという話しをしたんだけど、たしかにこれとお勧めできるものがない。note も最近そういった機能を追加して sns になろうとしているように垣間見える。

• note のコミュニティ機能とメンバーシップ
  • 試しに掲示板を使ってみているが、メンバーはほとんど書き込まない
    • いとうさんと私しか、ほとんど書き込みしていない
    • 但し、メンバーに質問していると掲示板をみてはいるという
  • 掲示板はストックのサービスだからリアルタイムに返信をもらうことをそもそも期待していない
  • リアルタイム性の高いサービスならチャットツールがよいのではないか？
    • slack, discord, ms teams など
  • 他のツールもどうか？
    • note の掲示板, notion, trello など

他にもコワーキングスペースをうまく運営するためにはコワーキングスペースマネージャーが必要だといとうさんは考えている。コミュニティマネージャーはコミュニティ形成を目的とするが、コワーキングスペースマネージャーは似て非なるものだという。あれもこれもできないといけないという話しをしてたら、基本的にスーパーマンを要求するポジションになるみたいw、とはいえ、求められる能力として3つをあげると次のような話しをされていた。

• 利用者と話しができる
  • 利用者の居場所になるには、利用者の業界や業務をある程度は理解して話せないといけない
  • コワーキングだから協調のためにお互いの相互理解が必要になる
• 人の紹介ができる
  • コワーキングだから協調のために利用者同士、または自身の人脈からマッチする人を紹介できないといけない
• 仕事の斡旋ができる
  • ビジネスなので仕事を依頼したい人、仕事を受けたい人、仕事 (お金) がまわらないと継続できない

カフーツさんはうちのオフィスから一駅、自転車で10分の距離にオフィス兼コワーキングスペースがある。1人でお仕事をしていると相談相手がいないことの弊害 がある。身近に信頼できる相談相手がいることは重要だと思う。今後もビジネス寄りのコミュニティやコワーキングの在り方を学んでいこうと思う。

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

slots で v-data-table のカラムを書き換える

昨日の続き。v-html で v-dta-table のカラム書き換えしてたら slots でやれと言われた続き。次のようなテンプレートのコードでカスタムカラムを配置するためのコンポーネントを作れば既存の vuejs の仕組みで保守もしやすそうに思う。

<my-wrapping-data-table>
  <template #[`item.data`]="{ item }">
    <my-custom-cell-layout :item="item" />
  </template>
</my-wrapping-data-table>

vuejs のテンプレートのこの構文はどういう評価をされるのかが理解できない。

<template #[`item.data`]="{ item }">

そしたら同僚がそれは次の構文のシンタックスシュガーだと教えてもらった。いずれにしても dsl 万歳って感じで私からは訳がわからない。雰囲気でテンプレート書いて動けばいいんだけど。

<template v-slot:`item.data`="row">
  <my-custom-cell-layout :item="row.item" />
</template>

その後、要素の更新処理のモーダルダイアログ画面も作って1週間以上に渡って開発していた画面を一通り作り終えた。vuejs のことわかってない素人でも雰囲気だけで動く画面は作れた (pr のときにほとんどレビューで指摘を受けなかったので大半は間違ってはないのだろう) 。簡単と言えば簡単ではある。ちなみに私が作ったものが初のページング可能な一覧画面になる。検索フォームもページングに連動してクエリを実行できるようにすべてフルスクラッチでコンポーネントを作った。

0時に寝て7時に起きた。また日曜日は寝てた。

任意のカラムの書き換え

v-data-table の、あるセルが複雑なデータをもっていて、単純にその値を表示するのではなく、一定の構造化やレイアウトを調整した状態で表示したい。セル内の構造を書き換える方法を私は知らなかったので v-html という api を使って書き換えればよいのだと思った。しかし、これは間違いだった。間違いの訂正は翌日にやるとして仮に v-html を使うとしても xss の懸念があるのでスクリプトをエスケープしてあげないといけない。Sanitize v-html #6333 でも議論されていて vue3 はデフォルトでエスケープする仕組みが入るのかな？vue2 だと sanitize-html を使って次のようにラップすればいいと書いてあった。実際に動かしてみるとスクリプトを実行できたので v-html は危険だというのはわかった。

<div v-html="$sanitize(value)" />

この仕組みを作って pr でレビューしてもらっていたら、カラムの構造を書き換えたいだけなら slots を使えば普通にできると教えてもらった。また明日へ。

昨日は深夜も夕方もたくさん話して疲れたのか、ブログを書こうかと考えていたけど面倒になって休んでた。

ストレッチ

今日の開脚幅は開始前155cmで、ストレッチ後161cmだった。開始前の数値が悪いけど、とくに調子が悪いというわけでもなかったので計測の仕方がよくなかったか、たまたま足の開き方が悪かったかといったところだろう。昨日、高級時計と投資の話しを聞いたのでトレーナーさんとお金があったら何に使う話しが盛り上がった。トレーナーさんも庶民的な方でとくにお金があっても贅沢をしたいというものでもないらしい。私も改めてお金があったら何がしたいかを考えてみてもお金を使ってやりたいことはとくにないなというのが率直な思いでもある。私には自分がやったことのないことをやってみたいという思いしかなく、そのためにお金を使ってきた側面も多々あるけれど、お金を直接的に使って何かをやるというよりも、生活できるだけのお金があれば、その時間に自分がやったことのないことに挑戦して人生を楽しむということぐらいしかやることはないんだなと、トレーナーさんと話していて考えたりしていた。

os 雑談

午後から昨日の障害のふりかえりといくつか調査をして、夕方におがわさんに声をかけたら話し相手になってくれると返ってきた。障害のふりかえりをした後に課題管理の雑談もしていて4時間弱ぐらい話してた。私自身、反省しないといけないとは思っていたのでおがわさんはちゃんと指摘をしてくれた。この歳になると私を叱ってくれる人はいない。たまに失敗したときにおがわさんに話して然るべき指摘をしてもらえるのは本当にありがたい。

kubernetes がどうやって動いているのかを理解して運用しているのか？

コンピューターがどうやって動いているのかを理解しているのか？

私が未熟で理解できていなかったからこんな障害を見過ごしていた。システム障害が発生しても人生は終わりじゃない。反省してから次につなげる。おがわさんと話していて、os の仕組みや機能についていくつか教えてもらった。

• 制限対象の違い
  • ulimit はユーザーに対する制限
  • /proc ファイルシステムはシステムに対する制限
• /proc/sys/kernel/pid_max は kernel のデフォルト値として 32768 が設定されているが、systemd を使っていれば値を変更している場合がある
  • 私の ubuntu マシンだと 4194304 が設定されていた
• コンテナ内から /sys/fs/cgroup/memory/memory.usage_in_bytes をみると、コンテナが使っているメモリ量なのか？
  • cgroup の使い方次第で変わる、システムの値かもしれないしコンテナの値かもしれない
• ゾンビプロセスに残っている情報は親プロセスが子プロセスの統計情報を取得するために必要なもの
  • どんな子プロセスも一時的にはゾンビプロセスになる
  • kernel の task_struct 構造体やその他の構造体、リンクしている情報などをすべて足すと1つのゾンビプロセスが10数 KiB 程度ではないか
    • 仮に 15 KiB として 32000 個のゾンビプロセスがあると約 469 MiB のメモリ量になるのでだいたい数字があう
• ユーザー空間とカーネル空間の違いを理解できるようになった方がよい
  • システムコールの fork がエラーになるのはシステムがおかしいとすぐに気付けるはず
    • fork がエラーになる原因として考えられるのはメモリを確保できないか、pid_max に達したか、いずれにしてもエラーコードをみれば推測がつくのではないか
• 環境にログインできるのであれば strace を使えば障害調査に役立つ
  • 私が普段使っていないツールなので障害のときにとっさに扱えるよう練習しておく

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

eks クラスター障害の原因判明

過去に2回発生していた eks クラスター障害 の原因がようやくわかった。テスト環境も本番環境は5日ごとに再現していて、datadog で k8s のダッシュボードでそれぞれの pod 単位のメモリ使用量をみると datadog-agent の pod がメモリリークしていることに気付いた。そこから当たりをつけて datadog-agent の issue を調べると次のバグに遭遇していた。

• [BUG] agent leaves defunct processes with version 7.38.0 #12997

ゾンビプロセスが生成されて、それが os のプロセス数上限に達してしまい、それによってプロセス (スレッド) が生成できなくなって、その結果として aws/amazon-vpc-cni-k8s の aws-node という eks クラスターの管理アプリケーションが動かなくなって、それが動かないと k8s ノードのステータスが NotReady になってしまって、通常の pod のアプリケーションも動かなくなってしまうという現象が発生していた。datadog-agent のアップグレードは私が行ったものだし、その後の k8s ノードの監視や調査で気付きが足りなかったと反省した。

• datadog-agent の新しいバージョンをテスト環境でもうしばらく検証してもよかった
• datadog-agent をリソースリークの可能性を私の中の調査対象から外していた
  • 世の中で使われているものに致命的なバグが起きないだろうという先入観があった
• プロセスを生成できない原因として考えられる背景を調査すべきだった
  • ulimit を確認してリソース制限はないようにみえた
  • プロセス数やゾンビプロセスを調べていなかった
  • kernel に /proc/sys/kernel/pid_max という上限設定があることを知らなかった
• テスト環境と本番環境で5日程度で落ちるという周期性から気付くべきだった
  • たしかにテスト環境から1日遅れて本番環境で障害が発生していた
  • 周期性があることでリソースリークの可能性は高いとすぐに調査すべきだった
• datadog で k8s のダッシュボードを調べるべきだった
  • すでに用意されているものがあったのでみようと思えばみえた
• aws のインフラ要因ではないかと疑っていた
  • ごめんなさい

これは悔しい。自分の無能さや気付きの低さを実感した事件だった。私が注意深く観察していればもう1週間早く気付けた。そのせいで余分な障害と調査に時間を費やした。1つ1つは全く難しくない現象が巧妙に絡みあって隠蔽された結果としての状況に気付けなかった。注意して1つずつ観察して追跡していけばすぐに気付けた。本当に悔しい。

1つだけ言い訳をさせてもらうと、私は本番環境にアクセスできない。だからテスト環境と本番環境で発生している現象が同じかどうかを判断できず、調査を進める確証をもてなかった。

呑み

あまりに悔しかったのと調査してたら遅くなって晩ご飯食べる気力もなかったので気分転換に仲のよい焼き鳥屋さんに寄ってみた。あとから常連客のセブンイレブンの店長さんも来られて、私は初対面かなと思ってたんだけど先方は知っていると言ってたから以前にもカウンターでご一緒していたみたい。何気はなしに3人で2時前ぐらいまで雑談していた。

その店長さんがロレックスを購入しようと考えているという話しになって、資産または投資商品としてのロレックスの話しになった。たまたまヒカキンが1億円で買ったロレックスがいま2億円になっているといった話しがあったそうで、いまがバブルな状態らしいが、ロレックスをはじめとした高級時計の資産価値が上がっているらしい。私は腕時計を身につけないし高級時計もまったく興味はないが、投資商品の1つなんだというところに関心がもてた。

中小企業の社長の一般的な節税方法の1つに外車を買ったり売ったりするという話しがある。儲かったときに経費で外車を買って、赤字のときに外車を売って雑所得に変える。車は社用車として経費で落とせるから可能なことだが、高級時計はどうなのだろうか？ 結論から言うと、普通の会社では高級時計は経費にできない。経費の原則は売上を上げるために必要な支出を経費とできる。普通の会社は高級時計で売上を上げることはできない。一方で経費として認められる職業もある。芸能人がそうだという。それは番組のために必要だという理屈で経費で落とせる。おそらくヒカキンも経費で高級時計を購入して、そのことを動画にしているのも仕事で必要だという言い訳作りの目的もあるのだと推測する。

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

vuetify で検索フォームのコンポーネント作成

ページング処理ができた。次に検索リクエストのための検索条件を扱うフォームを汎用コンポーネントで作ってみることにした。コンポーネントを生成するための検索条件のオブジェクトを外部から渡して、あとはよしなに grid に構成要素を配置する。v-date-picker のところは本当はもっと凝った作りをしないといけない。ここでは型で分岐してコンポーネントを配置する概念を表しているだけ。v-col は cols は1から12までの数字を受け取る。この数値を調整して v-spacer を入れることで行の位置調整もできるのがひと工夫しているところ。イベントハンドラーは click:search とか click:searchClearのように名前を付け替えて、外部から意図したイベントのみをフックできるように考慮している。

<template>
  <v-container>
    <v-row dense>
      <v-col v-for="item in conditions" :cols="item.cols" :key="item.label">
        <v-switch
          v-if="Boolean === item.type"
          v-model="item.value"
          :label="$t(item.label)"
          :clearable="true"
        />

        <v-text-field
          v-if="String === item.type"
          v-model="item.value"
          :label="$t(item.label)"
          :clearable="true"
        />

        <v-text-field
          v-if="Number === item.type"
          v-model="item.value"
          type="number"
          :label="$t(item.label)"
          :clearable="true"
        />

        <v-date-picker
          v-if="Date === item.type"
          v-model="item.value"
          :clearable="true"
        />

        <v-spacer v-if="null === item.type">
          <!-- use an empty block for grid layout -->
        </v-spacer>
      </v-col>
    </v-row>
    <v-row>
      <v-col cols="4">
        <v-btn
          v-text="$t('label.clearSearchCondition')"
          @click="_searchClear"
        />
      </v-col>
      <v-col cols="3">
        <v-btn color="primary" v-text="$t('label.search')" @click="_search" />
      </v-col>
    </v-row>
  </v-container>
</template>
<script lang="ts">
import { PropType, defineComponent } from '@vue/composition-api';
export interface SearchConditionItem<T = any> {
  type: PropType<T> | null;
  name: string;
  label?: string;
  col: number;
  value?: any;
  fromValue?: string | null;
  toValue?: string | null;
}

export default defineComponent({
  components: {},
  props: {
    conditions: {
      type: Array as PropType<SearchConditionItem[]>,
      default: () => [],
    },
  },
  setup(props, context) {
    return {};
  },
  methods: {
    _search(value: any) {
      this.$emit('click:search', value);
    },
    _searchClear(value: any) {
      for (const c of this.conditions) {
        c.value = null;
        c.fromValue = null;
        c.toValue = null;
      }
      this.$emit('click:searchClear', value);
    },
  },
});
</script>

呼び出し側ではこんな感じ。任意の conditions を渡し、検索ボタンをクリックしたときのイベントハンドラーを登録する。

<search-condition-form
  :conditions.sync="searchCondition"
  @click:search="search"
  v-on="$listeners"
/>

vuetify で初めてコンポーネントを作ってみた。雰囲気だけで実装している個人的な所感だけど、template, script, style を1つのファイルに同梱する考え方が私には馴染まない。1つのファイルに複数の構文が混在する認知負荷が気になるのと、1つのファイルに複数のコードを同梱しているメリットが私には感じられない。もしかしたら小さいシンプルなコンポーネントなら見通しがよいのかもしれない。しかし、業務での開発だと一定の複雑さをもつコンポーネントの方が大半だと思うので1ファイルが1画面におさまらない。どうせエディターを画面分割して複数画面でソースを読むのであれば、その画面のソースが1つのファイルでも別のファイルでも私にとってあまり大差ない。ファイル間の依存関係さえ適切に管理できればファイルは用途ごとに分割できた方が人間にとってわかりやすいのではないかとも思う。一方でフレームワーク側からみたら依存関係の解決はやや煩雑な処理になるので開発や依存管理がシンプルになってビルドが速くなるといったメリットがあったりするのかもしれない。どうなんだろう？