Posts Tagged ‘symfony’
TinyMe – Linux LiveCD ディストロ(2)
2009 年 2 月 14 日 | 
Author で、続き。
とりあえず、ApacheとPHPおよびpear経由でのsymfonyは何とかインストール出来た。ちょっと、問題といえば、phpのバージョンが古くて、Symfony1.2はインストールできず、Symfony1.1にした。今からだったら、1.2の方がよかったのだが、まぁ、1.1でもそれほど何かが不足しているというわけでもないから、よしとしよう。
だが…問題は MySQLである。どうも PCLinuxOSが配布している MySQLのパッケージだと、ライブラリの依存を解決しようとして、新しいライブラリを入れようとするのだが、そうするとイモずる式にそのライブラリに依存しているもろもろがアンインストールされてしまう。
なんとかここまで
その過程に何か「やってはいけない何か」が含まれるらしく、その後 X が起動しなくなる。Xサーバーの起動の途中でなんかのドライバがないだかなんだかと怒られて Xの起動に失敗し、コマンドプロンプトに戻ってしまうのだ。
ちょっとだけ調べてみたが、容易な解決方法はなさそうだし。このコンパクトさゆえの制限でもあるから、残念だが MySQLはあきらめることにした。
とはいえ、RDBMSなしでは、Symfonyのいいところが半分以上削がれてしまうわけで、MySQLはだめでも、他の何かで代用しなければならない。
とはいえ、Symfonyで、すんなり使用可能そうな選択肢といえば PostgreSQLかOracleか…って感じになって…し・ま・う？おぉ、そうだもっとも安直な解決策 SQLite があるじゃないかぁ～。
SQLiteはDBサーバーではない。単なるライブラリ。DB本体は、普通の1個のファイルとして作られ、そのDBとのインターフェースがSQLになっているってこと。これは、もうまさしくMicrosoft Access のDAOっていうか、Jetエンジンとまったく同じしくみだな。そういうわけで、使い方は極めて簡単。っていうか、今回はphpがSQLiteと会話するプラグインをロードできていればいいわけで、これはSQLiteのインストールと一緒にインストールしてしまった。
ってな感じで、ようやく、このTinyMeの小さな環境でSymfonyを使った開発までできる環境がそろった。メモリは192MBで、普段の使用率はだいたい30％ほどでまるで余裕。むしろ、CPUが非力だと、そっちの方がすぐ100%に行ってしまうのが悲しいところ。
この段階で仮想マシンイメージを7zipで固めると、240MBほどになる。いやぁ、まだまだ余裕だなぁ～。なんちゃって。
Posted in 
Tags: 
たまにはプログラミングネタ
こんなもんを作ってみたり
かなり、久しぶりだが、プログラミングネタ。
symfonyによるwebアプリで、郵便番号から住所を引いてくるおまけ機能を実装しようと思って、とりあえず郵便ホームページから、いつもの郵便番号と住所の収められているCSVファイルをゲット。都道府県ごとに別になっているファイルもあるのだが、面倒なので、全国版をもらってきた。
んで、これをもとに
Zip:
id:
zip7: varchar(16)
jusyo: varchar(1024)
jusyo_kana: varchar(1024)
ってな感じのテーブルに格納していきたいわけだが。
まぁ、一応 schema.yml とかは出来上がっているので、$data->loadData(以下略)ができればいいわけ。symfony1.1になって、askeetの内容のまんまではうまくいかないが、1.1に合わせていくらかいじれば、これはすんなり動く。っていうか、その他のテストデータをぶっ込むために、この壁は乗り越え済み。
てことで、あとはcsvファイルからZip:
zip_00000:
zip7: 8200701
jusyo: 福岡県飯塚市長尾
jusyo_kana: フクオカケンイイヅカシナガオ
ってな感じのレコードを全国分作成すればいいだけ…。だけなのだが…。
先ず、csvデータの面倒なところなのだが、その１は住所のカタカナ表記がいまどき半角カナとなっていること。
さらに、都道府県と市町村とそれ以降が三つのフィールドに分けられていて、まぁ、それだけだったら別に問題ないのだが、なんと「それ以降」の部分が76バイトを超えると、複数レコードに分割されるという仕様。分割されたフィールド以外は、同じ値が入っている。で、連続行がどうかって、普通に考えて「7桁郵便番号」がプライマリーキーになっていて、それで判断するんだろうと予想したのだが、見事に裏切ってくれる。だいたいは、これでいいのだが、同じ郵便番号であるにも関わらず、住所が明らかに連続ではないデータが入っている部分がいくつかあるようだ。
なんで、こんな解釈が一意にできないデータを平気で公開できるんだろうなぁ～。とか、思ったりするのだが、まぁ、いいや。とりあえず、その辺を「善きにはからい」ながら、perl でせっせと yml ファイルを吐き出させた。途中、multi-byte<=>single-byte の正規化など、いろいろ最近のperlのコード変換事情なども勉強させてもらいながら。しかし、もうお役御免とも思われる jcode.pl の記事や最近のUnicode::Japanese に記事など、かなり混沌としていて、なかなか大変なことになっているなぁ～というのが率直な感想。
で、郵便番号レコードは12万件ほどあって、上記のようにymlでは1レコードが5行ほどになるので60万行以上の巨大なファイルになる。さすがにこれを1レコードずつpropelのオブジェクトモデルに従って、いちいちハイドレートしながらsave()していくと思いきり時間が、そしてリソースが必要となる。
で、windows上のちょっと古めの環境でやっていた時は、時間はかかったが、特に問題なく終わったのに、こんど同じymlをUbuntu8の環境で実行すると、途中からymlの内容を標準出力に吐き出して、さらにはそれも途中で終わってしまう。
当然、commitされないので、dbの中はからっぽ。読み込ませる yml が小さい分には問題なさそうなので、どうも使用リソースで制限がかかっているくさい。ってことで、つらつら見ていると、/etc/php5/cli/php.ini にResource Limits なんてブロックを発見。ここに、memory_limit = 32M なんて記述がある。ymlだけで16Mあるのに、これで足りるわけがない。んで、これを128MにUP。して再実行。おぉ、標準出力へのお漏らしは止まったぞ！が…、結局しばらくすると、勝手に終了してしまう。最初は、おぉ、えらく早く終わったぞと感心したのだが、mysqlでのぞいてみると、やはりcommitはされていないようだ…。しくしく。
で、再度、さっきのResource Limitsのブロックを見てみると、なんと「max_execution_time」なんてのがあって、これが30とかになっている。もちろん、30秒のことなので、これではお話にならない。こんどはこれを3600に書き直して、再チャレンジ。やはり、時間がかかったが、なんとか12万件のレコードを登録することができた。
以外と、いろんなところではまるなぁ～。としみじみ。
「symfony」とCDからの取り込み失敗
ところで、すでに翌日なんだけど、朝起きて、鬼束の「This Armor」を聴きながら、symfony のお勉強していたら…。
ちなみに、symfony は何もtypoではない。symphonyではなくて、symfonyなのだ。php5でWebアプリを作成するフレームワーク。ここのところ、自分にとってWebアプリと言うとASP.NET一辺倒 だったので、追跡がすっかりおろそかになっていたのだが、Linuxサーバ環境でのWebアプリ作成ベースの進化もASP.NETに負けずにすごいことになっていたのを実感。そういうフレームワークがスラドとかで話題になるた びに少しは気になっていたのだが…。
で、これまでちょこちょことしか、いじったことのなかった php も仕組みや構文から見直しているのだが、基本は unix 由来のスクリプト言語なので、perl歴が異常に長い自分的には、ほとんど違和感はないっていうか、そういえば、前にも同じようなことをして、php4のマニュアルをざ～っと通して眺めたことがあったなぁ～、だからかぁ～。それに、これらの言語はやっぱり少なからず perlの影響を受けざるを得ないわけで。もちろん、言うまでもなく phpはより「埋め込みスクリプト」としての使われ方を意識した言語になっているし、いろいろと新しい機能や概念が付加されているわけだけど。
symfonyは、まだ勉強中なのでなんとも言えないが、とりあえず強く結び付いている IDEとかがあるわけではなさそう。もちろん、ASP.NETだって Visual Web Developer がないと書けないってわけじゃないけれど、開発環境としてはほぼセットって感じだった。そういう意味では、symfonyには VWDに対応するものはなさそうだ。ただ、VWDが標準で作成するディレクトリツリーとか、ページのテンプレートとかに対応するものは、CLIのコマンドを叩くことで、自動生成してくれる。まぁ、いかにも伝統的なUnixユーザが喜びそうなしくみだ。っていうか、自分もこっちの方がしっくりくるというか、気持ちが良かったりする。
まぁ、まだほんのとばぐちなので、これから、なんか気づいたら書いていこうかとも思っている。
で、話は戻るが、「This Armor」をかけながら、お勉強していたのだが、途中で「ん？」、なんか音が濁っているような気が…。と思って、気になったので、原盤と聴き較べてみる。が…、残念ながらよくわからん、が、原盤の方だと通して聴いても、「ん？」と思う濁りに気づかないので、確かに違うようだ。
実は、昨日はCDから取り込む時に、最初、昔LPからディジタル化した伊藤銀次のCD-R2枚を再度取り込んで, SoundEngineでちょこっといじってから焼きなおすということをしていた。その取り込み時に、取り込みソフトで「Normalizeする」設定にしていたのだが、どうもこれがいけなかったらしい。同じ「This Armor」を「Normlizeなし」で取り込みなおしてからCD-Rに焼き、聴きなおしてみると、若干音がクリアになり、鬼束のボーカルの後ろにたまにかすかに入っているコーラスとかがちゃんと聴こえるような変化がみられた。ってことで、昨日コピーした残り2枚も取り込みなおしだなぁ～。