2013年10月18日金曜日

eclipse俺俺チートシート

ショートカット
(macなんで、ctrl ≒ cmd)

移動

  • ジャンプ
    • f3
  • ジャンプからもどる
    • cmd + [
  • クラス検索
    • cmd + shift + r
  • クイック階層移動
    • cmd + t
  • workspaceの検索
    • ctrl + h

生成

  • javadoc生成
    • cmd + shift + j

整形

  • フォーマット
    • cmd + shift + f

TIPS


参考になるリンク
http://hutyao.hatenablog.com/entry/eclipse-shortcutkey



まだ書きかけ

2013年10月8日火曜日

自前のWordPressを運用する意義が見いだせなくなったので、Bloggerに引っ越しました。

wordpress形式をexportしたものを下記のサイトでconvertして、bloggerにimportできました。

http://wordpress2blogger.appspot.com/

ありがたい。

wordpressのほうはしばらく放置しておきますが、そのうち消します。

2013年9月2日月曜日

かつて、フィールドワークコンサルティング手法を勝手に試してみた話

とどのつまり、何をしたらゴールなのかよくわからない仕事ってあると思います。

普通、なんの仕事でも、始まりの時に、勝利条件を明確にするものですが、仕事を依頼する側も、仕事を受け取る側も、勝利条件がわかっていないとき、まずゲームのルールを探らなければいけない時があります。

現実世界は、ゲームのルールなんて、どっかに書いてあることも少ないので、みんな(利害関係者たち)これがルールかな、とおもったものが、ゲームのルールとなります。

で、ゲームのルールを探る必要があるときに、その手法っていろいろあるかと思います。

何年か前のしごとで、フィールドワークコンサルティング手法を勝手に使ってみたことがありました(フィールドワークコンサルティングという言葉は使ってない)。その時の感想をメモがてら書いておきます。

参考リンク
フィールドワークを活用したコンサルティング手法とその効果

(今日skypeでなぜなぜ分析の話題を出したら、この数年前の仕事を思い出しました)

フィールドワークコンサルティング手法に対する自分の理解



  • 文化人類学のフィールドワークをベースにしている

  • STEP1.えらいひとにインタビュー(まとめておく)

  • STEP2.業務フローをつくる

  • STEP3.現場に張り付く


    • 現場の人の動きをひたすらメモる(なるべく先入観なしで)

    • 邪魔者扱いされるが泣かない


  • STEP4.現場の人を含めた利害関係者で、ディスカッションしたり個別にインタビュー

  • STEP5.まとめて、改善の実行案つくる(もしくは改善案の実行まで行って)おしまい(次につなげる)


きっかけ:とある依頼



  • SE派遣をしているSIerがありました

  • 派遣している方(SIer)も、受け入れている方(お客さん)も、現場でなにをやっているのかイマイチよくわかってません

  • でも、改善したいです

  • 改善とかしていきます前向きさをアピールしたい

  • あと、実際現場ブラックボックスなんだよねー


前提条件



  • 期間は半年

  • この件に裂ける人員は俺一人

  • 0.3人月 * 6ヶ月ぐらいでよろぴく

  • 俺はただのしがないSEだった(25歳ぐらい?)


    • この手のしごとはしたこともなかったし、誰もやり方を教えてくれない。



どうしよう



  • 契約や、日々のドキュメント類は見せてもらったが、これだけだとやっぱりよくわからん

  • とはいえ、きれいなBPRっぽいテンプレドキュメント出したところで、なんか納得されなさそう

  • 逃げたい

  • ぐぐる

  • 富士通のサイトに面白いはなしがのってる

  • これだ


まず、やったこと



  • 仮設を立てる


    • 現状こういう問題があるんじゃない?


  • スケジュールを立てる


    • ざっくりと


  • キックオフをする


    • 利害関係者を集めれる範囲でキックオフをして、これから半年やることを宣言する

    • この時は、調査3ヶ月、施策3ヶ月ぐらいにしといたと思う

    • 怒られたらその部分はなおす


  • シートを作る


    • インタビューシート、フィールドワークのメモ用シートなどをつくる



じゃあインタビューしてみよう



  • 利害関係者のなかでも偉い人方面にインタビューしてみる


    • 同じ船に乗ってるとは思えないほど、認識が違う

    • 逃げたい

    • 無知な若者が、失礼なことを聞いてるんですぅという感じで相手の器量に期待する方向で物事をすすめることを決意する。若くて良かった。


  • 現場の人にインタビューしてみる


    • 現場ならではの問題意識をいろいろ抱えている

    • よくわからないところは、フィールドワークで補うか

    • この時点で現場の人が助かる方向に物事を進めようという気になる

    • 偉い人方面は、政治のできる人になんとかしてもらおうという気になる



で、フィールドワーク



  • 週2回ぐらい、現場にいく

  • 現場のSEの後ろについてまわる(マジで)最初はすごく恥ずかしかった。

  • だんだん慣れてくる。

  • あんたなんなの?の視線にもめげない。

  • やっぱり答えは現場にある。


仮説の修正、結果の報告、施策案を提示



  • ブラックボックスってのが気になるのであって、箱を開けてあげれば、具体的な議論ができる


    • ブラックボックス→あいつら仕事してんの?(不安の裏返し)

    • ブラックボックスを紙に可視化

    • フィールドワークの結果があるので、説得力はある


  • 現場は疲弊している


    • こういう理由で疲弊しているので、戦力増強なり、効率化(のためのコストをかける必要がある)みたいな話を、利害関係者の偉い人にいう。


  • 紙をいっぱいつくる


    • 現場に近い人にとっては有用な資料

    • 偉い人向けには、ちゃんとエグゼクティブ・サマリーをつくるのを忘れない

    • 偉い人は細かい文書を読まない。くれって言われたら出すぐらいでちょうどいい


  • 改善案を出す


    • この時は現場よりの改善案だった。

    • 実行も結局俺がやることになってしまった。


  • 改善案のゴールを明確にする(KPI)


    • フィールドワークの結果をもとに、定性的、定量的な改善目標を立てる

    • これがゲームのルール



その後



  • 業務改善のためのツールをつくった


  • 施策の結果は、多分、利害関係者全員が納得できるものではなかった。

  • これはひとえに俺の力不足であった。

  • 継続的にコミットできる仕事として、このツールをブラッシュアップしていかないと意味ないなーと思った。


    • そのために、ツールをつくるにしても、その現場の人が扱えるテクノロジーを採用するってのが大事。

    • ただ、自分がそれに習熟しているかは別問題なのであった。。。





まとめ



  • フィールドワーク手法はかなり有用だった


    • 机上で資料を眺めているよりはるかに意味があった

    • 日本の仕事のスタイルで、現場のドキュメンテーションが少ない、ってのも大きい


  • 改善案の実行を定量目標を満たすように達成するのはすごく大変


    • 特に自分でやる場合、その業務なり、テクノロジーに造詣が深くないと、その成果は微妙なものになりがち。

    • なんの仕事でもそうなんだけどね。。。


  • とにかくすばやく


    • ゆっくりやっていると、組織だったり、技術だったりが変わってしまう

    • 来月ココかわるから、手を入れても意味ね~じゃんとか普通に起こりまくる

    • メスを入れるべきところの見極めと、素早さが重要


2013年8月22日木曜日

macでbind使いたい人のメモ

Macでインターネッツ共有をしたときに、自前のDNSを参照させたい時ってあると思います。
そんなときに、MacでBINDを使うメモです。

環境


Max OS X Lion

事前準備



/etc/rndc.keyの作成

sudo rndc-confgen -a


named.confの設定

vim /etc/named.conf


以下サンプル


include "/etc/rndc.key";

controls {
inet 127.0.0.1 port 54 allow {any;}
keys { "rndc-key"; };
};

options {
directory "/var/named";
pid-file "/var/run/named.pid";
allow-query { any; };

// query-source address * port 53;

};

zone "." IN {
type hint;
file "named.ca";
};

zone "localhost" IN {
type master;
file "localhost.zone";
allow-update { none; };
};

zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
allow-update { none; };
};

