こんにちは、エンジニアの越川です。今回は、(Merge|Pull) Requestを育てる方法について考えてみました。 作業開始 目的を明確に 機能単位で ブランチを作ることを心がけます。 git checkout -b topic-name 普段の作業 なるべく小さな単位で作業する事が大事です。commit前に、こまめに git status することや、細かいcommitをするためには、 git add -p が大事です。 意味のある単位でgit-addしてインデックスへ追加。git diff --cachedでこまめに確認、いい感じの単位になったら、git commit -vしていまコミットする単位を確認し、コミットという流れを意識します。 (Merge|Pull) Requestを出す なるべく早めに出す。なんなら何もせずに出すが大事です。 何もせずに出すときには、以下のように、-

こんにちはJavaエンジニアの盛田です。 社内で唯一の女子エンジニアなので素敵な女子エンジニアを絶賛募集中です！（唐突） 今回はみなさんご存知?MF Geeks Nightの移転後初開催についてレポートをお届けします！！ マネーフォワードでは毎月ピザを片手にビールを飲みながらLTを聞いたり、エンジニア同士熱く語ったりするMFGeeks Nightというエンジニア勉強会を開催しています。 最近は毎回社外からもゲストを招待していて、今回は過去最高となるゲスト9名をお招きして参加者総勢約２５名！！ 移転後の記念すべき初開催が参加者多数で嬉しい限りです。 と言いながら私は今回２回目の参加です。 旧オフィスでのMF Geeks Night 初参加は移転前の旧オフィスにいた頃だったのですが、10人でいっぱいになってしまう広さでした。 というわけでそこまでgeekじゃない私が参加してThe geekな方

こんにちは、マネーフォワードのデザイナーの金井です。 1年半お世話になったオフィスを離れて、5月11日から新オフィスに移転しました！ 場所は東京都港区の田町エリアなので移転前と同じですが、駅直結の森永プラザビルへの移転です。 （通勤がだいぶラクになります） 今回、移転プロジェクトメンバーにデザイナーとして参加して、コンセプトや内装などに色々と関わることができました。 移転のコンセプトや、デザイナー目線で注力したポイントなどをご紹介させていただきます。 コンセプトは『マネーフォワードらしさが伝わるオフィス』 シンプルでスマートだけどあたたかみがある。 信頼感があり、こだわりあるプロダクトを生み出すと感じさせるオフィス。 ■オフィスエントランス マネーフォワードの雰囲気・空気感、大事にしているマインドのようなものが伝わるようなオフィスにしたかったので、コンセプトに関しては移転をお願いしたオフィ

開発推進本部の越川です。普段はRailsでコードを書いてるRailsエンジニアです。 普段の仕事の中で モチベーション をコントロールすることは非常に大事です。モチベーションをコントロールするうえで、 ふりかえり をすることが重要であることに気づいたので、そのことについて書きます。 評価制度などで振り返り面談などを行うことは多いと思いますが、私のチームでは、それとは別に個人KPTを軸にした振り返りを毎週行っています。 KPT KPTとは、よかったこと(Keep)、うまくいかなかったこと(Problem)、改善するために試すこと(Try)に分けて考える振り返りのフレームワークです。 KPTは適度なサイクルで行うと良いです。私のチームでは1週間を1サイクルとして考えているので、1週間を振り返るタイミングとして週の終わりである金曜日の夕方に1人30分を目安に振り返りを行っています。 まずは、1週

エンジニアの越川です。毎月恒例（？）、4/22(火)夜に開催したマネーフォワードのエンジニアイベント「MF Geeks Night 2015-04」をご紹介します。毎月第三週目あたりに開催しております、エンジニアの交流会です。外部の方もゲストで来ていただき、社内外のエンジニアが普段に何をしているかを共有する場となっております。 株式会社マネーフォワード 越川 最近個人開発で使っている、Faye: Simple pub/sub messaging for the webについての発表。 Faye使って見てる話 at MF Geeks Night 2015.04.21 from Naoto Koshikawa Faye: Simple pub/sub messaging for the web faye-rails faye-redis-ruby クックパッド株式会社 村田さん AWSの機会学

はじめまして、エンジニアの中村です。 実は今年の1月1日にマネーフォワードに入社したばかりの新参者です。 前職ではRubyやJavaでBtoC向けのWebサービスの開発・運用に携わっていました。 マネーフォワードに入社してからは、先日リリースした給与計算ソフト「MFクラウド給与」を担当しました。 そこで今回は、入社してからサービスリリースまでに経験したイケてるTipsを紹介します。 エンジニア向けの業務仕様まとめ もともとお金が絡むサービスの開発経験がなかった私は、「入社後には業務知識の理解に凄く苦労するかもしれない・・・」と漠然とした不安を抱えていました。 ところが、マネーフォワードでは、サービスの仕様・用語集など必要な情報がQiita:Teamに集約されており、早期のキャッチアップが可能でした。 更に今回担当した「MFクラウド給与」については、難しい仕組みや仕様がエンジニアに理解しやす

