http://plus.appgiga.jp/masatolan/2014/07/10/52941/
株式会社コアテック | 404 Not Found
お探しのページが 見つかりませんでした 申し訳ございません。リンクに問題があるか、 ページが削除された可能性がございます。
アジャイル開発でソフトウェアの品質を高める方法
さて、アジャイル開発でソフトウェアの品質は良くなるか？ そう思う方、ちょっと手を挙げてください（4割くらい手が挙がる？）。けっこういますね。 自分の実感としては、アジャイルでは品質良くなる、と感じているが、一方で否定的な人もいる。 私がアジャイルを始めたころ、2002年あたりには、そういう否定的な人に対して「面倒くさいだけちゃうんか」とか「新しいプロセスに臆病なんじゃないか」と反発したりしていた。 考えてみると、ソフトウェアの品質には2つの側面がある。良し悪しという側面と、品質が確定しているかどうか、という側面。 品質保証担当の人が考えるアジャイルの品質確定のイメージは、こういうイメージなのかなと。アジャイルでイテレーションを繰り返して成果物が大きくなるにつれて、次のイテレーションで品質を確定させるためには、さらにたくさん作業をしなくちゃいけないなと。 この2つを比べると、ウォーターフォー
例え話だけで解決に向かうのか? - 技術的負債論 - MassKaneko.Out
はじめに 以下のエントリがHOTになっています。公開4日後の現在で949はてブです。 技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog 私は企業で Software Engineer in Test としてソフトウェアの保守性に責任を持つポジションに就いている身ですのでこのテーマに関心があるのはよいことだとは思います。技術的負債そのものについてのエントリは過去にも沢山あるようですが、mizchi さんのエントリは誤解を恐れないシンプルで断定的な書き方ですので多くの人に刺さったのでしょう。 ただ、技術的負債(technical debt)というメタファーが万人に誤解無く伝わるのかは疑問です。時間を借りているのかはピンと来ませんし、財務的負債と異なり返済の義務はありません。また、エンドユーザーに提供する価値よりも負債にフォーカスし
Jenkinsを使って継続的に静的コード解析をさせる - suzukij's diary
最近プロジェクト内でJenkinsをどう運用しているのか聞かれることがあったので書いておくことにします。 ビルドだけではもったいないので色々なことをやらせているのですが、とりあえず今回は静的コード解析について。 コード解析の設定は最初は少しだけ面倒かもしれませんが、出力されるレポートはプロジェクトの大事なインプットとなってくれます。 出力されたレポート、グラフを見て自分達の日々開発しているものをチェックしてチーム内の朝会やふりかえりでアレコレ語るのがいいんじゃないかと思います。 まずは必要なプラグインのインストール 静的コード解析 FindBugs Plugin - コンパイル後のバイトコードを解析してバグや不具合が発生しそうなコードをチェックしてくれる https://wiki.jenkins-ci.org/display/JENKINS/FindBugs+Plugin Checksty
Jenkinsをインストールして使ってみよう［Mac／Linux／Windows］
継続的インテグレーションツール「Jenkins」の使い方を基礎から解説する連載がスタート。初回は、Jenkinsの概要とインストール手順、簡単なジョブの登録方法を説明する。 連載 INDEX 次回 → Jenkinsとは何か？ 「Jenkins」というツールをご存じだろうか？ 情報に敏感な読者であれば「継続的インテグレーション（CI）」という言葉とともにネット上で一度や二度は見たことがあるかもしれない。しかしながら「継続的インテグレーション」という言葉の難解さや「Javaで作成されている」という点で、敷居が高く感じられ、導入を見送っているプログラマーの方もいるのではないだろうか。 そんな方々にとって、本連載がJenkinsを使うきっかけになれば幸いだ。本連載では、Jenkinsの使い方を基礎から説明する。その説明用のプログラミング環境としてはRubyを採用しているが、他の環境の方にも参考と
Ruby on Railsが簡単というのは嘘 - toyoshiの日記
WinユーザがRailsアプリをこれから公開しようと思った場合 Windowsで学習を開始するのは不可能なのでLinuxをいれる でもWindowsで進めようとしてmsysGitをいれたりするが結局半日無駄にする なぜかgemが最新じゃないと怒られる gemを単純に使っても後から困るのでrvmかrbenvが必要。使い方覚えないといけない やっとRails3.2導入。javascriptエンジンが入ってないので起動しない やっと起動 HTML書いてるのは情弱だけ => hamlを覚える js書いてるのは情弱だけ => coffee scriptを覚える css書いてるのは情弱だけ => scssを覚える テスト書いてないコードはレガシーコードっていわれる しかたないのでRspecいれる => Rspec覚える ユニットテストだけではしかたないといわれcapybaraもいれる => capyb
すごいぞRSpec(letとlet!編) - @yohfee.blog!
すでに前回のすごいぞRSpec(shared example group編) - ぷろぐらまねがで登場してるけどあらためてletを調べるよ。rspec-core(2.5.1)/features/helper_methods/let.featureを参考に。 let 要するにメモ化するわけで、同一サンプル内だと同じオブジェクトを使いまわせるのだな。違うサンプルでは改めて評価される。さらに遅延評価なので実際に評価されるのは最初にメソッドが呼ばれたときだ。 $count = 0 describe 'let' do let(:count) { $count += 1 } it 'memoizes the value' do count.should == 1 count.should == 1 end it 'is not cached across examples' do count.shou
[lib] モックとスタブの違い
TEST http://d.hatena.ne.jp/devbankh/201001 モックやスタブを使った効率的なユニットテスト http://d.hatena.ne.jp/devbankh/201002 モックとスタブの違い コミュニケーション http://d.hatena.ne.jp/devbankh/20051124 簡単かつ効果的に話すために "モックオブジェクト"という言葉は、テストのために本物のオブジェクトをまねる特殊なオブジェクトを表す言葉として定着した。しかしモックという言葉は元々スタブをキャッチーにしたものでなく、[スタブを使ったのとは別の] ユニットテスト方法を用いるためのものなのだ。この記事では、モックオブジェクトのファンに好まれる相互作用中心のテストと、よく行わている状態中心のテストスタイルとの違いを説明するために、モックとスタブの違いについて掘り下げる。 目次
![[lib] モックとスタブの違い](https://cdn-ak-scissors.b.st-hatena.com/image/square/06a15c64ba0ceec233d86d71001ebb29a9dcbf5d/height=288;version=1;width=512/https%3A%2F%2Fcdn.blog.st-hatena.com%2Fimages%2Ftheme%2Fog-image-1500.png)
rspecの標準matchers(マッチャー)一覧 - 酒と泪とRubyとRailsと
RSpecの標準マッチャー(matcher)の一覧を作ってみました。できるだけ一覧を見やすくして、開発の手助けになることを目指しています。 🚜 RSpecって何？RSpecのベーシックな情報は以下がお勧めです。 「RSpec をもっと理解したかったので、まとめを作りました」に感動してRuby 1.9.3でやってみた！ : 以前作ったものです。RSpecの導入の手助けになると思います。 改めて学ぶ RSpec : RSpec初歩からしっかり理解できるすばらしい記事です。 RSpec 簡潔に記述する(1) it ブロックを短く書く！ : 説明がすごくわかりやすくて勉強になります。 🐡 マッチャー一覧 マッチャー not 意味・機能
Rubyist Magazine - スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0064 号 バックナンバー Rubyist Magazine 0064 号 Rubyist Magazine 0063 号 Rubyist Magazine 0062 号 Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist
RSpecによるユニットテストの書き方 — recompile.net
2012年04月19日 最近、新人のテストコードを見る機会があり、ユニットテストの書き方について考える機会があった。ユニットテストはテンプレートみたいなものがあるので、それさえ押さえれば、誰でも簡単に書くことができる。 ここでは、その方法について紹介したい。サンプルはRSpecで書くが、その他のユニットテストフレームワークでも、応用ができるとおもう。 はじめにごく単純化すると、テスト対象は状態を持ち、入力を与えると何らかの出力を行なうものである。入力が変われば出力は変化するし、状態が変化すると入力が同じでも出力が変わる（かもしれない）。 ユニットテストは、テスト対象の状態を操作し、与えた入力によって意図通りの出力を得られるかを確認する作業のことをいう。なので、ユニットテストを書くときには、オブジェクトの状態ごとにメソッド単位で入力と出力を確認するようにする。 RSpecの疑似コードで書くと
「正しいアジャイル」でなくてもいい
34. スケジュール 先行開発チーム 仕様策定チーム 開発チーム １ヶ月 ２ヶ月 ３ヶ月 ４ヶ月 ５ヶ月 ６ヶ月 ▼先行開発 ベースラインアーキテクチャの策定やコア機能を先行で開 発。何度となくハマったが、難易度の高い部分に取り組んだ ことによって早期に多くことを学習できた。 顧客 １０年戦士 ５年戦士 13年5月26日日曜日 35. スケジュール 先行開発チーム 仕様策定チーム 開発チーム １ヶ月 ２ヶ月 ３ヶ月 ４ヶ月 ５ヶ月 ６ヶ月 ▼既存システム調査 既存システム要件／機能を分析し、随時「仕様策定チーム」 と連携。テスト仕様書に積極的にフィードバックし、仕様書 の精度を上げていった。 顧客 １０年戦士 ５年戦士 13年5月26日日曜日
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 直
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
