こんにちは。転職ドラフトでエンジニアをしている verdy_266 です。 今回は、 RubyKaigi に参加した結果、 OSS にコントリビュートできたよという自慢をさせてください。 Merged!! irb に redo 機能を実装しました まずは、今回コントリビュートした内容をご紹介します。 RubyKaigi で以下の発表を聞いたのですが、その中で Future Works として挙げられていたもののひとつを実装しました。 rubykaigi.org speakerdeck.com irb を実行した際に、入力内容を表示したり、カーソル移動を制御したりしてくれる Reline というライブラリがあります。 今回はこの Reline に、 redo （やり直し）機能を実装しました。 ここに自分のアイコンが表示されているの、嬉しすぎる…… 実装の簡単な解説 github.com こち

こんにちは、かたいなかです。 2024年2月に長年の悲願だったマッハバイトのメインDBのAuroraへの移行を完遂しました！！！ この記事では、どのようにマッハバイトのAurora移行を進めていったかを記事として残します。 なお、この記事の中では結構レガシーな部分の対応に苦しんだところも出てくるのですが、DB移行が終わったあとで、弊社内でこのレベルのレガシー対応を行う必要があることはほぼないと考えているので、リブセンスに興味を持っている方も安心して読んでいただければと思います。 やったこと プロジェクトの流れ テックリードから聞く初耳の単語: 『Mroonga』 状況をざっくりと調査 このコード使われてるの？使われてないの？ DMSの検証本格化 移行準備期 ついに、本番移行 Auroraに移行してよかったこと パフォーマンス改善 Performance Insightsが便利！！！ DB移

こんにちは、かたいなかです。 マッハバイトではシステムのオンプレからAWSへの移行を絶賛爆速で進めています。 そのなかでDB移行の下準備としてRidgepoleを導入することにしました。 今回はそのRidgepoleの導入について記事にまとめます。 Ridgepoleとは なぜRidgepoleを導入したのか AWS移行時にテーブル構造を変更する必要がある箇所がある： Ridgepoleで比較を容易に DMSのためにインデックスや外部キーをあとから別々に適用できる必要がある：Ridgepoleで不要な箇所をコメントアウトする GitHub ActionsでRidgepoleを動かす Pull Requestにスキーマの差分をコメント マージ/タグプッシュ時の実行 テーブル削除時の手動実行 Ridgepoleを使ってみてよかったこと エクスポートが楽なため導入しやすい DBスキーマがGitH

はじめまして。 採用広報チームの @iwtn です。 2023年上期の終わりの6月末に、リブセンスのエンジニアが集まって『Engineer Drink Up』を行いましたので、そのレポートをします。 Engineer Drink Upとは？ 当日のプログラム LT大会 ビアポン大会 歓談タイム 後日振り返り まとめ Engineer Drink Upとは？ リブセンスのエンジニアのための懇親会です。 普段リモートワークをしているエンジニアが集まり、LTをしたり、ポストモーテムを共有したりして盛り上がり、他の事業部のエンジニアとも繋がることを目的にしています。 現在リブセンスは東京の竹芝にオフィスがありますが、基本的にはフルリモートワークで働いており、全国にいるエンジニアが集まる機会は中々ありません。 今回は四谷に会場を借りて集まることになりました（もちろん交通費や遠方の人の場合は宿泊費が出

リブセンスでデータサイエンティストをしている北原です。普段はAnalyticsブログの方に記事を書いています。先月開催された2023年度人工知能学会全国大会で、紹介型マッチングアプリknewの満足度に関する発表をしてきたので、簡単に内容を紹介します。なお、発表タイトルは「提案型オンラインデーティングサービスにおける相手に対する満足度の因果探索」です。 異性と短時間対面したときに「付き合ってもいい」と思ってもらうためには何が大事だと思いますか？やっぱり見た目なんだろうか。いや、話が面白いほうがモテるんじゃないか。いろいろ意見はあると思います。knewでは5分間のビデオチャットを行なって相手に対する満足度を入力してもらっているので、これらのデータを分析することで異性に好感をもってもらうには何が大事なのかを調べることができます。このあたりを因果探索という方法で調べたのが今回の発表です。 knew

