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| %>

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" ],

tyabe

#! /usr/bin/env ruby
# coding: utf-8

require 'sinatra/base'
require 'active_resource'
require 'haml'

class MAService < ActiveResource::Base
  self.site = 'http://jlp.yahooapis.jp'
  DEFAULT_PARAMS = {

satococoa

#!/bin/zsh
tmux new-window -n name # 新しいwindowを開きたくない場合は以下
# tmux rename-window name
tmux split-window -h
tmux split-window -v -t name.0
tmux split-window -v -t name.1

tmux send-keys -t name.0 'echo 0' C-m
tmux send-keys -t name.1 'echo 1' C-m
tmux send-keys -t name.2 'echo 2' C-m

nesquena

Jbuilder.encode do |json|
  json.content format_content(@message.content)
  json.(@message, :created_at, :updated_at)

  json.author do |json|
    json.name @message.creator.name.familiar
    json.email_address @message.creator.email_address_with_name
    json.url url_for(@message.creator, format: :json)
  end

onk

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

esehara

by https://github.com/erlang/otp/wiki/Writing-good-commit-messages

良いコミットメッセージは、重要な役割が、少なくとも三つあります。

• レビューするプロセスをスピードアップする。

• 良いリリースノートを書く手助けになる。

• 将来、Erlang/OTPのメンテナンスを手助けするため（もしかしたら君かも！）。それは五年後の未来において、なんでコードの中で特定の変更が加えられたのか、あるいは特定の機能が追加されたのか見つけるため、ということ。

sunaot

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

お題

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

テストとは

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

masatomo

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

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

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

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

---

sunaot

例外設計の話。

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

例外の目的とは？

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

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