Introduction

ブログ内検索

  • このサイトの記事を検索 by Google

おすすめの一冊!

無料ブログはココログ

« 2011年1月 | トップページ | 2011年5月 »

2011年2月

2011-02-04

セキュリティソフトは最新版を


ESET Smart Security は最新版を使いましょう、というお話。



Seaoak は数年前からセキュリティソフトとして ESET Smart Security を愛用してます。
以前は Norton とか Kaspersky とか使っていたこともあったのですが、
ESET Smart Security を使い始めてからは一度も浮気してません :-)

その魅力は、

  ・軽い(動作が重くなることがないし、ファイルのスキャンも十分速い)
  ・寡黙(邪魔なポップアップが出ない)
  ・サポートの姿勢が良心的(古いバージョンも平行してサポートしてくれてる)

といったところでしょうか。

先日、PC を改造して Windows XP から Windows 7 に乗り換えたのですが、
ホームページで公開されているファイルをダウンロードしてインストールして、
ユーザ名とパスワードを入れたら、何も問題なくライセンスが引き継げたので
とっても楽でした♪



ところで、うちの Windows 7 では UAC を殺しているのですが、たまに、
ファイルに書き込み権限がないというエラーが出て、困っていました。

デスクトップとかにファイルを保存しようとすると、

C:\User\hogehoge\Desktop\ このネットワークの場所でファイルを変更するアクセス許可がありません。 管理者に連絡して、これらのファイルを変更するアクセス許可を取得してください。
とかいうエラーウインドウが開いて、でもデスクトップには 0 byte のファイルが できていて、アプリ上で再試行すると今度は
foobar.txtは既に存在します。 上書きしますか?
とか言われてしまうのです。 上書きを「OK」すればちゃんと保存はできるのですが、面倒。 他にも、CD のリッピング中に書き込みエラーが出て止まってしまう (「再試行」すると何事もなかったかのように継続できる)とか、 iTunes で「情報の書き込みに失敗しました」と言われたりとか。 常に問題があるわけではなくて、ほんとにランダムに発生するので、 致命的ではないのですが、ちょっと気持ち悪いなぁ、という感じ。 で、てっきり Windows 7 の UAC かファイルシステムかどちらかが悪さをしているんだと 思いこんでいたのですが、ためしにちょっとググってみたら、セキュリティソフトの リアルタイムファイルシステム保護が悪さをしているケースがあるらしい、と判明。
Windows7で以下のようなエラーが発生し、ファイルが保存出来ないことが度々あるの... -- Yahoo! 知恵袋
さっそく開発元の Canon のサイトで検索してみると、それっぽい記述を発見。
共有フォルダにMicrosoft Officeのファイルを保存しようとするとエラーになる -- キヤノンITソリューションズ:ESET Smart Security & ESET NOD32アンチウイルス:サポート情報:ETPC40066
どうやら既知の問題らしく、ESET Smart Security v4.2 の最新版にすればよいらしい。 確認してみると、サイト上で公開されているファイルは v4.2.67.3 で、 うちの PC に入っていたのは v.4.2.52.0 でした。 ちょっと古い。 上記ページによると
・ESET Smart Security V4.0.474.9以降 ・ESET NOD32 アンチウイルス V4.0.479以降 にて、この現象について改善しております。
とのことですが、v4.2 系については触れられていないので、不明。 とりあえず、ファイルをダウンロードして実行して、最新版にしてみました。 それから1週間くらい経ちましたが、ファイル保存時の意味不明なエラーは まったく出なくなりました! 快適! ESET Smart Security のユーザの皆さま、ぜひ最新版を使いましょう! (もしかしたら NOD32 もかも?)

2011-02-02

verilog-mode for xyzzy


ソフトウェアの世界のヒトはたぶん聞いたこともないと思われますが、
Verilog-HDL という言語があります。ハードウェア記述言語というもので、
LSI のロジックをプログラムみたいに書くことができる、というシロモノです。
一般に、プログラミング言語のソースコードをコンパイルすると実行ファイルや
ライブラリ(DLL とか)が得られますが、ハードウェア記述言語のソースコードを
コンパイルすると回路図が得られます。最近は SystemVerilog が主流なのかも。

で、ハードウェア記述言語と言ってもソースコードを書くときはエディタのお世話になります。
世の中にはこんなマイナーな言語をサポートしてくれるエディタなんてほとんど無いんですが、
無いなら作ればいいんです。そう、xyzzy とか Emacs ならそれができる!

