GitHub Actions による Renovate の安全自動マージ
本記事は Renovate の Pull Request を安全に自動マージするためのガイドです。 以下のドキュメントが元になっています。 この記事は一度書いたら後はメンテしませんが元のドキュメントはメンテしていくので、元のドキュメントも参照してください。 Renovate の導入は非常に簡単ですが、単に GitHub App をインストールしただけではその真価は発揮されません。 この記事では安全かつ自動で Renovate の Pull Request をマージし dependencies を常に最新に保つためのテクニックを紹介します。 この記事では CI に GitHub Actions を使うことを前提とします。また、 Renovate とは直接関係ない内容も含みます。 1. 概要 ある dependency を update する場合、その update に関連した test が
Renovate の Best Practices から学ぶ依存関係管理の考え方
Renovateはプロジェクトの依存関係の更新を自動化するツールです。 npmライブラリやGitHub Actions、Dockerイメージのバージョンなどを監視し、ライブラリアップデート用のPRの作成を行います。 Renovateは豊富な構文から柔軟な設定ができますが、プリセットと呼ばれるカスタマイズされた設定集を利用することもできます。 その中でconfig:best-practicesというRenovateが考えるベストプラクティスのプリセットが用意されています。 このプリセットを読み解くことで、Renovateがどのようにライブラリのバージョンを指定し運用するべきか知ることができます。 この記事ではconfig:best-practicesの設定を読み解き、どのようにライブラリの依存関係を扱うかを考えていきます。 config:best-practice で設定されている項目 執筆
**強い**エンジニアのなり方 - フィードバックサイクルを勝ち取る / grow one day each day
# 参考資料 - https://speakerdeck.com/pokotyamu/furikaeri-2024-95ceb97e-d587-4c4b-a4ec-5e52672644f6 - https://www.1101.com/umeda_iwata/ - https://speakerdeck.com/soudai/release-small
決済ステータス定義の最適解
ネットスーパーシステムの決済ステータス表現 (状態遷移) は複雑だ。 その理由は要求要件が多いことに起因しているが、多いことが悪いのではなく、それに応えなければシステムとして真の価値を発揮できないからで。逆に問題解決できなければ、著しく利便性を落としてしまうので、必須要件という位置付けにある。 前提文脈を汲み取りづらいモデリングなので、問題解決例を示すのはあまり見かけないが、自分が考えた決済ステータス定義の答えを示す。 この内容は過去にブログや登壇で話した内容の延長でもあるので、過去の内容も参考にすると良いかもしれません。 「E-Groceryにおけるカード決済処理の難しさと設計戦略」 「ネットスーパーの買い物体験を支える工夫と決済機能実現の過程」 前提条件 注文から支払い完了まで時間差がある注文後に注文内容の変更ができる品切れが発生するケースがある販売員が注文内容を変更できる0円での支払
Bunのロックファイル(bun.lockb)のバージョン管理をPull Requestのコメントで可視化する
Bunをパッケージマネージャーとして利用する場合、ロックファイルのバージョン管理をどのように行っていますか。 Bunはロックファイル(bun.lockb)がバイナリ形式のため、変更内容をgitコミットの差分から確認することができません。 公式ではgit diffでyarn.lockの形式で差分を確認する方法が紹介されていますが、手作業で毎回diffをとるのは面倒です。 また、差分を検知するためにyarn.lockを出力して差分を検知する用途でバージョン管理する方法もありますが、他の開発者に対して混乱を生んだり、ロックファイルの二重管理になってしまいます。 今回はリポジトリでyarn.lockを管理せずに、ロックファイルの差分をPull Requestにコメントすることでロックファイルのバージョン管理を可視化する方法を紹介します。 作ったもの Bunのロックファイルに変更があった場合、mai
Engineering Productivity Meetup に参加しました - /var/log/da1
サイボウズさんの生産性向上チームが主催する Engineering Productivity Meetup に参加しました。 cybozu.connpass.com もともと生産性向上チームが週次で発信している zenn の記事が好きで読んでいたのですが、中の人がどうやって情報を拾ったり業務に活かしているのか気になっていたので良い機会でした。 zenn.dev 聞きに行くだけでも楽しそうだったのですが、ちょうど隅田川dev というLT会で話したネタが今回のイベントとマッチしていたので内容をさらに掘り下げてLTをすることにしました。 sumidagawa-dev.connpass.com 発表した内容は、「ECSで運用するサービスにBlue/Greenデプロイを導入することで普段の運用を改善した」というものです。 speakerdeck.com 技術自体は新しいものではないのでどのくらい関心
「任天堂」採用ページの「人材に対する考え方」が反響 Googleとも共通する最重要事項とは | マグミクス
任天堂が公開した採用情報のページ「任天堂の人材に対する考え方」が注目されています。このページには「任天堂らしさ」がどういうものなのか、そして任天堂が最も重視する企業成長の秘訣が書かれているのです。 任天堂が公開した「任天堂の人材に対する考え方」（https://www.nintendo.co.jp/jobs/human-capital/index.html）というページが大きな話題になっています。 このページでは、任天堂が人びとに喜ばれる娯楽を作るため、どのように人材を育成し会社の力をつけていくかといったことが書かれています。採用に関する情報を公開すること自体は特に珍しくないわけですが、日本を代表する任天堂がわざわざ明文化したことが注目されているようです。 「任天堂の人材に対する考え方」は、任天堂に就職したい人のみならず、ゲーム好き、そして社会人としても見るべきものが含まれています。特に注
Railsプロジェクトで発生するflaky testの傾向と対策｜グロービス・デジタル・プラットフォーム
はじめにはじめまして。この一年ほど学び放題のDevExpチームでバックエンド開発のお手伝いをしてるmasa_iwasakiです。 今回の記事では、学び放題のバックエンドとして使われているRailsアプリケーションで実際に発生していたflaky testの事例を中心に、一般的なRailsアプリケーションで発生しがちなケースをまとめました。 個人的に、flaky testの発生パターンは割と定番化している印象を持っています。たとえば、以下の記事に記載されている内容と本記事の内容は共通するものが多いです。 Ruby: テストを不安定にする5つの残念な書き方（翻訳）｜TechRacho by BPS株式会社 しかし、同じ原因で発生したflaky testであっても、コードベースが異なれば発生の仕方は変わりますし、なにより原因の調査にかかる手間は大きく異なります。本記事がflaky testに遭遇し
設計の知識と技能で駆動するソフトウェア開発
Object Oriented Conference 2024 登壇の機会をいただいたので、ここ数年、設計について考えていることを、言語化してみました。 はじめに 設計と開発プロセスの関係性 ソフトウェア設計の知識と技能 ① ソフトウェア設計の基礎知識 a. 基本課題 b. 解決のアプローチ c. モジュール化：基本となる４つの技法 ② モジュール化 a. モジュールの分類 b. オブジェクト指向プログラミングのモジュール化 c. ドメイン駆動設計のモジュール化 ③アプリケーションのモジュール構成（参照モデル） コア（中心） ポート（境界） アダプタ（周辺） ④モデル駆動設計 全体 事業活動、要件、アーキテクチャ コア（中央） 業務ロジック、ドメインモデル 業務機能、アプリケーションサービス アダプター（周辺） 記録モデル、データベーススキーマ 連係モデル、プロトコル設計 対話モデル、イン
Rails 7.1 + Ruby 3.3 で YJIT を有効化してパフォーマンス改善を行った結果
この記事の概要 こんにちは。PharmaX でエンジニアをしている諸岡（@hakoten）です。 この記事では、薬局DX事業部のバックエンドで採用しているRuby on Railsのアプリケーションについて、Rubyバージョンを3.3にアップグレードし、YJITを有効化した結果、どのようにパフォーマンスが向上したかをご紹介します。 現在のRuby on Railsのバージョンは、「7.1.3」になります。 YJITについての簡単な説明 YJITとは、CRuby内部に組み込まれた軽量のJIT機能で、遅延コード生成を行い、必要なメソッドを部分的にコンパイルすることで高速化を図る仕組みです。 (処理系は詳しくないため、ざっくりになってしまいすみません。。) Ruby 3系列の主要な機能の一つであり、3.1で導入され、3.2で正式にサポートされ、3.3においてさらに安定化が行われています。 詳しい
個人開発を7年以上続けて分かった技術選択のコツ
技術革新に適応しようとするイヌさんInkdropというMarkdownノートアプリを作り続けて7年になる。 お陰さまでその売上でずっと生活できている。 これまで個人開発でどう継続していくかについて「ユーザの退会理由をあれこれ考えない」とか「アプリの売上目標を立てるのをやめました」とか、ビジネス面あるいはメンタル面からいろいろ書いてきた。 今回は、技術面にフォーカスして、どう継続して開発していくかについてシェアしたい。 TL;DR最初はとにかく最速でリリースする事を最優先する迷ったら「ときめく方」を選べ程よいところで切り上げて開発を進める使っているモジュールがdeprecatedされるなんてザラだと覚悟する古いから悪いとは限らないシンプルにしていく老舗から継続の秘訣を学ぶ運ゲー要素は排除しきれない最初はとにかく最速でリリースする事を目標に技術選定する開発計画とビジネス計画は切っても切り離せな
12年目を迎えた『ガールフレンド(仮)』におけるデータベースの負債解消への道のり【CAGC2024】
本セッションではPC/スマートフォン向けゲーム『ガールフレンド(仮)』のデータベースの負債とその解消の道のりをご紹介します。 当ゲームではデータベースにMySQLを採用しており、長年の運用を続けていく中で下記のような課題が発生してきました。 「突発的なユーザー増加で更新負荷に耐えられない」 「データ容量が肥大化しパフォーマンスやコストの悪化」 これら課題に対しどのような手段で対応したのか、またその対応によって新たな負債が生まれることとなったその経緯と解決策の歴史を解説します。 https://cagc.cyberagent.co.jp/2024/session/index.html?id=m7XRYTxp Copyright © CyberAgent, Inc.
『LeanとDevOpsの科学』をきちんと解読する 〜Four Keys だけじゃ絶対もったいなくなる話〜
スクラムフェス福岡2024での講演資料です。 --- 皆さん、職場でFour Keysを導入していますか？ Yesと答えた皆さん、『LeanとDevOpsの科学』は読みましたか？ あくまで僕の周囲のみの観測で語るのですが、Four Keysを職場で導入しているという人はとても多いのですが、そのうち、出典である『LeanとDevOpsの科学』をきちんと読んだ人はかなり少ないようです。 そして、ここで敢えて強めの主張をするのですが 『LeanとDevOpsの科学』を読まずにFour Keysをきちんと利用することはほぼ不可能です。 Forsgrenらは徹底した研究の結果として4つのメトリクス（指標）を見出すのですが、その裏には彼女らの沢山の思いが詰まっています。その思いや彼女らの思考を理解し、彼女らの考えをきちんとトレースして始めて、Four Keysは意味を持ちます。 そして『LeanとDe
ソフトウェアアーキテクチャメトリクスの基礎: Software architecture metrics in a nutshell
ソフトウェアアーキテクチャメトリクス - Forkwell Library #44 での発表資料です https://forkwell.connpass.com/event/309739/ 動画: https://www.youtube.com/watch?v=C52rYX_E9bA #Forkwell_Library
プロダクトマネージャーとエンジニアリングマネージャーで協力して使われなくなったコードを消していった話 - Retty Tech Blog
Rettyの松田です。普段はプロダクトマネージャーとしてSEOに関わっていることが多いですが、今回はエンジニアリング寄りのブログです。 元々Webエンジニアをしていたのである程度はコードを読むことができ、現実的にプロダクトの改善につながるものがあったため、週1時間ぐらいを確保してコードリーディングするのを半年ぐらい続けていました。 一定の区切りがついたのと、実際にいくつか不要なコードを削除することができたので、その取り組みについてまとめてみます。 きっかけ プロダクトの主要なページについて、現状を把握することが難しくなってきていることが課題として存在していました。 主要なページは数多くの施策が行われている分コードの変化も多く、ユーザーさんに価値を提供し続けられなくなってしまったものも取り残されてしまっていました。 他の施策の実行に合わせてリファクタリングできるレベルであればよかったのですが
行動をするときに「自分には向いてないかも」と悩む時間は必要ない - そーだいなるらくがき帳
PHPカンファレンス関西懇親会で若者に「俺だってソフトウェアエンジニアの才能が無いかも…と悩んだことあるよ」って話をした。 そんな悩みを持っていたのは自分が25 ~ 26歳くらいの頃で自分はエンジニアとしてスタートが遅かった（異業種転職組）から、技術力の無さを痛感しながらも、それを才能の理由にしようとしていた。 続けるために必要なのは才能ではない 悩んでいるとき、飲み会で当時の同僚で先輩の @maepon さんに相談した*1ところ、次のことを言われた。 自分が「才能ないかも」と言ったあとに帰ってきた言葉は「もし、お前に才能が無かったとして、じゃあお前はどうするんの？そのifの中に実装があるの？何も無いんだったらそのifについて考える時間は無駄じゃん。必要なくない？」って感じ。 確かに才能が無かったとして、じゃあソフトウェアエンジニアを辞めて別の仕事したいってのがあるなら考えればいいけど、当
ElasticsearchのANNを利用して100万件のベクトル検索を高速化！ - Taste of Tech Topics
この記事は Elastic Stack (Elasticsearch) Advent Calendar 2023 18日目の記事です。 こんにちは。 Acroquestのデータサイエンスチーム「YAMALEX」に所属する@shin0higuchiです😊 YAMALEXチームでは、コンペティションへの参加や自社製品開発、技術研究などに日々取り組んでいます。 さて、最近はLLMの発展に伴ってRAG（Retrieval-Augumented Generation）が盛んに活用されています。 その中で、キーワードベースの検索だけでなくベクトル検索を併用するケースが多く見られ、実際にElasticsearchが利用されているケースも多く目にします。そのため、Elasticsearchのベクトル検索に興味を持っている方も多いと思います。今回の記事では、Elasticsearchのベクトル検索の速度な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
検証を通して見えてきたTiDBの性能特性
経験に複利を効かせろ！ふりかえり研修2024
アジャイル勘違い集 (2024) | Agile Studio
