はてなブックマーク

こんにちは、松久です。 昨年（2023 年）、デザインチームに新しいデザイナーが加わりました。新しいデザイナーがすぐ活躍しやすいようにオンボーディングを実施しました。 デザインチームでのオンボーディングとは デザインチームでのオンボーディングが久しぶりなので、改めてオンボーディングの目的を定めました。 入社してきた人が、早く実力を発揮しやすくすること（自分がチームでやっていけそうという感覚を手に入れる） 入社している人が当たり前と思っていたことを改めて確認する機会になること 目的を「入ってくる側」「受け入れ側」の 2 つに分けて、オンボーディングの実施計画を用意しました。 受け入れ側のオンボーディングの目的は、ドキュメントにもなんもなっていないことを言語化してみることで、説明できる状態を目指しました。また、そもそも「当たり前」と思っていることについて、指摘をもらわないと気付けないことが増え

こんにちは。松久です。 デザインデータを作るとき、デザイナーが一人で作業をすることもありますが、複数のデザイナーや、デザイナー以外の職能の人と一緒に取り組む事も少しづつ増えています。 現在、どのようにデザインデータを作っているのかを紹介します。 デザインデータができるまで 食べチョクで、デザインデータができるまでの大まかな行程は下記の通りです。 施策の目的を整理する。資料を集める。 施策の目的にそったデザインの初稿を作る 関係者で見ながら作って確認する（ モブデザイン・ペアデザイン ） デザイナー同士で確認・検討をする（デザインレビュー） 関係者で合意する（ デザインが確定 ） 今回は 3〜4 の工程で取り組んでいることを紹介していきます。 UI のためのデザインデータは認識合わせのためのドキュメント デザイナーが作っている「デザインデータ」の役割は、バナーなどのグラフィックとUIでは異な

こんにちは。プロダクト開発チームの Engineering Manager 兼 人事の @hirashun です。 利用率No.1の産直通販サイト「食べチョク」を開発/運用するビビッドガーデンではリリース当初からバックエンドをすべてRubyで開発しており、ユーザーに迅速なサービス提供ができる恩恵を最大限にあずかっております。 この度RubyKaigiが3年ぶりのオフライン開催@三重県ということで、Rubyコミュニティーに何か恩返しは出来ないことか・・・と考えた結果、 ビビッドガーデンは"Mie Food Sponsor"として三重のこだわり食材を携えて協賛することにしました！ こだわりをもってRubyで開発を続けるみなさんに、三重の生産者の方々のこだわりをたっぷりお届けします！是非RubyKaigiで三重の魅力もお楽しみください。 三重のこだわりお届けします オフライン参加の方だけでなく、

皆さんこんにちは、エンジニアの久保と金田一です。 今回は、食べチョクの自動テスト改善チームが取り組んでいるテスト実行速度の改善についてお話しいたします。 自動テスト改善チームとは何か？について知りたい方は、以下のエントリーをご覧ください。 食べチョクの自動テスト改善活動 〜これまでとこれから〜 食べチョクにおける自動テストの現状 食べチョクでは、GitHub Actions のワークフローを使って、push をトリガーに自動テストを実行しています。食べチョクのリポジトリには System Spec までを含んでいて、E2E は別リポジトリとなっています。 メンバーが増えて体制が整ってきたこともあり、この 1 年くらいに実装した機能についてはテストがしっかり書かれていることが多いです。一方で、それ以上前に作られた機能については、まだまだカバレッジが低い箇所もあり、みんなで手分けして少しずつテ

どうもはじめまして。 muryoimpl です。 前回のエントリ 食べチョクの自動テスト改善活動 〜これまでとこれから〜 で、自動テスト改善チームが発足したことを書きましたが、今回はその活動の中で実施した、RSpec による自動テストのカバレッジのデータ収集の自動化と、そのデータを利用した可視化について書きたいと思います。 これまではどう可視化していたか 食べチョクは Ruby on Rails で動いており、バックエンドの自動テストは RSpec を使って書いています。 テストカバレッジは定番の SimpleCov で計測して結果を HTML に出力し、テストケースごとの実行情報は RSpec JUnit Formatter を使って XML として出力して、GitHub Actions でそれらの情報を Code Climate に送信していました。 また、可視化という点では、以前ビビ

