kidooom

Effecive Java 勉強会資料

勉強会, 読書メモ

社内のEffectiveJava勉強会で７章を担当して発表したので張っときます。

Permalink | コメント(0) | トラックバック(0) | 19:18

CleanCode第２章読書メモ

読書メモ, 勉強会

今の開発チームに新しくAさんという方が来て、その方の机の上に丁度CleanCodeが置かれているのを見つけて軽く盛り上がりました。やっぱ良い本だよねーと共感を得たところで、来週からチーム内でCleanCode勉強会をやることになりました。

こういう仲間がたくさんいる職場で良かったなーと改めて思います。

とりあえず簡単にですが、まずは自分が担当分の「第２章　意味のある名前」をSlideShareに挙げてみました。

Permalink | コメント(0) | トラックバック(0) | 23:24

ソフトウェア開発の食物連鎖 〜Code Complete 上巻 読書メモ〜

読書メモ

コードコンプリート上巻を読んでいて面白いと思ったメタファがあったのでメモしておきます。

プログラマはソフトウェアの食物連鎖の末端にいる。アーキテクトは要求を取り込み、設計者はアーキテクチャを取り込む。そして、プログラマは設計を取り込む。

生態学的に健全な環境では、カモメは新鮮な鮭を食べる。酒は新鮮なニシンを食べ、ニシンは新鮮な水中昆虫を食べているので、カモメは鮭を食べて栄養分を得る。その結果、健全な食物連鎖が生じる。プログラミングでは、食物連鎖の各段階に健康に良い食物があると、幸せなプログラマによって書かれた健全なコードが得られる。

汚染された環境では、水生昆虫は放射性廃棄物の中を泳ぎ、ニシンはＰＣＢによって汚染され、ニシンを食べる鮭は海上に流出した石油にまみれて泳ぐ。カモメは不運にも食物連鎖の末端にるので、汚染された鮭から石油を摂取するだけでなく、ニシンのＰＣＢや水生昆虫の放射性廃棄物まで摂取してしまう。プログラミングでは、要求が汚染されると、それらによってアーキテクチャが汚染され、アーキテクチャによってコンストラクションが汚染される。こうして、栄養不足の不機嫌なプログラマと、放射能に汚染された欠陥だらけのソフトウェアが生じることになる。

ウォーターフォール型開発では基本的に後戻りをしないため、上流が汚染されていると最後までその汚染を引きずることになりかねません。それに対し、イテレーション型開発では少しずつ全体の汚染を取り除いていくスタイルであるため、上流での汚染のリスクが軽減されることが期待されます。

ウォータフォール型（逐次型）か、イテレーション型（反復型）のどちらを選択すべきかはソフトウェアの種類やプロジェクトの形式、メンバーのスキルなどによって異なります。

下記のような場合には、より逐次性の高い（事前に準備を済ませる）手法を選択した方が良いと考えられています。

• ウォータフォール型（逐次型）が適している例
  • 要求がかなり安定している
  • 設計が比較的単純で、かなり理解されている
  • 開発チームがそのアプリケーション分野に精通している
  • プロジェクトのリスクが低い
  • 長期的な予測が風要である
  • 要求、設計、コードを下流で変更すると、高くつく可能性がある

一方、次の場合には、反復型（作業を進めながら作業する）手法を選択した方が良いと考えられています。

• イテレーション型（反復型）が適している例
  • 要求が十分に理解されていない、あるいは他の理由により要求が変化しやすいことが予想される
  • 設計が複雑である、手間がかかる、あるいはその両方である
  • 開発チームがそのアプリケーション分野をよく知らない
  • プロジェクトのリスクが高い
  • 長期的な予測は重要でない
  • 要求、設計、コードを下流で変更しても、安価な可能性がある

現在のスピード感あふれるソフトウェア開発の潮流を考慮すると、反復型の方が開発スタイルとして適していそうですね。

反復型開発 Wilipedia

Permalink | コメント(0) | トラックバック(0) | 11:06

ログインログなどからユニークユーザ数を算出する方法メモ

linux

とある期間に存在する大量のログインログからユニークユーザ数を算出したのでその時のメモ。

ログインログのフォーマットは下記とします。

YYYY-MM-DD hh:mm:ss UserID IPaddress UserAgent ...

awk使ってUserIDだけを抽出し、sortをかけた後、uniqで重複を排除して行数をカウント。

awk '{print $3}' ファイル名(正規表現でまとめて指定) | sort | uniq | grep -c .

awkちゃんと覚えていきたいです。

Permalink | コメント(0) | トラックバック(0) | 01:46

小さなチーム、大きな仕事

読書メモ

新卒で大企業に入社した自分にとって、うなずける内容がたくさん。やはり組織には小数精鋭が大切で、精鋭じゃない人が入って肥大化した組織はどんどん弱体化していくと思う。成長していける環境があればそれでも発展していけるだろうけど。

以下、メモ。

• 会社の規模なんて気にしない。小さいことは通過点ではない。小さいことは、目的地でもある。
• 必要なものは思ったより少ない。
• 機能が多いから優れているわけではない。芯から始める。やることを減らす。
• たくさん働いた（ワーカーホリック）からって偉いわけじゃない。少ない時間で効率よく成果を出す。
• 料理人を見習う（レシピを教える）。舞台裏を公開する。
• 無用な人は雇わない。経験年数は関係ない。履歴書はバカバカしい。
  • 雇用に関しては最近痛い目にあったので激しく同意。その時点でのスキルや経験ってのはあんまりアテにならなくて、伸びしろが重要だと感じた。
• 従業員はガキではない。５時に帰宅させる。

Permalink | コメント(0) | トラックバック(0) | 18:05