はてなブックマーク

こんにちは、駅メモ！開発チームエンジニアの id:hayayanai です！ 私が開発に関わる駅メモ！は、今年で 10 周年を迎えたゲームです。フロントエンドは Vue.js で開発されていて、現在もコード量が増加しています。 今回は、そんな駅メモ！のフロントエンドに vue-tsc を導入して、GitHub Actions で型チェックを実行し、reviewdog に Pull Request で指摘してもらえる状態を作った話を紹介します。 駅メモ！のフロントエンドの状態 はじめに駅メモ！のフロントエンドの簡単な概要を紹介します。 フレームワークは Angular → Vue 2 → Vue 3 パッケージマネージャーは Yarn Linter や Formatter の GitHub Actions は導入済み JavaScript と TypeScript が混在 JS ファイルでも

はじめに こんにちは。駅メモ！開発チームの横井です。 今回はプロダクトの機能開発をしながら改善に取り組むためのチーム構成について話します。 背景 駅メモ！はありがたいことに今年で 10 周年を迎えました。 10 年もの間、機能追加や改修をしていくことでアプリケーションは使いやすく進化してきましたが、それとともにコードベースも肥大化し、保守性の面での課題が浮き彫りになっていました。 そんな中、エンジニアとしてその課題を認識しながらも、開発チーム全体として改善に割くリソースが不足していることに気づいたのが 2022 年頃。 ビジネス側の協力を得て、機能開発と並行して改善を進められるチーム体制を構築したのが 2023 年頃です。 2024 年に入って、さらにチームの実情に沿った形へと体制が変更して今に至るのですが、そんなチーム構成の変遷と、気づいたことを説明していきます。 独立した改善チーム（2

