こんにちは、freee株式会社 の @hiraguri です。 この記事は freee Engineers Advent Calendar の24日目です。 明日25日目はいよいよfreee advent calendarの最終日として弊社CTO @yokoji が登場します。 そんな大団円を控えた今日は、これまでとは少し毛色を変えてfreeeのエンジニアチームについて話そうと思います。 マネジメントの話をガッツリしてもおもしろくないと思うので、freeeのユニークな点についていくつかご紹介します。 エンジニアチームの責任者が2人いる freeeには現在50人のエンジニアがいて、エンジニアチームの責任者が2人います。 CTO と vp of engineeringです。 CTO を @yokoji が、vp of engineering をぼくがやっています。 CTOは「最高技術責任者」の

はじめに ここ一年くらいずっと Rails の何がダメでどうすれば良くなるのかを考えていました。 Rails を使ってそれなりの規模のアプリケーションを作ったことがある人なら、メンテナンスのしづらさを感じたことがあるのではないでしょうか。 メンテナンスの問題は Rails 以外の開発でも発生することですが、実のところメンテナンスしやすいアプリケーションはどうすれば作れるのでしょうか？ この難問に対して私も答えを持っていませんが、考え続けています。 少なくとも、 Rails Way や Rails Tutorial をベースにしたアプリケーション開発は、業務で用いるには簡単すぎるように思います。 「レールに乗る」という言葉がありますが、私は考え方を変えました。 Rails は規模の大きいフレームワークですが、土台に過ぎません。 Rails Way の設計方針は小規模な開発では有効ですが、規模

背景 ひと昔前までフロント側build toolと言えば grunt が主流でしたが、今は gulp が主流になりました。 gulpは現在のところ3.9が最新ですが、水面下では4.0が準備中です。 4.0は久しぶりの major version release だけあって、結構な breaking changes が含まれる予定です。 4.0がいつリリースされるかは分かりませんが、 4.0 branch は用意されていて、そのほとんどの機能はもう動かすことができます。 本エントリではchangelogを見ながら、その機能を実際に試していって、どういったものか説明していこうと思います。 今回書いたコードはgithubにあげたので、もし試したい方がいればどうぞ。 資料 changelog API document バージョン $ ./node_modules/gulp/node_modules