サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
中東情勢
tech.mobilefactory.jp
駅奪取チームでエンジニアをしている id:kebhr です。 今回は、駅奪取チームにおけるプロジェクト管理のツールとして、従来利用していたガントチャートに加え、新たにバッファ傾向グラフを導入してみた経験について書きます。 バッファ傾向グラフとは このプロジェクトでは、プロジェクト管理手法として CCPM (Critical Chain Project Management) を採用しました。 CCPM では、個別のタスクにはバッファを設けず、すべてのバッファをプロジェクトの終盤に設けます。このバッファをプロジェクトバッファと呼びます。 必然的に、プロジェクトが進行するにつれて、プロジェクトバッファを消費していきます。 プロジェクトバッファの消費量を可視化するツールがバッファ傾向グラフです。 下図のような、横軸に日付、縦軸にバッファ消費率を取るグラフです。 バッファ傾向グラフ バッファ消費率
駅メモ!開発基盤チームの id:xztaityozx です。 今回はテスト実行のボトルネックを OverlayFS を利用することで解消した話と、OverlayFS の動作を調べるためにbpftraceを使った話をします。 かんたん概要 Test::mysqldを使って挿入済みのデータを持ったmysqldをテストごとに起動していた データが増えてきたことでコピーがめちゃくちゃ遅くなり、開発体験が最悪になった コピーを OverlayFS でのマウントに置き換えてすごく速くした 動作について気になる点があったのでbpftrace を使ってトレースを行い、カーネル関数の呼び出しも観察した 前提 この記事で登場する主なツールのバージョンを示します Ubuntu 22.04.4(WSL2) カーネル: 5.15.146.1-microsoft-standard-WSL2 hyperfine 1.1
言葉の定義 モバファクの 1on1 の目的 1on1 で自分が大事にしていること 1on1 はメンティーの時間である 1on1 はメンターの時間でもある 1on1 初回 今使っている 1on1 のフォーマット 体調 半期目標の進捗振り返り ネクストアクションの振り返り うまくいかなかったこと・もっとよくなりそうなところ・うまくいったこと・その他に話したいこと ネクストアクション 1on1 の中でのやりとり お休みの取り方がわからない 最近見積もりの精度が高くなっている 朝会の議事録をとるようにしたい 最近チームの動きがぎこちないと感じている 1on1 定期的な振り返り まとめ こんにちは。駅メモエンジニアの id:dorapon2000 です。 今回は自分自身がメンター側として実施している 1on1 について、どのように実施しているのかご紹介しようと思います。 1on1 のやり方はメンター
こんにちは、ブロックチェーンチームの id:charines です。 今回は ERC-721 コントラクト(NFT コントラクト)にメタトランザクションを導入した開発事例について紹介します。 主にブロックチェーンに関する開発者の方を対象とした内容になります。 メタトランザクションの導入理由 1. マーケットプレイスのユーザが NFT を出品しやすい 2. NFT クリエイターがコントラクトを管理しやすい 実装方針 実装 フォワーダー ERC-721 まとめ メタトランザクションの導入理由 メタトランザクションとは、トランザクションの実行に必要なガス代を実行者ではない第三者が払うシステムです。 これによりトランザクション実行者は ETH を保持する必要がなくなり、 DApps を利用する障壁の 1 つを取り除くことができます。 弊チームでメタトランザクションを導入したい具体的な目的は主に 2
駅メモ!チームエンジニアの id:yumlonne です。 この記事では Redis の sorted sets で実装していたランキング処理を MySQL に移行した仕組みを紹介します。 背景 駅メモ!には複数のランキングがあり、Redis の sorted sets を使うことでパフォーマンスの高いランキング処理を実現していました。 中にはリリースからの全期間に渡るデータを利用するランキングもあり、Redis のメモリ使用率は日に日に増えていく一方でした。 何度か Redis をスケールアップしてメモリを増やすことで対応していましたが、根本的に対応しなければ今後も Redis をスケールアップもしくはスケールアウトさせ続けるしか選択肢がなく、コストが増え続けてしまう状況でした。 調査したところ、一部のランキングがメモリ使用率の 2/3 程度を占めていることが判明しました。 そこで、その
皆さんこんにちは、最近ずっとポットのお湯を沸かし続けないと寒くて耐えられないエンジニアの id:Dozi0116 です。 今回は、 dayjs で相対時間を求める方法、自由自在に操る方法を紹介します。 TL; DR 以下は今日紹介する出力をいじるための設定と、利用例です。 import dayjs from "dayjs" import relativeTime from "dayjs/plugin/relativeTime.js" import updateLocale from "dayjs/plugin/updateLocale.js" import "dayjs/locale/ja.js" // 基準になる時刻を調整 // l: relativeTimeで使うkey // r: dで判定した時、この値以下までがこの閾値になる // d: 判定に利用する時間単位、省略した場合は直前の
こんにちは!ブロックチェーンチームでエンジニアをしている id:dorapon2000 です。寒暖ある中でインフルも流行っているようで、私も咳がなかなか収まらず困っています。皆様におかれましても体調にはお気をつけください。 今回はタイトルの通り「緊急度が低く重要度が高く、そして重いプロジェクト」を私が担当した際に感じたことや学んだことをまとめた記事になります。前半で私の担当したプロジェクトの経過について感じたことをお話して、後半で学びをまとめます。 第二領域 重い第二領域の問題 私の場合 初期 中期 後期 重い第二領域プロジェクトを通しての学び まとめ 第二領域 「緊急度が低いが重要度が高いタスク」では記述にあたり少し長いので、ここでは第二領域1のタスクと呼ぶことにします。今すぐではないがいつかは必ずやらねばならないタスク。例えば OS やライブラリのアップデート、開発負債の解消などが第二
こんにちは、ブロックチェーンチームの id:charines です。 今回はアップグレード可能なスマートコントラクトの開発事例について紹介します。 コントラクト開発者のみなさんの参考になればと思います。 アップグレード機能の必要性 アップグレード可能なコントラクトの仕組み 今回行った実装 コントラクト実装 プロキシをデプロイする仕組みの実装 まとめ アップグレード機能の必要性 ブロックチェーン上に展開されたコントラクトはオフチェーンのアプリケーションと異なり、通常は後から実装を修正したり機能を追加することはできません。しかしアップグレード可能なコントラクトとして設計することで、変更の余地を持たせることが可能になります。 例えば弊チームでは NFT をウェブコンソールから生成できる、「ユニキスガレージ」というサービスを開発・運用しています。 以前このブログでも紹介した ERC-2981 への
こんにちは!ブロックチェーンチームでエンジニアをしている id:dorapon2000 です。最近買ってよかったものは「潮の華 あおさといわしふりかけ」です。 今回は Git の Squash マージについての知見を共有したいと思います。端的に言うと、 チーム開発で Non Fast-Forward マージをやめて Squash マージを採用し、再び Non Fast-Forward マージに戻した経緯の説明です。Squash マージを運用に導入するか考えたことがある方の参考になればと思います。 Squash マージとは マージには 3 種類ありますね。みなさんはトピックブランチを main へマージする際にどのマージ方法を利用していますか? Fast-Forward マージ git merge --ff-only Non Fast-Forward マージ git merge --no-f
駅メモ!チームエンジニアの id:yumlonne です。 この記事では駅メモ!で使っていた Memcached を廃止し Redis に統合した経緯や流れを紹介します。 記事内で提供するサンプルコードは、駅メモ!の実装に合わせ Perl となってます。 簡単なコードなので Perl に詳しく無い方でも十分理解できると思います。 KVS 統合の背景 駅メモ!は AWS を使ってサービスを提供しています。 統合前は Amazon ElastiCache で Memcached と Redis の両方を運用していました。 Memcached はプライマリノードのみ、Redis はプライマリノードとレプリカノードそれぞれ 1 台の構成でした。 それとほとんど同じ構成が他に 2 セットあるため、全体を見ると Memcached は 3 ノード存在していました。 Memcached は m6g.la
こんにちは、駅メモ!でフロントエンドを良い感じにしたかったチームの id:yunagi_n です。 今回は、駅メモ!にて使用している Vue.js を 2 系から 3 系へあげて行くに当たって、採用した手法とマイグレーションプロセスについて紹介します。 今回、マイグレーションするに当たって、以下の要件がありました: 機能開発を止めてはいけない 駅メモ!では 6 月と 10 月に周年リリースがあり、それの開発を止めるわけにはいきませんでした もちろん、その間にあったイベントなどについても、開発は継続し続けています 多くのメンバーは割けない 基本はわたしが中心に、追加で 1 人〜2 人に手伝ってもらうことはありました また、参考のため、駅メモ!のフロントエンドの規模感を紹介しておくと: Vue コンポーネント数は 1500 コンポーネント fd --type file --extension
こんにちは、エンジニアの id:kaoru-k_0106 です。 駅奪取のサブスク機能である「駅奪取er定期券」は、App Storeのサーバ通知の実装の際に App Store Server Notification V2 を用いました。 他の言語での Server Notification V2 の実装例は見つかりますが、Perl のものはありませんでした。 そこで、今回は Perl での検証部分の実装方法について触れようと思います。 App Store Server Notification V2 について V1 のときは、通常の App 内課金と同じように、サーバ通知で送られてきたレシートを、App Store サーバの verifyReceipt エンドポイントに送信して検証する必要がありました。 参考: App Storeを使用してレシートを検証する - 日本語ドキュメント -
こんにちは!BC チームでエンジニアをしている id:d-kimuson です。 今回は外部リレーションに関して型安全性の乏しい TypeORM の Data Mapper パターンを独自のユーティリティ型を使ってちょっとマシにする方法を紹介します。 前提: TypeORM の外部リレーションについて TypeORM では ManyToMany 等のデコレータを使ってスキーマに Foreign Key を書くことができます。 // 公式ドキュメントのサンプルです @Entity() export class Category { @PrimaryGeneratedColumn() id: number @Column() name: string @ManyToMany((type) => Question, (question) => question.categories) quest
駅メモ!開発基盤チームの id:xztaityozx です!今回は CI/CD のお話です。 現在、駅メモ!チームでは Jenkins を使った CI/CD が構築されています。今回ここに GitHub Actions を加えることとなりました。チームでは段階的に GitHub Actions に移行していく計画です。 GitHub Actions を採用した理由としては、技術スタックの変化による需要の増加と Jenkins で抱えていた問題を解決するためという 2 点が主です。この記事では後者について書こうと思います。 現在の Jenkins 構成で困っていたこと 現在の Jenkins 構成では、起動できるサーバのスペックを柔軟に切り替えたり、追加できるようにしたいというリクエストに答えづらい状態でした。仕組み上の制約などから、追加の作業はそこそこ時間のかかる作業となっていたからです。
こんにちは、エンジニアの id:mp0liiu です。 今年も7/2にPerlの最新安定バージョンである5.38がリリースされたので新機能や変更点についてまとめます。 5.38 はかなり変更点が多いですが、ニッチな機能に対する変更も多いので影響の大きそうな箇所だけ知りたい方は最初の方だけ読んで頂くといいと思います。 重要な変更点 class構文の追加 実験的機能としてですが、ついに Perl にclass構文が追加されました。 次のような構文になります。 use v5.38; use experimental 'class'; class Point; field $x :param = 0; field $y :param = 0; method move($dx = 0, $dy = 0) { $x = $dx; $y = $dy; } method print { say "x: $
こんにちは!BC チームでエンジニアをしている id:d-kimuson です。 最近、弊チームで構築した社内向け Web API のバックエンド設計をしたので事例として紹介しようと思います。 フレームワークとして NestJS を採用していますが、NestJS Way よりも TS Way を意識した設計をしており、このエントリの主題でもあるため、TS Backend の設計事例として読んでいただければと思います。 対象システムの概要 社内の他サービス向けの Web API で、他チームのサービスを経由してエンドユーザーに届く中間システム チーム内のサービスからもチーム外のサービスからも叩かれる想定 チーム外からも叩かれるため、なんらかのスキーマを共有したいというモチベーションがある → 2023 年現在で標準的な OpenAPI Specification (以後 OAS と呼びます)
pnpm には Docker でキャッシュを利用しやすくする fetch というコマンドが用意されています この記事では pnpm fetch を使ってキャッシュを利用しやすい Dockerfile を書いていく方法を紹介します Docker のマルチステージビルドとキャッシュ Docker にはマルチステージビルドという機能が存在し、単一の Docker イメージ下で実行するのではなく、ビルドやインストール, 本番実行等に分けて Docker イメージ を作成できます Dockerfile でマルチステージビルドを行う際の例を示します ARG NODE_VERSION=18.15.0 FROM node:$NODE_VERSION-buster as builder # build 処理 RUN pnpm build FROM node:$NODE_VERSION-slim as run
メリークリスマス 🎉 BC チームの id:d-kimuson です。アドベントカレンダーもとうとう最終日となりました! 今年のアドベントカレンダーでは、初日の記事は僕が執筆をしました この記事を書いていて、レビューをお願いしていたら以下のような投稿をもらいました 社内ではドキュメントサービスとして DocBase を使っているので、技術ブログの下書きを DocBase に書いていたのですが、Pull Request で行うレビューに比べてレビューがしづらいよね、というものです 課題があれば解決するのがエンジニアです かねてからローカルで書けたほうが執筆体験良いのに... と思っていたこともあり ローカルで記事を執筆できる GitHub 上でレビューができる ような仕組みを整えて、今年のアドベントカレンダーのお試し運用をしてみたので紹介します ローカルで執筆できる環境の整備 エンジニアに
🎄モバイルファクトリー Advent Calendar 2022! 毎週土曜日は「良いモノ」を作る技術というテーマで、モバファクの非エンジニアが知見やTipsをお届けします! こんにちは。「駅メモ!」開発チームディレクターの id:Torch4083 です。 この記事では、エンジニア以外の職種による勉強会を増やすメリットについて改めて整理し、実際に開催する際に役立つ事例を添えてお伝えいたします。 まえおき:モバファクの社内制度 それって、エンジニアはなにがうれしいの どうやってるの 勉強会のケース 輪読会 LT会 ワークショップ プレゼン・講義形式(+ 質疑応答) 具体例 ゲームプランニング勉強会 『イシューからはじめよ』輪読会 おわりに まえおき:モバファクの社内制度 弊社には「1日の業務時間のうち1時間は勉強に充ててOK!」という制度があります。(「シェアナレ」と呼ばれています) 業
こんにちは。駅奪取チームエンジニアのid:dorapon2000です。 私達のチームでは、4月〜7月にプロダクトの負荷対策に注力しました。その結果、通信量の削減やDB負荷の低減、それに伴うインフラコストの削減などに繋がりました。負荷対策の方法は手探りながら多くのことをしたのですが、その中で今回は不要なDBのロック待ちを改善した部分に注目して、どのような方法でロック待ちを改善したかについてサンプルコードを交えてお話していきます。 ロック待ちの改善にバリエーションがあることについて持ち帰っていただけると幸いです。 環境 Amazon Aurora MySQL version 2 (MySQL 5.7) データベースエンジンはInnoDB トランザクション分離レベルはREPEATABLE READ ロックとロック待ち 詳細は他の記事にお譲りします。ここでは簡単な説明をば。 ロックをわかりやすく言
こんにちは、エンジニアの id:mp0liiu です。 自分が所属しているチームでは現在もPerl製のプロダクトを運用しており、VSCode で Perl のコードを書いたり触ったりする機会が多いです。 Perl は開発環境が貧弱で他の言語と比べるとあまり開発体験はよくありませんが、それでも少しずつ便利な拡張機能が充実していってるので、この記事では自分が利用している便利な VSCode の Perl 向け拡張機能を紹介します。 Perl Navigator marketplace.visualstudio.com 今年話題になった Languager Server を利用した拡張機能です。 他にも Perl の Languager Server を利用した拡張機能はいくつか種類がありますが、以前から存在する拡張機能と比べると自動補完やコードジャンプがちゃんとできたり、Perl::Criti
駅メモ!チームでエンジニアをしている id:stakHash です。 弊社の主力プロダクトの 1 つである駅メモ!は、今年で 8 周年を迎えました 🎉 スマートフォンゲームとしては息の長いサービスですが、現在でも日々様々な新機能の開発が進んでいます。 今後も今以上の速度でユーザの皆様に価値提供をしていくためには、分かりやすく変更しやすいコードベースを維持・改善していくことが必要です。 しかし、「分かりやすさ」「複雑さ」という主観的でぼんやりとした感覚値は、長いライブサービスでは、人員の入れ替わりもあって判断が困難になっていました。 そこで、「複雑さ」 を定量的に計測する方法を探ってみました。 「複雑さ」とは 今回は、Microsoft 社が主に Visual Studio 内で利用している保守容易性指数 (Maintainability Index)を扱ってみます。 MAX( 0, (1
駅メモ!チームエンジニアの id:yumlonne です。 この記事ではスーパープロジェクト(サブモジュールが登録されている親プロジェクト)側で git checkout や git pull を実行したときに、自動で git submodule update 相当の処理を実行してくれる便利な設定を紹介します。 git submodule についてはドキュメントを参照してください。 記事中の各種動作は git version 2.38.1 で確認しています。 背景 私は最近サブモジュールが存在するプロジェクトを触り始めました。 しかし、git 操作をするときにサブモジュールが存在することを意識していないと、サブモジュールの参照を意図せず書き換えてしまうことがありました。 $ cd MyProject $ git checkout topic-A # サブモジュールをtopic-Aブランチが
🎄モバイルファクトリー Advent Calendar 2022!毎週土曜日は「良いモノ」を作る技術というテーマで、モバファクの非エンジニアが知見やTipsをお届けします! こんにちは。モバファクでマネージャーをしているゆっぴぃです。 タイトルにもある通り、エンタメ企業の社員である私が、どのようにエンタメを楽しんでいるのかをブログ記事として書いてみました。 これを書こうと思った背景 社内でチームメンバーからこんな質問を受けました。 「ゆっぴぃさんって、いつこんなにアニメを見たりゲームをやったりしてるんですか?」 メンバーがこの質問をした背景には、普段の業務における会話の中で、私がアニメの話だったりゲームの話をする印象があるからかな(?)と思います。 ただ、その私に対する印象はインプットしている量が多いからではなく、私のアニメ等に関する発言(アウトプット)頻度が多いことが影響しているのでは
駅メモ!チームエンジニアの id:Eadaeda です。 みなさんシェルスクリプト書いてますか?私は時々書いています。12/2 の記事ではシェルスクリプトのテストを書いてみませんかという話を書きました。 tech.mobilefactory.jp 今回はテストではなく、linter の話です。 シェルの文法はなかなか難しいです。例えばダブルクォートで括るかどうかなどです。 # スクリプト a.sh があるとして $ cat ./a.sh #!/bin/bash echo "[$1]" "[$2]" "[$3]" "[$4]" "[$5]" "[$6]" # 例:引数のコマンド置換をダブルクォートで括るかどうかで動作が変わる $ ./a.bash $(date) [Wed] [Nov] [30] [17:06:59] [JST] [2022] $ ./a.bash "$(date)" [We
こんにちは、エンジニアの id:yunagi_n です。 みなさんは JavaScript において、 URL をパースするとき、どの API を使用していますか? もっとも簡単なのは、 URL Interface を使用することだと思います。 今回は、その URL Interface が、 JavaScript の実行エンジンによって挙動が異なることについて書こうと思います。 事前情報 この記事の内容は、以下のバージョンにて確認を行っています。 macOS 12.5.1 Google Chrome 107.0.5304.121 Safari 15.6.1 Firefox 107.0.1 本題 URL Interface は、 各種ブラウザおよび Node.js 上で URL を扱うためのインターフェースです。適当な URL を渡すと、下のように各部分毎に分解してくれて、 URL を元に何
こんにちは。モバイルファクトリーでエンジニアをしているまえけんです。 自分の居るチームではスクラムで開発をしていて、自分はスクラムマスターとしてチーム運用をしていました。 が、プロダクトオーナーの退職と組織編成によるチーム人数の増加などにより、スクラムマスターからプロダクトオーナーへ帽子を被り直すことになりました。 そこで、初めてプロダクトオーナーをやってみて何があったのか、気づいたこと、などをまとめようと思います。 突然の別れと新チーム 自分がスクラムマスターをしていた頃、チームは全部で5人居ました。しかし1ヶ月の間に、 新プロジェクトの立ち上げ プロダクトオーナーの退職 組織編成に伴いチームメンバーが5人から9人に増加 という怒涛の変化がありました。特に当時のプロダクトオーナーとは新プロジェクトについて立ち上げから協力して計画を建てていたので、その半ばでの退職ということで突然の別れとな
🎄モバイルファクトリー Advent Calendar 2022!毎週土曜日は「良いモノ」を作る技術というテーマで、モバファクの非エンジニアが知見やTipsをお届けします! こんにちは。駅メモ!シリーズでデザイナーをしている19卒入社の @watagisanです。 アドベントカレンダー初投稿ということで、新卒デザイナーとして、「どのように行動すると入社して早い時期からいい感じに会社に貢献できるか」について個人的に意識していた「心構え」のまとめを書きました。 こころとからだのためにたいせつなこと 睡眠はたいせつ IT関係の企業では、どちらかというと頭を使うお仕事が多いのでしっかり休まないと日常業務に支障をきたします 作業時間(残業時間)ではなく成果を自慢しよう 自分の扱いがおかしいなと感じたらすぐに誰かに相談する 上司もチームももちろん僕もあなたも、人間なのでチームメンバーとの相性が悪かっ
こんにちは。駅奪取エンジニアのid:dorapon2000です。 コード差分の大きなプルリクエスト(以下、プルリク)をコードレビューした経験は多くの方があると思います。 プルリクは小さく・単位ごとに、とは頭でわかっていても、実装している内に想定よりも大きくなってしまったり、1つのプルリクにまとめなければコンテキストが伝わらなかったり、どうしてもということはあります。本当に申し訳ないと思いつつレビュー依頼を出したり、出されたり。 今回は、巨大なプルリクを前にして、自分がどうモチベーションを保つか、どう読み解いていくか、同じ状況を避けるためにレビューイと協力できることはなにか、について自分の場合を例に紹介していきます。 プルリクは小さく ここでは巨大なプルリクは避けるべきだという前提で記事を進めていきます。 つまり、プルリクは可能な範囲で小さい方がよいという前提です。 その理由は、コードレビュ
次のページ
このページを最初にブックマークしてみませんか?
『Mobile Factory Tech Blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く