はてなブックマーク

モノリス特有の運用課題 こんにちは。バックエンドエンジニアの須貝です。 タイミーのバックエンドAPIはモノリスなRuby on Railsアプリケーションです。2024年12月現在、このリポジトリ上で10程度のチームが開発しています。 モノリスは利点も多いのですが、チームが増加するにつれて運用面でモノリス特有の難しさを感じることも増えてきました。例えば、SentryやDatadogで何かエラーや問題を検知しても「これはどこのチームの持ち物なのか」という責任があいまいになってしまい改善がなかなか進まない、基盤的なチームがエラーのトリアージをするにしても調査の負担が大きい、といった課題がありました。 SentryとDatadogにコードオーナーを送る 「まずどこのチームの持ち物なのかわかりやすくしよう」ということで、SentryとDatadogにコードオーナー（リポジトリ内の特定のファイルやデ

こんにちは！ タイミーでPlatform Engineerをしている @MoneyForest です。 こちらは Timee Product Advent Calendar 2024 の10日目の記事です。 2024年8月に入社して、幸いにもチームメンバーにも恵まれて楽しく働いています。 個人的にキャッチアップがあまりできていなかった OpenTelemetry を題材にして実装をしてみたので、ここから得られた気づきや知見を共有したいと思います。 はじめに アプリケーションの可観測性（Observability）を担保する上で、APM(Application Performance Monitoring)は重要です。 現在、JaegerやPrometheusのような非商用のものから、DatadogやNew RelicやSplunkなど様々なAPMを利用できるツールが存在します。（本記事では

この記事は Timee Advent Calendar 2024 シリーズ 1 の5日目の記事です。 はじめに こんにちは。タイミーの DRE チームの chanyou です。2024年の3月に DRE チームにジョインして、社内のデータ基盤を作って運用しています。 DuckDB を使ってデータ基盤で扱うデータの品質を保証し始めたので、その内容をご紹介します。 データ品質と完全性 タイミーのデータ基盤で重視しているデータ品質 タイミーでは、DMBOK を参考に以下のデータ品質を重視して設計や日々の運用を行っています。 特性 意味 完全性 データが欠損していないか 適時性 必要なときにすぐにデータを参照できるか 一意性 データが重複していないか 一貫性 型・タイムゾーン・表記揺れなど、値の書式や意味が統一されているか 今回は完全性にフォーカスします。 完全性が損なわれるタイミング 上記の通り

このエントリは「Timee Advent Calendar 2024」の12月2日分のエントリーです。 私は誰？ 2024年5月入社した山田といいます。 ニックネームは「やまけん」とみんなから呼ばれています。 本名より浸透しているので、社員の中には本名を知らない方も一定いる(らしいです)。 productpr.timee.co.jp 前職では、オンライン商談システムを展開するベルフェイスでCREチームのマネージャーをやっておりました。 note.com タイミーは現在、累計ワーカー900万人にご利用いただいているサービスとなっています。 これからも多くの方々にいいサービスを提供し続けられるよう、タイミーでは顧客満足度を技術的アプローチで高めていくためにCREチームを立ち上げることとなりました。 今日はタイミーでのCREの立ち上げから現在、そしてこれからについてお話します。 CREのはじまり

タイミーでバックエンドのテックリードをしている新谷（@euglena1215）です。 タイミーでは RBS の活用を推進する取り組みを少しずつ進めています。意図はこちら メンバーと雑談していたときに「steep check でコケたときにその名前で調べても全然ヒットしないので型周りのキャッチアップが難しい」という話を聞きました。 いくつかのエラー名でググってみたところ、 Ruby::ArgumentTypeMismatch や Ruby::NoMethod など有名なエラーはヒットしますがほとんどのエラーはヒットせず、ヒットするのは Steep リポジトリの該当実装のみでした。 これでは確かにキャッチアップは難しいだろうと感じたので、Steep のエラーリファレンスを作ってみました。ググってヒットするのが目的なのでテックブログとして公開してインデックスされることを期待します。 各エラーの説

エンジニアリング本部 プラットフォームエンジニアリング1G 橋本です。我々のグループでは業務の柱の一つとして、クラウドインフラの構築・運用を行っています。その中でAmazon Aurora MySQL（以下、AuroraもしくはAurora MySQL）のアップグレードがビジネスインパクトが大きい作業となりました。本記事はAurora MySQLアップグレード方法の検討について記述した投稿になります。 この記事のまとめ 前提情報や課題感について Blue/Green Deploymentsによるアップグレードとは もしもの場合はロールバックしたい 検討したロールバック手法 DMS方式 リストア方式 逆レプリ方式（没案） 困った。どうしよう？ タイムリーな機能を教えてもらえた？ SwitchOver時に静止断面を教えてくれる 逆レプリ（新案）はどうなるのか？ いままでの方式案との比較 まとめ

