2013年04月16日

[将棋]天才による天才の解説

タイトルではよくわからないかもしれないが、本の帯にそう書いてあるんだもんよ。



まだ読破はしてないんだけど、いつもの加藤先生です。('ω')
posted by koteitan at 14:51| Comment(0) | TrackBack(0) | 将棋 | このブログの読者になる | 更新情報をチェックする

2013年04月05日

modern.ie ってなにげにグッジョブじゃないか?

まだ、パラパラとしか見ていないが、WEB開発してる人にはけっこういいんじゃない?
仮想環境も貸してくれるし、オンラインスキャンもしてくれるし。

どれぐらいの精度があるのかとかは要検証だろうけど
少なくとも大雑把に荒を取る分にはいけそうですな。

http://www.modern.ie/ja

なんやかんやいうても、結局IEで見てる人が一番多いしなぁ。
posted by koteitan at 10:24| Comment(0) | TrackBack(0) | その他備忘録 | このブログの読者になる | 更新情報をチェックする

2013年04月04日

GROOVY グルービー? GROOOOOOOOOOVYyyyyyyyyy!

DIO様風に言うとグルゥゥゥゥゥゥゥゥゥヴイィィィィィィィィィィィィ!

Javaから形式的なところとかいつもこう書く、みたいな箇所を極力排除したといいますか。
まぁ、ここいらのリンクを見るとわかるんじゃないかな。
クロージャとかがちょっと慣れてないとむつかしいかもしれんけど。
http://www.slideshare.net/kiy0taka/jenkins-and-groovy

本はこれが良い感じです。
電子版ありゃよかったのになぁ・・。ipadで読書に慣れちゃってからは
活字はしんどいでう。重さと字の大きさが・・。(拡大したい・・。老眼乙。orz)



Dolphineの続きも書きたいんだけどね、ちょっと今年に入ってから忙しいんだよなぁ。
posted by koteitan at 10:48| Comment(0) | TrackBack(0) | プログラム全般 | このブログの読者になる | 更新情報をチェックする

2013年03月27日

[DB2]導入されているエディション、バージョンの確認方法

以前に書いたかもしれないんだけど、新しめのバージョンから(V8ぐらいだったかな)
db2lsというコマンドがあります。
導入メディアのrootディレクトリにもあったような気がしまする。

確認手順
(1)db2lsを実行して導入場所をしらべる
 db2lsは通常の場合、/usr/local/binにエイリアスがあるので、普通にdb2lsとやればOKです。
 rootユーザーで実施。

(2)実行すると、導入パスがわかるので、db2lsにいくつかオプションをつけて実行する
db2ls -q -p -b <導入パス>

db2licm -l とかでライセンス状態を見てもよいかもしれないけど、こっちのが簡単だと思う。

詳しくはInfocenterで。
http://pic.dhe.ibm.com/infocenter/db2luw/v10r1/index.jsp

posted by koteitan at 17:17| Comment(0) | TrackBack(0) | DB2 | このブログの読者になる | 更新情報をチェックする

2013年03月18日

第2回将棋 電王戦

最近忙しくて、あんまり更新できていません・・・。

さて、表題の電王戦、もうすぐ始まります。
とても楽しみにしております。
もちろん人間側の全勝で終わってほしいですね。

http://ex.nicovideo.jp/denousen2013/
posted by koteitan at 10:55| Comment(0) | TrackBack(0) | 将棋 | このブログの読者になる | 更新情報をチェックする

2013年02月28日

[日記]Retinaに最適の解像度

もう豆粒な文字で使うのは疲れたので、いろいろ調べて
Retinaに最適な解像度に設定しなおし。DTIとかイラストレーターなどを使ったりするときには
巨大な解像度が便利なんだろうけどね。

(1)vmware Fusionの設定から「Retinaの解像度を使う」のチェックを外す
(2)mac側の解像度を「Retinaに最適」を選ぶ
(3)windowsは自動でRetinaの1280×800になる

windows側は特になにもしなくてもよい。vmさんが適切にやってくれます。
うひゃぁー、文字ちいせぇえええええwwwは最初だけでいいかと。
posted by koteitan at 18:46| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2013年02月27日

