NOD32 ライセンス有効期限が表示されるようになった？

実はV3.0の頃はどうだったか確認していないのですが、V2.7の頃はNOD32の画面からライセンスの有効期限を確認することができませんでした。

「更新のお知らせ」のメールが届いて、有効期限の日付を知ることができるという（＾＾；

V4.0においては、「保護の状態」の画面で、普通にライセンス有効期限が表示されています。まぁ、有効期限を画面から確認できたとしても、実際に更新するのはお知らせのメールが届いてからになるんでしょうけど。

Trac：文字列項目での範囲指定

すごく久しぶりのTracネタです。またしばらくの間、Tracをいじる時間がなくなる可能性もありますが（＾＾；

TracのTicketにおいて、「日付」の項目を追加するような場合、基本的にTEXT型でカスタムフィールドを作成するかと思うのですが、「日付の範囲指定」での抽出ができないというのが難点。

ということで、ticket/query.pyを直接いじってみました（ちとバージョンが古くてTrac0.11.1-jaです）。
編集対象となるのは、get_constraint_sql(name, value, mode, neg)関数の部分。以下の条件の場合、範囲指定での抽出を行うようにしてみます。

・カスタムクエリの条件入力としては、「～に次が含まれる」「～に次は含まれない」が選択されている
・項目にセミコロン";"が含まれている（入力値をセミコロンで区切り、下限値／上限値として処理）

Continue reading "Trac：文字列項目での範囲指定"

NOD32 V4.0

NOD32をV3.0からV4.0に更新しました。まぁ、インストール(Update)自体は特に問題なく終わったのですが、定義ファイルの更新の際に「ダウンロードに失敗しました」のエラーが。

NOD32の画面を開いて、「設定＞環境設定で詳細な設定をする」で設定画面を表示し、「ウイルス・スパイウェア対策＞アップデート」の項目で、アップデートキャッシュを削除を実行して、再度アップデートを実行すると問題なく処理できました。

果たして、キャッシュの削除が効果があったのか、それとも、たまたまダウンロードに失敗していただけだったのか？？

freeSSHd

freeSSHd・・・Windows上で動作するsshサーバ。Putty等で接続すると、コマンドプロンプトからあれこれ作業することが可能となります。

まぁ、Windowsの場合、リモートで操作するのであればRDPで接続することの方が多いような気もしますが（＾＾；

LIVE CD「Request～リクエスト～」

　加藤いづみリクエストライブのCD。発売してちょっと時間は経ってしまっていますが、無事に入手できました（＾＾）。

　過去にライブで聴きたいと思いつつ縁がなかった「坂道」も収録されていて、いい感じです（いづみさんのコンサートに初めて行ったのはSad Beautyの頃）。

　８／８（土）に東京でライブがあるんですよね・・・８／６（木）には、（やはり東京で）JavaWorld Day 2009が開催されたりしますし、まとめて行ってきたい気もしつつ。歯医者の予約（８／８）ずらすかなぁ（笑）。

Firefox 3.5

　とりあえず、Firefox3.5をインストールしてみました（正確には、3.0からUpdateしました）。現状ではフォクすけのテーマが使用できないのが悲しいところですが、まぁ、なんとなく（笑）。

　Firefoxの２倍速くなったとのことですが・・・よくわかりません（＾＾；　まぁ、表示するWebページによっては効果を実感するのかもしれませんが。

　ま、とりあえずは、ぼちぼちと。

Clonezillaでリカバリ用のDVDを作成する

　Clonezillaを用いると、簡単にリカバリ用のHDDイメージを作成することができます。また、リカバリ用のイメージに関しても、ローカルデバイスの他に、ftpサーバやsambaサーバなどに保管することができます（残念ながら、ローカルデバイス以外を使用したことはないのですが）。

　リカバリ用のイメージを例えばUSB-HDDに保管した場合、同時にリカバリを走らせることができる端末台数はUSB-HDDの台数に制限されてしまいます（同じイメージを複数の端末に複製したいような場合）。多くの場合はこれでも充分だとは思いますが、頻繁に利用するイメージの場合、CD/DVDのメディアだけで完結できればいいなぁ・・・と思っていたら、標準でサポートしていました（Clonezilla Live 1.2.2-14で動作確認）。

※あと、USB-HDDがそれなりに安価になったとはいえ、やはり容量の都合もあるので、既に固定化されたイメージはDVDなどに焼いてHDDから削除しておきたいところであります。

　イメージの保存／復元といったメニューの中から、「recovery-iso-zip リカバリ用のClonezilla_Liveディスクを作成」を選択すればＯＫ。Clonezilla Liveとリカバリ用のイメージを組み込んだISOファイルを作成することができるので、あとはそれをメディアに焼けばＯＫ。複製も簡単（かつ、それなりに安価）。
　ただし、当然ながら、メディアに入りきらないサイズのバックアップイメージは無理です。DVD数枚組（あるいはCD数枚組）のリカバリセットを作ることができれば非常にうれしいのですが。

　ちなみに、Create Your Own Recovery Clonezilla Liveのページによると、使用しているプログラムの都合上、4.5GBを超えるファイルのイメージは作成できないとのことですが、これはiso化する元ファイルのサイズの話のようで、例えば2GBごとにファイルを分割していれば、DLのメディアを用いたリカバリDVDも作成可能となるようです（それでも約8GBが限界ですが）。