こんにちは、タイミーのデータアナリティクス部でデータアナリストをしている夏目です。普段は主にタイミーのプロダクトに関する分析業務に従事しています。 本日はタイミーにおいて、効果検証設計を施策前に正しく行える仕組みづくりと効果検証設計・結果を一元的に管理できるデータベースについてご紹介します。 解決したかった課題 タイミーでは、プロダクト、マーケティング、営業組織などで様々な施策が行われています。しかしながら、それらの施策の結果を判断する効果検証には課題も多く存在しています。今回は以下の２つの課題にフォーカスしてブログを書きます。 効果検証設計が事前になされていない施策があった 効果検証設計や検証結果がバラバラに保管され、会社として知見が溜まっていなかった まず１つ目の「効果検証設計が事前になされていない施策があった」に関してです。タイミーではアナリストの数も限られており、事前に全ての施策に

タイミーでバックエンドのテックリードをしている新谷（@euglena1215）です。 この記事は先日公開した「前編：YARD から rbs-inline に移行しました」の後編となっています。前編では rbs-inline の紹介、移行の目的などをまとめています。前編を読んでいない方はぜひ読んでみてください。 tech.timee.co.jp 後編では実際の移行の流れや詰まったポイント、今後の展望について紹介します。 移行の流れ 1. 型をやっていくことを表明する 2. rbs-inline のセットアップを行う 3. YARD から rbs-inline への移行を進める 4. 後片付け sord gem の削除 rbs subtract をやめる 今後の展望 型検査を通す リアルタイムな実装へのフィードバック まとめ 移行の流れ YARD が日常的に書かれている状況から YARD がほ

タイミーでバックエンドのテックリードをしている新谷（@euglena1215）です。 タイミーのバックエンドはモノリスの Rails を中心に構成されています。そのモノリスな Rails に書かれていた YARD を rbs-inline に一通り移行した事例を紹介します。 前編では、rbs-inline の紹介と rbs-inline への移行理由について触れ、後編では実際の移行の流れや詰まったポイント、今後の展望について触れる予定です。 rbs-inline とは RBS 活用推進の背景 移行理由 1. YARD(sord) よりも rbs-inline の方が表現力が高い 2. YARD は書いていたが yardoc は使っていなかった 3. rbs-inline が今後言語標準の機能になっていく rbs-inline とは まずは rbs-inline について簡単に紹介します。

読んで欲しいと思っている人 POやステークホルダーと品質について共通言語や目標が欲しい開発者 開発者と品質について共通言語や目標が欲しいPO スクラムで品質について困っている人 読むとわかること 完成の定義（Definition of Done）とはどんなものか スクラムと非機能的な品質の関係性 タイミーのWorkingRelationsSquadでどんな完成の定義を作り、活用していきたいと思っているか 完成の定義（Definition of Done）とは インクリメントが常に守るべき状態のことです。スクラムガイド1では以下のように説明されています。 完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を⽰した正式な記述である。 プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕⽣する。 つまり完成の定義を満たしていない成果物は、いかに優れた機能であっ

タイミー QA Enabling Teamのyajiriです。 去る6月28日〜29日の2日間、ファインディ様主催の「開発生産性カンファレンス2024」に参加してきました。 （タイミーには世界中で開催されるすべての技術系カンファレンスに無制限で参加できる「Kaigi Pass」という制度があり、今回もこれを利用して新潟からはるばる参加してきました。） productpr.timee.co.jp タイミーでは弊社VPoE(VP of ええやん Engineering)の赤澤の登壇でもご紹介した通り、チームトポロジーを組織に適用し、プロダクト組織の強化と改善にチャレンジしています。 speakerdeck.com この登壇でも紹介されておりますが、私自身もイネイブリングチームの一員として、プロダクト組織全体のQA（品質保証）ケイパビリティの向上や、障害予防プロセスの改善に取り組んでいます。 開

株式会社タイミーのkatsumiです！ dbtのバージョン1.8以上を利用することで、unit testsが利用可能になります。今までもSingular テスト（単一テスト）やGeneric テスト（汎用テスト）は可能でしたが、テストデータを利用した単体テストも行うことができます。 導入準備 dbt-coreの場合 dbt v1.8 以上を利用してください。 dbt-cloudの場合 2024/06/12時点では dbt「Keep on latest version」を選択することで利用できます。 弊社ではunit-test用の環境のみlatest versionを利用しています。 Unit Testの基本 # run data and unit tests dbt test # run only data tests dbt test --select test_type:data #

