Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
ソフトウェア見積り - lamuuの勿忘草日記
厳しい仕事が終わり、やっと他の事考えられそう。 去年後半の痛手から立ち直るのはしばらくかかりそうだけど、復活します。 ソフトウェア見積り 作者: スティーブマコネル,久手堅憲之,Steve McConnell,田沢恵,溝口真理子出版社/メーカー: 日経BP社発売日: 2006/10/07メディア: 単行本購入: 31人 クリック: 472回この商品を含むブログ (92件) を見る ということで、またもや見積りのお仕事が降ってきたので、今日は見積りのお勉強。 なんだか、１年に１冊はこの手の本を買ってる気がする。 去年は『初めて学ぶソフトウエアメトリクス~プロジェクト見積もりのためのデータの導き方』だったな。 そして、たいていは身についたかどうかよく分からないまま、見積もったプロジェクトの数だけは増えてゆくという…。 まぁ、いいや。 この本ですが、なぜに『コードコンプリート』の著者が見積りを？
C++開発者の皆さん。テスト、ちゃんとしていますか？ − ＠IT
第1回 C++開発者の皆さん。テスト、ちゃんとしていますか？：連載 C++開発者のための単体テスト入門（1/4 ページ） 連載目次 「ビッグバン・テスト」をご存じですか？ アプリケーション全体を構築する数千行、数万行に及ぶコードをコンパイルし、いきなり全体を走らせてその動作を確認するテスト手法です。われわれプログラマーが絶対に過ちを犯さないならともかくも、そうではない現実を考えると、このようなビッグバン・テストは極めてつたないテスト法です（そもそも過ちを犯さないなら、テストの必要はないのですけど）。 テストとは、ひと言でいってしまえば「思ったとおりに動くかを検証すること」でしょうね。プログラムは思ったとおりには動きません。作ったとおりに動きます。従って、「思ったとおりに動くか」の検証とは「思ったとおりに作られているか」の検証にほかなりません。 ビッグバン・テストでも「思ったとおりに動くか」
Effective Code Reviews Without the Pain | Developer.com
Code reviews in most organizations are a painful experience for everyone involved. The developer often feels like it’s a bashing session designed to beat out their will. The development leads are often confused as to what is important to point out and what isn’t. And other developers that may be involved often use this as a chance to show how much better they can be by pointing out possible issues
間違ったコードは間違って見えるようにする - The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳 2005年5月11日 水曜 私が最初の本当の仕事をはじめたのは1983年9月に遡る。それはオラニムというイスラエルの大きな製パン工場で、16台の飛行機ほどもある巨大なオーブンで、毎晩10万個のパンが作られていた。 はじめて工場に入った時、そのあまりの汚さに信じられない思いだった。オーブンの側面は黄ばんでいるし、機械は錆びていて、そこらじゅうが油だらけだった。 「いつもこんなに汚いの?」と私は聞いてみた。 「なんだって? なんの話をしてるんだ?」とマネージャが答えた。「掃除したばかりだから、今が一番きれいな状態なんだ」 なんてこった。 毎朝の工場の清掃を何ヶ月か続けて、ようやく彼らの言っていたことが理解できるようになった。パン工場では、きれいというのは機械にパン生地が付いてないことを言うのだ。きれいというのは、ゴミ箱に発酵したパン生地が入ってないこと
Code Review FAQ - MDC
コードレビューの目的は何ですか？ コードレビューは、パッチの設計と実装について検証を行うための、基本的な機構です。沢山のハッカーたちが Mozilla の様々なモジュールに対して行う設計と実装を、常に一貫したレベルのものにするために役立っています。私たちは現在、二段階のレビューを行っています。「レビュー」と「スーパーレビュー」です。 もちろんコードレビューは即座に行えるものではなく、このシステムにはある程度の待ち時間が伴います。私たちは、レビュアーやスーパーレビュアーが彼ら自身のハッキングを行うのを妨げずに、レビューの待ち時間を減らす方法を常に模索しています。私たちのシステムは完璧ではなく、将来も完璧にはならないでしょう。私たちは現在もシステムを発展させている途上であり、もし良い方法があるのなら提案してください。 私が書いたコードのレビューを行うのは誰ですか？ あなたは、コードがチェッ
＠IT：明日からできるプロジェクト管理（4） - 単体テストの品質をチェックするには
明日からできるプロジェクト管理（4） 単体テストの品質をチェックするには 1page｜2page｜3page 高野敦 2006/1/12 実装・単体テストの品質をうまくチェックするにはどうすればいいのだろうか。本稿ではまず品質の考え方を概観し、その後、チェックを現実化するツールを紹介していく（＠IT編集部） プロジェクトマネージャ（＝PM）の石出さんは今日も悩んでいます。 石出さん談――。 今度のプロジェクトは実装・単体テストを一括発注することになった。でも一括発注だとどのように品質をチェックしたらいいのだろう。いつものように目の前で作業をしてくれれば分かるんだけれど……。 なるほど、石出さんは実装・単体テストの品質に関して悩んでいるようです。 ◆ 品質の考え方 品質には大きく分けて2つの考え方があります。製品（システム）そのものの品質と製品を作成するプロセス（作り方）の品質です。前者は、
効率の良いコードレビュー [software]
とある友人が紹介してくれた，「苦痛を伴なわない効率の良いコードレビュー」という記事．なかなか良いことが書いてある． Effective Code Reviews Without the Pain 特に，コードレビューには，1) コードの品質を保証する，2) 開発者を教育する，という2つの目的があると前置きした上で，コードレビューに対するアプローチに言及している点がおもしろい． 1) 物事を断定するのではなく，質問を投げかけるようにすること 2) 「なぜ?」という質問を避けること 3) 褒めることを忘れないように 4) コーディングルールが確立されていること 5) 議論の対象はあくまでもコード，決してコーダー (開発者) になってはいけない 6) 解決方法は1つだけではないことを念頭に そしてもしあなたが開発者ならば， 1) コードがあなた自身ではないことを忘れないように 2) 自分用のチェ
へ〜たのめも:Google のソフトウェア・エンジニアリング - livedoor Blog（ブログ）
2007年06月07日 Google のソフトウェア・エンジニアリング Google Developer Day Tokyo の鵜飼さんのプレゼンより、「Google のエンジニアはどうやって開発しているのか?」 Google の研修 入社して最初の 3ヶ月は本社(Mountain View)で研修 研修中は、メンターがついて「Google での開発の仕方」を学ぶ 内部ウェブ・サイトで社内共有ライブラリの使い方などを説明する動画があるので、それで自習 Google のプロジェクト・チーム 開発拠点は米国、スイス、オーストラリア、インド、日本など 場所とプロジェクト・チームは関係なく、プロジェクト・チームが拠点をまたがることは普通。世界中の拠点全部合わせて、一つの Google エンジニアリング・チーム 開発はデザイン、コーディング、テスト、改善、デモの運用まで上流から下流まで同じチーム(同
googleの開発プロセス - 森崎修司の「どうやってはかるの？」 [ITmedia オルタナティブ・ブログ]
昨日に続きますが、ディベロッパーサミットでgoogleの開発プロセスについて聴講してきました。Googleは一味異なるプロセスや組織をお持ちのようです。請負開発をされている方には新鮮なのではないでしょうか。工藤氏はGoogleのインフラ寄りの話、小松氏は開発プロセスの話で講演されていました。サービスインフラも開発プロセスも私にとっては身近な話ですが、ここでは、小松氏の講演について書こうと思います。講演では、極めて異例/エキセントリックというプロセスは話されていませんでしたが、以下は、特徴的と感じました。 異なる観点から複数のレビューを実施していること。いわゆるperspective-based readingを実施しているそうです。役割分担型レビュー（reviewというよりはおそらくinspection）で、セキュリティやユーザインタフェースの観点から見たデザイン/ソースコードの妥当性検証
![googleの開発プロセス - 森崎修司の「どうやってはかるの？」 [ITmedia オルタナティブ・ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/7f2a4ced7f91e578679d11d5fcc8f34c5d080289/height=288;version=1;width=512/https%3A%2F%2Fblogs.itmedia.co.jp%2Fmt-static%2Fsupport%2Fassets_c%2Fuserpics%2Fuserpic-83-100x100.png)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
MSDN - 派生クラスから基本クラス イベントを発生させる