つまるところ、どうなんだ？

昨日、Fedoraの更新を行いました。
大体週に一度更新しており、昨日もその定期更新です。
で、更新パッケージ内容にkernelが含まれていたんですね。kernelを更新するとNVIDIAのモジュールもついでに更新することになるため、次回起動時にはひょっとしてBerylがちゃんと起動するようになっていたりしないかしらと期待してたりしました。
で、今日Berylを起動して見たところ、なんと今のところ安定して動いています！ これだからなかなか再インストールには踏み切れないんだよなぁ・・・＾＾；
実際のところ、まだ今日１日しか様子を見ていないので、明日起動したらやっぱりダメという可能性も十分に残されているので油断は禁物。
まぁでも、昨日まで使っていたkernelとNVIDIAモジュールの組み合わせだとほぼ100%BerylのせいでXが再起動するという状態でしたので、それから考えると非常に安定しているといえますね。
ん〜、明日も使ってみて安定しているようなら、kernelは更新対象から外しておこうかなぁ・・・。そこまで頻繁に更新しなくても特に問題にはならないと思うし。
くそぅ、HDDに空きがあれば別パーティションに新しいFedora放り込むんだけどな。無駄に64bitとか。
ただ、HDDやっすいのよなぁ。320GBが8000円切るとかどうなってんのよと＾＾；幸か不幸かそんなに困っている訳ではないからなぁ。音楽パーティションがそろそろやばいから引っ越したいというのはあるけど、それ以外はなんだかんだでやっていけてるし。
けど今DLしてる全45曲収録の「Final Fantasy VII: Voices of the Lifestream」がネット上で無料配布中を共有パーティションに置いたらえらいことになりそうだ。なんと2.2GB。音楽パーティションの残り容量が3GBなので、あっけなく空きを食い潰しちゃうよ（ぉ
ん〜、いよいよHDDを追加する時期が来たか・・・？ それともまたいらないデータを整理して誤魔化すか・・・？
ちょいと逼迫してきましたよ、と(苦笑)

えんがちょ

とあるアルゴリズムをちょっくら拡張してみたのが昨日で、今日はその効果を検証してみました。
結論。使えねぇOrz
従来の方法に対してアドバンテージ何かないかなー？と色々と調べてみましたがなさげ。きっちり理論を詰めて実装した訳じゃないけど、ちょっと予想GUY! 逆にうまく動作しない原因を調べないとだめだな。そこを詰めたら改善できるかも。
もしくは、他の手法と組み合わせるかだな。今原因不明のフィルタ係数発散を起こしているアルゴリズムがあるからそこのフィルタ係数更新の部分に組み込んでみるかな。処理的に重くてメモリ量が増えるけどそれに見合っただけの高速化が得られるなら救いがあるさ、うん。
にしても卒業するまでにそれの理論をがっつり詰められるかなぁ・・・？ ・・・、今のうちに行列の勉強しといた方がいいかしら・・・？

私も、確認出来ました

