ActiveRecord
Introduction 第1章: for Ruby users (4) ・CRUD operations ・Assocations 第2章: for Rails users (15) ・With Scope ・Scoped Access 第3章: for Rails developers (17) ・Acts As View ・Finder Query CRUD : ActiveRecord Pattern require 'rubygems' require_gem 'activerecord' ActiveRecord::Base.eatablish_connection( :adapter=>"sqlite3", :db=>"db/users.db" ) class Member < ActiveRecord::Base # "members" e
DCIが面白い件 - ヽ( ・∀・)ノくまくまー(2010-05-12)
● DCIが面白い件 DCI凄い！ヤバイ！ 「DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien」(翻訳) http://d.hatena.ne.jp/digitalsoul/20100131/1264925022 前に読んだときは難しすぎて(長すぎて)途中で挫折したけど、今改めて読んだらDCIは凄いと気付いた。以下、まとめ。 今回、内容理解の決め手となったのは「前半部分を読まない」ことだった。 そんな無謀な読み方(読んでないのだけれど)をした私の理解なので、 もちろん間違いはあるはず。 という前提で、 ツッコミを入れる気満々なテンションでどうぞ。 古来からプログラムの中心は＜データ＞であった なぜなら、それが設計の中で一番変化しにくい要素(箇所)であるから そして、＜データ構造＞とそれに対する＜処理＞の2つで考えるようになった (手続き型
RubyからScalaに乗り換えた15くらいの理由 - ヽ( ・∀・)ノくまくまー(2010-04-26)
● [Scala] RubyからScalaに乗り換えた15くらいの理由 [注意] この文章を読むと、既存のRubyコードをScalaでrewriteしたくなる、 Rubyコードで型チェックをやるのが鬱になる、Ruby案件でやる気が出なくなる、 などの幻覚や異常行動が報告されています。 現在関わっているプロジェクトや家族のことを常に意識し、 気を強く持って冷静に読むとよいでしょう。 「Scalaプログラミング入門」を読みはじめて、いきなり大きく頷いてしまった。 "コーディング時間の半分をテスト作成に費やさなければならなかった"(p.3) "Railsによって得られた生産性の向上は、テスト作成の作業に失われてしまいました"(p.3) まさにここ数年私が抱いてた漠然としたストレスの正体が、的確に文章となっていたからだ。そしてほどなく、「あ、この機能がRubyに欲しかった！」という驚きと共に Sc
ヽ( ・∀・)ノくまくまー(2009-04-08)
やはりテストの話題になって stubとmockの違いを1行で！ 今のテストフレームワークのお薦めは？ RRが熱いよ！(英語ぽく書くのが目的じゃない、rubyぽいdslが必要なんだ！) mock で should_receive でガチガチにサブオブジェクトに介入してくる人って何なの！ duck type の考え方からしても、何をやるかは相手に任せるベッキー mock は探針であるべきだ stub しか使わないよね ごめん、俺、最近は実データ派に戻ってきたんだ（Fixtureラブ） Fixture はシナリオ別に使い分けるのが面倒じゃない？ そこで FactoryGirl ですよ 何が嬉しいの？ テストデータを ruby コードで動的に書きたいときがある それって、もし fixture を簡単に切り替えられる機能があれば不要じゃね？ 動的なら YAML でゴリゴリ書く方法もあるし 切り替え、
ヽ( ・∀・)ノくまくまー(2009-07-21)
UnitTest で部品をしっかり守っているのに運用時にエラー さらに version up 時には頑張って書いた UnitTest が無駄になる UnitTest の存在意義に疑問が出てくるから、書こうとする気力が落ちる 思考停止して頑張ってまた書いても、また運用時にエラーが起きちゃう こうして悪いリズムが生まれていく 長期的な回帰テストとしては UnitTest は無力 まず書くべきは End to End のテストだった・・・ 河田・・・受入テストにつけ！ なるほど、UnitTest よりも受入テストの方が対象となるシステムの挙動と密接であるため、確かに テストコードが長生きする とことがわかる。うん、それで問題が解決しているよ。でも、さらに「実行者が人でないといけない」と言ってるのはなぜ？ここからが問題の核心だが、その答えから言えば 人である方がテストコードがさらに長生きする から
JRuby はじめました - ヽ( ・∀・)ノくまくまー(2009-06-30)
1.8 のスレッドは？ green thread (ユーザレベルスレッド) 1.9 でなんか変わったの？ native thread (カーネルスレッド)になった おぉ、マルチコアの恩恵を受けて高速化！？ いや、並行実行はしない どういうこと？ 各スレッドを順番に少しずつ実行するけど、同時には実行しない え？じゃ、速度は... 1コアでも32コアCPUでも一緒 ちょｗ。それって1.8でも一緒じゃん。何で並行実行しないの？ Rubyから使うCの拡張ライブラリを全部、並行処理に対応させる必要があるから それは大変そうだな。連絡付かない作者もいるだろうし 1.9 では動かなくなるライブラリがあるのを避けるために、native にしたけど並行化はしなかった 確かに、正しい選択だ。で、本当は？ 作業コストが大変だから(笑) ちょｗｗ。あれ？じゃあ green thread のままでも良かったんじゃね
ヽ( ・∀・)ノくまくまー(2008-06-02)
● [Rails] svn レポジトリを github に移行させてみる svn はわかる (使ってる) git は多分イケテル svn なのだろう (メリットも知らね) github は git をまとめて公開してるサービス？ 前知識はこれだけなgit無学者が、ネットに溢れる git コマンドを適当に入力することで、私的 svn を github に公開しようと試みたところ、おおよそ考えられる全ての落とし穴に落ちた気がしたので、次の方は是非とも俺の屍を越えてゆけとゆいたいです。 目的 http://wota.jp/svn/rails/plugins/trunk/dsl_accessor これを github に移すのが目的 手順 github に自分のアカウントを作成する github にレポジトリを作成する 同レポジトリに既存の svn の内容を commit する あわよくば gem
優しい Merb の育て方
● [Rails][Merb] Merb とは？ Merb (Mongrel + Erb) は MVC ベースな Ruby の Web フレームワークである。簡単に言うと、軽量な ActionPack クローンである。Rails のテーマが「規約とDRY」ならば、Merbのテーマは「疑わしきものは入れない」であり、Rails の各機能を取り込みつつも、小さくて単純で簡単で軽量、そして高速であることを目指している。 特徴 コアはシンプルに (必要な機能はプラグインとして追加させる) thread safe cgi.rb を使っていない 高速な ERb エンジンである Erubis を標準装備 Rails に似ている (機能、ファイル配置) 大体3倍くらい速い (Rails Mongrel との比較) チートシート (Rails との比較) 基本的に Rails である。app 以下のディレク
MySQL 文字化け問題を本気で直す
mysql> status; -------------- mysql Ver 14.7 Distrib 4.1.20, for redhat-linux-gnu (i386) using readline 4.3 Connection id: 36 Current database: staff2006 Current user: maiha@localhost SSL: Not in use Current pager: lv Using outfile: '' Using delimiter: ; Server version: 4.1.20 Protocol version: 10 Connection: Localhost via UNIX socket Server characterset: latin1 Db characterset: latin1 Client char
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