zone "blog.shase.info" IN {
type master;
file "blog.shase.info.zone";
};

logging {
category default {
_default_log;
};

channel _default_log {
file "/Library/Logs/named.log";
severity debug;
print-time yes;
};
};



zoneファイルを作る


vim /var/named/blog.shase.info.zone


以下zoneのサンプル

$TTL 86400
@ IN SOA localhost root.example.jp.(
2002122001 ; serial
3600 ; refresh 1hr
900 ; retry 15min
604800 ; expire 1w
86400 ; min 24hr
)
IN NS localhost.
hoge IN A 0.0.0.0


他のファイルはデフォルトです。

起動と停止



フォアグラウンド起動


$ sudo named -g


デーモン起動

$ sudo launchctl load -F /System/Library/LaunchDaemons/org.isc.named.plist
Password:
$ ps aux |grep named
hoge 41792 0.2 0.0 2434892 548 s007 S+ 9:27PM 0:00.00 grep named
root 41784 0.0 0.1 2439512 6280 ?? Ss 9:27PM 0:00.02 /usr/sbin/named -f


デーモン停止

$ sudo launchctl unload /System/Library/LaunchDaemons/org.isc.named.plist
$ ps aux |grep named
hoge 41800 0.0 0.0 2434892 548 s007 R+ 9:29PM 0:00.00 grep named


