RubyとPythonでクライアント・サーバ
2007.11.09 Friday 23:13
最近必要があってハードディスクの再圧縮をするソフトを作っている．zipファイルを7-zipの7z形式で圧縮し直すと，サイズが30%～65%削減できることを利用したものだ．
クライアント(ワーキングタスク)をRuby，サーバをPythonで作成．Ruby, Python, Databaseとすべて不慣れな中ようやく分散処理として動けるところまでたどり着いたところで振り返ってみたい．
クライアント(ワーキングタスク)をRuby，サーバをPythonで作成．Ruby, Python, Databaseとすべて不慣れな中ようやく分散処理として動けるところまでたどり着いたところで振り返ってみたい．
データ量が大きいので複数のPCで分散処理できないかと作り始めたのが2週間ほど前．実際の処理部をRubyでまず作り，単体でおおむね動いたら稼働を開始しつつ，管理サーバ側をPythonでDjangoを使って作っている．
DjangoはPython用のMVCフレームワークで，Ruby on Railsみたいなものだ．処理部として(得意なPerlではなく)Rubyを選択したのには理由がある．ExerbというrubyをEXEにまとめるソフトを使うと500KBそこそこのバイナリにまとめることができるので，複数のPCに入れる際にわざわざrubyをインストールしなくてよくなるとのもくろみである．
そして，なぜ管理サーバ側もRubyで作らないのかというと，Ruby on Railsは経験が無いが，Djangoは以前試したことがあること，そしてそのとき完成に至らなかった経緯があるので，もうすこしDjangoに取り組んでみたいという至極個人的な理由も含んでいる．
以下は今回感じたこと．
Rubyのブロック構文に感動した．net/httpとかパイプの処理とかをコマンド直後のブロックに「安全に」記述できるものだが，Dir.chdir()でも同様に使えるのがうれしい．
Dir.chdir(new_dir){ 処理 }
すると，中の処理をnew_dirで行った後で元のディレクトリに戻ってくれる．これは便利．
Rubyの問い合わせ系メソッドで最後に?がついているのはよく忘れる．そこまで名前の一部なので覚えるしかないのだが．
Rubyのモジュールジャンプが使えなくて編集がやりづらかったのは単にサクラエディタがRubyのアウトラインをサポートしていないというだけの理由．
Python(というよりDjangoは)HttpResponseなどの処理を使うたびに個別にimportしないといけないのが面倒くさい．マニュアル見る→記述→実行→存在しないメソッドとエラー→どのモジュールにあるのか調べる→ファイルの先頭に戻って記述．けっこういらいらする．1つ指定すれば関連ファイルをすべてインポートするまとめモジュールみたいなものを作ることも可能なのだが，そうはなっていない．
ただ，この点はDjangoが発展途上でマニュアル整備が貧弱なせいもあるだろう．メソッドの使い方についてはマニュアルがあるが当該箇所を見つけるのが結構大変である．メソッドの説明とincludeが必要なモジュールを併せて記述したリファレンスがあれば解消できるだろう．
PythonとRubyを交互に編集していると混乱する．特に文字列．
Ruby: "fileName #{file} Size: #{size}"
Python: "fileName %s Size: %d" % (file, size)
やっぱり全部Rubyに統一した方がいいかもね．
Djangoで画面を作るのが大変．出力用テンプレートについてはサンプルが無いので，簡単なものを一から作った．流行のWeb 2.0風グラデーションとは無縁な状態．Djangoはテンプレートの継承ができるので，スタイルテンプレート集があればうれしい．
サーバとクライアントの通信はJSON．Djangoにはdjango.utils.simplejson というのが入っているので，simplejson.loads(), simplejson.dumps()でエンコード・デコードが可能．Rubyではこのページのライブラリを使った．今回は両方向でJSONによるデータ交換を行っている．
Ruby, Python両方に言えることだが，例外への考慮が難しい．例外が出る可能性のある位置と型がわかっていないと怖い感じがする．動的片付け言語ではメソッド定義を見ても実際に渡されるオブジェクトの型はわからないのsで，追いかけるのが大変だ．
DjangoはPython用のMVCフレームワークで，Ruby on Railsみたいなものだ．処理部として(得意なPerlではなく)Rubyを選択したのには理由がある．ExerbというrubyをEXEにまとめるソフトを使うと500KBそこそこのバイナリにまとめることができるので，複数のPCに入れる際にわざわざrubyをインストールしなくてよくなるとのもくろみである．
そして，なぜ管理サーバ側もRubyで作らないのかというと，Ruby on Railsは経験が無いが，Djangoは以前試したことがあること，そしてそのとき完成に至らなかった経緯があるので，もうすこしDjangoに取り組んでみたいという至極個人的な理由も含んでいる．
以下は今回感じたこと．
Rubyのブロック構文に感動した．net/httpとかパイプの処理とかをコマンド直後のブロックに「安全に」記述できるものだが，Dir.chdir()でも同様に使えるのがうれしい．
Dir.chdir(new_dir){ 処理 }
すると，中の処理をnew_dirで行った後で元のディレクトリに戻ってくれる．これは便利．
Rubyの問い合わせ系メソッドで最後に?がついているのはよく忘れる．そこまで名前の一部なので覚えるしかないのだが．
Rubyのモジュールジャンプが使えなくて編集がやりづらかったのは単にサクラエディタがRubyのアウトラインをサポートしていないというだけの理由．
Python(というよりDjangoは)HttpResponseなどの処理を使うたびに個別にimportしないといけないのが面倒くさい．マニュアル見る→記述→実行→存在しないメソッドとエラー→どのモジュールにあるのか調べる→ファイルの先頭に戻って記述．けっこういらいらする．1つ指定すれば関連ファイルをすべてインポートするまとめモジュールみたいなものを作ることも可能なのだが，そうはなっていない．
ただ，この点はDjangoが発展途上でマニュアル整備が貧弱なせいもあるだろう．メソッドの使い方についてはマニュアルがあるが当該箇所を見つけるのが結構大変である．メソッドの説明とincludeが必要なモジュールを併せて記述したリファレンスがあれば解消できるだろう．
PythonとRubyを交互に編集していると混乱する．特に文字列．
Ruby: "fileName #{file} Size: #{size}"
Python: "fileName %s Size: %d" % (file, size)
やっぱり全部Rubyに統一した方がいいかもね．
Djangoで画面を作るのが大変．出力用テンプレートについてはサンプルが無いので，簡単なものを一から作った．流行のWeb 2.0風グラデーションとは無縁な状態．Djangoはテンプレートの継承ができるので，スタイルテンプレート集があればうれしい．
サーバとクライアントの通信はJSON．Djangoにはdjango.utils.simplejson というのが入っているので，simplejson.loads(), simplejson.dumps()でエンコード・デコードが可能．Rubyではこのページのライブラリを使った．今回は両方向でJSONによるデータ交換を行っている．
Ruby, Python両方に言えることだが，例外への考慮が難しい．例外が出る可能性のある位置と型がわかっていないと怖い感じがする．動的片付け言語ではメソッド定義を見ても実際に渡されるオブジェクトの型はわからないのsで，追いかけるのが大変だ．
Comments