今日の感動したこと - 中学生の情報リテラシー

いやぁー、中学3年生の娘の行動に感動させられました。

たまたま、娘と一緒にパソコンの画面を見ながらamazonで本を購入しようとしていました。
購入の際に僕がパスワードを入力しようとしていたとき、娘が視線を画面からはずすようになんとなく感じました。

何回かそのようなことがあったので、娘に聞いたところ、「パスワードを入力するときには視線をはずすようにしてるよ」との返事。 続けて、「それっと誰かに聞いて実行しているの？」 と聞いたところ、「そうするほうがよいのかなと自分で考えてやっているよ」という返事でした。

今どきの中学生はそれぐらいの情報リテラシーがあるのかと感動してしまいました。

会社で新人さんに「パスワードを入力しているときはね....」という話をよくしているのですが、コンピュータが当たり前の世代になるとそんなことも常識になるのかなぁ。

google chromeのパスワード管理ってずさんだね

すこし前からWebブラウザにgoogle chromeを使うようにしていました。

検索欄の作りが非常に使いやすかったからです。

でも、ウェブサイトのパスワード管理のずさんさですっかり冷めてしまいました。いくらベータ版とはいえ、パスワードが平文で見えてしまうつくりというのはありえないと思います。

「オプション」、「詳細設定」、「保存したパスワードを表示」、「パスワードを表示」とたどってみてください。平文のパスワードがばっちり見えますよ。また、chromeのパスワードを取得するツールも世の中にはあります。

最低でもFirefoxのようにマスタパスワードを設定できるようにしてほしいです。

tracksはmod_railsと相性が悪いねぇ

GTD(Getting Things Done)ツールのtracks(1.50)とmod_rails(passenger 1.0.5)の相性が悪いようです。

問題点として、以下のことがあげられます。

• 新規アクションを追加しようとすると応答が返ってこないことがよくある。
• 時々、生のHTMLの応答が返ってくる。
• 結構遅い。

tracksだけは、mongrel_clusterに戻そうかと思います

タグ：Rails mod_rails tracks

mod_rails(passenger) をFedora8で使い始めた

mod_rails(passenger)を使い始めました。 以前は、apache(proxy_balancer) + mongrel_clusterの構成でrailsアプリケーションを構築していたのですが、mod_railsがよさそうな香りを放っていたので試しに乗り換えてみました。

いままでのrailsアプリケーションの環境構築の面倒さがうそのように感じるほど、本当に楽チンでした。

mongrelとの比較をしてみると、

• 初回のアクセスがmongrelより遅いです。
  mod_railsは、初回のアクセス時にrubyプロセスを起動するから仕方ないです。いちおうパラメータでrubyプロセスのライフタイムを設定できるから問題にならないようにできるとは思いますが。
• mongrelの場合、前段にapache proxy balancerを入れると、簡単にロードバランスを構築できますが、mod_railsだと多段構成が難しいかも？

今回mod_railsをインストールしたOSは、Fedora8です。簡単なインストール手順を書いておきます。

事前準備
1) aprの開発ツールをインストール

$ yum install apr-devel

2) apxsを利用するため、httpd-develをインストール

$ yum install httpd-devel

mod_rails(passenger)のインストール

$ gem install passenger
$ passenger-install-apache2-module

mod_railsの設定

$ vi /etc/httpd.conf/mod_rails.conf
LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-1.0.5/ext/apache2/mod_passenger.so
RailsSpawnServer  /usr/lib/ruby/gems/1.8/gems/passenger-1.0.5/bin/passenger-spawn-server
RailsRuby /usr/bin/ruby
<VirtualHost *:80>
    ServerName www.yourhost.com
    DocumentRoot /somewhere/public
   <Directory /somewhere/public>
     AddType "application/x-javascript; charset=utf-8" .js
     AddType "text/css; charset=utf-8" .css
     AllowOverride all
     Order allow,deny
     Allow from all
   </Directory>
</VirtualHost>

httpdの再起動

$ /etc/init.d/httpd restart

ほんまに、mod_railsはよろしいで

タグ：Rails mod_rails

定期的なファイルのバックアップにAmazon S3を使う

おうちサーバのディスクのバックアップとして、Amazon S3(Simple Strage Service)を利用することにしました。

2007年12月におうちサーバのハードディスクが故障し、数ヶ月前のバックアップから復元した経験もあります。あのときの手間を考えると、毎日のバックアップは絶対必要ですね。

バックアップの要件として、以下のことを考慮してAmazon S3を選択しました。

• 信頼できる
• 自動化できる
• 簡単に利用できるツールがある
• 安価なこと
  容量課金は、1GBあたり$0.15で通信料課金は1GBあたり$0.1です。

Amazon S3の準備

1. Amazon S3のページにアクセスします
2. 「Sign Up For This Web Service」をクリックし、後は指示に従って入力します

s3syncの準備
自動的に行うバックアップとしては、使いやすさを第一に考えs3sync.rbを選択しました。
また、この記事ではFedora OSでのs3sync.rbのインストール方法や環境設定方法を記述しています。

1. ダウンロード
2. 圧縮ファイルを展開
   

   $ cd /usr/local
   $ tar zxvf /tmp/s3sync.tar.gz
   

