タグ

ブックマーク / blog.willnet.in (42)

  • 良いエンジニアを採用するにはどうしたらいいか - おもしろwebサービス開発日記

    以前ソフトウェア開発者採用ガイドの読書感想文を書いたときに反響が思ったより大きかったので、エンジニア採用というテーマは関心が高いのだなと感じました。 上記感想文のエントリでも書いていますが、お手伝いしている会社の方などから「どうやったら良いエンジニアを採用できますか?」と聞かれることがよくあります。先のエントリでは「頑張るしかないですねとしか答えようがない」と書きましたが、頑張るとはいったい何を頑張るのか、きちんとまとめておいたほうが良いなと思いエントリをしたためる次第です*1。 あくまで僕はこう思いますという話で、この通りにしたからといって必ず良いエンジニアを採用できる保証はありません。あしからず。 想定読者 良いエンジニアを採用したい偉いひと、もしくは人事のひとです。 前提: 良いエンジニアとは このエントリでの「エンジニア」とはいわゆるweb系のエンジニア(例: サーバサイドエンジニ

    良いエンジニアを採用するにはどうしたらいいか - おもしろwebサービス開発日記
  • 技術的負債を貯めずに開発するには - おもしろwebサービス開発日記

    先日行われたMedBeer -Rails開発での技術的負債との付き合い方で、「Rails Good Parts, Bad Parts」というタイトルで発表しました。 資料はこちら。 内容を要約すると、技術的負債を貯めずに開発するには (Railsプロジェクトであれば)Railsの便利な機能を活用する 要注意と言われている機能について、対応方法も含めて把握する 上記をチームで共有して、負債になりそうなものをmasterブランチに入れないように頑張りましょう つまり勉強と教育をがんばりましょう という話でした。あとは clean-rails.orgの紹介をすこしだけ。 所感 たいていどの会社でもコードレビューはしていると思いますが、少数のシニアエンジニアが全ての変更点をレビューしきれるとは限らないし、設計をコードレビューの段階で指摘するのは難しいことです。かくして負債となるコードや設計がレビュ

    技術的負債を貯めずに開発するには - おもしろwebサービス開発日記
  • Railsの可読性の高いコードについて議論するコミュニティを作りました - おもしろwebサービス開発日記

    Railsで可読性の高いコードを書くにはどうしたらいいのか。コミュニティやブログなどで個別の事例について言及されることはありますが、横断的なまとまった情報はほとんどないのではないかと思います。みんな、散らばった情報を集めて自分なりのやり方を模索しているのではないでしょうか。 そこで、自分なりのやり方を研ぎ澄ませるような、可読性の高いコードについて議論できる場所を作ってみました。clean-rails.orgというドメイン*1です。コミュニティ体はサブドメインのdiscourse.clean-rails.orgで、オンライン上できれいなコードについて議論できるようにしています。 可読性の高いコードを書くのが好きな方、参加してコメントいただけるとうれしいです(\( ⁰⊖⁰)/) これまでの経緯 Railsのきれいなコードについて議論する勉強会 - おもしろwebサービス開発日記チラシの裏 続

    Railsの可読性の高いコードについて議論するコミュニティを作りました - おもしろwebサービス開発日記
  • Rails Developers Meetup で綺麗なテストコードの書き方について発表した - おもしろwebサービス開発日記

    昨日のRails Developers Meetupで綺麗なテストコードの書き方について発表してきました。 Rails Developers Meetup #1(東京会場) - connpass 資料はこちら 余談 もともと数年前くらいから、テストコードの書き方についてまとめたいなーと思っていたのですがなかなかキッカケがなくて手を付けられていませんでした。今回のミートアップ駆動で一通り形にするところまでいけて今とてもスッキリした気持ちです 😇 もっと多くの人にテストコードの書き方を意識してもらいたいので、また機会があればどこかで喋りたいですね。 昨日発表した内容はGitHubリポジトリにまとめたものの一部です。綺麗なテストコードの書き方について詳しく知りたい方は下記のリンクからどうぞ。 willnet/rspec-style-guide お願い 今回まとめた内容はあくまで僕が考えるテスト

    Rails Developers Meetup で綺麗なテストコードの書き方について発表した - おもしろwebサービス開発日記
  • Rails::API について発表した - おもしろwebサービス開発日記

    FiNC さんの社内マイクロサービス勉強会と、表参道.rb にて、そろそろリリースされそうな Rails 5 におけるメジャーフィーチャの一つ Rails::API について話しました。 雑感 スライド読むと分かるように、Rails::APIAPI サーバを作る時の銀の弾丸でもなんでもなくて、条件に合致したときに使うとちょっとだけ速くなりますよ、軽くなりますよという機能なのでした。 Rails::API の機能面としてはそれだけなのだけど、Rails は Rack Middleware や ActionController::Base 内の Module が疎になっていて、着脱が簡単なんですよというのを示す良い例にもなっていると思います。使っていない Middleware や Module を外すことで、手軽にちょっぴり速く/軽くできるので、API サーバに限らず不要なものがある場合

    Rails::API について発表した - おもしろwebサービス開発日記
  • Rails で fat model を避けるための、あまり知られていない方法について - おもしろwebサービス開発日記

    このエントリで書いた内容は、ほぼ Growing Rails Applications in Practice の内容が元になっています。英語ですが、ここで挙げた内容以外にもコードを綺麗に保つテクニックが書かれており、かつページ数も少なく読みやすいです。コードを綺麗に保つのが好きな方は一読してみることをおすすめします。 はじめに Rails で fat model を避けるための方法は、7 Patterns to Refactor Fat ActiveRecord Models を始めとして、多くのやり方が存在します*1。 validation や callback は ActiveRecord(以下AR) を継承せずとも利用することができます。7 Patterns to Refactor Fat ActiveRecord Models の 「3. Extract Form Objects

    Rails で fat model を避けるための、あまり知られていない方法について - おもしろwebサービス開発日記
  • ゆるデブ合宿で島根に行ってきた - おもしろwebサービス開発日記

    ひょんなことから島根の自治体の方と知り合いになり、島根県が企業やコミュニティの合宿を誘致しているという話を聞きました。 合宿またやりたいなあ。島根まだ行ったことないし行ってみたいなあ。という気持ちからゆるデブのメンバーに相談したところ、反応がよかったので色々詳細詰めて、ゴールデンウィークを利用して島根に行くことにしました (\( ⁰⊖⁰)/) 内容については、すでに iR3 さんがブログに書いてくれています。 島根県松江市美保関町北浦海岸でyurufuwa開発合宿 - iR3’s diary 感想 全体を通じて、とても楽しい合宿でした!また行きたい! 島根の田中さんや井上さん、民宿の中村屋さんにいろいろご配慮&差し入れいただいて快適な合宿になりました。 4泊5日の合宿でしたが、2日は移動日(ゴールデンウィークなので調度良い時間のチケットが取れなかった><)に当て、2日もくもく、1日はアクテ

    ゆるデブ合宿で島根に行ってきた - おもしろwebサービス開発日記
  • 最近の Rack サーバ事情について - おもしろwebサービス開発日記

    先月、heroku推しサーバが unicorn から puma に変わったという発表がありました。unicorn だとスロークライアントの影響を受けやすいというのが理由なようです。 もう少し詳しく調べてみましょう。 そもそもスロークライアントってなに その名の通り遅い回線のクライアントです。3G環境のモバイル端末などが該当します。 「unicorn だとスロークライアントの影響を受けやすい」とは unicorn はプロセスモデルのサーバであり、blocking I/O モデルを採用しています。つまり、クライアントとの通信中プロセスが専有されるということです。 例えば unicorn がワーカプロセスを3つ立ち上げていて、そこへ通信完了に10分かかるようなスロークライアントが3つ接続されたら…、続くクライアントはスロークライアントの通信が完了するまで実行を待たなければならなくなります。プ

    最近の Rack サーバ事情について - おもしろwebサービス開発日記
  • 第19回 ginza.rb ミートアップ - おもしろwebサービス開発日記

    第19回目の ginza.rb ミートアップを開催しました。 Ginza.rb 第19回 だれが一番?Railsアプリサーバ徒競走!&Ruby2.2について話そう - Ginza.rb | Doorkeeper raptor と rhebok のパフォーマンスをみる 第17回ミートアップ で、Rack サーバの比較をしましたが、その時はまだ raptor の実装が公開されていませんでした。 今回は raptor(Passenger5) のベンチマークがとれるようになったので、ベンチを取ってみました。さらに、unicorn の2倍早いという rhebok というサーバも登場したので、それも一緒に。 @y_yagi さんが、第17回に利用したengine yardさんのアプリを使ってベンチをとってくれました。多謝! 使用したコード ベンチマークの結果 結果としては、比較対象としてベンチをとった

    第19回 ginza.rb ミートアップ - おもしろwebサービス開発日記
  • heroku 用の DNS を PointDNS に変更した - おもしろwebサービス開発日記

    heroku はデフォルトでは naked domain (サブドメインがないドメイン)は使えません。おそらく EC2 の制約?のはず。DNS によっては抜け道があるのですが、route53 では回避ができません。 route53 だと、現状では「naked domain にアクセスしたら www のサブドメインにリダイレクトする」という設定をするのが精一杯です。 僕は基 route53 を利用していて、そのため heroku で運用しているこのブログも一時 www.willnet.in というドメインにしていました。しかしやっぱり naked domain が使いたいな−。と思ったのでやり方を調べました。 PointDNS 結論として、PointDNS というサービスを使うことにしました。 heroku の addon として提供されていること heroku で naked domai

    heroku 用の DNS を PointDNS に変更した - おもしろwebサービス開発日記
  • ゆるふわ Development Club というサークルができた - おもしろwebサービス開発日記

    僕は個人でコツコツとwebサービスを作っているのですが、実際はチームで開発するほうが好きです。GitHub 上でミサワや寿司ゆきを貼ったり、チャットで機能の相談をしたり、雑談したりしながら開発を進める。やったことがある人なら、きっとその楽しさを理解してもらえるのではないでしょうか。 当たり前ですが、個人で開発するとなるとそうはいきません。チームで開発する楽しさを覚えてしまうと個人の開発は味気なくて物足りないです。 モチベーションの維持も課題です。納期や他者の目がないと、際限なく脇道にそれることができてしまいます。一人だとなかなか開発が進まない…><。 個人だけどチームっぽく楽しく開発を進めたい。 そこでポエムに、「僕みたいに個人で開発をしている人たちを集めたら、チームっぽい開発ができるのでは?」という内容を書いたところ、色々あってサークルが出来ました。 ゆるふわ Development C

    ゆるふわ Development Club というサークルができた - おもしろwebサービス開発日記
  • RSpec 3 時代の設定ファイル rails_helper.rb について - おもしろwebサービス開発日記

    rspec-rails、3.0.1 がリリースされていますね。インストールして rails g rspec:install とすると、spec/rails_helper.rb という見慣れないファイルが作成されます。これは一体何でしょうか。 rspec-rails のREADMEを読むと、これからは spec/rails_helper.rb に Rails 特有の設定を書き、spec/spec_helper.rbには RSpec の全体的な設定を書く、というようにお作法が変わるそうです。これによって、Railsを必要としないテストを書きやすくなるんだとか。 というわけで、これまで require 'spec_helper' としていた箇所の大部分は require 'rails_helper' に置換してあげる必要がありそうですね。パーフェクト Ruby on Rails のテストの章は

    RSpec 3 時代の設定ファイル rails_helper.rb について - おもしろwebサービス開発日記
  • パーフェクト Ruby on Rails のサンプルアプリケーションを Github 上で公開しました - おもしろwebサービス開発日記

    パーフェクトRuby on Rails 中の第6章で取り扱っている題材、イベント開催支援系のRailsアプリケーション awesome_events のソースコードを Github 上で公開しました。 ソースコードは技術評論社さんのサポートページからダウンロードすることもできますが、やっぱり Github から持ってこれたほうがいいですよね。 さて awesome_events とはどんなアプリケーションでしょうか。すごくざっくり書くと、Doorkeeper や ATND の簡略版です。 使っている gem は、Rails を普段使っている人から見たらかなり普通な感じ。特筆すべきなのは carrierwave と ransack くらいでしょうか。omniauth で「Twitterログイン」機能を作ったりもしています。 gem 'rails', '4.1.1' gem 'sqlite3'

    パーフェクト Ruby on Rails のサンプルアプリケーションを Github 上で公開しました - おもしろwebサービス開発日記
  • rspec-rails を 3.0.0.rc1 にアップデートする際に気をつけること - おもしろwebサービス開発日記

    rspec-rails を 3.0.0.rc1 にアップデートすると、きっとテストがこけまくるようになるはず。そんな時は spec_helper.rb に次の設定を足してあげてください。 config.infer_spec_type_from_file_location! これまでの rspec-rails は、例えば spec/controllers 配下のテストであれば自動で type: controller を付与してくれていました。しかしrc1から前述の設定を足してあげないと自動付与しなくなりました。 これ結構なハマリポイントだと思うのですが、あんまり周知されていないようなのでエントリ書いてみました。無駄に時間を費やす人が一人でも減ることを祈っております…。

    rspec-rails を 3.0.0.rc1 にアップデートする際に気をつけること - おもしろwebサービス開発日記
  • パーフェクト Ruby on Rails という本を書きました - おもしろwebサービス開発日記

    ここのところブログの更新頻度が下がっていたのはそういうことです。 @sugamasao、@udzura、@joker1007と共同で書きました。 パーフェクト Ruby on Railsposted with amazlet at 14.05.02すが まさお 前島 真一 近藤 宇智朗 橋立 友宏 技術評論社 売り上げランキング: 272 Amazon.co.jpで詳細を見る 執筆経緯 個人的な発端は去年の9月くらい。当時常駐していた会社のメンバーたちでランチ行く途中、@udzuraさんに「Railsを書く話があるんですが興味あります?」と聞かれたので、査読でもお願いされるのかなと思いながら「興味ありますよー」と答えたらいつの間にか著者になっていました。とはいえ、もともとRailsは一回書いてみたいと思っていたので結果オーライ。 どんななの このは、著者陣たちが「Railsを始

    パーフェクト Ruby on Rails という本を書きました - おもしろwebサービス開発日記
  • Rails 4.1.0 で新しく導入された便利メソッド - おもしろwebサービス開発日記

    Rails(ActiveSupport) は標準クラスを拡張した便利メソッド群を提供してくれています。時々これは使わないなー…という微妙なやつもありますが、僕はけっこう好きです。 Rails 4.1.0 で新しく入ったそんなメソッドをまとめます。 Numeric#in_milliseconds 数値をミリ秒の単位に合わせて返す。 1.hour.in_milliseconds #=> 3600000 実装は単に1000倍しているだけ。 def in_milliseconds self * 1000 end すごくたまに使うかもしれない。 Date#middle_of_day, DateTime#middle_of_day, Time#middle_of_day 昼の12時を返す。 date = Date.today date.middle_of_day => Sat, 19 Apr 2014

    Rails 4.1.0 で新しく導入された便利メソッド - おもしろwebサービス開発日記
  • ランダムで日本人の名前を返す gem を作った - おもしろwebサービス開発日記

    gimei という、ランダムで日人の名前を返す gem を作りました。 似たようなライブラリに faker があります。faker は人の名前だけではなく、住所やメールアドレスやユーザ名や電話番号など、たくさんのジャンルのダミーデータを返してくれるすごい gem です。しかも i18n に対応しており、yaml ファイルを定義すれば日語も使えます。 じゃあ faker でいいじゃん!って思いますよね。しかし一つだけ問題がありまして…。ふりがなが使えないのです。 そこでgimeiです。gimeiは下記のような形でふりがな(フリガナ)に対応しています。 gimei = Gimei.new gimei.kanji #=> "斎藤 陽菜" gimei.hiragana #=> "さいとう はるな" gimei.katakana #=> "サイトウ ハルナ" gimei.last.kanji #

    ランダムで日本人の名前を返す gem を作った - おもしろwebサービス開発日記
  • logrotateでログのローテーションをする - おもしろwebサービス開発日記

    railsのproduction.logなどをローテーションする一般的な方法、logrotateについてのメモ書きです。 基 /etc/logrotate.confにデフォルトの設定 /etc/logrotate.d/配下に個別の設定を書く 利用できるディレクティブ(の一部) daily or weekly or monthly ログのローテーション間隔 missingok ログファイルがない場合でもエラーにしない rotate n n回ローテーションする compress ローテーションされたログを圧縮 delaycompress 次回のログローテーションサイクルになるまで圧縮しない notifempty ログファイルが空ならローテートしない create 0644 user group ログファイルのパーミッションと所有ユーザの設定 copytruncate 通常、ローテートするとき

    logrotateでログのローテーションをする - おもしろwebサービス開発日記
  • Rails 4.0 と bundler install --binstubs について - おもしろwebサービス開発日記

    Rails 4.0.beta1 でアプリ作ってみようとして、途中で bundle install --binstubs としたら、なぜか rails generate などのコマンドが効かなくなってしまいました。、これは、Rails 4.0 が生成する bin/railsbundler がオーバライドしてしまったことが原因です。前に何処かで「bundler 1.3 は bin/rails が存在していたらオーバライドしないようにする」みたいなことを読んだ気がしたのですが、これはどういうことだったのだろう…というかそもそもなんでオーバライドしたら不具合起きるの><と思ったのでちょっと調べてみました。そして「多分こういうことなんだろうなあ」というところまで来たのでまとめてみます。推測も混じってるので間違ってたら教えてください。 Rails 4.0 での変更 Rails 4.0 からは s

    Rails 4.0 と bundler install --binstubs について - おもしろwebサービス開発日記
  • js で利用する DOM の名前をどうやってつけたらよいのか - おもしろwebサービス開発日記

    js で DOM をゴニョゴニョしたい時、きっと皆さんは id や class で DOM に名前を付けて、その名前を利用して js の処理を書いていると思います。 例えば<input type="button" class="update" value="更新" />のようなボタンがあったとして、 js 側で更新処理を書くときには下記のように書きます。 $('.update').on('click', function () { // update 処理 }) でもこれだと問題になるケースがあります。よくあるのが、マークアッパーとフロントエンジニアが分業していて、マークアッパーがデザインのために class 名を変えてしまい js が動かなくなるパターン。分業せずに一人で全部やってたとしても、時間が経つにつれ使っている class 名が js だけで使っているのか、css でも使っている

    js で利用する DOM の名前をどうやってつけたらよいのか - おもしろwebサービス開発日記