カテゴリー: 開発環境

私の唯一のWindows専業マシンが、知り合いに引き取られていく。
Pen4の1.6GHzなマシンであったが、メモ代わりのPocketPCのシンクロ用に
使っていた。（最近のＰＣにはシリアルがない）
他にネイティブマシンなので、Win32なシステム開発にも活用していた。
ただ、我が家唯一のATXケースであり場所をとるし、
昔のPen4なのでかなり電気をくう。
非常に貴重なPCだが、今、手放さないときっと誰ももらってくれなくなる。
そんな理由から今回の貴重な引き取り話のためにPCを整理する必要がある。
で、前置きが長いですが、現在シミュレーション用PCの空きHDDを利用して、
バックアップをとりたい。
そんなわけで、Sambaを設定する。
以前からなぜかwebminから設定するとどうしてもMacからアクセスできない。
今回もやはりできない。
いろいろと設定を変えてみるが、なかなか動かない。
で、結局わかったことは、以下のとおり。
・Macの標準のワークグループ名は「workgroup」である。
　LinuxのSambaをこれに設定しとくと、Macからのネットワークから参照できる。
・ユーザの管理をwebminからしない。
　UNIXユーザを手で追加、
　pdbedit -a user
　で、追加。
・　Linuxディレクトリのユーザ・グループの設定を適正にする。
これで、Macから作業できるようになった。
今まで気になっていたのでよかったよかった。

今日メインのサーバを再起動した。
再起動した理由は、
・　新しく買ったディスプレイの解像度に対応させる設定をする
・　デーモン化したプログラムをきれいにする
というものであった。
ただ、うちのPCでは再起動をすると、
・　NICを手動で認識しないといけない
・　NICのIDが不正な値になり再度一から設定が必要
・　各種サービスなどを手動で起動しなくてはいけない
・　dom Uのサーバの起動でいつも手間取る
など、かなり面倒。
サブの方は全部自動で起動するので、サブをメインにして、
メインをサブにしても良いのであるが、設定を変えるのも面倒で
躊躇している。
今回のメインである解像度の変更については、
うちのCentOSで対応しているドライバは、現在のディスプレイの、
1600×1050に対応しておらず、ATIからドライバをDLして組み込む必要がある。
普通にソースを置いてくれたらいいのに、いらぬ親切でインストーラで組み込む。
なにをどこにいれるのかわからず怖いが、型番も合致しているし、
OSもポピュラーなもので、そんなに危ないことにはならないと納得し、
インストールをした。
・・
画面が砂嵐・・・
全く話にならない。
だから、インストーラーは嫌いだ。
テキストモードに切り替え、xの設定を標準のvesaドライバに切り替え、
結局、1280×1024に戻した。
あとXenも調子が悪く、DBサーバの立ち上げがうまくいかない。
なんだかんだで結局半日くらいを費やしてしまった。
本当はもっとFXや他のシステム構築に時間を使うつもりが、
機械的な作業でつかれてしまった。
今週も同じ指標を使ってデモトレードをしていくつもりである。

今日の朝からデモ口座からのレート取得をしている。
本番運用を始めてからは本番口座からレートを取得していたが、
今回のAPIサービス停止で当面の指標作成の基礎データを取得する必要もあり、
デモ口座から取得を試してみたが、現在のところ順調に取得できている。
今回の件で、証券会社のAPIサービスは信用ならぬことがわかったのは、
今後のシステム構築には良い教訓となった。
と、言っても、最初からひまわりとの併用をしていたので、
完全に信用してたわけではないのですが・・
ひまわりはWEBからレート取得、取引をできるようにしており、
クリックに関しても同様の手法で取引環境を構築できると思う。
ただAPIがなくなった以上、信用ならぬクリック証券でやり続ける意味もなく、
やはり信用のあるところ（ひまわりなど）で取引を確実にできるように、
詰めていく方が良いかもしれない。
今週いっぱい考えたいと思う。

先日の大損失から日々精進を重ね、
かなりリスクを限定できるシステムを作ることができました。
この土日はいつものようにシミュレーションを重ね、
月曜日からの指標の抽出などを行ってきました。
いつものように、レート取得システムと発注システムを稼働させると
なぜかエラーを表示します。
なんでかな・・と、見てみるとクリック証券のAPIが反応していない。
こんな時間までメンテとは大変だなぁ・・とのんきにクリック証券に接続すると
API終了のお知らせが・・
日頃は自分のシステムで取引をしており、WEBを見ない私が悪いですが、
先々週の月曜日に発表されたようです。
発表から２週間で中止・・・。
WEBを見てみると、悪用した業者がいてたようです。
いままで構築したシステムがかなり組み直しが必要になります。
レートに関しては、ひまわり証券から平行して取得できますが、
注文などがAPIでかなり安全に注文できていたものが、
WEB経由で注文する必要がでてきそうです。
この大がかりな修正は１，２日ではできないと思いますので、
また、ぼちぼちとやっていきたいと思います。
ここまで検証などのシステムを構築したので、
これまでの経験を無駄にしないようにしたいと思います。
本当は新しい環境などについて書こうと思っていましたが、
もうすこし落ち着いたら書こうと思います。