こんにちは。転職ドラフトでエンジニアをしている @verdy_266 です。 今回は、昨年末から取り組んでいた「指名禁止企業設定」のリニューアルについて、要件定義や実装で悩んだことが多くあったのでまとめます。 転職ドラフトでの仕事の進め方について、参考になれば幸いです。 リリースノート 指名禁止企業設定とは 指名禁止企業設定とは、ユーザーが特定の企業に対し、レジュメなどの情報を非公開にする機能です。前職や現職の会社を登録するケースや、以前に接触があったので関わりたくないという企業を設定することがほとんどのようです。 前職や現職の会社を登録するケースが多いことから、まだ転職ドラフトに登録していない企業も指名禁止できるようにしたいというニーズがあり、従来は「指名禁止ワード」を設定してそれに一致する企業が指名禁止になるような仕様になっていました。「株式会社リブセンス」を指名禁止にしたい場合は、指

はじめに CIの概要 出てきた課題と対策 ライブラリのtimeout値が固定値な上に短い ドキュメントにないパラメータがダマで増えた モニターのゾンビ化 想定したように設定が反映されずに手動で変更 YAMLのdiffツール(dyff)の自己主張が激しい 結局CI化するべきだったのか？ 得られたメリット 正直な感想と今後 はじめに インフラGの@yjszkです。先日は青森競輪と盛岡競馬に行ってきて負けました、盛岡のジャンボ焼き鳥が美味しかったです。 さて、前回の記事ではCronitorというサービスのコード化と、CIの構築を行ったことを書きました。 それを実際に運用してみたところ、いくつかの問題が発生しました。今回は、それに対して、現在進行形で苦労している話を書きます。 CIの概要 前回の記事にあるように、CIを構築しました。 GitHub Actionsを使用し、PRにコミットが積まれると

マッハバイトで絶賛進行中のシステムのAWS移行にあわせ、開発者向けのAWS勉強会を開催しました。 今回の記事では勉強会の模様を紹介します。 なぜ勉強会をすることになったのか？ マッハバイトでは、システムのオンプレからAWSへの移行をすすめています。この移行はAWSの知見があるインフラGのメンバー全員+マッハバイトの一部メンバーという構成で取り組んでいます。 made.livesense.co.jp made.livesense.co.jp AWS上で動いているシステムが増えていく中で、AWSの知識量が人によって大きく差があり、AWSまわりを触れるアプリケーションエンジニアが一部に限られた状態になりかけていました。 このまま一部の人だけAWSを理解している状態が続くのはまずそうだ、という認識がチーム内で生まれ始めたため、インフラGのメンバーが中心になって社内AWS勉強会を開催することになりま

みなさん、プレビュー環境してますか？どうも、かたいなかです。 以前、記事や登壇でIstioベースのPreview環境の構築方法をご紹介しました。 made.livesense.co.jp 外向けに発表したものの、Istioの運用工数や学習コストがネックとなってしまい、実際の転職会議の開発環境の導入にはいたっていませんでした。 最近になってGateway APIの実装例も増えてきて、Istio以外にもプレビュー環境でのヘッダを元にしたルーティングの実現において、現実的な選択肢となりそうなツールが増えてきました。そこで、Gateway APIのEnvoyによる実装であるEnvoy Gatewayを用いて、サービスメッシュを使用しないプレビュー環境の構築を試してみたため、この記事では構成例をご紹介します。 なお、今回の記事の中ではプレビュー環境の説明等について前回の記事と同様の説明を再度する箇所

