<?xml version="1.0" encoding="UTF-8"?>
 <rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://pinboard.in">
    <title>Pinboard (Vaguery)</title>
    <link>https://pinboard.in/u:Vaguery/public/</link>
    <description>recent bookmarks from Vaguery</description>
    <items>
      <rdf:Seq>	<rdf:li rdf:resource="http://arxiv.org/abs/1308.3689"/>
	<rdf:li rdf:resource="http://arxiv.org/abs/1412.4847"/>
	<rdf:li rdf:resource="http://arxiv.org/abs/1206.3713"/>
	<rdf:li rdf:resource="http://arxiv.org/abs/1209.5805"/>
	<rdf:li rdf:resource="https://github.com/riverglide/cukesalad/wiki"/>
	<rdf:li rdf:resource="http://lizkeogh.com/2010/07/23/what-not-to-test/"/>
	<rdf:li rdf:resource="http://elabs.se/blog/15-you-re-cuking-it-wrong"/>
	<rdf:li rdf:resource="http://open.bekk.no/2010/06/02/automated-functional-testing-of-iphone-apps-with-icuke/"/>
	<rdf:li rdf:resource="http://eggsonbread.com/2010/03/28/my-rspec-best-practices-and-tips/"/>
	<rdf:li rdf:resource="http://lizkeogh.com/2008/09/10/feature-injection-and-handling-technical-stories/"/>
	<rdf:li rdf:resource="http://iamneato.com/2009/08/01/rspec-and-sinatra-quick-start"/>
	<rdf:li rdf:resource="http://japhr.blogspot.com/2009/03/rspec-with-sinatra-couchdb.html"/>
	<rdf:li rdf:resource="http://wiki.github.com/aslakhellesoy/cucumber/step-organisation"/>
	<rdf:li rdf:resource="http://www.pathf.com/blogs/2009/03/using-cucumber-for-acceptance-testing/"/>
	<rdf:li rdf:resource="http://giantrobots.thoughtbot.com/2009/2/20/mixing-cucumber-with-test-unit"/>
	<rdf:li rdf:resource="http://mir.aculo.us/2006/09/16/adventures-in-javascript-testing"/>
	<rdf:li rdf:resource="http://jania.pe.kr/aw/moin.cgi/JSSpec"/>
	<rdf:li rdf:resource="http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd"/>
	<rdf:li rdf:resource="http://opensoul.org/2008/11/10/making-rspec-concise"/>
	<rdf:li rdf:resource="http://www.oreillynet.com/pub/a/ruby/2007/08/09/behavior-driven-development-using-ruby-part-1.html"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="http://arxiv.org/abs/1308.3689">
    <title>[1308.3689] Evolving a Behavioral Repertoire for a Walking Robot</title>
    <dc:date>2015-09-14T11:13:04+00:00</dc:date>
    <link>http://arxiv.org/abs/1308.3689</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Numerous algorithms have been proposed to allow legged robots to learn to walk. However, the vast majority of these algorithms is devised to learn to walk in a straight line, which is not sufficient to accomplish any real-world mission. Here we introduce the Transferability-based Behavioral Repertoire Evolution algorithm (TBR-Evolution), a novel evolutionary algorithm that simultaneously discovers several hundreds of simple walking controllers, one for each possible direction. By taking advantage of solutions that are usually discarded by evolutionary processes, TBR-Evolution is substantially faster than independently evolving each controller. Our technique relies on two methods: (1) novelty search with local competition, which searches for both high-performing and diverse solutions, and (2) the transferability approach, which com-bines simulations and real tests to evolve controllers for a physical robot. We evaluate this new technique on a hexapod robot. Results show that with only a few dozen short experiments performed on the robot, the algorithm learns a repertoire of con-trollers that allows the robot to reach every point in its reachable space. Overall, TBR-Evolution opens a new kind of learning algorithm that simultaneously optimizes all the achievable behaviors of a robot.
]]></description>
<dc:subject>robotics evolutionary-algorithms behavior-driven-design rather-interesting nudge-targets consider:representation</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:56d4586da032/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:robotics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:evolutionary-algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:behavior-driven-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rather-interesting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:nudge-targets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:consider:representation"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arxiv.org/abs/1412.4847">
    <title>[1412.4847] A representation of robotic behaviors using component port arbitration</title>
    <dc:date>2015-03-15T12:45:18+00:00</dc:date>
    <link>http://arxiv.org/abs/1412.4847</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[Developing applications considering reactiveness, scalability and re-usability has always been at the center of attention of robotic researchers. Behavior-based architectures have been proposed as a programming paradigm to develop robust and complex behaviors as integration of simpler modules whose activities are directly modulated by sensory feedback or input from other models. The design of behavior based systems, however, becomes increasingly difficult as the complexity of the application grows. This article proposes an approach for modeling and coordinating behaviors in distributed architectures based on port arbitration which clearly separates representation of the behaviors from the composition of the software components. Therefore, based on different behavioral descriptions, the same software components can be reused to implement different applications.
]]></description>
<dc:subject>robotics behavior-driven-design representation rather-interesting agent-based ontology nudge-targets problem-decomposition</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:42d8fd3dad7a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:robotics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:behavior-driven-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:representation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rather-interesting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:agent-based"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:ontology"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:nudge-targets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:problem-decomposition"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arxiv.org/abs/1206.3713">
    <title>[1206.3713] Learning the Structure and Parameters of Large-Population Graphical Games from Behavioral Data</title>
    <dc:date>2013-11-30T12:37:26+00:00</dc:date>
    <link>http://arxiv.org/abs/1206.3713</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[We consider learning, from strictly behavioral data, the structure and parameters of linear influence games (LIGs), a class of parametric graphical games introduced by Irfan and Ortiz [2011, 2013]. LIGs facilitate causal strategic inference: Making inferences from causal interventions on stable behavior in strategic settings. Applications include the identification of the most influential individuals in large (social) networks. Such tasks can also support policy-making analysis. Motivated by the computational work on LIGs, we cast the learning problem as maximum-likelihood estimation (MLE) of a generative model defined by pure-strategy Nash equilibria (PSNE). Our simple formulation uncovers the fundamental interplay between goodness-of-fit and model complexity: good models capture equilibrium behavior within the data while controlling the true number of equilibria, including those unobserved. We provide a generalization bound establishing the sample complexity for MLE in our framework. We propose several algorithms including convex loss minimization (CLM) and sigmoidal approximations. We formally prove LIGs have a small true number of PSNE, with high probability; thus, CLM is sound. We illustrate our approach on synthetic data and real-world U.S. congressional voting records. We briefly discuss our learning framework's generality and potential applicability to general graphical games.
]]></description>
<dc:subject>game-theory inverse-problems inference behavior-driven-design interesting nudge-targets algorithms</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:3a545ce6e08f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:game-theory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:inverse-problems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:inference"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:behavior-driven-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:interesting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:nudge-targets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:algorithms"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arxiv.org/abs/1209.5805">
    <title>[1209.5805] Memoryless Control Design for Persistent Surveillance under Safety Constraints</title>
    <dc:date>2013-03-07T11:23:19+00:00</dc:date>
    <link>http://arxiv.org/abs/1209.5805</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA[This paper deals with the design of time-invariant memoryless control policies for robots that move in a finite two- dimensional lattice and are tasked with persistent surveillance of an area in which there are forbidden regions. We model each robot as a controlled Markov chain whose state comprises its position in the lattice and the direction of motion. The goal is to find the minimum number of robots and an associated time-invariant memoryless control policy that guarantees that the largest number of states are persistently surveilled without ever visiting a forbidden state. We propose a design method that relies on a finitely parametrized convex program inspired by entropy maximization principles. Numerical examples are provided.]]></description>
