Excelアドインファイルの自分自身のフルパスを取得する
エクセルのVBAプロジェクトで、自身の.xlamファイルのフルパスを取得する方法。まずはコード。
' 自身のファイル名 Const kMyXlamFileName = "MyAddIn.xlam" Private Function GetMyXlamFullPath() Dim proj As Object For Each proj In Application.VBE.VBProjects If InStr(proj.Filename, kMyXlamFileName) <> 0 Then GetMyAddInFullPath = proj.Filename Exit Function End If Next GetMyAddInFullPath = "" End Function
ThisProject.Filepathみたいな感じで簡単に取れるかと思いきや、存在するVBProjectを全舐めする方法しか見つからなかった…(´・ω・`)。自身の名前をリテラルでコード内に持ってるのがイケてないが、もしxlamファイル名を変えたらExcelのアドイン設定をし直さなきゃならんので、そう易易と変えることは無いだろうってことで。
「実行時エラー'1004': プログラミングによるVisual Basicプロジェクトへのアクセスは信頼性に欠けます」エラーが出た場合は、Excelのファイル>オプション>セキュリティセンター>セキュリティセンターの設定から、マクロの設定>VBAプロジェクトオブジェクトモデルへのアクセスを信頼する、にチェックを入れるべし。
参考サイト
FreeBSD 10に入れたTomcat 7のタイムゾーン設定方法
何かの拍子に、Tomcat 7.0で動かしているサービスのタイムゾーンがUTCとして認識されるようになってしまった。マシンのRTCは昔からUTCで、OSのロケール≒タイムゾーンも以前からJSTで特に変更はしてないのだが…。
変わっちゃったもんは仕方ないんで、Tomcatのタイムゾーンを変更する方法を調べたところ、setenv.shでCATALINA_OPTS環境変数を弄ればいいらしい。setenv.shってどこにあんのよっていうと、/usr/local/apache-tomacat-7.0/bin/である。もっとも自分の環境(FreeBSD 10.3-RELEASE-p26/Tomcat 7.0.59)ではsetenv.shは無かったんだけど、startup.shを見るにsetenv.shがあれば読み込むように見えたので、新規で作ったら上手く行った。
setenv.shの中味は以下の通り。
export CATALINA_OPTS='-Duser.timezone=Asia/Tokyo'
あとはApacheとTomcatを再起動してやればおk。
MozJPEGのjpegtranによるJPEG圧縮最適化が凄い件
とても今更なんですけどね、Mozilla謹製JPEGライブラリ群の一部、jpegtranによるJPEG最適化の効果に驚愕しとるわけです。
PENTAX K-1を買ってからというものPCのストレージの減り方が半端なく、そりゃJPEG+RAWで撮ってれば1シャッターにつき60MB前後の容量を食うので当たり前なわけでありますが、冗談抜きで空き容量が逼迫しとるんですわ。1TBのSSDうち820GBをデータ用に割り当ててるのに、現時点で残り2.3GBですよ。使用量のうち8割が写真であるからして、白羽の矢が立ったのがMozJPEGというわけ。(RAWが一番容量食ってるってツッコミはなしなんだぜ。)
とりあえず急場凌ぎで、画像の品質には一切影響を与えないjpegtranで最適化してみたら、縮むこと縮むこと。元の画像サイズが大きいことも相まって、1枚あたり1MB弱ほど小さくなった。論より証拠ってなもんでスクショをご覧頂こう。
圧縮データの最適化、つまり無劣化でここまで縮むんだから大したもんですよ。もっとも、演算能力や処理時間の制約が厳しいデジカメで生成されたJPEGデータなので、最適化の余地が大きかろう点は考慮の必要があるだろうが…。
画像右端の「算術符号」ってのは、-arithmeticオプションで最適化した結果である。ハフマン符号最適化(-optimizeオプション)より更に小さくなっており、その効果には目を見張るばかりだが、哀しい哉、特許の関係で算術符号でエンコードされたJPEGに対応したソフトは皆無…。試した範囲では、MacOS X v10.9のプレビュー.app、Photoshop CC 2015.5、Firefox 58のいずれにおいても表示する事ができなかった。フォトショとLightroomで使えれば、手元のデジタル写真ライブラリの容量削減に大きく寄与するんだがなー。口惜しい…。
ついでに言うと、-optimizeより-arithmeticの方が処理時間が短かったりするのよね。軽くて縮むとかどんだけだよ。本当に口惜しい……。MacBook Pro (Late 2013)での処理時間は↓こんな感じ。
・-optimizeの時 real 3m35.907s user 3m22.685s sys 0m11.282s ・-arithmeticの時 real 3m12.291s user 2m57.712s sys 0m11.897s
-copy allオプションを付ければJPEGに含まれるメタデータは全て引き継がれる。少なくともexiftoolで比較した限りでは、元ファイルと最適化後のファイルでExifの相違はなかった。
個人的には元ファイルのタイムスタンプも継承したかったので、下記のようなシェルスクリプトで処理した。
#!/bin/sh TARGETDIR="$1" OUTDIR="$1/out" FILES=`find "$TARGETDIR" -maxdepth 1 -type f -name '*.JPG'` echo `pwd` mkdir -p $OUTDIR for file in $FILES; do echo $file CTIME=`GetFileInfo -d "$file"` MTIME=`GetFileInfo -m "$file"` OUTFILE="$OUTDIR/$file" jpegtran -optimize -progressive -copy all "$file" > "$OUTFILE" #jpegtran -arithmetic -progressive -arithmetic -copy all "$file" > "$OUTFILE" SetFile -d "$CTIME" "$OUTFILE" SetFile -m "$MTIME" "$OUTFILE" done
ご覧の通り、エラー処理とか何も入れてないので、元ファイルが無関係のファイルが無くなってもしらにゃい(´・ω・`)。GetFileInfoとSetFileを使ってるのでXcodeを入れとく必要がある、つまりこのスクリプトはMac専用なんだぜ。
ブリッジネットワーク接続の仮想マシンを使う時はport-securityに気をつける
ブリッジネットワーク接続の仮想マシンがあり、その通信がCiscoのCatalystスイッチを通るネットワーク構成の時は、スイッチのポートセキュリティ設定に気をつけなければならない。さもないと仮想マシンが通信できなくてハマる。VMとLAN内の物理マシンとでARP RequestとReplayは通っており、互いのARPテーブルは正しく作られているように見えるのに通信が出来なくて超ハマる。3ヶ月くらい悩んでた…(ヽ´ω`)
port-securityが有効なポートでは、最初に通過したMACアドレス以外のフレームが破棄される。
ここで、ブリッジ接続の仮想マシンのフレームは、物理マシンが繋がってるポートに流れる事になる。つまり、1ポートに対して複数のMACアドレスが関連付けられるわけだが、port-securityが有効だと最初の通信のMACアドレスしか有効にならない。それは殆どのケースで物理マシンのMACアドレスになるので、VMは一切通信出来なくなるという寸法。逆にいえば、物理マシンの通信ならOKなので、NATでVMの通信を物理マシンの通信に変換してやれば通信できるということだ。実際、NAT接続でなら通信出来てた。
対策方法は次の3つ。
- port-securityを無効化する
- 信頼するMACアドレスを静的に追加する
- 学習するMACエントリの上限を引き上げる(デフォルトでは1個)
自宅ネットワークならport-security無効化が簡単で影響も殆どないかと。
この問題を調べてる時に、ブリッジ接続が上手くいかないと嘆いているロシアのフォーラムを見つけたんだけど、結局使ってるホスティング業者を変えたら動いた!って結末だったので、恐らくダメだった方の業者のスイッチで似たようなセキュリティ設定になってたんだろうと思う。
原因がわかって全てが繋がった感じ。通信だけにね(´・∀・` )
参考サイト
VirtualBox上のWin 7でディスクイメージとzvolの速度比較(ついでにbhyveも)
仮想マシンのストレージ形式について、一般的にはイメージファイルよりもzvolの方が適していると言われている。ホストのファイルシステムレイヤを通過したファイル上にゲストのFSレイヤを通したFSを構築するよりかは、zvol(の薄いレイヤしか通らない)のブロックデバイスをゲストのFSレイヤに渡した方が効率が良さそう、ってのは理屈としても合っている。
以前から実際に速度比較しようと思いつつ、ようやく実行に移せた。環境は以下の通り。
- ホスト
- FreeBSD 11.1-RELEASE-p1
- VirtualBox 5.2.0
- CPU: Xeon E5-2648Lv3 1.8GHz 12C24T
- RAM: 64GB
- SSD: Intel DC S3500 480GB
- SATA 3接続
- ZFSのLZ4で透過圧縮している
- ゲスト
- Windows 7 Ultimate (x64)
- CPU: 4コア
- RAM: 8GB
- SSD: VirtIO 40GB
ゲストのストレージを、同一内容のイメージファイルとzvolデバイスとで切り替えてCrystalDiskMark 6.0.0で速度を計測した。なお、イメージファイルからzvolへの変換は以下のコマンドで行った。
VBoxManage clonehd /path/to/vms/Windows/HDD.vmdk /path/to/vms/HDD.raw --format RAW zfs create -V 40G zvm/zvols/Windows dd if=/path/to/vms/Windows/HDD.raw of=/dev/zvol/zvols/Windows bs=4096 VBoxManage internalcommands createrawvmdk -filename /path/to/vms/Windows/zvol.vmdk -rawdisk /dev/zvol/zvols/Windows
おろ、殆ど変わらんがな…(´・ω・`)。シーケンシャルR/W共にSATA 3の上限ぶっちぎっちゃってるし、ホストのキャッシュが効いちゃってる?
というわけで、VirtualBoxの「ホストのI/Oキャッシュを使う」オプションを切って再計測。
すごく、、、速いです………。こりゃZFSのキャッシュが効いてるなー。確認してみるとARCで4.8GB持ってるしなー。ベンチ中にtopで見てるとARCがもりもり増えてくし。
ついでにイメージファイルをHDDに置いた時のベンチも取ってみた。
うっは2.5インチHDDとは思えぬ速さwwwww
zpool iostatの結果を見るに、ランダムライトはZFS側でまとめられ、ほぼシーケンシャルライトとしてHDDに書き出されているようだ。
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
zhome2 1.33T 1.38T 1 922 153K 105M
mirror 1.33T 1.38T 1 922 153K 105M
ada3p1 - - 0 861 25.5K 105M
ada2p1 - - 0 875 127K 107M
logs - - - - - -
mirror 40K 3.97G 0 0 0 0
ada0p4 - - 0 0 0 0
ada1p4 - - 0 0 0 0
---------- ----- ----- ----- ----- ----- -----
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
zhome2 1.33T 1.38T 2 932 277K 111M
mirror 1.33T 1.38T 2 932 277K 111M
ada3p1 - - 0 919 50.4K 114M
ada2p1 - - 1 890 227K 110M
logs - - - - - -
mirror 40K 3.97G 0 0 0 0
ada0p4 - - 0 0 0 0
ada1p4 - - 0 0 0 0
---------- ----- ----- ----- ----- ----- -----
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
zhome2 1.33T 1.38T 0 962 102K 119M
mirror 1.33T 1.38T 0 962 102K 119M
ada3p1 - - 0 941 102K 117M
ada2p1 - - 0 965 0 120M
logs - - - - - -
mirror 40K 3.97G 0 0 0 0
ada0p4 - - 0 0 0 0
ada1p4 - - 0 0 0 0
---------- ----- ----- ----- ----- ----- -----
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
zhome2 1.34T 1.38T 1 940 153K 113M
mirror 1.34T 1.38T 1 940 153K 113M
ada3p1 - - 0 918 76.7K 113M
ada2p1 - - 0 906 76.7K 112M
logs - - - - - -
mirror 40K 3.97G 0 0 0 0
ada0p4 - - 0 0 0 0
ada1p4 - - 0 0 0 0
---------- ----- ----- ----- ----- ----- -----
結論としては、イメージファイルでもzvolでも大差なさそう。ストレージ形式の差よりも、ZFSそのものの動作環境やチューニングの差の方が覿面に影響しそう。なので、好きな方を使えばいいんじゃないかな。俺は扱いやすいイメージファイルの方を選ぶんだぜ。
とりあえずZFSパネェ…。
(2017-11-25 追記)
ついでにbhyveでもやってみた。
ストレージは同一SSDだけど、計測環境は新規インストールのWindows 10なので厳密な比較にはならんけど。なお、ストレージはahci-hdで繋いでる。virtio-blkはWindowsでは現状未対応らしい。
ベンチ結果は左から、gzip-5のZFS上のイメージファイル、同zvol、lz4なzvol。