テクノロジカルマーケティング部データプラットフォームグループの池谷です。 社内の Web ログ基盤を、GA4 と BigQuery をベースとする構成に刷新したプロジェクトについてご紹介します。 なにをしたか 弊社には Livesense Analytics (以下 LA) という AWS の Redshift を DWH としたデータ基盤があります。Web ログやアプリログだけでなく、事業部が保持するマスタデータのコピーも Redshift を通して社内に提供しています。ユーザー行動の分析や施策の評価、レコメンドのデータソース等で全社的に利用されています。 LA の歴史は長く、機能によっては 10 年近く提供し続けているものもあります。その中でも Web ログを収集し加工する部分は技術的負債も多く、運用面でも苦労していました。もともと Web ログの収集ツールは内製していたのですが、この

リブセンスVPoEの中野(etsxxx)です。 私はこれまでWorking Out Loud(WOL)というコミュニケーションスタイルを、所属した2チームで実践してきました。最初のチームでは7年、次のチームでは1年ほど運用しています。 最近、他のチームからも取り入れてみたいと相談されることがあったので、改めてWOLについて振り返りをしてみようと思い、この記事を書いています。 WOLとは？ 導入の経緯 1チーム目: WOLの原体験 2チーム目: 意図を持って始めたWOL WOLの導入を振り返る 導入前の課題感 実際にWOL導入初期にやったこと チャンネル削減 会話量を増やすための行動 WOL導入前後の比較 私が気をつけていたこと 積極的に絡みに行く 読み落としを責めない 長文をなるべく送らない 大事なメッセージは目立たせる スレッドが嫌いなことを言い続ける 集中したい時は、チャットを見ないで

はじめに LET運営の村山と毛利です。 社内の交流を活発にし、お互いの知識を伝搬する機会を設けるために、Livesense Engineer Talk（通称:LET）というチームを運営しています。 今回は、GitHub Copilot for Businessを社内導入して2ヶ月程経ったので、エンジニアにCopilotを使った感想を聞いてみました。 はじめに みんなの感想 ayumu838さん ここがよかった ここが惜しい 池谷さん ここがよかった ここが惜しい 赤坂さん ここがよかった ここが惜しい 中野さん ここがよかった ここが惜しい 富士谷さん ここがよかった ここが惜しい 渡辺さん ここがよかった ここが惜しい 鈴木さん ここがよかった ここが惜しい 今井さん ここがよかった ここが惜しい まとめ みんなの感想 みんなの感想をChatGPTに要約してもらうと、こんな感じになりまし

まえがき こんにちは、インフラグループの yjszk です。 インフラグループでは、Amazon Inspectorで検出された脆弱性への対応を定期的に行っています。 ただ、脆弱性情報を収集して適切な対応を行うプロセスは手作業です。作業が面倒であり、トイルとなっていました。 そこで、PythonとGitHub Actionsを使ってGitHub IssuesにAmazon Inspectorで検出した脆弱性情報を登録し、必要な対応内容がひと目でわかるようにしました。 この自動化により、より迅速な脆弱性対応が可能になりました。具体的には以下のようなIssueを自動作成しています。 Amazon Inspectorについて 概要は以下です。 EC2インスタンスにAmazon Inspector エージェントをインストールして、ネットワーク到達性や、プラットフォームの脆弱性を診断し、潜在的なセキ

これは LIVESENSE madeブログ 4月のお題 の参加記事です。 Livesense madeブログ4月のお題のひとつに「新生活」があります。 新しい環境に足を踏み入れる新卒エンジニアには、これから多くの挑戦が待ち受けています。 そんな新卒エンジニアを応援するため、おすすめの書籍をリブセンス社員に聞いてきました！ 気になった本があれば手にとってみてはいかがでしょうか。 プログラマ・Webエンジニア初歩 システム工学全般について幅広く学べる本 基本情報技術者試験のテキスト 『コンピュータはなぜ動くのか 第２版 知っておきたいハードウエア＆ソフトウエアの基礎知識』 プログラマとしての基礎知識 『リーダブルコード』 『Web API: The Good Parts』 『アルゴリズム図鑑』 『SQLアンチパターン』 インフラ 『AWSで実現するモダンアプリケーション入門』 『マスタリングT

