カテゴリー: プログラミング

最近は仕事や家事関連で忙しくて、システムのメンテなどしかできなかったが、
両方とも落ち着きつつあるので、必要なシステムを作って行きたいと考えている。
最近の新しい言語に移行することも考えたが、基本的にはWEBアプリが主流であることには
変わりがないと思っているので、とりあえずは使い慣れたPerlのまま続行していきたい。
そんな時にお世話になるので、「CPAN」。
でも最近はCPANのShellではなく、CPANMが流行っている模様。
簡単に導入できるが、少しメモを。
・インストール
　sudo cpan App::cpanminus
・更新
　sudo cpanm –self-upgrade
ここで少しつまずいたところ。
・CPANサーバの再設定（最近国内サーバが減っているような・・・）
　（cpanに入って）
　o conf init urllist
・sudoでのPATH設定
　sudo visudo
　（secure_pathに必要なパスを設定）
と、言ったところ。
WEBフレームワークが乱立していて、どれを使うのがベストか判らない状況。
とりあえずCakeを使っていたけど、WEBアプリを考えるとやはりPerlのフレームワークが
必要ということで、Mojoで構築予定、また、Upします。

最近書き込み少し減っております。
仕事がばたばたしており、なかなか集中力が高まりません。
ただ、プログラムなどの作業は、Win8タブレットを購入したこともあり、
平日でも作業できています。
さて、今回はWin8タブレットにいつものPerl環境をつくろうとActivePerlをインストール
してみました。
まず引っかかったのが、DOS窓でPerlを使おうとしたら、「Perlみつかりません」でした。
Pathは通っているし・・と、DOS窓でSETしてみたら、なんと環境変数PATHに、
C:¥Perl¥binが入ってない・・
なんでWin8の設定が反映されていないのか・・と、再起動したら、認識しました。
DOS窓の設定はDOS窓を開くたびに設定しているんではないんですね。
すこしはまりました（５分くらいですけど）。
もう一つが、タイトルのPPMです。
いつもSHELLから使うので直接GUIのPPMは使わないのですが、
なにげに起動すると立ち上がらず。
ppm gui failed: DBI connect……
どうも、DBにアクセスできないようです。
よく見てみるとPathに全角が入るとアクセスできないようです。
PerlはルートにPerlディレクトリを作っているので、ここのppmフォルダを指定。
C:¥Perl¥bin¥ppm.bat
の３行目に、
SET ACTIVEPERL_PPM_HOME=C:¥Perl¥ppm
で、DBを指定。
これにて無事起動しました。

先の記事にも書きましたが、
今回はJSONで配信されたレート情報をデータベースに格納します。
この作業の簡単なこと。
元もと、JAVAやPHPなどのLL用のデータ交換プロトコルなので、
当然といえば当然ですが・・
use JSON qw/encode_json decode_json/;
で宣言。
$indata = decode_json($a->content());
でindataに展開されます。
@{$indata->{quotes}}
でforeachかけて、
配列から各レートを取りだして、
MySQLにInsertするだけです。
ちょっと、ハッシュから配列取り出すところで、
書き方分からずに、手間取りましたが、
２，３時間で対応できました。

今年の最期の作業は、ヤフオク関連だった。
いま、まさにこの時間までプログラムの修正をしていた。
先日書いたとおり、ヤフオクAPIからの商品リストの取得が、
50件から20件に縮小。
当然に処理自体は重くなり、今まで１日で処理仕切れたものが、
1.8日程度かかるようになった。
その結果、積み残しが大量に発生し、結果的に取得漏れが発生していた。
DBの処理能力を向上させれば解決できるが、そんな予算もないので、
プログラム上の工夫でなんとか高速化できたはず。
今テスト中だが、1/1の0:15からの処理で、いきなり本番適用されるように
設定をしている。
若干の取りモレが発生するかもしれないが、ヤフオクばかりに時間を使えない・・・
来年の目標を立てる時間もなかったので、
１／１に目標を立てて、作業を進めていきたい。

