STORES 予約 エンジニアの水野です。STORES 予約 の店舗管理画面で利用しているTypeScriptをv4.8からv5.5にアップグレードしたので追加された主な機能をおさらいしようと思います。 satisfies (v4.9) v4.9で実装されました。 型アノテーションのように型付けしつつ型推論も行う演算子です。 例を見てみましょう。 type Color = 'red' | 'green' | 'blue' const pallet: Record<Color, string | number[]> = { red: [255, 0, 0], green: '#00ff00', blue: '#0000ff', } // pallet.red => string | number[] pallet.redの型はstring | number[]となっています。これはRecor

はじめに こんにちは！ STORES 株式会社 リテール本部でエンジニアリングマネージャー( EM ) をしています、藤井( daitasu )です。 STORES はいま、会社全体が400名を超える規模であり、エンジニア部門だけでも100名以上の人数が在籍しており、ここ数年で組織として非常にスケールをしている会社になります。 従業員数の推移 こうしたスケール中の組織の中では、組織体制の変更も時としてあり、EM として新しい開発チームに後からJOINする、ということも度々あります。 新しくできたチーム、または、既に醸成しているチームに EM としてJOINする、というのはプロジェクトやカルチャー、メンバーステータスなど把握しないといけないことが山程あります。 こうした情報を早期に吸い上げておくことは、プロジェクトの進行としても、チームメンバーとのコミュニケーションの上でも、円滑に進めていく

社名変更に伴うGoogle Workspaceアカウントの引越し手順を解説します この記事は、 STORES PX Advent Calendar 2023 Spring の1日目の記事です。 はじめに こんにちは、STORES のPX部門IT本部でマネージャーをしている中野（@howdy39）です。 IT本部ではプロダクトづくりを支える社内ITを構築・運営しているのですが、社名変更という全社的なビッグイベントを最近行ったので、その中でIT本部が行ったGoogle Workspaceにおける社名変更対応について書いていこうと思います。 まず背景を軽く説明しますと、2022年10月1日に、ヘイ株式会社から STORES 株式会社へと社名変更を行いました。それに伴い、会社として使用しているドメインもhey.jpからst.incへ変更することになりました。*1 ドメインが変わることで、個人アカウ

STORES フロントエンドエンジニアの wattanx です。 2022/11/16、ついに Nuxt 3 が正式リリースされましたね。 nuxt.com 私たちのプロダクトである STORES でも Nuxt を利用しており、絶賛 Nuxt 3 への移行中です。 本記事では、私たちのプロダクトにおいてどのようにNuxt 3 に移行しようとしているのか紹介します。 また、これは STORES Advent Calendar 2022 の 11日目の記事です。 移行の基本方針 Nuxt 2 を利用しているプロダクトを Nuxt 3 に移行する場合、以下の2とおりの方法が一般的だと思っています。 Nuxt 2 から Nuxt 3 に直接移行する。 Nuxt 2 から Nuxt Bridge に移行する。その後 Nuxt Bridge から Nuxt 3 に移行する。 Nuxt Bridge

こちらは STORES Advent Calendar 2022 8日目の記事です。 みなさんこんにちは、STORES のリテール本部でフロントエンドのエンジニアリングマネージャーをしています、 daitasuと申します。 2022年の年の瀬、 STORES のフロントエンド組織は立ち上がりから約4年の月日を迎えました。 日々のカジュアル面談や採用活動のなかで、「STORES のいまの技術状況ってどんな感じですか？Nuxt化って進み具合どうですか？」といった質問を受けることがよくあります。 STORES のフロントエンドグループについて、対外的に全体像を示すような記事が今までなかったので、本記事では、下記を紹介していこうと思います！ STORES フロントエンドの成り立ち 技術負債の解消・改善にどのように向き合っているか 2022年末現在での主な技術状況 2022年現在のスナップショットを

