ZOZOTOWNのWebホーム画面をNext.jsでリプレイスして得た知見 - ZOZO TECH BLOG
はじめに ZOZOTOWN開発本部の武井と申します。ZOZOTOWNのフロントエンドリプレイスプロジェクトを主に担当しております。ZOZO DEVELOPERS BLOG でも「ZOZOのリプレイスプロジェクトで得られる唯一無二の経験。大規模サービスを進化させるやりがいとは」というインタビュー記事を掲載しておりますので、もしよろしければこちらも併せてご覧ください。 さて、本題です。現在ZOZOTOWNではオンプレミスかつ、モノリスだった既存システムをマイクロサービスAPIに責務を分割したり、インフラをクラウドに移行したりしています。しかし、いわゆるWebのUIを構築するためのシステムは現在も既存システムに新機能開発や機能改修を行なっており、リプレイスに着手できていませんでした。 そこで、まずホーム画面から段階的にリプレイスすべく設計・開発を昨年から行ない、無事リリースできました。ZOZOT
「Reactに書き換えないとこのプロダクトチームは緩やかに死を迎えます」 こんにちは、ログラスのエンジニアの佐藤です。 昨年に入社して早2ヶ月経ちましたので、入社記事でも書いていきます。 「Reactに書き換えないとこのプロダクトチームは緩やかに死を迎えます」 と、CTOに言ったのは昨年末くらいでした。 入社してまだ1ヶ月経たないくらいです。 ログラスは創業当時からAngularを使って開発をしていました。 正社員のフロントエンドエンジニアは自分が入るまではいなくて、業務委託の方と協働しながら開発をしていました。 そのプロダクトをゼロからこの創業期のタイミングでReactでフロントエンドを作り直そうというお話です。 今回のお話はあくまでログラスのプロダクトチームの目指す理想像とAngularの相性が悪いだけで、AngularがReactより劣っているわけではありません。 Angularはフ
ジャムジャム！！Jamstack_2に登壇した際の発表資料です。 https://jamjamjamstack.connpass.com/event/226467/ ご質問あれば、Twitter: aiji42_dev までどうぞ。
まもなく17周年を迎えるpixivでは、長年にわたり作品などの全文検索基盤としてApache Solrを使用してきました。 しかし、サービスの規模が拡大する中で、従来の基盤に問題が生じていました。これを受けて、pixivでは全文検索基盤のリプレイスを実行しました。 今回のリプレイスにより、pixivでは検索結果の更新反映時間や検索APIのレイテンシが大幅に短縮されました。また、今後のスケールに対応可能になり、新機能開発においても全文検索が容易に利用できるようになりました。 本記事では、pixivの全文検索基盤の歴史や、今回オンプレミス環境でElasticsearchクラスタを構築し、リプレイスを完了するまでの取り組みについてご紹介します。 こんにちは。pixivのnamazuです。最近、私たちのチームで進めていたpixivの全文検索基盤のリプレイスが完了しました。この機会に、pixivの全
pixivではNext.jsを用いたフロントエンドのリプレイスプロジェクトを2022年3月末より行っており、現時点(2022年8月)でリクエスト機能をNext.jsにてリプレイスしました。 今回のpixiv insideではピクシブ株式会社で働くエンジニアの取り組みとして、pixivのフロントエンドをNext.jsでリプレイスする取り組みについて実際に取り組んだメンバーからご紹介します。 まずは皆さんの自己紹介をお願いします namazu: pixivのウェブ領域に関するテックリードを担当しているnamazuです。今回のNext.js化プロジェクトではPjMやNext.jsのホスティング回りの実装を担当しています。 shu: 2022年3月に入社したshuです。Next.js化ではフロントエンドの設計、実装を担当しています。 mog: エンジニアとしてアルバイトをしているmogです。Nex
フロントエンドを Vue.js から React にリプレイスしたお話 (前編) - NTT Communications Engineers' Blog
はじめての方、はじめまして。久しぶりの方、お久しぶりです。 イノベーションセンターの何縫ねの。(@nenoMake)です。 普段の業務ではソフトウェアエンジニアとして Node-AI という WEB アプリケーションの開発をしています。 パブリックな活動としては、好きな言語である C# 関係の OSS 開発や技術ブログの投稿、登壇などをしています。 ですが、今回は C# ではなくフロントエンドのお話をします...! この記事では今まで Vue.js 2.x で開発されていた Node-AI の WEB フロントを完全に捨て去り、React にリプレイスしたお話をつらつらとしていきます。 まずは前編ということで、リプレイスプロジェクト発足時の課題感からはじめ、プロジェクトの進め方や選定技術などについてお話しします。 後編には内部の設計などのより技術的なお話をしたいと思います。では前編スタート
【結論】 5ヶ月かけて無事完了しました。あー長かった。 新規の機能開発を止めないために一般的な開発チームでは今回のようなフロントエンドのフルリプレイスで一部新規の機能開発を止めながら開発を行うことがあると思います。 コードフリーズとなど呼ばれているものですね。 しかしログラスのようなスタートアップではプロダクトを絶えず進化させていくことがとても重要です。 機能開発を止めてしまえばたちまち大きな開発チームをもつ競合に追い抜かれて会社が負けてしまいます。 本記事ではフロントエンドフルリプレイスを新規機能開発を止めずに走らせる方法を解説していきます。 リプレイス概要本題に入る前に今回リプレイス対象となったLoglassについてとプロジェクトの概要について説明します。 【Loglassについて】 「プランニングクラウド Loglass」はBtoB SaaSのサービスの一つです。 基本はSSGやSS
はじめに こんにちは、株式会社マイベストでフロントエンドのテックリードをしているteppeitaです。 弊社が運営している mybest の技術スタックをVueからReactに移行したので、その時の話を共有したいと思います💪 mybestのフロントエンド紹介 まずはイメージしやすくするために、簡単にmybestのフロントエンドについてご紹介します。 フロントエンドの技術構成 - TypeScript - React - ApolloClient（APIがGraphQLです） - Storybook（VRTやinteraction testsを実行しています） - Jest - Cypress ↑少し前まで、ReactのところがVueでしたが、リプレイスしました。今回はその話です。 画面構成 mybestには、大きく分けて、フロント画面（一般ユーザーが見る画面）と管理画面が有ります。 その
はじめに こんにちは。雑食系エンジニアの勝又です。 今回は、私が2年ほど参画させていただいた大規模サービスのインフラやDevOps周りを全面的にリプレイスしたお話について簡単にご紹介させていただきます。(内容に関しては事前に参画先企業様に確認していただいております) サービス概要 詳細な内容は伏せますが、メインとなるテーブルのレコード数が数十億件、スパイク時には数万〜数十万のユーザーが一斉にアクセスする大規模サービスです。 技術的負債 長く運用されてきたサービスのあるあるですが、新機能の追加が最優先されてきたことにより、こちらのサービスにも下記のような技術的負債が大量に積み上がっていました。 RubyやRailsやMySQLのバージョンがかなり古い インフラの構成がコードではなくドキュメントで管理されている アプリケーションの構成管理がおこなわれていない CI/CDパイプラインが構築されて
『じゃらん』『ホットペッパーグルメ』はなぜリプレイスを選んだのか？ 大規模サービスが「新しい技術要素」を採用するまで - はてなニュース
運営を長年続けるうちに開発コードが膨大になり、身動きが取りづらくなる。大規模なサービスにはよくある課題です。しかし、根本的な解決に向けて大ナタを振るうには「痛み」も伴うため、なかなか踏み切れない、という企業も多いのではないでしょうか。 リクルートでは今回、『ホットペッパーグルメ』と『じゃらん』という大規模サービスのアプリのリプレイスを実施。リプレイスに際して、Flutter、Kotlin Multiplatform Mobile（以後、KMM）という新しい技術要素を導入しました。Flutterは今やクロスプラットフォーム開発に欠かせないフレームワークとして磐石の地位を固めつつあります。一方、後発のKMMも、クロスプラットフォーム開発とネイティブアプリ開発、双方の利点を兼ね備えたSDK（Software Development Kit）として今注目を集めています。 いずれも過去の導入事例が少
個人開発の動機はユーザーとの距離を縮めること そもそも、個人開発を始められたきっかけは何だったのでしょうか。 坂本氏：一番最初は、プログラミングスキルを高めるためだけにやっていました。個人開発とはいっても、プログラマーが作ってみましたという感じの、とてもシンプルなQiitaのリーダーアプリです。 ファミリーTODOでは、ちゃんとマネタイズまで考えています。 ファミリーTODO：iOS版 / Android版 なるほど。副業として企業でのアプリ開発もされていたと思いますが、こういった副業は、あまりはまらなかったのでしょうか？ 坂本氏：そうですね。労働時間の対価にお金をもらう形が、本業と変わらないなと思っていました。当時、お金を稼ぐ優先度は低かったので、もっと別のことに時間を使いたいと思ったんです。 それで、やりたいことについて考えた時に、自分のサービスでお金を生み出すチャレンジをしたいと思
ZOZOにおけるID基盤のk8sへのリプレイスとセキュリティの取り組み / Authentication service replacement and security efforts of zozotown(CNDT2020)
ZOZOにおけるID基盤のk8sへのリプレイスとセキュリティの取り組み / Authentication service replacement and security efforts of zozotown(CNDT2020)
はじめに 弊社にはGoで作ったシステムが存在しますが、作られてから数年が経過して、メンテナンスも十分にできていない状況でした。 そこで、このシステムをリファクタリングして生産性を上げようという結論になりました。 リファクタリングにあたり、Goのままで行くのか、弊社でよく使われているRubyで行くのかを検討してみましたので、その過程を紹介したいと思います。 Rubyでリプレイスしようと思った理由 Goで動いてて言語やライブラリのバージョンアップなどメンテナンスがされてない部分はありますが、 そこを解消すればGoのままで行った方が良いのでは？と思うかもしれません。 しかし、あえてRubyでリプレイスしようと思うに至ったのは以下の点があります。 Rubyの方が開発速度があがりそう Goのリファクタリングをするのに時間がかかりそう Goのリファクタリングと機能追加でコード修正箇所が被るとスケジュー
大規模システムのリプレイスを2度経験したPMが語るシステム移行プロジェクトで重要なこと - JMDC TECH BLOG
JMDCの開発本部データ基盤開発部の新倉です。JMDCには大型案件に自由度高く取り組める環境があります。今回は私が実際に経験したDWHシステムの2度のリプレイスの事例をお伝えします。1度目はPL（プロジェクトリーダー）、2度目はPM（プロジェクトマネージャー）としてプロジェクトに参画。その経験からシステム移行プロジェクトを成功に導くポイントを解説します。 ＜プロフィール＞※執筆当時 新倉 裕一郎（にいくら ゆういちろう）データウェアハウス開発部 データレイクグループ グループリーダー 新卒でソフトウェア会社に入社。大手ベンダー企業の介護パッケージソフト製造などの開発業務に従事。その後、SaaS型CRMサービスを展開するベンチャー企業に転職し、2015年5月に日本医療データセンター（現JMDC）入社。レセプトDWHシステムを担当し、2度のリプレイスを経験。現在はレセプトDWHシステムの保守開
BacklogのSREを担当しているmuziです。 今回の記事では、ヌーラボにおけるSREの活動事例として、Backlogの課題検索機能のリプレイスプロジェクトについてご紹介します。 このプロジェクトでは、SREと開発者がチームを組んで、要件定義からリリースまで行いました。その結果、Backlogを構成するサーバ同士が疎結合になり、将来的なマイクロサービス化に向けた足がかりを作ることができました。 歴史の長いプロダクトにありがちな技術的負債への取り組みの一例として、みなさんの参考になれば幸いです。 リプレイスプロジェクトの背景 Backlogの課題検索機能 最初に、このリプレイスプロジェクトの背景として、Backlogの課題検索機能についてご紹介します。 課題検索機能とは、Backlogの「課題」ページで利用できる検索機能のことです。件名や詳細に対するキーワード検索に加えて、プレミアムプラ
AWS については利用していないのでよくわからない。あくまで Erlang/OTP で書かれたミドルウェアのリプレイス事例として感想を雑に書く。ちなみに、現地で発表を聞いている。 一般的な感想 自分のような AWS 素人が見てもわかりやすいシンプルなシステムになっていた HTTP/2 を利用した独自プロトコルでの双方向通信が気になる TCP/IP を利用した大量の常時接続は本当に大変だとおもう カーネルパラメーターチューニング！ 少ないリソースで、たくさんの接続を担う ゴールが素晴らしい デプロイの自動化を GitHub Actions でやってるのやっぱりいい 負荷試験にて1億台の接続を維持した状態で挙動が問題ないことを確認 最高 Graviton ベースの Fargate の活用 Go であれば arm64 向けバイナリがサクッと生成されるのは良い Erlang/OTP から Go へ
ゲーム攻略メディア「神ゲー攻略」の記事配信システムを、五年の歴史がある SSG から二年の歴史がある lit-html による SSR にリプレイスした話 - CARTA TECH BLOG
VOYAGE Lighthouse Studio の海老原 (@co3k) です。 ゲーム攻略メディア「神ゲー攻略」の記事は、これまで SSG (Static Site Generator; 静的サイトジェネレータ) を用いて構築、配信されていました。 このたび、従来の SSG を活用した記事配信の仕組みから、 SSR (Server Side Rendering) による仕組みにリプレイスしていくことにしました。 本記事では、そうした新しい記事配信システムの詳細と、移行にまつわる工夫や苦労話などについてご紹介します。 [PR] 本エントリをお読みいただく前に そもそもリプレイス前の構成ってどんな感じだったの？ というか「神ゲー攻略」って何？ みたいなのが気になって記事が読み進められないかも〜とご心配の方に耳寄りな情報です。 実は「神ゲー攻略」の事業やシステム構成については『Enginee
Rails の非同期処理を Sidekiq から Cloud Tasks にリプレイスして Cloud Run のコストが6分の1になった話
成果 最終的に、Cloud Run のコストが$6/day前後から$1/day前後に！ ちなみに、Cloud Tasks は1ヶ月あたり最初の100万回のオペレーションまで無料なので余裕で収まっています。 モチベーション 今回リプレイスを検討したシステムは軽量な非同期処理が大半で、もともと絶対に Sidekiq でないと困るということが少なかった Sidekiq は Redis をポーリングしてジョブを取得する方式なので、Cloud Run で実行するには min-instances を1以上にしなければいけない 何もジョブがない状態が続いてインスタンスが0になると起こしてくれる人がいないので... 絶対に Sidekiq でないと困らないなら Cloud Tasksにして、非同期処理がない時は寝ていても良いようにしたい => コストダウン！ Pub/Sub との比較検討もしましたが今回は
はじめに 2023年にZennチームにJoinしたdyoshikawaです。 このたびZennのE2Eテスト基盤をリプレイスしました。このような下回りの改善はユーザへの価値提供との距離が近い機能開発と比べてどうしても後回しになりがちな中、Publication Proという大きなリリースを迎えて少し開発が落ち着いたタイミングであり、E2Eテストを拡充できる土台を整えることで今後より安心して機能を追加していけるようにするために必要だということで実施しました。 各テストを独立実行可能にすることによる開発体験向上、CI（GitHub Actions）の実行時間短縮、そして将来を見据えてのCypressからPlaywrightへの移行を行いました。 本記事ではリプレイス前に抱えていた課題、それに対して打ち出した解決方針、そして具体的にどんなことをやったのかを紹介します。 抱えていた課題 前提として
Software Design 2024年8月号 連載「レガシーシステム攻略のプロセス」第4回 ZOZOTOWNリプレイスにおけるマスタDBの移行 - ZOZO TECH BLOG
はじめに 技術評論社様より発刊されているSoftware Designの2024年5月号より「レガシーシステム攻略のプロセス」と題した全8回の連載が始まりました。 ZOZOTOWNリプレイスプロジェクトで採用したマイクロサービス化のアプローチでは、安全かつ整合性のとれたデータ移行が必須となりました。第4回では、このマスタDBの移行について紹介します。 目次 はじめに 目次 はじめに マスタDB移行 マスタDB移行について 要件と課題 テーブル構成を再設計したうえでデータ移行を実施する ダウンタイムなしでデータ移行を実施する 方針 異なるDBおよびデータスキーマ間で移行を実施するためEmbulkを使用する ダブルライトをリリースし、データ移行中に発生するDBへの書き込みを両DBにアトミックに実施する データを一時DBに格納し、一時DBから移行先DBにデータを移行する BulkloadとBac
「Developers Meetup 急成長ベンチャーが向き合う『開発生産性』」は、開発組織や事業フェーズの異なる株式会社Another works・株式会社SmartHR・株式会社スタメンの3社が、開発生産性について語り尽くすイベントです。ここで株式会社スタメンのかみお氏が登壇。フロントエンドのリプレイス前にあった課題と、「生産性が向上した」と感じさせてくれた5つのことについて紹介します。 かみお氏の自己紹介 かみお氏：「レガシーフロントエンドをリプレイスしたら開発生産性が向上しました」というタイトルでお話をします。よろしくお願いします。 まず自己紹介を簡単にさせてください。2021年1月にスタメンに入社して、主にフロントエンドを担当している「かみお」です。現在は、今回お話しするNext.jsへのリプレイスのプロジェクトに参加中です。今回初登壇なのでお手柔らかにお願いします。 今日は、リ
はじめに こんにちは、レストランボード（以下、RB）のフロントエンドチームの石亀です。担当していた規模の大きめなプロジェクトでVueを結構触っていまして、設計含め困難と向き合いながら色々取り組ませてもらったのでそれをナレッジとして残そうと思い記事を書くことになりました。エモいですね。 RBは現在自社のフレームワークで構築されていて、徐々にVueでリプレイスをかけています。 今回、大規模なプロジェクトにてVueでさらなるリプレイスを実行しましたが、プロダクト自体がとても大きく且つ限られたリソースの中でいかに負債化させずにできるだけ安全に移行させるかを検討しました。 そこで実際に実施した施策や検討内容などを紹介します。 おそらく、多くのサービスやプロダクトで既存のコードを新しいライブラリ・フレームワークで書き換えているかと思います。 背景だったり関わる規模・コンテキストが異なるとは思いますが、
DMM GAMESのプラットフォームリプレイスを支えるBackends For Frontends (BFF) の裏側 - DMM inside
Single NodeのDocker Swarmを利用してオンプレミスにデプロイされるGraphQLサーバを安全にローリングアップデートさせている話
受発注・サプライチェーン管理システムとサプライパートナー向けシステムに関する現状や課題などについて、開発を担当しているエンジニアが話す「Rustで負債を解消するために大幅刷新する複雑な業務Webアプリ」。ここでバックエンドエンジニアのKaribe氏が登壇。Kotlin製の業務WebアプリケーションをRustでリプレイスした経験について話します。 自己紹介 Takumi Karibe氏：「Kotlin製の業務WebアプリケーションをRustでリプレイス」というテーマで発表します。先ほど「Rust製の業務WebアプリケーションをRustでリプレイス」という話と、そのどさくさに紛れて「フロントエンドをリプレイス」という話もありましたが、今回もどさくさに紛れてKotlin製のWebアプリケーションをRustでリプレイスした話をします。 自己紹介です。Karibeと申します。2021年の9月に入社し
こんにちは、WEARバックエンドブロックの天春です。バックエンドの運用・開発に携わっています。本記事では、以前公開したWEARにおけるプッシュ通知システムのリプレイス のフェーズ2を終え、旧環境のプッシュ通知システムのリプレイスを完了したのでシステム構成や移行手順をご紹介します。 目次 目次 1:Nのプッシュ通知システム リプレイス前の1:Nのプッシュ通知システム リプレイス前のシステム構成 問題点 リプレイス後の1:Nのプッシュ通知システム リプレイス後のシステム構成 1:Nキュー（Sidekiqダッシュボード） 負荷テスト 目標 対象 事前準備 負荷テスト実施 負荷テスト結果 負荷テスト実施後の改善内容 大量の通知の遅延を減らす 同時実行数の調整 500件単位でFCM通知配信 1:N通知配信の親ジョブ 500件単位でFCM配信を行う1:N通知配信の子ジョブ 500件単位でDynamoD
田中邦裕氏の自己紹介 司会者：みなさま、お待たせしました。これより再び特別企画をお送りします。2つ目の特別企画は、「生成AI／LLM未踏的ビジネス活用最前線」と題してお届けします。なお、本セッションでは視聴者からの質問を受けます。質問は「Slido」というコミュニケーションツールを使用します。 それでは、登壇者のみなさま、ステージへお願いします。みなさま、拍手でお迎えください。 （会場拍手） ここからの進行は未踏IT人材発掘・育成事業プロジェクトマネージャーの田中さんにお願いします。よろしくお願いします。 田中邦裕氏（以下、田中）：はい、みなさま、セッションにお越しいただきありがとうございます。タイトルが「生成AI／LLM未踏的ビジネス活用最前線」ということで、お届けしたいと思います。では、さっそくですが、パネラーの方の紹介をしたいと思います。 まず中山さんから……。あっ、自己紹介か。忘れ
WEARにおける画像配信のリプレイス戦略とAkamai Image & Video Managerの導入 - ZOZO TECH BLOG
こんにちは、WEAR部の繁谷です。SREとしてWEARの運用・保守・開発をしています。 WEARでは、以前の記事で説明した通り、画像配信のリプレイスを行ってきました。本記事ではSRE観点で画像配信のリプレイスやAkamai Image & Video Manager（以下、Image Manager）を利用した画像リサイズの導入の事例を説明します。 techblog.zozo.com WEARにおける画像配信の課題 前述の記事でも紹介している通り、リプレイス前のWEARの画像配信は下図の構成でした。コーディネート投稿時などのタイミングでIISのAPIを叩き、オリジナル画像をS3に保存します。その書き込みをフックとし、オリジナル画像をリサイズするAWS Lambdaが実行され、派生画像を作成します。そして、作成された派生画像をCDNで配信します。 図1 : リプレイス前の構成図 しかし、この
FAANSにおけるCloud RunからGKE Autopilotへのリプレイス事例 - ZOZO TECH BLOG
はじめに こんにちは。ブランドソリューション開発本部 WEAR部 SREの笹沢（@sasamuku）です。 FAANSはショップスタッフの効率的な販売をサポートするスタッフ専用ツールです。FAANSの一部機能は既にリリースされており全国の店舗で利用いただいております。正式リリースに向け、WEARと連携したコーディネート投稿機能やその成果をチェックできる機能などを開発中です。 FAANSのコンテナ基盤にはCloud Runを採用しており、昨年にSREとしての取り組みをテックブログでご紹介しました。しかし、運用していく中で機能需要や技術戦略の変遷があり、Cloud RunからGKE Autopilotへリプレイスすることを決めました。本記事ではリプレイスの背景と、複数サービスが稼働している状況下でのリプレイス方法についてご紹介します。 目次 はじめに 目次 リプレイスの背景 なぜCloud R
ZOZOTOWN カート決済機能リプレイス Phase1 〜 キャパシティコントロールの実現 - ZOZO TECH BLOG
こんにちは。ECプラットフォーム部 カート決済ブロックの高橋です。 ZOZOTOWNでは、数年前よりClassic ASPからJavaへのリプレイスが実施されています。そのリプレイスの一環として、2021年4月からカート決済機能のマイクロサービス化を開始しました。 ZOZOTOWNの中長期目標である「商品取扱高5000億円」を達成するために、リプレイス後は以下の要件をシステムが満たしている必要があります。 セールなどの高負荷イベント時にスケール可能であること キャパシティコントロールが可能であること Datadog、SentryなどのSaaSを利用した運用監視の効率化できること CI/CDなどを取り入れ、開発生産性を向上できること レガシー技術をモダン化できること そして、カート決済機能はZOZOTOWNの中でも最も大きな機能であり、最も重要な機能です。そのため、リプレイスは慎重に進めなけ
はじめに こんにちは。基幹システム本部・物流開発部の上原です。昨年度に中途入社しまして、現在はZOZO基幹システムのリプレイスを担当しています。前職では、SESエンジニアとしてリプレイスプロジェクトに上流工程から参画し、大規模なシステムの言語リプレイスを経験してきました。さて私の紹介はこの辺りにして本題に入ります。 基幹システムリプレイスは既に進行しており、本年度には発送領域の機能を発送マイクロサービスとして切り出してリリースしました。それに続いて、入荷領域の機能をマイクロサービス化ではなくモジュラーモノリスに移行するリプレイスも進んでおり、こちらは細かく区切った単位でリリースをしています。 本記事では、自動テストによる「等価比較」を本番環境で実施しながら言語リプレイスを進めた事例を紹介します。この事例では、「言語間での処理の等価性を保証し、安心・安全にリプレイスをする」ということを目的と
はじめに こんにちは。検索基盤部 検索技術ブロックの今井です。 検索基盤部では検索機能や検索精度を改善する中で検索クエリの意図解釈にも取り組んでいます。ZOZOTOWNで検索窓にクエリを入力して検索ボタンを押すと、クエリに応じて検索の絞り込み条件に変換するクエリ解釈機能の処理が動作します。 例えば、「ワンピース 白色」と検索した時、「ワンピース」を洋服のカテゴリー、「白色」を色のカテゴリーと解釈し、「白色のワンピース」を検索する絞り込み条件に変換します。 2024年5月現在ではスマートフォン向けWebサイト（https://zozo.jp/sp/xxx）とアプリのみ、クエリ解釈機能の処理が適用されています。クエリ解釈機能では意図解釈や検索の絞り込み条件に変換しています。 現在はシンプルな辞書ベースの手法を用いていますが、カバーしきれない課題も出てきており、改善のモチベーションが少しずつ上が
PR TIMESのトップページをNext.jsにリプレイスしました | PR TIMES 開発者ブログ
こんにちは、フロントエンドエンジニアのやなぎ（ @apple_yagi ）です。 プレスリリース掲載ページ、キーワード検索ページに続き、PR TIMESのトップページを PHP + Smarty + jQuery から Next.js（Pages Router）にリプレイスしました。
ZOZOTOWNアプリのレガシーAPIリプレイスの道のり 〜チームでの挑戦〜 - ZOZO TECH BLOG
はじめに こんにちは、ZOZOTOWN開発本部アプリバックエンドブロックの髙井です。 私達のチームでは、レガシーとなっているZOZOTOWNアプリ用API（以下、レガシーAPIと呼ぶ）のリプレイスに2023年から着手しています。リプレイス対象となるレガシーAPIは規模が大きいので、フェーズで区切り、段階的にリプレイスを進めています。区切られた各フェーズは、フェーズ1、フェーズ2といった形で呼び分けており、フェーズごとにリプレイス対象とするエンドポイントを設定しています。一方で、事業案件や他マイクロサービスのリプレイスが並行して行われるため、フェーズごとにリプレイス計画を柔軟に調整してきました。 本記事ではレガシーAPIのリプレイスについて、フェーズ3までを担当者が背景と課題を踏まえつつ紹介していきます。 目次 はじめに 目次 背景 フェーズ1 課題 1. リプレイス先APIの開発が初めて
WEARをリノベ！Objective-CからSwiftへのリプレイス戦略でも使えるスナップショットテスト - ZOZO TECH BLOG
目次 目次 はじめに マイページ画面リプレイスに伴う課題 使用したライブラリ Objective-Cでリファレンス、Swiftでテスト リファレンス画像のファイルサイズを小さく デバイスも言語も一気にテスト 複数言語のテスト自動化 複数デバイスを一気にテストする方法 いにしえVCのためのスタブデータの用意 おわりに はじめに みなさん、こんにちは！ 松井です。普段はWEAR iOSアプリ開発で、コードを書く筋肉をパンパンに鍛えています。WEARアプリは、長い歴史を持っており、まだまだObjective-Cで書かれたレガシーなコードも居座っているんです。そんな中、私たちは地道にリファクタリングを進めています。そうしたObjective-CからSwiftへのリプレイス戦略において、スナップショットテストを活用したお話をしたいと思います。 スナップショットテストと聞くと、一般的にはコードの修正前
WEARのAndroidアプリをBottomNavigationにリプレイスした際の状態保存について - ZOZO TECH BLOG
はじめに こんにちは。WEAR部の鈴木（@zukkey59）です。 普段は、「ファッションコーディネートアプリ WEAR」のAndroidアプリを担当しています。 実は最近、コツコツとやっていたリプレイスがおわり、AndroidアプリのBottomNavigation化がリリースされました！ 今回は、ドロワーメニューからBottomNavigationへリプレイスした際に悩んだFragmentの状態保存について、紹介します。 背景 今までのWEARのAndroidアプリは、iOSアプリと異なりドロワーメニューという古いUIのままだったため、BottomNavigationでの実装を行うことにしました。 実装を進めていると、BottomNavigationの項目の切り替えを行うことでリストのデータやスクロールの位置が保存されない現象に遭遇しました。 BottomNavigationの項目切り
こんにちは。WEARバックエンドエンジニアのid:takanamitoです。先日リリースしたWEARの新プッシュ通知基盤の紹介をしようと思います。 新プッシュ通知基盤開発の背景と目的 WEARでは既にiOS/Androidアプリに向けたプッシュ通知配信基盤が存在していました。 しかし、かなり昔につくられた基盤ということで運用にコストがかかったり、必要な機能が足りていなかったりします。 例えば、ユーザー全体にプッシュ通知を送りたい場合に以下のような問題が存在しました。 ログイン済みユーザーにしかプッシュ通知を送信できない プッシュ通知の送信開始から完了までに半日以上かかる 配信サーバーのスケールに手作業が発生する 1.についてはWEAR開発当初、はじめてプッシュ通知を導入するきっかけとなったキャンペーンが存在したものの、そのキャンペーンの対象がWEARアカウントを持っている人だったために、こ
WEARの画像アップロード機能リプレイスによるパフォーマンスと運用保守の効率化 - ZOZO TECH BLOG
こんにちは、WEAR部 運用改善チームの三浦です。普段は WEAR の運用改善を行っていますが、最近は新規プロジェクトの開発にも携わっています。 本記事では、WEARのS3への画像アップロード機能をインフラ・バックエンド両面からリプレイスを行い、パフォーマンスの向上と安全かつ効率的に運用保守を行えるよう改善をした事例を紹介します。 背景 現在取り組んでいる新規プロジェクトで、WEARの外部連携用APIを通してWEARへコーデ投稿をできる機能を作ることになりました。WEARのコーデ画像はAmazon S3で管理しており、今回作成するコーデ投稿機能でもWEARのバケットに対して画像をアップロードする必要があります。しかし、現状の画像アップロードの仕組みには様々な課題がありました。 その仕組みと課題の概要を説明します。 現状の画像アップロード機能の仕組み WEARの現状の画像アップロードの仕組み
AWSを活用するAutify、ZOZO、dipが、AWSコスト削減についての事例を発表するオンラインイベント「AWSコスト削減事例祭り」。3社それぞれが事例を発表しました。株式会社ZOZOからは、小林未来氏が登壇。約10倍になってしまったEKSコストに対する取り組みについて発表しました。全2回。前半は、コストが上がってしまった原因について。 ゆるふわ系SRE・小林未来氏 小林未来氏：それでは続いて、株式会社ZOZOから私、小林が「WEARのEKSコストを救いたい」という内容で発表いたします。よろしくお願いします。 まず私が誰なのかをお話しします。私は株式会社ZOZOから参りました、ブランドソリューション開発本部 バックエンド部 SREブロックの小林未来と申します。「ゆるふわ系SRE」と勝手に名乗っていて、Twitterも「@mirai_kobaaaaaa」という名前でやっているので、ぜひフ
コミューンのモバイルアプリを Flutter でリプレイスしている話 - Commune Engineer Blog
はじめに こんにちは、コミューン株式会社でソフトウェアエンジニアをしている牛嶋です。 2022 年 4 月にコミューンに入社してから、モバイルアプリチームに所属しており、Flutter を用いてコミューンのモバイルアプリ開発に従事しております。 元々コミューンのモバイルアプリは React Native で開発されていましたが、2022 年の 4 月から Flutter を利用したクロスプラットフォーム開発に取り組んでいます。 具体的には、WebView を利用してコンテンツを表示していた部分を Flutter 側で実装し直すことに取り組んでおり、その結果として、ユーザー体験の向上させることを目的としています。 この記事では、Flutter を利用したリプレイスプロジェクトの概要について書いていきたいと思います。 はじめに リプレイス PJ の背景 段階的リプレイス計画 第一弾リプレイス
こんにちは、WEARバックエンドブロックの天春（@AmagA001）です。バックエンドの運用・開発に携わっています。WEARはサービス開始から10年ほどの古いVBScriptを使った環境からRuby on Rails環境にシステムリプレイスを行なっています。本記事では、リプレイスの中でも既存環境が複雑で問題や課題が多くあったPUSH通知システムのリプレイスについてご紹介します。 目次 目次 PUSH通知システムとは リプレイス前のPUSH通知システム リプレイス前のPUSH通知システムの問題点 通知送信バッチのスケールアウトが出来ない 障害対応・運用が難しい状況 複数の開発言語による運用・改修コストが高い ステージング環境で通知確認ができない リプレイスの背景 リプレイス後のPUSH通知システム 非同期システム・EKS導入 既存システムの問題解決 バッチのスケールアウトが出来ない 障害対応
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
愛すべきAngularとのお別れ。2,3年後を見据えReactにリプレイスする話｜Yuito Sato
70万通りのURLを持つWebサービスを Next.jsにリプレイスして高速化した話
pixivの全文検索基盤とElasticsearchによるリプレイス - pixiv inside
pixivをNext.jsでリプレイスする取り組みをご紹介します。 - pixiv inside
5ヶ月で完走！新規開発を止めないAngular→Reactリプレイスの進め方まとめ｜Yuito Sato
VueをReactにリプレイスしてEasyからSimpleにした話
大規模サービスのインフラを全面的にリプレイスした話 - Qiita
個人開発の副業にはFlutterが一番。リプレイスのポイントとアプリのグロースの考え方 | Offers Magazine
Goで作ったシステムをRubyでリプレイスすることを検討してみた
SREの活動事例紹介 〜 Backlogのマイクロサービス化に向けた課題検索機能のリプレイス
"Nintendo Switch™ 向けプッシュ通知システムのリプレイス事例" の感想
ZennのE2Eテスト基盤をリプレイスしました（開発体験向上、CI時間の短縮、Playwright移行）
レガシーフロントエンドをNext.jsにリプレイス 「開発生産性の向上」を感じさせてくれた5つのこと
「レストランボード」における大規模フロントエンドの漸進的なVueリプレイスの取り組み
機能開発・運用効率向上のためにKotlinからRustへ Webアプリケーションのリプレイスにおける設計・開発の考慮
WEARにおけるプッシュ通知システムのリプレイスを全て完了した話 - ZOZO TECH BLOG
「ホワイトカラーの領域が急速にリプレイスされている」 中山心太氏が考える、生成AIとLLMで起きている革命
本番環境における等価比較を活用した言語リプレイス - ZOZO TECH BLOG
ZOZOTOWNのクエリ解釈機能の改善に向けたAPIリプレイスの取り組み - ZOZO TECH BLOG
FCMを使ったWEARプッシュ通知基盤リプレイス - ZOZO TECH BLOG
ECSからのリプレイスで“約10倍”になってしまったEKSコスト 異常値を調査してわかった、コスト急増の原因
WEARにおけるPUSH通知システムのリプレイス - ZOZO TECH BLOG