minne事業部プロダクト開発チームのtepiです。先日minneのモバイルチームで「合宿」を行いましたのでその様子をご紹介したいと思います。実施内容について成果 良かった点反省点合宿の最後に打ち上げ！各パートナーの一言感想 kyuumatoshifumyyagijinまとめ実施内容についてデザインチームで合宿を行って有意義だったという話を聞きつけ、モバイルチームでもできないかと考え実施してみました。成果これまで「やりたい」で止まっていたAIを使った実装や動画の実装のプロトタイプを作成し、事業部内でデモを見せることができました。まだminneのモバイルアプリで活用できていない機能でしたが、活用のイメージが湧いてくるなど他部署の方からもポジティブな意見をもらえました。さらに、その過程で気づいてなかった改善点も発見し、改善に向けた実装を行うことができました。一方で合宿の目的である、「DAUの向上のための施策」はモバイルエンジニアのみで完結する施策がなく、実装には至りませんでした。良かった点集中した作業時間やりたいで止まっていた作業の可視化みんなで集まって作業する楽しさ反省点お題に関する諸々時間が短かった作業の分担合宿の最後に打ち上げ！このために今回のモバイル合宿をやったと言っても過言ではありませんが、なかなか一同に介することがないモバイルチームのメンバー全員でお酒を飲みました！今回の開催場所のGMO Yoursでは、毎週金曜日18:00 ~ 21:00にBar Timeが開催され、社員や招待者であればお酒・食事が無料で提供されています。さらに合宿を実施した3月29日は「GMO すごい花見 2024」と題して、桜の木を部屋の中に飾り特別メニューを提供するイベントを開催しており、お花見気分でメンバー同士親睦を深めました。各パートナーの一言感想kyu最初はDAU向上のための取り組みというお題でしたが、意見が発散してしまう場面も多く、事前準備が不足していたことには反省があります。最終的には個々人が思いついた課題やトピックについて、実際に実装を行う会となり、普段の業務と違いエンジニアが起点での取り組みを行うことができたので、非常に興味深く楽しめました。今回の取り組みからエンジニア起点での機能提案や改善も今後はできるようにエンジニア以外の方とコミュニケーションをとりアプリをより良い

こんにちは、最近は旅行しているか、コードを書いているかの２極化が進みつつあります、P山です。直近の業務において、私が支援している国内最大級のハンドメイドマーケットサービス minne において画像変換サーバの実装を変更し、大幅にコストダウンできたので、その事例を紹介します。minneについて minneはハンドメイド作家が創作したハンドメイド作品を販売することができるハンドメイド作家支援サービスです。技術スタックとしてはRuby on Railsを軸に、実行環境はOpenStackとAWSを用いたデュアルスタックのKubernetesを利用しており、スマートフォンアプリもiOS、Androidともに提供しています。 幅広い技術を、モダンな構成で扱うことができるので、もし採用にご興味があれば採用ページ をご確認ください。ペパボ社内を見渡しても若いメンバーが比較的多く、日々活気のある開発がされています。なにか個人的に相談したいことがあれば DM で質問もお待ちしております。画像変換サーバについて minneの画像配信はオリジナルのデータをS3に保存して、その前段にLambdaで実行される画像変換サーバがあり、変換した画像をCloud Frontで配信しています。ImageMagickからlibvipsへ 画像変換サーバについては、Go言語を用いて実装されており、変更前の画像変換についてはImageMagickを利用して実行されていました。今回、ImageMagickからlibvipsのGo言語のバインディング実装であるh2non/bimgを利用した実行に変更しました。なお、ImageMagickが利用されていた経緯としては、Go言語のimageパッケージを利用したところ、我々の環境ではうまくカラープロファイルが引き継がれないという問題があったため、ImageMagickをexecして利用するような実装になっていました。 下記にImageMagickとlibvipsのjpgイメージを用いたベンチマークの結果を示します。# サイズ変換処理BenchmarkConvertImageUseImageMagick-11 22 56439328 ns/opBenchmarkConvertImageUseLibVips-11 129 9790194 ns/op# サイズ変換+jpgか

