あると思いますが、もちろんコストも手間も結構かかってきちゃいます。導入しようという選択肢をとる場合があります。もったnginxでキャッシュサーバーを立てる方法を公開します。linux最少構成でインストールしてyumでインストールするだけです。必要な項目を追加していきます。これでキャッシュサーバーの完成、hogehoge.jpにアクセスするとfumfum.jpをキャッシュして返してくれます。変更が必要ないので導入リスクも低いです。複数台用意してDNSラウンドロビンで簡単に負荷分散なんかすると、かなりコスト効率のよい負荷分散構成になります。導入したいなどあれば以下から問い合わせください。研修をかねて社内のシステムをpythonのフレームワークdjangoを使って書いてみています。rails」と並んで有名なWebアプリのフレームワークです。フレームワークの学習ってコストが高くつくので、本格的なものはRailsくらいしか使って試したことはないのだけど、確かに定型的なプログラムには便利です。自由度が高くて、よくあるフォーム入力の画面なんかも、全部システムにお任せから、テンプレートだけプログラマが書く場合、全部プログラムする場合など、柔軟な仕組みになっています。非定型的な部分は結局人間が書くしかないので、ここは生産性の向上は見込めませんが、定型部分なら、シコシコとコードで書くより2~3倍くらい生産性が上がりそうです。実際上記のようなフォームを生成するのに、以下のようなコードを書くだけです。重要なのは、7行目のmodel=Itemの部分と、exclude=xxxxxの部分で、どのモデル(テーブル)に対する編集画面かを指定し、excludeで入力しない項目を指定しています。このフォームをas_p()メソッドとか、as_table()メソッドとかで出力すると、そのまま、htmlコードが出力されます。formオブジェクトをテンプレートに渡して、「{{form.name}}」のような形で組み込むと、その位置にその項目に応じた、入力フィールドが生成されます。一方で、特に言語としてはpythonはかなり変わった仕様をして他の言語から移行するとかなり戸惑う部分もあります。慣れると便利な部分もあるのですが、釈然としないものも多々あります。普通の感覚なら、10から20までの数字が表示されと思うのが一般的です。このコードの結果は、10から19までの数字を表示します。この方法は、違和感がありますが、使い勝手はいいです。関数とメソッドとどちらにあるのか釈然としない。PHPならすべてが、関数なので、処理の内容から区分を探すことになります。Rubyなら逆にすべてがメソッドなので、どの要素を主体に考えるとかで、操作対象になるオブジェクトのメソッドを探せば、よいのですがpythonは、関数で存在するかメソッドで存在するか判然としません。文字列の長さを取得するには、phpならstrlen()関数ですし、rubyなら、length()メソッドです。pythonは、len()関数になります。文字列を小文字化するには、phpならstrtolower()関数で、rubyは、downcaseメソッドです。pythonは、今度は、lower()メソッドです。私が基本Rubyが好きなのですが、そのベースにある多様性は善という思想なのです。どちらかと言うとpythonは多様性は悪であるという思想のようです。その点では、pythonという言語はちょっとpascalに似ているような気がします。ynaRubyでSqlite3を使う2012-05-01Byyna,開発perlやrubyには、SDBやGDBというハッシュ形式でデータを保存する仕組みがあり、ランダムアクセスが可能なため比較的データ件数の多いデータに対しても有効な仕組みが提供されています。これ以上に大掛かりなデータを扱うにはMySqlやPostgreSQLのようなデータベースを使用するのが一般的です。データベースは、サービスやデーモンですので、レンタルサーバーで提供されているとは限りません。データを外部から持ってきたり、データをバックアップしたりするには、ちょっとファイルをscpやftpで持ってきたりというわけにはいきません。そこで使われるようになったきたのが、sqliteです。Sqliteには次のような特徴があります。・データベース本体がライブラリ形式で提供されるため、サービス(デーモン)のインストールなどの手順が不要で可搬性に優れる。・データベースが1つのファイルで、CPUを選ばないデータ形式のため、コピーするだけで、使用することができます。・SQL92に準拠しているので、機能的に不足はない。トランザクションもサポートされています。処理が衝突したを場合など別プロセスを待機したりせずにエラーになるので、積極的にトランザクションを使用したほうが安全です。Railsの標準DBは長らくMySqlでしたが、最近ではSqliteを標準DBとして採用しています。今回はRailsでおなじみのActiveRecordではなくて、PerlでおなじみのDBIを使ってみましょう。DBIは、データベース独立インターフェースと呼ばれ、データベースによらない独立したインターフェースを提供しています。DBIはRubyの標準パッケージに含まれていませんので、別途組み込む必要があります。次にsqlite3のDBドライバーを組み込みます。sqliteはsqlite3やsqlite3-rubyを参照していますので、必要なパッケージを芋づる式にインストールしてくれます。ユーザーはパッケージの依存関係を気にせずにインストールできるようになっています。sqliteの内部文字列はutf8を想定しています。このあたりは、いろいろな文字コードを扱えるMySqlやMSDEなどのほうが強力ですが、RubyやPerlに関する限りutf8オンリーでも不都合はありません。sqlite3.exeというコマンドライン版では不都合なことに漢字コード変換をしてくれません。そのため、Windowsで使用するにはちょっと問題があります。コマンドラインだけでデータベースを操作するのはかなり面倒です。日本語で使い勝手のいいソフトを探したところPupsqliteというソフトが見つかりましたのでこれを使ってみます。このソフトは、zip圧縮されており、それを適当なフォルダーに展開するだけで使用できます。使用するライブラリが標準的なものであれば、sqliteを使用したソフトは特別なインストーラーを使用せずに配布できるところも魅力です。なにもデータがないのは寂しいので、ちょっと簡単なテーブルを作成します。sqliteの型は、TEXT、INTEGER、REAL、DATETIME、BOOLEAN,BLOBといたってシンプルです。これを表示してみましょう。なんとか、使える状況まできましたので、そのうちもう少し掘り下げてみたいと思います。ynarubyの話(1)2012-02-21Byyna,開発Rubyにはモジュールという概念があります。何に使用されるかというと、一定のコード(関数やクラス)をグループ化をして、名前空間の汚染を防ぐためにあります。規模の大きいプログラムを書く場合や、広く一般に配布されるようなプログラムを書く場合、クラス名やメソッド名、定数名が衝突する危険性があります。moduleで全体を囲むことで、特定の機能ごとに分割して扱うことが出来るようになります。ある意味、C++やC#のnamespaceという機能に似ています。このような使い方は、CGIモジュールとかNetモジュールなどで使われています。ひとつRubyでは、mixinという用途のためにモジュールが使用されます。以下のコードのtestというメソッドは、インスタンスメソッドです。モジュールでは、インスタンスを生成できませんので、このままではこのメソッドを使用することはできません。このようなモジュールがあったとき、MyClassでMyModuleをインクルードすることで、MyModleのtestメソッドを使用することができるようになります。この仕組みを生かしたのがEnumerableというモジュールです。このモジュールをインクルードするクラスにeachというメソッドがあれば、検索やgrepなどイロイロな機能を使うことが出来るようになります。データ構造がファイルと連携しているなどの場合に、素直にArrayにすることができないことがあります。この場合、eachだけでもインプリメントすることで、全体検索に必要な機能をインプリメントすることができます。このmixinという仕組みは、javaなどで使われるインターフェース技法を一歩進めた形といえます。先日アジャイル開発の勉強会のメーリングリストを読んでいて、ユーザーストーリーを集めるって話が書かれていた。ウォーターフロー開発手法で、システム開発を進める上で最も重要なのは、「要求仕様書」の作成だと言われている。ところが、実際に完璧な「要求仕様書」が書かれることは少ない。そこでアジャイル開発では、より多くのユーザーストーリーを集めるってべきだと言っている。ユーザーストーリーというのは、ユーザーの言葉で書かれた要望のことだ。本来は要求仕様書というは、本来はユーザー側が提出するものなのだが、コンピュータの経験のないユーザーが作れることはない。実際にはシステムアナリストとか受注側SEが聞き取りをしながら骨子を固めて作っていく。この文書を元に両者が内容を認証したものが開発のベースになる。この要求仕様を作る段階で、システムアナリストや受注側SEが相手先の業務の内容やフローを完全に理解していることは、稀である。するとシステムを作りこんでいく段階で、業務とシステムの齟齬があるのではないかと疑いが出てくることになる。最悪のパターンは、実際に作成するスタッフが、齟齬に気がつかず、まったく疑念も持たずに、突っ走ってしまうことで、これも珍しくない。したときに重要になってくるのが、ユーザーから実際に聞き取りした内容である。出来るだけユーザーの言葉で書かれた要望とか、ユーザーストーリーというのを開発スタッフ側で把握しておくことが重要になってくる。必要なのは、あくまでもユーザーの言葉なのだと思う。