[日記]windows8 が やってきた

ついに、windows8に移行した!
7もvistaもすっとばして、XPから8に。
office も 2003から2013に。(アップグレード優待)

この記事も、そのwin8から書いている。
去年購入したmacbook pro に vmware fusion を導入して仮想マシンを構築し
そこにwindows が入っている。
キーバインドがちょっと違うし、PFキーがまだ使えないので、漢字変換がすごい面倒なのと
レティーナのフル解像度の場合、文字が豆粒過ぎて罰ゲーム状態なのがつらい。
デスクトップが広いのは良いんだが。(*´Д`)
ま、ぼちぼち慣れるしかないな。

仮想化に移行したので、今後のマシン買い替えや、移行がハイパー楽になる。
それだけでも踏み切った価値はある。

posted by koteitan at 13:38| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2013年02月07日

[java]多重ループからの脱出

大昔のJDKでもできたっぽい。(;´Д`・・・

いままで多重ループの内側から一気に脱出しなければならないようなロジックを書く必要が無いぐらい
ちゃんとオブジェクト指向して書いていたからだ!!!! 

とでも思って慰めておくことにする。
Gotoみたいなもんじゃん・・。例外エラーロジックだとtry〜catchでいいやん。

書き方は分岐先頭or末尾にラベルを書く。(for、while、ifなどなど)

HOGE: for(int i = 0; i< max; i++)
{

}

とか

if(hoge > 0) { HAGA:

}
とか。

脱出には 

break HOGE;

とか

continue HAGA;

とか書く。

まぁ、知らなくてもおk。
3つも4つもループするなら普通はprivateメソッドになるやろ。( ´Д`)
posted by koteitan at 17:47| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする

2013年01月30日

[java]Dolphin!(4)

どこまで書いたかな・・。


//(3)String Switch
String str1="abcde";
switch(str1)
{
case "hoge":break;
case "huga":break;
case "abcde":System.out.println(str1);break;
}


キタ━━━━(゚∀゚)━━━━!!
もうこれでしょーもない private static final int とか Enumを作らなくてよいし、
ソース分析時に、このswitchの数字の意味はなんなんだ・・・、43だけスルーとかなんなんだ・・・。
コメントねーし、ぐぬぬぬぬ(`皿´;)とかも解決!

よし、まぁ待て。落ち着け。
内部ではEnumに自動変換してそうな予感がしてしょうがない。

でゅわ、jdの出番だ。


String str = "abcde";

Object localObject1 = str;
int k = -1;
switch (((String)localObject1).hashCode())
{
case 3208229:
if (((String)localObject1).equals("hoge")) k = 0; break;
case 3213991:
if (((String)localObject1).equals("huga")) k = 1; break;
case 92599395:
if (((String)localObject1).equals("abcde")) k = 2; break;
}

switch (k) {
case 0:
break;
case 1:
break;
case 2:
System.out.println(str);
}

文字列ハッシュでswitchかーって感想だけだと、味気ないので、もうちょっと|д゚)カンサツ

if(localObject1.equals("hoge")){
}else if(localObject1.equals("hoge")){
}else if(localObject1.equals("abcde")){
}
でも良さそうな気がせんでもないし、実際昔はこう書くしかなかった。
でも、先にハッシュだけ比較するほうが計算コストが低くなるので
こういう実装なんだと思う。コンパイル時に対象のハッシュも確定できるし。

つまり、String#equals() の実装見てくれればわかるんだが
比較は大きくわけて5ステップある。

(1)自分自身か?
(2)文字列のインスタンス?
(3)文字数一致?
(4)ハッシュ一致?
(5)文字列のコンペア

(4)の処理は初回のみ実行時計算@インスタンスなので、
JDK7の実装だとハッシュ一致時のみしかラベル文字のハッシュ計算は走らないが、
旧の実装だと必ず走ってしまう。また、(2)の処理は意外にコストが要る計算である。
文字列以外が来る可能性が_でもあるなら、しょうがないけど。

ということで涙ぐましいコスト最適化がかかっているために、こういった表記なんだと思うんだね。


posted by koteitan at 11:07| Comment(0) | TrackBack(0) | Java | このブログの読者になる | 更新情報をチェックする