今日は入社前研修の教材のお勉強をやってみました。
電気回路の教材で、学習編をやり、その後試験編をやってその結果をエクセルに貼っつけて提出しろというものでした。
で、横着していきなり試験編やったんですよ（ぁ なんとかなるかなーと。
はい、見事撃沈（チーン
100点中40点 サーセンwwwww
問題自体はそこまで難しくは無い（簡単でもない）ですが、なんせ時間が無い。20問問題があったんですが、1問5分。戻ることは出来ず、5分以内に答えなければ勝手に次の問題に進みます。
ふっつーに回路の計算をする問題とか出てくるのでもう必死。おまけに事前に勉強もせず、いきなりやったもんだからもう大変。
ということで、今回やったのは提出せず、ちゃんと学習編やってから再挑戦します＾＾； あまりにもふがいないですからねぇ・・・。ズルはするもんじゃないですね（当然
20日が提出期限だから早めにやんないとな。
で、昼過ぎに後輩へ研究の解説。B4にコールバック関数の扱いやらポインタやらエンディアン、ダブルバッファリングとかを理解しろと言う方が無理なのは分かってるんですけどねぇ。それが卒研なんだから仕方ないよね。
とりあえず私がいるうちはある程度説明できるけど、いなくなった後が心配だなぁ。私以外に実装を把握している人間が居ないから、彼が綺麗に引き継いでくれないとちょっと面倒なことに＾＾；
大変だろうが頑張ってもらわなくては。
で、そいつを片付けた後、しばらくぐて〜っとしてたのですが、昨日から引き続いて行っていたプログラムの修正を開始。アルゴリズムは合ってると思うんだけどな〜と思いつつ眺めていたら、2ヶ所ほど間違い発見。分かりにくい間違いなんだよねあそこ＾＾；
時間領域での畳み込みは周波数領域では積になるけど、配列への要素の詰め方を間違うと全然違う結果になるからなぁ。今後も気をつけなくては。
で、それ修正して動作することを確認。元々あったアルゴリズムの拡張だけれど、理論を突き詰めるのはとりあえず後回しで動くかどうかを確認するために実装してみましたよ、と。
後は従来法と比べてどの程度有利かをちまちまと調べようってとこですね。理論は本気で突き詰めるとなると残りの在籍日数ではちょいと厳しいかなぁ・・・。後輩に投げるつもりで実装したけど、なんか理論まで完成させてから卒業してとか言われそうだ＾＾；
理論の解析は鬼のようにややこしいんだよなぁ・・・。できれば逃げたいぜ・・・！！！
今日中間発表のレジュメも一応作ったし、来週いっぱいでスライド作ったらOKかな。後輩のために出勤するのもしんどい話やし、Gmailのアドレス教えて、いざとなったらメッセで話しかけろと伝えておくか。
ま、夕方から夜中に掛けてしかいないけどね！（ぁ

挫折と成功

昨日に引き続き、Plaggerのインストール挑戦。
色々とやってみたけど、やっぱり依存するモジュールのインストールが完了しませんでした；；
強引に
cpan> force install Plagger
とかやってみたんですが、まぁ当然ながら動きませんでしたOrz
で、FedoraでどないしたらPlagger動くねんとググったところ、どうもYumでリポジトリを公開しているらしいと。そいつをインポートしてインストールしたらできるぞと。
な、なんだってーーー！！！
となると、今までの苦労はなんだったんだ・・・？
まぁ苦労は買ってでもしろと。そういう教訓なんだと言い聞かせ、インストール開始。
依存パッケージ260個！
どんだけ依存してんねんと(苦笑) まぁそりゃこれをCPANからインストールしようとしてもなるほど失敗する訳だよな〜と思いましたね。
で、無事インストールも終了しまして、Mixiのマイミク日記の取得に挑戦。
したんですが、フェッチ件数0。
「あっれ〜？パスワード間違ったかな？」
とか思ったんですがどうもそれもなさそう。さらにググってみますと、どうもMixiのモジュールを少々修正する必要があるらしく、そこを修正したらちゃんと動きました。
mixiって結構頻繁にログインページとか変更してますしね。今後もマイナーチェンジの度にモジュールを修正する必要はありそうです。
これでマイミクの日記はRSS化することが出来ました。WinはY!Widgetで更新状況をチェックしてますし、日記などを見るときはmixiブラウザを使っているのでRSSを取得する必要性は薄いのですが、LinuxではSuperKarambaのウィジェットにmixiチェッカーがあるわけでもなく、APIが公開されている訳でもないためRSS化できるPlaggerは魅力的だったんですよね。Sageに登録して、さらにcronで30分ごとに更新するように設定。これでLinuxでも自動でマイミク日記を取得できます。
そりゃいいんですが、cronって強制的にメール送りつけて来ましたっけ？＾＾； 実行内容をメールで送ってくれるんですが、別に無くてもいいんだよなぁ・・・。30分ごとに送られてくるのもなかなかに邪魔くさい。まぁ実行ログが見れるという点では意味があるけど・・・。
ま、気が向いたら探しておこう。やりたいことは全部できたんだし。
他にもPlaggerは面白いことができそうだ。ぼちぼち調べて行きますかな。Perl組めたら自分で色々とモジュールが作れるんだろうけど・・・、ちょいとそれはハードル高そうだ＾＾；
とりあえずは便利な利用法の紹介しているサイトとか巡回してみますかねぇ＾＾