こんにちは。駅メモエンジニアの id:dorapon2000 です。 約半年前の 6 月 1 日にステーションメモリーズ！（駅メモ！）10 周年を記念してタイムラインと地図の切替機能をリリースしました。大変好評を頂いておりとても嬉しいです。 今回は、その機能の中で毎秒最寄り駅を計算するロジックをどのように実現しているのかについてお話します。様々なスペックの端末で遊ばれているため、可能な限りリソースを節約するような工夫をしました。堅い言い方をすれば、過去の計算情報を使った最近傍探索アルゴリズムを実装しました。 記事中のサンプルコードは TypeScript で記述しています。 2024/11/22 追記： はてなブックマークでのご指摘ありがとうございます。 ご指摘をいただいた「事前計算の時間計算量」と「基準点と現在地の距離が近すぎるとき」の説明部分を修正しております。 誤：事前計算を O(N

はじめに モバイルファクトリーは、21 年度から完全リモートワークに移行しています。 リモートワークではコミュニケーション不足に陥りがちです。まだ会社に慣れていない、社員の顔と名前が一致していないような状態にある新卒のエンジニア達はなおさら、コミュニケーションに困難を感じるのではないかと想像されます。 リモートワーク下でも、新卒エンジニア同士 / 新卒エンジニアと先輩社員 がコミュニケーションしやすい状況を作りたい！ というわけで、今年の新卒技術研修を担当しました(id:kaidan388)が、コミュニケーションしやすい状況作りのために新人技術研修で行った工夫について説明します。 端的にいえば、コミュニケーションするきっかけを増やすことに注力して、内容を組みました。 具体的には、新人技術研修に以下の工夫を盛り込んでいます。 朝会と夕会で雑談タイムを作り、互いのことを話す 幅広い社員を募った

駅奪取チームエンジニアの id:kimkim0106 です。 「レポートを書くまでが YAPC」とのことなので、自分も書こうと思います。 YAPC::Hakodate の概要 2024/10/5（土）に、北海道函館市の公立はこだて未来大学にて開催されました。 YAPC は Yet Another Perl Conference の略で、Perl を軸とした IT に関わる全ての人のためのカンファレンスです 前夜祭 会場入口の看板 前夜祭会場のスクリーン 前夜祭のトークテーマも気になるものが多かったので、前夜祭から行きたいと思っていました。 特に印象に残ったトークをいくつか紹介します。 アンカンファレンス いくつかトピックがあった中で、生成 AI に関するトピックがありました。 GitHub Copilot などの生成 AI を使っている人が多く、これからは生成 AI の時代なんだと改めて感

はじめに vim に最近目覚めた。そこから NeoVim、LunarVim を使うようになった流れについて、自分が思う好きなポイントと絡めてまとめる。 書かないこと エディタ戦争 VSCode も、vim も、emacs も、みんな違ってみんないい あくまでも vim のココスキをまとめるので比較はしない どうして vim か VSCode を今まで使っていて、remote の接続が悪かったり重かったりしていたのでこれを機に、気になっていた vim に乗り換えてみた vim を選んだ理由は、 慣れるとコーディングスピードがすごいらしい 脳とコーディングを直結したい 軽そう 使ってる人が多い つまりググったときの情報が多い という辺り。 どうして NeoVim か vim について色々調べていると、どうやら新しい NeoVim というのがあるらしい*1事に気づいたのでそっちを使うことにした。

こんにちは、駅奪取エンジニアの id:kimkim0106（旧: id:kaoru_k_0106）です。 今回の記事は、駅奪取でテーブルにレコードが「無ければ INSERT、あれば UPDATE」（いわゆる UPSERT）をする箇所で Duplicate entry が出ていたのを修正したり、未然に防ぐ実装をしたときに得られた知見です。 このような処理はよく使われますが、うまく実装しないとエラーが発生したりパフォーマンスの問題が生じたりします。 この記事では、自分が試した方法のメリット・デメリットについて説明します。 目次 前提条件 Duplicate entry とは 1. Duplicate entry が出たらトランザクション自体をやり直す 2. INSERT ... ON DUPLICATE KEY UPDATE 3. とりあえず INSERT して Duplicate entry

駅奪取チームでエンジニアをしている id:kebhr です。 今回は、駅奪取チームにおけるプロジェクト管理のツールとして、従来利用していたガントチャートに加え、新たにバッファ傾向グラフを導入してみた経験について書きます。 バッファ傾向グラフとは このプロジェクトでは、プロジェクト管理手法として CCPM (Critical Chain Project Management) を採用しました。 CCPM では、個別のタスクにはバッファを設けず、すべてのバッファをプロジェクトの終盤に設けます。このバッファをプロジェクトバッファと呼びます。 必然的に、プロジェクトが進行するにつれて、プロジェクトバッファを消費していきます。 プロジェクトバッファの消費量を可視化するツールがバッファ傾向グラフです。 下図のような、横軸に日付、縦軸にバッファ消費率を取るグラフです。 バッファ傾向グラフ バッファ消費率

言葉の定義 モバファクの 1on1 の目的 1on1 で自分が大事にしていること 1on1 はメンティーの時間である 1on1 はメンターの時間でもある 1on1 初回 今使っている 1on1 のフォーマット 体調 半期目標の進捗振り返り ネクストアクションの振り返り うまくいかなかったこと・もっとよくなりそうなところ・うまくいったこと・その他に話したいこと ネクストアクション 1on1 の中でのやりとり お休みの取り方がわからない 最近見積もりの精度が高くなっている 朝会の議事録をとるようにしたい 最近チームの動きがぎこちないと感じている 1on1 定期的な振り返り まとめ こんにちは。駅メモエンジニアの id:dorapon2000 です。 今回は自分自身がメンター側として実施している 1on1 について、どのように実施しているのかご紹介しようと思います。 1on1 のやり方はメンター

駅メモ！チームエンジニアの id:yumlonne です。 この記事では Redis の sorted sets で実装していたランキング処理を MySQL に移行した仕組みを紹介します。 背景 駅メモ！には複数のランキングがあり、Redis の sorted sets を使うことでパフォーマンスの高いランキング処理を実現していました。 中にはリリースからの全期間に渡るデータを利用するランキングもあり、Redis のメモリ使用率は日に日に増えていく一方でした。 何度か Redis をスケールアップしてメモリを増やすことで対応していましたが、根本的に対応しなければ今後も Redis をスケールアップもしくはスケールアウトさせ続けるしか選択肢がなく、コストが増え続けてしまう状況でした。 調査したところ、一部のランキングがメモリ使用率の 2/3 程度を占めていることが判明しました。 そこで、その

こんにちは！ブロックチェーンチームでエンジニアをしている 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

こんにちは！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: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 と呼びます)

