はじめに 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勉強会を開催することになりま

はじめに マッハバイトでエンジニアとして働いている今井です。 昨年2月にリブセンスに入社し約1年が経ったため、この1年を振り返りながら、リブセンス・マッハバイトでどのような働き方をしているか、その一例を紹介できればと思います。 はじめに 入社前 入社後 今やっていること 実際に働いてみて オンボーディングとサポート 会社としての働き方の話 学び 入社前後のギャップ Good 人のよさ 距離感の近さ 新しいチャレンジに対する柔軟さ Bad 技術的負債 今後やりたいこと まとめ 最後に 入社前 入社前は、インターンとしての期間を含め２年間ほど、Webベンチャー企業に所属していました。 人数の少ない組織であったことから、一人一人の携わる範囲が広く、バックエンドからフロントエンド、またAWSを利用してインフラ構築を行っていました。 また、成果や実力が認められると裁量が与えられる環境でもあり、入社か

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

リブセンス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 エージェントをインストールして、ネットワーク到達性や、プラットフォームの脆弱性を診断し、潜在的なセキ

インフラエンジニアの中野(etsxxx)です。 Slackで少し凝った機能・・・例えば簡単な演算ツールを作ったり、ChatOpsを行おうとすると、コードを書いて動かしたくなることがあります。しかし、やりたい処理は簡単だったとしても、従来は、”書いたコードをどこで動かすか”に悩んだものです。 Pipedreamはまさにその救世主となりうるサービスで、感銘を受けたので利用法の紹介記事を書いています。 ちなみに、この記事は元々2023年3月に書いたメモが元なので、スクリーンショットが古い部分があったらごめんなさいｗ Pipedream is 何？ Slackのスラッシュコマンドを作る 利用イメージ PipedreamでTrigger(入力)を準備 Slack管理画面でスラッシュコマンドの準備 PipedreamでPythonステップを追加 動作テスト 最後に雑多に感想を Pipedream is

2021年9月からマッハバイトに業務委託として参画している草間と申します。 iOSエンジニアとして参画し、今ではandroid・Web側も担当するようになり楽しく業務しています。 前回は導入した話をしました。 今回は、SwiftUIの導入で苦労した話をします。 OSSの動きが想定と違った問題 アニメーションのViewが画面サイズより大きくなる 画面サイズの違いで発生した問題 scaledToFitだけでは画像サイズがよしなに広がってくれない？ 実機でしか発生しなかった問題 文字が省略されてる！？ 検証したこと 検証環境としてプロジェクトを3つ用意 文字が省略されてしまう条件は？ まとめ 最後に Appendix ViewModifier OSSの動きが想定と違った問題 アニメーションのViewが画面サイズより大きくなる マッハバイトiOSアプリでは、アニメーションの実装にLottieを利用

これは 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で可視

はじめに ご無沙汰しています。転職会議事業部でエンジニアリングマネージャーと開発者をやっている落合です。もうすっかり春ですね。 さて、つい先ほどプレスリリースも発表されましたが、本日転職会議にてChatGPTのAPIを利用した企業口コミの要約コンテンツを掲載する新機能の試験提供を始めました。 prtimes.jp リリース速度優先でまだスマホでしか見られないのですが、こんな感じの画面になっています。もしご興味あれば、スマホでこちらからアクセスしてみてください。 リブセンスの口コミ要約キャプチャ さまざまなみなさんのご協力もあり、ChatGPTのAPI公開、検討開始から3週間ぐらいでなかなかいい感じに形にできそうだぞと喜んでいたのですが、リリースが見え始めた開発後半の夕方、機能リリースと合わせた広報戦略を練っていた企画陣から恐ろしい無茶振り相談が飛んできました。 企画のみなさん「機能リリース

こんにちは。リブセンスエンジニアブログ運営です。 リブセンスではSIerなどの受託開発企業の出身のエンジニアが多数活躍しています。 本記事では3名の社員へのインタビューを通じ、入社理由や転職後のギャップ、リブセンスの魅力について聞いてみました。 インタビュイー紹介 iwtnさん Kさん satoさん − もともとどんな仕事をしていましたか？ − 転職を考えた理由はなんですか？ − リブセンスに入社しようと思った理由を教えてください。 − 入社後、期待通りだったこととギャップがあったことを教えてください。 − 入社後、どんな学びや成長がありましたか？ − ご自身の転職前と似たような環境で働いていて、リブセンスに興味を持ってくださった方向けに一言お願いします！ Join us! インタビュイー紹介 iwtnさん 入社5年以上。HR、不動産、新規事業といった事業部を経験し、現在は転職ドラフトでW

