tkfm.net

またまたまとめて2週間分の報告です。元本150万円もあったはずなのに、今はこの価格... 約5分の1まで減ってしまいました。(涙)




東理ホールディングス(5856)は、自己株の取得を発表。3,000万株／3億円を上限としたものです。巷の掲示板では「10円以下はお買い得！」なんていう書き込みもありますが、9億株以上もある中で、3,000万株の自己株取得が影響あるとは思えません。それより、この不動産不況の真っ只中の今期に、3億円ものお金を自己株取得に使えるほど経営に余裕があるんでしょうかね～?

井上工業(1858)は第三者割り当て増資を発表。あ～あ、結局こうなってしまうんですね～　怪しげな投資組合からお金を調達しないと資金繰りが厳しい... それが井上工業の実態なのですよ。宮崎前社長も主要株主から外れたようですが、現経営陣の中にも癌が居るみたいです。

どの銘柄も良い発表はありませんね～　一体私の資産はどこまで縮小するんでしょうか?


SBI証券のFX口座開設が終わり、試しに買った豪ドル／円ですが、買ったとたんに急落！　「もう下げ止まり」と思って追加で買えばまた下落... FXでも大きな評価損を出してしまいました。維持率が150%～170%ありますので、とりあえずこのまま放置します。スワップ狙いのつもりは無かったんですが... 豪国経済もあまりいい発表はありませんし、買値に戻るのは何年かかかるかもしれませんね～グスン(涙)

このサイトではありませんが、サーバーとしてXREA+を使ってます。そこでMODxとWordPressを最初にインストールしたものがあったんですが、これがまたMySQLの設定を良くわからないままやってしまったんで、MySQLのDB内で文字コードがおかしくて化け化けな状態... XREA+の管理画面でEUC-JPを選んでDB作成してしまったのが原因。でも、DB内では文字化けのデータなのに、フロントエンドからはMODxもWordPressも正常にUTF-8で表示されるもんだから、あんまり気にしないでいました。

ということで、この化け化けデータを一旦エクスポートして、新たにUTF-8でDBを作成してそっちにデータを引っ越す作業を行いました。手順は以下のような感じ...

1. SSHができるように設定
   XREA+の管理画面からSSHができるようにホスト登録を行います。
2. MySQLの文字化けデータをエクスポート
   サーバーにSSHで接続して、以下のコマンドでMySQL内の文字化けしているデータベースを全てダンプします。

   # mysqldump -u [MySQLユーザ名] -p --default-character-set=latin1 [データベース名] > [エクスポートされたデータのファイル名]

   どうして「EUC-JP」じゃなくて「latin1」なのかは謎... MODx側から確認したら何故か「latin1」でデータの出し入れをしていたので...笑(いい加減だ！)
3. 文字コードの変換
   次にエクスポートしたデータの文字コードをUTF-8に変換します。

   # nkf -lw < [エクスポートしたデータのファイル名] > [変換後のファイル名]

   これを新たに作成したUTF-8のDBにインポートして、MODxとWordPress側で新しいDBに接続するようコンフィグを修正すればOK！

ということで、DB内も文字化けの無いクリーンな状態にすることができました～
それにしてもMySQLの文字コードは難しい... もっと勉強しなきゃね！

お盆休み明けの日経は、あいも変わらず下降路線... 12,500円くらいまでは間違いなく下がるだろうなぁ～なんてチャートを見て根拠もなく考えていましたが、そういう予想は絶対外れないものですね～笑


この週は一時33万円台まで評価額が下がったこともありました。東理ホールディングも為すすべなく7円を付けましたし、どの手持ち株も年安をうろちょろ... 何度も叫んでいますが、元本150万円ですよ～　それが今や33万円... 株って怖い。笑

しかし、いろんな掲示板では9月から日経も持ち直し上昇基調に変わるなんていう投稿もちらほら出始めています。そうなれば嬉しいんですけどね～　そこに中間決算が好成績なんていうIRが出たら... 年末まで上昇基調は続くかな?... って、絶対そんなことは無い！(断言)


FXは96.1円／ドルで買った豪ドルを久しぶりに長めに保有してます。だって、買値に戻らないんだもん！笑　最初から中期保有の狙いなんてありませんよ～　さて、スワップがどこまで増えて決済できるんでしょうかね～?

分解掃除で爆音が静まった我がメインPCのDELL Dimension5150C ですが、1GB載せていたメモリの増設を行いました！