みなさん初めまして。 QAエンジニアのujeです。 食べチョクでは、2022年4月から正式に自動テスト改善チームが発足いたしました。 チームメンバーは機能開発との掛け持ちにはなりますが、Webエンジニア5名・QA1名で取り組んでいます。 自動テスト改善チームの発足に伴い、食べチョクのテストにまつわる振り返りと、改善チームが取り組んでいることをお話しいたします。 これまで 食べチョクはサービスリリースから5年がたつプロダクトです。 特にここ1年半は食べチョクに参加してくれる仲間が増えており、サービス開発のスピードも上がっています。 食べチョクは2020年まで、テストカバレッジが低く、またなかなか向上しない状態でした。 システム全体に影響がある改修をする際は、毎回全画面を一通り手作業で触りテストするなど労力のかかる状態でした。 この状態を脱するため、2020年末から少しずつ自動テスト改善の動き

こんにちは。 食べチョクの開発を副業でお手伝いしているプログラマーの花村です。 監査ログをJSONL（JSON Lines）のファイルに記録するためのGemのAuditLoggableを作成してrubygems.orgで公開しました。 ソースコードもGitHubで公開しています。 ​ rubygems.org github.com なぜ開発したのか 食べチョクでは監査ログを記録するためにAuditedを利用していました。 AuditedはActiveRecordのコールバックを利用してモデルの変更を手軽にRDBに記録してくれる大変便利なGemです。 しかしRDBに記録するためテーブルサイズが肥大化しパフォーマンスに影響を与える場合があるというデメリットもあります。 食べチョクでは注文数の増加に伴ってこの問題に直面しました。 これを解決するにあたり以下のようなアプローチが思いつきます。 監査

皆さんこんにちは、エンジニアの西尾です。 あなたは今、コードレビューをしています。 以下コードに直面したとき、何を指摘しますか。 修正してほしい点を、どのようにレビュイーに伝えますか。 // これはJavaScriptのコードです。 // 商品の在庫を1つ減らし、売り切れになったものを抽出したい、と思っています。 const soldOutProducts = products.filter(product => { product.quantity -= 1; return product.quantity <= 0; }); よくないコードレビューの例 問題は表題の通り、filterの中で状態を書き換えているのが、よくありません。 関数型言語を学んだことがある方なら、このコードの違和感に気がつきます。 filterは純粋関数であるべきだ、副作用を起こしてはいけない。そう認識しているから

こんにちは。 今年の年始からジョインした遠藤です。 さて、入社したところ会社支給のMacBook ProがM1チップのものでした。 はい、現状は開発環境で苦労するとか色々噂を聞くやつです。 実際に試したのですが、 現状の開発環境構築スクリプト、手順書が一切使えない VitualBox, Vagrantは利用不可 Dockerは利用可能ではあるが、一部イメージが対応されてない 古いパッケージは動かす手段がない などなど、通常ではぶつからない問題にぶつかります。 食べチョクでは、 Ruby Node.js MySQL Redis ElasticSearch Kibana を利用しています。 この辺りをメインに話つつ、Intel版とこんな風に違うのかっていう辺りの雰囲気を感じ取っていただければと思います。 どこに開発環境を構築するか まず、どこで開発環境を構築するかを考えてみたいと思います。 ロ

