年の瀬なので、これまで作業するのに使ってきたデスクの遍歴について書く。 2011 これは3年前、大学生のときの実家の自分の部屋。インターンで得たバイト代をほぼ全部使って購入したMacbook Air 11inchと、Acerの大きめのディスプレイ。隣に転がってるヘッドフォンはAKGのK701で、けいおんで使われて流行ったのがきっかけで急に売れ始め理解できないまま業者が大量輸入するもそこまで売れず、抱えた在庫への不安から価格が一万円代まで下がった一瞬の隙を突いて買った。机は中学のときに親にもらったやつで、姉が一人暮らしを始めて余ってたのを貰い受けて二つ繋げて使ってた。ディスプレイとヘッドフォンと机は今も全く同じものを使ってる。右側にMacbookを置いてトラックパッド代わりに使うというのも今と変わってない。 部室 これは大学で所属していたギタークラブの部室の机。ここでよく譜読み (うちの部活

『Web API: The Good Parts』を読んだ。贈ってくれた人達ありがとうございます。 Web API: The Good Parts 作者: 水野貴明出版社/メーカー: オライリージャパン発売日: 2014/11/21メディア: 大型本この商品を含むブログ (2件) を見る 目次 詳細はO'Reillyのページにて。 1章 Web APIとは何か 2章 エンドポイントの設計とリクエストの形式 3章 レスポンスデータの設計 4章 HTTPの仕様を最大限利用する 5章 設計変更をしやすいWeb APIを作る 6章 堅牢なWeb APIを作る 所感 Web API、よく知らない場合はとりあえず作りやすい方法で作っていこうという気持ちになりやすい。しかし、Web APIは後から変更するのが比較的難しいものなので、つらいものを使い続ける羽目になりやすい。また一貫性が重要視されやすいので

華やかなところはまあググれば出てくるんで、地味なところに触れる。 日報にまとめておく リモートワーク中は、毎朝10:10 - 10:20の間、Google+ ハングアウトのビデオ通話を利用して進捗・問題共有しているんだけど、慣れてないと共有過多で時間が長くなりがち。8人居て、1人5分とかになると重い。いま取り組んでいる実装の話とかを始めてしまったり、あと会議参加者に対して「これどうですかね？」と質問する内容が含まれていたりすると、特に時間が長くなりがち。この辺は、事前にQiita:Teamの日報に前日やったことや翌日やることをまとめておいて、詳しくは日報に書いたんで見てくれという風に改善されたりした。日報、リモートワークで特に役に立つ。では日報を書いておけばミーティングは不要になるのではないかという話になるかもしれないが、この先は君の目で確かめてくれ。 情報の倍率を変えられるようにしておく

https://github.com/r7kamura/ruboty RubotyというRuby製のChatterbotをつくった。 Herokuで動かす Herokuにデプロイすれば無料で動く。 Slackというチャットサービスで動かすならこういう感じ (部屋名とかは適宜変える): $ mkdir mybot $ cd mybot $ echo 'source "https://rubygems.org"' >> Gemfile $ echo 'gem "ruboty"' >> Gemfile $ echo 'gem "ruboty-slack"' >> Gemfile $ echo 'bot: bundle exec ruboty' >> Procfile $ bundle install $ git init $ git add . $ git commit -m "Initial

最近APIサーバ用途でRailsアプリを1個つくったので振り返る。 概要 接続元はiOSやAndroidアプリとか、Webブラウザとか、別のWebアプリケーションとか。1ホストあたり秒間数百リクエスト、平均応答時間10msぐらい。Rails 4.1.0.rc2、Unicorn、Nginxを使ってる。正直Railsは全部入りで重いイメージがあったので何となく平均50ms以内程度であれば良いところだろうと思ってたけど、意外と速い。多分そもそもサーバの性能が良いんだと思う。実装時に気を付けたことは普段の開発と特に変わりない。いつもは大勢でワイワイ開発するものに少し手を加えるということが多いんだけど、今回は珍しく自分一人でつくったから目が行き届いてたのかもしれない。DBへの問合せの効率に気を配るとか、Rubyでの処理の無駄を省くとか、アプリケーションのプロセスに無駄なコードを読み込ませないとか、計

高速スケーラブル検索エンジン　ElasticSearch Server (アスキー書籍) 作者: Ｒａｆａｌ　Ｋｕｃ　（ｌにストローク符号、ｃにアクサン・テギュ付く）,Ｍａｒｅｋ　Ｒｏｇｏｚｉｎｓｋｉ　（ｎにアクサン・テギュ付く）出版社/メーカー: KADOKAWA / アスキー・メディアワークス発売日: 2014/03/25メディア: Kindle版この商品を含むブログを見る 高速スケーラブル検索エンジン ElasticSearch Server という本を読んだ。読んだ理由は、タイミングが良かったから。効率的に学ぶのに丁度いい時機というものがあると思う。何かを学ぶのには動機と情報源が必要。動機が無ければ勉学は長続きしないし、無理矢理覚えようとしても楽しくない。Elasticsearchに対しては何か面白そうという気持ちを最近少しだけ感じていて、こういう気持ちが湧くのは貴重なことだから大

この記事には、Rubyを書いているときに「これは言語化されたり公式化されたりしていないけれど基本的には必ずこのパターンに則ってプログラムを書いているな」ということをふと思い出したときにやってきてそのパターンを書く。多分3パターンぐらいで終わると思う。ウケが良ければ思い出す確率が高くなると思う。題材さえあれば何も考えずに書けるので、これを書くコストは全然高くない。 名前が"?"で終わるメソッドは必ずtrueまたはfalseのどちらかを返す trueとfalse以外(例えばnil)が返る可能性がある場合は、必ず式の先頭に!!を付けてtrueかfalseになるようにしてる。 このパターンを守ることがとても大事だという風には全く考えていないけど、もしhas_user?がuserを返すとして、has_user?という名前のメソッドがUserオブジェクトを返すというのは一体どういう意味を持っているのだ

テスト書きすぎ問題 - hitode909の日記 階層が増えるとテストが増える - はこべブログ ♨ テストと対応関係 - $shibayu36->blog; 最近書いているWebアプリは、HTTPリクエストを送ってレスポンスと状態をテストする、というテストだけ書くようにしてる。リクエストするとブログエントリを返す、というサービスだとこういう風なテストを書いてる。(HTMLを返すようにすると話が広がって説明が面倒なのでJSONを返すAPIで説明する) describe "Entry resource" do let(:params) do {} end let(:env) do { "HTTP_AUTHORIZATION" => "Bearer: #{access_token.token}" } end let(:access_token) do AccessToken.make(user