先の分解清掃の際に内部を確認したところ既に512MBのメモリが2個実装済みで、合計で4個あるメモリスロットの2個を使用していました。ということで、まあ1GBを2個買って、合計3GBとしようと計画を立てました。メモリは画像の「上海問屋セレクト」品を選んでみました～　DDR2 PC2-6400 の 1GBメモリの2個セットです。既に先客の声によると5150Cでも動作済みとの書き込みがありましたので、安心して注文を出しました。本体￥4,299＋送料￥210の合計で￥4,509です。届いた品物はトランセンドのJetRamでした。

実はデスクトップPCのメモリ増設はほとんど初体験...キャァ～笑　案外スロットの差込みが堅くて、最初はメモリをスロットに入れられませんでした。だって、マザーボードがメキメキと音を立てて反るんですから... 私の挿し方は相当下手糞だったみたいです。Webで検索してみても、「コツを掴めば簡単にさせます」なんて無責任な発言ばかり... そのコツを知りたいんだってば！とPCの前で叫んでいたのは私です。笑

何とかメモリを全てスロットに納め、さて増設の結果は... う～ん、特別体感速度は変化無いかも...涙　ただ、仮想ファイルがほとんど使用されなくなりました。私の通常の使用(Firefoxで20ページくらい同時にタブに開いた状態)状況で、1GBの物理メモリが使用される程度です。今までメモリ使用量監視＋お掃除ソフトを常駐させていましたが、この状態だともうそれも不要になりそうですね～　残りメモリを気にする必要はほとんどありそうも無いです。少しは高熱のHDDの負荷が下がるかな～?

7bitさんのWordPressIntegratorですが、スニペットとプラグインの設置以外にWordPress側の改造が必要になるのがちょっと面倒ですね。これがまた、WordPressのバージョンアップが結構頻繁にあり、その度にWordPressIntegratorと一緒に使うための改造点が変わってしまうと言う複雑さ... 念のため、最新版のWordPress 2.6.1 日本語版を改造した時の悪戦苦闘(最近は慣れてきましたが...笑)の奇跡を下記に記しておきます。必ずしもこの順に改造をする必要は無いのですが、私が出るエラーメッセージを見ながら対処した奇跡そのものを書いてあります。他の方の参考になれば...

なお、使ったMODxのバージョンはSVN版(rev.3938)で、WordPressIntegratorは1.2.0です。

1. まずはWordPress側を何も修正しないで使うと...

   画面(フロントエンド)上に以下のエラーメッセージが表示されます。

   Fatal error: Call to a member function main() on a non-object in /hogehoge/public_html/wp261/wp-includes/functions.php on line 1111

2. 「wp-settings.php」の4箇所の「=& new」を「= new」に変更...

   表示されるエラーが以下に変わります。

   « MODx Parse Error »
   
   MODx encountered the following error while attempting to parse the requested resource:
   
   « PHP Parse Error »
   
   
   
   PHP error debug
   
     Error: 	Invalid argument supplied for foreach()	 
   
     Error type/ Nr.: 	Warning - 2	 
   
     File: 	/hogehoge/public_html/wp261/wp-includes/classes.php	 
   
     Line: 	148	 
   
     Line 148 source: 	foreach ( $GLOBALS['wp_taxonomies'] as $taxonomy => $t ) 	 
   
   
   
   Parser timing
   
     MySQL: 	0.0056 s	(13 Requests)
   
     PHP: 	0.2713 s	 
   
     Total: 	0.2769 s

3. WordPressIntegratorスニペットに「global $wp_taxonomies;」を追加...

   表示されるエラーが以下に変わります。

   Fatal error: Call to a member function set_404() on a non-object in /hogehoge/public_html/wp261/wp-includes/classes.php on line 296

4. 「wp-settings.php」の1箇所の「=&」を「=」に変更...

   画面(フロントエンド)上のエラーは無く正常に表示されますが、MODxのイベントログに以下が発生します。

   Redefining already defined constructor for class WP_Dependencies

5. 「wp-includes/class.wp-dependencies.php」の中にある「function __construct() {}」の行をコメントアウト...

   MODxのイベントログのエラーが以下に変わります。

   Assigning the return value of new by reference is deprecated

6. 「wp-includes/」ディレクトリ内の「cache.php/query.php/theme.php」の3つのファイルに1箇所ずつある「=& new」を「= new」に変更...

   MODxのイベントログのエラーが以下に変わります。

   Redefining already defined constructor for class WP_Object_Cache

7. 「wp-includes/cache.php」の以下の3行をコメントアウト...

   function WP_Object_Cache() {
   
       return $this->__construct();
   
   }

で、無事にノーエラーで動作するようになりました！