2024-12-31 共有記事ログ

概要

現職の開発部のメンバーに共有した記事のログ

技術系

遅いSQLを改善して高速化を実現するためのアプローチ

JOINを減らすことでパフォーマンスが改善される例の紹介です
FuelPHPを利用していると知らないところで大量のクエリが発生するのでできる限り先に取るようにしてしまいがちですが、状況に応じて取得するクエリを分けて対応するのも必要だと思います共有します

MySQL実行計画によるパフォーマンスチューニングの実践

MySQL の具体的なパフォーマンスチューニング方法の解説記事です
WITH句はMySQL8.0以降でなければ使えませんが、ここで記載されているテクニックは比較的汎用的に使えそうなので共有いたします！
データ数が増えると問題になることが多々出てくるかと思いますので、最初に設計できれば問題ありませんが、問題になってからもしっかりリカバリーできるようにしていきましょう！

マネジメント系

PMが頼ったり頼られたりするために気をつけていること

マネジメントする上で気をつけていることの紹介記事です
これは決してマネジメントする人に限らず、どんな人でも実践することで仕事がやりやすくなるのではと思います！
うちの村長はこれを常にやってる気がします笑
頼りやすく、頼られたら頑張ろうとなれるタイプ！

開発チームの活動を見える化できた話

見える化と属人化脱却のための取り組みの記事です
弊社では全プロダクトにおいて属人化を排除することは困難ですが、村内のプロダクトは属人化しないようにしていきたいと思います
そのために足りないドキュメントを少しずつ用意したり、ここにあるような実装前に村内で実装方針を話し合ったり共有したりして、全員が緊急時でも動ける体制を整えていく必要があると思います

セキュリティ系

　

その他

視座・視野・視点を磨く重要性と方法

視座・視野・視点について例を交えながら解説している記事です
自分は特にプログラムという視点で見る曲があり、UI/UXなどの視点が欠落しがちだったり、視野が狭く、ビジネスや経営にまで目を向けれていないことが多々あります
皆様はいかがでしょうか？
視座・視野・視点を強化することで自身の成長にも繋がると思いましたので共有いたします！

「相応に良い設計」によって失われるものと、そのリカバリー方法

「相応に良い設計」＝「妥協した部分がある」ときにどのように返済するのかという記事です
ここで自分たちも取り入れるべきだと思った内容として、妥協した部分は必ずチケット化するという部分でした
CodeRabbit Pro の導入が完了すれば Issue を自動で作ってもらうというのも手ではありますが
自分たちが Backlog で管理しているという都合上、こういったものも Backlog の課題として乗せるべきだと思いました

【開発効率爆上がり】すべてのエンジニアが必ず見るべき16のウェブサイト

便利なサイト紹介記事です
個人的に良さそうだと思ったのはDev Dock, 個人情報テストジェネレーター, ダミー画像生成ツールでした
いくつか良さそうなサイトが記載されていたので共有します！

To プロダクトチーム

問い合わせフォームを実装しただけなのにスパムメールの加害者になっていた話

問い合わせフォームから入力されたメールアドレスに自動送信するとスパムメールを大量に送信させられていたという記事です
当システムも最近緊急連絡用フォームを実装致しましたが、場合によっては同様の使い方が可能な気がします
もちろんバグがある事が前提なので記事のケースとは前提が異なりますが、自動返信の内容は見直しても良いかも知れないと思いました

To Intern

新人エンジニア指導完全ガイドブック【OJT編】

指導者向けに新人教育で行うと良い考え方などの紹介記事です
自分たち既存社員はもちろん、指導者としての立場でここに書いてあるようなことを意識しながら行動する必要があります
逆に言うとインターン生の皆様は、「こう指導した方が良い」の指導結果を意識しながら働くと、より良い成果を出すことができるようになると思います！

共有するほどではないけど興味があったもので読んだもの