<dc:subject>engineering-design monte-carlo-model agent-based nudge-targets multiobjective-optimization stochastic-system behavior-driven-design</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:4d59f5dee065/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:engineering-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:monte-carlo-model"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:agent-based"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:nudge-targets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:multiobjective-optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:stochastic-system"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:behavior-driven-design"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/riverglide/cukesalad/wiki">
    <title>Home - GitHub</title>
    <dc:date>2011-05-30T12:21:43+00:00</dc:date>
    <link>https://github.com/riverglide/cukesalad/wiki</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["CukeSalad is a Cucumber extension that allows you to focus on the task at hand - expressing examples, the roles involved in those examples and what those roles can do with the product under development."]]></description>
<dc:subject>Cucumber behavior-driven-design test-driven-design Ruby toolkit rubygem</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:Vaguery/b:85d81f10cb63/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Cucumber"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:behavior-driven-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:test-driven-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:toolkit"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rubygem"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://lizkeogh.com/2010/07/23/what-not-to-test/">
    <title>Liz Keogh's blog » What not to test</title>
    <dc:date>2010-08-12T12:27:56+00:00</dc:date>
    <link>http://lizkeogh.com/2010/07/23/what-not-to-test/</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["Work out which bits of the system you know least about. Create the scenarios and have conversations around those bits of the system. You don’t have to grow the system from the beginning – you can pick any point you like! Which bits of the system make you most uncomfortable? Which bits make your stakeholders most uncomfortable?"
]]></description>
<dc:subject>agility bdd behavior-driven-design best-practices advice software-development</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:62088bf41f2d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:agility"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:bdd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:behavior-driven-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:best-practices"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:advice"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software-development"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://elabs.se/blog/15-you-re-cuking-it-wrong">
    <title>You're Cuking It Wrong – Elabs</title>
    <dc:date>2010-08-12T12:20:07+00:00</dc:date>
    <link>http://elabs.se/blog/15-you-re-cuking-it-wrong</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["So where does this gulf of experiences come from, why is cucumber loved by some and hated by others. At the risk of over-generalisation and mischaracterisation I recently came up with a theory: the cucumber detractors are not using cuke the way it was intended."
]]></description>
<dc:subject>behavior-driven-design bdd cucumber antipatterns advice problem-I-sometimes-have</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:6f503c524027/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:behavior-driven-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:bdd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:cucumber"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:antipatterns"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:advice"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:problem-I-sometimes-have"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://open.bekk.no/2010/06/02/automated-functional-testing-of-iphone-apps-with-icuke/">
    <title>Automated functional testing of iPhone apps with iCuke – BEKK Open</title>
    <dc:date>2010-06-02T12:59:10+00:00</dc:date>
    <link>http://open.bekk.no/2010/06/02/automated-functional-testing-of-iphone-apps-with-icuke/</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["UK-based super hacker and long time Cucumber contributor Rob Holland announced iCuke yesterday. iCuke is a Cucumber extension that lets you write automated functional tests for iPhone apps. Here is a little teaser…"
]]></description>
<dc:subject>cucumber iPgibw software-development BDD behavior-driven-design testing</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:7bf2cca8eafe/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:cucumber"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:iPgibw"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software-development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:BDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:behavior-driven-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://eggsonbread.com/2010/03/28/my-rspec-best-practices-and-tips/">
    <title>(My) RSpec best practices and tips | EggsOnBread</title>
    <dc:date>2010-03-31T23:06:06+00:00</dc:date>
    <link>http://eggsonbread.com/2010/03/28/my-rspec-best-practices-and-tips/</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["After a year using RSpec, I’m happy to share “(My) RSpec Best Practices and Tips”. Let’s make your specs easier to maintain, less verbose, more structured and covering more cases!"
]]></description>
<dc:subject>rspec Ruby programming BDD behavior-driven-design best-practices tips testing</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:6b3f45516e67/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rspec"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:BDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:behavior-driven-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:best-practices"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:tips"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://lizkeogh.com/2008/09/10/feature-injection-and-handling-technical-stories/">
    <title>Liz Keogh's blog » Feature Injection and handling technical stories</title>
    <dc:date>2010-02-12T12:38:32+00:00</dc:date>
    <link>http://lizkeogh.com/2008/09/10/feature-injection-and-handling-technical-stories/</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["There are some technical stories, though, which really do deliver something the business care about. You can find this out by asking, “Who cares if I don’t do this? Who cares if I don’t have an automated build? If I don’t write unit tests? If I don’t write acceptance tests?”