これは LIVESENSE madeブログ 4月のお題 の参加記事です。 データプラットフォームグループの富士谷です。 ChatGPTのAPIの提供とポリシーの改変から、はや1ヶ月半くらい経ちました。弊社でも、ChatGPT（OpenAI API）を使った機能を開発し、転職会議や面接支援ツールのbatonnで、すでにリリースしています。 転職口コミサイト『転職会議』、ChatGPTのAIを活用した企業口コミの要約情報を提供開始 | 株式会社リブセンス 【業界初】面接最適化クラウド『batonn』、「ChatGPT」のAIを活用した面接内容の要約機能をリリース | 株式会社リブセンス 転職会議については、開発の裏側もブログで公開しています。 made.livesense.co.jp APIを使った機能開発や業務効率化は今後も模索していきたいと考えています。 重要なのは、各々がどのように使える

まえがき こんにちは、インフラグループの yjszk です。 今回は、Cronitorというツールについてご紹介します。Cronitorはジョブの状態を簡単に管理することができるモニタリングサービスです。 このサービスは、Cronジョブの監視を行うことができ、提供されているSDKは複数のプログラミング言語で利用可能で、設定をYAMLでエクスポートし、コード管理することができるのも魅力の1つです。 今回は、Python SDKを使用してCronitorを設定する方法について説明します。 まえがき Cronitorとは Python SDKによる設定のコード管理 GUIでのジョブ作成 SDKによる設定 既存設定のエクスポート コード化した設定の適用 Dry-Run GitHub Actionsによるパイプライン化の例 ハマりどころ 終わりに 参考 Cronitorとは Cronitorは、ジョ

はじめに ArgoCDを構成するコンポーネントについて ArgoCDのログ量問題に直面した背景 ロギングライブラリが複数あることによる苦労 ログレベルを調整した結果 おわりに はじめに インフラストラクチャーグループの @mom0tomo です。普段はマッハバイトのクラウド移行に取り組んだり、コーポレートサイトのCSS/JSと格闘したりしています。最近、少しずつ転職会議のKubernetes運用にも関わるようになりました。 転職会議では、KubernetesクラスターへのCI/CDツールとしてArgoCDを利用しています。 made.livesense.co.jp ArgoCDにはGUIがあるためアプリケーション開発者も親しみやすいなど利点が多いのですが、デフォルトで出力されるログが多く、必要以上にログデータを生成してしまうと言う問題がありました。とくにDatadogのようなログ分析ツール

こんにちは、かたいなかです。 みなさんが関わっているシステムでなぜか遅くて悩まされている処理はないでしょうか？ 最近、遅いAPIをDatadog Continuous Profilerを使用して調べました。どのように問題解決までつなげたかを記事にまとめます。 www.datadoghq.com TL;DR 特定のAPIが遅い問題が発覚 Continous Profiler導入 Continuous Profilerで計測してみると・・・ 問題修正 実際のところ まとめ 参考 TL;DR 遅い処理を改善しようと思ったらまずは計測してみること。 計測することで実は単純な問題であったことに気付けるケースがたくさんあります。また、的はずれな推測を元にでたらめな変更を繰り返してしまう事態を防げます。 通常のDatadog APMで原因がわからない場合には、Continuous Profilerで可視

こんにちは、かたいなかです。 最近、転職会議のEKSクラスタのワーカーノードをManaged Node Groupに置き換えました。 この記事ではManaged Node Group導入に際してどのような考慮が必要だったかを紹介します。 Cordon、Draining、Pod Disruption Budgetのおさらい Podが配置されないようにするCordon Podを他のノードに退避するDraining Drainingを安全に行うためのPod Disruption Budget 煩雑だったノードの入れ替え作業 Managed Node Group導入 Managed Node Groupの更新処理 Workflowの定義でPDBを指定 WorkflowのRetryPolicyをAlwaysに Managed Node Group導入後の更新処理 まとめ 参考 Cordon、Drai