コードの複雑さを上げずに「世界の複雑さ」と戦うために読んでおきたい良書5選【2012年のインプットlog-和田卓人】 - エンジニアtype業界で名の知れたプログラマーは、今年1年何を学んでいたのか？ 2012年も残りわずかとなり、いよいよ「年忘れ」の時期になった今、あえて今年1年で学んだことを忘れる前に取材・記録しておこうという本企画。「同業者が役に立ったものは、自分にも役に立つはず」という仮説を基に、彼らの学びlogから、今年の流れと来年の動向予想をしてみよう！
「愛せないコードを書くには人生はあまりにも短い」というタイトルで TDD について講演させていただきました #TddAdventJp #devlove2012 - t-wada の日記（旧）
このエントリは、 TDD Advent Calendar jp: 2012 の 17 日目の参加エントリです。前日のエントリは [twitter:@shuji_w6e] さんの「軽量なテスト駆動開発を目指して」でした。 久しぶりのエントリです。久しぶりどころか、なんと日記の更新が一年ぶりになってしまいました……(もはや年記ですね)。 昨日、二日間開催された DevLOVE 2012 の二日目最後の(?)講演として、「愛せないコードを書くには人生はあまりにも短い」というタイトルで TDD について講演をさせて頂きました。 DevLOVE では何度か登壇の機会を頂いているのですが、昨日はいつもとは少しだけ違いました。その違いとは「イベントで私以外にも TDD の事を講演する人が複数いる」ということでした。諸橋さん([twitter:@moro])の「テストに開発をもっと駆動させたい」と和智さん
テストの男坂 - nemuzukaの「明日から本気出す」
ござ先輩の記事に触発されたので書いてみる。 自分が書いたプログラムに対してテストをする必要があることについてはご認識の通りでしょう。自分の趣味に留まらず、そのプログラム（で作られたシステム）がビジネスを回す上で必要だったり、「お金」という対価を得る場合は特に。 「ちゃんとテストしました」と自信満々で言われ、いざ使ってみてつまんない実行時エラーが出てきた時、受け取った側はどんな顔をすればいいかわかりません。ましてやそんなのが何回も続くとその人の信用はガタ落ちです。時間をかけにかけまっくてシステムを作って、満を持してユーザに見せた時にそんな状態だと人格そのものを否定される可能性だってあります。 言い訳がましく「入ってるべきデータが入っていなかったからです」と報告しても「なんで落ちたかの説明よりもとっとと直せ。お前が作ったプログラムは信用ならん」と言われるの、切ないですよね。でも、ユーザがあなた
テスト駆動開発について僕は誤解していた - 偏見プログラマの語り！
ここ数日 ruby をやってるんですけど、ruby といえばテストらしいので Test::Unit やら RSpec やらを調べてました。しかし僕はこれまでまともな TDD をやってこなかったので、先にテストとは何ぞや？TDD とは何ぞや？ってのを調べたりしていました。 この記事は、ずぶの TDD 素人がテストについて知り始めたまとめです。 1. きっかけは RSpec のドキュメント そもそも RSpec の↓紹介文の冒頭から意味不明に感じたんです。 FAQ:「RSpec って、要は Test::Unit でやっていることを別の書き方にしただけでは？」 この FAQ への短い答えはイエスです。 『スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)』 Rubyist Magazine えっ... じゃあ要らんやろソレ。いちいち手作業でチェック
テストというのは、ソースコードの冗長化だと思う - きしだのHatena
テストというのは、基本的にはソースコードの冗長化だと思う。本来ならプロダクトコードだけ書けばよいところを、信頼性を高めるために複数の視点でのコードを追加する。 また、サーバーの冗長化で、２台構成を３台構成にするよりも、はるかに１台構成を２台にするのが難しいように、テストも、10本のテストを20本にするよりも、最初のテスト(プロダクトコードも含めると２本目のコード)を書くのが一番難しい。 テストがソースコードの冗長化であるなら、アクセスのないサイトでサーバーをクラスタリングするのが単なる金や設定時間の無駄であるように、長期的な信頼性の求められないプロダクトにテストを書くことも金の無駄だ。 アクセスが多いのにサーバー冗長化の金を払わない顧客に対してクラスタリング構成を構築する義理がないように、信頼性が求められるのにテストの金を払わず時間も確保しない顧客のためにテストを書いてやる必要もない。もち
How Google Tests Software - A Brief Interlude
Sure James. Thanks. By any chance will you be covering the topic - What Google really looks for, when hiring testers? ReplyDelete Since I had the honor of having my last, deliberately dramatic, comment included in this post I feel I should make some sort of reply. First of all I am glad that you took the opportunity to clarify the newfound direction of the testing strategy over at Google, it obvio
How Google Tests Software - Part Three
Thanks for sharing your experiences. I like the way you do things at google :-) ReplyDelete Hey James, I haven't been in a testing position for very long, but I've been actively scouring the blogs and reading up on different methodologies in my free time to supplement my hands-on experience. The lack of experience may prove my following point to not really be the case in some companies, but I'll m
How Google Tests Software - Part Two
Interesting. I had never heard of Test Engineer being used as a job title before. Does the addition of the word engineer really represent what the job entails? Or do you think it is a reaction to the typically pejorative title 'tester' or 'QA'. Note: I write test automation code for a living, and have always wondered what a suitable job title should be. ReplyDelete
How Google Tests Software - Part One
Thanks for the interesting post. 2 questions about : "So this means that testers report to Eng Prod managers but identify themselves with a product team" 1) does this also apply to developpers ? 2) Where are Eng Prod Managers sitting ? Meaning : are they embeded in projects also or they stay outsite ? Thanks, Laurent ReplyDelete
Les sources de l'information
Découvrez comment exploiter pleinement les capacités de votre iPhone grâce à ce guide exhaustif. De l’accès rapide aux informations via Apple News et les widgets, à la personnalisation de vos communications avec Messages et Facetime, en passant par l’optimisation de votre appareil avec des réglages précis, ce tour d’horizon vous offre toutes les clés pour enrichir votre expérience utilisateur. App
xUnit Test Patterns - higepon blog
xUnit Test Patterns: Refactoring Test Code 良さを伝えるのは結構難しい。勉強会も開かれているので広く読まれている事は間違いない。ただ読むのはしんどい。「どこから読み始めても分かるように」という筆者のありがたい配慮により、とにかく冗長な構成。全く同じ文章をコピペしたのではないか？という箇所もちらほら。おかげで833ページ。 読む価値はある。筆者は間違いなくテストを書く事と真剣に向き合っている。本書でしか読めないパターンも多い。Mock Object、Stub、Test Spy の違い。Slow Test に立ち向かうための Fixture 。種々の Result Verification 手法などお腹いっぱいの内容。 本書が出たのは 2007年5月。やっと 2007年のテスト事情まで追いついた。次は2009年末に出たGrowing Object-Or
Unit Test vs Functional TestそしてClean Code - masayang's diary
Agile2008でもらったゴムバンドを未だに手首につけている。確かBob Martinだったと思うが、テスト駆動開発と「Clean Code」の関係について熱く語っていた年だ。 メソッドは短く。 メソッドが実現することは一つ。 あるメソッドのテストに色々と条件を設定しているのなら、それはClean Codeではない。 だが我々はその基本を簡単に忘れてしまう。色々とテストのための道具が揃ってきたせいもあろう。基本を忘れて一つのメソッドに色々と詰め込みすぎるとテストが大変になる。Mockがあっても、だ。Fixture使うのはさらに大変だし、Seleniumとかで入力から何から条件を与えるのはもっと面倒。そしておそらく抜けが発生する。 最近、内職でPython使ったアプリを組んでいるのだが、今回は上記「基本」を徹底するようにしている。例えばこんなコードがある。 def nearby(reque
TEF有志によるTestLink日本語化プロジェクト - TestLinkJP
How to Write a Thesis on T-Building A strong introductory paragraph starts with a hook that grabs the reader’s attention. Then, it provides details that lead to the thesis statement. The T Building—formerly the Triboro Tuberculosis Hospital in Queens, New York —is now affordable and supportive housing. It’s also a model for adaptive reuse of historic buildings. Adaptive Reuse of an Historic Buildi
A/B testing - Wikipedia
Challenges[edit] When conducting A/B testing, the user should evaluate the pros and cons of it to see if it aligns best with the results that they're hoping for. Pros: Through A/B testing, it is easy to get a clear idea of what users prefer, since it is directly testing one thing over the other. It is based on real user behavior so the data can be very helpful especially when determining what work
Test Driven Code Review
For same reasons I start reviewing a code from headers, rather than implementation. ReplyDelete Interesting, but there is some danger in here as well. You could see Code Review as a different form of testing. Like a view from a different angle on the product. If you first look at the (unit) tests, don't you loose some objectivity as you start to think alike the one that wrote the tests (which is i
Test Driven Development by Kent Beck | The Pragmatic Bookshelf
Available in: DRM-free Theora Ogg, iPod/iPhone 3 Video, iPad/iPhone 4 Video, and Quicktime Video Download and watch when and where you want If you have tried TDD and you are looking to improve your skills, this series was recorded for you. TDD re-discoverer Kent Beck demonstrates advanced TDD topics on a realistic example: Dividing a big test into slices to increase feedback Dividing a big feature
レガシーコードは南斗聖拳(外から攻める)。新規開発は北斗神拳(内から攻める)、レガシーコード改善ガイド読書会ふりかえり - 未来のいつか/hyoshiokの日記
社内テスト勉強会でレガシーコード改善ガイド読書会の報告をした。 読書会を地味に開催してテストの価値観を共有できたのは非常によかった。そして実際、自分のプロジェクトに試してみた人たちの報告もあった。 一方で社内読書会の課題も見えてきた。やはり、参加者のスケジュール調整が難しいこと、少しずつ参加者が減ってしまうことなどである。皆忙しいし、時には突発のトラブルでスケジュールどおりに参加できない事はある意味致し方ない。忙しいと読書会どころではなく、それに参加しつづけるモチベーションの確保も難しい。*1 レガシーコード改善ガイド読書会View more presentations from Hiro Yoshioka. 今あるレガシーコードとどう向き合うか 新規にソフトウェアを作る場合はTDDでユニットテストを書いていけばいい。この方法論についての報告、参考書などは豊富にある。 レガシーコードという
【書評】経験ゼロでもできるプログラミング現場の単体テスト - GoTheDistance
BBQ和尚の同僚の方とは知らずタイトル買いした本ですが、タイトルに偽りなしです。とにかく平易で優しいわりにいちいち実践的で助かってます。最小の努力で結果が出るように配慮されています。 経験ゼロでもできるプログラミング現場の単体テスト 作者: 片桐一宗出版社/メーカー: 翔泳社発売日: 2009/05/29メディア: 単行本（ソフトカバー）購入: 11人 クリック: 564回この商品を含むブログ (26件) を見る この本を買ったきっかけは、とにかくデグレを無くしていい意味で手離れの良いコードを書いて楽がしたい、というもの。その為にはテストツールの使い方よりも、｢どうやってテストコードを書けばある一定の品質が保てるのか｣ということが書いてあるまとまった情報が欲しかった。で、本書をあたりました。 テストコードの書き方がわかっても、テストの内容が不十分であったりテストする単位が均質でなければ意味
テストは誰が書くのか - 未来のいつか/hyoshiokの日記
昨日のエントリの補足的なもの。id:hyoshiok:20100612#p1 テストは誰が書くのか。もちろんコードを書いた人が書く。コードは誰が書くのか。設計をした人が書く。誰が設計をするのか。要求を分析した人がする。このように一つの機能について一人が責任を持って行うのがベストプラクティスになっている。 ところが、日本のソフトウェア産業の8割以上は受託開発と言われているが、そのような現場では誰かが一貫してすべての工程に責任を持つということは普通行われていない。工程を上流下流とわけ、いわゆる一次受けと呼ばれる大手SIベンダーが要求分析をし、その下に設計実装する下請け、孫請けを持つという多重構造になる。 要求分析をして、仕様にまとめるわけであるが、実装のコスト（実装のしやすやしにくさ、実装工数の大きさ）はほとんど考慮されない。契約文書として、これこれを実装することみたいなものがあらかじめ取り交
テストを書くこととテストをすることの違い - 未来のいつか/hyoshiokの日記
会社でレガシーコード改善ガイドの読書会をやっていて、次回で読了だ。4月に入ってから週に1回くらいのペースでやっていて、2ヶ月半くらいかかった。途中、ゴールデンウィークや所用で開催しないこともあったので、１０回くらいで完走したことになる。 一人当たり、1章ないし2章くらいを担当して、その章に書いてあることを説明した後にみんなであーだこーだ議論をする。気になったことを質問したり、どうも良く分からないことをみんなで考えたりする。 テストがないコードはレガシーコードだ！というキャッチフレーズはわたしの心をとらえた。 参加者の皆さんとその価値観を共有できた事はうれしい。 現場での開発の実情をいろいろ教えてもらった。テストを書くことはあまり一般的ではないということにわたしは衝撃を覚えたのであるが、この読書会を通じて、テストを書かない開発というのがレガシーコードを作っている事に他ならないという共通の認識
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