This is where the feature injection comes in. I’m flexing Chris Matts’s template a bit to do this; here’s how mine reads:

In order to

will need ."
]]></description>
<dc:subject>BDD behavior-driven-design features software-development software-development-is-not-programming business-value</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:f639a25ea3b7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:BDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:behavior-driven-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:features"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software-development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software-development-is-not-programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:business-value"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://iamneato.com/2009/08/01/rspec-and-sinatra-quick-start">
    <title>RSpec and Sinatra Quick Start // iamneato.com</title>
    <dc:date>2009-11-04T12:19:52+00:00</dc:date>
    <link>http://iamneato.com/2009/08/01/rspec-and-sinatra-quick-start</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["Are you familiar with RSpec, new to Sinatra, and can’t get the two to cooperate? This article maybe of use to you. Alternatively, if you’re like me and you’re simply new to this universe all together, this article can certainly be of use."
]]></description>
<dc:subject>RSpec BDD behavior-driven-design Sinatra testing tutorial how-to ruby</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:f789b0221f06/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:RSpec"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:BDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:behavior-driven-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Sinatra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:tutorial"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:how-to"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:ruby"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://japhr.blogspot.com/2009/03/rspec-with-sinatra-couchdb.html">
    <title>japh(r): RSpec with Sinatra &amp; CouchDB</title>
    <dc:date>2009-11-04T12:17:04+00:00</dc:date>
    <link>http://japhr.blogspot.com/2009/03/rspec-with-sinatra-couchdb.html</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["I left off last night moving into the guts of the application. The plan was to start BDDing with RSpec. It occurred to me, however, that I had no idea how to do it. Happily, Sinatra's testing documentation includes RSpec information."
]]></description>
<dc:subject>BDD behavior-driven-design rspec Sinatra Ruby web-applications CouchDB</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:c6fc856af4b4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:BDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:behavior-driven-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rspec"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Sinatra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:web-applications"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:CouchDB"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://wiki.github.com/aslakhellesoy/cucumber/step-organisation">
    <title>Step Organisation - cucumber - GitHub</title>
    <dc:date>2009-09-15T14:01:40+00:00</dc:date>
    <link>http://wiki.github.com/aslakhellesoy/cucumber/step-organisation</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["How do you name step files? What to put in each step? What not to put in steps? Here are some guidelines that will lead to better scenarios. If you are new to steps and the general syntax, please read Feature Introduction first."
]]></description>
<dc:subject>Cucumber BDD behavior-driven-design design-patterns antipatterns advice</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:16b5d652c89e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Cucumber"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:BDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:behavior-driven-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:design-patterns"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:antipatterns"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:advice"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.pathf.com/blogs/2009/03/using-cucumber-for-acceptance-testing/">
    <title>Agile Ajax » Using Cucumber for Acceptance Testing » Pathfinder Development</title>
    <dc:date>2009-03-21T14:48:40+00:00</dc:date>
    <link>http://www.pathf.com/blogs/2009/03/using-cucumber-for-acceptance-testing/</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["My experience so far, as I explore what Cucumber can do, has been largely positive. Where I was starting with Cucumber and only a vague idea of how the user interaction would play out, writing the scenarios at the Cucumber level felt very valuable and gave the development a clear path that I wouldn't have otherwise had. That said, there is extra code being written, and it's clearly possible to get really tangled in getting the step definitions right."
]]></description>
<dc:subject>Cucumber BDD behavior-driven-design Ruby TDD Machinist testing agility software-development</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:6cdb49f428d7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Cucumber"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:BDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:behavior-driven-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:TDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Machinist"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:agility"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software-development"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://giantrobots.thoughtbot.com/2009/2/20/mixing-cucumber-with-test-unit">
    <title>Mixing Cucumber with Test::Unit/Shoulda — GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS</title>
    <dc:date>2009-02-22T00:40:33+00:00</dc:date>
    <link>http://giantrobots.thoughtbot.com/2009/2/20/mixing-cucumber-with-test-unit</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["We’ve been writing a “feature” for every new client request on that project – for each user-created ticket we handle, we create a .feature file (and include the ticket number in the feature title), and write steps for that request. This means that we have acceptance tests for all new client requests on that project. This approach may seem a little strange, but it’s been helpful, and we’re very happy with it so far. We’ll likely take a different approach if we use Cucumber on a project from scratch.