はじめに hey のネットショップ開設サービス「STORES」 の開発フロントエンド組織で EMをしています、 daitasu と申します。 2022年の上半期、私たちのフロントエンドチームで「除雪部」という技術負債解消ワーキンググループ(以下、WGとします)を立ち上げました。 この記事では、「除雪部」とは何なのか、なぜ設立したのか、何をしているのか、半年間の振り返りをご紹介します。 「除雪部」とは 除雪部は、フロントエンド内で、通常のプロジェクト(以下、PJTとします) と並行して、有志数名で集まり、技術負債の解消をハンドリングするWGです。 フロントエンド関連で負債に感じている課題を集約し、優先度付け、必要な各所への連携やタスクの分解をして、「負債を各メンバーが対応可能な状態まで落とし込むこと」、「負債の解消を一歩でも前に進めること」を役割として動いています。 なぜ設立したのか STO

2022年6月7日に、テスト駆動開発者の和田卓人さんをお招きし、社内講演会をオンラインで開催しました！ 経緯 弊社では、2022年3月にテクノロジー部門のマニフェストとバリューができました。CTO 藤村が「和田さんの「質とスピード」のお話はテックバリューにも通じるところがあるのでは？」と思い、和田さんのお話をみんなに聞いてもらおうとお招きすることになりました。 結論：めっちゃ盛り上がりました 和田さんの講演会をアナウンスした時の盛り上がり 事前アナウンスでも盛り上がったのですが、当日はもっと盛り上がりました！ 和田さんのアドバイスを受けて、講演会専用のSlackチャンネルを作成したのですが、講演当日の投稿数は1,223！リアクション数は1,540でした！月に一度開催される全社レビュー会での投稿数が数百なので、桁違いの盛り上がりです。同時視聴数も200人を超え、エンジニアだけでなく、色んな職

はじめに こんにちは。heyで STORES 決済 の Androidアプリ開発をしている Yamaton です。普段は趣味のDIYと業務を掛け合わせて、 決済カードリーダーをワイヤレス充電する記事（★1）を書いたりしています。今日は、 STORES 決済 のエンジニアが日常どのようにVOC*1に対応しているかをお伝えします。 VOCのキャッチアップ heyは基本的にオープンコミュニケーションです。プライバシーに関わることや、個人情報などの秘匿すべき情報以外は、共有されます。コミュニケーションはSlackのパブリックチャンネルで、ドキュメンテーションはesaを利用しています。VOCに関しても、秘匿すべき情報を除外した内容が投稿される専用のチャンネルがあります。 VOCの一例 このチャンネルで共有されるVOCを日々ながめて「オーナーさんがよろこんでくれてる」や「利用者視点ではそこが使いにくか

hey でソフトウェアエンジニアをやっている @_morihirok です。 私たちが開発・運用しているネットショップ開設サービス STORES に、このたび新しい決済手段が追加されました。 www.hey.jp 規模と影響範囲が大きい開発でしたが、3人という少人数の開発チームでスケジュール通り無事故でリリースでき、すでに多くのユーザーさまに使っていただいている決済手段となっております。 私たちのチームがどのようなことを意識することでこれらの成果を上げることができたか、ご紹介させていただきます。 私たちのチームについて 私たちはネットショップ開設サービス STORES とオフライン店舗向けPOSレジアプリ STORES レジ の機能開発を行っているチームです。 昨年秋頃に「新たな決済手段を追加する」という意思決定が行われ、その開発を私たちのチームで行うことになりました。 規模が大きくリリー

みなさんこんにちは。モバイル本部のマネージャーをやっている @huin です。 去る 1月22日 (土) 〜 1月30日 (日) に技術書オンリーイベント 技術書典 12 が開催されました。 技術書典は、仕事や趣味で触っている技術はもちろん、とてもニッチ (褒め言葉) なトピックの本も販売されていて「さまざまな技術の知見」が集まるとてもユニークで面白いイベントです。正直「こんなことやってる人いるの？」と思いながら新刊を眺めているだけでも楽しめます。 僕自身は物理で参加したことはないのですが、何年か前から気になる本を購入しています。今回は下記の4冊を購入しました (かなり実益寄りのラインナップ)。 techbookfest.org techbookfest.org techbookfest.org techbookfest.org さて、この技術書典ですが、昨年の夏に続いて今回も ヘイ とし

