apacheのrotatelogs

よく知られていますが、httpd.conf等に下記のような記述をすることが多いかと思います

CustomLog '|/hoge/apache/bin/rotatelogs "logs/access_log.%Y%m%d 86400 540' "combined" "

マニュアルに書いてますが

http://httpd.apache.org/docs/2.4/programs/rotatelogs.html

86400ってのは、1日を表す「秒」

540ってのは、offsetなんですが、なぜか「分」なんですね。

上記を設定すると下記のようなファイルができます

access_log.2013101

知らなかったのですが、どっかのバージョンから -l というオプションがついてまして、これを使うとローカルタイム（UTCではなく）を使うようになるので、540が不要になったみたいです。

つまり、+9時間してくれると。

手元のapacheにローテートが入ってなくて、久しぶりにぐぐったので、φ(｀д´)ﾒﾓﾒﾓ...

mockito参考になるリンク集（あとでかく）

http://www.slideshare.net/momomoblue/mockito-12627783

tmux & screen チートシート

tmux

デフォルトはctrl + bだけど、置き換えたほうが使いやすい...

ショートカットキー

• ペイン分割（縦）
• ctrl + b %
• ペイン分割（横）
• ctrl + b "
• ペインレイアウト変更
• ctrl + b [space]
• ペイントを閉じる
• ctrl + b &

コマンド

• 再接続
• tmux attach

screen

•  セッションのデタッチ
• ctrl + a , ctrl +d
• セッションの再接続
• screen -r
• セッション一覧
• screen -ls
 

Clean Code 2章のメモ

社内の輪講で使ったやつ

2章

意味のある名前


意図が明確な名前にする

これはだめ

public List<int[]> getThem() {
List<int[]> list1 = new ArrayList<int[]>();
for (int[] x : theList)
if( x[0] == 4 )
list1.add(x);
return list1;
}


ここがよくない
・暗黙さ

こんなかんじ

public<Cell> getFlaggedCells() {
List<Cell> flaggedCells = new ArrayList<Cell>();
for (Cell cell : gameBoard)
flaggedCells.add(cell);
return flaggedCells;
}

偽情報を避ける

似情報の例

・hp,aix,sco などの変数
unix由来？と錯覚する
・Listではないものに、hogeListとする
acoountsぐらいにしておく
・ごく一部のみが違う名前
・小文字のL,大文字のOなど


意味のある対比を行う

ノイズワード

・数字の連続（a1,a2...）
無情報です
source,destinationなど意味のあるものに

・意味のはっきりしない単語
Info? Data?
おなじです

・aとかtheのようなもの
明確な違いが生じるのであればOK
zorkがあるときに、theZorkはNG


発音可能な名前を使用する

・英単語として発音できるものにしよう


検索可能な名前を用いる

・1文字の名前は小さなメソッドのローカル変数でのみOK
・長い定数はあり
なるべく、enum、でいいんじゃね？


エンコーディングを避ける

・読めないものはよくない
・新たなことを覚えさせるのもだるい


ハンガリアン記法

・辞めよう

例）
long整数 lData
PhoneNumber phoneString; // やってしまう...


メンバープレフィックス

・m_など
そもそもなんで昔つかってたの？？


インターフェースと実装

・Iを前置、IHogeFactory
やめよう
・HogeFactoryImp or CHogeFactory
Cは具象のconcreteかな


メンタルマッピングを避ける

・i,j,kはループの中ぐらいなら可
・プロのプログラマは透明性を大事にする（賢い、のではない）


クラス名

・名詞あるいは名詞句をつけろ
Customer,WikiPage,Account,AddressParserCustomer
・Manager,Processor,Data,Info は避けるべき
・動詞を避けるべき


メソッド名

・postPayment,DeletePage,save などの動詞、動詞句
・Accessors,mutators,predicatesといった名前はメソッドが扱う値に付けるべき(get,set,isを前置しろ)
・コンストラクタがオーバーロードされている場合は、staticなファクトリメソッドを用意し、名前に引数を表現するものを含める

気取らない


１つのコンセプトには１つの単語
・複数のクラスで、fetch,retrieve,getを同じ意味で提供するとかやってはいけない
・controller,manager,driver なんかも紛らわしい
・整合性を持った語彙が大切


語呂合わせをしない

・addに、連結とコレクションの追記、２つの意味があるなどやってはいけない



解決領域の用語の使用

・すべての名前をいちいち業務用語か取り出すのは推奨しない
・プログラマーが分かる言葉（JobQueue,AccountVisitor）がよい


問題領域の用語の使用

・処理がプログラマちっくでないのであれば、業務側から用語を持ってきてもよい



意味のある文脈を加える


根拠のない文脈を与えない

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

まだ書きかけ

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

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

http://wordpress2blogger.appspot.com/

ありがたい。

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

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

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

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

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

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

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

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

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

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

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


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


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


• STEP3.現場に張り付く




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


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




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


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

きっかけ：とある依頼

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


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


• でも、改善したいです


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


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

前提条件

• 期間は半年


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


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


• 俺はただのしがないSEだった（25歳ぐらい？）




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

どうしよう

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


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


• 逃げたい


• ぐぐる


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


• これだ

まず、やったこと

• 仮設を立てる




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




• スケジュールを立てる




• ざっくりと




• キックオフをする




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


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


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




• シートを作る




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

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

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




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


• 逃げたい


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




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




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


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


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


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

で、フィールドワーク

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


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


• だんだん慣れてくる。


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


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

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

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




• ブラックボックス→あいつら仕事してんの？（不安の裏返し）


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


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




• 現場は疲弊している




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




• 紙をいっぱいつくる




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


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


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




• 改善案を出す




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


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




• 改善案のゴールを明確にする（KPI）




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


• これがゲームのルール

その後

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


• が


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


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


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




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


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

まとめ

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




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


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




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




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


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




• とにかくすばやく




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


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


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