たまに使うんだけど、順番を毎回ググって確認していた 2>&1 というリダイレクト処理がある
いままで
command >> word 2>&1
という書き方で、標準出力、標準エラー出力をリダイレクトしてきたが、
実は bash 4.0 から以下のような記載ができるようになったようだ。
command &>> word
man コマンドで bash を見ると以下のような記載がある
The format for appending standard output and standard error is:
&>>word
This is semantically equivalent to
>> word 2> &1
https://www.gnu.org/software/bash/manual/html_node/Redirections.html
これは便利なので活用していきたい。
参考情報
業務をしていたプロジェクトリーダーを努めさせてもらった一年半の長い長いプロジェクトがようやく終わりを迎える。
振り返ってみたら、不確実性との戦いだった。手探りにプロジェクトを進め、ひっくり返ることもあった。
不確実性との戦いは今回担当したプロジェクト特有のものではない。おそらくきっと、人生につきまとってくるもののひとつだ。
それであればこの機会に不確実性についての取り扱いについてきちんと学びたいと思うに至った。
そこで ヒロキさんの Qiita にたどり着いた。
トム・デルマコの著書はとてもいい知見に溢れているものの、自分からしたら比喩がわかりにくいこともあり、あまりすすんで読もうとはしてこなかったが、
知見を得たいとの一心で久しぶりに トム・デルマコ本。 ピープルウエア を読むことにした。
一言で言うと、この本は不確実性を直接対処するものではなく、生産性の高いチームを育てることで不確実性にも対応できるようにするといった本だ。
個人的にはここで挙げられている項目が現在の自分が考えていた感覚とドンピシャだった。
７つ記載があったが、その中の３つがとても良かった。
人が楽しいと思える仕事に必ず「挑戦」がある。
挑戦はチームのメンバーが一緒になって努力する目標が与えられるからこそ必要になる。挑戦は時にチームを一つにまとめる道具になる。最良の仕事仲間を持った時、人は愉快な気分になるものだし、力を尽くす。その時チームの相互作用がフルに働く。この瞬間、メンバーも楽しいと感じる。
チームが結束し始めると、成功の確率はぐんと高まる。このフェーズに入ったチームを率いることはリーダーとしての楽しみにもなるようだ。
結束の強いチームの特徴として、退職率の低さがある。
チーム編成を妨げ、プロジェクトを崩壊させる確実な方策与えられた仕事をこなす能力が部下にない場合、プロジェクトは失敗する。
しかし、与えられたグループでやっていこうと一旦決めたなら、最良の戦術は部下を信頼すること。
部下を信頼する代わりに、プロジェクトの成功を保障しようとして自己防衛の手段をとれば事態は悪化する。
「管理」などないかのように、チームが和やかに一致団結働かせることができる人。
管理されていることを部下に気づかせずに、そんなやり方を繰り返しやれる人。
この本が書かれた時と時代は変わり、リモートワークが定着したことでオフィスに全員が出社する頻度はかなり減った。本書ではオフィスの環境についても書かれてあったが、そこはざっと読んだだけで、ほとんど読み飛ばした。
ここの部分はリモートワークについて語ってる Youtube大学で語っていることを取り入れることにした。
時代は変わってもチームビルディングについてのポイントは変わってない。
名著から学ぶことは多い。
API gateway にinsert する際、エラが発生
Your API was not imported due to errors in the Swagger file.
Unable to create model for 'user_id': Model name must be alphanumeric: user_id
Unable to create model for 'staff_id': Model name must be alphanumeric: staff_id
これは正規表現でいうところの
[a-zA-Z0-9]+
のみ model name としての利用を許容しており、アンダースコア含めた名前は API gateway に許容されていないため。
swagger としては アンダースコアが利用可能なので、API gateway も許容してもらいたいところだ。。
以下のように対処する
paths:
/hoge:
post:
requestBody:
content:
application/json:
schema:
type: object
properties:
booking_deadline:
$ref: '#/components/schemas/hogeline'
components:
schemas:
Event:
type: object
properties:
hoge_line:
$ref: '#/components/schemas/hogeline'
誰も正解を持っていない中プロダクトを開発しなければならない。不確実性との戦いである。
情熱を科学で支える。データ駆動戦略とは、データを駆動させることで事業の優れた価値を見つけ、組織がデータを中心に意思決定する世界。このゴールのイメージがとても重要になる。
本書ではデータ駆動する上でスクラムなどの開発手法の話にも言及があるが、その辺はすっ飛ばして、あくまでも”データ基盤” を作る上で必要な情報のみまとめる。
データ駆動戦略を用いた事業の捉え方と、プロセスは以下の順番を遡ると説いている。
データ基盤を作る上では、まずはデータを集約することが第一歩にな理、データパイプラインが必要になる。
データ集約は組織全体で行わないと効果が限定的になり、局所最適化になってしまう。