USBメモリでブートするUbuntu9.04

Ubuntu9.04をCDブートし、メニューから簡単にUSBメモリにUbuntu9.04をインストールできるんですね。
USBメモリの容量が足りているかどうかのチェックも問題なく行ってくれます。

UbuntuをUSBメモリから起動すると、内蔵CD/DVDドライブを自由に利用可能になるので、結構便利かも。

＃CD/DVD非搭載のマシンでもブート可能になりますし。

mod_proxy_balancerの振り分けをhttpで

　Apache2.2以降は、mod_proxy_balancerやmod_proxy_ajpで簡単に複数台のTomcatと連携できるようになりました。

　これらのmoduleを組み合わせる場合は、ブラウザから送られてきたリクエストを、Proxyディレクティブでbalancerプロトコルに変換し、balancerプロトコル側でさらにajpに転送といった感じでの指定が一般的（参考：Apache2.2とTomcatでロードバランサー）。

　ただ、Apache/Tomcat間にFirewallが存在すると、時々ajpのエラーが発生することもあるようで（これ自体、そもそも何故エラーが発生しているのか、どういう回避方法があるのか不明なのですが）、試しに、ajpではなくhttpでApache⇒Tomcatへ転送してみました。

　すると・・・Redirectの部分で、見事に大ハマリ（苦笑）。リダイレクトされた場合、次のリクエストがBalancerMemberのところで指定したホスト名になってしまうため、PRGで画面遷移を行っているTeedaなどは実質使用不可に・・・。

BalancerMember http://localhost:8080/Test route=Tomcat1

　なんて感じで指定していると、リダイレクト時は、http://localhost:8080/でアクセスしようとするため、接続先不明と言うことに・・・（当然ながら、localhost:8080で待ち受けているものがあればそこに接続してしまいます）。

＃そもそも設定方法を間違えているのかなぁ・・・。

開発速度

プログラマーの開発速度は「はまる」時間の長さで決まる

1. クラスやメソッドの命名が不適切
　時々、自分自身でもやっちゃってます（苦笑）。メソッド名だけでは内容がよくわからず、結局ソースコードを見て「今使いたいメソッドかどうか」を判断する場合も。

2. 「とりあえず」書いたコードが悪さをしている
　これも、よく経験があります。多くの場合、その箇所を修正する機会もなく平穏に（？）時は流れるのですが、「その場しのぎ」での修正が後々響いてくることも。そういう時に限って、元々「その場しのぎ」での修正だったため、修正すべき箇所の特定に手間取ったり、別の箇所に影響が出たり。

3. 「このままでは何かがおかしい」と感じながら作業を続けている
　２．と同様ですね（＾＾；　ただ、「おかしい」と気付きながら作業するのか、そもそも「おかしい」とすら気付かずに作業を続けるのか、といったところに、それなりに大きな開きがあるような気もします（おそらく、４以降とも関連してくると思いますが）。

4. ツールに振り回されている
　EclipseやC#を使っていると、デバッガの使い方で作業時間に大きな開きが出てくる場合も。不慣れな（？）人の場合、例外トレースの内容を上手く解釈できず、全くといっていいほど見当違いの箇所の修正をしていることもあるようで（当然ながら、ブレークポイントも見当違いな場所に）。
　例外が発生しないけどおかしな動きをしている場合、「どういう動きをすべきか？」「その結果を得るためにはどの部分の処理が関与しているのか？」「その部分の処理が期待した通りに動いていないのは何故か？」と言ったところの推測が不充分なケースも。

5. 「よくあるつくり」に対する理解が乏しい
　おそらく、言語を問わず、「プログラム開発における共通的な考え方」ってのはあると思います（デザインパターンなども「共通的な考え方」に入るものではないかと）。まぁ、最近では目移りしてしまうほどいろいろな（しかも使い勝手の良い）ライブラリやフレームワークがあるため、それを使うことで手一杯になってしまう（あるいは満足してしまう）ってことも多いのではないかと思いますが。
　オープンソースなライブラリ／フレームワークを使っていて、「ここってどういう風に処理を実現しているのだろう？」って時に、ソースを見ようと思うかどうか、ってのも大きな境目になるのではないかと。

6. APIの存在を認知できていない
　これって、なかなか難しいですよね・・・。各言語の標準API、ライブラリ／フレームワークのAPI等々、１つのアプリケーションを構築する際に全部のAPIを一通りチェックするとした場合、かなり膨大な数になってしまうのではないかと。そういう意味では、１とも絡んでくるのですが、「ある機能が必要」⇒「英語だと、ｘｘという単語になるのでは？」⇒「ｘｘという単語を含んでいるクラスはある？」って感じで、徐々に自分の中でのAPIライブラリを増やしていくというのが現実的な選択肢かなぁ、と。
　あとは、言語のバージョンが上がった時の、「目玉API」に関して、概要だけでも目を通しておくとか。Java5やJava6での追加機能に関しては、例えばJava in the boxのようにいい感じでまとめてくださっているところもありますし。スレッドプールが必要になった場合、Java5で追加された同期関連のAPIを知っているかどうかは大きな差として現れるかと。

Continue reading "開発速度"