こんにちは。
マネーフォワード福岡拠点でインターンをしています長島です。
普段は『マネーフォワードクラウド経費』のサーバーサイドの開発を担当しています。
最近マネーフォワード社内で、エンジニアの日々の「開発の調子」や「アウトプット量」を可視化してみたいという話がありました。
そこで、ちゃんとしたダッシュボードなどを作る前に、ひとまずデータの中身を覗いてみようという事でちょっとやってみました。
エンジニアの開発の調子をどう測るという話ですが、やはりまず思いつくのはGitのログを見る事かなと。
こんにちは。ハルキです。
4月から中学二年生になりました。
僕はこの春休み、パパが働いているマネーフォワードに職業体験インターンという形でお世話になりました。
プログラミングを始めたきっかけは、Scratchという子供向けのプログラミング学習サービスです。
小学校3年生の時にどハマりし、そこから6年生まで夢中になってやり込みました。
ただ、やはり子供向けなので最低限のことしかできず卒業。
その頃、マネーフォワードの方が開催してくれたバーベキューで酒井さんと出会い、そこでPythonを教わりました。
（酒井さんはビジネスマンなのにプログラミングもできちゃうすごい人なのです！）
そこから、Chatworkで酒井さんとコミュニケーションを取るようになり、プログラミングで悩んだことがあったら酒井さんに報告して、バグがあれば直し方を教わるようになりました。
酒井さんは面白い記事を紹介してくれたり、それまで誰にも相談できなかったことに答えてくれたので、それはすごく嬉しいことでした。
それからしばらくして、マネーフォワードクラウドの渋谷さんから「ハルキくんにぜひインターンにきてほしいです！」と誘っていただき、パパも「よし、じゃあ頑張ってみる？」ということで今回の職業体験がスタートしました。
今回の職業体験インターンで大変だったのは（もちろんお仕事も大変だったのですが）、満員電車での通勤です。僕は普段全く電車に乗らないので、初日は満員電車と路線を覚えるのがすごく大変でした。
マネーフォワード福岡拠点の責任者をしております 黒田 です。
普段はRailsエンジニアとして マネーフォワードクラウド経費 の開発を担当しています。
普段Railsを使って開発されている方であれば、N+1問題に悩まされた経験は大抵の方がおありではないでしょうか。
N+1なクエリの発見には bullet を使うと良いですね。
bulletを使うとN+1なクエリを発見してくれ、さらに、具体的にここにincludesを追加しなさいと指摘までしてくれるので大変助かります。
しかし、先日bulletに言われるがままにincludesを付けてみたところ、N+1は解消したものの、スロークエリに見舞われることとなったので、includes,preload, eager_loadについて改めて調べてまとめてみることにしました。
（ソース調査したRailsのバージョンは 6.0.0.beta3 です。）
includesの挙動について、「preloadとeager_loadをよろしく使い分けしてくれるもの」と認識しているRailsエンジニアは結構いるのではないでしょうか？
そういったエンジニアの方の中には、先日の私のようにN+1問題の対策で深く考えずに「includesつけとけばOKでしょ。ほらbulletのN+1のアラート止まったし。」という方もいらっしゃるのではと思っています。「とりあえずincludes」で、データが少ないうちは問題にならなくてもデータが増えてきた時に問題が顕在化する事がよくあります。
みなさん、こんにちは！
マネーフォワードは、新たに京都開発拠点を開設しました。
〒604-8004 京都府京都市中京区三条通河原町東入中島町78 明治屋京都ビル4F
Google Mapはこちら
京都駅からバスに乗車しての、マネーフォワードへの道のりをご紹介させていただきます。
※最寄りのバス停は河原町三条です！
※Google Mapでは異なる案内をされることがあります。
電車でお越しの方はこちら
マネーフォワードへの道（電車で行く 京都開発拠点編）
京都駅中央口（外からの景観）
RubyKaigi 2019 参加者のみなさま、こんにちは。
Ruby Kaigi Local Organizer の伊藤です。
マネーフォワードは RubyKaigi 2019 を Ruby Sponsor で協賛します！
さて、今年のRubyKaigiの会場は福岡ですが、ご飯を食べる場所は決まりましたか？
マネーフォワードは1年ほど前から福岡に開発拠点を立ち上げ、RubyKaigi 2019に備えてきました。
そんな福岡を知り尽くしたメンバーが、おすすめのお店を紹介します。
だいたい、天神大名、中洲川端、今泉あたりのお店です。
エンジニアの澤田です。
この連載では、社内のRuby (on Rails)コードで気になった箇所の問題点やそこから発展して関連事項を議論しています。
前回投稿の マネーフォワード社内PRに見られるRubyの書き方について (3) では文字列の生成と検証を考察しました。
記事に言及してもらったり、コメントをもらったりして、励みになっています。
今回は真理値について考察します。
【バックナンバー】
題材とするコードは、社内のGitHubプルリクエストで実際に見かけたコードから問題点に関係する部分を抽出し、抽象化したもので、見かけたものそのままではありません。
今回は真理値の周辺を考察します。プログラミングにおいて真理値が何のためにあるかといえば、時に論理演算を施され、最終的に制御構造の条件部やメソッドに渡される引数やメソッド内のフラグなどとなって、場合分けに使われることがほとんどだと思います。従って、今回の真理値の考察には場合分けについての議論が多く登場します。
みなさん、こんにちは！
マネーフォワードは、新たに京都開発拠点を開設しました。
〒604-8004 京都府京都市中京区三条通河原町東入中島町78 明治屋京都ビル4F
Google Mapはこちら
それでは、三条京阪駅からのマネーフォワードへの道のりをご紹介させていただきます。
※出発地点によっては『京都市役所前駅』からの案内が表示されますが、最寄り駅の『三条京阪駅』からのルートをご紹介させていただきます。
バスでお越しの方はこちら
マネーフォワードへの道（バスで行く 京都開発拠点編）
地下鉄の改札口を出て、右を向いてまっすぐお進みください。
(改札を出て左側にセブンイレブンがありますが、そちらとは反対側です。)
エンジニアの澤田です。
この連載では、マネーフォワード社内のRuby (on Rails)コードで気になった箇所の問題点やそこから発展して関連事項を議論しています。
前回の『マネーフォワード社内PRに見られるRubyの書き方について(2)』ではハッシュの生成を扱いました。
概念的な話で始まり、また長かったので、読んだ方は少し疲れたかも知れません。
今回は内容の特性により、用例を並べて手短に問題点を指摘して、文字列(String)の生成や検証を考察します。
題材とするコードは、マネーフォワード社内のGitHubプルリクエストで実際に見かけたコードから問題点に関係する部分を抽出し、抽象化したもので、見かけたものそのままではありません。
社内のコードに限らず、文字列に関わるRubyコードで問題のあるものの多くは、必要もないのに正規表現を使ってやろうとしていたり、特定のメソッドに固執してそれを乱用しているということに集約されると思います。正規表現の乱用の例とメソッド別の不的確な用例を挙げていきます。
エンジニアの澤田です。
この連載では、社内のRuby (on Rails)コードで気になった箇所の問題点やそこから発展して関連事項を議論しています。
1回目の 社内PRに見られるRubyの書き方について (1) では配列の生成を扱いましたが、今回はハッシュ(Hash)の生成を考察します。
題材とするコードは、社内のGitHubプルリクエストで実際に見かけたコードから問題点に関係する部分を抽出し、抽象化したもので、見かけたものそのままではありません。
また、本稿で述べるオブジェクトの分類や用法は筆者独自の見解であることをご了承下さい。
ハッシュは配列に似ている面があります。配列では「要素」、ハッシュでは「値」と呼ばれる、(実用上)任意の個数のオブジェクトの集合を蓄えるという点です。一方で、ハッシュは配列よりも複雑な情報を持ち、多様な使い方があるため、その生成を考えるに当たっては、配列ではあまり意識しなかった用法の違いを考慮することが有効です。以下で、オブジェクトの情報の複雑さという観点からオブジェクトを分類し、配列やハッシュの主な用法を考えます。
配列は要素の集合、ハッシュは値の集合を持っていますが、ハッシュは他に「キー」と呼ばれるオブジェクトの集合も持っています。1つのハッシュのキーの全体は一般には不均質な集まりであり、キーは個別に特徴付けられるため、キーの情報はハッシュが1つずつ保持しておかなければならない情報です。本稿では、ある配列の要素の全体やあるハッシュの値の全体に相当する情報を「主系列」、あるハッシュのキーの全体に相当する情報を「副系列」と呼ぶことにします。
この記事は Money Forward Advent Calendar 2018 15日目の記事です。
こんにちは、マネーフォワードでマネーフォワードクラウドの開発をしている @kamille です。
今年の10月に新卒で入社して、今はマネーフォワードクラウドの全体的な課題を解決する横断チームにてRailsエンジニアをしています。
今日はRailsの accepts_nested_attributes_for メソッドについてお話したいと思います。
突然ですが皆さん accepts_nested_attributes_for は好きですか？僕は複数リリースの同時保存・更新が超お手軽にできて素敵なコンセプトだなと思います。
でもこのメソッドはあまり評判が良くなく、特にRails生みの親のDHHがaccepts_nested_attributes_forを消したいと言っていたり、代わりとなる公式なformオブジェクトのプロジェクトが立ち上がったり(残念ながら途中でなくなってしまったようです 😥 )している等、あまりいいメソッドと思われていないようです。
社内でも accepts_nested_attributes_for は今後は使わないようにして、既存のコードもリプレイスしていく活動が始まっているので accepts_nested_attributes_for を使わずに、 FormObject を使って複数リリースの同時保存を行うコードを書いてみました。