今、作っているシステム。
大量のデータをネット上から収集している。
新しく作ったシステムのテストが完了し、
今週から本番運用していたが、かなりの処理速度の向上のはずが、
全然成果が上がってこない。
もしかして・・と先ほど確認したら、案の定肝心な部分が
テストモードのまま可動していた。
大きなシステムを作るときは、起動オプションで本番、テストの
切り替えをしているが、比較的小さなシステムなので、
ソース内にフラグを作っていたが、モジュールの一つが
テストモードになっていた。
処理完了フラグをセットする部分で、結局、従来のシステムと、
今回のシステムと同じものを二重処理していた。
ほんともったいない・・・。
この間の電気料金の試算もあるけど、無駄な処理は環境によくないので、
今後気をつけたい。
（と、いう気持ちを忘れないために、このBlogに反省文を書いておく。(^^;）

今日、久しぶりにに、VisualC++6.0で、
SAPI5.1なプログラムの修正をした。
開発当時現役だったリアルマシンは既に無く、
環境はメインマシンのMacmini上の、
VirtualBoxに乗っけている。
今までは軽い修正が多くて、
全てのソースを全コンパイルすることはなかったので
気がつかなかったが・・・
なんとSRなソフト開発環境なのに、
SAPI5.1が入っていなかった。
そんな訳で、MSからSAPI5.1のSDKをDLして
インスト。
その後、VisualC++6.0の「ツール」「オプション」
で、インクルードファイルと、ライブラリ場所を指定。
C:¥PROGRAM FILES¥MICROSOFT SPEECH SDK 5.1¥
以下に導入されている。
これでやっとプログラム修正できる・・・。
古いソフトの開発環境って、みなさんはどうしているんでしょ。
リアルマシンで置いておくわけにもいかないでしょうし、
OSをUPしていくと、環境が変わって開発できないし・・・

急にヤフーデベロッパを利用していたシステムが動かなくなった。
エラーの状況を見てみると、xmlパーサが落ちている。
よくよく見てみると、コンテント部分がgzip圧縮されていた。
なんの予告もなくひどい話だ。
WWW::Mechanize::DecodedContent
を利用して、事なきを得た。
あっ、全然逆襲じゃなかった。(^^;

先日書いたとおり、この一月は全く取引できていない。
かなりひどい状態だ。
以前も週に１，２度レートの取得に失敗していた。
ただ、失敗してもほとんどの場合は、継続して取得するようになっていた。
それが、４月を過ぎたころから、エラーで止まるようになった。
そこで、エラーになったときの、処理を見直して、
一定期間処理を待機し、再度接続するようにシステムを修正した。
しかし、その再度接続するところで処理がうまくいかず、
結局、再処理できずに止まってしまうことが多くなり、
先週は５，６時間しか継続して取得できなくなってしまった。
今日はその部分を見直し、
evalを使わずに、一つ一つのロジックで、処理の状況を見直すようにした。
こればかりは実際に稼働してみないと、どのように動くのか予想できないので、
来週からがんばっていきたい。
とりあえずは、７月から再度きっちり処理できればと思う。

開発環境が、VisualC++6.0からVisulaStudio2010に変わったことを書いた。
基本的なMFCがかなり大きく変わっていて、便利になったのはいいけど、
かなり設定などが変わった。
その一つにメニューの表示がある。
昔のメニューは全て表示するのが当たり前だったが、
最近(?)は使わないメニューは表示しなくなり、なんどか使っていると、
最初から表示するようになる。
今作っているソフトは、メニュー項目が消えると困るので、
リソースなどを見たり、CMenu（すでにこれをみてる時点で古い・・）の
メンバをみたりしていた。
ネットでぐぐってみたりもしたけど、あまり情報がないままに、
ソースをみていると、それらしきコードが・・・。
CMainFrame OnCreate で、SetBasicCommandsへの
リスト登録。
なにやら基本メニューの登録らしく、
ここにメニューIDを登録しとくと、いつでも表示してくれる。
やれやれ。

先日から何度か書いているが、
やっとシミュレーション結果の分析をしている。
基礎データは毎週計算結果を追加。
月に一度は分析用DBの更新作業をしているが、
今回は分析用のDBを駆使して、最適な指標を作る作業を
手作業で行っている。
いつもは半自動で作業しているが、作業内容の検証も兼ねて、
SQLサーバの補助として、アクセスとエクセルを併用しながら、
内容を検証している。
その中で、レコード数が妙にすくないテーブルがあったことから、
手作業で再度集計してみると、やはり少ない。
そこで、再度、分析用DBの作業をやってみると、
「The total number of locks exceeds the lock table size」なるエラーが出ていた。
結局はメモリ不足ということで、
MySQLのinnnodb_buffer_pool_sizeを、512Mくらい割り当てて作業を再開。
Linuxの方では問題なかったが、Windows用Mysqlは微妙にその辺の頑丈さが
違うようです。
いつもは、FX取引用サーバの空き時間を使って作業しているが、
かなりの負荷をかける作業をするので、作業DBをWindows上で行ったのが原因。
同じ４Gのメモリを積んでても、メモリ管理などが違うので、使うソフトに応じて
かんがえていかないといけない。