こんにちは、タイミーの @masarakki です。 先日、5月15日から3日間開催された「RubyKaigi2024」に参加しました。 本記事で取り上げるのは、そのRubyKaigi2024の最後のセッションであるmatzのキーノートで、「これが入ったらRuby 4.0」とまで言われた @tagomoris 氏のNamespace機能。 セッション終了後、目の前に本人が座っていたので「責任重大だねwww」と煽りに行こうとしたところ、感極まって帽子を目深に被りなおしている瞬間だったのでそっとしておきました。 というわけで、セッションの内容 は他にいくらでも記事があると思うので、実際に手を動かしてみようと思います。 参考: https://gist.github.com/tagomoris/4392f1091f658294bd4d473d8ff631cb 作業ブランチが Namespace

5月15日から17日の3日間、RubyKaigi 2024が沖縄県那覇市で開催されました。 rubykaigi.org タイミーには世界中で開催されるすべての技術系カンファレンスに無制限で参加できる「Kaigi Pass」という制度があります。今年もこの制度を活用してタイミーから総勢12名のエンジニアが参加しました。 今回から2回に分けて、各エンジニアが印象に残ったセッションの感想を参加レポートとしてお届けします。 Good first issues of TypeProf rubykaigi.org このセッションでは、動的型付け言語が苦手とするエディタ上でのエラー表示、コードジャンプ、コード補完などの機能を公式で提供しようとしている TypeProf の紹介と、TypeProf に貢献するための方法や tips の紹介がメインでした。 手元で TypeProf を動かして遊んでみる方法

こんにちは、タイミーでデータサイエンティストとして働いている小栗です。 先日、群馬大学にご招待いただき、大学生向けにキャリアに関する講演を行いました。 講演や学生との交流を行うにあたり、データサイエンティストの仕事やキャリアについて考える時間が自然と発生しました。 この記事では、学生からいただいた以下の質問をテーマに据えて、私やタイミーの事例を紹介しつつ考えてみます。 大企業とベンチャー企業のデータサイエンティストはどう違う？ 未経験からデータサイエンティストを目指すには？ 大学生向けに講演を行いました 今回、「群馬大学 グローバルフロンティアリーダー（GFL）育成プログラム」の同窓会にご招待いただき、大学生向けに講演を行いました。 私自身もGFL育成プログラムの修了生であることから、今回は講演のご依頼をいただき、発表を行いました。その後、学生との座談会や交流会に参加させていただきました。

こんにちは。バックエンドエンジニアの須貝（@sugaishun）です。 今回はタイミーが本番運用しているRailsアプリケーションに対してRuby3.3.0へのアップデートを行った（YJITは引き続き有効なまま）のでその結果をご紹介したいと思います。 昨年弊社のid:euglena1215が書いたエントリーのRuby3.3.0版です。 tech.timee.co.jp 前提 タイミーのWebアプリケーションとしての特性は基本的には昨年と変わりありません。ですので、昨年の内容をそのまま引用させてもらいます。 タイミーを支えるバックエンドの Web API は多くのケースで Ruby の実行よりも DB がボトルネックの一般的な Rails アプリケーションです。JSON への serialize は active_model_serializers を利用しています。 今回の集計では API

はじめに こんにちは、タイミーでバックエンドエンジニアをしている新谷、須貝、難波です。 2月10日に広島国際会議場で YAPC::Hiroshima 2024 が開催されました。タイミーはGold Sponsorとしてブース出展をしており、エンジニアが3名とDevEnable室が3名の総勢6名で参加させていただきました。 どのセッションも興味深かったのですが、この記事では我々が拝見したセッションのうち特に印象に残ったものをいくつかピックアップしてご紹介します。 なお、タイミーには世界中で開催されている全ての技術カンファレンスに無制限で参加できる「Kaigi Pass」という制度があり、エンジニアはこれを使って参加しております。詳しくは下記のリンクをご覧ください。 productpr.timee.co.jp 経営・意思・エンジニアリング speakerdeck.com 普段我々が行なっている

イベント概要 2023年11月15日に「GENBA #1 〜RubyとRails開発の現場〜」と題してRuby/Railsでの開発に関するトピックでタイミーとエンペイ社合同で勉強会を開催しました。 その中でタイミーバックエンドエンジニアのpokohideさん（@pokohide）の発表「Railsアプリで秘匿情報を環境変数からCredentialsに移行した話」をイベントレポート形式でお届けします。 登壇者紹介 Credentialsとは Credentials は、Rails 5.2から追加された秘匿情報を管理するための仕組み※1 で、Rails 6から複数の環境をサポート※2 しています。 【主な登場人物】 暗号化ファイル： config/credentials/.yml.enc 復号用の伴： ENV[”RAILS_MASTER_KEY”] or config/credentials/