データチームの@komi_edtr_1230です。 突然ですが、heyがメインで使ってるプログラミング言語は何か知っていますでしょうか？ heyはECと決済、予約など複数事業の事業を展開しているのですが、ECと予約はRuby (+ Rails)で決済はJavaを使っています。 また、アカウント共通基盤ではGoを使っています。 今回データチームでは事業成績を日次でSlackに通知してくれるアプリをRustで開発しました。 この記事ではどのようにして開発を進めたのか、ツラいポイントはなんだったか、何が良かったかなどについてまとめます。 何を作ったのか 今回作ったSlackアプリはどのような要件を抱えていたかというと、 様々な項目についてのデータを取得 Slackに投稿できるようJSONを整形 日次で稼働する(CRON Job) というような具合でした。 現在heyのSlackでは、以下のように

heyで採用広報を担当しているえんじぇるです。 7月13日（火）にCTOの藤村 @ffu_ とフロントエンドエンジニアの藤川@ushiro_noko がTwitter Spacesでフロントエンドについておしゃべりしたので、その様子を一部お届けします。 人生で一番弱気なバージョニングをした 藤村：heyでCTOやってる藤村と申します。フロントエンド老人会という名前で、友達と飲んで、ずっとExt JSとか、Backbone.jsより前のUIライブラリの話をして盛り上がったりする、React以降には何にも役に立たないフロントエンドエンジニアです。 藤川：（笑）そんなことないでしょう。 藤村：（笑）で、藤川さんはheyで働いてくれているフロントエンジニアで、最近週に1時間ぐらい時間をもらって、一緒にコードを書いてるんですけど、その話を最初してみようかな。 藤川：そうですね。 藤村：僕ら、今、ST

STORES 予約 でwebアプリケーションエンジニアをやっております。ykpythemindです。 Rails開発で、どのようなアプリケーションでも抑えておくとチーム開発が少し楽になるポイントがあります。今回はいくつか実例を載せながら紹介します。 アプリケーションの設計的な部分や実装には踏み込まず、すぐに導入できます。 あくまでRailsアプリケーションについての記事ですが、他言語やフレームワークを用いていても同様のことができます。 1. シードデータが壊れないようにCIで担保する 新しいメンバーが入って環境構築をしてもらう度にシードデータが壊れており、 db/seeds.rb *1 を直すという作業を何回か経験しています。db/seeds.rbで実行する内容をテスト中に実行しておくとメンテされるようになります。 # db/seeds.rb # 定数データが必要であればここで呼ぶ req

はじめに hey のECとかレジのバックエンドエンジニアをやっている @ucks です。 前回は、Mongoid の基本的な使い方と MongoDB を利用した開発のメリットを紹介しました。 今回はもう少し踏み込んで、STORES (以下、区別のため STORES EC と表記)、STORES レジで利用している仕組みを紹介します。 タイトルにもありますが、 STI をご存知でしょうか? Single Table Inheritance の略で、日本語にすると単一テーブル継承と言うらしいです。 筆者は、初めて聞いた時、青い車向けのピンクのパーツを開発している会社しか思い当たりませんでした。 簡単に説明すると1つのテーブルで複数のモデルを永続化する手法です。 STI には良い印象を持ってない人も多いかと思いますが、STORES EC とレジでは、Webアプリケーションフレームワークに Rub

はじめに hey でECのフロントエンドエンジニアを担当している @nkoba です。 STORES ECでは先日、アイテム機能のアップデートをリリースしました。そのアップデートのうちの一つが、アイテム画像件数上限アップです。 これは今までアイテムごとに画像を15枚までしか登録できなかった制限を拡大し、30枚まで登録できるようにしたアップデートです（スタンダードプランのみ）。 このアップデートのプロジェクトに担当の一人として開発に参画した中で、フロントエンドに求められる仕事について多くの気づきがあったので、この記事で紹介したいと思います。 アイテム画像件数上限アップとユーザー体験 プロジェクトの当初はフロントエンドとバックエンドの画像枚数のバリデーションを修正すれば作業は終わりという認識でした。 そのため、開発期間もかなり短く見積もって計画を立てていました。実際にバリデーション周りのコード