昨日購入したシミュレーション用PC。
いつも組み立てて、さくっとOSをインストール。
いつもなら１時間程度の作業であるが、今回は動かない・・。
機械的に動いていない。
試行錯誤で、マザーかメモリが不良なことまではわかったが、
それ以上は環境がないと解明できない。
結局購入した寺町のＪ＆○に行き、症状を見てもらう。
「メモリがくさいっすね・・」ということ、やはりメモリかぁ・・
結局、メモリを別のものに変えるとあっけなく動作。
半日の作業が無駄になってしまった。
OSはいつものCentOSである。
DVDからのインストール、その後環境を整える。
とりあえず、Telnnetで入れるようになれば、
リビングのPCと暫定のキーボードを切り離し、
自分の足下においておける。
本来はOSを含めた環境整備もさくっとおわるが、
今回はなぜかPerlモジュールがうまくはいらない。
原因は「DateTime::Format::MySQL」、これはうちのシステムでも
ないと動かないのでどうにかして入れたいが、どうしてもテストでこける。
エラーを見てみると、「Weak」がない・・とのこと。
そんなこと言われても要求されたこともないし・・、いったいどこでなくなったのか。
WEBで調べると、「Scalar::Util」を入れ直すと良いらしい。
うちはWebminで見ても入っていないので、CPANで直接入れる。
あとはさっくり動いた。
ふーー

現在はUSD/JPYのみで取引をしている。
理由は、スプレッドは狭く、流動性がある、ということが一番だが、
以前にこの通貨ペアを中心にシミュレートして、
そのシミュレート結果から、煮詰めていき、現在の指標が出来上がった。
ただ、この中で数十の指標を作っても、所詮は同じ通貨ペアであり、
リスクを低減したとしても限定的である。
そんなわけで現在他の通貨ペアについても、前回と同様の基本的な計算を
繰り返しているが、４台のＰＣで分散して処理しても、
あと半月くらいはかかりそうな感じである。
しかもこの計算をしている間に３週間がすぎ、その３週間分も追加で処理を
しようとするとどうしても処理が追いつかない。
結局はロジックを根本的に見直すか、力業でマシンを増やすか。
ロジックを見直してスピードアップは、実は比較的簡単にできる。
今は実取引と同じように処理しているので時間がかかっている。
ただ、これはいろんなシミュレートをして、そのまま本番に使うという
基本的な考え方からすると、修正してしまうので、気が引ける。
そんなわけで力業になるのであるが、現在の家の環境からすると、
あまりPCを増やすことはできない。
ベランダにだして処理しようとおもったが、夏場が非常に心配だ。
そんな時に、AmazonEC2を思い出した。
これはクラウドコンピューティングという技術で、マシンを間借りできる。
しかも初期費用無料で、時間単位で借りられる。
今、つかうとすると、１時間0.2ドルのマシン。
CPUは５つ分、メモリは1.7GB、HDDは350GBという構成。
メモリはぎりぎりだがなんとかなりそう。
そこで１月分の金額を計算する・・
一月744時間、0.2ドルで・・あとデータの管理費用と・・・で、
約15000円と算定された。
うーーん、微妙。
たしかに他のレンタルサーバとかに比べると、時間単位で使えたりして非常に
便利だけど・・
ちなみに、土曜日に寺町でリサーチした結果。
Phenom9550、4G、1TB、小型ケースで約40,000円
３ヶ月で元がとれる。
利点欠点あるので、もうすこし検討したい。