イベント概要 2023年11月15日に「GENBA #1 〜RubyとRails開発の現場〜」と題してRuby/Railsでの開発に関するトピックでタイミーとエンペイ社合同で勉強会を開催しました。 その中でタイミーバックエンドエンジニアの正徳さん a.k.a 神速さん（@sinsoku_listy）の発表「Railsアプリと型検査」をイベントレポート形式でお届けします。 登壇者情報 Railsアプリと型検査 RBSの基本 RBSとは RBS（Ruby Signature）は、Ruby 3.0から導入された言語機能で、Rubyのコードに型情報を追加し、型検査と入力補完を可能にするための言語です。RBSファイルの拡張子は .rbsで、通常はプロジェクト内の sig/ ディレクトリに配置されます。 RBSのメリット RBSの主なメリットは「型検査」と「入力補完」の2つがあります。 型検査とは 型

はじめに 私自身の事例 日々の学習・研究時間の確保 育児との折り合い パートナーや家族のサポートの重要性 日々の学習や研究の効率化 効率的な勉強法や研究の進め方の文献 社会人の特権のツールへの投資 ストレス管理と心の健康 タイミーという最適な環境 育児への支援制度 自己研鑽への支援制度 DSグループでの働き方 まとめ はじめに こんにちは、株式会社タイミーのデータエンジニアリング部データサイエンス（DS）グループ所属の貝出です。 私は現在タイミーで働きながら、育児しつつ、社会人大学院（修士）に通っています。今回のブログでは、仕事・育児・社会人大学院をどう調整して進めていくかについて書いていきたいと思います。 私自身の事例 簡単な私のプロフィールとしては、以下となります。 妻と一歳の息子の三人家族 妻は2023年度までは育休を取得予定 タイミーで週5リモートワーク勤務 JAIST博士前期課程

タイミーでバックエンドエンジニアをしている新谷 id:euglena1215 です。 今回は社内で決めたコーディングルールに強制力を持たせるために CustomCop を作った話を紹介します。 背景 タイミーの Rails アプリケーションには /app/services ディレクトリがあり、 Service クラスが存在しています。 これまで社内で Service クラスは、なるべく使わない方が好ましいものの、どんな時に使っていいかは特段明言されていない状況でした。 その結果かは分かりませんが、一部の機能では Service クラスを多用し Service クラスが Service クラスを呼んでいるなど複雑になっており、コードリーディングの負荷が高まっていました。 この現状に課題感を持った @rhiroe が以下のような問題提起を行いました。 この問題提起を受け、チーム横断の技術領域ご

こちらはTimee Advent Calendar 2023 シリーズ1の25日目の記事になります。 昨日は @tomoyuki_HAYAKAWA による Swift Concurrency AsyncStreamを使ってみる #Swift - Qiita でした。 タイミーでバックエンドエンジニアをしている id:euglena1215 です。 メリークリスマス🎄 みなさんの手元にはプレゼントは届いているでしょうか。 Ruby の世界では Ruby コミッターサンタさんがクリスマスプレゼントとして新しい Ruby バージョンをリリースしてくれます。 今年は Ruby 3.3 ですね。個人的には 3.3 の YJIT がどれだけ速くなるのか楽しみです。 また、新しいバージョンのリリースにはアップグレードがつきものです。アップグレードせずには新しいバージョンの恩恵を受けることはできません。

はじめに こんにちは、マッチング領域でバックエンドエンジニアをしているぽこひで ( @pokohide ) です。 タイミーのアドベントカレンダー2日目の記事です。 今回は、タイミーのプロダクト組織で毎週開催している技術的な雑談を行うテックトークの紹介をします。なぜ開催しようと考えたか、どのように運用をしているかなどをお話しします。 はじめに 開催の背景 毎週ゆるく開催するテックトークについて テックトークの仕組み化 会の説明や目的の共有 WINの共有 ポストモーテムの学び共有 雑談タイム やってみて さいごに 開催の背景 タイミーのプロダクト組織では、働き方の柔軟性を担保する観点などからフルリモートという働き方を選択しています。また、タイミーではチームトポロジーを採用しており、それに沿ってチーム構成などを考えています。 チームトポロジーの変遷や取り組みについてはCTOとCPO（発表当時は

この記事はTimee Advent Calendar 2023シリーズ 1の1日目の記事です。 はじめに こんにちは、タイミーでバックエンドエンジニアをしている須貝（@sugaishun）です。昨年は弊社でアドベントカレンダーに取り組んだか覚えていないのですが、今年はなぜかいきなり3トラックで臨むということで、非常に勢いがあるなと思いました。量と勢いで攻めていくところが弊社らしいなと感じています。全て完走できると良いですね。 さて私はその中のひとつのトップバッターということで、タイミーのRailsアプリケーションについて弊社のシニアなエンジニアたちと雑談した内容を座談会風にお伝えできればと思います。事の発端は弊社Slackのバックエンドエンジニアが集まるチャンネルで「タイミーのRailsアプリケーションの健康度はどのくらいなのか？」という会話をしたことでした。その時の私の感想は「人によって