この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

rick　No24です。
今回は、Rails3のコマンドを簡単に紹介。

環境

ruby 1.9.3
rails 3.0.7

アプリ作成

rails2まで
$ rails hoge
rails3から
$ rails new hoge

コントローラー等作成

rails2まで
$ ruby script/generate controller hoge index
rails3から
$ rails generate controller hoge index

migrate

rails2まで
$ rake db:migrate
rails3から
$ rake db:migrate
変化なし

サーバ起動

rails2まで
$ ruby script/server
rails3から
$ rails s

コンソール

rails2まで
$ ruby script/console
rails3から
rails c

その他

$ bundle install
Gemfileの中身をinstallします。
installした内容は
$ bundle exec list
で確認完了
実行するときは
$ bundel exec rails s
このように先頭に「bundle exec」を付けてください。

前はrailsコマンドでアプリ作成だったので今回から
railsコマンドはサーバ起動とかあるためなんだか違和感ありますが、
慣れるしかないですね。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

昨今、様々なサービスが展開されているが、サービスを利用するに当たり、利用規約が掲げられている。今回は、利用規約のなかから「あれ？」と思わせるような内容をいくつか、ピックアップしてみよう。

■ どこからか持ってきた規約

いくつかの規約で、共通する文言を目にする事がある。そういった文言を、googleに入れ検索すると、大量に同じような規約が登場する。当然、元の規約*1があるわけだが、それを探そうにも、どれがマスターだったのか解らない状況に。

■ 電気通信事業法？

SNSの利用規約に見られるモノとして、[電気通信事業法（昭和59年法律第86号）第４条に基づき，利用者の通信の秘密を守る]と書かれたモノがあるが、そもそも、電気通信事業法は、「電気通信事業者」に対する法律であり、電気通信事業者を取得していない者は関係ない法律だ。

電気通信事業者では無いにもかかわらず、こうした事を掲げる場合、詐称もしくは詐欺行為と見なされる場合がある。注意が必要だ。

■ 電気通信事業者？

もうひとつの問題もある。それは、何らかの利益を得ての役務が発生している場合だ。

通常、電気通信事業者は、第三者を経由する通信を「有償」で提供している場合に取得する必要のある資格だ。友達から施設負担金として、月額数百円レベルでお金をもらっていても、この資格は必要であるし、また、アフィリエイトなどの広告を掲載している場合も、同様の資格が必要となる。当然として、出会い系サイトなどを運営する場合も、同様の資格が必要となる。過去の事例としては、国内のみにサービス提供しているゲームで、海外の利用者を、国内のproxy経由でアクセスできるようにしていた、中国人留学生が検挙されたが、これも、きっかけは電気通信事業者の資格を有していなかった事に端を発している。こうしたサービスを提供する際には、電気通信事業者の資格取得を、忘れないよう、注意されたい。

■ インターネットの仕組みを理解していない

[サービスに関わる記載について，無断でそのコピー，複製，アップロード，掲示，伝送又は配布等をする行為]と書かれたモノを多く見る。が、コンピュータやインターネットでは、多くの情報を「常に複製」し、画面に表示したり音にしている。たとえ、マウスやキーボードで入力したデータであったとしても、メモリやCPU、その他のIOデバイスを経由するなかで「すべて複製」したものであり、どれ一つとして「オリジナル」と呼べるモノは無い。そういった中で、こうした規約は「あぁ、コンピュータやインターネットの仕組みを理解していないんだな」と、考えざるを得ない。本来、こうした規約は、本や雑誌などの物理内容について、作られたモノと推測されるが、そのまま、ネットのサービス規約に持ってくるのが、そもそも間違いと言えよう。

*1: 規約そのものに対しては著作権法の適用対象外なので、複製しても問題は無い

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

rails 3.1ではJavaScriptのランタイムが必要になります。

今回はCentOS6にnode.jsを入れて対応してみます。

標準でRails3.1をインストールするとassetsという仕組みでCoffeeScriptが利用されることになります。

そのため、JavaScriptのランタイムがないと起動できません。

