ポリシーファイル
JavaのポリシーファイルでFilePermissionを使う時は、パスの区切りはプラットフォーム依存で書かないとだめみたいだ。Windowsでは\\と書かないと認識されない。grantのcodeBaseのところはfile:///で指定するので、逆に/で書かないと認識されない。紛らわしいな。
で、テンポラリファイルにだけアクセス可能とする場合、Windowsではどう書けばいいのか。テンポラリファイルは、x:\Documents and Settings\user\Local Settings\Tempにできる模様。しかし、こんなの直書きなんて、あり得ない。ユーザ名が入るし。${user.home}\\Local Settings\\Tempというのも、なんか間抜けな感じ。と思ったら、${java.io.tmpdir}なんてのがあった。
grant codeBase "file:///x:/Program Files/applicationDir/*" {
permission java.io.FilePermission "${java.io.tmpdir}\\*", "read,write,delete";
};
みたいな感じだ。くどいが、${java.io.tmpdir}/*だとダメだ。口惜しい。
JSR-305
FindBugsの@NonNullとか@ImmutableがJSRに提案された模様。FindBugsだけじゃなくてIntelliJなど他のツールも考慮するみたい(そりゃ標準への提案だから当然か)。
java.policyファイル。
jre/lib/securityに入っているセキュリティポリシファイル。1.4だと、
grant codeBase "file:${java.home}/lib/ext/*" {
5.0だと、
grant codeBase "file:${{java.ext.dirs}}/*" {
なんか{が二重になってるんですけど。でも、ちゃんと効いているみたいだ。extディレクトリに置いたファイルはセキュリティマネージャを指定してもセキュリティ違反にならない。試しに、
grant codeBase "file:${{user.home}}/*" {
とかして、homeに危険なプログラム置いてみたが、セキュリティ違反になるので、やっぱり二重カッコはダメっぽい。まさか額面通り読むべき？
String ext = System.getProperty("java.ext.dirs");
System.out.println("ext dir:" + ext);
System.out.println("ext ext dir:" + System.getProperty(ext));
ext dir:d:\jdk1.5.0_07\jre\lib\ext ext ext dir:null
んなわけないか(それに本当なら${${java.ext.dirs}}みたいにならないとおかしいし)。extを指定する時にだけ使える特殊表記なんだろうか。ここの最後に"General Expansion in Policy Files"というのがあって、それっぽいことが書いてある。java.ext.dirsというのは、ここで言うprotocolの1つなんだろうか。selfとaliasしか書かれていないので、不明。
PL/SQL
なぜかPL/SQLの仕事が。何でストアドプロシージャを一度も書いたことの無い自分のところに…。案の定、要件詰まってないし、2週間で造るとかスケジュールだけ決まってるし。みんなお手上げで落ちてきた感じか。
断ってもいいけど、強気で行けそうなので絶対TDDでやることにして引き受けた。テストケース出来るまでコードは一切書かないことにしよう。幸いバッチだから、完璧なテストケースさえできれば、コードは2-3日で行けそうだし。一週間半はテスト作りで要件の抜けを虱つぶしにしよう。
なんとか復活。
$ svn delete trunk/test2.txt --force D trunk\test2.txt $ svn update trunk/test2.txt A trunk\test2.txt リビジョン 13 に更新しました。 $ svn commit -m "" 削除しています trunk\test2.txt 追加しています trunk\test4.txt リビジョン 14 をコミットしました。 $ ls trunk test.txt* test2.txt* test3.txt test4.txt*
とりあえずマージでタグ指定は危険なようだ。リビジョン番号で指定したら特に変なことは起きなかった。テスト中に気付いて良かった。こんなの本番で起きたらたまらない。
と思ったら。
はまる。
$ touch trunk/test2.txt $ svn commit -m "" 置換しています trunk\test2.txt svn: コミットに失敗しました (詳しい理由は以下のとおりです): svn: '/trunk/test2.txt' (トランザクション '13-1' 中) はリポジトリ側と比べて古くなっています $ svn update trunk/test2.txt svn: ファイル 'trunk\test2.txt' を追加できませんでした: 同名のオブジェクトが既に存在します $ svn diff trunk/test2.txt $ rm trunk/test2.txt $ svn update trunk/test2.txt 'trunk\test2.txt' を元に戻しました svn: ファイル 'trunk\test2.txt' を追加できませんでした: 同名のオブジェクトが既に存在します $ ls trunk test.txt* test2.txt* test3.txt test4.txt* $ svn delete trunk/test2.txt --force D trunk\test2.txt $ svn commit -m "" 削除しています trunk\test2.txt svn: コミットに失敗しました (詳しい理由は以下のとおりです): svn: '/trunk/test2.txt' (トランザクション '13-1' 中) はリポジトリ側と比べて古くなっています
svn copyはタイムスタンプが変わる。
svn copyするとタイムスタンプが変わる。それはまあ、そういうものだと思えばいいのだけど、そのせいなのか、たまに妙なことが起きる。
svn merge tags/RBOLDREL_1_0_1@HEAD tags/RBOLDREL_1_0_2@HEAD trunk D trunk\test2.txt A trunk\test2.txt A trunk\test4.txt
なぜかtest2.txtに対して削除と追加が起きている。test2.txtは全く変更されていないファイルで、上記のどのタグでもtrunkでも同一の内容。まぁSubversionなら履歴が残るからいいかなということでcommitすると、
svn commit -m 'RBOLDREL_1_0_1からRBOLDREL_1_0_2までをtrunkにマージ。' 置換しています trunk\test2.txt svn: コミットに失敗しました (詳しい理由は以下のとおりです): svn: '/trunk/test2.txt' (トランザクション '13-1' 中) はリポジトリ側と比べて古くなっています
う〜む…気持ち悪いな。とりあえず、このエラーが出たらdiffを見てtouchするしかないか。
続ケロリン
衛生上の理由で木からプラスチックにというのがきっかけ。
このストラップ、ちょっと欲しいかも。
ほんもの(?!)。やっぱり見覚えないな。というか広告に合わせて一面黄色のパッケージにすべきだよ。その方が目にとまるし、つい買ってしまうはず。
こんなCMも、と思ったら静岡だけで流れたらしい。最後の「ニン」が謎。
Subversionでディレクトリが衝突
A trunk\test2.txt U trunk\test.txt C trunk
マージ中にtrunkディレクトリが衝突。ファイルじゃなくてディレクトリが衝突？ と思ったら、マージ元の2タグが同じ名前で内容が異なるプロパティを持っていた。そうか。こういう場合って衝突になるんだな。
ケロリン
今も銭湯にあるのかな。しかし改めて考えてみると、なんで銭湯にケロリンの洗面器があったのか、ちょっとした謎だ。というか何で内外薬品は、洗面器で宣伝をしようと思ったんだろうか。とはいえ、こうして明瞭に覚えているということは宣伝は成功だったということか。いやでもバファリンばっかりでケロリンって買ったことなかったり。じゃ、だめじゃん。薬局いって「ケロリンください」は、ちょっと、躊躇するよなぁ。
svnのdiff
ちょっといやなクセを発見。
$ svn update -r2 リビジョン 2 です。 $ ls test.txt*
$ svn update -r3 A test2.txt U test.txt リビジョン 3 に更新しました。 $ ls test.txt* test2.txt*
test2.txtはリビジョン3で新規追加されたファイル。diffをとると、
$ svn diff -r2:3 Index: test2.txt =================================================================== --- test2.txt (リビジョン 0) +++ test2.txt (リビジョン 3) @@ -0,0 +1 @@ +Test2 Index: test.txt =================================================================== --- test.txt (リビジョン 2) +++ test.txt (リビジョン 3) @@ -1 +1,2 @@ Test1 +Test2
あたかも最初の行に1行追加されたかのように見える。
CVS備忘録
cvs update -r HEADとcvs update -Aは違う。前者はHEADのSitckyタグがつく。
$ cvs status cvs status: Examining . =================================================================== File: test.txt Status: Up-to-date ... Sticky Tag: HEAD (revision: 1.1.1.1) ...
HEADはリリースタグと思われているようで、このような状態だと変更できなくなる。
$ ls >foo.txt $ cvs add foo.txt cvs add: cannot add file on non-branch tag HEAD
ワーキングコピーをブランチにupdateしてから、HEADとdiffすると、HEADをブランチの先端と認識しているように見える(cvsのバグなんだろうか)。
$ cvs update -A cvs update: Updating . $ ls CVS/ test.txt* $ cvs update -r RB_1_0 cvs update: Updating . U test.txt U test2.txt U test3.txt $ cvs diff -r HEAD -r RB_1_0 cvs diff: Diffing . ... 何も表示されない。
ISO4000
オリンパス、ISO4000撮影が可能な10倍ズーム機「SP-510UZ」
ついにISO4000か。そのうちISO9000とかISO14000とか出たら、おもしろいな。面白いだけだけど。
doPrivileged()
ようやくdoPrivileged()の動作が分かった気がする。どうもJavaセキュリティは、1.0, 1.1, 1.2以降とで色々と変わっているものだから、情報が錯綜している気がする。やっぱりWeb上の断片的な情報を見ていてもだめだ。このあたりを読んで、ようやく頭の中が整理できた。
Eclipse-3.2だとソースディレクトリの.svnがクラスファイル作成先にコピーされるらしい。
そういえば、一度だけなぜかクラスファイルを格納するディレクトリがSubversionの管理下になってしまって、そんなバカなことするわけないので、Subversionのバグだろうかと、ちょっと不安になっていた。そんなバグがあったら安心して使えないし。
思い出してみると、丁度その頃、Eclipse-3.2が出たので試しに入れてみて、djUnitが動かないから3.12に戻した記憶がある。これが原因だったのかもしれない。
手元で試してみた。確かにクラスファイルを格納するディレクトリに、.svnが出来てる。この辺によると、subclipse入れるか、srcでexclude指定してねってことなんだけど、**/.svn/**/*とか書いてもダメだ。指定の仕方が悪いんだろうか。**/.svn/*, **/.svn/**、どれもダメっぽい。
bloglinesに乗り替え
最近DELCOの調子が悪くて、フィードが更新されない。どうも変な感じで/.-Jは更新されないけど、/.本家は更新されるとか、挙動不審なのでbloglinesに乗り替えた。前に試した時は、ものすごく重かった記憶があるのだけど、全く問題ないレスポンスだ(今のところ)。特にいいのは、モバイル用のビューがある点。最近blogはケータイで読む事が多いので便利。というかPCの場合もこっちのビューの方が軽くていいかも。
なんでかなぁ
提出しちゃってから、読み返す。
メール出しちゃってから、読み返す。
書き込んじゃってから、読み返す。
で、後から間違いに気づいて訂正を入れる二度手間。どうして予め読み返しておくことができないんだろう。いや正確には、その時はちゃんと読み返しているんだけど、気付かないのだ。それがなぜか出しちゃってからだと色々と気付いたりする。もう出しちゃったメールを何度も読み返したくなってしまうのも謎だ。
PETボトル
昔、こんな会話があった。
私「テレカのようなPETカードで」
「PETって何」
私「何ってえ〜とポリエチレンテレフタレート」
「…かついでる？」
PETボトルという言葉が一般的になったから、普通に使っていたのだけど、一般には、なんとなく愛玩動物のpetにかけた商品名か何かみたいな感覚の方が多いのかもしれない。わざわざ樹脂の名前を付けてPETボトルなんて愛称を考えたやつは、なかなかセンスあるのかも。ABS器とかPVCホースなんて絶対言わないし。
svn文字化け
なぜかWindowsXP環境の方だけ、UTF-8でメッセージ出力される。環境変数APR_ICONV_PATHをsubversionをインストールしたディレクトリの下のiconvに通すと直る。なんでWindows2000の環境の方は大丈夫なんだろうか。と思ったら、設定されてたよ。どうやらインストーラパッケージの方で導入すると自動設定されるようだ。
備忘録：openssh
使用したopenssh(http://www.openssh.org/ja/)
openssh-3.9p1-1fc2
openssh-clients-3.9p1-1fc2
openssh-server-3.9p1-1fc2
putty(http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html)
putty.zip
/etc/ssh/sshd_configの変更。
Protocol 2 PasswordAuthentication no
ログインすべきユーザで以下を実行
ssh-keygen -t rsa
パスフレーズを入力すると.sshディレクトリが作成されて、id_rsa.pubとid_rsaが生成される。
id_rsaをクライアント側にコピーして、サーバ上のファイルは消しておく。 .sshディレクトリの属性が700で、ownerがログインすべきユーザになっている事を確認。
クライアント側でputtygenを起動。
Loadボタンを押して、id_rsaを読み込ませる。パスフレーズを聞いてくるので入力。
Save private keyボタンを押して、秘密鍵を生成。
Public key for pasting OpenSSHのところに表示される公開鍵をコピーペーストして、サーバ上の.ssh/authorized_keysにしまう。このファイルの属性は600に、ownerはログインするユーザにしておくこと(インターネット上の情報だと、ファイル名がauthorized_keys2となっているのが多いが、これだと"Server refused our key"と表示されて接続できない。ログに何も情報が出ないので、これで数時間はまった)。
クライアント側でputtyを起動。
SessionでprotocolにSSHを指定。
Connection->SSHで、protocol versionに2 onlyを指定。
SSH->AUTHで、生成していおいた秘密鍵を指定。
必要に応じてSessionでsaveを押して設定保存。
Openボタンで接続。パスフレーズを入力すると、接続される。
OSに望むこと
こんな風に考える人もいるんだ…。自分的にはOSはもうWindows2000レベルでいいかな。あとは細かいところを詰めて欲しい。必要リソース量を減らすとか、オーバヘッドを軽くとか、起動を速くとか。あとバグ修正。赤外線通信に失敗するとか、メモリが多いとハイバネーションに失敗するとか、というかバグなんだからさっさと直して欲しい。あとバグじゃないけど、時々1つファイル消すだけで1分くらいかかるのはなんとかして欲しい。
イノベーションはアプリケーションでやる方向で。
CVSのブランチタグとリリースタグ
あるリリースタグでupdateして変更してからコミット。同じリリースタグで取得し直してみると、変更が反映されている。
結局、リリースタグとブランチタグって同じものなんだろうか。cvs logで見ると、どっちもsymbolic nameだし。変に別の名前付けないで、単にタグじゃだめなんだろうか。なんで、cvs tagに-bなんてオプションが必要なんだろうか。
Subversionはリリースタグへの変更を禁止できるようだ。
コンパイルエラー放置
[備忘録] CVSでバイナリをテキストに変換。
最近のCVSはcvs adminではなくて、cvs update -kkvしてから、cvs commit -fする必要があるようだ。
複数ファイルをディレクトリ指定で変更しようとしたら、失敗。ファイルを指定しないとだめのようだ。
新宿まで行くか、やめるか
ちょっと本が買いたくて、近所の駅デパートに行ったのだけど、いいのが見つからず。買いたい本が特定されていればAmazonで終了なんだけど、色々比べたい時は、やはり今のところは本屋の方がいい(そのうちオンラインでも中身をある程度立ち読みできるようになるかもしれないが)。さて明日、新宿に行くかどうか。迷う。
しかしあれだ、結局、休みの日まで電車に乗る気力は無いから、車で行くわけで、ガソリン代に、駐車場代、行ったら行ったで余計なもの買ったりとか、行き帰りでの余計な時間の浪費とか、そもそも、ここでどうしようかと思い悩んでいる時間とか、わざわざ新宿まで行っても結局見つからず「取り寄せです」とか言われるリスクとか、その時の精神的ダメージとか(^^;)、そんな事を考えると、Amazonで2-3冊余計に買って、ハズレ品は中古で売るという戦略の方がトータルでは安上がりのような気もしないでもない。
でも別の理由で行きたがっている人が約1名いるので、明日は行くことになりそうだ。
はまった
WebSphere 5.1で、web.xmlをShift_JISエンコーディングにして、サーブレット初期化パラメータのdescription要素に日本語を入れていると、アプリケーションが挙動不審になる。ログに何も出ないから原因に辿り着くまでに3時間くらいかかっちゃったよ…
