Ubuntu 12.04LTSでのRuby on Rails環境の構築
前回の記事「Ubuntu 12.04LTSでのRuby環境構築 - 無銘書房」の続き。既にRuby 2.1.5が導入されたとする。Railsの導入からテストアプリケーションの起動までを書く。
Railsの導入
まずはgemのバージョンを確認する。
$ gem -v
ここでgemがないと警告が出ればapt-getで入れておく。さて、Railsの導入は先程のgemで簡単にできる。今回はRails 4.1.0を入れる。
$ gem install rails --version "=4.1.0"
導入が終れば、いよいよテストアプリケーションの作成だ。最初にホームディレクトリ配下に適当なディレクトリを作成する。
$ mkdir dev $ cd dev
次にRailsでテストアプリケーション――ここでは名前はtest_appとしておく――を作成する。
$ rails new test_app
test_appというプロジェクトディレクトリが作られるのでそこに移動し、テストアプリケーションを起動せしめる。
$ cd test_app
$ rails server
ここで筆者の環境では「ExecJS::RuntimeUnavailable」という警告が出て起動に失敗した。
$ rails server $HOME/.rvm/gems/ruby-2.1.5/gems/execjs-2.2.2/lib/execjs/runtimes.rb:51:in `autodetect': Could not find a JavaScript runtime. See https://github.com/sstephenson/execjs for a list of available runtimes. (ExecJS::RuntimeUnavailable)
「Rails - Could not find a JavaScript runtime? - Stack Overflow」によれば、nodejsがないことが原因なので、apt-getでnodejsを入れる。
$ sudo apt-get install nodejs
nodejsの導入後再びアプリケーションを起動させようとしたときに以下の様に表示せられれば問題ない。
$ rails server => Booting WEBrick => Rails 4.1.0 application starting in development on http://0.0.0.0:3000 => Run `rails server -h` for more startup options => Notice: server is listening on all interfaces (0.0.0.0). Consider using 127.0.0.1 (--binding option) => Ctrl-C to shutdown server [2015-01-15 23:38:27] INFO WEBrick 1.3.1 [2015-01-15 23:38:27] INFO ruby 2.1.5 (2014-11-13) [i686-linux] [2015-01-15 23:38:27] INFO WEBrick::HTTPServer#start: pid=21646 port=3000
最後にブラウザで「http://localhost:3000/」に繋いで画面が表示されれば、Ruby on Railsが正常に導入されたと判断できる。
Ubuntu 12.04LTSでのRuby環境構築
自己紹介にPerlという文字列を入れておきながら、新年最初の記事がRubyの導入であることに我ながら流石に何だかなと思う。
閑話休題、VirtualBox上のUbuntu 12.04LTSへのRuby環境の導入について書いておく。もちろん、Ubuntuには既定でRubyはインストールされて居るけれども、バージョンが1.9.1と古いものあるからRVMを利用して新しいバージョンを導入したい。基本的な手順としては、
- http://blog.kondoyoshiyuki.com/2013/01/15/install-ruby-on-rails-on-ubuntu-12-04lts/
- http://www.atmarkit.co.jp/ait/articles/1402/27/news042.html
を参考にして導入した。備忘録がてらコマンドだけをつらつらと書いていく。
RVMの導入
$ curl -L https://get.rvm.io | bash -s stable
ここで筆者の環境では公開鍵がないと警告が出て失敗したので、エラーメッセージに従って公開鍵を取得した。
$ curl -sSL https://rvm.io/mpapis.asc | gpg --import -
公開鍵の取得後、先程のcURLの導入コマンドを再実行する。そして、rvmを有効化せしめるために下記コマンドを実行する。
$ source $HOME/.rvm/scripts/rvm
正常にrvmが導入されたのなら、以下のコマンドでrvmを通じて導入できるRubyのバージョンが示される。
$ rvm list known
Rubyの導入
今回は2.1.0系列の最終版たる2.1.5を入れよう。
$ rvm install ruby-2.1.5 --default
必要なパッケージもまとめてインストールされるが、時間が少し掛かることに注意する。インストール終了後、以下のコマンドのうち何れかで現在のRubyバージョンを確認できる。
$ ruby -v
$ which ruby
指定したバージョンが表示されたら、正常にインストールされて居る。
rvmの管理下に置かれて居るRubyの確認は以下の通り。
$ rvm list
Rubyのバージョン切替は次の様になる。
$ rvm use [version]
大体この様なものであろうか。後日、Railsの導入の備忘録も書いておきたい。
Windows Phone 7.5からFirefox OSへの連絡帳の移行
題名の通り、Windows Phone 7.5からFirefox OS(Fx0 LGL25)へのアドレス移行の備忘録である。連絡帳はMicrosoft Peopleに自動同期されているのを前提とする。自動同期されていれば、Firefox OS(Fx0 LGL25)での操作だけで移行は完了する。
InDesign向けJavaScriptでの検索・置換
題字の如く、InDesign向けJavaScriptにおける検索や置換のコードについて実例を示す。なお、Windows版InDesign CS6で動作を確認した。
テキスト検索
基本的な手続きとしては、検索条件のプロパティを設定し、置換テキストを設定し、検索を実行するコードを記述する。
//プロパティの初期化 app.findTextPreferences.findWhat = NothingEnum.nothing; app.changeTextPreferences.changeTo = NothingEnum.nothing; //検索条件と置換後の文字列との設定 app.findTextPreferences.findWhat = "検索文字列"; app.changeTextPreferences.changeTo = "置換後文字列"; //現在編集中の全てのドキュメント app.changeText(); //選択範囲 var text = app.activeDocument.selection; for(var i = 0; i < text.length; i++) { text[i].changeText(); } //ドキュメント全体 for (var i = 0; i < app.activeDocument.pages.length; i++) { var pageObject = app.activeDocument.pages[i]; for (var j = 0; j < pageObject.textFrames.length; j++) { pageObject.textFrames[j].parentStory.changeText(); } } //検索条件等の消去 app.findTextPreferences.findWhat = NothingEnum.nothing; app.changeTextPreferences.changeTo = NothingEnum.nothing;
app.findTextPreferencesオブジェクトのプロパティが、appオブジェクトのメソッドの挙動に影響するのみならず、selectionのメソッドやparentStoryのメソッドの挙動に影響を及ぼすことに注意。
以下の正規表現や字形置換でも同様である。
正規表現
簡潔に設定部分だけを示す。手続きは先と同様である。
//検索 app.findGrepPreferences.findWhat = "(\\d)"; //置換 app.changeGrepPreferences.changeTo = "$1";
置換メソッドはchangeGrep()を使用する。検索範囲に合せて、上記のコードのchangeTextメソッドを置き換えればよい。
字形置換
これも手続きは同じだが上記と比べると設定が少し厄介だ。先と同様に設定部分だけを示すが、フォント名を正しく指定しないとエラーが出る。また、フォント名とウェイトとは「タブ」で繋ぎ、GlyphIDプロパティにCID番号を指定する。
//検索条件 app.findGlyphPreferences.appliedFont = app.fonts.item("小塚明朝 Pro" + " "+"R"); app.findGlyphPreferences.glyphID = 2051; //置換設定 app.changeGlyphPreferences.appliedFont = app.fonts.item("小塚明朝 Pro" + " "+"R"); app.changeGlyphPreferences.glyphID = 4467;
置換メソッドはchangeGlyph()を使用する。今までと同じく検索範囲に応じて呼び出すべきメソッドが属するオブジェクトが異なることに留意する。
引用符の基本的な記法
文章を書くと多かれ少なかれカギ括弧の類を使う。その用途は台詞を示すものであったり文意の強調であったりと様々であるが、開き括弧と閉じ括弧とを対応させるというのはカギ括弧の使い方の基本(作文の基本)として認識されているだろう。
それでは“引用符”の類はどうだろうか。カギ括弧の使い方を間違える人はまず居ないだろうが、引用符になると普段使わない人も多いから途端に使い方に誤りが見られる。今回は引用符(和文限定)についてあれこれ書いておきたい。
※ここでは引用符をシングルクォーテーション、ダブルクォーテーション、ダブルミニュートと定義する。
※書かれた原稿が最終的には印刷物もしくは電子書籍などの様にある程度体裁が整えられた状態に編集されるとする。
疑問符や感嘆符の後ろは必ずあける?
疑問符や感嘆符の直後にはスペ-スを入れる
小説に限らず、それなりに文章を書いた経験がある人ならば、上記のルールはよく知っているだろう。一般に以下の様な表現は妥当でない。
アイエエエエ!エクセル方眼紙!?エクセル方眼紙ナンデ!?
校正者や編集者の手によって、上記の文章は次の様に直されるだろう。
アイエエエエ! エクセル方眼紙!? エクセル方眼紙ナンデ!?
何故スペースを入れるのかというと、これらの疑問符や感嘆符は「句点と同じ役割」で使用しているからである。すなわち、文章の区切りを明示させるため、スペースを入れているのである。
三種類の例外
もちろん上記の原則には例外がある。この例外は三つあるとされ*1、
- 直後に終り括弧類が来る場合
- 直後にダーシや三点リーダが来る場合
- 文脈上、アキを入れると不自然な場合
の何れかに該当するとき、スペースの挿入は不要であるとされる。
さて、一番最後にあげた例外は認知度が低いため誤解をよく招く。本稿では各例外を説明しつつ、認知度が低い例外についてどう対処すべきか考えたい。
*1:『文字の組方ルールブック 縦組み編』(日本エディタースクール出版部)
Webアプリケーションのアンチパターン
業務で、Webアプリケーション(.NET化以前のaspとそれに連携するVB6.0という化石)を弄る日々だが、不幸なことにそれらはアンチパターンの集積である。今日は筆者が今まで見てきたWebアプリケーションのアンチパターンについて列挙したい。
モノシリックなファイル、関数
引数取得、制御、DBクエリの発行と取得、データ加工、HTML出力まで全部が一つのファイル(もしくは関数)に詰め込まれたもの。所謂MVCパターンで言うところのコントローラ、モデル、ビューが渾然一体となったものか。見栄え、制御、処理が一箇所に記述されているわけだから、改修をするときにどこを改修すべきなのかが判別できない。
もちろん、極めて小さなWebアプリケーションであれば、分割せず一つにしたほうがいいかもしれない。
不明瞭なレイヤー分割
長くなったコードを適当に分割するとこれに陥りやすい。上記と同様に改修時に地獄を見る。
データベースクエリの乱発
データベース廻りは注意深く設計しても、改修を重ねるうちに混沌としやすい。フレームワークなるハイカラなものを利用すれば結構抽象化できるが、そうでない環境で何も考えずにデータベースクエリを乱発すると、当然見通しが悪くなる。データベースから取るべきデータ項目や取得条件が変ったら、該当する箇所を全て洗い出して修正する必要が出てくる。
筆者がいじっている化石は、機能モジュールごとにそれが使用するDBアクセス関数(実体はクエリのベタ書き)を集めたファイルが十数個もあるので、状況は上記と似た様なもの。むしろ、もっとひどい。当然、誰もDB周りを把握できていない。
参考:DAOの悪夢
引数が多すぎる関数
引数がたくさんある関数は使用する側にとっては相当面倒な代物。その様な関数がたくさんあると……。十個以上の引数の並び順や型なんぞ誰も覚えられない。さらに関数ごとに引数の並び順に規則がない場合、ますます大変なことになる。
長すぎるGetパラメータ
RFC上*1、Getパラメータに限度はないそうだが、ブラウザで制限を設けていることもある。現にInternet Explorerは約2000字が限度だ*2。何でもかんでもGetパラメータに渡してしまって制限長を超えると、データ送信は不完全になる。
ファイル名をパラメータとして渡す
パラメータ名をそのままファイル名として開く処理があると特に危険である。情報漏洩の原因になりやすい。全く対策をしていなければ、ディレクトリトラバーサル攻撃も可能。
URLエンコード(あるいはデコード)をしない
日本語が入力されないから不要? 空白や特殊記号類もURLエンコードの対象である。特殊文字が入ったデータをエンコードせずにURLクエリとして渡すと、データの取得が思った様にできなくなる。
特殊文字処理をしない
論外。外部公開されるシステムであると、コマンドインジェクション、SQLインジェクションの練習場になってしまう。フレームワークに特殊文字処理が組み込まれているのであれば、それに任せる方向が無難。いちいち自前で書いていたら漏れが起きる。
大体、このようなものだろうか。実装上のアンチパターンの一部は放置するとセキュリティ上の重大な危機を招きうる。設計上のものは後々の改修時で大変なことになる。Webアプリケーションを作った結果、上記の様な状態になってしまったら、設計なり実装なりを見直そう。
*1:HTTP/1.1 RFC2616の3.2.1 General Syntaxを参照