1つのPRをレビューしてる間に手元に2つのパッチが増えるので、手元のパッチが増え続けるという...
posted at 15:08:10
| Stats | Twitter歴 5,105日（2009/06/15より） |
ツイート数 78,835（15.4件/日） |
表示するツイート :
2023年04月04日(火)1 tweetsource
2023年04月03日(月)3 tweetssource
@bikun_bikun 証跡は残るけど、レビューできないので代替にはならない...
posted at 18:58:22
仕事の進め方を色々と変えてみる。今までのやり方が現職にあってなさそう。
posted at 16:11:54
AWSコンソールを使う作業はレビューも記録も残らないので、仕事では基本NGだと思っているけど、人によってわりと認識が違いそう。
posted at 13:49:22
2023年04月01日(土)4 tweetssource
天気が良い☀️
posted at 11:21:47
春問題にウェブサイトのリニューアルの問題あったら面白いのになぁ
posted at 11:21:04
秋試験の午後で使うための渾身のネタ作りと思うかのようなリダイレクト対応漏れ https://twitter.com/ipajp/status/1641644238315347968…
posted at 11:16:11
エイプリルフールだから何か嘘つきたいけど、普段は嘘をつかず、品行方正に過ごしているから、何も嘘が思い浮かばないなー
posted at 10:45:06
2023年03月31日(金)3 tweetssource
見積りについて考えたけど、チームが顧客の満足する成果を定期的に出せるなら、見積りは要らないのでは。
顧客の欲しい価値を整理して、優先度で並べた上で、これを定期的に届けることだなと。
posted at 16:39:18
ソフトウェア開発の見積りについて思案してたけど、見積りの精度が上がれば上がるほどに各開発者の処理能力が可視化されるわけで、これはこれで厳しい世界な気がしてきた。
posted at 11:35:59
桜を観にきた。良い🌸 https://pic.twitter.com/1c5EWyPizU
posted at 09:50:20
2023年03月30日(木)17 tweetssource
あくまで仮説で、本当に上手くいくかは分からん
posted at 20:25:26
GitHubで管理されているものは、そのリポジトリのIssueで管理するのが1番良いという仮説がある。テンプレを用意した上で、CSも営業もGitHubにIssue切る運用。
posted at 20:25:10
プルリクのApproveやマージの気持ちも人によって変わりそう。個人的には「マージの利点が納得できて、メンテする覚悟を持てる」ものにApproveしたいと思ってる。
posted at 19:58:27
@luccafort Request changesは「マージしたくない」ときで、Commentは「このコードの責任をもてない(メンテし辛い)」くらいの気持ちで使い分けていますねー
posted at 19:55:00
レビュワーのApproveなしのコメントは暗に「私のApproveが欲しいなら、納得いく説明やコードの変更」を求めているのと同じだと思ってるけど、この辺りの感覚はわりと人によって異なりそう。
posted at 19:49:56
あれ、今まではあまり脳を使わずに仕事を…
posted at 19:29:51
この時間になると頭痛が酷いので、仕事で脳を酷使してる感ある。
posted at 19:29:13
後者は貴重なリソースである開発者のやる気を高く保ちやすい。
posted at 17:44:42
バッグログを作って優先度の高いものから実行するのもアリだけど、開発者が好きな順番で改善するのもアリだと思っている。この辺りはチームの戦略次第。
posted at 17:43:28
今までコピペエンジニアにも「自然言語を読んで選び取る」という価値があったが、Copilotが上位互換になりつつある。
posted at 16:13:35
GitHub Copilotがすごいと思うけど、Copilotが生成したコードを理解せずにそのまま使う人はそのうち職を失うだろうなとも思う。
posted at 16:13:35
@Akira_Akagawa 「属人的なあの人」が山頂で休むわけもなく、彼らがヘリコプターとかで更に上に上がっていて、空を飛ぶ覚悟がいるケースもある。
posted at 14:36:36
@tdakak そこも含めて人間で、人間が上手く働いて成果を出すのが仕事なので、相手の気遣いが低いなら自分が譲歩して成果に繋げられないか...みたいな考え方をするようになってきました。
posted at 10:50:17
エクセリオンバスター打った後のなのはさんの気持ちになっている。力が足りない...
posted at 09:53:57
@bakueikozo 自宅の🔑が無いのはすごい。
ただ、そこの連携だと自宅と外出の区別なので顧客の要件を満たせるか怪しいので難しそう。(ハードオフにいるのが分からなそう)
posted at 09:35:39
AirTagを自宅キーにつけるのが楽そう https://twitter.com/bakueikozo/status/1640945657946198016…
posted at 09:21:50
AIの開発者に何も利がないので、こんな提案が通るわけない https://www.itmedia.co.jp/news/articles/2303/29/news180.html…
posted at 08:32:04
2023年03月29日(水)19 tweetssource
typo: chor -> chore
posted at 17:15:50
機能要望(feat)とバグ(bug)は起票しつつ、雑用(chor)は一切起票しないくらいが良かったりするのかな🤔
posted at 17:15:06
Issueの粒度は技術力に依存する気がしていて、人によって簡単に終わる(起票するまでもない)範囲が違って合わせるのは難しい気がする。
posted at 17:15:05
@pgm_shikata Oliveは別で発行されますよー。
ただ、今持ってるクレカがキャッシュカード一体型の場合は、そっちが解約されるので注意がいる。
posted at 16:34:07
そのIssueからバグを直すプルリクを作るGitHub Copilotも一緒に...（強欲)
posted at 14:33:50
Twitterのハッシュタグで投稿されている内容からプロダクトのバグを見つけてGitHub Issueに起票するAI欲しい。
posted at 14:32:27
Issueを書くよりもSlackで質問する方のハードルが低いのはたしかにある。ChatGPTがSlackの会話からプロダクトの課題を見つけて、良い感じにIssueとして登録してくれないものか...
posted at 14:31:33
Slackで質問ではなくて、GitHub Issueに「プロダクトの課題」として起票するのが良い気はするものの、そういう環境を整備するのがまず難しそう。
posted at 14:31:33
@kameike まぁ、最初にWhyを適切に書くのが難しいのですが...。ただ、Howは相手に出してもらいたいし、進捗（終わりそう、ヤバそう）も相手に判断して欲しくて、こっちで「ヤバそうと判断して助ける」をすると相手の判断力が高まらないかなと。
posted at 14:20:28
@kameike タスクに関してはWhyと期限をいくつか切って任せるのが良いのかなと思っています。
最初の期限で大まかな方針を出してもらって、次の期限で...と複数のチェックポイントを設けて、それ以外では相手を信頼して一切の口を出さない方が委譲できそう。
posted at 14:18:35
@kameike うまく仕事を分解して、リスク低い部分から少しずつ任せると良いんでしょうね...私もできてないですが...
posted at 10:32:09
@haradakiro 抱えたタスクが後で膨らんで、動きづらくなるケース多いですね...
posted at 10:28:12
仕事を委譲するにも工数がかかるので、普段から委譲できるように仕事を進めるのが大事そう。タスクを抱え込み過ぎると委譲するための時間まで無くなる。
posted at 10:12:24
「もう少し頑張らないとだね」「全力全開」「アクセラレーター！」
posted at 09:34:23
先週末になのはDetonationを観たばかりなので、考え方がなのはに染まってる。
posted at 09:33:06
仕事の手が回ってない感あるけど、チケット書くのも時間かかるわけで、結局は速度を高めるという身も蓋もない結論。
posted at 09:31:30
民主主義的な進め方はメンバーの納得感や属人性の排除を重要視していて、必ずしも成果のために実施してないと認識してる。
posted at 01:44:11
ジムに行かねば…という気持ちはある
posted at 01:10:55
ジムの会員費を払ってるだけでは体重は落ちないし、筋肉もつかない。
posted at 01:10:28
2023年03月28日(火)8 tweetssource
AWSが🍞を焼くサービスを提供すれば…。basic bake bread(Amazon B3)は柔軟性と保温性に優れた美味しい🍞を(以下略 https://twitter.com/toricls/status/1640602097124245505…
posted at 15:42:12
AWSの魔物をTerraform Importで封印する仕事
posted at 15:11:56
コンフリクトしないのが自分にとっては楽だけど、どのPRがいつマージされるかも分からないし、色んな人が改善を容赦なく投げるのもそれはそれで良い気もしてきた。
posted at 13:45:58
ただ、最近は blame.ignoreRevsFile あるから、cosmetic changesのリジェクトは緩和される余地はありそうな気もする。
posted at 13:16:23
改めてRailsの「課題はIssue、機能要望はプルリク、cosmetic changesはリジェクト」は理にかなってる運用だなと思う。
posted at 13:14:25
@chiastolite 全PRを見ていれば誰が、どの辺りのコードを触っているのか分かるので、その近辺を変更するPRは後回しにする感じでしょうか。
RuboCopのStyle/StringLiteralsのような優先度の低い、しかし広範囲を変更するcosmetic changesは特に考慮していると嬉しい。
posted at 13:09:14
わりとコンフリクトするプルリクを作られることが多くて、たぶん他の人のプルリクを読んでる人が少ないんだろうなぁ...というのを感じる。
粛々とリベースして直すわけですが。
posted at 12:46:04
プルリクのタイミングを考えて出して欲しいと思うのは他人に求めすぎなんだろうか...。自分が全てのプルリクを見た上で、できるだけコンフリクトしないように作っているので、それを他人にも求めてしまう。
posted at 12:31:00