リブセンスでデータエンジニアをしている富士谷です。 Software Designのデータベースに関連する特集記事を再構成した「データベース速攻入門 ～モデリングからSQLの書き方まで」が、2023年3月に発売されました。 gihyo.jp リブセンスがSoftware Design 2017年11月号に寄稿した「データ分析に効くSQL50本ノック」が、内容を更新して再掲載されました。 今回、再掲載にあたって、「SQL50本ノック」の内容の更新を私が担当しましたので、簡単に紹介します。 SQL50本ノック 「SQL50本ノック」は、SQL、特にSELECT文の演習問題集です。 PostgreSQLをDockerで立ち上げて、もっともシンプルな例から実行し、WHERE句、LIMIT句などを一つ一つ体験し、最後には、移動平均といった高度な文法を習得する事ができます。 これを読めば、SQLを使っ

大きなPull Requestのレビューがつらい 修正ファイル数が多いこと自体が問題なのではない 1つの内容に集中する 小さなPull Requestの作り方 リファクタリングの修正は気になっても別で出す Web API 1つに着目して実装を切り分ける 小さなPull Requestで作ったときのリリースの仕方 featureブランチを作って、そこから更にブランチを作っていく フィーチャートグルを使う 小さいPull Requestで小さくフィードバックをもらおう 大きなPull Requestのレビューがつらい 転職ドラフトでWebアプリケーションエンジニアをしている @iwtn です。 この記事ではチーム開発では当たり前になったレビューにおいて、修正されたファイルがたくさんあるとつらいよね、というお話と、その解決策を提示してみたいと思います。 昨今のWebアプリケーションなどのチーム開

こんにちは、インフラストラクチャーグループのyjszkです。2月から入社しました。 リブセンスにはバッチをECSとEventBridge Ruleで動かしている実装があります。EventBridge Ruleがなかなかの曲者で、UTCでしか時間を指定できません。 UTCで指定されたルールはいつ動くのかがわかりづらいですし、JSTでは1つのルールで済んだものがUTCでは2つ以上に分割されてしまうこともあります。 例えば、JSTで特定の曜日に10分ごとに実行するタスクがあるとします。 */10 * * * 0-3,5-6 * これがUTCだと3つになります。これはなかなかつらいです。 0/10 0-15 ? * 4 * 0/10 15-0 ? * 5 * 0/10 * ? * 1-3,6,7 * 一方、2022年11月にリリースされたAWSの新機能EventBridge Schedulerでは

こんにちは、かたいなかです。 『詳解システムパフォーマンス 第2版』の日本語版が2023/01/24についに発売されました！ www.oreilly.co.jp 私個人は原著で読んだのですが、他の人に強くおすすめしたくなるような内容でした。そこで、日本語版の発売に合わせてどのあたりが良かったのかなど、内容をご紹介します。 TL;DR パフォーマンス改善タスクの課題感 どんな本？ この本のどこがいい？ Linuxの仕組みを広く深く学べる パフォーマンスの観点での情報が豊富 どんなひとにおすすめできるか？ クラウドやコンテナが当たり前になってからSREになった人 Linuxの知識をアップデートしたいエンジニア 最後まで読み切るには？ あせらずゆっくり読んでいく Linuxの前提知識を仕入れてから読む 終わりに TL;DR 『詳解システムパフォーマンス 第2版』は、Linuxを深く学んで仕事に活

これは Livesense Advent Calendar 2022 DAY 23の記事です。 株式会社リブセンス アルバイト事業部エンジニアの村山です。 個人的に興味があり、チームの状態を測るための取り組みを少しずつ始めています。 その内容をブログにまとめてみました。 最後まで読んでもらえたら嬉しいです。 きっかけ 元々、チームの活動を測る良い方法は無いだろうか、という漠然とした疑問を持っていたのですが 当時の上司から「LeanとDevOpsの科学」という本を教えていただきました。 book.impress.co.jp 第二章「開発組織のパフォーマンスを計測」では、チームのパフォーマンスを測定するための効果的で信頼に足る基準は何か、について議論されています。 パフォーマンスを可視化することは組織の状態を把握し、改善に繋げるために重要な取り組みです。 ですが、古のソフトウェア業界で使われて