masatomo

前回、現在のQuipperの状況みたいのを書いたが、今回は、普段CTOとして、どういうことを意識して開発チームを作っているか、どういう開発チームになって欲しいと思っているか、というのを書いてみたいと思う。

この辺り、自分自身の経験からくる「好み」とか「美学」みたいなものが強めな部分でもあるので、表に出すのはなかなか勇気がいるが、co-founder/CTOである自分のそういうところが、開発チームのカルチャーに当然影響しているし、一緒に働くことになる人ととはカルチャーのマッチがとても大事だと思っているので出してみる。

まず、以前、社内でなんとなく書いた文章があるのでそのまま出してみる。これは開発者の採用活動に当たり、どんな人が欲しいと思っているか率直に書いたものである。

以下、「開発者」と書いてある部分は、Web開発者/iOS開発者/Android開発者/デザイナー/インフラ等の人達を指している。

---

sunaot

ユニットテストでテストを書くか書かないかの判断の話

お題

メソッドの出力の結果が、true か false のどちらでも返ってくる可能性がある場合、assert 文を書く時は true の場合だけで良いのだろうか

テストとは

まず、基本の考えとしてなぜテストをするのか？というのがあります。

onk

# rubocop v0.35.0 から inherit_gem という機能が増えたので gem にしました
# https://github.com/onk/onkcop
inherit_gem:
  onkcop: "config/rubocop.yml"

saboyutaka

input = [
    # [ id, input, expected ],
  [ 0, "4*5+6&7|8", "44" ],
  [ 1, "15*5", "75" ],
  [ 2, "15+5", "20" ],
  [ 3, "15&5", "5" ],
  [ 4, "15|5", "15" ],
  [ 5, "30*15*5", "2250" ],
  [ 6, "30*15+5", "600" ],
  [ 7, "30*15&5", "150" ],

1syo

<div class="container">
  <% if flash[:notice] %>
    <div class="alert alert-success">
      <%= flash[:notice] %>
    </div>
  <% end %>

  <h1>Users</h1>
  <%= form_for(@user_import, url: import_admin_users_path,
    html: {method: :post, multipart: true, role: "form", class: "form-inline"}) do |f| %>

sunaot

例外設計の話。

こんな指針がいいのかなー 2013 夏 ver.

例外の目的とは？

• 「例外をキャッチする主な目的は、エラーの原因を取り除いて、回復すること」
  • via http://dobon.net/vb/dotnet/beginner/exceptionhandling.html

.NET の「例外のデザインのガイドライン」にもこう書いてある。

turadg

# Support for Rspec / Capybara subdomain integration testing
# Make sure this file is required by spec_helper.rb
# (e.g. save as spec/support/subdomains.rb)
 
def switch_to_subdomain(subdomain)
  # lvh.me always resolves to 127.0.0.1
  hostname = subdomain ? "#{subdomain}.lvh.me" : "lvh.me"
  Capybara.app_host = "http://#{hostname}"
end

hayajo

ChangeLog を支える英語

ChangeLog を書く際によく使われる英語をまとめました。

ほとんど引用です。

基本形

Gab-km

GitHub Flow

• Scott Chacon on the Interwebs(リンク切れ)
• Scott Chacon on the Interwebs
• GitHub Flow - The best way to use Git and GitHub

31 Aug 2011

git-flowの問題点 (Issues with git-flow)

rosylilly

先輩に学ぶ HTTP Status Code

超雑にまとめました。修正してください。

登場人物

• アプリケーション先輩: いつも忙しい。横に広がるのが得意(デブじゃない)。
• 後輩: 頼んでばっかしで役に立たない。
• サーバー先輩: アプリケーション先輩と仲がいい。Unix Socket でつながるくらい仲良し。
• プロクシ先輩: アプリケーション先輩とかサーバー先輩と後輩の間を取り持って代わりに伝えたりしてくれる。たまに勝手にレスポンスを書き換える。