指針となるのは主観という名の怪物

今日はPlaggerのインストールに挑戦してました。
理由はmixiの更新状況をRSSで取得したかったから。
まぁ何かとここ最近話題だし、インストールして扱うまでに持っていくのはそんなに難しくないだろうと思っていたのですが、ところがどっこい、これが完全に裏切られました＾＾；
まずPerlを今まで一度も扱ったことがなかったのが最大の敗因かも。
CPAN？なにそれ？おいしい？
とまではいかなくても(苦笑)、CPANからどうやってモジュールをダウンロード&インストールすればいいのかはさっぱり知りません。
で、知らないならググれ、たまにはインフォれってことで調べてみたんですが、なぜか出てくるのはWindowsでのインストール方法ばかり。流行りは流行りだけど、なにもWindowsでやらなくたっていいじゃないかとか思ったよ。自宅サーバといえばLinuxじゃないか！（こら
そんなこんなでなんとか参考になりそうなサイトを発見。ここでしっかりと最初から熟読してやればまだよかったものを、つい流してコマンドからいきなり実行しちゃったんですね。これが運の尽き。
CPANからモジュールをダウンロードし、展開してコンパイル。ここまでは良かったのだけれど、インストール先がデフォルトでは/usr/local/libなど。当然、ユーザアカウントでは書き込めない。よってエラー。
最初はなんでエラーが出るのかさっぱりでした。でよいさほいさどっこいさで調べてみると、参考にしていたサイトの冒頭にちゃんと書いてありましたOrz よく読め自分。
で、そこに書いてあるとおりやったつもりだったのですが、結果としては失敗しました。原因はよく分かっていません。単に己の知識不足かなと。
正直ここまで手間が掛かるとは思ってなかったんだよなぁ・・・。けど実現できたら色々と面白そうだから、とりあえずなんとかインストールはしてみたいところ。CPANの環境設定がまずってるだけだとは思うから、そこを重点的に調べて再挑戦しよう。
ぢつのところ、一部インストールに成功したモジュールもあるのですが、どこにインストールされたのか不明だったり・・・。明日最初から全部やり直そうとは思ってますが、ほんと、どこにインストールされたんだろう・・・？＾＾；

OS再インストールを拒む理由

