このエントリーは、『今まで他の言語やフレームワーク等を使ってWebアプリケーションを作っていたけど、Ruby on Railsの噂を聞きつけて始めよう』と思っている人、あるいは『既に始めたけどイマイチ良く分からないや』という人、あるいは『プロジェクトでRuby on Railsを使うことが決定したけど、ど、どうしたら(汗)』という人あたりが対象です。
【Rails入門編】
『5分で作れるとか15分で作れる系のWebの動画リソースは概要とRuby on Railsに興味を示すのには十分なんだけど、実際作ろうと思うとイチイチ停止してコマンドを打ったりしなきゃいけなかったりで面倒くさいよ~。』というあなたにはこの本。RubyやRailsのインストール、Ruby文法などのRuby入門編、フレームワークとしてのRails入門編、便利なコマンドの使い方、4時間で作るちょっと凝ったRailsアプリケーション、とこの1冊で入門編としてはバッチリ。
【Rails中級編】
『上記の本では物足りない、もっと詳しくRuby on Railsのことが知りたい!』という方にオススメな本。というかRuby on Railsの開発者のDave ThomasとDavid Heinemeier Hansson(DHH)が書いた公式本(?)なので、一人一冊は買うべきなバイブル本。
第1部:Railsのアーキテクチャの解説やインストール方法、最初のアプリケーションの構築
第2部:ショッピングサイトの構築を通してのRailsでのアジャイル開発の体験
第3部:Railsのフレームワークを基礎から詳細まで解説
という流れ。第3部では、Railsフレームワークの中枢と言える優れたO/RマッピングツールActive Recordの基礎と詳細、MVCモデルのビューとコントローラ部分であるAction Controller、Action Viewの説明にかなりのページが割かれているので、第1部、第2部を読み飛ばしても、ここを読めば実践的アプリはかけるようになるでしょう。更にアプリをより実践的に作れるようにする上で必要となる、メール操作、キャッシュ関連、セキュリティ関連、パフォーマンスとスケーラビリティ、AJAXまで、Railsでアプリを書く上で必要な情報はほとんど載っています。
【Ruby入門編】
Rubyの柔軟な言語仕様に戸惑いを覚えたならこの1冊。○○をするには××という形式で、実際使えるコードが多数載っています。リファレンスもしっかりしているので、『配列をeachで回したいけどどう書けばいいの?』みたいなときにもすぐに探せます。
Rubyレシピブック 第2版 268の技
- 作者:青木峰郎, 後藤裕蔵, 高橋征義, まつもとゆきひろ
- 出版社/メーカー:ソフトバンク クリエイティブ
- 発売日: 2007/02/01
- メディア: 単行本
というわけで、GWは引きこもってPG書きですよ。
GW明けたらスキルが1個増えてるですよ。
でも1日くらいは外に出て散歩するとステキな出会いが待ってるかもね♪
Posted by CHo at
08:17
|
コメント (0)
|
Clip!!
config/environment.rbに下記を記述する
ENV['TZ'] = 'Japan'
【参考】
・HowtoSetDefaultTimeZone
Posted by CHo at
16:24
|
コメント (0)
|
Clip!!
更新をサボり続けたあげく、突然何の前触れもなくRuby on Railsのサンプルコードを知ったかぶって載せてみるテスト。
Ruby on RailsといいつつRailsは関係なくて単にRubyのコードのようです。
1枚の画像から3種類のサイズのサムネイルを作ります。
サイズごとにファイル名の先頭に"l_","m_","s_"のプレフィックスをつけます。
横サイズは指定されたサイズ、縦サイズは元画像の縦横比率を維持して計算されます。
動作環境はWindowsでRuby,ImageMagick,RMagickが必要です。
#!/C:\ruby\bin
require 'RMagick'
# 変換テーブル
sizes = {:prefix => "l_", :size_x=>400},
{:prefix => "m_", :size_x=>200},
{:prefix => "s_", :size_x=>100}
# 変換元ファイル
in_file1 = 'C:\\temp\\cat1.jpg'
in_file2 = 'C:\\temp\\cat2.jpg'
# 出力先フォルダ
out_dir = 'C:\\temp\\'
# RMagickのインスタンスを作成
images = Magick::ImageList.new(in_file1,in_file2)
# 画像の個数分繰り返し
images.each do | image |
# 変換後画像名を時刻で決める
out_file = Time.now.to_f.to_s
# 元画像の縦横サイズを取得
image_x = image.columns.to_f
image_y = image.rows.to_f
# 変換テーブルの個数分繰り返し
sizes.each do | size |
# 変換後サイズ(横:変換テーブルの値、縦:元画像の縦横比率で計算)
image_x_min = size[:size_x]
image_y_min = (image_y/image_x * image_x_min).round
# サイズ変換して保存
image.resize!(image_x_min, image_y_min)
image.write(out_dir + size[:prefix] + out_file + '.' +image.format)
end
end
画像1個に対して複数枚のサムネイルを作るのにファイル名とサイズの対応が面倒じゃのう~って思ってたんだけど、そこはRubyという言語のすばらしさなのかシンプルに表現できた。
VBScript,VB.Net経験が長い自分にとってはこの辺が面白いところ。(しかしハマりどころでもある。カッコの使い方がわからないよ~)
個人的なポイント。
配列をこう宣言すると、
sizes = {:prefix => "l_", :size_x=>400},
{:prefix => "m_", :size_x=>200},
{:prefix => "s_", :size_x=>100}
こう使えるのね。
sizes.each do | size |
p size[:prefix] + "," + size[:size_x].to_s
end
で、出力結果:
"l_,400"
"m_,200"
"s_,100"
Posted by CHo at
15:26
|
コメント (0)
|
Clip!!
今やっているプロジェクトも終盤に差し掛かり、膨大な量のバグも優秀な人員の投入と昼夜を問わない修正を重ねた結果、文言修正を残すのみとなったこの時期、ソース類一切が入っているサーバーのディスクがぶっ飛びました。恐らく論理的なディスク障害だとは思いますが、一旦エラーが出たディスクはもう信用できず、全てを投げ出したくなる気持ちを抑えながら、最善の手を打っている最中です。こうなってくると、今日撤収をした外注会社が最後っ屁をかましたんじゃないかとか、前からイベントログにエラー出てるのを見逃してるのが原因だと誰かをしかってみたくなったり、そもそもミラーリングもしてないのかとか、2環境あるのに実ファイルもソース管理サーバーも1サーバーに集中させてるのはリスクが高かっただの、後の祭りなことばかり考えてしまいます。
とりあえずは復旧を祈るばかりです。
しかし、元々大変なのにどうしてこんな事故がおきてしまうのでしょうか。普段の行いが悪いのでしょうか。周りでも大変なことが良く起きるプロジェクトもあるし、やっぱりお祓いですかねぇ。それとも試練と思って乗り切るしかないのでしょうか。もう笑うしかない状況なので、精神的には全然平気なんですが。。
Posted by CHo at
21:24
|
コメント (3)
|
Clip!!
アリと組織と脇役の研究を読みました。80対20の法則(パレートの法則)とも絡んでいてとても興味深いです。
動いているだけ、“働いているフリ”をしているだけというアリが全体の2割はいるという。働いているアリについてもよく観察してみると、大変よく働くアリと、普通の働きのアリがいる。全体の割合を観察するとよく働くアリが2割、普通に働くアリが6割、全く働かないアリが2割という構成になるようだ。
20%のよく働くアリとその他の80%のアリの違いは何でしょうか?20%の全く働かないアリはどうして存在するのでしょうか?
次に、よく働くアリだけを一カ所に集めて、新たなアリの組織を作ってみる。すると、なぜかまた働かないアリが出てくる。よく働くアリだけの集団を何度作っても、時間がたつと自然に2:6:2の比率でアリは仕事を分担するようになる。逆に働かないアリだけの集団を作ると、さすがに作業能率は落ちるのだが、それでも働かないアリの集団の中からよく働くアリが2割ほど登場するようだ。
よく働くアリだけを集めても、全く働かないアリだけを集めても、2:6:2となるというのがすごく興味深いです。前から思っていたことですが、会社の評価が良くないのにチームに必要な人だと直感的に思える人って言うのが必ず1人はいました。そういう人は結局辞めてしまうのですが、そういう人がいなくなった現在自分が全く働かないアリになっている気がしています。役立ってない感がするというか、そういう人になったという実感はあり、働かないんであれば会社のために辞めた方がいいのかなとか思うのですが、どうなんですかね。できる人材だけでドリームチームを作っても、必ず全員が100%の力を発揮できていないと感じることも多々あり、この実験結果は大変興味があります。
全く働いてないアリの存在意義と待遇をどうするのか、考える必要がありそうですね。
Posted by CHo at
16:16
|
コメント (0)
|
Clip!!