Now you have no excuse if your projects aren’t doing any kind of top-down testing, so get out there and write some acceptance tests!"
]]></description>
<dc:subject>test-driven-development TDD behavior-driven-design BDD cucumber shoulda ruby testing agility emergent-design</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:1a293e6f34b5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:test-driven-development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:TDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:behavior-driven-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:BDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:cucumber"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:shoulda"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:agility"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:emergent-design"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://mir.aculo.us/2006/09/16/adventures-in-javascript-testing">
    <title>mir.aculo.us</title>
    <dc:date>2009-01-09T13:32:15+00:00</dc:date>
    <link>http://mir.aculo.us/2006/09/16/adventures-in-javascript-testing</link>
    <dc:creator>Vaguery</dc:creator><dc:subject>Javascript BDD TDD test-driven-design behavior-driven-design RoR programming presentations framework scriptaculous unittest</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:3436a117e464/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Javascript"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:BDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:TDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:test-driven-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:behavior-driven-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:RoR"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:presentations"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:framework"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:scriptaculous"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:unittest"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://jania.pe.kr/aw/moin.cgi/JSSpec">
    <title>JSSpec - AlansWiki</title>
    <dc:date>2009-01-09T12:32:24+00:00</dc:date>
    <link>http://jania.pe.kr/aw/moin.cgi/JSSpec</link>
    <dc:creator>Vaguery</dc:creator><dc:subject>Javascript BDD behavior-driven-design programming development testing ajax rspec behavior framework spec</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:c2207eabdad9/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Javascript"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:BDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:behavior-driven-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:ajax"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rspec"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:behavior"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:framework"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:spec"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd">
    <title>The Truth about BDD</title>
    <dc:date>2008-12-31T15:39:12+00:00</dc:date>
    <link>http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd</link>
    <dc:creator>Vaguery</dc:creator><description><![CDATA["But enough of irony. Is this useful? I think it may be. You see, one of the great benefits of describing a problem as a Finite State Machine (FSM) is that you can complete the logic of the problem. That is, if you can enumerate the states and the events, then you know that the number of paths through the system is no larger than S * E. Or, rather, there are no more than S*E transitions from one state to another. More importantly, enumerating them is simply a matter of creating a transition for every combination of state and event.

One of the more persistent problems in BDD (and TDD for that matter) is knowing when you are done. That is, how do you know that you have written enough scenarios (tests). Perhaps there is some condition that you have forgotten to explore, some pathway through the system that you have not described."
]]></description>
<dc:subject>via:arsyed software design BDD programming TDD behavior-driven-design analogies finite-state-machine</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:5e33503c3c92/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:via:arsyed"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:BDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:TDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:behavior-driven-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:analogies"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:finite-state-machine"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://opensoul.org/2008/11/10/making-rspec-concise">
    <title>Making RSpec concise | opensoul.org</title>
    <dc:date>2008-11-10T13:08:56+00:00</dc:date>
    <link>http://opensoul.org/2008/11/10/making-rspec-concise</link>
    <dc:creator>Vaguery</dc:creator><dc:subject>rspec cucumber BDD behavior-driven-design Ruby programming software development</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:3039aad6c940/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rspec"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:cucumber"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:BDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:behavior-driven-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:development"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.oreillynet.com/pub/a/ruby/2007/08/09/behavior-driven-development-using-ruby-part-1.html">
    <title>O'Reilly Network -- Behavior Driven Development Using Ruby (Part 1)</title>
    <dc:date>2008-03-11T20:51:31+00:00</dc:date>
    <link>http://www.oreillynet.com/pub/a/ruby/2007/08/09/behavior-driven-development-using-ruby-part-1.html</link>
    <dc:creator>Vaguery</dc:creator><dc:subject>agile BDD behavior-driven-design software development programming Rails RoR Ruby rspec</dc:subject>
<dc:identifier>https://pinboard.in/u:Vaguery/b:7b1903e2bdb6/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:agile"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:BDD"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:behavior-driven-design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:development"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Rails"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:RoR"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:Ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:Vaguery/t:rspec"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>