こんにちは。
マネーフォワードのわり算グループでインターンをしている小野直人です。

今回の記事ではタイトルにもある通り、rakeコマンドを打つことでRailsのActiveRecordのバリデーションを自動で書いてくれるgemについて紹介したいと思います。
https://github.com/ono-max/spicy_validation

gemを作った背景

僕の頂いたタスクで「与えられた仕様に沿ってモデルファイル・テーブル定義をする（マイグレーションファイルを書く）」というものがありました。この時に作るモデルファイルやマイグレーションファイルの量が多く、以下の課題感を持ちました。

• 内向きな課題：単純作業なので途中で飽きてしまいそう
• 外向きな課題：ケアレスミスを指摘する手間をレビュアーにかけたくない・効率的にミスなくやりたい

そこでこれらの解決策として自動化するgemを作ってみようと考えました。どこを自動化すべきか考えるために自分が普段モデルファイル・テーブル定義をする上でどのようなコマンドを打ちどのようにコードを書くのか考えてみることにしました。

こんにちは。
マネーフォワードクラウド確定申告アプリiOSエンジニアの佐藤です。
本稿ではマネーフォワードクラウド確定申告に実装したiOSアプリ内課金の設計指針について紹介します。

はじめに

皆さん、iOSアプリ内課金という単語はご存知でしょうか。
iOSアプリ内課金とは、ユーザーが利用するアプリ内または App Store から一連の購入処理を踏むことで、iOSアプリに様々な追加コンテンツやサービスを提供できる機能です。

iOSアプリ内課金の種類

主にアプリ内課金には4つのタイプが存在します。Apple 公式サイトではこちらで説明されています。
弊社確定申告アプリにおける課金タイプは、追加コンテンツを解約するまで利用できる「自動更新サブスクリプション」形式を採用しました。
そのため本稿は自動更新サブスクリプションに少しフォーカスを当てた紹介となります。

こんにちは。
マネーフォワードのVPoE、渋谷（ryoff）です。

多くの優秀なエンジニアの方々に入社いただき、プロダクトラインナップも増えてきました。

一方、「GraphQL使ってるプロダクトって他にもありますか？」だったり、「PdMやりたいのでINSPIREDについて語りたいんですけど」、みたいな会話をSlack上でちらほら見るようになってきました。

プロダクトラインナップの増加に伴い、Slack の部屋数も増えており、今では3100を超えています（2021年3月現在）。

実は同じ技術を使っているのに交流がなかったり、実は同じ思いを持っているのに気づけていなかったりするのはもったいないな、と思ったため、その一助になればいいなと思い、社内勉強会カレンダーを作ってみました！
運用開始して半年ほどたち、社内でもかなり浸透してきたので、今回はそのご紹介です。

こんにちは。マネーフォワードのgotoken（@kennygt51）です。

突然ですが、マルチアカウントAWS環境の管理業務をおこなっている皆さん、AWS SSOやってますか？？
当社のAWS環境の改善活動に取り組む中で、AWS SSOの便利さにすっかり虜になってしまいました。
今回の記事では僕が業務で取り組んだ『150超のAWSマルチアカウント環境における「AWS SSO」の設定をTerraform管理に移行した話』について紹介します

AWSアカウントへのアクセスコントロールの歴史

AWS SSOやTerraform管理の話をする前に、当社のAWSアカウントへのアクセスコントロールの歴史を紐解いてみましょう。
　

はじめてのAWS SSO

2020年の初め頃、当社のAWS環境にAWS SSOがはじめて導入されました。それ以前は、踏み台用のAWSアカウントにのみIAMユーザを作成し、アクセスしたいAWSアカウントのIAMロールにスイッチする方式を採用していました。

こんにちは。
マネーフォワードでコーポレートエンジニアリングを担当している 下村 です。

コーポレートエンジニアって？という方は こちら をご参照下さい。
誤解を恐れず言えば、社内環境をITでハックする人 といった職種です。

さて、マネーフォワードではチャットツールとして、Slackを使っているのですが、
地味に困る、「チャンネル名変更」オペレーションについて、 Slackチャンネルを一般権限の方 でも変更できるようにしてみたのでその内容をご紹介します。

そもそもSlackってチャンネル名を自分で変えられないの？

本題に入る前に、「そもそもSlackってチャンネル名を誰でも変えられないの？」って思われた方も結構多いのではないかと思います。(私もそうでした)

こんにちは。
京都開発拠点でGoエンジニアをしています @yoskeoka です。
Goを中心技術として性能改善やプロダクト間を横断するような機能の設計、実装を行うKTAチーム (京都開発本部 テクニカルアーキテクトチーム) 所属です。

突然ですが、皆さんはGoでテストを書いているでしょうか。
我々はテストを書くことが中長期的なスピードアップに繋がると信じて日々テストを書くようにしています。

KTAではGoの実装をする際にClean Architectureの考えに基づいたpackage分けを行っていますが、packageを分けたり、インターフェースを定義したりとしていくと、テストを書くのが難しい部分というのが出てきます。
そんな場合に使えるモック作りテクニックを今回は紹介したいと思います。

Clean Architectureはテストしやすくなると言うが