あわせてどうぞ


MacOSXのインターネット共有で、MACアドレス制限を行いたい

2013年8月5日月曜日

JBODはややこしい

カイワレ先生のブログを見て、自分のメモがてら、JBODについて書いてみます。
JBODって、なんぞやって、日本人なら誰もが一度は考えると思うからです。(RAID0と何が違うの?って)

現状、JBODという言葉は非常に曖昧な言葉です。
日本語wikipediaにも3つ定義があります。


1.JBOD機能を持つRAIDコントローラカードを取り付けて、JBODにしたいハードディスクをRAIDコントローラカードに接続する。
2.JBOD用として製造されたディスクアレイ製品をSCSIやファイバーチャネル等のインターフェースに接続する。
3.すでに接続されている複数のハードディスクを、ソフトウェア的に統合してJBODとする(Windows NT系列のOSには「スパン」という名称でこの機能が標準装備されている)。


http://ja.wikipedia.org/wiki/JBOD
より。これはこれで微妙なんですが。。。

まず大雑把な理解として、JBODの特徴を2つ挙げます。(どちらともRAIDに対する優位点です)

  • A.複数のディスクにて、容量が異なる場合も(単純な足し算の)単一のボリュームを構成することができる

  • B.I/O性能がよい、とされる



ちなみに、Aが成立するのは、上記wikipedia定義の1,2,3のときです。
Bが成立するのは、1,2です。(とはいうものの、状況によってRAIDのほうが性能がよかったりします。これは使い方によって変わります。)

3のとき、なぜBが成立しないかというと、ソフトウェアで処理している分オーバーヘッドが大きく、I/Oが出ません。

以下は、ざっくり、1と2は、ハードウェアベースのJBOD。3をソフトウェアベースのJBODとします。

ハードウェアベースのJBOD


ハードウェアベースのJBODとHadoopの話に入りますね。ハードウェアベースのJBODも2つの意味があります。1つは、「束ねられたディスク群」という意味のJBOD。

もうひとつは「物理ディスクが別々の論理ボリュームにマッピングされて、並列書き込み可能な状態(仕組み)」です。上記とはぜんぜん違いますね。

つまり、OSから見えるマウントポイントと物理的なディスクが紐付いている状態ということです。(そして、きちんと別々に書き込むように対応したコントローラがいわゆるJBOD対応のコントローラってやつです)。

Hadoopはアーキテクチャ上、並列に書き込みをしてくれるようです。これは、マウントポイントと実際のディスクが一対一で結びついている時に、その並列性が意味を成すということです。逆にRAIDを組んでしまうとストライプ書き込みをしてしまうので、そのラウンドロビン並列書き込みの意味がなくなってしまうということですね。

ハードウェアのJBODは外付けのエンクロージャで使用されることが多く、サーバ筐体の内蔵ディスクで対応しているものがどのくらい世にあるのかは知りません。

ちょっとだけ調べたら、さすがにDELLのCシリーズとかはJBOD対応のチップ(HBAとしての役割しか果たさないモード)を搭載したLSIのチップとか積んでるみたいですね。

ソフトウェアベースのJBOD


ソフトウェアベースのJBODの話は余談です。こっちは束ねる方だけ触れておきます。

お仕事用途ではあまり使われないので。カイワレ先生がWindows Home Serverの例を出してましたが、あれは、「Drive Bender」の実装の話だと思います。(別に、HOME鯖が最初のJBOD実装ってわけではないです)。

なぜ、Home Server(家庭用鯖)にJBODが必要とされてMSが実装したかというと(最新のHOME鯖では外されているようです)、発売当時、まだ、HDDの値段はそれなりに高く、ユーザのニーズとして、「ジャンク屋で買ってきたHDDいくつか、組み合わせて、でかいOneボリューム構成したいんだけどなー」というのがあったからです。

