調べたついでに、メモ書き。
書いておかないと忘れるので。
■Netscreen のOID（MIB情報）
1.3.6.1.4.1.3224.4 -> VPN系の情報 1.3.6.1.4.1.3224.16 -> リソース系の情報
■Juniper SRX のOID（MIB情報）
1.3.6.1.4.1.2636.3
http://kb.juniper.net/InfoCenter/index?page=content&id=KB16545
■Juniper SSG のOID（MIB情報）
Screen OSなので、Netscreenと同じようだ。
Powershell用のModeのモードがあった。
じゃわてぃーのxyzzy的な何か：http://kazy111.info/xyzzy/
使い方は、ダウンロードしたファイルを解凍して、xyzzyのフォルダのetcとsite-lispにそれぞれ解凍したファイルを保存する。
あとは、、、xyzzyを起動するときにpowershellmodeが読み込まれた。
いろいろとやっているうちに読み込まれたので、、、なんとも書けない。
実際に使ってみると、
変数の部分やコマンドレットの部分の色を変えてくれるので便利。
WindowsについているPowerShellの開発環境でもいいのだけど、
スクリプトを読んだり、簡単な変更をするだけなら、
使い慣れたテキストエディタの方が好きだ。
FreeBSDのTCP問題で知ったのだけど、
Juniper Networks の Junos って、FreeBSDベースで作られていたのね。
FreeBSDは、目立たないところで使われているな。
今も昔も。
使う可能性はゼロではないのでメモ。
http://kb.juniper.net/InfoCenter/index?page=content&id=KB29072
普段から使用しているウェブにGoogle Chromeでアクセスした際に
「Google Chrome では www.xenos.co.jp に接続できませんでした」
とエラーが表示されたときの対処方法。
このエラーが出た時に最初に疑わなければならないのはネットワークの接続。
他のウェブサイトの閲覧ができていれば、ネットワークの可能性は低い。
また普段使いのサイトなら、急にドメインやサーバがなくなったりもしないので
こちらの可能性も低くなる。
そうすると一番最初に疑わなければならないのは、Google Chromeだ。
Chromeでは、Cookieファイルが壊れた際にこのエラーメッセージが表示されるとのこと。
切り分ける方法で一番簡単なのは、「シークレットウィンドウ」を使ってみること。
シークレットウィンドウは、Cookieなどの情報を引き継がないため、
このモードで正常にアクセスできればCookieの問題ということになる。
■切り分けと対処方法
■参考
https://support.google.com/chromebook/answer/1085581?hl=ja
SQL Server 2005（Transact SQL）で現在の時刻は、GETDATE() 関数で取得できる。
SELECT文で使えば、現在時刻を取得できる。
UPDATE文やINSERT文で使えば、SQL Serverの現在時刻を使って、更新日を更新できる。
例えば、現在の時刻を取得するだけのSELECT文
SELECT GETDATE() AS TIME
例えば、更新日（UpdateDate）を現在時刻で更新するUPDATE文
UPDATE Employee SET UpdateDate = GETDATE()
Android 4.1（Jelly Beans）でスクリーンショットをとるには、
“ボリュームを下げるボタン”と“電源ボタン”を1秒くらい同時押しする。
すると、スクリーンショットがとれる。
（画面上にエフェクトがかかるので、簡単にわかる）
Android 4.0でも同様にスクリーンショットがとれるようだ。
これらは、Android OS の機能なので、初期セットアップ中でも
スクリーンショットを撮ることができた。
少なくとも、Xperia VLでは撮れた。
Android 2.3の時は、PC側に開発ツールをインストールし、
スクリーンショットを撮っていたことを考えるとかなり楽になった。
Gmailの2012年の稼働率が99.983%という発表。
http://googleenterprise.blogspot.jp/2013/04/pure-and-proven-cloud-gmail.html
http://www.itmedia.co.jp/news/articles/1304/09/news082.html
稼働率を下げたいわけじゃないが、Gmailでも99.9%の稼働率保証で、
実際には99.983%というのは良い指標になるのではないか。
目指すところが99.999%というのがいいけれど、本当にその稼働率が必要なのか、
という議論はよくある。
が、落としどころがなくて、そのままインフラ設計が進むなんてこともある。
そういうとき、この稼働率は使えそうだ。
99.9%としておいて、実際の運用でカバーして、それ以上を目指す。
最初から宣言する数字を大きくしてしまうと、それ以上の運用体制が必要になるわけで、
落としどころとしては、99.9%は悪くない。
ベンチマーク的な使い方ができる数字を出してくれるのはうれしいね。
タイトルが長すぎ・・・
だけど、ほかに表現のしようがない。
Android 2.3 のスマートフォンで撮影した写真をGoogleドライブに
アップロードしようとしたところ、
アップロードの途中でGoogleドライブのアプリが落ちてアップロードが
終了してしまう現象に遭遇した。
検証をしたところ、スマートフォンの本体容量の残りが少ないときに、
このエラーが発生する。
Google ドライブのアプリは、SDカード側のストレージを使用できない。
そのため、限られた本体側ストレージ（メモリ）を使わなければならず、
たくさんのアプリをインストールした状態ではストレージ不足に陥る。
ストレージ不足の状態で、Googleドライブに対して写真などの大きなファイルを
スマートフォンからアップロードしようとすると
アップロードの途中でメモリが足らずにアプリケーションが落ちてしまうようだ。
なんとも悲しい仕様だ。
Android スマートフォンの場合、ほとんどが本体のストレージ容量が限られていて
大きなデータはmicro SDカードに保存する。
そのような状況なのに、Androidのアプリは本体ストレージにしかインストールできないものが多数ある。
そうなると簡単にストレージを浪費してしまう。
Googleドライブのアプリのように、ストレージが少ない状態では動作が安定しないアプリもある。
本体かアプリか、どちらかを改善してもらいたい。
ちなみに、Google ドライブにたくさんの写真やドキュメントをアップロードするときに
アプリが落ちてしまう場合は、1つずつアップロードしていくと成功する。
（もちろん、本体の空き容量次第なわけだが・・・）
Mac版のJavaってメンテナンスをしないといっていたような気がするのだけど、
気のせいだったのかな？
影響が大きいから、サポートを打ち切るといいつつ、
Javaの利用が下火になるのを待っているということだろうか？
どちらにしても、セキュリティアップデートは当てないといけないですね。
http://www.itmedia.co.jp/enterprise/articles/1210/18/news024.html
Windows7でAcroabat X Pro でフォームを作成したり、フォームを編集したら、
元が数10KBのファイルが数MBにまで肥大化した。
PDFのファイルを最適化するために、別名で保存しても圧縮できない画像があるとかで
ファイルのサイズはほぼ変わらず。（数10KB小さくなっただけ）
PDFファイルの圧縮などを試していたら、フォーム自体が消えてしまったり。
それでもファイルは小さくならない。
前に同じような編集をした際には、ここまでPDFファイルが肥大化することはなかった。
原因不明の謎な現象。
前に編集したときと条件が異なるのは、Windows OSのバージョンだけ。
ためしにWindows XP にAcrobato Proをインストールして同じ編集をした。
すると、フォームを作成したときに若干ファイルサイズが大きくなるものの300KBくらいになった。
（ここで編集したのは、肥大化したPDFファイルではなくて、フォームを作成する前の元のPDFだ。）
XPの方で、別名で保存を行えば、PDFが最適化されてさらにコンパクトになった。
結論： PDFファイルが肥大化した原因は、Windows7とAcrobatの組み合わせ
原因はまったくもってわからないが、OSのバージョンによってAcrobatの動作が変わっている模様。
そのため、PDFファイルに余計なものがついてファイルサイズが肥大化したようだ。
不可解だが、なんとか解決。
Windows 7 でPDFファイルの肥大化に困ったら、とりあえずWindows XPで試してみるとよい。