ちょっと調べてみたところ、xyzzy 向けの verilog-mode が公開されていました。

    ⇒ http://www.oct-net.ne.jp/~mayu-a/xyzzy.html

さっそく使わせていただいたのですが、ちょっと手になじまないところがあったので、
勝手に改造させていただきました。

で、できたファイル一式をここで公開しておきます。

    ⇒ verilog-mode の勝手に改造版

よろしければお使いください。

ちなみに、数年前に作って放置されてたものなので、
おかしなところがあるかもしれませんが、まぁ、
ご報告いただければたぶん修正します。

ご意見・ご感想・ご要望などは、お気軽に Seaoak までどうぞ。
メールアドレスはこのブログの左サイドバーに書いてあります。
あるいは Twitter 上で @seaoak2003 まで。

JavaScript の配列アクセス速度


先週末、「続・ハイパフォーマンス Web サイト」を読みました。


前作に比べてさらにマニアックな内容になっていて、
ブラウザの処理をブロックせずに外部 JavaScript ファイルを
読み込むにはどうすればよいか、とかが詳しく書いてあります。
あと、Comet (ロングポーリング)の仕組みや利点欠点が
ちゃんと書いてあるのはけっこう貴重かもしれません。
とりあえず、動的な Web サイトを構築している人なら
一読の価値はあると思います。



で、読んでいて気になった記述がひとつ。

JavaScript のコードの実行効率に関する話の中で、

JavaScript の Array の要素へのアクセス速度は一定ではなく、 配列の後ろのほうの要素へのアクセスは前のほうの要素に比べて遅い。
という意味の記述がありました。 つまり、a[65535] へのアクセスは a[7] へのアクセスより遅い、というのです。 これはいわゆる「配列」というデータ構造に関して Seaoak が持っていた直感に反しています。 びっくり! さっそく自宅の PC で実験してみました。 8M 個の乱数を格納した数値配列オブジェクトを作成して、 ランダムに選択した要素の読み取りを 128M 回繰り返し、 かかった時間を計測してみました。 単純に実行すると「スクリプトの実行に異常に時間がかかっています」という 警告が出て、それでも続行するとブラウザが半分固まってしまうので、 今回は Web Worker に処理させてみました。 以下、Web Worker のコード:
(function() { try { var list = new Array; for (var i=0; i<8*1024*1024; i++) { list[i] = Math.random(); } onmessage = function(event) { try { var count = 128*1024*1024; var start_time = (new Date).getTime(); var acc = Math.random(); var index = Math.floor(Math.random()*list.length); while (count-- > 0) { acc = acc ^ list[0] ^ list[index]; } postMessage({'index': index, 'time': (new Date).getTime() - start_time}); } catch(e) { postMessage('FATAL2: ' + e); } }; } catch(e) { postMessage('FATAL2: ' + e); } })();
このコードを Google Chrome と Firefox と Opera で 1024 回ずつ 実行した結果、以下のグラフのようになりました。 グラフ(Google Chrome での計測結果) グラフ(Firefox での計測結果) グラフ(Opera での計測結果) 実行時間の絶対値はブラウザによってかなり異なっていますが、 傾向はどれも同じで、添字の大小によるアクセス速度の差は無し。 残念ながら IE8 は Web Worker が実装されていないので未測定です。 こんな単純な処理なのに、ブラウザによって実行時間が 15 倍も違うのは かなり意外でした。というか、Chrome が速すぎ? ちなみに、各ブラウザのバージョンと測定環境は以下のとおり:
Google Chrome 9.0.597.83 beta Firefox 3.6.13 Opera 11.01 Windows 7 Professional 32bit AMD Phenom II X4 970 BlackEdition (3.5GHz / Quad Core / TDP95W) ASUS M4A89TD PRO/USB3 (AMD 890FX + SB850) DDR3 PC3-12800 4GB ×2枚 (CL=9-9-9-24)
まぁ、Wikipedia の「配列」の項を見ても「配列内のデータへのアクセスは O(1) 時間でできる」と 書いてあるので、たぶん、本の記述が間違っているのだと思います。 とりあえず、モダンブラウザは直感に合った挙動をしているみたいで、ひと安心。

« 2011年1月 | トップページ | 2011年5月 »