k1takeのブックマーク / 2024年7月15日

Reactテスト駆動開発に一度挫折した人が、生成AIの力を借りて再挑戦する話 - Insight Edge Tech Blog

はじめに Insight EdgeのLead Engineerの日下です。弊社ではフロントエンドのスクラッチ開発にReactを採用することが多いのですが、フロントエンドの保守性はしばしば課題となっています。というのも、要求仕様が曖昧なPoC（Proof of Concept）の段階からMVP（Minimum Viable Product）として開発を進めることも多く、ビジネス側ユーザの意見にも左右されながらアプリを改善していくため、画面のレイアウトやデザイン、画面遷移の変更が多発するためです。こうした状況の中でスピードと品質を両立するためには良質なテストコードが不可欠なのはもちろん、プロダクトコードとテストコードの双方とも、変化に対応しやすく作る必要があります。過去にテスト駆動開発を挫折した要因実は、筆者は過去にReactのテスト駆動開発の実践、および社内普及活動に挑戦したこ

k1take 2024/07/15

AI

リンク

コードレビューの目的と考え方 - osa_k’s diary

まえがきコードレビューの目的大目的小目的チェックリスト優先度高（大きな損失を生む問題・後からの修正が困難な問題）優先度中優先度低（システムに大きな影響を与えない問題・後からの修正が容易な問題）レビューを負担にしないためにレビューサイズのコントロール誰がレビューをするか議論をどうまとめるか批判と個人攻撃レビュワー向けアドバイス Code author向けアドバイス参考文献まえがきコードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを

k1take 2024/07/15

コード

リンク

若い時の無目的なインプットが重要｜山口周

以前からずっと思っていたことなのですが、どこかで書いておかないと忘れちゃうなと思っていたので、備忘録代わりに。結論から先に言えば「無目的なインプットをやってこなかった人は、肝心カナメの時期にアウトプットできなくなる」という話です。どうしてそういうことになるのか、順に説明しましょう。まず、いわゆる「勉強」について、ここでおそるべき一つの法則を提案したいと思います。それは「アウトプット＝インプットの法則」です。一体どんな法則なのかというと「人生全体で見てみれば、アウトプットの量とインプットの量は同じである」ということです。アウトプットする人はインプットしているし、インプットしていない人は、どこかで枯れる」ということで、実にシンプルな法則。実名を挙げるのはさすがに憚られるので、ここでは差し控えますが、一時期にベストセラーを連発して飛ぶ鳥を落とすような勢いだったのに、ぱったりとアウトプットが

k1take 2024/07/15

学習

リンク

GoFの次に覚えたいデザインパターン～Specificationパターン～ - RAKUS Developers Blog | ラクスエンジニアブログ

ビジネスアプリケーションとビジネスルール用語についてパターン適用前 Specification パターン Hard Coded Specification Parameterized Specification Composite Specification 条件の再利用性が向上するテスト性が向上するルールと条件を統一したインターフェースで扱える動的にルールを構成できるまとめ関連するデザインパターン Strategy パターン Composite パターン Interpreter パターン参考文献補足ビジネスアプリケーションとビジネスルール楽楽精算開発部の id:smdr3s です。主に Java を使ったサーバーサイドを担当しています。弊社のサービスである楽楽精算は、その名のとおり経費精算のサービスです。主に企業にお勤めの方が、業務での移動時ににかかった交通費や業

k1take 2024/07/15

アーキテクチャ

リンク

セキュアなAWS環境の設計についての解説【2024年版】 - サーバーワークスエンジニアブログ

こんにちは！イーゴリです。 AWS にとって、クラウドのセキュリティは最優先事項です。(AWS公式ページ) AWS環境のセキュリティ対策としてAWSサービスを解説するよりも、まずはAWS環境の最適な設計について考える必要があります。AWS Well-Architected Frameworkを考慮しながらの設計を推奨します。AWS Well-Architected Frameworkを全部詳しく読むことをおすすめしますが、この記事では個人的に一番重要だと思う点について記載します。とてもざっくり説明しますと、AWS Well-Architected Frameworkとは、クラウドシステムの最適な設計方法を提供するAWSのガイドラインで、6つの柱があります。この記事では基本的に「セキュリティ」の柱を技術的観点から見てみたいと思います。 AWS Well-Architected Framew

k1take 2024/07/15

security
AWS

リンク

社会人の不幸の8割は合意のない期待から｜田中邦裕

社会人の不幸の8割くらいは、合意のない期待によって生まれているんじゃないかなぁと思っています。勝手に期待をして、裏切られたと思う、この気持ちが自分の中のフラストレーションを生んでいます。このことを、先日のダイアモンドオンラインの記事（債務超過を招いた経営陣の「無関心」が最大の失敗さくらインターネット・田中邦裕社長）でお話ししたんですが、思いのほか周りからの反響を頂いたので、ちょっとnoteを書いてみます。一つの例ですが、上司が部下に対して、これくらいやってくれて当然だろうと思っていることでも、それが部下に伝わっていなくて、結局部下はそれをやってなくて、「なんでやらないんだ」と上司は部下を叱責したりしてしまうことがあると思います。でも部下は「なんだよ。自分のやることじゃないだろう」と思って、結局上司も部下も2人とも腹を立てているという状況は、まぁよくありそうなシチュエーションです。