そのニーズに合致していたのが、ソフトウェアJBODだったんですね。

Linuxの場合は、LVMでソフトウェアのJBOD(のようなもの)を構成することができます。

まとめ


JBODという言葉は、いろんな人が勝手にオレオレ定義で使っている言葉です。さりとて、代替になる適当な言葉もないので、JBODいいよーって言いたいエライ人は、適当に新しい言葉をでっち上げていただけると、世のエンジニアが助かります。

ちなみに、Hadoopのクラスタ組もうと思って、JBOD使えないRAIDカードしか積んでないサーバ渡されたら、しょうがないから、1ディスクでRAID 0ってのを一つの筐体で何個か組む感じの構成になるかと思います。お金くれるんだったら、LSIとかのちゃんと対応したチップ詰んだ鯖にしたいですが。

世の事例を見ると、RAID 0を並べたようなものをJBODなんて言ってる例もあるので、みんな適当に使ってる単語といえばそんな感じ。

おまけ


JBODではWriteキャッシュを切りましょうが一般的なお約束なのですが、もしかしたらHadoopだと気にしなくてもいいのかもしれません。ぐぐればどっかにそんなこと言ってる人いるかも。

2013年7月13日土曜日

struts2参考になるリンク集

本家




日本語記事



マイナビ




codezine


MacOSXのインターネット共有で、MACアドレス制限を行いたい

MAC,MACややこしいですが、T/Oです。
MACのインターネット共有は便利なので、ついつい使いたくなってしまうのですが、はやりセキュリティを考慮しないのは危険ということで、インターネット共有を行う際に、指定したMACアドレス以外は、接続できないようにしたいと思います。

環境



  • Mac OS X Lion



どのレイヤーでやるか


最初、ipfwでやろうとしたのですが、どうにもうまく行かず。

インターネット共有では、dhcpでIPアドレスをばらまいてるわけですが、ココで指定したMACアドレス以外にはdhcpでアドレスを付与しない方向に切り替えました。

想定外の端末が直接アドレス指定してアクセスしてくるリスクには、払い出すアドレス数の管理+ipfw等で対応することとします。もちろん、無線LANのキーを設定するのは言うまでもありません。

もし、下記を実行して、セキュリティインシデント起こしても当方は知りません( ー`дー´)キリッ

概要:インターネット共有の手順


[システム環境設定] -> [共有] -> [共有する接続経路(Ethernet)] + [相手のコンピュータが使用するポート(Wi-Fi)]を選択し、インターネット共有チェックボックスをONにします。

そうすると、bootpが動き出し、/etc/bootpd.plist が生成されます。このファイルを編集するのですが、難があり、デーモン起動時に新規にファイル生成し、デーモン停止時にファイルを削除しやがります。この点、多少ケアが必要です。

/etc/bootpd.plist 実際のファイルサンプル


[xml]




Subnets


_creator
com.apple.InternetSharing
allocate

dhcp_domain_name_server

10.0.2.1

dhcp_router
10.0.2.1
lease_max
86400
lease_min
86400
name
10.0.2/24
net_address
10.0.2.0
net_mask
255.255.255.0
net_range

10.0.2.2
10.0.2.254



allow

xx:xx:xx:xx:xx:xx

bootp_enabled

detect_other_dhcp_server

dhcp_enabled

en1

use_server_config_for_dhcp_options



[/xml]

allowの部分に注目して欲しいのですが、
[xml]
allow

xx:xx:xx:xx:xx:xx

[/xml]
allowで指定したMACアドレスだけに、IPアドレスを割り振るようになります。(その他はデフォルト値です)

実際のオペレーション


[bash]
#設定ファイルを編集して
sudo vim /etc/bootpd.plist

#chflagsを立てます
sudo chflags uchg /etc/bootpd.plist

# インターネット共有開始
[/bash]

ファイルが消されてしまう対策として、BSD系OSで使用出来るchflagsを利用します(chmodでreadOnlyにしても消されるので)。
もっとエレガントな方法ありそうな気はしますが。。。

再度ファイルを編集したくなったら
[bash]
sudo chflags nouchg /etc/bootpd.plist
[/bash]
上記を叩けばOKです。

ではでは。

参考にしました


https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man8/bootpd.8.html