はじめに はじめまして、hey でECとかレジのバックエンドエンジニアをやっている @ucks です。 STORES (以下、区別のため STORES EC と表記) と STORES レジでは、Webアプリケーションフレームワークに Ruby on Rails 、 データベースに MongoDB 、 ODM (RDB でいう ORM) に Mongoid を利用しています。 普段 RDB で開発しているエンジニアからすると MongoDB ってどうなの? と思う方も少なくないと思います。 そこで、今回は Rails で一般的なORMである Active Record を殆ど使ったことがない筆者が、 MongoDB + Mongoid での開発の良いところを RDB + Active Record と比較して紹介します。 以前 STORESってMongoDBを使ってるらしいけど正直どうなの

テクノロジー部門、STORES ECでフロントエンドエンジニアをしている @daitasuです。 私たちのチームでは、会社全体での人事制度で設定する目標とは別に、チーム内で独自にクオーターごとの目標設定と振り返りをしています。 チーム内での目標設定と振り返りを1年ほど続けてきたので、なぜこの取組を始めたのか、実際やってみてどうだったかを書いていこうと思います。 チームの位置づけ UI改善チームとは hey内では、全プロダクト横断的なテクノロジー部門という棲み分けがあり、その中にSTORES ECの開発を進めるECの部隊があります。 私たちフロントエンドチームは、ECのエンジニアチームの中の1つとなっています。 hey社のEC本部では、フロントエンドチームはUI改善チームと呼ばれています。 フロントエンドチームの構成 フロントエンドチームは、大きくプロダクト開発のチームと基盤改善のチームに分

STORES でECの開発に携わっている @katsumata_ryo です。先日5月27日に「【生配信】"hey Talk" Engineers STORESのカジュアル面談全部お見せします！」というイベントを行いました。当初20名を定員とさせていただいておりましたが、即日定員に達したため50人まで増席しました。当初の予想以上にご期待いただいた中良いイベントになりましたのでその様子をご紹介できればと思います。 どんなイベント？ STORES というサービスのことを少しでも知って頂く機会になればという目的で、 前半コンテンツ：公開カジュアル面談 後半コンテンツ：パネルトーク を行いました。 「公開カジュアル面談」は純粋に STORES のことを知ってもらうという意図で企画をしました。私自身カジュアル面談の担当をさせていただくことが多く他社のカジュアル面談はどのように行われているかとても興味

STORES 予約 でwebアプリケーションエンジニアをやっております。ykpythemindです。 GitHub Actions、とても便利ですよね。STORES 予約チームでは徐々にCircleCI から GitHub Actionsへの移行を進めていますが、この度歴史あるRailsのリポジトリのCIを移行したので知見を公開します。 概要 RSpecを実行する CIの実行速度のチューニング（CircleCIと同等の速度にしたい） node_modulesなどのインストール結果をキャッシュする テストを並列実行する 大きな方針として、CircleCI等の他サービスからの乗り換えの場合、同等のCI速度/課金額でないと移行は現実的でないと思いますので、速度面のチューニングも意識しています。 ほぼそのままの設定を貼ります 一部プロジェクト固有のstep等があり注釈コメントをつけています。適宜調

業務委託で STORES の開発をしている @inouetakuya です。 先日 STORES のフロントエンドチーム内でクライアントサイドのバリデーションについて見直す機会があり、特にバリデーションエラーのデータ型をどうするかについての議論が興味深かったので、共有させていただきます。 背景 議論の背景について簡単に触れておくと、STORES のクライアントサイドでは、バリデーションのライブラリとしてこれまで joi-browser を使ってきました。 しかしながら、本家の Node.js 版の joi がブラウザ対応したことにより joi-browser が deprecated になったことを受けて、今後も joi を使い続けるかを検討したところ、 joi-browser と joi の最新バージョンとの間で API の差異がいくつかあり、joi-browser から joi への乗