$ rails s -p 5001
/usr/local/lib/ruby/gems/1.9.1/gems/execjs-1.2.9/lib/execjs/runtimes.rb:47
:in `autodetect': Could not find a JavaScript runtime. 
See https://github.com/sstephenson/execjs 
for a list of available runtimes. (ExecJS::RuntimeUnavailable)
(以下略)

実際、Gemfileに指定されているcoffee-railsは以下のような依存関係があります。

$ gem dependency coffee-rails
Gem coffee-rails-3.1.1
  coffee-script (>= 2.2.0)
  railties (~> 3.1.0)

$ gem dependency coffee-script
Gem coffee-script-2.2.0
  coffee-script-source (>= 0)
  execjs (>= 0)

では、この依存関係をクリアするようにCentOS上でnode.jsをインストールしましょう。

ただし、普通にソースコードから入れてしまうと管理のコストが上がってしまい非常にSAN値が削られてしまうので、Redhat系OSらしくrpmでインストールしましょう。

運がいいことに、kazuhisyaさんがspecファイルを公開しているので、こちらを利用します。

ちなみに、ruby1.9をインストールしたときにだいたい依存関係クリアしていたっぽいので、ビルドで落ちたら依存関係を確認してください。(yum-builddepとか使ったことないので…)

$ mkdir -p ~/rpmbuild/SOURCES/
$ cd ~/rpmbuild/SOURCES/
$ wget http://nodejs.org/dist/v0.6.5/node-v0.6.5.tar.gz
$ cd
$ git clone https://github.com/kazuhisya/nodejs-rpm.git
$ cd nodejs-rpm/
$ git checkout -b v0.6.5 v0.6.5
$ rpmbuild -bb nodejs.spec
$ sudo rpm -ivh ~/rpmbuild/RPMS/x86_64/nodejs-0.6.5-1.el6.x86_64.rpm

これでnode.jsのインストールが完了しました。

あとはサーバを起動してみましょう。

$ rails s -p 5001=> Booting WEBrick
=> Rails 3.1.3 application starting in development on http://0.0.0.0:5001
=> Call with -d to detach
=> Ctrl-C to shutdown server

無事成功しました。

大変有益なspecファイルを公開してくれたkazuhisyaさん、ありがとうございます！今度おごってください！

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

昨今、ソーシャルメディアを使った様々なサービスがあるが、今回はソーシャルメディアを使うことによるメリットとデメリット（リスク）について考えてみたいと思う。

■ ソーシャルメディアを企業が利用するメリット

今、Twitterやmixi、facebookなどといった、様々なソーシャルメディアが存在する。このソーシャルメディアを用いた、各種割引クーポンサービスや、ソーシャルゲーム*1などの情報提供サイトが多数存在している。これらの情報提供サイトは、従来のサイトと異なり、極めて少ないコストで広告を提供している。これは、利用者が告知することにより、利用していない人に対しても、告知が広がるためであり、企業は多くの友人や知人を持つユーザに対し、情報を提供するだけでよく、従来の広告モデルより安価に広告費を減らすことが出来る。

■ ユーザがソーシャルメディアを利用するメリット

一方、ユーザはソーシャルメディアを利用することで、１０数年ぶりに友人とソーシャルメディア上で再会したり、遠くにいる人とチャットで情報交換する等のメリットが有る。また、企業が提供する各種クーポン等を安価に手に入れることができ、今までとは違った情報の入手ルートを開拓することが出来る。他者の書いた記事を読むことで、今まで思いもしなかった様な情報を定入れたり、他者の意見交換をすることで、新たな考え方を共有することが出来る。

■ ユーザがソーシャルメディアを利用することのリスク

こうした情報交換をすることで、様々な情報を手に入れられる一方、自ら発信する情報には気をつける必要がある。自分を見つけやすくするために、出身校や住んでいる地域、スカイプIDやメールアドレス等といった情報を公開することが有る。こうした行為は、自分を見つけ出しやすくするだけではなく、攻撃者により多くの情報を与えることになり、結果としてなりすましメールや標的型メールが送りつけられる事になりかねない。

■ 標的型攻撃のシナリオ

たとえば、◎◎銀行に勤めるA氏にターゲットを絞ったと仮定する。普通に、A氏に対して標的型メールを送ったとしても、開いてもらうことさえままならないだろう。そこで、登場するのがソーシャルメディアだ。まず、A氏のアカウントを調べることから始める。Facebookでは、本名を書くことが規約に書かれているため、A氏にたどり着くことは容易いだろう。A氏のアカウントを見つけたら、A氏と親しく会話している人を数名見つけよう。ここで、重要なのは見つけるのは複数人であることだ。一人しか見つからなかった場合、ソーシャルメディアを用いた攻撃は諦めたほうが良い。

A氏と親しい人を数名見つけたら、次にその人を含む多くの人たちと、友人になろう。その時、決して素性をばらすようなことはやめることだ。自然にダミーデータを散りばめ、決して本名や個人情報を晒さないようにする。万一、疑われても本人に警察の魔の手が及ばないようにする。A氏に近づくために、A氏と親しい友人たちと知り合いという「担保」を用い、A氏に友人申請をしよう。A氏がよほど疑り深い人で無い限り、A氏の知ってる「友人たちも知ってる」という「担保」によって、A氏は容易に攻撃者からの申請を受け入れるはずだ。

もし、A氏の親しい知人が一人しかいなかった場合、A氏は攻撃者からの申請を疑ったかもしれないし、その親しい知人に、問い合わせていたかもしれない。

A氏の友人として、まんまと潜り込めたら、次はA氏と全く関係のない人たちに、どんどん友人関係を築き、多くの人と友人関係にあることをA氏にそれとなく、アピールしよう。こうすれば、自分を狙っているようには思わないだろう。

A氏と友人たちの、ウォールでの会話は、攻撃者も見ることができるだろう。この会話をよく読み、今何を会話しているのか。それぞれ、共通の興味を調べておこう。その時、会話に登場する友人の個人情報も調べておくことを忘れないでほしい。共通の話題や趣味、個人情報をある程度把握したら、友人になりすまして、A氏にメールを送る。その時の文面はこうだ

「先日、Facebookで話したゲームだけど、新しい情報見つけたよ。よかったら見て、Facebookで感想を送って」と。

メールに添付するURLは、ながければ長いほどよい。下手に短縮URLを使うと、Facebookやツイッターじゃないのになぜ？と、不審がられるだろう。

そのURLに、標的型ウィルスを仕込んでおけば、そのサイトをクリックした瞬間にウィルスの餌食になる。単純なアンチウィルスでは、感染したウィルスのシグニチャを持っていないため、駆除することはできない。もちろん、Facebookで偽装した本物の友人に確認しても、後の祭りだ。

実際には、こんなに簡単に標的型ウィルスを感染させることは難しいだろうが、時を重ねて会話の内容をほぼすべて把握すれば、こうしたことも難しくないかもしれない。

■ 現在地を示すソーシャルアプリ

今、ソーシャルメディアは多様化しており、現在地を示すツールも、ロケタッチや4sqなど多数存在する。現在地を示し、待ち合わせをするには、十分だと思うが、そこに居るということは、他の場所（例えば自宅や会社など）にはいないということになる。一人暮らしの場合、それをツイッターやFacebookなどで他人に対してまで公開することは、空き巣に入って欲しいと言っているようなものだ。こうしたツールを使うなら、相手を限定し、決して第三者に情報を開示しないことだ。

ソーシャルメディアで、なりすましを避けるには、一番良いのはソーシャルメディアを使わないことだが、どうしても使いたい場合は、明らかに個人を特定しうる以上の情報を提供しないことだ。顔写真や本名、連絡先、電話番号など多彩になればなるほど、攻撃者からも特定され安くなることを肝に銘じてほしい。また、自分が知らないけど、共通の知人がいる人から友人登録の申し込みがあった場合、そのまま登録するのではなく、共通の知人の中でも「リアルに連絡先を知っている知人」に連絡を複数取り、「この人ってどんなひと？」と聞くのが確実だろう。もし、「よく知らないんだけど」や「ネットで最近知ってね」という人が、複数出た場合は、要注意として、ペンディグしたほうが良いだろう。承認はあとでもできるし、場合によっては、そのまま無視することも出来る。一度、友人登録を許可してしまったら、登録解除まで、情報が流れてしまうことを理解しておこう。多くの情報を集約し、巨大化するソーシャルメディア。実際に使うときは、十分情報管理には注意したほうが良いだろう。

*1: 弊社も提供している

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

Android開発者が必要なのがどれなのか破滅的にわかりづらいのでとりあえずソートしてみた。

JPCERT/CCがCERT Oracle Java セキュアコーディングスタンダード 日本語版を公開しております。

その中で、Androidアプリケーション開発へのルールの適用という項目があるのですが、順番が項目順で破滅的に分かりづらいので、Android開発でガリガリ下がりまくったSAN値を回復するためにソートしなおしてrubyでリンクもつけて見ました。

以下が、その表になります。リンク間違ってたらTwitterのsmellmanに適当にMention送ってください。

作成は、エクセルにコピペしてCSV作成してnkfかましたあとのファイルをこんなスクリプトでサクッと。出力は安心のはてな記法です。

require 'csv'

open("jpcertlist_utf8.csv") do |file|
  file.each_with_index do |aline, idx|
    line = CSV.parse_line(aline)
    if idx == 0
      puts "|*#{line[0].to_s.strip}|*#{line[1].to_s.strip}|*#{line[2].to_s.strip}|"
    else
      url = "https://www.jpcert.or.jp/java-rules/" + line[0].strip.downcase + ".html"
      puts "|[#{url}:title=#{line[0].to_s.strip}]|#{line[1].to_s.strip}|#{line[2].to_s.strip}|"
    end
  end
end

しかし、SJISですらSAN値下がりますね>エクセル

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

　yoppiです。今回はRubyでAmazon S3のマルチパートアップロードを行う方法を紹介させていただこうと思います。

　Amazon S3のストレージシステムをAPIで利用する場合、ファイルアップロードを1回のリクエストで行うことは、ファイルのサイズが大きくなるにつれて失敗の確率が大きくなります。

　そのリスクを回避するための機能がマルチパートアップロードです。詳細は下記のリンクを参照していただくことにして、簡単に説明するとファイルを小分けにして、複数回のリクエストでアップロードできるというものです。

【AWS発表】 Amazon S3において大容量ファイルを分割アップロード可能にするマルチパートアップロード機能(Multipart Upload)の発表 – Amazon Web Services ブログ

　便利である分、APIの仕様が複雑になっているのですが、Ruby用のSDKでは(他の言語用も多分そうでしょうが)難しい仕様は隠ぺいする形で実装されているので、便利な機能が簡単に使えるようになっています。

　SDKはgemで提供されているので、簡単に導入できます。

gem install aws-sdk 

　以下に利用例のコードを紹介します。

require 'aws-sdk'
AWS.config(
  :access_key_id => 'YOUR_ACCESS_KEY_ID',
  :secret_access_key => 'YOUR_SECRET_ACCESS_KEY')

file_path_for_multipart_upload = 'SOME_FILE_PATH'

#前もってSOME_BUCKET_NAMEという名前のバケットを作成する必要がある
bucket = AWS::S3.new.buckets['SOME_BUCKET_NAME']

open(file_path_for_multipart_upload) do |file|
  uploading_object = bucket.objects[File.basename(file.path)]
  uploading_object.multipart_upload do |upload|
    while !file.eof?
      upload.add_part(file.read 10.megabytes) 
      p('Aborted') if upload.aborted?
    end
  end
end

　AWS::S3::S3Objectのインスタンスを生成し、multipart_uploadに引数1つのブロックを渡し実行します。

　渡したブロックの引数にAWS::S3::MultipartUploadのインスタンスが渡されるので、それのadd_partに小分けにしたファイルの内容を渡す。

　大まかには以上のようになります。

　マルチパートアップロードでも失敗する場合はあり、それはAWS::S3::MultipartUploadのインスタンスのaborted?で判別でき、その値を元に再送など必要な処理を実装することができます。

　Amazon S3を使うRubyシステムを扱う場合、大きなファイルのアップロード処理が必要になることもあると思います。

　その時に是非この内容を参考に指定ただければと思います。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

Mac OS X LionでWiresharkを動かすと起動しない自体が頻発しますが、変な方法で動くようになったので報告します。

Mac OS X Lionがリリースされてはや数ヶ月立ちますが、様々なソフトが死んだりして正しい生存戦略ができない自体になりかねない状況です。

エンジニアにとって必須ソフト、Wiresharkも同じように荒ぶるLionによって惨殺される自体になっていますが、よくわからないけど動くようにできたので報告します。

Wiresharkでは一般権限で動かすときに、 /dev/bpf* の所有者を変更してあげる必要があります。ただし、現在のMacPortsのバージョンでは一般権限でなぜかセグってしまい死んでしまう状態になっています。

bash-3.2$ wireshark
Segmentation fault: 11

そこでroot権限で動かすのですが、なぜかWiresharkがそのまま終了するという状態になったりします。

bash-3.2$ sudo wireshark
(そのまま死亡)

そこで、一旦所有者を変更してみました。

bash-3.2$ ls -lh /dev/bpf*
crw-------  1 tmatsuzawa  admin   23,   0 Oct 25 10:10 /dev/bpf0
crw-------  1 tmatsuzawa  admin   23,   1 Oct 25 10:10 /dev/bpf1
crw-------  1 tmatsuzawa  admin   23,   2 Oct 25 10:10 /dev/bpf2
crw-------  1 tmatsuzawa  admin   23,   3 Oct 25 10:10 /dev/bpf3
bash-3.2$ sudo chown tmatsuzawa:admin /dev/bpf*
bash-3.2$ sudo wireshark

すると今度は起動するようになりました。

で、一旦終了してから再度起動をします。すると今度は死にます。

bash-3.2$ sudo wireshark
(そのまま死亡)

おかしいと思って、元の所有者に戻してみました。

bash-3.2$ ls -lh /dev/bpf*
crw-------  1 tmatsuzawa  admin   23,   0 Oct 25 10:10 /dev/bpf0
crw-------  1 tmatsuzawa  admin   23,   1 Oct 25 10:10 /dev/bpf1
crw-------  1 tmatsuzawa  admin   23,   2 Oct 25 10:10 /dev/bpf2
crw-------  1 tmatsuzawa  admin   23,   3 Oct 25 10:10 /dev/bpf3
bash-3.2$ sudo chown root:wheel /dev/bpf*
bash-3.2$ sudo wireshark

今度は正常に動きます。そして、再度起動すると動かないという状態になります。

まとめると、Wiresharkを起動する場合は、一度 /dev/bpf* の所有者を変更すると動くようです。

たぶん、短期的なバグだと思われますが、とりあえず生存戦略を遂行するためにはこのような対策をしていただく必要があるみたいです。

本家への報告は時間があれば…

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

railsプロジェクトで、外部サイトへデータをpostする時、パラメータの生成にhttpの「set_form_data」メソッドをお勧めします。railsプロジェクトで、外部サイトへデータをpostする時、パラメータの生成にhttpの「set_form_data」メソッドをお勧めします。

このメソッドをお勧めする理由は特殊文字（「&」、「” “」、「”/”」など）がパラメータの値に入る時、うまくエンコードできるのです。

例、
URI.encode⇒ “&”（&）
CGI.escape⇒” ”（+）
URI.escape ⇒ “&”（&）
ERB::Util.u(s)はうまくできると思います。

httpのset_form_dataの元ソースを見てみしょう。
/usr/local/lib/ruby/1.8/net/http.rb（rubyのインストールパスによりパスが変わる可能性がある）の
1432～ 1441行目前後
  def set_form_data(params, sep = ‘&’)
    self.body = params.map {|k,v| “#{urlencode(k.to_s)}=#{urlencode(v.to_s)}” }.join(sep)
    self.content_type = ‘application/x-www-form-urlencoded’
  end

  def urlencode(str)
    str.gsub(/[^a-zA-Z0-9_\.\-]/n) {|s| sprintf(‘%%%02x’, s[0]) }
  end

使用方法は
98～ 109行目を確認
パラメータのキーと値をハッシュで渡せば、結構です。
  #3: Detailed control
  url = URI.parse(‘http://www.example.com/todo.cgi’)
  req = Net::HTTP::Post.new(url.path)
  req.basic_auth ‘jack’, ‘pass’
  req.set_form_data({‘from’=>’2005-01-01’, ‘to’=>’2005-03-31’}, ‘;’)
  res = Net::HTTP.new(url.host, url.port).start {|http| http.request(req) }
    case res
    when Net::HTTPSuccess, Net::HTTPRedirection
      # OK
    else
      res.error!
    end

よろしくお願いします。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

最近防衛産業でにわかに流行り始めてると言われる、標的型攻撃だが、実際には４年以上前から、こうした攻撃が観測されており、ようやく、そういう事が発生していると、報道がされたに過ぎない。

今から５年ほど前、某所で行ったハンズオンセミナーでは、三菱重工業が受けたような標的型攻撃の可能性について、指摘を行い、また、事前に入手してあった

admin権限を必要とするアクセス権への攻撃

を繰り返す、コンセプト型ウィルスもいくつか紹介し、その挙動についてハンズオンセミナーで紹介している。

その時紹介したいくつかのコンセプト型ウィルスは、後のコンフリッカーと呼ばれるウイルスになったり、今回の様な標的型攻撃に利用されている。

私たちが観測している標的型攻撃に利用されそうなコンセプト型ウイルスは、巧妙に姿を隠し、通常の状態では発見されない状況になった。

完全に、地下に潜ったかの様に見える。ウイルスは、PCに設定されているDNSを参照せず、ウイルスが他のDNSを参照している。この通信は、他のクライアント（例えば、IE）が通信しているとき、それに乗じて、https通信を行う。実際に通信しているのは、暗号化されたDNSクエリーであり、内容を解読*1しても、webコンテンツが流れているわけではない。

また、活動時間も、ユーザが利用していないアイドル時間に、通信以外の行動を行い、ユーザがネットを利用している間に、通信を行い、ユーザに気づかせない対策を行なっている。

こうした、状況を踏まえ、標的型攻撃の対策を行うべきであり、弊社では、それを踏まえた対策セミナーを考えている。現在検討しているセミナーは以下のとおり

1. 標的型メールの最新動向の把握とメール送信事故等の防止対策セミナー
2. システム管理者向け　標的型攻撃対策ハンズオンセミナー（３日間コース）

1は、企業や事業部、部署毎に実施するもので、教育フェイズと訓練から構成されており、繰り返し訓練を行うことで、ひとりひとりに自覚させ、標的型メールを踏みにくい耐性をつくることを主軸に考えている。

2は、上記訓練を繰り返し行なったとしても、一定割合で踏んでしまう社員が居る統計がある。

このため、「実際の標的型メールを改良」した物を複数種類用いたり、実際に攻撃が行われた際に記録されたログを用い、実際に何が起きるのかを、体験していただき、どのような対策を行うかを理解して頂ける、セミナーである。

それぞれの対策セミナーは、開催決定次第、都度、http://security.kbmj.com/ にて公開する。

*1: SSL通信は、暗号解読の方法が幾つかある

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

こんにちは。KBMJの本多です。

今回はサーバーのSSL証明書の更新時にたまに陥る問題と、それを解決する際に役立った情報を紹介したいと思います。

先日、とあるPC/携帯向けサイトの話にてSSL証明書を更新後、携帯端末で参照できなくなる問題が発生しました。
原因は用意したサーバー証明書と中間証明書の組み合わせが間違っているためでした。

PCブラウザでは中間証明書が間違っていてもブラウザ側で補完してくれるためエラーが出ないらしいのですが、
携帯端末ではそういうわけにはいかず、サイトにアクセスするとエラーが出ます。

最近はクロスルート証明書が登場した事で、サーバー証明書の種類によって設定方法が複雑化したりしていますが、
そもそも発行されたサーバー証明書はどの中間証明書を使うのが正しいか？それを確認しないことには始まりません。

本日は、発行されたサーバー証明書と中間証明書の中身を確認し、正しい組み合わせである事を調べる方法を紹介したいと思います。

ファイルの準備

windows環境にて、用意したサーバー証明書及び中間証明書を拡張子cerというファイルで保存します。
拡張子cerで保存したファイルをダブルクリックする事で、証明書の中身を参照する事が出来るようになります。

サーバー証明書の中身を確認

発行先：サイトのドメイン名
　いきなりここが違った場合はもうそれは別のサーバー証明書です。証明書を発行した人に確認しましょう。

発行者：SSL証明書の発行会社、及び証明書の形式情報
　ここに何が書かれてるかを覚えておきましょう。

有効期限
　期間が更新されていることを確認しましょう。

中間証明書の中身を確認

発行先：サーバー証明書の「発行者」と同じ
　先ほど確認したサーバー証明書の発行者と照らし合わせましょう。
今回は、ここが異なっていたため、適用後に不具合が発生しました。

中間証明書が間違っていた場合については、証明書を発行した会社のサイトからダウンロードできますので
サーバー証明書の「発行者」を元に、正しい中間証明書を取得しましょう。

あとはapacheに正しく設定すれば、携帯端末でもSSLのページが参照できるようになります。

SSL証明書の更新時に躓くパターンといえば、クロスルート証明書を絡めた中間証明書の設定部分が上手くできていない場合が多いイメージがありますが、たまにこういうパターンの落とし穴もあります。
更新する際には、一度中身を確認してみるとトラブル回避につながるかもしれません。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

KBMJのコジです。

ここ3カ月技術に関わっていないので、今年2011年6月に受験して合格したデータベーススぺシャリストの試験対策について書きます。

10年ぶりの受験だったので、当然午前Ⅰの免除はなく、勉強に5か月費やしました。

まぁ、一日の勉強時間は通勤の1時間半程度ですが(土日は除く)。

使用した図書は以下の3冊です。

・翔泳社 高度試験午前Ⅰ・Ⅱ

　→暗記量は多いが自分の受験範囲をやれば確実に突破可能。

・翔泳社 情報処理教科書 データベーススペシャリスト

　→他の参考書より優れていると思わないが、過去問9年分付きが素晴らしい。

・リックテレコム データベース午後徹底演習(古本)

　→上記参考書の説明不足を補う為に使用。あと、過去問に入る前の肩慣らしにもなる。

午前Ⅰがあると、とにかく暗記する量が半端ないので、

中学生以来に単語帳を使用し、3ヵ月かけました。

残り2ヵ月は過去問ですね。

翔泳社の参考書は9年分の過去問が付いているので、5年分やりました。

ここで厄介なのが、午後Ⅱ。

2問中1問選択し120分の問題なので、

2問とも解いて、採点・見直しも実施すると6時間位かかります。

過去問で土日をどれだけ無駄にしたか…

過去問を進めるにつれ、合格ラインの採点が続くようになり

自信満々で試験当日を迎えたわけですが、

午後Ⅱで選択した問2の記述量が過去最大級で

回答を7～8割しか埋められず不安のまま合格発表を迎えました。

結果、見事1発でギリギリ合格した訳ですが、

午後Ⅱは合格率を一定にするため、得点調整があるとの噂があります。

なので、とにかく回答を埋めるように頑張って下さい。

最後に、個人的に発見した小さな裏技を１つ。

試験開始までは問題冊子を開いてはいけません。

が!

解答冊子は開いてもいいんです。

なので、試験開始までボーっとせずに回答欄から問題を予想し、

午後Ⅰ・Ⅱの設問選択時間を少しでも省略することをお勧めします。

(問題冊子を開いてると勘違いされる可能性もあるので自己責任で)

では、これから受験される方のご検討を祈っております。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

Ruby on Railsにて、外部からアクセスした際にもエラー画面を見れるようにしてみた

この記事は公開から１年以上が経過しています。情報が古い可能性がありますのでご注意ください。こんにちは。KBMJの本多です。

今回は実際にリリースされたプロジェクト等でアプリケーションエラーが発生した際に、開発時のようなエラーメッセージを見るための方法を紹介したいと思います。基本的に、RoRのproductionモードでは、アプリケーションエラーが発生するとlocalhost以外から接続時には
#{RAILS_ROOT}/public/500.html
を返す仕組みになっています。

これを回避する主な方法は２通りあります。

１．productionモードの設定を変更して、アプリケーションエラー時にメッセージが見れるようにする

※Rails2系及びRails3系で利用可能

#{RAILS_ROOT}/config/environments/production.rb 内の以下の行を変更
config.action_controller.consider_all_requests_local = false
↓
config.action_controller.consider_all_requests_local = true

これにより、developmentモードと同様に、外部からのアクセスでもエラーメッセージをブラウザ上に表示するようになります。

が…絶対にやってはいけません！

基本的にエラーメッセージを不特定多数の利用者の目に触れるような状態にするのはセキュリティ上非常によろしくないです。
たまにRoRではない別の言語・システムで構築されたサイトにてナマのエラーメッセージを見たことがありますが、ファイルパスやSQL等の情報が漏れる原因になるため、この方法を利用する事はやめましょう…。

一応、（物理的には）可能な方法だったので、紹介しておきました。

２．エラー発生時に特定のIPアドレス（例えば開発会社のグローバルIP）をlocalhostと「誤認」させる事で、エラーメッセージを表示するように設定する

※Rails2系で利用可能

今回紹介する方法はこちらです。
RoRの内部にて、エラー発生時の処理を”local_request?”というメソッドで判定して処理を切り替えている部分があるので、
local_request?の中身を書き換える事で、特定のIPアドレスをlocalhostであるかのように振る舞うようになります。

local_request?の元ソース（Rails 2.3.10から抜粋）は以下の通りです。

LOCALHOST = [/^127\.0\.0\.\d{1,3}$/, /^::1$/, /^0:0:0:0:0:0:0:1(%.*)?$/].freeze
（中略）
# True if the request came from localhost, 127.0.0.1. Override this
# method if you wish to redefine the meaning of a local request to
# include remote IP addresses or other criteria.
def local_request? #:doc:
  LOCALHOST.any?{ |local_ip| request.remote_addr =~ local_ip && request.remote_ip =~ local_ip }
end

これをapplication_controller.rb内にて以下のように記述する事で、指定のIPアドレスでのみエラーメッセージを見れるようになります。

private
def local_request?
  [“127.0.0.1”, “（対象のIPアドレス）”].include?(request.remote_ip)
end

これにより、開発時と同様にログから追いかけるエラーメッセージをブラウザから参照できるようになり、
不具合発生時の対応が比較的楽になると思います。

残念ながらRails3系では仕様が変わって使えなくなりましたが、まだRails2系が使われているプロジェクトが多いと思いますので、是非ご活用ください。

GOOD RAILS!!

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

rickNo23です。
今回はjQueryのプラグインGoogleChartsを使って簡単にグラフを表示する方法を紹介します。

環境

jquery1.4.2
jgcharts.js.0.9.7

Download

本家

ソース

< script type=”text/javascript” src=”http://search.kbmj.com/javascripts/jquery-1.4.2.min.js” 　 >< /script >
< script tyep=”text/javascript” src=”http://rikiya.sakura.ne.jp/jQuery/jgcharts/jgcharts.js” >< /script >

< script language=”JavaScript” >< !–
　　jQuery(function(){
　　　　var api = new jGCharts.Api();
　　　　jQuery(‘< img >’).attr(‘src’, api.make({data : [[153, 60, 52], [113, 70, 60], [120, 80, 40]]})).appendTo(“#bar1”);
　　})
//– >< /script >
< div id=”bar1″ >< /div >

解説

まずはjqueryの読み込みでjquery-1.4.2.min.jsを参照
次にGoogleChartsの読み込みでjgcharts.jsを参照
var api = new jGCharts.Api();
で初期化
jQuery(‘< img >’).attr(‘src’, api.make({data : [[153, 60, 52], [113, 70, 60], [120, 80, 40]]})).appendTo(“#bar1”);
でデータを送信して画像を取得し、divのbar1へ出力しています。

オプション

本家を見てもらうと分かる通りグラフには様々な種類があります。
api.makeの中で
type : ??
とすることで別の種類のグラフに変わります。
例えばtype : ‘bhs’などにすると帯グラフに変化します。
また、画像サイズには制限がかけられておりmaximum size 300,000 pixelsとなっています。
サイズの変更は
size : ‘??x??’
で変更できます。
他にも様々なオプションがありますので、興味があったら本家を見てみてください。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

先日、apacheの脆弱性が公開された。この脆弱性は、既存の全バージョンで確認され、「緊急」扱いとなっている。

今回は、この脆弱性が如何に危険な存在であるか、検証してみよう。

今回見つかった脆弱性は、と呼ばれるもので、ざっくりと言ってしまえば、サービス拒否攻撃の類だ。サービス拒否攻撃には、いくつかの手法があり、

1. 帯域圧迫型
2. socket飽和型
3. CPU占有型
4. メモリ圧迫型

の４種類に大別することが出来る。このうち、1は一般的にはDDoS攻撃と呼ばれるもので、古くは「田代砲」と呼ばれる攻撃ツールもあった。2は、1と似ているが、大した帯域を使わず、大量にセッションを張るだけ張り、持続させて、相手のsocketを食いつぶす。syn floodやack flood攻撃もこの種になる。

3は、CGIを呼び出す部分のみを、高速に外部から呼び出し、CGIに費やす負荷を極限まで上げる方法だ。4は、ファイル転送を行う際に、大量かつ大容量のデータを転送することで、内部メモリを飽和させる方法だ。

今回見つかった脆弱性は、3と4を合わせ持つ強力なものだ。通常３や４を実行する場合、攻撃側もそれ相応の機材やネットワークを必要とし、botネットを用いることが一般的だ。しかし、今回の脆弱性を検証するために用いられたツールは、わずか8000バイト弱のデータを、１つのhttpリクエストにしたため、接続しているだけだ。

通信内容は、次のようになっている

HEAD / HTTP/1.1

Host: 192.168.2.113

Range:bytes=0-,5-0,5-1,5-2,5-3,5-4,5-5,5-6,5-7,5-8,5-9,5-10,5-11,5-12,5-13,5-14,5-15,5-16,5-17,5-18,5-19,5-20,5-21,5-22,5-23,5-24,5-25,5-26,5-27,5-28,5-29,5-30,5-31,5-32,5-33,5-34,5-35,5-36,5-37,5-38,5-39,5-40,5-41,5-42,5-43,5-44,5-45,5-46,5-47,5-48,5-49,5-50,5-51,5-52,5-53,5-54,5-55,5-56,5-57,5-58,5-59,5-60,5-61,5-62,5-63,5-64,5-65,5-66,5-67,5-68,5-69,5-70,5-71,5-72,5-73,5-74,5-75,5-76,5-77,5-78,5-79,5-80,5-81,5-82,5-83,5-84,5-85,5-86,5-87,5-88,5-89,5-90,5-91,5-92,5-93,5-94,5-95,5-96,5-97,5-98,5-99,5-100,5-101,5-102,5-103,5-104,5-105,5-106,5-107,5-108,5-109,5-110,5-111,5-112,5-113,5-114,5-115,5-116,5-117,5-118,5-119,5-120,5-121,5-122,5-123,5-124,5-125,5-126,5-127,5-128,5-129,5-130,5-131,5-132,5-133,5-134,5-135,5-136,5-137,5-138,5-139,5-140,5-141,5-142,5-143,5-144,5-145,5-146,5-147,5-148,5-149,5-150,5-151,5-152,5-153,5-154,5-155,5-156,5-157,5-158,5-159,5-160,5-161,5-162,5-163,5-164,5-165,5-166,5-167,5-168,5-169,5-170,5-171,5-172　以下略

こう言った攻撃コードを、1回の通信で行っている。

ここで注目すべきは、「Range:bytes=」だ。

このRangeは、データを分割する際に用いる方法

だ。つまり、大量のデータがある場合、そのデータをいくつかに分割し、転送することを要求している。5-6 5-7 と言ったように、特定のバイトからバイトまでを分割して転送要求を行う。5-0 バイトから5-1299バイトまでを、1バイトづつ増やしながら、同じものを含め、再度転送することを要求する。この要求を受けたターゲットは、その要求に従い、律儀に転送しようと試みる。

これを受け取ったサーバは、下記に示すように、要求された分だけ、apacheの接続を受け止めようとする。

見てわかるように、この時点でload average は、40を越えている。通常のサーバではありえない現象だ。

この時の通信ログは

192.168.3.26 – – [01/Sep/2011:10:20:37 +0900] “HEAD / HTTP/1.1” 206 354 “-” “-“

192.168.3.26 – – [01/Sep/2011:10:20:37 +0900] “HEAD / HTTP/1.1” 206 354 “-” “-“

192.168.3.26 – – [01/Sep/2011:10:20:37 +0900] “HEAD / HTTP/1.1” 206 354 “-” “-“

192.168.3.26 – – [01/Sep/2011:10:20:37 +0900] “HEAD / HTTP/1.1” 206 354 “-” “-“

192.168.3.26 – – [01/Sep/2011:10:20:37 +0900] “HEAD / HTTP/1.1” 206 354 “-” “-“

192.168.3.26 – – [01/Sep/2011:10:20:37 +0900] “HEAD / HTTP/1.1” 206 354 “-” “-“

192.168.3.26 – – [01/Sep/2011:10:20:37 +0900] “HEAD / HTTP/1.1” 206 354 “-” “-“

192.168.3.26 – – [01/Sep/2011:10:20:37 +0900] “HEAD / HTTP/1.1” 206 354 “-” “-“

192.168.3.26 – – [01/Sep/2011:10:20:37 +0900] “HEAD / HTTP/1.1” 206 354 “-” “-“

となっており、先程の様な、Range:bytes=は含まれていない。

この状況が続くとどうなるのか、状況を見てみよう。

waが97%を示していることがわかるだろうか。これは、IO Wait と呼ばれるもので、通信ではなくIO系の処理にそれだけのwaitが発生していることを示す。

この数値が大きければ、大きいほどシステムの反応速度は落ち、ファイルの書き込みや様々な応答速度は悪くなる。

webブラウザで接続した際、クルクルとレインボウカーソルが発生し、何時まで経っても、画面が表示されない。そういった状況を想い出せばよいだろう。

この状況が続くと、メモリもCPUも圧迫され続け、システムそのものへのssh接続もままならなくなる。

こうなると、システムは次の画面にあるように、OOM Killer を発動する。

この状況では、諸悪の根源を、apache に有ると考え、apache のタスクを殺しにかかる。

この時、apacheの抱えるタスクは当然のごとく消され、最悪の場合システムが完全にロックする場合もある。

この記事を書いてる現在、既にapache 2.2.20のパッチが提供され、それ以外のバージョンでも暫定的な対応策が公開されている。まだ、apacheの対策を行っていないのであれば、早急な対応されることの望む。最悪の場合、apacheどころか、OSまで止まるのだから。

この後の検証で、killapache.pl のHEADをGETに書き換えた場合、HEADの時より、高速にサービス拒否攻撃が成立し、OOMKillerが発動する事がわかった。

これは、HEAD によって呼び出される情報が、Serverの情報のみに集約され、あまり、1300バイトを超えることが無いことに対し、GET の場合は、HTMLが含まれ、容易に1300バイトを超えるためと推測される。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

８月２５日、DeNAが提供するモバゲーが９時３０分くらいからアクセスできなくなった。折しも、Apacheで、重大なセキュリティホールが報道された為、落とされた？と、思っていたら・・・

どうやら、Apache の脆弱性によるものではなく、単なるデータセンタの障害だったらしい。

DeNAが入るデータセンタの発表によると

弊社データセンターにおける通信障害について

本日9時30分頃、弊社データセンターにおいて通信障害が発生いたしました。この障害は、データセンター内のテナント様が行なっていた工事中に誤って回線を切断したことによるものです。

とのことで、第三者の人為的ミスによる障害と判明した。

今回の、通信障害から分かることを考えてみたいと思う。

1. データセンタは、共用ビルだった？
2. ネットワークが共有部分を走っていた？
3. ネットワークがシングルポイントになっていた？

まず、1の問題から。様々な理由からデータセンタのみを運用するデータセンタの構築は難しいとされる。だが、データセンタを構成する上で重要となる、クリティカルな情報を扱う場合、L7もしくはL6程度のファシリティが必要になると考えている。つまり、DeNAが入るデータセンタは、クリティカルデータを扱う事はできないと、宣言しているようなものだ。

次に、2の問題。共有ビルの場合、通信ケーブルを専有部分のみに走らせることは厳しい。しかしながら、他のデータセンタでは、共有部分に於いても、通信ケーブルを切断されないように、シールド線を用いたり、囲いを使ったりして対策を施している。

最後に、３の問題。データセンタを設計する上で、一番重要な問題は、シングルポイントを絶対に作らないこと。これは、電源ケーブルしかり、通信ケーブルしかり、２重３重に経路設計を行い、物理線は当然のこと、複数の異なるライン、複数の異なる物理経路を用い、仮に１本切断されたとしても、他の経路で確実に到達するように設計を行う。

DeNAが入っていたデータセンタは、耐震性を謳っているようだが、地震云々よりも、こういったアタリマエのことをやってから、耐震性を考えて欲しいものである。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

侵入者に対する考え方は、様々なポリシーによって、多種多様に存在する。

今回は、様々なポリシーの中から、少し変わった対策を紹介しよう。

まず、侵入者に対する考え方は、大きく分けて次のように分類される

1. 絶対防御
2. ノーガード戦法
3. ハニーポット

このうち、多くの企業や組織が行っているのが、絶対防御の考えである。通常であれば、侵入者の試みを快く思わず、様々なポイントで、侵入者の試みを排除しようとする。

一切の試みを禁止しているため、最悪の場合DDoSを使って、サイトそのものを外部から閲覧させないように攻撃される場合がある。

次に、割と多く困った存在が、ノーガード戦法だ。普段は何もせず、最低限の対策だけ行い、なにか問題が発生したら、ひたすら謝る方法だ。先程の、絶対防御に比べ、多くのリソースを必要としないため、月々のコストを下げることが出来る。もちろん、実際の攻撃を受けた場合、多大な損害が発生するわけだが、万一の事態に備える必要がないため、状況によっては、ノーガード戦法が、コストが安くつくかもしれない

最後に、ハニーポット。通常のサイトのフリをし、脆弱なサイトの様に見せかけて、攻撃者の動向を調べる手法だ。一般的な企業がこれを採用する事は少なく、どちらかと言えばセキュリティを生業とする企業が用いる。

今回紹介する手法は、３つのどのモデルにも該当しない。

多くの侵入者は、ちょっとした遊びゴコロで侵入している事が多い。たしかに、プロの犯罪者が情報を盗むために侵入するケースもあるが、それはごくごく一部だ。

侵入者は、まず、脆弱なパスワードを設定したアカウントを探し出し、そのアカウントに対してsshやtelnet ftpなどに対して攻撃を仕掛ける。ここで、脆弱性なアカウントとパスワード（例えば id:test passwd:test 等の様に）を見つけ出し、サイトに侵入したとする。

次に侵入者は、いつでもそのサイトに侵入できるようにバックドアを仕掛ける。そして、ローカルexploitを用い、管理者権限を奪い、rootkit を仕掛け・・・と、こんな具合に侵入して、次に踏める場所を調べ始める。これと同時に、有用な情報がサイト内に無いかを調査することも忘れない。ここまで書くと、ハニーポットに視えるだろう。たしかに、このままではハニーポットだ。有益な情報をわざと散りばめ、かつ、それに毒入れを行っていたらどうなるだろうか。

通常のテキストファイルだけでは、毒入れすることは難しいが、PDFファイルや、GIFファイルなどであれば、毒入れすることはかなり容易くなる。具体的な毒入れ手法は書かないが、毒入れされた有益な情報を侵入者が持ち帰り、自分のPCや友だちのPCでひらこうものなら、それを開いたPCの情報が、丸裸のように、別サイトに通知されるように仕込んでおく。つまり、有益な情報を盗んだ！と思ったら、実際には攻撃者が丸裸にされるわけだ。

侵入者には、簡単に入れるという快楽を与え、実際には侵入者の個人情報を盗む。そういった対策を考えてみるのも一考だろう。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

Twitterが自動的に付加する短縮URLはセキュリティとか考えてるかよくわからないので安心できそうなサービスを使ってみます。

(先に結論を言うと、無駄足でした。)

なにやら最近、TwitterでURLを普通に流すと勝手にt.coという短縮URLに変更してしまいます。

短縮URLは少ない文字で記述するには非常に便利ですが、セキュリティ上考えられているかというとよくわかりません。

短縮URLでセッションを奪ったりなんていうのは昔からよくあった話で今更感がありますが、このようにデフォルトサービスにまで発展するとさすがにまともなサービスを検討して使っておかないとまずいターンだろうと思います。

で、まともなサービスがないかなーと思っていたら、同僚から「マカフィーの短縮URLがあるよ」と教えてもらいました。

調べてみると、「McAf.ee」というサービスで、マカフィーのデータベースを使ってURLを評価しているようです。(参考記事: McAfee、サイトの安全性も評価するURL短縮サービス「McAf.ee」ベータ版公開)

これなら安心して使えそうということで、さっそく夜フクロウで使えるようにしてみました。

夜フクロウの環境設定画面を開きます。

そして、詳細タブのURL短縮サービスの項目でカスタムを選択します。

次に、ダイアログが現れるので、以下のように入力します。

http://mcaf.ee/api/shorten?input_url=%@&format=text

フォーマットはテキストのままにしておきます。

これで短縮URLで「McAf.ee」が使えるようになりました。

ですが….結局、この短縮URLにしても、Twitter側が勝手にt.coという短縮URLに変更してしまいます。

対策としては、Command+Sで短縮URLに変更したあとに、http://からhを削ってみるとよいでしょう。

McAf.eeのAPIのドキュメントはThe McAf.ee APIにあります。自分のサービスに組み込みたい人は、ぜひ参照してください。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

Rails3.1ではSCSSが標準で搭載されました。とても面白い仕組みなので紹介します。

CSSはWebページにおいて構造とデザインを分離するとても重要な仕組みです。しかし、デザインが複雑になるに連れてどんどん肥大化していき、うまくコントロールしないとメンテナンスが容易ではなくなってしまいます。よく、新しいデザインを追加したと思ったら他のデザインとぶつかってしまったなんてことがあったり、一箇所にクラスの定義がなくバラバラになっていて途方にくれてしまうなんてことはよくあります。

SCSSはこのような悩みをほどよく解決してくれるシンタックスを持つCSS用のメタ言語で、Rails 3.1から採用されました。SCSSについての詳細は、Sass、そしてSassy CSS (SCSS) をご覧ください。

今回は、黒田努氏のはじめる！Rails3(達人出版)のサンプルプログラム:hinagikuで、7.3 スタイルシートの作成に登場するサンプル(public/stylesheets/tasks.css)を例に、Rails 3.1でSCSSで記述した場合にどのような動きをするのかを紹介します。

書籍のサンプルでは、以下のようなコードになっています。

table.tasks {
  width: 560px;
  margin: 5px auto;
  background-color: #eee;
  border-collapse: collapse;
  border-spacing: 0;
}

table.tasks tr {
  border: solid 1px #ccc;
}

table.tasks td {
  padding: 5px;
}

table.tasks col.name {
  width: 320px;
}

table.tasks col.due_date {
  background-color: #ddd;
}

これをSCSSで書きなおしてみます。

まず、書籍と同様にコントローラを作成します。

$ rails generate controller tasks
      create  app/controllers/tasks_controller.rb
      invoke  erb
      create    app/views/tasks
      invoke  test_unit
      create    test/functional/tasks_controller_test.rb
      invoke  helper
      create    app/helpers/tasks_helper.rb
      invoke    test_unit
      create      test/unit/helpers/tasks_helper_test.rb
      invoke  assets
      invoke    coffee
      create      app/assets/javascripts/tasks.js.coffee
      invoke    scss
      create      app/assets/stylesheets/tasks.css.scss

この時に、app/assets/stylesheets/tasks.css.scssも作成されます。

先ほどのCSSをapp/assets/stylesheets/tasks.css.scssに記述します。SCSSでは以下のようになります。

// Place all the styles related to the tasks controller here.
// They will automatically be included in application.css.
// You can use Sass (SCSS) here: http://sass-lang.com/

table.tasks {
    width: 560px;
    margin: 5px auto;
    background-color: #eee;
    border-collapse: collapse;
    border-spacing: 0;

    tr {
        border: solid 1px #ccc;
    }

    td {
        padding: 5px;
    }

    col.name {
        width: 320px;
    }

    col.due_date {
        background-color: #ddd;
    }
}

このようにCSSで書きづらかった階層関係が非常にわかりやすく書くことができます。個人的に困っていたデザイナさんが作ってくれた新しいデザインを忙しいとかいう理由で一番下に追加して阿鼻叫喚とかいうことが、この階層化によって発生しづらくなっています。

さて、今まではCSSの指定は <%= stylesheet_link_tag :all %> として、public/stylesheets 以下のものを全て読み込む形になっていましたが、Rails 3.1からは、 <%= stylesheet_link_tag “application” %> となり application.css のみ標準で読み込む形になります。ということは、tasks.css はどこにいくのでしょうか？正解は、SCSSを利用してtasks.css.scssの内容が application.css に入るのです。

実際にこの仕組みをみてみましょう。

先ほど作成したコントローラにアクセスしてみます。

Started GET "/tasks" for 127.0.0.1 at 2011-08-09 14:10:51 +0900
  Processing by TasksController#index as HTML
MONGODB hinagiku_development['tasks'].find({:done=>false})
Rendered tasks/index.html.erb within layouts/application (616.2ms)
Completed 200 OK in 678ms (Views: 677.1ms)


Started GET "/assets/application.css" for 127.0.0.1 at 2011-08-09 14:10:52 +0900
Compiled ~/develop/ruby/mongo_rails3_test/hinagiku/app/assets/stylesheets/tasks.css.scss  (45ms)  (pid 85886)
Compiled ~/develop/ruby/mongo_rails3_test/hinagiku/app/assets/stylesheets/application.css  (1ms)  (pid 85886)
Compiled ~/develop/ruby/mongo_rails3_test/hinagiku/app/assets/stylesheets/application.css  (0ms)  (pid 85886)
Served asset /application.css - 304 Not Modified (96ms)


Started GET "/assets/application.js" for 127.0.0.1 at 2011-08-09 14:10:52 +0900
Served asset /application.js - 304 Not Modified (19ms)

ここで、Compiledという文字があるとおり、コンパイルをしているということになります。

実際に出力されるCSSは以下のようになります。

/*
 * This is a manifest file that'll automatically include all the stylesheets available in this directory
 * and any sub-directories. You're free to add application-wide styles to this file and they'll appear at
 * the top of the compiled file, but it's generally better to create a new file per style scope.
*/
/* line 5, /Users/btm/develop/ruby/mongo_rails3_test/hinagiku/app/assets/stylesheets/tasks.css.scss */
table.tasks {
  width: 560px;
  margin: 5px auto;
  background-color: #eee;
  border-collapse: collapse;
  border-spacing: 0;
}
/* line 12, /Users/btm/develop/ruby/mongo_rails3_test/hinagiku/app/assets/stylesheets/tasks.css.scss */
table.tasks tr {
  border: solid 1px #ccc;
}
/* line 16, /Users/btm/develop/ruby/mongo_rails3_test/hinagiku/app/assets/stylesheets/tasks.css.scss */
table.tasks td {
  padding: 5px;
}
/* line 20, /Users/btm/develop/ruby/mongo_rails3_test/hinagiku/app/assets/stylesheets/tasks.css.scss */
table.tasks col.name {
  width: 320px;
}
/* line 24, /Users/btm/develop/ruby/mongo_rails3_test/hinagiku/app/assets/stylesheets/tasks.css.scss */
table.tasks col.due_date {
  background-color: #ddd;
}
// Place all the styles related to the tasks controller here.
// They will automatically be included in application.css.
// You can use Sass (SCSS) here: http://sass-lang.com/

出力されたファイルはほとんど元の変換前と同じ内容になりました。すばらしい！

さて、今回 /assets/stylesheets にアクセスしているのに気をつけてください。以前では /stylesheets にアクセスしていたものが変わっています。これは、assetという仕組みを利用しているためで、config/application.rbから変更ができます。

    # Enable the asset pipeline
    config.assets.enabled = false

falseになっている場合は、以前と同様に public/stylesheets 以下を見に行くようになります。

SCSSは非常に面白い仕組みです。まさに幸福実現です。Sass、そしてSassy CSS (SCSS)には非常に多くの例があります。ぜひ、ご一読の上、Rails 3.1+SCSSの世界に飛び込んで下さい。

ちなみに、筆者はCoffeeScriptよく知らないので、そっちの方は別の人が記事にしてくれると期待しています。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

社内用の開発の為、ノートPCで自宅⇔会社で同じリポジトリを使いたいという要望がわりと多くあると思いますが、そんな時に便利なソフトウェアを紹介します。まず、以下の図をみてください

  上記のイメージにある通り、社内にいる人間はそのままリポジトリへアクセスできますが、その人がノートPCをもって自宅へ帰り、チェックアウトしようとしてもできません。

  もし社内にsshログインできるようなゲートウェイサーバがあるのであれば、そのサーバを使ってポートフォワードをしてチェックアウトすればひとまず目的は達成できそうです。 でも、なんか不便だと思います。やり方は様々かと思いますが、社内では

% svn co http://repo.example.co.jp/prjname/ 

とするだけで事足りたのに、ポートフォワードを使って外出先からチェックアウトする時は

% svn co http://localhost:8080/prjname/

みたいな事をしなくてはならず、スマートじゃない気がします。そもそもリポジトリのURLを同等に扱いたいです。 これをtsocksというコマンドで解決したいと思います。MacユーザはMacPortsから導入するのが楽です。

% sudo port install tsocks

設定ファイルを準備します。以下のような感じで。

% cat /opt/local/etc/tsocks.conf 
server = 127.0.0.1
server_port = 1080
tordns_enable = false
server_type = 5

この状態でゲートウェイサーバへログインをして、セッションを貼るようにしてみます。

% ssh -D 1080 ゲートウェイサーバ

上記セッションを活かした状態で、社内ネットワークの「外」からアクセスしてみます。 社内にいるときにチェックアウトしたコマンドの先頭に”tsocks”をつけるだけでsocks経由でのアクセスにすることができます。

% tsocks svn co http://repo.example.com/prjname/

あとはソースコードにバンバンコミットです。社内では

% svn ci -m "test commit" filename

などとして普段通りアクセスしていればよいですし、外出先などでは

% tsocks  svn ci -m "test commit" filename

のように、tsocksをつければいいだけです。 subversionを例に使いましたが、gitでも同じ事です。 これだったらあまり難しい事を考えず、どこでも同じURLをつかってリポジトリにアクセスできるので、便利じゃないかと思います。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

こんにちは、SHIMADAです。

今回は、いつもと少し違った趣向ですが、推薦図書の紹介をしたいと思います。

コードコンプリート CODE COMPLETE 第二版（上巻・下巻）
日経BPソフトプレス刊
Steve McConnell（スティーブ・マコネル）著

 
この本にはかなり思い入れがあります。
というのも、IT業界で飯を食おうと決心したときに、最初に大枚をはたいて買った本だったからです。そのときはまだ初版でした。
情報系の専門教育を受けていない自分が、これまでまがりなりにもやってこれたのは、この本のおかげだと思います。

このエントリで言いたいこと

上下巻に分かれていて、それぞれ六千円超という値段なので、買うとしたらかなり躊躇してしまうかも知れません。
 

でも、買え！

 
それだけの価値があります。
もしかしたら既に職場にある、あるいは申請したら買ってくれる、といった恵まれた環境にいらっしゃる方もおられるかも知れません。
どんなことが書いてあるのか、事前に確かめられる幸運に感謝しましょう。
 

でも、買え！

 
図書館で本を借りたときよく体験するのですが、娯楽のための小説や雑誌とちがって、こういう歯ごたえのある本は自分の懐を痛めて買わないと、人間なかなか読まないものです。
大丈夫。一万三千円、充分モトが取れる本です。自分に投資しましょう。

どんな本なのか？

三行でおk、という声が聞こえてきたので三行でまとめると、

• ソフトウェアコンストラクションに関する
• 特定の言語や方法論に限定されない
• 普遍的なベストプラクティス

を広い範囲で収集し、体系的にまとめた本です
プログラマ、エンジニアとして、最低限知っておかなければいけない、でも入門書や教科書にはあまり載っていない現場寄りの知識を具体的に教えてくれます。
知っていればしなくていい苦労、というものがあります。システムの開発に携わるにあたって、しなくていい苦労を避けたい人に読んで欲しい本です。
またそういう種類の苦労は、えてして他の人を巻き込みます。いらぬ苦労に巻き込まれたくない人にもおすすめです。

「ソフトウェアコンストラクション」ってなに？

「ソフトウェアコンストラクション」というのは耳慣れない言葉かもしれません。
システム開発における各種アクティビティの一部で、下図のグレーで塗られた楕円の部分になります。（文字の大きさが、本書における取扱いのウェイトを示しています。）
「コーディングとデバッグ」が最も大きなウェイトを占めていて、「課題定義」「要求開発」「システムテスト」などは範囲外となっています。

本書 p.6 図1-2 を引用

ただし、この本で触れていないアクティビティが、システム開発にとって重要でないということはないです。
そういった方面については他に有用な書籍が充実しているので、あえて焦点を当てていないという側面があります。

内容についてもっと詳しく知りたい

@ITさんのサイトで上下巻の完全な目次と、一部の章の本文が公開されています。

＠IT： BOOK Preview：Code Complete 第2版

• 第6章 クラスの作成（前半）
• 第6章 クラスの作成（後半）
• 第24章 リファクタリング
• 第34章 ソフトウェア職人気質とは

本書を買うつもりがない人も、上記ページは無料で公開されてますので、是非読んでみて下さい。

最後に本文からの引用を

第一部「基礎を固める」から、本書の姿勢をよく表している一節を引用してみます。

言語の「中で」のプログラミングと言語の「中へ」のプログラミングの違いを理解することは、本書の内容を理解する上で重要である。
重要なプログラミング原理のほとんどは、言語の種類ではなく、言語を使用する方法に依存する。使用したい構造が言語に含まれていない、あるいは何らかの問題が起きやすいという場合は、それらを補正できないかどうか試してみよう。コーディング規約、標準、クラスライブラリなどの補強を独自に考案してみよう。

（上巻 p.83 4.3.1 「言語の『中へ』のプログラミングの例」より）

追記：弊社社員へ

本書を使った読書会／勉強会について検討しています。（どういう形で進めるのがいいか、頭を痛めています）
興味のある人は是非SHIMADAまで一声掛けて下さい！

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

前回、PHPのソースインストールで32bit版CentOSへのインストール方法を記載しましたが、最近64bit版CentOSにインストールする機会があったので、PHP以外も含め変更点をメモしておきます。

●PHPのインストール

下記のエラーが出るので、オプションに「–with-libdir=lib64」を追加する。

configure: error: mysql configure failed. Please check config.log for more information.
# ./configure –with-apxs2 –with-bz2 –enable-calendar –with-curl –enable-exif –enable-ftp –with-gd –with-gettext –with-gmp –with-ldap –enable-mbstring –with-mcrypt –with-mysql –with-mysqli –with-openssl –with-pdo-mysql –with-pspell –enable-shmop –enable-soap –enable-sockets –enable-sysvmsg –enable-wddx –enable-xml –with-xsl –with-zlib –with-config-file-path=/etc –with-config-file-scan-dir=/etc/php.d –with-libdir=lib64

●saslauthdの設定

「/usr/lib/sasl2」ではなく「/usr/lib64/sasl2」のを変更する。

# cd /usr/lib64/sasl2
# cp -a smtpd.conf smtpd.conf,20110401
# vi smtpd.conf
—- ここから —-
### START 2011/04/01 myname ###
#pwcheck_method: saslauthd
pwcheck_method: auxprop
### END ###
—- ここまで —-

●Squidの設定変更

「/usr/lib/squid/ncsa_auth」ではなく「/usr/lib64/squid/ncsa_auth」にする。

# cd /etc/squid
# cp -a squid.conf squid.conf,20110401
# vi squid.conf
—- ここから —-
### START 2011/04/01 myname ###
auth_param basic program /usr/lib64/squid/ncsa_auth /etc/squid/.htpasswd
### END ###
—- ここまで —-