こんにちは、エンジニアの id:mp0liiu です。 自分が所属しているチームでは現在もPerl製のプロダクトを運用しており、VSCode で Perl のコードを書いたり触ったりする機会が多いです。 Perl は開発環境が貧弱で他の言語と比べるとあまり開発体験はよくありませんが、それでも少しずつ便利な拡張機能が充実していってるので、この記事では自分が利用している便利な VSCode の Perl 向け拡張機能を紹介します。 Perl Navigator marketplace.visualstudio.com 今年話題になった Languager Server を利用した拡張機能です。 他にも Perl の Languager Server を利用した拡張機能はいくつか種類がありますが、以前から存在する拡張機能と比べると自動補完やコードジャンプがちゃんとできたり、Perl::Criti

駅メモ！チームエンジニアの 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ブランチが

駅メモ！チームエンジニアの 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:Eadaeda です。シバンは #!/usr/bin/envを使う派です。 皆さんはシェルスクリプト書いてますか？ 環境構築、開発、テスト、ビルド、デプロイなどなど、一連の作業を自動化するための手段として時々出番があるんじゃないでしょうか。 ところでそのシェルスクリプト、テスト書いてますか？ シェルスクリプトのテスト 「シェルスクリプトのテスト〜？」って感じですよね。殆どの場合、一度書いてしまえばあんまり壊れることはないし別に…って感じですよね。わかります。実際開発環境のためにdocker compose upするだけのスクリプトなら雑でもいいですよね。 でも、重要な役割をもつスクリプトならどうでしょう。例えばアプリケーションのエントリーポイントや、リリースビルド・デプロイのためのスクリプトなどが思いつきます。 こういうのはテストである程度保証され

BC チームでエンジニアをしている id:d-kimuson です 11月にリリースされた TypeScript 4.9 から satisfies operator が追加されました。satisfies operator が追加されたことで 「React Router でのナビゲーションを型安全にする」がやりやすくなったのでやってみました この記事で紹介するコードは TS Playground で試すことができます React Router v6.4 からオブジェクト形式でルーティングをかけるようになり、ルーティング宣言から型を拾いやすくなった React Router v6.4 から createXXXRouter のAPIが追加され、コンポーネントではなく、プレーンオブジェクトでルーティングを書けるようになりました import { createBrowserRouter } from

こんにちは。ブロックチェーンチームのソフトウェアエンジニアの id:odan3240 です。 tech.mobilefactory.jp 上記の記事で紹介した通りユニマ/ガレージのインフラは Terraform で管理されています。 この記事では Terraform を管理するリポジトリのディレクトリ構成とその思想について紹介します。 前提 Terraform を管理するリポジトリは2020年の1月頃に開発されたものです。 当時の最新版の Terraform のバージョンは 0.12 でした。 当時の Terraform のバージョンでのディレクトリ構成の紹介であり、現在の最新版のベストプラクティスに沿わない可能性があります。 ディレクトリ構成 リポジトリルートのディレクトリ構造は次の通りです。以降で紹介するディレクトリ構造は説明のために一部簡略化しています。 $ tree -L 1 .

駅奪取チームエンジニアの id:dorapon2000 です。 弊社の今年の技術研修についての記事が何点か投稿されています。 tech.mobilefactory.jp tech.mobilefactory.jp プロダクトで利用されているプログラミング言語、ライブラリ、RDBMSなどの技術研修を行っても、プロダクト開発を円滑に行うことは難しいです。プロダクトの仕様の理解が浅く、各機能のコードがどこにあるか把握できていないことが一因です。他にも、口頭伝承になりがちで毎年のコストになっていたことや、新機能開発に取り組んでも、プロダクト理解が浅ければ出るべき提案も出てこない問題もあります。 私達のチームでは、こういった問題を解決するため、チーム横断の技術研修とは別に「プロダクト技術研修」を4年前から実施しています。本記事では、そのプロダクト技術研修の紹介と実施にあたり大切にしていることを書きた