Clean Architectureを実践するにはDIP: Dependency Inversion Principle (依存性逆転の原則) に従って、ビジネスロジック層はインターフェースに依存するように実装していきます。
そして、インターフェースを通じてデータアクセス層などと繋ぐことで、お互いを疎結合にしておくことができるという実装方法です。
疎結合なので、例えばデータアクセス層でパフォーマンス改善、冪等性の担保などといった修正を加えても、ビジネスロジック層のコード修正が生まれない、分割されているので個別にテスト可能といったメリットがあり、実装するコードが大規模になる程、メリットが活きてきます。

こんにちは。
マネーフォワード CTOの中出（なかで）です。

CTOの私が、普段「なにを感じて、どんなことを考えているか」について、四半期に一回社内へ共有している内容を一部編集し、エンジニアブログに公開したいと思います。

前回はこちら：マネーフォワードCTOが考えていること（2020年9月）

目次

• エンジニア採用と働きやすい環境づくりについて
• スマートデバイス推進グループの発足と技術顧問の就任について
• Golangもっと進めます

エンジニア採用と働きやすい環境づくりについて

１．グローバルエンジニア

21年入社の新卒エンジニアは外国籍メンバーが大幅に増え、ベトナム、インド、台湾、中国、マレーシア、インドネシア、タイなど、多様な国と地域からの採用が実現しています。海外新卒採用は日本語能力を必ずしも重視しない方針にシフトし始めているため、優秀なエンジニアを採用できるチャンスが大きく広がっています。これまではベトナム出身者が大部分でしたが、今後はインドを中心に他の国の出身者の割合も拡大することを想定しています。

これはなに？

今日はぼくがマネーフォワードという会社に入社しておよそ1年たち、今年から始まる新たな挑戦の紹介と挑戦によるキャリアパスの話し、そして今後の展望を語らせてもらおうと思いました。

新しい挑戦がほんの少し他人とは少し違う、ユニークなキャリア形成に繋がるということで個人としてもマネーフォワードという会社としてもチャレンジングなことをしようとしている足跡を残すことに意味があると考えたのでこの記事を書こうと考えました。

で、新しいチャレンジってなんなの？

ぼく、ことluccafort は 2021年3月からTech Enhancement Group(通称TEG)の技術広報を担当することになりました！🎉🎉🎉

TEG is なに？？？

TEG設立の経緯は社内ドキュメントにしっかり残っていました、こういうことがSlackで流れてしまうのではなく、ドキュメントとしてしっかり残っているのはマネーフォワードという組織のよいところですね！

ある日、神は言った。

神　「 全体的にエンジニアがもっと力出す上でのサポートに全然リソース割けてなさすぎじゃ？ 」

(つд⊂)ｺﾞｼｺﾞｼ

(；ﾟдﾟ)‥‥ﾏｼﾞ???

個人名が入っていたところを神にリネームした以外は原文のままです。

こんにちは、最近ブルグミュラー15曲目（原曲No.20）が終わった内波です。
「じゃあ小学校3年生くらいだね」と言われて少しだけしょんぼりした瞬間もありましたが楽しくやっています。

このブログではだいぶご無沙汰していましたが、最近、我々の会社の立場がかなり稀有なもので、そこで得られている情報をもっと多くの人に広く共有していくべきだな、と感じるようになったので、久々に筆をとりました。
何がそんなに珍しい立場かというと、他社が提供するAPI、その中でも特に、単純な「機能」としてのAPIではない、ユーザーの認可を受けてその代理人として利用するAPIを、これほど多く扱っている企業はなかなかないんじゃないかな、というものです。

はじめに

この記事で取り扱うAPI

API（アプリケーション・プログラミング・インターフェース）という単語は非常に広い意味で利用されるものですが、この記事でフォーカスするものを一言で述べると「第三者向けユーザー認可型」のWeb APIになります。

こんにちは。
マネーフォワード クラウドのアカウント基盤のプラットフォームをプロダクトオーナー兼バックエンドエンジニアとして開発しているkamillleです。
普段はRailsやk8s manifest、Terraformなどを書いています。

今回はKubernetesクラスタ上で動かしているSidekiq(※)プロセスに対してヘルスチェックを導入して、より安全にデプロイが行えるようになった話をご紹介しようと思います。

(※) Railsのアプリケーションで非同期処理を行うためのライブラリ

ヘルスチェックで満たしたい要件

今回ヘルスチェックで満たしたかったゴールは下記の2つです。

1. デプロイ時に新しいSidekiq用のPodが起動したが内部でプロセスが立ち上がらなかった場合は既存Podのterminateを行わない（いわゆるゼロダウンタイムデプロイを高いレベルで実現したい）
2. Sidekiqのプロセスは生きているがなんらかの理由でジョブを捌けなくなったら検知して再起動する

　
ゴール実現のためにそれぞれ以下の状態を検知できるようにすることが必要と考えました。

1. Sidekiqが起動し、Redisのキューを捌けるようになった
2. Sidekiqのプロセスは生きているが処理が止まってしまっている

　
これをKubernetesのヘルスチェック（Readiness, Liveness, Startup Probe）に当てはめると下記になると考えました。

• Startup Probe、もしくはReadiness Probe（※）で 1. Sidekiqが起動し、Redisのキューを捌けるようになったを検知する
• Liveness Probeで 2. Sidekiqのプロセスは生きているが処理が止まってしまっているを検知する

（※）Startup ProbeとReadiness Probe、どちらを使うべきかは後述します。