Rails のモデルはどうあるべきか - tomykaira makes love with codes
2013-07-05 Rails のモデルはどうあるべきか rails TL;DR: Rails の model が太りやすいのは、生まれつき責務過剰だから。開発者が設計段階で責務を絞り、食べる量を減らしてあげよう。 Rails の model というのは、概念も実装も、とても奇妙な使われ方をしている。 いささか不気味だし、実害もある。 fat model はずっと Rails 界で話題になりつづけている。 すでに Rails のプロフェッショナルは抜け出せているのかもしれないが、まだ議論の余地のある話題ではあるようだ。 なぜ model が太るかというと、なんでもかんでも model に食べさせるからである。 一日中食べてれば元々どんなにスレンダーでも太るに決まってる。 コードのダイエットは食べる量を減らすか、外に出すしかない。 太ってから外に出すのがリファクタリングである。 後知恵的に
レビューフレンドリーな開発のしかた - tomykaira makes love with codes
2013-09-02 レビューフレンドリーな開発のしかた git dev 最近は多くのチームでレビューの習慣が定着してきました。おもにレビュアーとしての仕事を依頼されることもあります。 コミット・ブランチの作りかた一つでこのレビューのしやすさが格段に違ってきます。 自分が普段の開発でこころがけていることをまとめてみます。 前提 レビュイーとレビュアーの間に上下関係があるわけではないですが、レビュイーは多少手数が増えても、レビュアーのことを最大限配慮すべきです。 なぜなら、レビュイーはその機能の開発に集中して取り組んでいますが、レビュアーはすこし見るだけです。 なにかするとしたら、レビュイーがやったほうが時間も手間も少なくなります。 レビュアーはレビュイーよりも、変更について詳しくありません。 レビュイーは開発にいろんな部分を見てまわり、他のモジュールとの関連性や実装のこまかな意図を把握して
Rails の validation 論争批判 - tomykaira makes love with codes
2013-07-10 Rails の validation 論争批判 Rails 容赦なく批判するので、気分悪く思う方は読まないでください（後半だけよむといいかも）。 twitter での議論は、徳丸さんがまとめられている分はみましたが、それ以外は見落としがあるかもしれません。 TL; DR: これまでの議論は教条的であり、技術を誤解したうえで過信している。 バリデーションは広い意味をもつが、重要なドメインについての観点が見落とされている。 技術者として、なにが必要で、どう実装すべきか自分の頭で考えよう。 validation (バリデーション) とは バリデーションとは 【validation】 〔バリデート〕 - 意味/解説/説明/定義 ： IT用語辞典 検証(する)、実証(する)、認可(する)、妥当性確認、などの意味を持つ英単語。ITの分野では、対象がその仕様や文法などに照らして適切
Rails、あんたなんか嫌いよ - Rails での OO 設計について - tomykaira makes love with codes
2013-06-25 Rails、あんたなんか嫌いよ - Rails での OO 設計について ruby rails 最近はずっと Rails 書いてるんですが、書けば書くほど嫌いになってくるんです。 倦怠期的なやつなんですが、 Rails さんの悪いところばっかり見えてきて、もう一緒にいたくないんです。 でも別れるほどじゃないし… という愚痴にみせかけた Rails での設計についての議論です。 長いけどコードは一切出てこないので通勤中にでもよんでください。 注意 一部にはげしい言葉遣いがでてくるので、読んで不快になるかもしれません。 不快になったとしても責任は負いかねます。 次のような方の期待に沿う結論はでません。残念でした。 Sinatra, Padrino の人 関数型の人 静的型付けの人 C の人 TL;DR Rails にだまされない。 自分の道を見定める。 欺瞞にみちた Ra
Response to "7 Patterns to Refactor Fat ActiveRecord Models" - tomykaira makes love with codes
2013-06-02 Response to "7 Patterns to Refactor Fat ActiveRecord Models" rails This is the English version. The Japanese version with the same content is at the bottom of this article. Original article: 7 Patterns to Refactor Fat ActiveRecord Models - Code Climate Blog The video of presentation recorded in RubyKaigi 2013, 2nd day The problem -- Where they should be? "7 Patterns to Refactor Fat Acti
使う rbenv-gemset をスクリプト内で指定する - tomykaira makes love with codes
2013-04-09 使う rbenv-gemset をスクリプト内で指定する ruby rbenv rbenv-gemset rbenv の gemset をつかうと、ちょっと試したい gem をグローバルの gem list を汚さずに利用できる。 rvm の gemset とほぼ同等の機能を提供するが、使い勝手がすこしちがい、 rbenv のほうがスクリプトをもちいた拡張に向いている。 複数の gem に依存する大きなプロジェクトやスクリプトを配布する場合は、 gem するか、bundler を使えばよい。 しかし、すこし試したい場合や普段づかいの書く場合にいちいち gem するのは面倒である。 かといって、グローバルの gem list にいろいろ入れると、散らかっているようで気分がわるいし、再セットアップのときになにを入れたらいいのか分からなくなりうる。 そこで、 rbenv-g
Valgrind でメモリリークをデバッグ - tomykaira makes love with codes
2013-01-28 Valgrind でメモリリークをデバッグ C++ C/C++ でメモリリークをデバッグするツールはいくつかある。代表的なものだと mtrace ccmalloc dmalloc LeakTracer valgrind など。 OpenCV と X11 を使ったプログラムのデバッグにおいて、 valgrind が役にたった。 使い方を他のツールのものもあわせてメモしておく。 紹介しているブログ記事や、それぞれのツールの example では通常短いプログラムを例に出している。 短いプログラムでそれなりの結果がでるのはあたりまえで、ライブラリを使って長時間動く複雑なプログラムにどれだけ対処できるかが腕のみせどころである。 今回は再現が簡単で、実行時間もせいぜい10分もとれば十分だったので、ケースとしてはそんなに難しくなかったが、規模が大きくなると解析結果を見ることすら困
使っていなかったが、今後使っていきたい emacs 拡張 - tomykaira makes love with codes
2013-01-25 使っていなかったが、今後使っていきたい emacs 拡張 emacs emacs の設定は放置しておくとどんどん肥大化していく。 最近 emacs の動作が不安定になったり、拡張の衝突でうまく動作しない場合があったりしたので、一回全体を整理してみた。 「あ、これ便利そう」と思って入れてみても、次の日までそのバインドを覚えてられないので結局使わない、みたいなことがよくある。 そこで普段あまり使っていない機能は便利なものでもバッサリ削除し、必要最小限に留めた。 実際に動作効率が向上したかはよくわからないが、すくなくともなにが入っているかの頭の整理にはなった。 整理したうえで、普段使ってなかったけどこれからは積極的に使わなきゃな、と思ったものを忘備をかねて書いておく。 highlight-symbol.el http://emacsmode.googlecode.com/s
最近の git の使い方について - tomykaira makes love with codes
先日の #shibuyarb の懇親会ですこし話したら、わりと食い付いてもらえたので、 knowledge worth spreading だと感じた。git の設定を中心に共有する。 ワークフロー @kyon_mm さんの Continuous Commit の熱心な信奉者である。 Continuous commit とは continuous integration, continuous delivery とおなじように、開発中のコミットを自動化する試みである。 continuous commit という言葉はなくても、おなじようなことを自分でやっているひとは多そうだ。 continuous commit は大量のコミットログを残すので、これを整理する作業はけっこう負荷が大きくなる。 最近はこのあたりを改善している。似たようなワークフローを採っている人には役にたつと思う。 コミットを
渋谷.rb で Jubatus について発表しました - tomykaira makes love with codes
飛びいりでしたが混ぜていただけて大変楽しい時間を過せました。 ruby コミュニティはどこもそうですが、 shibuya.rb もレベルの高い方が多く、刺激になりました。もっと勉強せんと。 「Jubatus 5 分クッキング」という題で、 Jubatus の簡単にはじめられる側面を紹介し、こないだの Qiita Hackathon で @kumagi さんと一緒に作成したアプリケーションを紹介しました。 今後、 qiita も Jubatus も機会をみつけて触っていきたいなと思います。 Jubatus とは Jubatus（ユバタス）は、大規模分散上でリアルタイムで機械学習を行うためのフレームワークです。 Jubatusを公開しました | Preferred Research しかも、簡単です。 インストール jubatus は依存性解決が大変… glog-0.3.2 libevent-
Rackhub を始めてみて、既存の rails アプリをデプロイしてみた。 - tomykaira makes love with codes
修正(2012-06-09 20:00) mysql の設定にかんして勘違いしている部分がありました。 user を明示的に mysql に設定しないと、パーミッションエラーで動作しないと思っていましたが、@sowawa さんとの議論でこれは誤解で、指定しなくても大丈夫ということがわかりました。 しかし、明示的に指定したほうが、mysql_safe 以外から起動したときなどにミスがおこりにくいので、よいとおもいます。 本文では間違いだった部分に取り消し線をいれました。 # そもそもなんで最初にうまく起動しなかったんだろう??? (以下本文) 登録にクレジットカード必須。持ってない人はメールで相談するとなんとかしてくれるんだったはず。 最初、DNS が設定されるまですこしかかる(1 minくらい) はいっているもの(使いそうなもの) nginx nginx/1.2.0 現在、se
JSX を二日間ぐらい使ってみて、あんまりよくないことがわかった - tomykaira makes love with codes
恒例の言語 dis 記事。無知をさらけだしているのでぜひともつっこみをください。 2日間ぐらい JSX でちょっとしたプログラム(真理値表をいじったり、QM法をおこなったりするもの)を書いてみて、JSX が残念なことがよくわかったのでまとめた。今回やったのはわりとロジックっぽい部分で、表示したりライブラリつかったり外部と連携したりといったことはなかった。 JavaScript / JSX の用途としてはかなり特異なものだとおもうので、そういうのに適当じゃなかった、というのはあるかもしれない。 しかし JSX の場合はべつにウェブ系に強い印象もないので(ライブラリとか)、今回指摘する問題点の一部は、やはり看過できないと思っている。 環境編 エラーが出たときに、どこで出ているのかわかりにくい 変換したスクリプトを node.js で実行しているため、通常の実行時エラーは変換後の js フ
RSpec で parameterized test を簡単に書ける、rspec-parameterized を作成しました - tomykaira makes love with codes
rspec-parameterized | RubyGems.org | your community gem host tomykaira/rspec-parameterized次のような spec が書けます。 describe "plus" do where(:a, :b, :answer) do [ [1 , 2 , 3], [5 , 8 , 13], [0 , 0 , 0] ] end with_them do it "should do additions" do (a + b).should == answer end end with_them :pending do it "should do additions" do (a + b).should == answer end end end -fd をつけて実行すると次のような感じで出力されます。 RSpec::Pa
人様の git リポジトリを milkode で簡単に管理するインタフェース「gitomb」を作った - tomykaira makes love with codes
tomykaira/gitomb Milkode は数万のファイルでも軽々動く、ソースコード検索エンジンです(製作者は id:tuto0621 さんです）。 しかし、数万ファイルもあるリポジトリなんて管理しますか?普通。 ソースコードを検索する回数がもっとも多いのは、既存のライブラリの使い方がよくわからないときに、ドキュメントに乗っているメソッド名を手掛かりに検索して、望みの機能を発掘していくような時のはずです。いままで、ライブラリのコード検索をしようとおもったら、 ライブラリを落としてくる そのディレクトリに移動する git grep かなんか ヒットしたファイルをエディタで開いて、まわりを見回す 見付かるまで検索をくりかえす みたいなことをやっていました。milkode web を使うと、次のようになります。 ライブラリを落としてくる そのディレクトリに移動する milkode
非 Rubyist に送る、失敗しない ruby 実行環境構築方法 - tomykaira makes love with codes
OS や、動かしたいアプリケーションに依りますが、ruby の実行環境の構築は大変です。 というのも、ruby 本体、rubygems、各 gem などのバージョン指定が交錯していて、ruby の ecosystem に慣れていない人にとっては、なにがなんだかわからないからです。 こっちのツールを動かそうとすると、こっちが動かなくなる、みたいなことになります。rubyists は、バージョンの問題を吸収するためのツールを使ってこの問題に対処していますが、ruby に詳しくなくて、ただ ruby 製のツール(たとえば Redmine)を使おうとしている人は分からないでしょう。 そういう人が ruby に挫折しないように、事実無根な中傷をしないように、最近流行のツールで、バージョンミスマッチの問題をおこさない方法を説明します。この説明が対象としているのは UNIX,LINUX 系の環境だ
#startupGroovy で Java+Groovy のテストを学んだ - tomykaira makes love with codes
ハンズオン id:kyon_mm 先生が書いたテストコードに対して、実装していく形の課題。 4clojure という clojure 勉強サイトでも、同様の形式をとっている。 ベストではない答をしてしまう問題があるが、自分で調べる方法がわかるというのが利点である。 groovy / clojure を実際に使ってるひとが、「こういうのよくやるよね〜」でお題を作るとよさそう。 問題の意図(これができる API 関数を探せ)というのがもしかしたら伝わっていなかった人がいたかもしれない。 第一ステップでほぼおわってしまい、あとは closure で遊んだり、groovy 独特の演算子を勉強したりした。演算子については Groovyの奇妙な演算子(その１） - Grな日々(uehajの日記) Groovyの奇妙な演算子(その2) - Grな日々(uehajの日記) Groovyの奇妙な演
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
再インストールの時にインストールすべき gem - tomykaira makes love with codes