[を] Lightweight Language Future は8月30日
いかねばです。
地元やんかー。
MSから『【PHP on IIS】Windows 環境で PHP 開発を実践する!新コンテンツ続々登場。』ってメールが来たんですが、Windows+IIS上でPHP動かすメリットってなんなんすかね。
mizzuさん
> DOMでスクレイピングしたいのですが、rubyでいいライブラリないですか?
僕は2nd lifeさんのruby のスクレイピングツールキット scrAPIを参考にこんなコードを書いてたようです。
ちょっと中身忘れてしまいましたが。
RSSをクローリングし、記事データの中からリンク先と画像のパスを取り出してDBに保存しまくる、みたいなソースの一部です。
# HTMLパース require 'scrapi'def extract_img_uri(html)
img_scrapper = Scraper.define do
process "img[src]", "uris[]"=>"@src"
result :uris
end
return img_scrapper.scrape(html,:parser => :html_parser)
end
def extract_link_uri(html)
a_href_scrapper = Scraper.define do
process "a[href]", "uris[]"=>"@href"
result :uris
end
return a_href_scrapper.scrape(html,:parser => :html_parser)
end
ねむい。。
このエントリーは、『今まで他の言語やフレームワーク等を使ってWebアプリケーションを作っていたけど、Ruby on Railsの噂を聞きつけて始めよう』と思っている人、あるいは『既に始めたけどイマイチ良く分からないや』という人、あるいは『プロジェクトでRuby on Railsを使うことが決定したけど、ど、どうしたら(汗)』という人あたりが対象です。
【Rails入門編】
『5分で作れるとか15分で作れる系のWebの動画リソースは概要とRuby on Railsに興味を示すのには十分なんだけど、実際作ろうと思うとイチイチ停止してコマンドを打ったりしなきゃいけなかったりで面倒くさいよ~。』というあなたにはこの本。RubyやRailsのインストール、Ruby文法などのRuby入門編、フレームワークとしてのRails入門編、便利なコマンドの使い方、4時間で作るちょっと凝ったRailsアプリケーション、とこの1冊で入門編としてはバッチリ。

実践 Ruby on Rails Webプログラミング入門―無駄なく迅速な開発環境
【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で回したいけどどう書けばいいの?』みたいなときにもすぐに探せます。
というわけで、GWは引きこもってPG書きですよ。
GW明けたらスキルが1個増えてるですよ。
でも1日くらいは外に出て散歩するとステキな出会いが待ってるかもね♪
#!/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
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"
今やっているプロジェクトも終盤に差し掛かり、膨大な量のバグも優秀な人員の投入と昼夜を問わない修正を重ねた結果、文言修正を残すのみとなったこの時期、ソース類一切が入っているサーバーのディスクがぶっ飛びました。恐らく論理的なディスク障害だとは思いますが、一旦エラーが出たディスクはもう信用できず、全てを投げ出したくなる気持ちを抑えながら、最善の手を打っている最中です。こうなってくると、今日撤収をした外注会社が最後っ屁をかましたんじゃないかとか、前からイベントログにエラー出てるのを見逃してるのが原因だと誰かをしかってみたくなったり、そもそもミラーリングもしてないのかとか、2環境あるのに実ファイルもソース管理サーバーも1サーバーに集中させてるのはリスクが高かっただの、後の祭りなことばかり考えてしまいます。
とりあえずは復旧を祈るばかりです。
しかし、元々大変なのにどうしてこんな事故がおきてしまうのでしょうか。普段の行いが悪いのでしょうか。周りでも大変なことが良く起きるプロジェクトもあるし、やっぱりお祓いですかねぇ。それとも試練と思って乗り切るしかないのでしょうか。もう笑うしかない状況なので、精神的には全然平気なんですが。。
アリと組織と脇役の研究を読みました。80対20の法則(パレートの法則)とも絡んでいてとても興味深いです。
動いているだけ、“働いているフリ”をしているだけというアリが全体の2割はいるという。働いているアリについてもよく観察してみると、大変よく働くアリと、普通の働きのアリがいる。全体の割合を観察するとよく働くアリが2割、普通に働くアリが6割、全く働かないアリが2割という構成になるようだ。
20%のよく働くアリとその他の80%のアリの違いは何でしょうか?20%の全く働かないアリはどうして存在するのでしょうか?
次に、よく働くアリだけを一カ所に集めて、新たなアリの組織を作ってみる。すると、なぜかまた働かないアリが出てくる。よく働くアリだけの集団を何度作っても、時間がたつと自然に2:6:2の比率でアリは仕事を分担するようになる。逆に働かないアリだけの集団を作ると、さすがに作業能率は落ちるのだが、それでも働かないアリの集団の中からよく働くアリが2割ほど登場するようだ。
よく働くアリだけを集めても、全く働かないアリだけを集めても、2:6:2となるというのがすごく興味深いです。前から思っていたことですが、会社の評価が良くないのにチームに必要な人だと直感的に思える人って言うのが必ず1人はいました。そういう人は結局辞めてしまうのですが、そういう人がいなくなった現在自分が全く働かないアリになっている気がしています。役立ってない感がするというか、そういう人になったという実感はあり、働かないんであれば会社のために辞めた方がいいのかなとか思うのですが、どうなんですかね。できる人材だけでドリームチームを作っても、必ず全員が100%の力を発揮できていないと感じることも多々あり、この実験結果は大変興味があります。
全く働いてないアリの存在意義と待遇をどうするのか、考える必要がありそうですね。