HTMLのIMGタグのSRC属性には、通常外部の（自分自身のHTMLファイルとは別の）画像ファイルを指定するのだが、
画像のデータを示す文字列を指定することで、
外部の画像ファイルを使用せずに自身のHTMLファイル内で「画像」データを再現できる。
※ただしその分、HTMLファイルの容量自体が膨らむ。
特定の静的HTMLコンテンツがそれだけで完結していて、
外部の画像を読み込むような隙がない（配置された場所からしてネットワーク環境的に不可能な）ケースで使用する。
↑のような書き方をするとなんとなくレアケースにしか感じないが、実際、あったのである。（実体験故、詳しいことが書けない）
記述方法は以下の通りだ。
<img src="data:image/png;base64,[BASE64エンコードされた文字列]" alt="base64test">
全角文字を含む値（VALUE）を持つjavaのpropertiesファイルは、使用する環境を考慮してか得てしてnative2ascii化されていることが多い。
よって、メモ帳やらサクラエディタ等の、一般的なテキストエディタで開くとこんな感じに見えてしまう↓
test.key=\u30d5\u30a1\u30a4\u30eb\u306e\u51fa\u529b\u306b\u5931\u6557\u3057\u307e\u3057\u305f\u3002 #ちなみに"ファイルの出力に失敗しました"と書いてある
当然この状態だと何書いてあるかわからんので日本語にしたいのだが、
知っているかぎりエディタ上でこれを日本語で復元して読み込んでくれるのはEclipseしかなく、
いちいちこのpropertiesファイルのために重いEclipse立ち上げるのも億劫で
手軽なnative2asciiの復元方法や、エディタがあればいいなあと思っていた。
どうもコマンドプロンプト上でnative2asciiコマンドを使うのが最も手っ取り早そうなので、
ここでその使い方を記述する。
テーブルにdefault指定付きの項目を追加（alter table tabne_name add column_name column_type default default_value）すると、
”テーブル項目追加中（alter文実行中）”はそのテーブルに対するSELECTが待たされるらしい。
alterが終われば解放されてSELECTも通るようになる。
テーブルに項目を追加するわけだから、
追加される前（alter文実行中も「追加」が完了する前という意味では「追加される前」）に発行するselect文には
当然追加対象のテーブル項目を含めることはできないので、
追加項目を見ないselectと、これからテーブルに項目を追加するalterの両者は、一見すると無関係に見える。
だけどどうも影響を受けてしまうようだ。
OracleのFunctionの実行時間はSQLそのものの完了よりはフェッチの部分に大部分が含まれるように感じる。
Functionを呼び出したタイミングではその中身まで深く計算せず、
フェッチしている中で詳細な計算をしていくようなイメージのようである。
SELECT文の問い合わせの”結果”には、
①Oracleからの検索結果返却開始
②全検索結果のフェッチ完了
の２段階のフェーズがあるが、
SELECTする項目の一つ、ないしそのうちの一部として同じ並びで記述するFunctionは、
基本的には前者「①Oracleからの検索結果返却開始」までの間に全て寄っていて、
検索結果が返却される段階ではもう既に計算済みだと思っていた。
だがどうやらそうではない。
実際にはOracleから検索結果が返却されてから、「②全検索結果のフェッチ完了」までの間に
その計算を行っているようである。
「①Oracleからの検索結果返却開始」が開始した段階では、
実際に発行したSELECTの中に含まれるFunctionの計算は行われていないということなのだな。
仕事のとある案件においてプロジェクトで自作した業務Functionの修正を行った際、
修正前後のスピード比較をしたときにふと疑問が浮かび、簡単な実験をして知った。
Oracle的には常識なのかもしれないが自分用のメモ。
VSS(Microsoft Visual SourceSafe)の起動プロセスは「ssexp.exe」である。
つまりWindows系マシンでこいつをぶっ殺す場合
taskkill /f /im "ssexp.exe"
とすればよいのだ。
というのをVSSがハンぐった2014/8/22知りましたのでメモ。
見積もりに関する社内教育を受けろと言われたので、この前受けてきた。
画面やバッチ等の機能の新規開発における高精度の見積もり手法の紹介と
その基本知識を身に着けることを目的とした教育であった。
Oracleの公式のマニュアルみたいのを見ると
「V$SESSION.BLOCKING_SESSIONにはブロックしているセッションの情報が出力される」
といった内容のことが書かれているが、
主語がないので自セッションから見て
UNIXコマンドxargsの簡単な使い方メモ。
例によって自分用の備忘録を兼ねる。
xargsはコマンドを呼ぶためのコマンドという感じだ。
xargsの引数に「実行したいコマンド」そのものをひきわたす。
通常標準入力から「実行したいコマンド」に渡す引数を入力するが、
スクリプトに組み込まれているようなケースではパイプと連動して使うことが多いはずだ。
HTMLからシンボリックリンクのCSSやJSを読み込む動作がIEとGoogle Chromeで違う。
例えば以下の構成だったとする。
SymLinkCSSTest.html
└─real_path
├─syml_test.css
├─syml_test.js
├─<SYMLINK> syml_test_from_real_path.css [syml_test.css]
└─<SYMLINK> syml_test_from_real_path.js [syml_test.js]
つまり実態は「syml_test.～」で、
そいつをシンボリックリンクで参照している「syml_test_from_real_path.～」というファイルが同階層に存在している。
このときの動作をまとめると
ファイルブラウザ(Version)結果Google Chrome(36.0.1985.125 m)読める（JS実行できる）
| syml_test.css | IE(10.0.9200.17028) | 読める（スタイル適用される） |
| Google Chrome(36.0.1985.125 m) | 読める（スタイル適用される） | |
| syml_test.js | IE(10.0.9200.17028) | 読める（JS実行できる） |
| syml_test_from_real_path.css | IE(10.0.9200.17028) | 読める（スタイル適用される） |
| Google Chrome(36.0.1985.125 m) | 読めない（スタイル適用されない） | |
| syml_test_from_real_path.js | IE(10.0.9200.17028) | 読める（JS実行できる） |
| Google Chrome(36.0.1985.125 m) | 読めない（JS実行できない） |
となる。
実態パスのCSSやJSが読めるのは当然だが（まとめてて変な気がしてきたｗ）、
シンボリックリンクのCSSやJSはGoogle Chromeでは読んでくれない。