タグ

ysirmanのブックマーク (1,947)

  • RSpecを書く上で意識した方がいいと思うことと少しのTips | Offers Tech Blog

    こんにちは!Offersを開発しているバックエンドエンジニアのShunです。 前回「テストは絶対書いた方がいい」という記事を書いたので、今回はテストを書く上で留意していることを書ければと思います。 そもそも、テストは絶対書いた方がいい 単体テスト・結合テスト・UseCase テストを書いておくことで、テストファイルを見るだけで仕様を理解できたりします。 また、複雑なメソッドほどテストを書いておくことで、きちんと想定した出力を保証したメソッドの実装ができます。 さらに、一度書いたテストは追加機能・修正対応・リファクタリングなどを行った際に、影響してるか否かを自動でチェックしてくれます。 これにより、ユーザ様への円滑な価値提供並びにサービス品質を保証する大事な役割を担ってくれるのです。(テスト書いてなかった頃が恐ろしい) しかし、きちんと書けば書くほどテストのコード量が爆増する 書けば増えます

    RSpecを書く上で意識した方がいいと思うことと少しのTips | Offers Tech Blog
  • Kaigi on Rails 2024

    Talk 約9000個の自動テストの時間を50分から10分に短縮、偽陽性率(Flakyテスト)を1%以下に抑えるまでの道のり 弊社の Rails アプリケーションは、7年間の開発を経て、自動テストの数が8871個、CIにかかる時間が50分、偽陽性(Flaky)によってCIが失敗する確率が15%という状況でした。 この状況から、CIの高速化 & 安定化のチームを発足し、CIの時間を10分、失敗率は1%程度と、大幅な改善を達成しました。 セッションでは、この道のりを振り返り、以下のような観点から知見をお話しします。 CI・自動テストに関する根課題の整理 改善に寄与した施策とその寄与度 効果がなかった施策とその理由 全員が機能開発を続けながら、サイドプロジェクトとして改善を達成するための工夫

    Kaigi on Rails 2024
  • 英会話力を上げた激キモ練習法

    こんにちは、近藤です。 コミューンという会社でグローバルチームの一員としてサービス開発をしています。 長期留学や海外赴任の経験はないのですが、グローバルチームに所属してから1年が経ちました。 今の英語力は自分の考えや気持ちを伝えるには困らない程度にはなってきたかなと思っています。 この記事では、私が日々実践している英会話の勉強方法を紹介します。かなり独自の(気持ちわるい)方法ですが、私なりに効果を感じているので、同じように「英語を使う環境だけど海外経験はあまりない」という方の参考になれば嬉しいです。科学的根拠などはなく私見なので、あくまでも体験記として読んでいただければ幸いです。 なお、日企業のグローバルチームでの働き方については、以前「海外経験のない私がグローバルチームに所属して9ヶ月たちました」という記事でまとめていますので、興味がある方はご覧ください。 英語は読めるのに喋れないのは

    英会話力を上げた激キモ練習法
  • 【2024年末最新】AWS 学習におすすめの技術書 厳選12冊(初級者から上級者まで) - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

    ysirman
    ysirman 2024/12/30
  • 「頭の回転が速い」を科学する|宮脇 啓輔 / 株式会社unname

    こんにちは、unnameの代表取締役の宮脇啓輔です。 普段から重要だなと感じたことや、自分なりに思考したものを伝えようとXで投稿しているのですが、その中でも反響が大きかった投稿をさらに肉付けして発信しようという試みで記事化しております。 「頭の回転が速い」とは「累積思考量が多い」ことだと思います。「過去に似たようなテーマについて考えたことがある」から、すぐに自分の意見が出てくるし、回転が速く見える。考えたことがないと、その場で思考してしまい、遅く見える。そういうことだと思っています。… — 宮脇 啓輔 / 積極採用中 / unname (@keisuke_unname) March 21, 2024 この投稿がかなりいい反響をいただいたということもあり、投稿をベースに、もう少し肉付けして解説してみます。 「頭の回転が速い」の正体はなんなのか「頭の回転が速い」と見える人は、実際は「累積思考量

    「頭の回転が速い」を科学する|宮脇 啓輔 / 株式会社unname
  • 「読みづらい文章を書く人」が無意識に使っている言葉とは?|庄子錬|編集者

    こんにちは! 先日、ある経営者からこんな相談を受けました。 「人事や総務が全社宛てにメールすることがあるんだけど、その内容が【長くて読みづらい】って不評なんだよね。実際、一文が長くて内容が頭に入ってこないから、読むのを後回しにしちゃうんだよ。どうにかならない?」 こういうケース、よくあると思います。 全社宛ての連絡では、重要度が高いことを共有するもの。わかりにくい文章だと、誤解や混乱を招いたり、個別対応が求められたり……書き手・読み手ともに余計なストレスになります。 そうした状況を避けるために、書き手が身につけておくべきこと。 それが、大事なことだけを短く書く技術=「要約の技術」です。 今回は「要約の技術」のなかでも、もっとも基となる「余計な言葉を削ること」にフォーカスして解説します。 無意識に使いがちな「余計な言葉」7選 質問です。以下の文章を読んで、どう思いますか? 私たち人事部の意

    「読みづらい文章を書く人」が無意識に使っている言葉とは?|庄子錬|編集者
  • インデックスの"正解"を探せ!決済レスポンスタイムを改善したパフォーマンスチューニング - inSmartBank

    はじめに サーバーサイドエンジニアの kurisu(ryomak) です。 普段は、カード決済やあとばらいチャージに関連する機能の開発・運用を行っております。 記事でお話しすること 記事では、インデックス追加によって決済レスポンスタイムを改善した事例をご紹介します。具体的なインデックス設計の検討や実行計画の見直しを通じて、どのようにレスポンスタイムを最適化したのか、その裏側を詳しく解説します。インデックス追加によるパフォーマンスチューニングの際の参考になれば幸いです。 はじめに 記事でお話しすること 決済処理の遅延の検知 事の発端 実行環境 原因調査 遅くなったクエリの特定 対応検討 方針 検証項目 インデックスの「アタリ」をつける ① オーソリゼーション履歴:(オーソリゼーションID, 承認番号,受信日時) ② オーソリゼーション:(カードID, 初回受信日時) ③ オーソリゼーシ

    インデックスの"正解"を探せ!決済レスポンスタイムを改善したパフォーマンスチューニング - inSmartBank
  • スクラムにおけるマネージャーとして意識していること - トラストバンクテックブログ

    パブリテック事業部プロダクトチームの所属のたけだです! この記事はトラストバンクAdobent Calender 2024の記事です。 qiita.com 何を話すか 何を話さないか パブリテック事業部と私 LeSS実践者トレーニング(CLP)を受けて スクラム開発(LeSS)組織におけるマネージャーの役割とは Go See 開発を管理するのではなく、より高い提供価値のために改善する スクラムガイドに「マネージャー」というポジションが一切登場しない背景 DoD(DONEの定義)はチームの能力を表す コンポーネントチームではなくフィーチャーチームにする 自己管理化された組織づくり マネージャーはスクラムチームの中に置かない 個人の成長なくしてチームの成長はしない 社員採用にチームを巻き込む 個人だけで達成するような評価対象となる業績目標を設定しない リソース思考に囚われ過ぎない チームがオー

    スクラムにおけるマネージャーとして意識していること - トラストバンクテックブログ
  • 3年でバックエンドエンジニアが5倍に増えても破綻しなかったアーキテクチャ そして、これから / Software architecture that scales even with a 5x increase in backend engineers in 3 years

    2024/12/24 に開催された「【アーキテクチャと組織の変遷】スピードとスケーラビリティの両立-基盤刷新・モジュラモノリスの行先-」の登壇資料です。 https://findy-tools.connpass.com/event/338716/ # スライド内に記載したURL 組織の立ち上げ…

    3年でバックエンドエンジニアが5倍に増えても破綻しなかったアーキテクチャ そして、これから / Software architecture that scales even with a 5x increase in backend engineers in 3 years
  • DBテーブルのカラムを削除するときにやること・考えること - エムスリーテックブログ

    突然ですが皆様は、稼働済みサービスのDBからテーブルカラムを削除されたりすること、ありますでしょうか? 基的に削除はまずやらないのではと思います。えっやらないの? と思われた方もいらっしゃるかもしれませんが、きっとこの記事を読めばなぜ多くの方がカラム削除を避けるのかわかることでしょう。 とはいえ、そうして使わないカラムがテーブルに溜まっていくとやがて新規加入メンバーがコードにキャッチアップする妨げとなるレベルにまで溜まってきたりします。いつかは大掃除のときがくるわけです。DBは寿命長いですからね。そうしたときに実際どのような手順でカラムを削除するのか見ていきましょう。エムスリーエンジニアリンググループUnit1(製薬プロモーション)・Unit9(治験臨床研究支援)チームエンジニアの三浦 [記事一覧 ]が、最近実際にやった作業から知見をお届けします。 長いので3行で 考え方 1. そのカ

    DBテーブルのカラムを削除するときにやること・考えること - エムスリーテックブログ
    ysirman
    ysirman 2024/12/28
  • あなたが癌になった時に最初に知ってほしい事

    癌治療を専門にしている医師ですが、夜寝付けなかったので、 癌になった時にまず最初に知っておいて欲しい事をかいてみました。 結論いかに早く治療を開始できるかで癌の治りやすさが変わります。 そして、あなた(患者)の頑張りで、治療開始日は大きく変化します。 今回は、知っておいて欲しい癌の知識について書いた後、癌の疑いがあると言われた時の治療開始RTAのコツについて書きます。 (RTA:リアルタイムアタック、いかに早くゲームをクリアできるかの挑戦の事) --- 知っておいて欲しい癌の知識 癌は、ひたすら増え続けるおかしな細胞人間の体は細胞で出来ていて、正常な細胞は決まった日数で細胞分裂して増えますし、決まった日数で死にます。例えば皮膚の細胞は1か月くらいで新しくなって、古い細胞は死んで垢になります。このバランスが保たれているのが通常です。 ただ、変な細胞も一定の割合で発生します。決まった日数で死な

    あなたが癌になった時に最初に知ってほしい事
  • GitHub Copilot in VS Code カスタムインストラクションの設定と効果検証【導入編】 - Findy Tech Blog

    こんにちは。 ファインディで Tech Lead をやらせてもらってる戸田です。 弊社では開発生産性の向上のための投資、検証を継続して行っており、生成AIの活用にも取り組んでいます。 そこで今回は、GitHub Copilot in VS Codeのカスタムインストラクションを導入した際の話を紹介しようと思います。 筆者も最近導入したばかりでフル活用までいっていないのが現状ですが、開発生産性の向上を見込めると確信している強力な機能となっています。 それでは見ていきましょう! GitHub Copilot in VS Codeとは 設定方法 効果検証 まとめ GitHub Copilot in VS Codeとは 公式ドキュメントはこちら code.visualstudio.com VS CodeにはGitHub Copilot、GitHub Copilot Chatを利用するための拡張機能

    GitHub Copilot in VS Code カスタムインストラクションの設定と効果検証【導入編】 - Findy Tech Blog
  • 詳解:フロントエンドの状態とリアクティブ (なぜuseEffect()でsetState()がアンチパターンか)

    すべての状態をできるだけ減らしたいypresto (プレスト) です。 12月頭に予約してたアドベントカレンダーですが12/23になってしまいました。 LayerXのバクラク事業部では、Webフロントエンド領域もがんばっています!! ということで一筆。 バクラク事業部のエンジニアは、バックエンド・フロントエンドの垣根なくプロダクト開発を手掛けています。各々に得意領域があり、わたしはフロントエンドの改善やコードレビューなども行っています。 そのコードレビューで、「Vueの watch() を使用せずに computed() でリアクティブに書きたいです」 (Reactで言えば useEffect() を避けたい) と指摘させていただいたときに、理解を深めたいとコメントを頂いたこともあり、フロントエンド開発のコアとも言える、リアクティブ (Reactive) な状態管理の話をまとめようと思いま

    詳解:フロントエンドの状態とリアクティブ (なぜuseEffect()でsetState()がアンチパターンか)
  • GAS高速化のススメ - Nealle Developer's Blog

    GAS高速化のススメ はじめに こんにちは。サクセスエンジニアリングチームの増田です。 今年の8月に入社して早4か月が経ちました。 入社エントリも公開していますので良ければ見ていってください note.nealle.com 最近週4でカレーばっかってます。 美味しいカレーの後がけスパイスやソースなどあればぜひ教えていただきたい...! GASについて みなさん普段から業務でGAS(Google Apps Script)利用されてますでしょうか。 GASは知っての通りセットアップ不要で使え、Googleサービス(Google Sheets、Gmail、Driveなど)への認証が標準で組み込まれている非常に便利なツールです。非エンジニアでも扱いやすく、業務効率化の手段として広く活用されています。 GASのデメリットと課題 そんな便利なGASですが多くの制限が存在します。 その中でも代表的なも

    GAS高速化のススメ - Nealle Developer's Blog
  • コンフリクトの解決を記録して再適用する git rerere - Qiita

    はじめに Git を使う場合、ブランチの作成とマージを頻繁に行うような運用が多いと思います。例えば、機能追加やバグ修正を行う場合には流ブランチからトピックブランチを作成して、作業はトピックブランチにコミット、作業が終わったらトピックブランチ流ブランチにマージ、といった運用です。 この場合、トピックブランチは細かい単位で作成して、作業が終わったらすぐマージする、というのが良いプラクティスであろうと思います。すぐマージすると、コンフリクトは起こらない場合が多いです。とはいえ、やはりコンフリクトが起こる場合はあります。 コンフリクトが起こる場合とは、feature/12345 ブランチを作成して作業して master ブランチにマージしようとしたところ、別の誰かによる変更が既に master ブランチに取り込まれており、しかもその変更箇所が feature/12345 ブランチでの変更箇所

    コンフリクトの解決を記録して再適用する git rerere - Qiita
    ysirman
    ysirman 2024/12/26
  • カード UI の入れ子のリンクの問題を解決する Link Area Delegation の提案

    多くのウェブサイトではリンクを入れ子にしたカード UI が利用されています。入れ子されたリンクとは以下のようなものです。 このような UI ではカード全体をクリックした場合にはカードのリンク先に遷移し、カード内のタグをクリックした場合にはタグのリンク先に遷移するという挙動が期待されます。この挙動を簡単に HTML で実装すると、以下のように <a> 要素が入れ子になります。 <a href="/new-product"  class="card"> <a class="tag" href="/tag/tech">Tech</a> <div> <h2>New Product</h2> <p>...</p> </div> </a> しかし、このようにインタラクティブな要素(<a> や <button> など)の子要素にインタラクティブな要素を配置することは HTML 仕様上許可されていません1

    カード UI の入れ子のリンクの問題を解決する Link Area Delegation の提案
    ysirman
    ysirman 2024/12/23
  • DevTools の使い方を可能な限りスクショ付きで解説してみる

    以下の公開計測会でやったものを個別に解説してみる。 細かいテクニックが多いのだが、それを可能な限りテキストとスクショで解説したい。使い方の解説が中心で、どういう意味があるかは解説しない。 Chrome131時点のスクリーンショットで、後で読む場合は頻繁にUIが変わっている点に注意。大事なのは意図。 宣伝: これを御社のサイトで解説する仕事をやっています。 デモのURL これに意味はなく、今日偶然見ていただけで意図はない。関係ないがエッジランナーズは最高のアニメ。 DevTools を開く F12 or 右クリックから「検証」 DevTools > Lighthouse この状態で計測 このとき、新しいプロファイルを作ったりして、可能な限り Chrome拡張が入ってない状態にすること。Chrome拡張による処理も計測に含まれてしまう。 Lighthouse レポートの読み方 点数部分にマウス

    DevTools の使い方を可能な限りスクショ付きで解説してみる
  • ソフトウェアは捨てやすく作ろう - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は株式会社カオナビ Advent Calendar 2024の5日目の記事です。 はじめに ソフトウェア開発は、不確実性がとても高いです。 問題を解決するために提案されたプロダクトが、実際にその課題を適切に解決できるかどうかは分からない 実際に問題解決がされたところで、利益となるかは分からない プロダクトを開発するにあたり、期間などのリソースが正確に予測できない こうした問題に対処するため、私たちは短期間での仮説検証を繰り返しながら、常にプロダクトを改善し続ける姿勢が必要になります。 この記事では、開発チームの立場から貢献するた

  • プロダクトの爆速開発を支える、 「作らない・削る・尖らせる」技術

    プロダクトの爆速開発を支える、 「作らない・削る・尖らせる」技術 pmconf2024登壇資料です。 https://2024.pmconf.jp/sessions/Ej1Am2MJ --------------------------------- 「プロダクト開発では、やらないことを決め…

    プロダクトの爆速開発を支える、 「作らない・削る・尖らせる」技術
  • BEGIN 中に BEGIN をすると COMMIT される

    この記事は MySQL Advent Calendar 2023 2日目の記事です。 (ちょっとフライング。。) 今回は僕がマジか、と思ってしまった MySQL の挙動について共有させていただきます。 BEGIN 中に BEGIN をすると COMMIT される 結論から言うとこれだけです ^^;; アプリエンジニアの方からお問い合わせをいただいた時にはこのことを意識したことすらなかったのでトランザクションの終了は COMMIT or ROLLBACK にてされるのだという先入観で動いていました。 ざっくりと言うとこんな感じ BEGIN; INSERT INTO testtable VALUES (1); BEGIN; このタイミングで別のターミナルを立ち上げて中身を確認するとなんと testtable には 1 という値が入っています。 個人的にはまじかーー、な挙動だったのでもしかしたら

    BEGIN 中に BEGIN をすると COMMIT される
    ysirman
    ysirman 2024/12/22