問題の原因も解決法も分かるけど、それを直す権限を持ち合わせていない。
posted at 18:02:19
| Stats | Twitter歴 5,225日（2009/06/15より） |
ツイート数 79,394（15.1件/日） |
表示するツイート :
2023年10月03日(火)3 tweetssource
自分が何もしてなくても、社内でRails v7.1対応が進んでいる。良い。
posted at 10:17:03
AWSのコスト削減は元がダメであるほど簡単に削減できる上、費用が定量的に変わるので評価されやすい特性がある印象。
posted at 09:28:22
2023年10月02日(月)6 tweetssource
一般的な性癖で何より https://anond.hatelabo.jp/20231002153144
posted at 20:29:26
なんか悩みことが多過ぎて人生の難しさを感じる。
posted at 17:10:18
それな
"怒られるくらいならスルーしちゃってもいいか。評価にも影響したら面倒"
posted at 14:43:06
最近の風潮だと厳しいことは言わず、致命的なときだけ口出すくらいの人が望まれているんだろうなと思ってる。
"厳しいフィードバックをしづらくなる。反対意見を言いづらくなる。失敗に対する処罰がしづらくなる。"
https://q.livesense.co.jp/2023/09/26/2287.html…
posted at 14:41:00
ただ、管理職が辞めるときはちゃんと引き継ぎして欲しさはある。
posted at 12:03:29
会社を辞める事が選択肢に浮かぶ状況下で、辞めた後の会社の業務について考える必要は無い。それで問題出るなら、それは管理職の問題。 https://twitter.com/anzaikyo1/status/1708351427704402290…
posted at 12:03:29
2023年09月30日(土)2 tweetssource
Terraformの自動applyとかも同じで、自前でちゃんと実装できる人は限られるので、Terrafom Cloud使っておいた方が良い。
posted at 16:33:10
デプロイの自動化が常に正しいかと言えば微妙ってのは体感と合ってる https://track3jyo.com/2022/11/blue-green-deploy-devday/…
posted at 16:31:39
2023年09月29日(金)1 tweetsource
業務だと問題が起きない堅牢なコードを書くよりも、わりと適当な実装とレビューでマージして、問題を起こして直す方が評価者に分かりやすい成果が出て評価されやすい可能性。意図的か否かは別で。
posted at 10:29:05
2023年09月28日(木)7 tweetssource
社内でAWS関連の業務をする機会が無くなったけど、勘が鈍るのも微妙なので副業するのはアリかもしれない。
posted at 11:33:45
動くコードを直すべきじゃないという話がある一方で、業務だと少ないレビューでマージされがち。
https://qiita.com/kotauchisunsun/items/d03c1e6936ffb250e4a1…
posted at 11:02:38
Gemfileから依存を取得し、プロダクトコードを解析してASTのconst使ってgemを参照してる箇所を洗い出すスクリプト書いたけど、地味に便利かもしれない。
posted at 10:51:00
喜怒哀楽を考えると、怒りでコード直す力が増すことあるけど、Professionalがそういう振舞いするかで言えば微妙そう。少なくとも自分のProfessional像だと常に冷静な感じ。
posted at 09:49:36
仕事はあくまで仕事なので、自身の感情と切り離して合理的な振舞いを常に心がけるべき。Act as Professional の精神で定時まで8時間を過ごせるようになりたい。
posted at 09:46:18
シニアや役職者にも共感されない課題はあるだろうし、同様の悩みはあるはず。これを否定してるわけではない。
posted at 09:34:45
シニアや役職者だと相手の課題に共感し辛い現象はありそう。課題の質にもよるけど、そもそもシニア(もしくは役職者)は周りから配慮があって課題に遭遇しないケースがある。
posted at 09:34:45
2023年09月27日(水)15 tweetssource
大三元は鳴いても成立するから、ナーフされても仕方ない…？
posted at 18:46:28
前者はスイッチングコストが高くて効率が悪くなる。後者は役職者の予定がボトルネックになって効率が悪くなる。
posted at 16:43:18
メンバーがプロジェクトを兼務する問題と、役職者が兼務する問題がある。
posted at 16:42:06
CxOのマネージャーは存在しないので、CxOなら兼務させ放題になってしまいそう https://twitter.com/ryuzee/status/1706933499419353309…
posted at 16:41:01
仕事の面倒さに比べれば、OSSの方がマシな気が一瞬だけしたけど、OSSもわりと面倒なことあるし、どっちもどっちだなと思い直した。
posted at 15:58:40
まぁ、そういうの考えるのはCTOやVPoEの仕事であって、一般社員の自分が頭を悩ませる話ではないが。
posted at 14:12:47
業務では何のためにレビューしてるのか。
バグを減らすためなら詳しい人がレビューする方が効率良いけど、ラストマンシップを育てるためであればチーム全員が等しくレビュワーに当たるのが妥当そう。
posted at 14:11:44
OSSだとコードに詳しい人がレビューするけど、仕事だと責任を持つチームに対してレビューを依頼するケースがある。この運用が妥当なのか悩ましい。
posted at 14:11:43
業務でコードオーナーをどう設定するべきか。
コードの変更内容に責任を持つ人（チーム）とコードの内容に詳しい人は別で、そこを業務でどう扱うべきかは開発組織によりそう。
posted at 14:08:10
v7.1.0.rc1 が出た
https://github.com/rails/rails/releases/tag/v7.1.0.rc1…
posted at 13:43:22
フルリモート環境下のSlackの投稿に対する振る舞いに関しても思うところあるけど、やっぱりXはパブリック過ぎるので書けない。
posted at 10:48:35
Railsは「v7.1.0がリリースされたら触る」よりも「v7.1.0.beta1 を触って（CIで動かすだけで良い）、問題があればフィードバックする」方が良い。v7.1.0が出たら変更し辛いけど、betaならまだ変更の余地がある。
posted at 10:01:14
記事に追記しておいた。
https://sinsoku.hatenablog.com/entry/2023/09/21/153121…
posted at 09:54:16
Railsのcan't be blankの変更がリバートされた。
https://github.com/rails/rails/commit/acfa0454058c535c1352ddab91c93ca914f0805a…
posted at 09:36:46
何か問題が起きたら、それは全て自分に問題があるので、そう弁えて行動するしかない。他人に期待したり、自分が問題を予知できないのが悪い。
posted at 09:26:33
2023年09月26日(火)2 tweetssource
Fate zeroのバーサーカー戦のセイバーみたいな心境になりつつある。難しい...
posted at 08:46:06
チーム開発をして、相談しながらより良い設計を見つけるとかしてみたいが、最近はそういうのと縁遠くなってしまったな…
posted at 07:34:21
2023年09月25日(月)4 tweetssource
OSSのコードを書いてるのも人間なので、まずは半年ROMってからプルリクを投げるのがコミュニケーション的に良い可能性はある。懐かしい2ch時代の所作。
posted at 16:59:20
1on1に関して思うところはあるが、それを書くにはXはオープン過ぎる。
posted at 16:46:22
typo修正とかは短くても伝わるので、それと同じで関係者にメリットが伝わるなら長文書く必要がないと言えば、それはそう。コミットメッセージに何を書くべきかは最近考えることが多い。
posted at 11:08:18
Pull Requestの説明がsmall improvementsだけで許されるの仕事のリポジトリくらいで、OSSでこれだけだと厳しい印象あるんだけど、そんなこともないんだろうか。
posted at 11:05:41
2023年09月22日(金)3 tweetssource
さすがに業務でランチ情報だけを書いていたらレビューで指摘するけど、適切な変更理由 + ランチ情報だと指摘しない気がする。
posted at 10:47:50
業務でもコミットメッセージがdiffの和訳しただけの人（xxxを追加、xxxを更新など）は一定いるので、それに比べれば職場近辺のランチ情報でもコミットメッセージに書いてある方が有意義な可能性は否定できない。
posted at 10:45:35
@Akira_Akagawa 自分の見識が古く(低い水準に)ならないように、書籍や勉強会で見識を広げ続けていきたい。ただ、あまり水準を上げると業務外で勉強しない人との会話が難しくなって、それはそれで難しい…
posted at 09:11:00
2023年09月21日(木)10 tweetssource
やっぱり前職の給与を聞くのは微妙だよ https://www.businessinsider.jp/post-275612
posted at 21:45:23
この話をするときは、だいたい石包丁のメタファを使う。
https://twitter.com/sinsoku_listy/status/1044561682163367937…
posted at 18:09:55
開発水準という概念があると思っていて、低い水準の開発体験しか知らない人には高い水準の開発体験は認知できないし、想像すら出来ないケースもある。
posted at 18:08:31
個人的には強い困りポイントは無いけど、レビューで気づけないから、このままv7.1が出たらRuboCop使って文字列リテラル内のcan'tやdon'tなどを直すコードを書くことになりそうとは思った。 https://twitter.com/sinsoku_listy/status/1704745250018000960…
posted at 17:14:08
はてなブログに投稿しました #はてなブログ
Rails v7.1.0 で `can't be blank` が `can’t be blank` に変わる - アジャイルSEの憂鬱 https://sinsoku.hatenablog.com/entry/2023/09/21/153121…
posted at 15:31:54
課題が共有されて（＝透明性）いて、誰でも課題にコメントできる状態になっているのが組織として良いことな気がする。
posted at 11:24:55
基本的に他のコードを真似して書いて、エラーが出たらエラー出なくなるまで適当に弄る感じ。
posted at 10:05:27
コピペでコードを書いていて、プログラミング言語の仕様を理解せずに書いてる人はFizzBuzzを独力で書けないだろうし、そういう人は一定いるだろうなという感覚はある。
posted at 10:05:26
Railsを使って仕事をしている以上、いつかは最新バージョンのキャッチアップをしないといけないわけで、それを今やるか、後でやるか。
今やれば「触ってみた」だけでブログや勉強会で話すネタになるのでお得だけど、後でやると目新しさは無くなるので、今やるのがお得。
posted at 00:53:55
終電を逃したと思ったけど、第二終電のルートがあったので帰宅できそう
posted at 00:25:25