3. 環境設定ファイルを作成。アクセスキーなどは自分で取得したものを記述してください。
   

   $ mkdir /etc/s3conf
   $ vi /etc/s3conf/s3config.yml
   aws_access_key_id: 11111111111111111111111
   aws_secret_access_key: 222222222222222222222
   $ chmod 600 /etc/s3conf/s3config.yml
   

4. 動作確認
   

   $ cd ~
   $ mkdir dummy
   $ echo hello > dummy/hello.txt
   $ /usr/local/s3sync/s3sync.rb dummy/ hogehoge_bucket:dummy
   

定期的なバックアップ
現時点で定期的にバックアップを行っているデータは、

• MySQLデータベース
• Subversion
• /var/wwwディレクトリ以下のすべてのファイル
• /etcディレクトリ以下の更新しているファイルとオリジナルのファイル

s3sync.rbはローカルのディレクトリ単位でバックアップを行うので、バックアップ対象のファイルを一箇所のディレクトリに集めるようにしています。
ローカルディレクトリの/var/backup/dailyに毎日バックアップしたいファイルを集め、/var/backup/weeklyに毎週バックアップしたいファイルを集めています。

一例ですが、毎日のバックアップ用のスクリプトは、以下のようにしています。

#!/bin/sh

# MySQLのダンプ
/usr/bin/mysqldump --user root --password=hogehoge --all-databases | gzip > /var/backup/daily/all_databases.sql.gz

# subversionのダンプ
svnadmin dump hoge_hoge_repository | gzip > /var/backup/daily/svn_backup.gz

####
# s3sync.rbを用いてバックアップ
/usr/local/s3sync/s3sync.rb /var/backup/daily/ hogehoge_bucket:backup/fedora/daily/

これで、ハードディスクの故障が発生しても、安心です。

また、GUIのツールは、FireFoxのプラグインのAmazon S3 Firefox Organizer(S3Fox)を利用させてもらっています。

参考となった情報

• Amazon S3の基本的なことを解説

タグ：バックアップ 毎日 Amazon S3

非同期な処理をRESTで記述するには

非同期処理をRESTで記述するのは、非常に簡単なのですね。 RESTful Webサービスの書籍を読んでいて目からうろこが落ちるような思いでした。
ポイントは、非同期処理の状態を1リソースとして考え、新たにリソースを作成すればよいということです。

処理の流れの概要は次のとおりです。

1. 非同期処理を開始するため、POSTリクエストを送信

   POST /message_queue HTTP/1.1
   Host: example.com
   

2. レスポンスを受信します。レスポンスコードの202も重要です。非同期処理を1リソースとし、Locationヘッダに非同期処理のリソースのURIを返却
   

   HTTP/1.1 202 Accepted
   Location: http://example.com/message_queue/1234
   

3. 非同期処理中のリソースの状態を取得するため、GETリクエストを送信
   

   GET /message_queue/1234 HTTP/1.1
   

4. レスポンスを受信する
   

   HTTP/1.1 200 OK
   <status>completed</status>
   

5. 非同期処理が完了すれば、リソースを破棄します。 リソースの破棄は、サーバが自発的にexpireしても、クライアントからDELETEメソッドを送信してもOKです。

RESTfulは、同期型のHTTPを使って、非同期処理やバッチ処理をうまく表現できるのがすばらしいねぇ。

RESTful Webサービス

• 作者: Leonard Richardson
• 出版社/メーカー: オライリー・ジャパン
• 発売日: 2007/12/21
• メディア: 単行本

タグ：REST 非同期

少し残念だったこと

redmineというissue管理ソフトを使っているのですが、3日前ぐらいから期限が来るとメールが送信される機能を実装していました。

しかーし、googleグループのredmine-users-jaに同様の機能をほしいという要望と回答がありました。

オープンソースにcommitできるよい機会だと思ったのになぁ。

でも、せっかくだから完成させてパッチを送ろうかとも思っています。

subversionのコミット方法を間違っていたよ

subversionを使い始めて3年ぐらいになるけど、僕のコミットの方法が間違っているのに今頃気づいたよ(泣)

iさんから聞いたのですが、CruiseControlは、subversionでコミットするタイミングでビルド&テストを実行するそうです。

その話を聞いたとき、コミットするタイミングでビルドを実行するとうまくビルドができないのではと思ってしまいました。 僕自身がCVS的な方法でsubversionを使っていたための勘違いです。

subversionは、Atomicな操作は一度で行うべきだったのです。たとえば、あるひとつの変更が複数のファイルに関係する場合、必ず一回でコミットしなければならないのです。一回でコミットすることで変更に対してリビジョン番号が割り当てられ、トレーサビリティが確保されるのです。

明日から心を入れ替えよっと。

iさん、本当にありがとうございました。

新年なのでPCのバックアップ

2006年になったので、おうちのパソコンたちのバックをアップをおこないました。
大体3ヶ月から半年に一回ぐらいの割合でバックアップしています。

ハードディスクの内容ををUSBのハードディスクにコピーするという、単純なものです。以前はディレクトリの容量を気にしながらCD-RWに焼いていましたが、便利な世の中になりました。

みなさんはディスクのバックアップしていますか?

バグを憎んで人を憎まず

「バグを憎んで人を憎まず」という言葉をふっと思い出しました。

それは、Hard on issues, soft on people.（問題にはタフに、人にはソフトに）という言葉を聞いたときです。問題と人とを切り離すとよりよい解決になるよということです。

確かにそうだよね。バグを埋め込んだ人の問題だって言っていても解決にはならないもんね。