記事は古いけど、気付いたことをメモ。 【元ネタ】 【ITpro Challenge!】「高い生産性を実現する『ハッカーのソフトウエアエンジニアリング』とは」---Google 鵜飼文敏氏：ITpro (前略) 開発もなるべく小さな単位で行う。「設計しつつ実装，こまめにマイルストーンを設定する。小さい単位で動くものを作る。作る順序は後で使うものから。テストしやすさ，デバッグしやすさのために重要」（鵜飼氏）。 既にあるコードを利用して，新たに作らないことも重要だ。「何を作らなくていいか，利用できるか，把握する。持ち駒が多ければ多いほどいい」（鵜飼氏）。 Googleに入って感じたのはコードレビューの有用性だという。「コードレビューはとてもいい。ゆるいペアプログラミングのようなものでお互いのコードをチェックできる。ペアプログラミングは時間が拘束されるが，コードレビューならいつでもどこでもできる」
2009/12/12に開催されたDevLOVE2009 FUSIONにて講演する機会を頂きました。 SlideShareに資料をアップしました。プレゼンテーションZenに多少影響を受けてるので、講演時の説明がないとわからない部分があるかもしれませんが、その辺りは、今後のブログで補足していきたいと思います。 今回のテーマは、同じIT業界と言っても、受託開発（SI）とサービス提供（SaaS）では、すごく大きな違いがあるということを、「ソフトウェア開発」という観点で伝えようというものでした。 まとめとしては、受託開発やパッケージは「製造業」であり「Point of Sales」の考え方を基底においてビジネスをすべきで、そこでは、１度の「納品／出荷」が顧客へ提供できる瞬間になるのに対し、ソフトウェアサービスビジネスでは「サービス業」であり「Point of Use」の考え方でビジネスをするためには
ページ分けの多い記事も自動でめくれる、クリック一発で翻訳出来る――。 便利な拡張機能の豊富さで知られる人気ブラウザーといえばFirefoxだ。だが、そこに現在Google Chromeが「エクステンション」と呼ばれる拡張機能で猛追を始めている。グーグルが9日に公開したサイト「Chrome Extensions」にはすでに、500本を超えるエクステンションが登録されている。 エクステンションに対応するChromeは現在、Windows版およびLinux版のみ。いずれも正式版ではなく4.0ベータ版で、体験したい人はそれぞれをインストールすることになる（エクステンションを入れようとするとダウンロードを促されるので、それに従えばオーケー）。Mac版も近いうちに対応予定とのことなので、しばしお待ちを。正式版の4.0リリースは2010年の見通しだ。 リリース間もない現在の問題は、Firefoxのときと
元記事 mercurialでチケット駆動開発 - logiqboard default・confirm・topic*いっぱいというbranchの使い方の懸念点 リリース順≠開発完了順（チケットAは開発完了しているが優先してチケットBだけを今すぐリリースしなければいけない という状況がありえるということで気になったのは、あるtopic branchでの変更について、 confirm branchにmergeして動作を確認しても、 そのtopic branchをdefault branchにmergeして正しく動作する事を保証しない、 ということ。 例えば開発完了したtopic branchがb1〜b5の5個あったとして、 b2,b4のみリリース予定は他より後になっているとする。 この時、confirm branchにb1,b2…という順番でmergeされているとして、 b5の正常動作がb2や
こいつを使おうと思ったが、上手く動かなくて困った。 HgTracHook - Mercurial やったこと TracMercurialを入れた 設定の仕方等は書いてあることに従ってやった そもそも必要なのかとかよく分かっていない HgTracHookを入れた bitbucketからclone http://python.g.hatena.ne.jp/Ubuntu/20081205/1228436862のやり方で調べたsite-packages直下にtrachook.pyを配置 設定の書き方は上記に従った 出たエラー hg push --debug -v --traceback ってやったら、 calling hook changegroup: trachook.hook error: changegroup hook raised an exception: 'str' object i
先日、ライブドアの社内勉強会に参加した。他社の社内勉強会をするという機会はそうそうない。その貴重な機会を与えていただいたライブドア情報環境技術研究室 執行役員 CTA 室長 伊勢幸一さんには厚く御礼を申し上げたい。担当の門馬さんにも大変お世話になった。また、当日参加していただいたライブドアの皆様にも御礼を申し上げたい。*1 書き出しがいきなり固くなちゃった感があるが、お話はいつものカーネル読書会のことというか、勉強会のことというか、それを社内でやってみたら、どーゆーことになったかとか、技術とはまったく関係ないよた話をさせていただいた。 今回、お話をさせていただくにあたり、わたしのセッションの部分を後日公開するということをお願いした。わたしのプレゼンは日頃いろいろなところでお話しているものであり、所属企業に属する非公開情報も特にないので、無理を言ってお願いした。 カーネル読書会の作り方＠ライ
以前のhokorobiさんの記事にあったTestLinkの使い方の意味がようやく分かったのでメモ。 僕が勘違いしていた部分もあったので、再考してみる。 【元ネタ】 TestLink を使ってみた - hokorobiの日記 テスト手法の概念をTestLinkで説明する: プログラマの思索 第5回 脱Excel！ TestLinkでアジャイルにテストをする - hokorobiの日記 TestLinkの運用方法は、開発チームがシステムテストで使う場合と発注者が納品モジュールを受入テストで使う場合で、観点が異なるようだ。 【1】開発チームがシステムテストで使う状況では、テスト計画をイテレーションと同一視して、Agileに開発するのがいいと思う。 理由は、スコープを狭めて徹底的にテストでバグを潰し、リリースできる範囲を少しずつ広げる手法の方が、システムの品質を確保しやすいからだ。 バグが残ってい
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） ストーリー分割によって、元のストーリー上のいくつかの仕事はやる必要がなくなるかもしれない（リーンの警告にあるような無駄をしなくなる）ストーリーを小さくした方が扱いやすく、分かりやすいストーリーを分割すると、個々のリスクが明らかになるストーリー分割によって、変更への対応が容易になる。大きいストーリーが変更されると大きなショックを受けるが、小さなストーリーならショックも小さい小さなストーリーの方が複数人で同時作業しやすい。ストーリーが大きくて専門知識が必要だと、一人の人にそのストーリーを任せる傾向にあるが、小さく分割されていれば、専門的知識がなくてもできるところがたくさんあるストーリー分割によって、本当のストーリーのサイズが明ら
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