はじめにminne 事業部でモバイルアプリエンジニアをしている @kyu です。今回、minne Android において、長らく支えてくれたビューバインディング用のライブラリであるButterKnifeを削除しました。その経緯と作業内容を共有し、この変更から学んだことを共有したいと思います。はじめにButterKnifeの概要 ButterKnife導入の効果ButterKnife削除の背景と決断 削除が遅れた理由:削除に至った動機:削除対応方針と内容 削除対応方針具体的な対応内容まとめと学びButterKnifeの概要ButterKnifeは、Androidアプリ開発においてビューバインディングを手軽に行うために広く採用されていたライブラリです。このツールは、XMLで定義されたビューとJavaやKotlinのコードをアノテーションを用いて結びつけ、冗長なコードを削減し、可読性と保守性を高める目的で使われました。ButterKnife導入の効果今更ではあるのですが、少しButterKnifeについて説明します。導入前の一般的な処理:以前は、onCreateメソッド内でfindViewByIdを使用してUIコンポーネントを手動で参照し、対応するフィールドに割り当てたり、イベントリスナーを設定する必要がありました。public class MainActivity extends AppCompatActivity { private Button button; private TextView textView; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); textView = findViewById(R.id.textView); button = findViewById(R.id.button); // ボタンが押下された処理 button.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { textVi

はじめにこんにちは、umatoshi & fumyです。このブログは、ペパボのminneに携わるiOSエンジニア達がお送りする「try! Swift Tokyo 2024」の参加レポートになります。try! Swift Tokyo 2024について「try! Swift」は、Swiftの開発者たちが世界中から集うコミュニティで、Swift・iOS・macOSをはじめとしたAppleプラットフォーム関連の最新情報・開発技術の共有や開発者同士の交流を目的とした国際色が豊かなカンファレンスです。2016年から始まり、現在では日本のみに留まらずにニューヨーク・インドでも開催されています。このイベントはベルサール渋谷ファーストにて3月22日〜24日の3日間の日程で開催され、3月22日〜3月23日の2日間はカンファレンス、最終日の3月24日にはワークショップが行われ、素晴らしい知見を拝聴する機会に加えて実際に手を動かしながら体験もできる、とても濃密な時間を過ごす事ができるイベントでもあります。2020年の開催が残念ながら新型コロナウィルスの流行が原因で中止となり、そこから5年の期間を経て、今年復活する運びとなったので久しぶりのオフライン参加ができる事が非常に嬉しかったです。そして今年は、弊社が開発しているSUZURIでも採用し、minneでも技術検証の際に利用経験がある「The Composable Architecture（以下、TCA）」を提供しているPoint-Free社からBrandon Williams氏とStephen Celis氏、そして普段の開発でも参考にさせて頂いている「Hacking with Swift」の著者でもあるPaul Hudson氏の登壇をはじめ、世界各国からのイベント参加者も多数見受けられるので、この機会を私達も本当に楽しみにしていました。カンファレンス中は、カンファレンス会場とは別に休憩スペースや企業様スポンサーブースも用意されており、様々なトピックに関する活発なコミュニケーションが生まれています。また海外から参加している開発者とも日本語以外の言語を交えて話す機会もあったりする点も、このイベントの大きな特徴だと思います。try! Swift Tokyoスポンサーブース巡りカンファレンスの合間には、勉強会や開発者コミュニテイ等でお会いした方や、

