タグ

ブックマーク / tech.timee.co.jp (7)

  • 【イベントレポート】「Railsアプリと型検査」 - Timee Product Team Blog

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

    【イベントレポート】「Railsアプリと型検査」 - Timee Product Team Blog
  • BigQueryにおけるdbtの増分更新についてまとめてみた - Timee Product Team Blog

    はじめに ※Timeeのカレンダー | Advent Calendar 2023 - Qiitaの12月8日分の記事です。 okodooooooonです BigQueryの料金爆発。怖いですよね。 dbtでの開発が進んでたくさんのモデルを作るようになると、デイリーのビルドだけでも凄まじいお金が消えていったりします(僕はもう現職で数え切れないくらいやらかしてます)。 コストの対策として「パーティショニング」「クラスタリング」などが挙げられますが、今回は「増分更新」の観点で話せたらと思います。 「dbtのmaterialized=’incremental’って増分更新できておしゃれでかっこよくてコストもなんとなく軽くなりそう!」くらいの認識でさまざまな失敗を経てきた僕が、BigQueryにおけるincrementalの挙動を説明した上で、タイミーデータ基盤における増分更新の使い方についてまとめ

    BigQueryにおけるdbtの増分更新についてまとめてみた - Timee Product Team Blog
  • タイミーのRailsアプリをシニアなエンジニアが採点したらだいぶ辛口だった - Timee Product Team Blog

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

    タイミーのRailsアプリをシニアなエンジニアが採点したらだいぶ辛口だった - Timee Product Team Blog
  • RedashをFargate, Datadog, Terraformで構築/運用する - Timee Product Team Blog

    こんにちは、タイミーSREチームの宮城です。 今回は弊社がRedashをFargateで構築/運用している話を紹介します。 背景 タイミーでは、CSやセールスのKPI策定から毎月の事業数値に至るまで、Redashが様々な用途で活用されています。 Fargateで構築する以前はEC2上のdocker-composeで運用されていましたが、以下の課題がありました。 オートスケールできないため、クエリが詰まってCPUが100%になってサービスが停止する。 その度slack上から再起動していた セットアップしたエンジニアが退社しており、インフラ構成図やノウハウの共有、IaCによる管理ができていない。 クエリやダッシュボードなどのデータの定期的なバックアップができていない。 v7系からv8系へのアップデートがしたいが、アップデートによる影響範囲がわからず恐怖感がある。 事業に大きく関わるサービスなの

    RedashをFargate, Datadog, Terraformで構築/運用する - Timee Product Team Blog
  • タイミーのデータ基盤品質。これまでとこれから。 - Timee Product Team Blog

    はじめに 以前のデータ基盤 3つの問題解決と振り返り 問題1: データパイプラインの更新遅延 解決策 実装 振り返り 問題2: 分析チームへのクエリ修正依頼の増加 解決策 実装 振り返り 問題3: ETLパイプラインにおける加工処理の負債 解決策 実装 振り返り これからの品質に関する改善 はじめに 初めまして、タイミーのDRE (Data Reliability Engineering) チームの土川(@tvtg_24)です。 記事ではデータ品質の保守に着目してここ1年くらいで試行錯誤したことを振り返っていきたいと思います。 対象にしている読者は以下の方々です。 データ品質について考えている方 データ分析の品質担保に困っている方 ETLからELTへの基盤移行を考えている方 この記事は Data Engineering Study #11「6社のデータエンジニアが振り返る2021」 -

    タイミーのデータ基盤品質。これまでとこれから。 - Timee Product Team Blog
  • バッチ処理の改善〜トランザクション範囲の最小化〜 - Timee Product Team Blog

    後編(冪等性の設計導入)へ はじめに こんにちは。タイミーのバックエンドエンジニアの中野です。よくGopherくんに似てると言われます。 記事では月次で実行している「締め」のバッチ処理に関する一連の技術的改善について掲載します。弊社のプロダクト「タイミー」は著しい事業成長に伴いデータ量が急増してきています。そこで今回はデータ量の急増を背景とした中長期的なバッチ処理の設計改善にどのように取り組んできたのかをご紹介したいと思います。バッチ処理に関する技術的改善の記事は前編・後編の2部構成をとっています。前編はバッチ処理におけるトランザクションの改善をテーマに、後編ではバッチ処理に冪等性の設計を導入したことをご紹介したいと思います。 今回は前編のトランザクションの改善をテーマにご紹介します。すでに番稼働しているアプリケーションにおいてトランザクションの範囲が大きい場合にどのような問題が発生し

    バッチ処理の改善〜トランザクション範囲の最小化〜 - Timee Product Team Blog
  • t_wada さんに「質とスピード」について講演していただきました - Timee Product Team Blog

    はじめに こんにちは、フロントエンドエンジニアの樫福 @cashfooooou です。 先日、 和田卓人氏(以下、 t_wada さん)に「質とスピード」というテーマで講演をしていただきました。 この講演にはエンジニア以外の方々も参加してくれました。 僕は学生時代に t_wada さんのテスト駆動開発についての講演を聞いたことがあり、それ以来テスト駆動開発を取り入れるようになりました。 今回の講演でも、なにか気づきが得られるとうれしいなあとワクワクしながら参加しました。 はじめに こんな講演でした 冒頭で投げられた問い 犠牲にされがちな「品質」とはなにか 内部品質を犠牲にしたときのスピードの損益分岐点はどこか 講演会の振り返り エンジニアの振り返り エンジニア以外の参加者の感想 おわりに こんな講演でした 講演の内容を簡単にまとめてみました。 t_wada さんが公開されているこちらの資料

    t_wada さんに「質とスピード」について講演していただきました - Timee Product Team Blog
  • 1