こんにちは、エンジニアの id:mp0liiu です。 少し前の話になりますが、5/28にPerlの最新安定バージョンである5.36がリリースされたので、コミュニティ周りの動向も含めて気になった点についてまとめていこうと思います。 use v5.36 一番影響がある変更は use VERSION の効果が変わったことです。 use v5.34 以前はバージョンチェック、要求されたバージョンで利用可能なすべての機能(featureバンドル)の有効化、strict の有効化を行っていましたが、 use v5.36 からは warnings も有効化されるようになりました。 use v5.36; my $str; say $str; # Use of uninitialized value $str in say at ... 1行だけで strict, warnings, 最新の機能の有効化が

こんにちはエンジニアのEadaedaです。 皆さんのチームではGitHub Actionsを使っていますか？ブロックチェーンチームではテストやリンター、デプロイといったワークフローをGitHub Actionsで行っています。 今まで、デプロイ以外のワークフローはGitHub-hosted runnerで実行、デプロイはSelf-hosted runnerで実行していましたが、運用していくうちに特定の環境内にあるサーバーで実行されるように仕組みを見直す必要がでてきました。このため全てのワークフローをSelf-hosted runnerに移行する対応を行いました。この記事では移行の際に見つけた便利なものや困ったことを紹介します。 Self-hosted runner GitHub Actionsでは、基本的にGitHubが用意したVMでワークフローが実行されます。このVMをGitHub-ho

こんにちは。エンジニアのid:kfly8です。 今月から、NestJSとethers.jsのスポンサーをはじめました🎉 この記事ではOSSのスポンサーをするにあたり考えたことを書きます。 モバファクは、NestJSとethers.jsの2つのOSSのスポンサーになりました NestJSとethers.jsを選んだ理由 多くのOSSに支えられてプロダクトの開発ができているので、気持ちとしては全てのOSSに貢献したいところですが、そういうわけにはいかないので、次のような基準で絞り込みをしました。 プロダクトで重要かつ頻繁に利用している メンテナーが少ないこと スポンサーメニューが明確で、経理処理や稟議が円滑にしやすいこと 1番目の基準は素直だと思います。ここでは2番目、3番目について補足します。 メンテナーが少ないOSSにスポンサーをした NestJSもethers.jsもどちらも優れたOS

こんにちは。エンジニアのid:kfly8です。 先日、技術研修のインタビュー記事を公開し、手を動かしつつ、コミュニケーションをよく取る技術研修といった主旨の内容でした。 tech.mobilefactory.jp こちらのインタビューでは具体的な研修内容は触れていませんでした。今回は、駅メモ！や駅奪取といった位置ゲームや着メロの月額コンテンツサイトなどで利用しているPerlの技術研修について紹介します。ブロックチェーン事業ではフロントエンド、バックエンドの両サイドで、TypeScriptを利用しているのですが、そちらの技術研修の話は追い追いできればと思います。 tech.mobilefactory.jp 技術研修を受ける人は、どの言語でも良いのである程度プログラミング言語に慣れてることを想定しています。そのため、学ぶ意味、特徴は何か、良教材は何か、罠は何か、などポイントを掻いつまむように技

こんにちは、ブロックチェーンチームの id:d-kimsuon です Vue2 では TypeScript がサポートされており、公式の TypeScript のサポートのドキュメント に従うことで TypeScript で書いていくことができます しかし、素直に書いていくと any 型になってしまったり、実際とは異なる型付けになってしまうポイントがあります この記事では TypeScript で Vue2 (Option API) を書くときに型を厳格にしやすい書き方等を紹介します 省略可能な props には明示的に PropType<型 | undefined> する 型安全な例 型安全でない例 props の型でリテラルに絞っている時、 default には as const をつける 型安全な例 型安全でない例 data の型を as で上書きせず、型注釈を書く 型安全な例 型安