はてなブックマーク

こんにちは。プロダクト開発エンジニアのプリン(@プリン)です。High Linkでは主にフロントエンドを担当しています。最近は趣味でプログラミング言語のZigを触っています。 本題ですが、カラリアの開発でE2E Testを始めたのでその取り組みを紹介させていただきます。 前提条件 弊社では「カラリア 香りの定期便」を開発しています。 カラリアのバックエンドがRuby on Railsで実装されているのに対し、フロントエンドはReact(Next.js)で実装されています。なので以下はReactを前提にお話しさせていただきます。 カラリアフロントエンドの課題 バックエンドはテストが拡充されていますが、フロントエンドにはほとんどテストがありません。 そして最近はグロースの勢いが加速し機能追加が増えてきています。直近では金曜を除き毎日5回前後、リリースされています。それに伴いフロント起因の障害が

こんにちは、株式会社High Link CTOの nogaken(@nogaken1107)です。 プロダクト開発企業にとって、データ負債は大敵です。 要件に合わないデータ構造、過去データの欠損、不整合データの存在、etc。 これらデータに関する負債は、開発スピードの悪化や分析業務の阻害などを通じて事業に大きな悪影響を及ぼします。 弊社で開発している香り商品ECのプラットフォームである Coloria (https://coloria.jp)は、サービス提供開始から5年が経過しています。その中で、多くのデータ負債を生み、そしてそれらを返済しながらサービスを運営してきました。（そしていまも、現在進行形で返済を続けています。） データ負債は、発生させないことが理想ですが、プロダクトの要件の変化が不確実である以上、0にすることはできないと考えています。特に、リソースの限られたスタートアップ企業で

はじめに こんにちは、ハイリンクで開発エンジニアをしていますタイガです。この会社に入社してから早いもので半年以上経過しました。 今回は「カラリア 香りの定期便」事業の開発に関わることで感じた我々のチームの特徴とそのチームの中で求められる開発エンジニアの役割についてお伝えしたいと思います。 プロダクト志向なチームについて 私たちハイリンクのプロダクト開発の一番の特徴として、「全メンバープロダクト志向」であることが挙げられます。これはプロダクトマネージャーはもちろんのこと、開発エンジニアやデータ分析エンジニア、デザイナーチームも含めてすべてのメンバーが意識していることです。 プロダクト志向とは、製品やサービスの全体的な品質、ユーザー体験に重点を置く考え方で、どうすれば自社のプロダクトがユーザーへの価値を最大化できるのかを第一に考えることと定義できるのではないかと思います。 そのため、新しい機能

こんにちは、High Linkでデータエンジニアをしている谷口(@ytaniguchi811)です。 私たちは、Webサービス「カラリア 香りの定期便」を運営しており、ユーザーの行動データを基にサービス改善を日々行っています。 その中でも、ユーザーがどんな経路でサイトに訪問したかという情報を分析するために「Googleアナリティクス4」(以下、GA4)とBigQueryを組み合わせて利用しています。 ユーザーの流入経路の定義はさまざまですが、私たちはその中でも「セッションごとの最後の流入チャネル」を採用しています。 しかしながら、BigQuery Exportされたデータにはデフォルトでこの情報は用意されておらず、自前で抽出する必要があります。 本記事では、BigQuery ExportされたGA4データをもとに「セッションごとの最後の流入チャネル」を分析するときの注意点と実際の抽出方法を

株式会社HighLink ロジスティクスエンジニアのかんたろう(@kantarow)です。 私たちは複数のチームで一つのステージング環境を利用しています。masterブランチが更新されるごとにステージング環境へのデプロイが行われ、リリース前には必ずここで動作確認を行います。 このmasterマージによるデプロイには問題が無いのですが、master以外のブランチの動作確認を行うために手動デプロイを行った場合、ステージング環境での検証が中断される問題が起こります。 そこで、Pull Requestごとに自動で検証環境を立ち上げる仕組みを構築することで、この課題を解決しました。 本記事では、この解決方法に至った経緯と、運用を始めて改善されたことをご紹介します。 これまでのリリースフローの問題 カラリアの開発では、masterにマージされた変更が自動でステージング環境にデプロイされ、担当する開発者

株式会社High LinkのCTOをやっている nogaken (@nogaken1107)です。 最近はChatGPTなどのLLM系のアプリケーションを触って楽しんでいます。 ハイリンクでは「カラリア 香りの定期便」などのサービスを開発しています。 「カラリア 香りの定期便」は2021年まで、フレームワークとしてはRuby on Rails (以下Rails)単体で書かれていましたが、デザインリニューアルと合わせて2021年前半から1年間強の時間をかけてフロントエンドをNext.jsにリプレースしました。 結果として開発体験が向上し、気軽に実装できるデザインの幅が広がり、エンジニアの採用面でもメリットが得られました。 この記事では、カラリアのフロントエンドリプレースの背景、技術選定、リプレースのフロー、課題と、リプレース全体の振り返りについて紹介します。 現在、RailsでWebアプリケ

はじめに こんにちは、ロジスティクスマネージャーの横山（@katsuya_high）です。 ハイリンクでは「COLORIA (カラリア)」という香り商品のECサービスを運営しています。中でも「カラリア 香りの定期便」は、毎月ユーザが選んだ香り商品をお届けする月額制のECサービスです。従来購入障壁が高かった香水をはじめとする香り商品を手軽に試し、楽しむことができます。 「カラリア 香りの定期便」では1ヶ月で使い切れるサイズの香水をお届けしており、完品をそのままお届けするサービスと比べると特殊な物流作業を必要とします。 弊社では、その物流業務を支えるシステムを自社開発しており、今回は自社開発に至った経緯について記載させていただきます。 カラリアというサービスの全体構成や技術スタックについてはこちらの記事を読んでいただければ幸いです。 tech.high-link.co.jp カラリアの特殊な物

はじめに こんにちは, 基盤開発チームの奥山(okue)です. High Link では, BigQuery を活用してデータの分析や可視化, 機械学習への活用を行っています. アプリケーション DB の BigQuery へ転送には, AWS ECS Fargate + Embulk という構成でバッチ処理を実行していましたが, いくつか運用上の問題点がありました. 本記事では, BigQuery へDBのデータを転送するバッチ処理を, AWS Step Functions + AWS ECS Fargate + Embulk で実装し改善した話をします. 改善前の構成と問題点 構成 改善前のバッチ処理は下図のような構成でした. AWS RDS MySQL には 60個以上のテーブルがありますが, それらを BigQuery へ転送する処理を1つの ECS Task で実行していました.

こんにちは、プロダクト開発エンジニアの神長(kaminaga)です。 High Linkでは「カラリア 香りの定期便」などのサービスを開発しています。 coloria.jp 「カラリア 香りの定期便」はNext.jsを利用して構築されており、今回はユーザー体験の向上を目的に、データ取得/キャッシュライブラリの SWRを導入した話です。 目次 SWR導入の背景 【発端】ブラウザバック時スクロール位置を復元したい scrollRestoration を設定したが、スクロール復元位置がずれる Ajaxによるレイアウトシフトをどう回避するか 対応策① スクロール位置を保存しておき、ブラウザバック時に一定の遅延後、スクロール位置を復元する 対応策② APIキャッシュを導入し、非同期APIコールによるブラウザバック時のレイアウトシフトが発生しないようにする Next.jsにAPIキャッシュ(SWR)を

はじめに こんにちは。High Linkのデータエンジニアの芦川 (@hirorororo772) です。 私たちが運営する香水サブスクサービス「カラリア」では、「香水診断」、「レコメンド機能」、「フレグランスプロフィール」など、データを活用したさまざまな機能を提供しています。 こういった機能を提供するためには、ロジックの開発だけでなく、安定的に提供するための基盤や開発を加速させるためのCI/CD基盤やデータパイプラインの構築（MLOps）が重要になってきます。 今回は、カラリアにおけるデータを活用した機能の裏側についてご紹介したいと思います。 スタートアップである私たちは、小さくはじめてスピードは保ちつつ、中長期的に開発スピードや運用コストにレバレッジを効かせられるよう意識してきました。 設計面で考慮したポイントや、実際に運用してみた所感なども併せてご紹介いたしますので、これからミニマム

はじめに こんにちは。株式会社High Linkのデータユニットマネージャーの芦川 (@assy) です。 私たちのチームでは、データを強みとした事業価値創出を促進するために、データ基盤の整備やデータマネジメント、全社的なデータ利活用レベルの引き上げに取り組んでいます。 データマネジメントをしていると、「誰が作ったかわからない野良のテーブルが乱立している」ことや「BigQueryコンソール上でviewを定義してしまってコードレビューができない」さらには、「テーブル間の依存関係がわからず削除できない」といった課題にぶつかる方は多いんじゃないでしょうか。 私たちもまさにこのような問題に直面し、導入したのがdbtです。 今回は、dbtの導入に至る経緯や選定の理由、dbtをどう活用しているのかといった話を共有させて頂こうと思います。 私たちのようにデータマネジメントにがっつり人的リソースを割けない