初めまして！
マネーフォワードでプロダクトマネージャーをやっております、後藤と申します。
突然ですが、今月10/27(火)開催の『プロダクトマネージャーカンファレンス 2020』(以下、pmconf 2020)に参加します！
『pmconf 2020』は、年次で開かれているプロダクトマネージャーのためのカンファレンスです！
著名なプロダクトマネージャーの方々の体験談や考え方などを講演形式で伺えるイベントで、今年は昨今の世情も踏まえ、「見えない未来をリードするプロダクトマネジメント」というテーマで開かれるみたいです。
pmconf 2020のチケット申し込み開始当日、社内PMチャットでこんなチャットが。
こんにちは。
マネーフォワードでコーポレートエンジニアリングを担当している 下村 です。
コーポレートエンジニアリングって？という方は こちら をご参照下さい。
誤解を恐れず言えば、社内ITをハックする人 といった職種です。
今回は、弊部で実施している SaaSの障害検知方法 について共有させていただきます。
我々、コーポレートエンジニアリングのミッションの一つに 社員にIT環境を安定して提供し続ける というものがあります。
ただ、障害によりSaaS製品がサービス停止になってしまうということもあります。
外部取引先との連携用に使っているSaaSなどもあるので、サービス停止してしまう＝売上に影響してしまうような事態も発生してしまうこともあります。
(例：商談でWeb会議を使用しようとしていたがサービス停止により商談の機会を損失する、等)
サービス停止自体は我々では防ぎようがないので、せめてサービス停止時は 障害検知を迅速に行い、代替策の検討/提供の開始 など、被害を最小限に抑える行動が必要になります。
あまりコストもかけたくなかったので、
Twitterのつぶやき をトリガーに障害検知しています。
具体的には下記のようにしています。
こんにちは。
Railsエンジニアのkamillleです。
マネーフォワードのアプリケーションはユーザーの権限やプラン・リクエスト時間等によって異なる振る舞いをするものが多く、そういった機能のテストではparameterized testingを利用することが多いです。マネーフォワードのRailsアプリケーションではテスティングフレームワークとしてRSpecが採用されることが多く、RSpecにおいてどのようにparameterized testingを行っているか紹介したいと思います。
RSpecはparameterized testingをサポートしていないので何かしらの拡張を行う必要があります。この拡張としてrspec-parameterizedというgemがあり、このgemが選ばれているケースが多いように思います。rspec-parameterizedは同じテストロジックに対し複数の入力値や結果を指定できるインターフェースを提供してくれるとても便利なgemです。（rspec-parameterizedの使い方はGoogle先生に聞いていただければと思います🙏）
マネーフォワードでもrspec-parameterizedには長年お世話になっていますが、使っていく間でrspec-parameterizedのデメリットが目立つケースが出てきました。
rspec-parameterizedはwhereに渡すブロックをトランザクション外で評価するため、例えばtravel_toで時間を固定していてもTime.currentが現在時刻として評価されたり、ブロック内でDB操作を行っている場合はDB操作がRSpecのuse_transactional_fixturesのトランザクション外で評価されるため、あるcontextで作ったデータが別のcontextでも存在したままになる、というデメリットがあります。
ちょっと例を書いてみます。
こんにちは。
マネーフォワード CTOの中出（なかで）です。
CTOの私が、普段「なにを感じて、どんなことを考えているか」について、四半期に一回社内へ共有している内容を一部編集し、エンジニアブログに公開したいと思います。
前回はこちら：マネーフォワードCTOが考えていること（2020年6月）
マネーフォワードは創業期からこれまで、Railsに集中する形で技術のポートフォリオを構成してきました。しかし私たちが中長期的に価値あるサービスを社会に提供し続けるために、技術戦略として、他の技術の割合を意識的に高めていく必要があると感じています。
これまでは、統一した技術で開発することのメリットが勝っていました。しかし多くのプロダクトがグロースしたため適材適所な技術選定を行う重要性が増しており、マイクロサービスアーキテクチャへの移行を行うことで、技術選定が柔軟に行えるようになりました。そしてエンジニア組織が拡大し、かつ世の中の技術がどんどん進化していく中で、中長期的にどんな技術が生き残るかを予測することは難しく、一つの技術に集中することのリスクが大きくなってきています。
まだまだRailsは人気がありますし、今後も多くのWeb系企業で広く使われ続けると考えていますが、以前と比べると、他の技術の選択肢が選ばれるケースが増えてきています。
こんにちは。
マネーフォワードの新卒Railsエンジニア、きなこ と申します。
マネーフォワードX という組織で、日々プロダクトの開発に勤しんでおります😊
突然ですが皆さんは JWT という技術をご存知でしょうか？
私は趣味でCTFというセキュリティコンテストに出場するのですが、最近ホットだと感じるのがJWTに関連する攻撃です。
今年の1月に初めてJWTを題材にした問題に遭遇し、その後JWTの出題頻度が強まっていると感じ、社内に向けてJWTにまつわる攻撃を通して学ぶための記事を書いたところ、たくさんの反応をいただきました。
今回の記事はその内容を社外向けにアレンジし、ハンズオンを通して実際にJWTを改竄し、受け取るAPIを攻撃することでJWT自体を学べるようにしたものです。
本記事はJWTに興味があるWeb開発者を想定していますが、そうでない方も楽しんでいただけるようにハンズオンを用意したので是非ご覧ください🙇♂️
JWTはRFC7519で定義されています。
しかし今回はjwt.ioを提供しているAuth0によるJWTの定義が分かりやすいため、こちらを用いて説明します。
こんにちは、Androidエンジニアのsyarihuです。
マネーフォワードの有志の社員が集まって立ち上げた「まねふぉ執筆部」では、技術書典7、技術書典 応援祭で「Money Forward TechBook」を頒布してきました。
そして2020年9月に開催される技術書典9では、まねふぉ執筆部としては3冊目となる「Money Forward Techbook #3」を出品します。
Forward Techbook #3：まねふぉ執筆部
https://techbookfest.org/product/5886292476821504
技術書典9は、2020年9月に11日間にわたって開催される、技術書典オンラインマーケットと、それを盛り上げるYouTube Liveでのスペシャルオンラインイベントのことです。
たくさんの技術本が販売されており、いろいろな技術に出会うことができる素敵なイベントです。ぜひ一緒に盛り上げていきましょう。
「Money Forward Techbook #3」は、マネーフォワードの有志の社員によって執筆した技術同人誌です。
ドキュメント管理のためにセキュアなポータルサイトを構築した話や、マネーフォワード クラウド会計Plusの各チームメンバーによるスクラム導入話、GoとAmazon SQSを用いた非同期処理の入門、Fat Modelへの実践的な対応方法、FactoryBotの詳しい解説などマネーフォワードを支える技術が盛りだくさんの内容となっています。
Hi, I’m Son (ソン) at the CTO office.
One of the projects that I am currently involved in is called Fadil - A Web app for visualizing engineering performance. In the following, I want to explain more about the motivation behind this project, what we are doing, and what’s future of this project.
As Money Forward is growing, there are around ~600 repositories handled by hundreds of engineers, which leads to difficulty in understanding the current performance of engineering in general. We already tried other engineering intelligent tools to track commit history , PR related metrics… However, every company has its own metric to know, these tools just don’t meet our requirement. Each business is unique and would require a certain level of customization. Therefore we decided to build our own engineering visualization tool (from scratch).
(Some metrics in our dashboard)
こんにちは。
京都開発本部の櫻(@ysakura_)です。
今回のテーマは、goroutine内のpanic handlingです。
panic handlingを行う事でアプリケーションの予期せぬ終了を防止できます。
今回扱うgoroutine内のpanic handlingを把握する事で、予期せずAPIサーバーが終了する事や、レスポンスを返さない事を防止できます。
panicのおさらいです。
panicは、コールされるとプログラムが終了するビルトイン関数の事です。
panic("hoge")といった様に、ビルトイン関数であるpanicを呼ぶと使えます。
recoverというビルトイン関数を呼ぶ事で、panicによるプログラムの終了を止める事も出来ます。
Goの仕様によると、以下の様に書かれています。
こんにちは。
マネーフォワードでVPoEをやらせていただいている渋谷といいます。
マネーフォワードでは2020年の新卒エンジニアの入社に合わせてマネジメントメンター制度を導入しました。
上長やメンターとの1on1とは別に、CTO/CISO/VPoEsといった面々が新卒エンジニアの方々と月次で1on1を実施しています。
コロナ禍でのリモート勤務でもスムーズに就業開始できるようにサポートする意味もありましたが、雑談からキャリア相談や悩み相談まで、様々な話をさせてもらっています。
その中で、『そういえばこの話題、他の人にも伝えたなー』と思うような、共通で新卒エンジニアに伝えている事があり、『自分が1on1担当じゃない新卒にもどうやったら伝わるかな』と思ったときに、『いっそ社外向けに書いちゃえば、どうせ社内の人も読んでくれるんじゃ』という めんどくさがり 効率的なやり方を思いついたので書いてみてます。
多くの人が気持ちよく働くために、制度を守ることはすごく大事です。
一方で、それと同じぐらい「制度が適切か」を考える習慣も大事だな、と思っています。
※ ここでは 制度 という言葉を使いましたが、 運用 や ルール なども同様に思っています。
マネーフォワードはおかげさまでエンジニアが200人を超える規模にまで拡大しました。
一方で、創業してまだ8年のベンチャー企業でもあります。
ほんの少し前までは、エンジニアの数も桁一つ少ない状況でした。
こんにちは。
マネーフォワードでインフラエンジニアとして働いているkappy（@kappyhappy）です。
今回は、Amazon EKSへのデプロイを効率化するために導入したGitHub Appsのdeploy-botを紹介します。
deploy-bot導入の経緯の説明の前に、デプロイのために使用しているコンポーネントとその用途を説明します。
2020年7月現在、弊社ではいくつかの本番サービスをAmazon EKS上で稼働させています。また我々は、複数サービスをEKSクラスタで稼働させる為に、いくつかの理由から1つのクラスタ上に複数のサービスを同居させるマルチテナント構成を採用しました。マルチテナント構成におけるマニフェスト管理の運用として、マニフェストファイルを単一のGitHubリポジトリに集約し、サービス単位でディレクトリを作成しています。