t_wの輪郭

https://fj.hatenablog.jp/entry/2014/10/13/183259

https://flowthink.jp/thinking/odsc/

　アイデンティティと成果物を紐づけないようにするというのはよく言われるが、なかなか難しい。5年ほどITエンジニアをしているが、それでも成果物に指摘（ダメ出し）を受けるとダメージを受ける。
　とりあえずコードレビューする側が「shit」とか「クソコード」みたいな侮辱する言葉を避けるのは効果があると思う。こうしたダメであることしか示さない言葉を避け、もっと具体に踏み込み、「この個所をこのように変更するとこういった利点がある」といった指摘にできれば良い。簡単な言い換えでWinWinにできるはずだ。

教育者が可能な批判は行動への批判

　行動への批判のみが可能であるという情報をもらった。コードを書く際のやり方に対して指摘ができればいいのだろう。行動への批判は以下の点で利点がある。

• 行動の変容により、成果物の品質が長期にわたって向上する
• 成果物への批判よりも人格攻撃の度合いが低い（教育から見たクソコード批判の問題点を読むにそういうことだと思うが、まだ十分に理解できていない。要調査。）

　具体的にできそうな、コードを書く際の行動への批判については、以下ができそうだ。

• 静的解析ツールを使う
• UMLで設計してからコードを書く

　成果物の問題点から行動の問題点を逆算し、実際に行動を観測し、それを指摘できれば良い。

過去に成された議論

• 『"クソコード"は人格攻撃ではないのか』
• 『クソコード批判とクソコード批判批判はなぜ燃えるのか』
• 『ポール・グレアム「アイデンティティは控え目に」』

2022年8月7日

朝からElevated accessの申請をした。

うおおおおTwitter APIでTwitterに自動投稿できるようになった！！！
やっと更新通知（と呼んでたけど記事が一定数閲覧されたらTwitter APIでTwitterに投稿）する機能を実装できるぞ！！！

記事が一定数閲覧されたらTwitter APIでTwitterに投稿する機能を実装した。

リリースした。

トークンとかの格納に.envを使っているのだけれど、これがrsyncすれば開発環境から本番環境に反映されると思っていて、本番環境でエラーを起こしていた。

2022年8月6日

Twitterへの自動投稿はめんどくさかった
ブログ更新したらTwitter APIで自動投稿したいとか考えてたけど、思ってた100倍ぐらいめんどいことが分かった

めんどくさい理由：

• 投稿に使うtokenが有効なのは2時間だけ
• refresh_tokenを使えばtokenの再取得ができるが、その際にrefresh_tokenも新しいものが払い出され、古いrefresh_tokenは利用できなくなる
• 故に、DBにrefresh_tokenを入れておく必要があり、さらに常に有効であるかに気を配る必要がある
• refresh_tokenが無効化した場合には、DBを触ってrefresh_tokenの入れ直しが必要

OAuth2.0だとめんどくさいらしく、OAuth1.0aを使った方が良いとSNSで情報をいただいた。ただ、OAuth1.0aの投稿APIはElevated accessが必要とのこと。

twitterAPIはoauth1.0aで使うのがオヌヌメ

oauth2.0はリフレッシュトークンの管理がめんどい

OAuth1.0が一生うまくいかん。
ブログ更新ツイートぐらいだったら手動でやればいいやという気持ちになってきたけど、それはそれとしてOAuth1.0に負けるわけにはいかない。

あきらめてライブラリ使ってもいいですか。

力尽きた。

丸一日OAuthに捧げたけど成果物は何もないし、いまだにAOuthって書きそうになる

①ステークホルダーモデル
②ビジネスコンテキスト
③業務フロー
④ビジネスユースケース(UC複合図)
⑤情報モデル図
⑥状態モデル図
⑦バリエーション・条件定義

　ダメ出し受けすぎてやる気が出ない。石を積んでは壊される気分だ。学習性無力感というやつだろうか。「何を作ってもどうせダメ出しを受けるんだろう」という気持ちになっている。ダメ出しを受けない時は特に何も言われないので、「仕方ねーな」みたいな雰囲気がある。ダメ出しすることに快感を覚えてないか？人を劣位に置くのは快感がある。私にも覚えがある。

　ダメ出し最小化を目指すと、作業量最小化につながってしまう。作業量を確保するには私自身の捉え方を変える（考え方の転換）しかなさそうだ。
　ダメ出しのダメージを受けないように成果物と精神を分離すると、「自分事で考えろ」なので、なかなか難しい。
　逆に、ダメ出し最大化を目指すのはどうだろうか。と思ったが、低品質な資料を作りまくってしまうだけになりそうだ……

　社長という役職も褒められることがないらしい。大変な役職だ。何をモチベーションにして頑張っているんだろうか。

開発費用の2/3が勉強代

　作業を後から成果物だけ見返すと、半分以下の時間でできるように見えるやつだ。試行錯誤に時間とお金がかかる。
　試行錯誤の時間を見積もらず、成果物だけから見積もりをすると足元をすくわれる。

　自分の作業量をいい感じのところにとどめるために、作業量の見積もりの導入をしたいが、見積もりをする作業がめんどくさい。見積もりをしたところで成果物が明確じゃないからずるずる伸びてしまうのも気がかりだ。先に作業完了の基準を定めるところからかもしれない。
　とはいえ、「作業完了の基準を満たしたからこれは完了です！！」と言って要望を突っぱねるのも引っかかるものがある。成果物ができてからの変更要望にこそ、作業依頼者の本意が宿っている気がする。

焦燥に駆られて求められてもない成果物を出すか、決意を決めて本を読むか

仕事の進みが悪い。特に期限のある作業もない。ざっくりした調査を頼まれているぐらい。何か成果物を出していないと不安になる。自分に存在意義が無いと感じてしまう。仕事中毒なのかもしれない。