• 技術がなければ作れない、必要がなければ存在している資格がない - Platform Engineering: A Guide for Technical, Product, and People Leaders の読書感想文
  • 読み手のことを考えてまとめる能力がないのかなと思うほどのクソ長記事
  • この記事を読む時間があったら実際の本を読むべきだったと後悔
  • 終始技術的な正しさだけで無く、顧客ニーズとのバランスが大事的な話
  • 技術よりもコミュニケーションというイメージが強い
• 来年30歳になる私が20代で経験して心から良かったと思う5つのこと
  • 男がSNSで顔出ししても意味ないんじゃって思っていたけど、意外と繋がれるのか？？
• 俺のガチってるdotfiles紹介
  • 作っておくと色々便利
• プロダクト技術責任者の技術負債との付き合い方
  • ヒアリングして可視化して改善方針をねる。これを自分もしっかりできるようにならなければと思う。特に信頼を勝ち取る部分を。
• 「リーダブルコード」から得た実践的知識まとめ
  • 復習
• 満足度の高い1on1を受けるコツ
  • 受ける側の心構え的な事については考えた事がなかった。とても参考になる。弊社も1on1を明示的に行うべきかも？？
• アプリケーションエンジニアが取り組んできたDB負荷削減の話
  • 本当にあるあるだなと。何度これで悩まされたことかw
• 初老を超えたエンジニアの現実
  • 確かにテクノロジでカバーできる範囲が広がっているから身体能力の劣化も補えそう
• マルチプロダクト開発の現場でAWS Security Hubを1年以上運用して得た教訓やあれこれ
  • 弊社も導入はしたが運用はできていないので参考にしてみても良さそう
• テスト管理ツールを移行してみた　〜ツール転生させてQA無双〜
  • どんなツールも一長一短なので、何を重視してせんて選定するのかが大事なのだと思った
• 今までアウトプットしてこなかった私が、今年からアウトプットを始めてわかったこと
  • 最近アウトプットというものに興味が湧いているけどたいして話せることがないのが困りものw
• 品質とスピードを両立するためにチーム体制を変えている話
  • 技術的な負債が積み重ならない、もしくは返済できる目処がたち、エンジニアが無理せず働けるならありなのかもしれないが、返済されずに負債を重ねると将来確実に詰むだろう…
• 創業時から運用が続いていたレガシーコードからの脱却
  • 言語自体を変えた理由がかなりきになる。
  • PHP8.4 で Laravel を利用するというのも一つだと思うが、この人が Ruby on Rails が得意だったからか？社内の Ruby 習得率とかも気になるところ
• 楽しく幸せに働くために、他人との比較をやめてみよう！
  • 他人と比較しないというのは言うは簡単だけど、実行するのは難しいと思う
  • 個人的には他人に期待しないようにすると、かなりストレスは減ると思った
• 権限管理基盤チームのCIの仕組みと課題
  • E2EテストのCIも工夫次第で時間削減できそう
• git revertは怖くない！
  • 使いこなせば便利だけど、乱用すると大変なことになる
• 1年半のマネージャー経験から見出した1on1術
  • 1on1もディスプレイ使いながらというのは新しい視点だと思った
• 速い開発のためのコミュニケーションと知的謙虚さ
  • 自分も開発部内で歴が長いだけに言葉に強制力が働いてないか心配になることが結構ある。気をつけなければ
  • 「自分の考えの証明になっていないかを振り返る」この言葉はとても刺さった
• AWS学習ロードマップ
  • ロードマップを見ると、意外と知らない機能も出てくるから面白い
• リンクの下線は消してもいいの？
  • デザインって難しいなと言う小並感
• 10年のエンジニア人生を振り返り、その中で本当に大切だと思ったもの
  • 自分も10年近くエンジニアをしているが、この人と似た感想を持っているなと感じた
• 小さなテーブルへのALTER TABLE一撃でサービス停止。そこから学んだ惨事を繰り返さないためのルール作り
  • MySQLのテーブルロック問題はしばしば遭遇するけど、事前に検知するのは難しい問題だと感じることが多い
• 【まとめ】プログラミング向けフォント使っていますか？
  • リガチャが入ると地味にVimの描画が遅い気がしてやめたんだよな…