タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
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 までどうぞ。
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パイプラインが構築されて
こんにちは、sue445です。 先日社内で使ってるGitLabのリプレイスをしたのでその辺の話をしたいと思います。 リプレイスの内容 今回のGitLabリプレイスでは主に下記を行いました。 サーバ移設に伴いURL以外全部変えた レガシーな環境で運用されていたGitLabを全てDockerコンテナに載せた MySQLからPostgreSQLに移行 以上を1時間弱のメンテでやりきった 構成 ざっくり書くと、SSL終端のフロントサーバのみ同じで、それ以外のバックエンドを全部変えました。 旧 APサーバ Debian Wheezy CPU: Intel Xeon E5-2640v2 * 2 Memory: 40GB Disk: 64G + 512G MySQL兼Redisサーバ Debian Wheezy CPU: Intel Xeon X3430 Memory: 8GB Disk: 256G M
開発チームが大規模リプレイスを成功させるために取り組んだ "7つの取り組みと反省"【Backlog Play 化プロジェクト】 | Backlogブログ
ヌーラボの松本です。「Backlog Playプロジェクト」に2017年2月から途中参加し、プロジェクト解散の2019年7月までメンバーの一員として動いていました（プロジェクトの概要は 時系列でみる！4年の歳月をかけてPlay Frameworkで「大規模リプレイス」した話をご覧ください）。 このBacklog Playプロジェクト(以下、Play化プロジェクト)では、期間によって私の役割は変わりました。 参加した当初は開発メンバーとしてコードを書いていましたが、2018年4月からプロジェクト終了の2019年7月までは、開発をしながらプロジェクトの取りまとめをしていました。 マネジメントのような役割ははじめてだったので、いろいろ未熟な点もありましたが、プロジェクトの機能リリースを早めるために、不具合対策や手戻り削減といった問題と向き合いました。 本記事では、私のPlay化プロジェクトでの役
『じゃらん』『ホットペッパーグルメ』はなぜリプレイスを選んだのか？ 大規模サービスが「新しい技術要素」を採用するまで - はてなニュース
運営を長年続けるうちに開発コードが膨大になり、身動きが取りづらくなる。大規模なサービスにはよくある課題です。しかし、根本的な解決に向けて大ナタを振るうには「痛み」も伴うため、なかなか踏み切れない、という企業も多いのではないでしょうか。 リクルートでは今回、『ホットペッパーグルメ』と『じゃらん』という大規模サービスのアプリのリプレイスを実施。リプレイスに際して、Flutter、Kotlin Multiplatform Mobile（以後、KMM）という新しい技術要素を導入しました。Flutterは今やクロスプラットフォーム開発に欠かせないフレームワークとして磐石の地位を固めつつあります。一方、後発のKMMも、クロスプラットフォーム開発とネイティブアプリ開発、双方の利点を兼ね備えたSDK（Software Development Kit）として今注目を集めています。 いずれも過去の導入事例が少
時系列でみる！4年の歳月をかけてPlay Frameworkで「大規模リプレイス」した話【Backlog Play 化プロジェクト】
ヌーラボの松浦です。私がSREのエンジニアリングマネージャーとしてプロジェクトのサポートに携わっているプロジェクト管理ツールのBacklogは、2019年7月にJavaからScala / Play Frameworkに完全移行をしました。 このPlay化プロジェクトは、10年がかりで改良され仕様が明文化されていなかったBacklogを、JavaからScala / Play Frameworkに移行するという壮大なプロジェクトでした。 約4年にわたる「Backlog Playプロジェクト」(以下、Play化プロジェクト) で体験した“紆余曲折”を記録に残し、後のプロジェクトにつなげるために、今回から7回に渡って、技術的な挑戦やプロジェクト管理の視点など、当時のチームメンバーが独自の目線でPlay化プロジェクトを振り返った記事を連載します。 連載第1回目の本記事では、序章としてPlay化プロジ
タイトルにあるように、弊社ハウスマートが提供する売買マンション提案アプリ "カウル" がiOS/Android共にFlutterでフルリプレイスしました！ 下記サイトよりダウンロードしてみてください。 本記事では、Flutterを採用したカウルの技術的背景の話を紹介していきます。Flutterに少しでも興味がある方、もしくは将来的にFlutterの採用を検討している方の参考になれれば嬉しいです。 技術周辺の話が中心になりますが、コーディングのtipsなどはなく、振り返りの開発後記の様な内容なので、1つの読み物として読んでみてください。 目次 ・はじめに ・技術的な意思決定とFlutter ・スタートアップ特有の技術負債 ・生産性の向上という狙い ・投資に見合ったリターンとリスク ・検証とキャッチアップ、9週でのリリース ・技術検証 ・1週のキャッチアップ ・9週の開発 ・Flutterの技
個人開発の動機はユーザーとの距離を縮めること そもそも、個人開発を始められたきっかけは何だったのでしょうか。 坂本氏：一番最初は、プログラミングスキルを高めるためだけにやっていました。個人開発とはいっても、プログラマーが作ってみましたという感じの、とてもシンプルな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の「課題」ページで利用できる検索機能のことです。件名や詳細に対するキーワード検索に加えて、プレミアムプラ
ゲーム攻略メディア「神ゲー攻略」の記事配信システムを、五年の歴史がある SSG から二年の歴史がある lit-html による SSR にリプレイスした話 - CARTA TECH BLOG
VOYAGE Lighthouse Studio の海老原 (@co3k) です。 ゲーム攻略メディア「神ゲー攻略」の記事は、これまで SSG (Static Site Generator; 静的サイトジェネレータ) を用いて構築、配信されていました。 このたび、従来の SSG を活用した記事配信の仕組みから、 SSR (Server Side Rendering) による仕組みにリプレイスしていくことにしました。 本記事では、そうした新しい記事配信システムの詳細と、移行にまつわる工夫や苦労話などについてご紹介します。 [PR] 本エントリをお読みいただく前に そもそもリプレイス前の構成ってどんな感じだったの？ というか「神ゲー攻略」って何？ みたいなのが気になって記事が読み進められないかも〜とご心配の方に耳寄りな情報です。 実は「神ゲー攻略」の事業やシステム構成については『Enginee
2019年7月6日、株式会社サイバーエージェントが主催するイベント「Battle Conference U30」が開催されました。30歳以下のエンジニアによる30歳以下のエンジニアのための技術カンファレンスである本イベントには、さまざまな領域で活躍する若手が登壇。企業の枠を超えて、自身の技術・事業・キャリアに関する知見を発表しました。「システムリプレイスで事業を変える開発戦略」に登壇したのは、株式会社エイチームライフスタイル・鈴木就斗氏。 社内共通システムをリプレイス 鈴木就斗 氏：それでは「システムリプレイスで事業を変える開発戦略」ということでお話させていただきます。エイチームのグループ会社である株式会社エイチームフィナジーの鈴木就斗です。ちなみにみなさん、エイチームという会社を知っていますか？ 聞いたことある方は手を挙げてほしいんですけど……。 （会場挙手） ありがとうございます。パラ
はじめに 2023年にZennチームにJoinしたdyoshikawaです。 このたびZennのE2Eテスト基盤をリプレイスしました。このような下回りの改善はユーザへの価値提供との距離が近い機能開発と比べてどうしても後回しになりがちな中、Publication Proという大きなリリースを迎えて少し開発が落ち着いたタイミングであり、E2Eテストを拡充できる土台を整えることで今後より安心して機能を追加していけるようにするために必要だということで実施しました。 各テストを独立実行可能にすることによる開発体験向上、CI（GitHub Actions）の実行時間短縮、そして将来を見据えてのCypressからPlaywrightへの移行を行いました。 本記事ではリプレイス前に抱えていた課題、それに対して打ち出した解決方針、そして具体的にどんなことをやったのかを紹介します。 抱えていた課題 前提として
「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における画像配信のリプレイス戦略と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 : リプレイス前の構成図 しかし、この
こんにちは、WEARバックエンドブロックの天春です。バックエンドの運用・開発に携わっています。本記事では、以前公開したWEARにおけるプッシュ通知システムのリプレイス のフェーズ2を終え、旧環境のプッシュ通知システムのリプレイスを完了したのでシステム構成や移行手順をご紹介します。 目次 目次 1:Nのプッシュ通知システム リプレイス前の1:Nのプッシュ通知システム リプレイス前のシステム構成 問題点 リプレイス後の1:Nのプッシュ通知システム リプレイス後のシステム構成 1:Nキュー（Sidekiqダッシュボード） 負荷テスト 目標 対象 事前準備 負荷テスト実施 負荷テスト結果 負荷テスト実施後の改善内容 大量の通知の遅延を減らす 同時実行数の調整 500件単位でFCM通知配信 1:N通知配信の親ジョブ 500件単位でFCM配信を行う1:N通知配信の子ジョブ 500件単位でDynamoD
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の中でも最も大きな機能であり、最も重要な機能です。そのため、リプレイスは慎重に進めなけ
はじめに こんにちは。検索基盤部 検索技術ブロックの今井です。 検索基盤部では検索機能や検索精度を改善する中で検索クエリの意図解釈にも取り組んでいます。ZOZOTOWNで検索窓にクエリを入力して検索ボタンを押すと、クエリに応じて検索の絞り込み条件に変換するクエリ解釈機能の処理が動作します。 例えば、「ワンピース 白色」と検索した時、「ワンピース」を洋服のカテゴリー、「白色」を色のカテゴリーと解釈し、「白色のワンピース」を検索する絞り込み条件に変換します。 2024年5月現在ではスマートフォン向けWebサイト（https://zozo.jp/sp/xxx）とアプリのみ、クエリ解釈機能の処理が適用されています。クエリ解釈機能では意図解釈や検索の絞り込み条件に変換しています。 現在はシンプルな辞書ベースの手法を用いていますが、カバーしきれない課題も出てきており、改善のモチベーションが少しずつ上が
WEARをリノベ！Objective-CからSwiftへのリプレイス戦略でも使えるスナップショットテスト - ZOZO TECH BLOG
目次 目次 はじめに マイページ画面リプレイスに伴う課題 使用したライブラリ Objective-Cでリファレンス、Swiftでテスト リファレンス画像のファイルサイズを小さく デバイスも言語も一気にテスト 複数言語のテスト自動化 複数デバイスを一気にテストする方法 いにしえVCのためのスタブデータの用意 おわりに はじめに みなさん、こんにちは！ 松井です。普段はWEAR iOSアプリ開発で、コードを書く筋肉をパンパンに鍛えています。WEARアプリは、長い歴史を持っており、まだまだObjective-Cで書かれたレガシーなコードも居座っているんです。そんな中、私たちは地道にリファクタリングを進めています。そうしたObjective-CからSwiftへのリプレイス戦略において、スナップショットテストを活用したお話をしたいと思います。 スナップショットテストと聞くと、一般的にはコードの修正前
こんにちは。WEARバックエンドエンジニアのid:takanamitoです。先日リリースしたWEARの新プッシュ通知基盤の紹介をしようと思います。 新プッシュ通知基盤開発の背景と目的 WEARでは既にiOS/Androidアプリに向けたプッシュ通知配信基盤が存在していました。 しかし、かなり昔につくられた基盤ということで運用にコストがかかったり、必要な機能が足りていなかったりします。 例えば、ユーザー全体にプッシュ通知を送りたい場合に以下のような問題が存在しました。 ログイン済みユーザーにしかプッシュ通知を送信できない プッシュ通知の送信開始から完了までに半日以上かかる 配信サーバーのスケールに手作業が発生する 1.についてはWEAR開発当初、はじめてプッシュ通知を導入するきっかけとなったキャンペーンが存在したものの、そのキャンペーンの対象がWEARアカウントを持っている人だったために、こ
WEARのAndroidアプリをBottomNavigationにリプレイスした際の状態保存について - ZOZO TECH BLOG
はじめに こんにちは。WEAR部の鈴木（@zukkey59）です。 普段は、「ファッションコーディネートアプリ WEAR」のAndroidアプリを担当しています。 実は最近、コツコツとやっていたリプレイスがおわり、AndroidアプリのBottomNavigation化がリリースされました！ 今回は、ドロワーメニューからBottomNavigationへリプレイスした際に悩んだFragmentの状態保存について、紹介します。 背景 今までのWEARのAndroidアプリは、iOSアプリと異なりドロワーメニューという古いUIのままだったため、BottomNavigationでの実装を行うことにしました。 実装を進めていると、BottomNavigationの項目の切り替えを行うことでリストのデータやスクロールの位置が保存されない現象に遭遇しました。 BottomNavigationの項目切り
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」という名前でやっているので、ぜひフ
こんにちは、WEARバックエンドブロックの天春（@AmagA001）です。バックエンドの運用・開発に携わっています。WEARはサービス開始から10年ほどの古いVBScriptを使った環境からRuby on Rails環境にシステムリプレイスを行なっています。本記事では、リプレイスの中でも既存環境が複雑で問題や課題が多くあったPUSH通知システムのリプレイスについてご紹介します。 目次 目次 PUSH通知システムとは リプレイス前のPUSH通知システム リプレイス前のPUSH通知システムの問題点 通知送信バッチのスケールアウトが出来ない 障害対応・運用が難しい状況 複数の開発言語による運用・改修コストが高い ステージング環境で通知確認ができない リプレイスの背景 リプレイス後のPUSH通知システム 非同期システム・EKS導入 既存システムの問題解決 バッチのスケールアウトが出来ない 障害対応
コミューンのモバイルアプリを Flutter でリプレイスしている話 - Commune Engineer Blog
はじめに こんにちは、コミューン株式会社でソフトウェアエンジニアをしている牛嶋です。 2022 年 4 月にコミューンに入社してから、モバイルアプリチームに所属しており、Flutter を用いてコミューンのモバイルアプリ開発に従事しております。 元々コミューンのモバイルアプリは React Native で開発されていましたが、2022 年の 4 月から Flutter を利用したクロスプラットフォーム開発に取り組んでいます。 具体的には、WebView を利用してコンテンツを表示していた部分を Flutter 側で実装し直すことに取り組んでおり、その結果として、ユーザー体験の向上させることを目的としています。 この記事では、Flutter を利用したリプレイスプロジェクトの概要について書いていきたいと思います。 はじめに リプレイス PJ の背景 段階的リプレイス計画 第一弾リプレイス
こんにちは。技術本部SRE部ZOZO-SREブロックに所属している杉山です。SRE部のテックリードとして、オンプレ/クラウドのインフラを担当しています。 ZOZOTOWNでは、既存システムのリプレイスプロジェクトを進めています。各サービスのマイクロサービス化は進んでいますが、バックエンドでは「WindowsServer + IIS」で稼働しているシステムがまだ多く残っています。そのリプレイスプロジェクトを進めるうえで重要なポイントとなる、セッションストアのリプレイス「セッションオフロードPhase 2」が完了しました。本記事では、リプレイスしていくうえでの工夫や課題への対応を紹介します。 目次 目次 セッションオフロードPhase 2について プロジェクト概要 Phase 1：CacheStoreのリプレイス Phase 2：SessionStoreのリプレイス ZOZOTOWNが抱える、
プロダクト開発未経験なプロダクトマネージャーがモバイルアプリのリプレイスを成功させた話 - Commune Engineer Blog
はじめに コミューン株式会社でプロダクトマネージャーとして働いている岡上と申します。 コミューンでは「あらゆる組織とひとが融け合う未来をつくる」をビジョンとして掲げ、｢commmune｣と｢SuccessHub｣のプロダクトを提供しています。 「commmune」はオンラインコミュニティプラットフォームをノーコードで作成できるSaaSです。toB/toC問わず、スタートアップからエンタープライズまで幅広いクライアントにご利用いただいています。 私はこれまでカスタマーサクセスとしてキャリアを歩んできましたが、コミューンに入社してプロダクトマネージャーにジョブチェンジいたしました。 カスタマーサクセスはユーザーの課題に詳しく、課題解決能力も求められる職業です。そのため、プロダクトマネージャーに求められる適性を満たしているケースがあると考えています。 本記事では、プロダクト開発未経験の状態から、
こんにちは、カート決済部の佐藤です。普段はZOZOTOWNカート決済サービスの新機能開発、既存改修、運用保守を担当しております。 弊社はモノリスからマイクロサービスへのリプレイスを進めており、カート決済サービスも先日リプレイスPhase1の記事を掲載いたしました。 techblog.zozo.com 本記事ではカートリプレイスPhase1全体を振り返りつつ、リプレイスプロジェクトを進める中で苦労した点や得られた知見等の、リプレイスの裏側をご紹介したいと思います。 カート機能はECサイトの中核を担う機能であり、障害のリスクを考えるとドラスティックな改修には中々手を出しにくい機能だと思っています。しかし、弊社ではリプレイスをしたことで確実に前進できたため、同じようなお悩みを抱えている方の参考になれば幸いです。 はじまり カートリプレイス計画の始動 カートリプレイス計画の策定 アーキテクチャ構成
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
愛すべきAngularとのお別れ。2,3年後を見据えReactにリプレイスする話｜Yuito Sato
70万通りのURLを持つWebサービスを Next.jsにリプレイスして高速化した話
pixivをNext.jsでリプレイスする取り組みをご紹介します。 - pixiv inside
5ヶ月で完走！新規開発を止めないAngular→Reactリプレイスの進め方まとめ｜Yuito Sato
VueをReactにリプレイスしてEasyからSimpleにした話
大規模サービスのインフラを全面的にリプレイスした話 - Qiita
GitLab令和最初のリプレイス。フルコンテナ化ポスグレ移行 - pixiv inside
カウルのアプリをFlutterでリプレイスしました｜yamarkz - Kazuki Yamaguchi
個人開発の副業にはFlutterが一番。リプレイスのポイントとアプリのグロースの考え方 | Offers Magazine
Goで作ったシステムをRubyでリプレイスすることを検討してみた
SREの活動事例紹介 〜 Backlogのマイクロサービス化に向けた課題検索機能のリプレイス
社内共通システムをPHPからRuby on Railsにリプレイスした話
ZennのE2Eテスト基盤をリプレイスしました（開発体験向上、CI時間の短縮、Playwright移行）
レガシーフロントエンドをNext.jsにリプレイス 「開発生産性の向上」を感じさせてくれた5つのこと
「レストランボード」における大規模フロントエンドの漸進的なVueリプレイスの取り組み
機能開発・運用効率向上のためにKotlinからRustへ Webアプリケーションのリプレイスにおける設計・開発の考慮
WEARにおけるプッシュ通知システムのリプレイスを全て完了した話 - ZOZO TECH BLOG
ZOZOTOWNのクエリ解釈機能の改善に向けたAPIリプレイスの取り組み - ZOZO TECH BLOG
FCMを使ったWEARプッシュ通知基盤リプレイス - ZOZO TECH BLOG
ECSからのリプレイスで“約10倍”になってしまったEKSコスト 異常値を調査してわかった、コスト急増の原因
WEARにおけるPUSH通知システムのリプレイス - ZOZO TECH BLOG
ZOZOTOWNにおけるセッションストアのリプレイス完了までの道のり - ZOZO TECH BLOG
ZOZOTOWNカート機能のリプレイスPhase1裏側を大公開 - ZOZO TECH BLOG
getnews.jp
jiyugaoka-family-hifuka.com
hirojisan.hatenadiary.jp
qiita.com/km____
ameblo.jp/zokukokon
www.google.com