Windowsだと割合あっけなく再インストールやるんですけどね＾＾； Linuxはほとほと再インストールする気が起きないんです、これが。
今までにも何度か致命的かもと思えるような状態に陥ったことはありましたが、その都度のらりくらりとかわしてきたんですよね。パッケージが新しくなって解決されたりとか、なんとか自力で解決したりとか。
まぁ、そんな試行錯誤の上に成り立っている現在の環境なので、かなり設定等はくちゃくちゃになっているとは思うのですが、今更直す気にもなれずそのまま放置状態。このままじゃ悪化の一途をたどるのは分かってはいるんですけれどねぇ・・・。
かつて経験してきた環境の変化としては、FC1から2になったときだったかな、ファイルシステムの文字コードがEUC-JPからUTF-8になったこと、ほぼ同時期に文字入力システムにIIIMFが採用されたこと、その後しばらくしてIIIMFもKinput2もサポートから外れ、SCIMになったこと、そしてCompizやBerylが採用されたことです。
ファイルシステムの文字コード変更は移行するかしないかで悩んだんですが（このときも再インストールは検討した）、一挙に全部ファイル名をリネームすることで対応しました。そういったスクリプトが出てきてくれたのが幸いでしたね。日本語のファイル名をつけていたのはマルチメディア系のみであり、自分のホームディレクトリ以外には影響がほぼでなかったので失敗してもシステムに影響はあたえないことから安心して実行できたというのもあります。
文字入力システムの変更は、過渡期には結構右往左往してましたね。IIIMFがデフォルトの設定となり、Kinput2がオプション扱いになったりしていたのですが、結局Kinput2に戻して使ってました。IIIMFを使っていた時期もあったのですが、あんまり馴染みませんでしたね。
その後SCIMとUIMが台頭し、さらに変換エンジンにもCannaとFreeWnn、SKKに代わりAnthyやPrimeなどが登場。なかなかのカオスっぷりでしたね。今でもまだやや混沌としている感はありますが＾＾；
今でこそSCIMが標準になっていますが、SCIMがFedoraに対応したのは割と遅かったです。SCIMは出た当時、Qtと相性があまり良くなかったため、XIMと相性の良いUIMを使っていました。Qtにqt-immoduleが搭載されるようになってようやくSCIMも安定し出し、リポジトリにも搭載されたので今はSCIMを使っています。
変換エンジンのAnthyは比較的更新が速く、そして割と高い確率で学習結果を忘れてくれるので（ぉ、今でもあまり賢いイメージがありません(苦笑) CannaはCannaでおバカな素敵変換をやってくれたものですが、学習結果が即座に反映されるので使い込んで行くと特に不便は感じないんですよね。
それに対してAnthyは学習結果を忘れたりするためなんかおバカな印象。やはり日本語の扱いは難しいのだろうね・・・。
そして登場した3Dデスクトップ。これはまだまだ出たばかりで不安定ですが、見た目のインパクトは大きいですね。派手好きな私は例に漏れず早速導入したのですが、果たしてどうにも不安定。今までもシステムが不安定になった事は多々ありましたが、どこかにヒントがあったんですよ。エラーログが吐かれるとか、同様の状態に陥っている人がいたとか。
ただ、今回は同様の事例はほとんど聞きません。Berylを有効にしていたらログイン後10分程度でXがお亡くなりに。そのときXがエラーを吐いていないのが気になる。ログを確認するのが基本だとはいわれるけれど、書いてないんだから仕方ない。
また、Xが強制再起動してから再ログインすると、今度はKDEがやたらと不安定に。いきなりKDE系のアプリがクラッシュしたり（単発でぽつぽつクラッシュすることもあれば、一斉にほぼすべてのKDEアプリがクラッシュすることもある）、デスクトップが無効になったりします。デスクトップのプロセスってなんなんだろ。あれはさすがに普段チェックしてないからお亡くなりになっても呼び出せなくて困るのよね・・・。いつも放置してるけど。アイコンと壁紙がなくなるくらいでそこまで実害はないしね。
さらにさらに、KDEがクラッシュしなくてもBerylのウィンドウデコレータがお亡くなりに。これはBerylマネージャからウィンドウデコレータの再起動か、ウィンドウマネージャの再起動を選べば復活するのでまだましな不具合ですが、これが出始めるとシステムが不安定になってきたというサインなため、やっぱり鬱は鬱ですね。
このウィンドウデコレータのクラッシュについては類似の案件が1個だけ見つかりました。原因はグラボの熱暴走ではないかとのことだったのですが、私のグラボがそこまで熱くなっていないときですら発生するのでこれは微妙なところ。
そもそもNVIDIAとは相性悪い可能性はあるけどね＾＾； 元々AIGLXはATI（現AMD）をベースに作られた技術だし。
とまぁこう色々とあった訳なのですが、最後のBeryl以外はなんとか乗り越えてきたんですよ。だから今回も乗り越えられないかなぁという期待と、OS入れ直して直るかわからないという不安があります。
そう、OS入れ直した結果それでもBerylが不安定だった、ってことになったら、なんか悔しいじゃないですか。
今のところ、Beryl以外は非常に安定し、自分好みの環境にセッティングされています。Berylの機能は私にとってもうなくてはならないものになってしまいましたが、それとシステムの再インストールとを天秤に掛けると、やはりBerylを我慢する方に傾きます。
HDDに空きがあったら、新規で別のFedora放り込んで確認するんですけどね。ちょっと空きがないために確認のしようがない状況。
ほんと、原因は何なんだろうなぁ・・・。それさえ分かれば、自分のスキルと相談して動静がはっきりするのに。うぅ、動きにくいYO!

まだ私には早すぎたようだ