エンジニアの中出です。 私は元々、C/C++やJava等のコンパイラ型言語をこれまで扱ってきましたが、マネーフォワードに入って、ついにRuby(Ruby on Rails)に触れる機会を頂きました。 Ruby on Railsの学習を始めてまだ2ヶ月弱なのですが、すでに色々な学びがありました。 今回はその中でも言語としてのrubyについて、今更ながら衝撃を受けたことを書きたいと思います。 1. 本当にすべてオブジェクト rubyは紛れもなくオブジェクト指向なプログラミング言語です。 一般的にオブジェクト指向な言語では処理や操作の対象をオブジェクトとして扱おうとし、すべてがオブジェクトとして扱える世界を善しとする文化があります。というよりそれがオブジェクト指向と言えます。 一方、多くのオブジェクト指向な言語においても数値等のデータ型はオブジェクトして扱わない事が多いと思います。 javaであ

エンジニアの渋谷です。 マネーフォワードは3月30日に【給与計算ソフト - MFクラウド給与】という新サービスをローンチさせていただきました。 マネーフォワード、クラウド型給与計算ソフト『MFクラウド給与』(β版)を無料提供開始～法改正や税制改正にも自動対応。企業の給与計算・労務をもっとスマートに～ クラウド給与計算ソフト　マネーフォワード クラウド上で完結する本格的な給与計算サービスとして、リアルタイム給与計算機能や料率自動反映などを備えております。 本サービスの企画自体は、昨年年末に３人でスタートし、年明けから様々な方にお手伝いいただきながら、約３ヶ月の開発期間でローンチしました。 今回は、新サービスをゼロから作り上げるにあたり、エンジニアとしてやって良かった、と思えた事を９つばかり紹介させていただきます。 １：リリース前確認シート 企画がスタートした時に、【ビジョン】【ミッション】と

エンジニアの越川です。 今回は、2/19(木)夜に開催したマネーフォワードのエンジニアイベント「MF Geeks Night 2015-02」をご紹介します。 同時間帯にベストアプリ勉強会＠Sansanも開催していましたが、それはまた別な投稿で紹介！ 今回もゲストをお招きして、ピザをつまみにビールで乾杯。 なぜrailsなのか まず越川から「なぜrailsなのか」の発表を行いました。 なぜRailsなのか from Naoto Koshikawa 規約縛り、 周辺のエコシステム、 webの進化への追従の3つ。 Railsの採用は重要な経営判断である ことを話しました。 プランニングポーカー 二番手は弊社杉本から、「プランニングポーカー」についての話題。 プランニングポーカーのすすめ from sugimoto1022 プランニングポーカーの一番の効果は、正確な見積もりよりも 皆で議論する場

Railsエンジニアの越川です。 Kobitoのユーザーインタビュー第2号としてインタビューを受けた頃から、qiitaを運営しているIncrements株式会社の創業メンバーと親しくさせて頂いておりまして、その縁から qiita meetup for moneyforward を開催して頂きました。 今回は弊社から8名のエンジニアが参加しました。交流が盛り上がってきたところでマネーフォワード陣からLTを2本させて頂きました。 弊社では情報共有にQiita:Teamを利用しているのですが、そこでの情報共有に関するLTです。 越川LT 私のLTでは、「WIPであろうと、情報共有すると何がいいのか？」というお話をしました。 Qiita meetup for MoneyForward from Naoto Koshikawa WIPの情報共有が良い点は、 当事者 になろうと思えばなれるチャンスが与

Railsエンジニアの越川です。 弊社では、テストを書く際にdatabase_rewinderを使うことが多いのですが、先日困ったことがありましたのでエンジニアブログで共有します。 database_nameを明示したモデルで困った 今回、複数のデータベースのテーブルを結合する際に明示的にデータベース名を指定したいケースがありました。 例えば、railsでいうとhas_many through: 'hogehoge'というシーンで、データベース名を明示したいケースがありました。 対象としたいモデルには以下の様な記述をします。 class Post < ActiveRecord::Base self.table_name = 'my_database.posts' end このようなモデルのデータがdatabase_rewinderで削除されないという事象がありました。 database_r