昨日の夜にメインサーバが急にダウンした。
かなり安定して動作していただけに、ショックが大きい。
原因ははっきりしない。
落ち方からするとハード的な不具合であったと思われ、
特に電源が弱ってきている可能性が高い。
あと、清掃をしていないことで、ほこりがたまってしまい、
熱がこもったりした可能性もある。
そんなわけで電源を抜き、細かく掃除してみた。
かなりのほこりで、ほんとに今まで動いていたのが不思議だ。
CDドライブはインストールで利用しただけで、今後使うこともないので、
エアフローと電源容量確保のためにはずした。
もともと小さな筐体のPCなので、効果的だと思う。
電源は外から見る限りは、コンデンサが破裂したりしていないようなので、
もうしばらくこのまま使うことにする。
ただ、来年の夏はむりだと思うので、それまでにまた環境を考えたい。
実は今日の夕方から日本橋に行き、新しいPCを作ろうと考えていた。
現に軍資金も用意し、会社にもその旨を伝え、準備万端であった。
それを確認した夜、買いに行く前日にダウンした。
以前にも新しいPCを買おうと思ったときに、いきなり今までのＰＣに不具合が生じるような
ことがあった。
このような現象は結構まわりでも耳にする。
やはり昔でいう「マーフィーの法則」はあるんだと思う。
今回の復旧は、サーバ設置時にばたばたしていて、基本をあまり勉強もせずに
いきなり構築してしまい、構築時のメモもあまり詳しく書いていなかったので、
ちょっと復旧に苦労した。
DomUのDBサーバのネットワークが外部にでれなかった。
原因は、すぐに思いついたが、その対策がわすれてしまって、
思い出すまで試行錯誤した。
前にも書いたが、うちのマザボのNICは、r8168なのでうちのCentOSでは認識しない。
insmodするまではいいが、その後のDomUの設定をするタイミングがずれてしまっていた。
今度からは間違えないよう、メモを残した。
ほんとはカーネルがさくっと認識してくれるといいんですけどね・・

やはり、基本はできるだけ多くのバックテストを行うことが必要。
今、試しているロジックの最近までのシミュレーションの処理ができていないので、
処理をしていくことにする。
今までは、各々のサーバで計算をし、結果も同サーバに格納。
シミュレーション結果テーブルを併合していた。
ただ、今後は継続的に、しかも都合の良いPCで適宜処理できるようにしたいので、
システムの修正と環境を整える。
今のメインマシンは、レートの取得、デモ口座の取引、本番処理、代替レートの取得を
平日行っている。
日々の負荷はさほどでないが、こちらのサーバはシミュレーションの結果を受け取るだけ
にして、重たい処理は他のＰＣで作業をする。
で、実際の作業であるが、
Mac上のVirtulaBoxで動かしているCentOSは全然問題なし、
AcerPower1000は、MySQLのデータをインポートする時にエラー、
GatewayのNotePCは、同じくインポート時エラー。
結構、いろいろと試したけど原因はWindowsということしか共通事項がない。
MySQLにインポートする時のファイルサイズに8Gの制限があるのか・・という想定の上、
今、シミュレーションに直接関係のないテーブルを削除した上で、dumpして、
インポート作業をしている。
どうなることやら・・やはり、このような作業はWindowsよりもUNIX系の方がいい・・

今でも私のメインマシンはMacminiである。
なんの不自由もなく、必要な作業はサブマシンたちが手助けしてくれる。
データベースはサブマシンで運用しているので、特に必要性は感じ無かったが、
やはり、メインマシンのMacでも運用ができるようにしておかないと、
なにか有った時には非常に困ることになる。
そんな訳で、うちのMacminiに、運用のための環境を作った。
まずはMySQL。
これはLinuxやWindowsでは手慣れたものである。
・　MySQLからサーバをDLする。（パッケージにした）
・　インストール（StartupItemsも入れる）
・　とりあえず起動。
　　(/Library/StartupItems/MySQLCOM/MySQLCOM start)
・　MysqlAdministratorを使ってrootでログイン。
・　rootパスワードの設定。ユーザの新規作成。ゲストユーザの削除。
コマンドラインからmysqlコマンドで作業するだけ。
次にCPANでも必要な開発環境。
よく考えるとこの間の修理から帰ってきてから、Xcode入れてなかった。
・　Xcode3.11は、X10.5以降らしい。
　　ちょっと寂しい。2.5をDL
・　本体インストール。WebObjectもインストール。
まださわってないけど、前に使っていたのは2.0の時代。
だいぶ変わっているかもしれずに不安です。

いつもはFX関係の記事を書いているが、
本当は機械を組み立てたり、システム環境を作るのが私の趣味である。
そんな訳で、新しい環境などができるとついつい入れてしまう。
知ってる人は知っているとおり、OpenOfficeはバージョンが3.0となり、
だいぶ見た目もよくなり、安定している。
これはMacですでに導入済みで、すでに活用しているのであるが、
FXのデータ分析は、Linux上で行っている。
Linux上のOpenOfficeも3.0にUpdateすることとした。
rpmからさくっと入れる。
calcも快適に動作する。
さて、メインのBaseで作業をしよう・・と作業に入る。
baseがJREをみつけれない・・おかしい・・。
JREは手で新しいものにUpdateしている。
sunのHPから最新のものをいれている。
HPなどで見たり、いろいろといじってもうまく動かない。
動作しないのはbaseだけであるが、2.4に戻そうか・・・
と、思ったときに、JREは64bitとしたことを思い出した。
OpenOfficeを入れるときに64bitを入れた覚えがない。
もしかして・・と、JREを32bitにするとあっさり認識した。
貴重な２時間の時間が消えた。
皆さんも気をつけてください。
OpenOfficeとJREは、Bit数を合わせましょう！！