プロとしての行為 Act as Proffesional
288ページという少ないページ数の中に、ほとんどの見開きの中に図をいれて、アジャイル開発のすべてがザックリ凝縮された書籍です。思わず「こういうのが欲しかったんだ！」と声に出してしまう内容に仕上がっています。この業界の新人に必ず読ませたいバイブルです。 今の仕事やプロジェクトに問題がある。順調でない。解決策の糸口が欲しい。 アジャイル開発に興味がある。はじめてみたい。どういったものか知りたい。 もっと価値のあるソフトウェアを顧客に提供したい。 ソフトウェア開発に携わるすべての人（プログラマ以外にも）にオススメします。東京に住んでいる人はよかったら読書会に参加してください。 良いコードを書く技術 -読みやすく保守しやすいプログラミング作法 (WEB+DB PRESS plus) 今年、プログラミングを本格的にはじめた人や、会社に入って多人数での開発をはじめてやる人に読んでもらいたい書籍。自分一
ペアプログラミングについてみんなが誤解していること | Act as Professional
プログラマ1人で完成できる仕事に、2人のプログラマを投入して、直感的に判断してペアプログラミングを拒否する人がいます。これには大きな間違いとリスクが潜んでいます。ペアプログラミングに対する真実を理解しましょう。 ペアプログラミングはコードを書く時間が15％増える1999年にユタ大学でおこなわれた実験によれば、設計の時間を別にして、ソロプログラミングに対してペアプログラミングを実施したペアは平均して15％多く、プログラムを書く時間に費やしました。 では、なぜペアプログラミングを選択するのか？将来的なテストと現場のリソース要求を減少させるためです。一般的なシステムにバグが見つかると業界のデータでは、33時間から88時間を修正に費やすそうです。これが、開発期間中に欠陥を修正すると0.5時間から88時間の時間を節約できることになるのです。したがって、ペアプログラミングは寿命の長いソフトウェアほど、
IT系勉強会に参加する人が実践すべき10のこと | Act as Professional
イベントの定義を事前に理解する 大きく分けて、イベントには2つのタイプがあると感じています。この２つのタイプを理解して、十分な準備をしてイベントにのぞみましょう。 講師から講義を受けて、知識を “教えてもらう” スタイル 特定のテーマに沿って、ディスカッションや手を動かして “学びあう” スタイル 告知ページやメーリングリスト、Twitterなどで雰囲気はつかめます。過去の開催情報も公開している勉強会も多いので、それを確認するのが一番確実でしょう。 教えもらうスタイル 「○○入門」といった感じの勉強会が多いタイプです。何も知らないところから、色々と手ほどきを受けて、使い始めてみるきっかけをつかむタイプの勉強会です。ですが、限られた時間で、限られたことをするので、体系的に知識を得られるケースはまれです。 よって、講義を受けたからといって満足してしまってはいけません。実際に自分で手を動かして、
これはマネしたい！スーパーエンジニア達の習慣 | Act as Professional
いままで勉強会に顔を出し、すばらしいエンジニアと数多く会うことができた。そして、スーパーエンジニアと共に仕事をすることもできたし、できている。そんなスーパーエンジニア達が持っていた習慣を僕の経験と視点からまとめてみる。 自分が使う道具を厳選して選んで手入れをしている エンジニアでいえばエディタやツールなど。皆が使っているIDEやエディタを何も考えずに使い始めたりしない。 厳選したエディタやツールを使って、手になじませるのである。手になじませるというのは、2つの意味がある。 1つは操作性に慣れること。呼吸をするように自然に、キーボードの上を駆け回る心地よいリズムを奏でるエディタを選ぶ。 2つめは、自分に合わせて拡張しているということ。プラグインのON/OFFだけではなく、オリジナルのショートカットを設定し、適切なハイライト、シンタックスのチェック、コーディングルールのチェック、様々な言語への
プロとしての行為 Act as Proffesional
Ruby を知らない人に Ruby の話をして欲しいと言われてないけど、ブログを書きました。(*1) 難しい話は抜きにしたいんだけど、抜きにしちゃうとまったく訳わかんないから簡単に説明する。 今回は Ruby の erb ってのを使って元ネタ同様のことを実現する。 mod_ruby が動くサーバなんて自分でつくらないとないだろうけど、 その辺はどうにかしてもらう。 erubyが導入されていれば、ファイルの1行目に #!/usr/bin/eruby -McKuCutf-8 とする。(*2) そんなこんなで、どうにかしてもらったら、 <%= と %> で囲めば動きます。 どうにかしてもらったサーバで example.html というファイルの拡張子を example.rhtml すれば良いだけです。 <%= Rubyスクリプト %> 拡張子を変えずに動かすこともできます。 .html ファイル
達人プログラマーに学ぶ 品質とチームメンバーの役割 | Act as Professional
割れ窓理論というのはご存じですか？建物の窓が割れているのを放置していると、やがてすべての窓が破壊されていくという理論です。 ソフトウェア開発に置き換えると、小さなバグを知っているのにもかかわらず、放置しておくと、どんどんバグだらけになっていくということになります。これは、バグだけいえることではなく、テスト駆動開発にも同じことがいえます。テストファーストのアプローチをせずに、テストがないコードを少しでも積み上げた状態をそのままにすると、どんどんテストがないレガシーコードが生産されていきます。品質は低下していく一方です。 達人プログラマーはどうするのか？ p.229 第8章 達人のプロジェクト 全員が環境の変化を積極的に監視しているかどうかを確認するのです。また、水質検査のチーフを任命するのです。その人が幅広い視野と、短い時間尺度で定期的に、追加機能、新環境といった元々の合議事項に無かったもの
達人プログラマーに学ぶ どこでも自動化 | Act as Professional
達人プログラマーはどうするのか？ p.240 第8章 達人のプロジェクトより 我々よりもコンピュータの方がうまくやってのけるような繰り返しや俗っぽいことは、すべてコンピュータに任せてしまいましょう。我々にはもっと重要で難しい仕事が待ち構えているのですから。 HIROCASTERの経験から cobblerをつかって、OSのインストールは自動化 puppetやChefをつかって、OSの設定やアプリケーションの導入と設定を自動化 capistranoをつかって、デプロイ作業を自動化 Nagiosなどの監視システムやCactiなどのモニタリングシステムへの追加も自動化 こんなことはさっさとやってしまおう。物理サーバが到着したら数分で本番環境へ投入できるように。 Amazon EC2を使えば、物理サーバが到着するのも待たなくてすむ。 達人プログラマーから想像できる開発中の自動化は… シェルを書いてし
達人プログラマーに学ぶ コメントは必要？不要？ | Act as Professional
HIROCASTERの経験から SIer時代にコメントの重要性と言うより納品物としての必然性を教え込まれた記憶がある。例えば、こんなコメントは不必要である。 class foobar { /** * foobar class のコンストラクタ */ public function __construct() { foo = array(); bar = array(); } } 「public function __construct()」と書かれているのにわざわざ上でコメントを書く必要性はない。同じ意味を違う言語(表現)で書いているだけだ。重複であるといってもよい。DRYの考えに反する。 でもこれ、ドキュメントを自動生成して納品物とする場合、クラスずつにページがあって、コンストラクタの場所にいろいろと書かれている場合と何も書かれてない場合とかってのは、納品物として白紙はまずいわけで、こう
達人プログラマーに学ぶ 絶え間ない結合化と容赦ないテスト | Act as Professional
書いたコードの量が増えれば、増えるほど、比例してバグが増えていきます。 予期せぬバグはスケジュールに致命的な影響を与える。 手を加えたソースの量が増えてからバグを特定するのには多くの時間や労力を費やすことになります。 達人プログラマーはどうするのか？p.241 第8章 達人のプロジェクトより 早めにテスト、何度もテスト、自動でテスト 書いたコードが少ない段階で、少ないテストをして、小さなバグをできるだけ早く解決していく。製品コードとテストコードを同時に書いていくのです。仮にバグを埋め込んでしまったとしても、バグになっている箇所はすぐに特定できるでしょう。 このテストをあながた手を動かしてやっている暇はありません。 あなたは新たなバグを埋め込むために製品コードを書かなければなりません。絶対に自動化しましょう。 自動化してテストを何度も、何度も、繰り返しおこなえるようにしましょう。結合テストも
達人プログラマーに学ぶ リファクタリング | Act as Professional
ガーデニングのメタファーはソフトウェア開発の現実にかなり近いものです。あるルーチンが大きくなりすぎたり、色々なことを実現しようとしすぎている場合、2つに株分けする必要があるのです。また、計画通りうまくいかないものは雑草を抜いたり剪定してやらないといけないのです。 こういったコード記述のやり直し、再作業、再設計を総称して「リファクタリング」と呼びます。 リファクタリングのきっかけ DRYの原則に反している 直交していない設計 時代遅れの知識をつかっている パフォーマンスがわるい クラス、メソッドが長い 名前がしっくりこない 同じようなコピペコードがいくつも見られ、UIを直すとロジックを直して、DBもなおすとか。非推奨のメソッドを使っていたり。ループ分が多いし、やってることとメソッドの名前があっていないとか。みなさんも、思い当たるようなことはありませんか？ タイミングとガン細胞の切除 きっかけ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