どうやってGoogleカレンダーとデスクトップアプリで同期を取ろうか、そう思っていましたが、Googleカレンダーのデータを一定間隔でローカルに反映させることは容易であることが分かりました。
と言うのも、GoogleカレンダーはiCal形式のファイルを提供しており、その形式にさえ対応していれば、そのファイルを一定間隔でDLしておきさえすればそれを読み込むだけでローカルに反映させることが出来るわけです。
で、iCalに対応したスケジューラやらカレンダーソフトは結構ごろごろしてます。LinuxではKOrganizerあたりがなかなか使い勝手よさげですね。直接HTTPプロトコルからファイルを読んでこれるあたりさすがKDEコンポーネント。ぬかりがないぜ。
ただ、ローカルで予定を書き込んでそれをGoogleカレンダーに同期というのは楽じゃない。そういう目的で作られたアプリなら別でしょうけれど、それは高望みというやつですからねぇ。
一応、Mozilla系列のSunbirdならばそれが可能なようです。Javaと連携するようですね。GoogleカレンダーはAPIが公開されているので、予定の追加などはAPIを使えば可能です。よーは、カレンダーソフト側がそのAPIを組み込めば可能っちゃー可能なわけで。Sunbirdはそーゆーのをやってのけちゃうらしい。すげーや。
その選択肢は非常に惹かれるモノがあったのですが（Sunbird+JavaはWinもLinuxもいける）、やっぱりデスクトップアクセサリのウィジェットに予定を表示させたい！と思ったのでなんとかその方向性を模索。
してるうちにあまりにもXの調子が悪くなってきたためLinuxでの作業を断念。Windowsに移行。
Linuxの話は「続きを読む」にて。
で、Windowsにきてとりあえずカレンダーソフトを探す。有名所で言えばRainlenderだけど、こいつがGoogleカレンダー、あるいはiCalに対応しているか調べたところ・・・、ばっちりビンゴ！　まぁカレンダーソフトならiCalは大概対応してますわな、やっぱり。
ついでに言えば、どうやら有料版の方はGoogleカレンダーに正式に（？）対応しているらしい。それはそれですごく興味がわいたけど、できたら無料で使いたいのでiCalを利用する方向で妥協。
実際iCalファイルをローカルに取り込み、それを反映させたところきっちり反映してくれました。ただ、イベントとして認識していないのか、イベントウィンドウに特に何も表示されないのが気にはなります。
単に1週間以内の予定が入っていないだけでした＾＾；
また、イベントの種類は反映されていないみたい？　まぁGoogleカレンダー側で特にそんなカテゴリ分けがない以上ある程度は仕方ないのかも。インポートしたカレンダー毎に一括してカテゴリを分けるコトは可能なので、Googleカレンダー側で目的に応じたカレンダーを複数作成し、それをそれぞれRainlenderに取り込めば問題なさそうですね。Rainlenderも複数のカレンダーを扱えますし。
さらにさらに、知らなかったのですが、Rainlenderはver.2になってからLinux版も出していたんですね！　これはありがたい。だって、WinとLinuxで同じSkin使えるんですもの＾＾
とりあえずオープンソースというわけではないのでライブラリがきちんと合ってくれるか不安ですが、まぁなんとかなるでしょう。後でLinux版も使ってみたいところです。
とりあえずSkinを改良してみようと仕様を確認してみたのですが、仕様そのものはスッキリしてますね。test用のサンプルを見てみましたら事細かくアイコンが作成してあって、ぶっちゃけ萎えましたが＾＾；　まぁ本気でやるにはそれだけ必要と言うことですね。大変だ・・・。
ただ、既にあるモノを改良するだけならさほど難しくはなさそうです。デフォルトでついてくるカレンダーは背景画像が何もないタイプのモノなので、てけとーに背景を見繕ってやればそれだけでもそれっぽくはなります。細かな修正はそのうちでいいでしょう。
とりあえずローカルへの同期は簡単に実現できて何よりです。次なる課題はいかにしてローカルでの変更をGoogleカレンダーに反映するかですが・・・、これはいさぎよくブラウザからやった方がいいですかねぇ？＾＾；　外出先からは携帯でも予定は追加できるわけですし、PCがあるならブラウザでやればいいか・・・？