こんにちは、minne事業部の@nissyiです。minne事業部では、Web/Mobileエンジニアを対象にインシデント対応演習を実施しました。今回はその演習についてお伝えします。インシデント対応演習とは？演習の内容について今回の演習の狙い参加した感想や学び yumuyanagisaki-htr主催者視点での感想さいごにインシデント対応演習とは？GMOペパボでは年に一度、インシデントの対応力向上を目的とし、インシデント対応演習を実施しています。検証環境でインシデントを引き起こし、検知から障害・脆弱性への対応、各関係向への報告、事態の収束まで一連の流れについて実際に取り組みます。演習の内容について今回は、「GraphQLの認証・認可に脆弱性があり、情報漏洩につながった」というシナリオで演習しました。演習を実施するには、擬似的なインシデントを引き起こす必要があります。そのために、minneで使用しているプログラムを調査し、検証環境のコードに脆弱性を仕込み、攻撃者のように振る舞って攻撃を仕掛けました。その結果引き起こされた擬似的なインシデントに対して、@nissyi以外のWeb/Mobileエンジニアがインシデント対応にあたりました。今回の演習の狙い演習を実施するにあたって、「演習を実施することで、minneの開発者全員がどう成長してほしいか？」という観点で題材を考えました。演習の準備を進める際に上長の @ebihara99999 にアドバイスをもらっていたのですが、真っ先にもらったアドバイスが先述の観点を持つことでした。2024年3月現在、minneの新規のAPIはGraphQLで実装しています。また、既存のRESTishなAPIに関してもGraphQL化を推進しています。GraphQLで実装をするにしても、自分を含めチームのメンバーがGraphQLの認証・認可について理解が浅いのではないか？という課題を感じていたため、それをメインの題材として選択しました。また、サブの目的として「演習を演習として活用し、普段は挑戦しにくいことにも挑戦してもらう」ことを考えていました。実際のインシデント対応中には、一刻も早く対応・復旧する必要があるため、何かに挑戦しようとしても、心理的なハードルが邪魔してアクションしづらい状況が発生しがちです。演習ならば失敗しても実害は発生しないので、

minne事業部プロダクト開発チームのtepiです。お恥ずかしい話ではあるのですが、昨年6月に私が入社した時点でminneで利用されているAndroid Gradle Plugin(以下、AGP)のバージョンがv7.0.4だったため、これは・・・と思いコツコツ積み重ねてきた結果、先日AGPのv8.2にすることができましたのでその変遷をお伝えしていきたいと思います。スタート時点の状況トラブルと解決方法の依存関係の整理トラブルの解消 その1：Jetpack Composeへの変更トラブルの解決 その2：Deprecatedになったライブラリの更新 FirebaseInstanceIdの解決INSTANCE_ID_EVENTの解決その他トラブルの解消 その3：AGPのバージョンアップに伴う更新 non-transitiveの対応BuildConfigの自動生成の解決proguardの変更の解決完成！まとめスタート時点の状況昨年時点でv7.0.4だったのは、主にライブラリのアップデートが間に合っていないことが理由でした。また、そのライブラリの更新ができない理由がアプリのクラッシュに起因するものであったりしたため、クラッシュが発生するUIの作り直しなどが必要ですぐ直せるものではなく放置されてきていました。トラブルと解決方法の依存関係の整理まずは、「何が解決されれば、どのトラブルが解消でき、その結果どのライブラリが更新できて、最終的にAGPが更新できるのか」を整理しました。例えば、あるUIがEpoxyというライブラリを利用しており、それとappcompatライブラリの相性が原因でクラッシュしている。結果、appcompatライブラリの更新ができない結果、AGPも更新ができないといった具合です。ある程度の予測がついたところで、末端の問題から着手していきあとはただひたすらに出てくる問題に対応していきました。トラブルの解消 その1：Jetpack Composeへの変更minneでは古くから開発されていることもあり、XMLのViewや上記にも記載があるEpoxyライブラリを利用したViewなどが混ざっています。また、例に漏れずEpoxyのライブラリが更新されておらず、全体への影響を考えると更新しづらい部分もありました。そこにきて上記の例で記載しているように、appcompatライブラ