こんにちは。食べチョクの開発をお手伝いしているフリーランスエンジニアのもぎゃ です。 ぼくも記事書いていいそうなので、最近食べチョクの開発をやっている時に発見したRailsテクニックの話を書きます。 バリデーションメッセージのつらみ Railsでバリデーションをつかって入力をチェックしている場合、@model.errors.full_message をエラーメッセージとして出すことができます。 Active Record バリデーション - Railsガイド ただ、ぼくらが作ったモデルの日本語名までRailsが知っていてくれるわけではないので、"User Messageを入力してください"みたいな分かりづらい文字列になってしまうことがあって、この場合i18nのリソースを適切に書いてあげることでエラーメッセージを改善することが出来ます。 Rails 国際化 (i18n) API - Rail

皆さんこんにちは、エンジニアの西尾です。 2019年9月24日(火)、フジテレビ系列のテレビ番組 「セブンルール」 にて弊社代表およびサービスを取り上げていただきました。 テレビ放送開始直後、サイトにはいままでにないアクセスが押し寄せましたが、 システムを落とすことなく、かつパフォーマンスも落とすことなく無事に稼働させることができました。 今回はテレビ放送前に、食べチョク開発チームが行ったパフォーマンス対策を紹介いたします。 開発チームのミッション 放送日が決まった時、代表が一言、Slackにつぶやきました。 サーバーを落とさない 放送中にサーバーは絶対落とさない。 この日から少しずつパフォーマンス対策を始めることにしました。 食べチョクのシステム構成 食べチョクはAWS上で運用しており、構成はとてもオーソドックスなものとなっています。 EC2,ELB,RDS,ElasticCache(R

はじめまして。食べチョク（株式会社ビビッドガーデン）のデザイナー千田です。 2024年11月、食べチョクアプリのFlutter化が無事完了しました。この機会に、プロジェクトの背景、進行過程、学びについてお伝えします。 Flutter化の背景 導入前は、アプリ開発をiOSとAndroidそれぞれで行っていたため、開発工数が二重で発生しており、かつ差異が生じていました。そこで、Flutter（複数のプラットフォームに対応したアプリケーションを一つのコードで開発できる）を導入し、根本的な開発工数削減と、これまで以上に新しい取り組みを実現できる状態を目指すこととなりました。 Flutter化前の状態 デザインマスター（Figma） ページによってデータがあったりなかったりの歯抜け状態😞 実装とデザインマスターに差がある（でもしょうがないよね）状態😞 iOS版を基盤に作成されており、Androi

皆さんこんにちは。エンジニアの西尾です。 今日は仕事を任せられるようなエンジニアになるために意識してほしいことをまとめましたので、ここに公開いたします。 もともとは社内向けに公開したものです。 この文章は私がビビッドガーデンに入社する前の、前職での経験を踏まえて書いています。 今の食べチョクエンジニアが意識できていない、という話ではありませんのでご注意ください。 意識面 作業の見積もりができる 技術力が低い（コーディングができないなど）よりも敬遠されるエンジニアは、作業の見積もりができない方です。 第一線で活躍している方は、作業見積もりが他の方に比べて正確です。 見積もりをするためには、どういう設計をして、どういう機能を作り、どういう影響範囲があるのかを正しく理解する必要があります。 見積もりができないということは、作業内容を正しく理解できていない、技術的な困難性を理解していない、不確定要

こんにちは。エンジニアの西尾です。 食べチョクのステージング環境では、本番環境のデータを日次で同期して利用しています。 今回はステージング環境の役割と、どのようにデータ同期をしているのかについてご紹介いたします。 ステージング環境 食べチョクでは、手元のマシンでプログラムを修正しコードレビューを実施後、改修内容をステージング環境にデプロイしています。 ステージングは、本番へのリリース前に修正箇所の動作確認・検証する環境です。この環境で動作や性能に問題がないかを確認後、本番環境へのデプロイを実施しています。 ステージング環境には、本番と同等のデータが入っています。 リリース当初は、ステージング環境と本番環境のデータは同期しておらず、テスト用のダミーデータで動作確認を行っていました。 しかしダミーデータでの確認だと、 ダミーばかりが並んだサイトと本番環境では見た目や印象が違っていて、UIが最適